Как агентству подключить разработчика к проекту клиента без хаоса в первую неделю

Такой срыв выглядит почти привычно. Клиент спешит. От прошлого исполнителя остались архив, пароль и обрывки старой переписки. Кто-то из аккаунт-команды добавляет нового разработчика в клиентский чат и рассчитывает, что дальше люди сами договорятся. Через несколько дней разработчик уже задаёт клиенту вопросы, которые агентство должно было закрыть заранее. Клиент слышит ответы напрямую и начинает думать, что агентство выпало из процесса. Снаружи как будто есть движение, но первый заметный результат часто нельзя выпустить, потому что никто не может по шагам объяснить путь изменения до рабочего сайта.

Здесь дело не в медленном специалисте и не в том, что человек «долго раскачивается». Если старт не очерчен, новый участник проекта начинает латать чужие пробелы вместо своей задачи. Быстрое подключение означает не более смелое обещание, а более узкую и управляемую первую неделю. Поэтому агентству нужен не героизм на созвоне, а короткий пакет, который готовится до первого контакта разработчика с клиентом.

1. Что на первой неделе действительно означает хаос

Сам факт вопросов не является проблемой. Вопросы в живом проекте неизбежны.

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

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

Для этого сценария не нужен слабый исполнитель. Достаточно того, что клиент уже услышал дату, а подготовку решили отложить. Ошибка возникает именно в этот момент. Дату лучше обсуждать до знакомства или представлять разработчика как человека, который ещё должен проверить, реальна ли она вообще.

2. Что передать до того, как человек откроет проект

Стартовая информация должна лежать в одном месте, которое видят и разработчик, и аккаунт-лид.

• Кто со стороны агентства утверждает объём работ, и кто со стороны клиента имеет право добавлять новые задачи. По одному имени.
• Куда идут вопросы. Одна лента. Разработчик не собирает ответы сообщениями клиенту «только в этот раз».
• Что считается хорошей первой неделей. Обычно так: проект запускается не на бою, один критичный путь проверен, список неизвестного записан. Не так: новая кампания уже выложена.
• Доступы как отдельные учётные записи, которые агентство или клиент могут отозвать. Репозиторий, хостинг, домен, место, где читают заявки, оплаты, если задача их затрагивает. Пароль от продакшена в ленту не вставляют.
• Да или нет: существует ли тестовая среда, которая не является боевым сайтом. Если нет, это и есть первая задача, а клиентская дата зависит именно от этого. Версия для владельца продукта разобрана здесь: почему отсутствие тестовой среды — не повод править боевой сайт.
• Один сценарий, который нельзя сломать: форма, создающая заявку в отчётности, оплата, бронирование. По одному предложению от агентства, даже если это предложение звучит как «мы пока не знаем».
• Как изменение попадает на боевой сайт — теми словами, которые у вас есть. «Это делал прошлый человек» — нормальный стартовый ответ. Делать вид, что шаги известны, не надо.

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

3. Как должны пройти первые дни

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

Следом нужна одна безопасная правка в тестовой среде. Её выбирают не за эффектность, а за полезность: она должна доказать, что путь от изменения до проверки существует и понятен. Агентство смотрит на этот результат первым или прямо называет коллегу, который его проверяет. Клиенту не нужен рассказ о внутренней кухне репозитория. Ему нужно коротко услышать, что уже работает и что ещё остаётся открытым.

Внешняя коммуникация в эту неделю должна оставаться у агентства. Если нужен факт, который знает только клиент, вопрос отправляете вы или остаетесь в общей переписке с контекстом. Боковой чат кажется удобным только в моменте. Потом он рвёт историю решений на куски.

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

4. От чего агентству лучше отказаться в эту неделю

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

Не надо смешивать аварийное выравнивание и запуск в одну пятницу. Если проект пришёл поломанным, первая неделя должна стабилизировать путь, а не одновременно спасать репутацию и тащить кампанию в релиз.

И ещё одно правило. Не называйте изменение на рабочем сайте признаком опыта. Когда проверить больше негде, это нужно озвучить прямо. Разработчик, который соглашается срочно исправить всё сразу на бою, прикрывает чужую дату реальными заказами клиента.

5. Какой статус можно переслать клиенту

К концу недели у вас должен появиться короткий статус без перевода коммитов: где проект можно проверить, какой сценарий уже пройден, что до сих пор неизвестно и от чего зависит следующая дата.

Если этих строк нет, это обычно говорит не о медленном разработчике, а о неполном стартовом пакете или о том, что список пробелов никто не прочитал внимательно. Сначала нужно исправить это, и только потом думать о втором человеке в том же проекте.

Когда стоит подключать разработчика ещё до обещания на неделю

Человека лучше звать до того, как клиент услышит дату, если задача касается оплат, общей клиентской базы или пути выкладки, который в агентстве никто не может описать без догадок. То же самое относится к ситуации, когда вы уже знаете, что тестовой среды нет. Разработчик, которого приводят после фразы «мы почти всё сделали», получает не аккуратный старт, а чужой сюрприз.

Я смотрю на такой вход как на ограниченную первую неделю: пакет, место для проверки, критичный сценарий и только потом изменение. Услуги охватывают отдельные проекты и длительную работу, где агентство остаётся между сторонами. Выбранные работы показывают тип унаследованных продуктов, в которые такие подключения попадают чаще всего. Если вам нужно быстро ввести человека в клиентский проект, пришлите имена тех, кто утверждает объём, укажите, есть ли тестовая среда, и напишите, какую дату уже назвали или ещё не называли. Пароли присылать не нужно.