Почему техзадание на тридцать страниц всё равно перепишут — и что мы делаем вместо него

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

Папка с техзаданием на первой встрече

Сценарий знакомый. Компания решила навести порядок, посадила внутри человека, тот полтора месяца собирал требования со всех отделов и родил документ на тридцать страниц. Иногда на семьдесят. Приносят его с гордостью: вот, мы всё описали, оцените.

Я отношусь к этому с уважением — человек проделал большую работу и вообще подумал головой, что ему нужно. Но говорю честно сразу: примерно половина написанного изменится, а часть просто не понадобится.

Люди приходят с ТЗ, оно не объективно, его всегда надо пересобирать. Это не претензия к клиенту. Это свойство жанра. Я и про свои собственные проекты могу сказать то же самое: то, что мы напишем на старте, через месяц работы выглядит наивно.

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

А есть реальность системы. Что-то в ней делается легко и штатно. Что-то делается, но стоит как половина проекта. А что-то делать вообще не стоит, потому что через месяц эксплуатации вы это выключите — я такое видел много раз.

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

Раз ТЗ всё равно пересобирается, вопрос только один: когда вы за это заплатите. Вариантов два, и оба стоят денег.

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

Второй — после. Вы платите переделками. Всё сделали строго по документу, запустили — и выясняется, что вот здесь неудобно, а вот этого не хватает. Каждая правка обсуждается отдельно, потому что формально подрядчик сделал всё по ТЗ.

Мы этот путь прошли. Большие сметы, длинные сроки, толстые документы. Грабли собрали, негатива хапнули. Нафиг нам это не надо. И дело даже не в деньгах, а в том, что обе стороны выходят из такого проекта уставшими друг от друга.

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

Через несколько дней у клиента на портале работающий фрагмент. Не презентация, не схема в редакторе — живая система. Можно кликать, завести сделку, прогнать её по этапам, посмотреть, как оно себя ведёт.

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

Дальше правим и делаем следующий кусок. То есть требования уточняются на работающей системе, а не в файле, который после подписания никто не перечитывает.

У меня есть правило, которому я не изменяю: сначала делаем то, что даст эффект на первой же неделе. Потом усложняем.

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

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

Тут важно не свалиться в другую крайность. Работа демо-версиями — это не «делаем как получится и ничего не фиксируем». Фиксируем, просто не заранее и не на тридцати страницах.

У нас есть дорожная карта: список шагов, что делаем сейчас, что следующим, что отложили осознанно. Она живая, после каждой демонстрации может измениться. И есть описание того, что уже сделано, — по факту, а не по замыслу. Это описание, кстати, полезнее любого исходного ТЗ, потому что оно про реально работающую систему.

Разница принципиальная. Большое ТЗ — это попытка угадать будущее и заморозить его в файле. Дорожная карта — это договорённость о ближайших шагах, которую не жалко поменять, когда стало понятнее.

Не хочу, чтобы это звучало как «документы не нужны». Мы умеем писать полноценное техзадание, и иногда оно действительно обязательно.

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

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

Главное изменение не в методике, а в риске. При большой фикс-смете подрядчик всегда закладывает в цену неопределённость, потому что объём непонятен и меняться он будет обязательно. Получается тот самый икс полтора, и платит за это клиент.

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

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

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