Як агенції підключити розробника до проєкту клієнта без хаосу в перший тиждень

Цей збій виглядає буденно, тому його легко недооцінити. Клієнт хоче швидкості. У спадок лишилися архів, старий пароль і кілька уривків переписки. Агенція додає нового виконавця в клієнтський чат і сподівається, що далі все складеться саме. За кілька днів розробник уже ставить питання не туди, клієнт чує відповіді напряму, а агенція втрачає роль того, хто тримає рамку. Ззовні ніби є рух, але перший помітний результат часто не можна випустити, бо ніхто не розуміє, як зміни доходять до робочого сайту.

Тут не допомагає ні досвід людини, ні її швидкість. Якщо старт не обмежений і не описаний, новий учасник команди починає закривати чужі прогалини замість своєї роботи. Нормальне швидке підключення означає не «пообіцяти більше», а «звузити перший тиждень до керованого обсягу». Саме для цього варто мати короткий пакет, який агентство готує до першого контакту з клієнтом.

Цю нотатку зручно тримати поруч з двома іншими. Для наявного Laravel-проєкту підійде передача, яка не виносить сюрпризи на дзвінок із клієнтом. Для нової сторінки або нового сценарію потрібен бриф, з якого розробник може стартувати без вгадування. А цей текст корисний тоді, коли людина входить у клієнтський проєкт із дедлайном, історією рішень і посередництвом агенції.

1. Що саме означає хаос у перший тиждень

Хаос — це не сам факт запитань. Запитання потрібні в будь-якому живому проєкті.

Проблема починається тоді, коли вони йдуть не в ту розмову, не до тієї людини і не про ті речі. Особливо якщо агенція вже мала ці відповіді або принаймні могла чесно позначити прогалини як невідомі.

Найчастіше все ламається одразу в кількох місцях. Розробник пише клієнту напряму, бо внутрішня гілка мовчить. Відповідь повертається в переказі, а не в оригіналі. Першим завданням стає щось показове для статусного дзвінка, хоча шлях викладки ніхто не підтвердив. Доступи приїжджають спільним паролем, дампом бази на особистому ноутбуці або чужим логіном, який завтра може зникнути.

Для такого сценарію не потрібен слабкий фахівець. Досить того, що клієнт уже почув дату, а пакет вирішили підготувати потім. Насправді саме це «потім» і створює перший збій. Дату краще обговорювати до знайомства або представляти розробника як людину, яка ще має перевірити, чи ця дата взагалі реальна.

2. Що передати до відкриття проєкту

Усе стартове має лежати в одному видимому місці. Не в трьох чатах, не в усних переказах після дзвінка, не в особистих повідомленнях між двома людьми.

• Хто з боку агенції затверджує обсяг робіт, і хто з боку клієнта має право додавати нові задачі. По одному імені.
• Куди йдуть питання. Одна стрічка. Розробник не збирає відповіді через повідомлення клієнту «тільки цього разу».
• Що означає «хороший перший тиждень». Зазвичай це так: проєкт запускається не на живому сайті, один критичний шлях перевірено, список невідомого записано. Не так: нова кампанія вже викладена.
• Доступи як окремі облікові записи, які агенція або клієнт можуть відкликати. Репозиторій, хостинг, домен, місце, де читають заявки, оплати, якщо задача їх зачіпає. Пароль від продакшену в стрічку не вставляють.
• Так чи ні: чи існує тестове середовище, яке не є живим сайтом. Якщо ні, це і є перше завдання, а дата для клієнта залежить саме від цього. Версія для власника продукту є тут: чому відсутність тестового середовища — не причина правити живий сайт.
• Один сценарій, який не можна зламати: форма, що створює заявку у звітності, оплата, бронювання. По одному реченню від агенції, навіть якщо це речення звучить як «ми поки не знаємо».
• Як зміна потрапляє на живий сайт — тими словами, які у вас є. «Це робила попередня людина» — нормальна стартова відповідь. Удавати, що кроки відомі, — погана ідея.

Якщо в той самий тиждень у роботі є дизайнер, макет не варто вважати готовим без порожніх станів, помилок і очікування. Інакше ці частини вигадає розробник, а перевірка перетвориться на нове коло переробок. Для цього випадку є окрема нотатка: що передати разом із макетом. Нова людина не повинна закривати розрив між сирим макетом і нетерплячим клієнтом.

3. Якими мають бути перші дні

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

Далі потрібна одна безпечна зміна в тестовому середовищі. Її обирають не за красою для дзвінка, а за користю: вона має довести, що шлях від редагування до перевірки справді існує. Саме агенція дивиться на цей результат першою або прямо називає того, хто його перевіряє. Клієнту не потрібна технічна екскурсія. Йому потрібне коротке пояснення, що вже працює і що ще лишається відкритим.

Зовнішній голос у цей тиждень має лишатися за агенцією. Якщо потрібен факт, який знає тільки клієнт, питання надсилаєте ви або лишаєтесь у спільній гілці з контекстом. Окремий бічний чат здається швидким лише на хвилину. Потім він розрізає історію рішень, і за два тижні вже ніхто не може відтворити, чому команда пішла саме цим шляхом.

4. Від чого краще відмовитися

Не варто замінювати підготовку простим додаванням людини в клієнтський чат. Не варто кидати пароль від продакшену в переписку, щоб «не втрачати день». Не варто називати тестовим середовищем повну копію клієнтської бази на чиємусь ноутбуці. Це не прискорення, а ще одна точка ризику. Для першого тижня достатньо меншого набору даних, якщо на ньому можна пройти критичний сценарій. Якщо збій видно лише на реальному навантаженні, це треба сказати прямо і запланувати відновлення, яке можна описати крок за кроком.

Так само не слід поєднувати аварійне вирівнювання і запуск в одну п’ятницю. Якщо проєкт зайшов напівполаманим, перший тиждень має стабілізувати шлях, а не одночасно рятувати репутацію і виштовхувати кампанію в реліз. І не треба видавати зміну на живому сайті за ознаку професіоналізму. Коли перевірити ніде, крім робочого сайту, це треба назвати вголос, а не маскувати під сміливість команди.

5. Який статус можна переслати клієнту

Наприкінці тижня у вас має бути короткий статус без перекладу комітів. Де саме можна перевірити проєкт. Який сценарій уже пройдено. Що досі невідомо. Від чого залежить наступна дата.

Якщо цих чотирьох рядків немає, це не означає, що розробник відстає. Зазвичай це означає, що стартовий пакет був неповним або список прогалин ніхто не прочитав як слід. Спершу треба виправити це, а вже потім думати про другу людину в тому самому проєкті. Двоє виконавців без однієї стрічки й без місця для перевірки не зменшують хаос, а просто множать його.

Коли підключати розробника ще до обіцянки на тиждень

Людину варто залучати до того, як клієнт почує дату, якщо задача стосується оплат, спільної клієнтської бази або шляху викладки, який ніхто в агенції не може описати без здогадок. Те саме стосується ситуації, коли ви вже знаєте, що тестового середовища немає. Розробник, якого приводять після слів «ми майже все зробили», успадковує не контрольований старт, а чужий сюрприз.

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