Каждый второй разговор начинается одинаково. «У нас есть ТЗ, посчитайте». Мы читаем и почти всегда находим одно и то же: подробно описано, из чего состоит продукт, и ни строчки о том, почему кто-то станет за него платить.
ТЗ отвечает не на тот вопрос
Документ фиксирует решение, принятое до него. Он полезен, когда решение уже проверено: тогда ТЗ экономит время на согласованиях. Но если решение ещё не проверено, ТЗ просто переносит непроверенную догадку в код — только дороже и на четыре месяца позже.
Подрядчику это выгодно: чем длиннее список, тем больше часов. Поэтому никто не спросит, нужен ли пункт 4.7.
Мы отвечаем за честность ответа, а не за то, чтобы ответ был «да»
Что даёт разговор
Восемь-двенадцать разговоров с людьми из вашего сегмента — включая тех, кто выбрал не вас, — дают три вещи, которых нет ни в одном ТЗ:
-
Задачу словами клиента. Не «нужна CRM», а «каждый день теряется предоплата, и я узнаю об этом от клиента»
-
Критерии выбора. По чему на самом деле сравнивают варианты — почти никогда это не цена
-
Список того, что строить не надо. Обычно это половина ТЗ
Иллюстрация к разделу
16:9
Прототип вместо документа
Кликабельный прототип за пять дней делает то, чего не делает сорокастраничный документ: его можно показать сотруднику и клиенту и увидеть, где человек застревает. После этого спор о содержании продукта заканчивается за один созвон.
Побочный эффект: цена перестаёт быть оценкой «от». Когда объём виден, его можно зафиксировать одной цифрой.
Когда ТЗ всё-таки нужно
Если продукт уже работает и вы добавляете модуль в понятную систему — документ уместен, он экономит время. Если вы регулируемая отрасль и без спецификации нельзя — тоже. Во всех остальных случаях ТЗ стоит писать после прототипа, а не вместо него.