Крупная компания присылает ТЗ на сорок страниц. Половина требований спорит с другой половиной, сроки взяты с потолка, а на первой встрече выясняется, что треть функций «надо обсудить отдельно». Раньше мы в такой ситуации подписывали договор и садились за разработку. Несколько болезненных проектов спустя поняли, что так нельзя.
Почему сырое ТЗ опасно
ТЗ от крупной компании почти никогда не отражает реальность. За документом обычно стоит legacy-система, согласования между отделами и автор ТЗ, который уже уволился.
Зафиксируешь смету по такому документу вслепую, и дальше либо уходишь в минус, либо начинаешь экономить, а заказчик это чувствует. Оба сценария плохие.
Аудит как отдельный первый этап
Мы стали выносить разбор в отдельный платный этап до разработки. Что в него входит:
- разбор текущей архитектуры и инфраструктуры;
- отделение реальных потребностей от того, что попало в ТЗ по инерции;
- разговор с теми, кто будет пользоваться системой, а не только с теми, кто подписывает счета;
- поиск рисков, которые в ТЗ не упомянуты.
На выходе заказчик получает непротиворечивое ТЗ, архитектуру, этапы с оценкой и карту рисков. Эти артефакты самоценны: даже если человек уйдёт делать продукт с другой командой, он уносит рабочий документ, а не обрывки.
Отдельно про «платный». Первое время было неловко брать деньги за анализ, пока не заметили закономерность: к бесплатной работе относятся как к бесплатной. Деньги резко поднимают и вовлечённость заказчика, и серьёзность разговора.
Как это превращается в разработку
После аудита обсуждаем не абстрактное ТЗ, а конкретный план, который сами составили и который заказчик уже видел. Дальше идём итерациями по две недели с демо, чтобы правки всплывали рано, а не на финальной приёмке.
Структура готова заранее, поэтому задачи ведём параллельно, а по спорным развилкам советуемся с коллегами из других компаний: свежий взгляд не раз спасал от решения, которое изнутри выглядело логичным, а оказывалось тупиковым.
Что мы поняли по дороге
Аудит нельзя растягивать: он превратится в месяц переписки, и потеряется смысл быстрого первого шага.
Иногда честный вывод аудита — «вам не нужна разработка». Краткосрочно теряешь проект, в долгую получаешь доверие, и такие заказчики возвращались.
Схема работает не везде. Для большой системы с высокой ценой ошибки аудит окупается, для лендинга он избыточен.
И главное: платный аудит сам по себе фильтр. Кто не готов вложиться в разбор своей системы, почти наверняка не дойдёт и до конца большого проекта.
Вопрос к сообществу
А у вас вход в крупные проекты как устроен: берёте ТЗ как есть или сначала делаете свой разбор? И если разбор, то платный или за свой счёт? Любопытно сравнить подходы.
Если хотите обсудить пост или поделиться идеями, напишите на sayat@silkroadtech.kz.
