Техническое задание — священная корова заказной разработки. Считается, что чем оно толще, тем надёжнее защищён заказчик. Практика упрямо показывает обратное: проекты с сорокастраничными ТЗ выходят за бюджет так же часто, как проекты вовсе без документов.

Дело не в том, что ТЗ написано плохо. Дело в том, чего от него ждут.

Зачем на самом деле пишут ТЗ

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

Документ, который пишут для суда, не помогает строить продукт.

Почему щит не работает

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

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

ТЗ никто не читает целиком. Сорок страниц читали два человека: автор и юрист. Разработчик читает выборочно, заказчик — по диагонали. Расхождения обнаруживаются не при чтении, а на приёмке, где они стоят дороже всего.

Полнота — иллюзия. Сколько бы страниц ни было, краевые случаи туда не попадают. Зато попадает балласт, из-за которого важное невозможно отличить от дежурного.

Что работает вместо

Работает документ противоположного устройства — короткие продуктовые требования:

  • проблема — что болит и почему;
  • роли и сценарии — кто и что делает в системе;
  • интеграции и данные — что снаружи;
  • границы версии — что входит и, главное, что не входит;
  • критерии приёмки — как поймём, что готово.

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

Когда толстое ТЗ всё-таки нужно

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

Как это устроено в coob

В coob формального ТЗ нет. AI-ассистент превращает описание идеи в структурированные продуктовые требования: роли, сценарии, границы версии. По ним фиксируется оценка, по ним же принимается результат. Документ остаётся рабочим до конца проекта, потому что обновляется с каждой версией продукта, а не подшивается к договору.