Что нужно новому подрядчику от прежнего, чтобы принять сайт и начать работу

В последнее время заказчики по понятным причинам уходят от зарубежных подрядчиков и ищут российских. Причины эти мы обсуждать не будем, а поговорим о следствии.

Любой бизнес хочет пережить такие перемены быстро и без стресса для продукта. Но сайты — сложные ребята, и для дружбы с ними новому агентству нужны вводные. Мы уже много раз были и прежним, и новым подрядчиком, так что успели составить список таких вводных. Делимся.

Вы — российская компания, которая заказывала поддержку сайта у зарубежного агентства или у ваших земляков. Планируете передать развитие в руки нового подрядчика.

Представим, что у вас любимый доберман, для которого вы регулярно нанимаете няню. Но потом вы находите догситтера подешевле или с навыками дрессировки. Ему нужно поладить с собакой, чтобы получить деньги и не отхватить от нее. От прошлой няни он должен узнать, когда и где доберман гуляет, что его триггерит и к какому стилю общения приучен. Тогда пес быстро привыкнет к новому человеку и будет вилять хвостом.

Точно такая же схема действует и на диджитал-проектах. Одна команда растила проект, занималась дизайном, дорабатывала функционал, вносила правки в код. Без ее исходников новому подрядчику придется рисовать баннеры с нуля, а программисту лопатить незадокументированный легаси. Это дорого, долго, энергозатратно и не выгодно никому.

Если мы говорим о технической поддержке, то для приемки сайта новому агентству нужно провести ревью кода и перенести код в GIT, настроить деплой, подготовить рецепты для выкатки на прод и изучить архитектуру сайта. Для всего этого нужны исходные данные.

Для дорисовки дизайна и креативной поддержки (баннеры, лендинги, плашки и прочий дизайнерский контент)

— макеты, которые делал прошлый подрядчик (Figma / Photoshop / Adobe Illustrator)

— гайдлайны

— брендбук или дизайн-система со шрифтами, фирменными цветами и фотобиблиотекой

Для технического саппорта и развития

а) Доступы

— SSH на продакшен с правами root и admin

— к MySQL с правами root и правами как у сайта

— к административной панели сайта с полными правами

— в контрольную панель

— к управлению всеми используемыми доменами и ДНС хостера

— к административному интерфейсу хостинга

— root-доступ к серверу, где размещается сайт

— в контрольную панель провайдера

— в GIT

б) Проектная документация

На практике проектная документация встречается редко, но лучше хотя бы попробовать запросить ее у прошлого подрядчика. Обычно она включает архитектуру, модель и логику работы системы, классы пользователей и уровни доступа, описание API, тестовые данные, описание интеграций. Кроме того, желательно получить от подрядчика документацию со списком внесенных изменений в дефолтную версию CMS и дизайна.

в) Счетчики веб-аналитики

Если прошлый подрядчик вешал на сайт какие-либо счетчики, запросите для каждого логин и пароль. Обратите внимание: некоторые счетчики программисты вставляют в код сайта, поэтому обычные пользователи их не видят. Например, для Яндекс Метрики и Google Analytics. Если в будущем вы планируете их использовать, запросите доступы.

Напомним о банальщине: каждый проект индивидуален. Так что что-то из этого списка может и не подходит под вашу ситуацию. Скажем, отрисовка баннеров не входит в ваши планы.

Выбирайте то, что подходит. Тогда ваш доберман будет сыт, весел и игрив.