Три разговора до старта проекта, которые спасли меня от полугода боли
Самый дорогой проект в моей практике обошёлся не в деньгах.
Он обошёлся в пять месяцев переработки. Потому что мы с клиентом по-разному понимали слово «готово». Я считал готовым то, что работало в проде. Клиент считал готовым то, что соответствовало его ментальной модели продукта — которую он ни разу не произнёс вслух.
Технически код был правильным. Архитектурно всё держалось. Просто мы говорили о разных системах.
Теперь у меня три разговора, которые я провожу до того, как открыть редактор. Это то, что помогает правильно поставить ожидания клиенту до старта. Каждый занимает 30–40 минут. Вместе они сохранили мне гораздо больше, чем эти пять месяцев.
Почему «мы всё обсудили» — это иллюзия
У любого нового проекта есть момент эйфории: бриф согласован, бюджет одобрен, дата запуска стоит в Google Calendar. Все кивают. Все довольны. Все говорят «да» — но каждый о своём.
Клиент говорит «да, делаем», имея в виду «и вот эти дополнительные вещи, которые я не внёс в бриф, тоже входят». Разработчик говорит «да, сделаем», имея в виду «то, что написано в техническом задании, и ничего кроме».
Эти два «да» — разные слова.
Scope creep — не проблема злого умысла. Это почти всегда проблема несогласованных предположений. Клиент не скрывал свои ожидания. Он просто не знал, что их нужно произносить вслух. Разработчик не упустил требования. Он просто считал, что всё, чего нет в ТЗ, не входит в проект.
Три разговора не устраняют неопределённость — они делают её видимой до того, как за неё уже заплачено чужим временем.
Разговор первый: что такое «готово» — произносим вслух
Это самый странный разговор из трёх. Потому что на него реакция почти всегда одна: «Ну, готово — значит работает».
Работает — это не определение.
Я задаю конкретные вопросы: «Что должно произойти, чтобы вы сказали мне, что проект закрыт?» Не «какие функции должны быть», а именно «что произойдёт». Это другой вопрос.
Потому что «работает» может означать:
- функции запущены в прод и нет критических багов
- функции запущены, прошли приёмочное тестирование клиента
- функции запущены, обучен персонал, написана документация
- функции запущены и проект показал первые 30 дней метрик
Всё это — «работает». Но это разный объём работы, другие сроки, другая цена.
Я пишу Definition of Done прямо в письме по итогам встречи: «По итогам нашего разговора, проект считается завершённым, когда: [три пункта, конкретно, без "и прочее"]». И прошу клиента добавить то, чего не хватает.
Важный момент: клиент часто добавляет. Не потому что хочет обмануть — а потому что только увидев список понял, что в нём чего-то нет.
В одном из проектов клиент после такого письма дописал: «И нам нужна возможность самостоятельно добавлять промо-баннеры без обращения к разработчику». Это была неделя работы, о которой мы иначе узнали бы после «сдачи» проекта.
Лучше — до.
Разговор второй: что мы НЕ делаем — фиксируем
У меня есть правило: к каждому ТЗ я прикладываю список из 3–5 пунктов «что не входит в этот проект». Не потому что хочу занизить объём. А потому что без явного «нет» любое «нет» звучит как отказ.
Типичные пункты:
- интеграция с системой лояльности — отдельный проект
- мобильное приложение — не в этом этапе
- SEO-оптимизация контента — за рамками разработки
Клиент читает ТЗ и видит, что написано. Он не видит, что не написано. А потом спрашивает через два месяца: «А почему нет автоматической рассылки?» — и это звучит как логичный вопрос, потому что для него это был очевидный контекст.
Явный список «out of scope» превращает такой разговор из конфликта в спокойное «да, мы договаривались без этого, давайте оценим отдельно».
Я узнал это поздно. На одном проекте мы полтора месяца потратили на функцию, которую клиент считал «само собой разумеющейся», а я — выходящей за рамки договора. Ни один из нас не был неправ. Мы просто оба предполагали, что другой понимает границы так же, как он.
После того как я начал фиксировать «что не делаем», конфликты на эту тему прекратились. Не потому что клиенты стали проще. А потому что у нас теперь есть общий документ, на который можно сослаться.
Если в процессе работы появляется новый запрос — мы добавляем его в список изменений с отдельной оценкой. Не «мы не будем это делать», а «это выходит за рамки текущего договора, вот сколько это займёт дополнительно».
Разговор третий: кто принимает решение, когда мы расходимся
На большинстве проектов есть несколько людей с мнением. Руководитель, который подписывал бюджет. Маркетолог, который будет пользоваться системой. IT-специалист, который будет её поддерживать. Иногда все трое хотят разного.
Мне не важно, кто прав. Мне важно знать — чьё «да» закрывает вопрос.
Я задаю этот вопрос напрямую: «Если в процессе работы мы с вами не придём к согласию по какому-то техническому решению — кто принимает финальное решение?» Это неловкий вопрос. Но он необходим.
Без ответа на него я могу согласовать что-то с одним человеком, потратить две недели на разработку — и услышать от другого, что это нужно переделать, потому что «он же не принимает решения, это я принимаю».
Технически все правы. Просто у проекта нет единой точки принятия решений. Я потерял две недели.
Теперь в начале проекта я явно спрашиваю: «Кто principal? Кто финально согласует технические решения?» Если их двое — это нужно зафиксировать и понять, как они между собой договариваются.
Это не про субординацию. Это про то, что разработчик не должен быть медиатором между двумя равноправными стейкхолдерами.
Почему это выгодно клиенту, а не только мне
Я понимаю, как это звучит: разработчик придумал три способа защититься от клиента. Но если смотреть на цифры — клиент выигрывает не меньше.
Scope creep стоит деньги обеим сторонам. Клиент платит за переработки, которых не ожидал. Или получает урезанный продукт, потому что бюджет кончился. Или проект затягивается — и теряются сроки запуска.
Пять месяцев, которые я потратил на тот «дорогой» проект, — это пять месяцев, когда клиент не получал работающий продукт. Это не только мои потери.
Definition of Done, out-of-scope список и ясность по decision-making — это инструменты прозрачности, а не защитные механизмы. Клиент знает, что он покупает. Разработчик знает, что он продаёт. Это честная сделка.
Я часто слышу от клиентов после первого же проекта вместе: «Хорошо, что ты это обговорил заранее. Раньше мы всегда узнавали о таких вещах в процессе». Это не комплимент моей переговорной технике. Это подтверждение, что большинство разработчиков этого не делают.
Как эти разговоры менялись
Первые версии были хуже.
Поначалу я просто спрашивал «вы согласны с ТЗ?» и считал это достаточным. Потом начал добавлять явный список «out of scope» — и сразу почувствовал разницу. Потом добавил вопрос про decision-maker — и это решило класс проблем, с которыми я раньше не знал, что делать.
Definition of Done появился последним — и оказался самым ценным. Потому что формулировка «что должно произойти, чтобы вы сказали мне, что всё» — это не про технику. Это про то, как клиент вообще думает о результате.
Два часа до старта. Это реальная инвестиция. И я не знаю ни одного проекта, где она не окупилась.
Если интересен контекст про то, как я оцениваю риски ещё до того, как принять проект вообще — читайте «Как я вычисляю трудного клиента ещё до старта проекта». Это предшествующий шаг: сначала понять, с кем работать, потом — как начать работу правильно. А если хочется увидеть, как я думаю о рисках внутри проекта в целом — «Я перестал закрывать тикеты. Стал закрывать риски».