Когда пора прекратить писать Техническое задание?

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

При описании задач в ТЗ мы балансируем между двумя крайностями:

1. Переплатить временем и деньгами за чрезмерно подробное описание задач.
2. Описать задание недостаточно подробно, что приведёт к серьёзным рискам и ошибкам.

Как понять, что в ТЗ написано достаточно? Как понять, что критичные риски закрыты? Давайте обсудим по каким критериям ориентироваться в этом вопросе.

Затраты на прогноз к эффективности прогноза

По оси Х отложим вложенные деньги и время, которые мы тратим на написание ТЗ. По оси Y уровень предсказания будущего, т.е. точность прогноза:

Вначале график идет резко вверх, поэтому небольшое вложение времени и денег дает хороший результат в 70-80% точности. Оценка «на глаз» опытным IT-архитектором обычно дает довольно неплохой прогноз.

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

Получается, что всегда остается место риску и неопределенности, даже если мы будем писать ТЗ годами. Полная определенность будет достигнута только после окончания проекта, но не перед стартом.

Критерии, на которые стоит ориентироваться

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

1. Высока цена ошибки

Если от качества или успеха проекта зависит что-то важное, то приходится платить за снижение риска. Если ошибка приведет к банкротству компании или к потери жизни человека (оборудование для поддержания здоровья) или многих людей (оружие), то изучение и снижение рисков может стоить больше, чем сам проект.

2. Важно не превысить бюджет

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

3. Важна скорость проверки гипотез

Если проект находится в стадиях Introduction или Growth (подробности в видео Асхата Уразбаева Как сохранить гибкость бизнеса), то для него критично время эксперимента.

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

С другой стороны, если мы делаем проект не в одиночку, то нужно общаться и ставить друг другу задачи. В таких проектах для постановки задач достаточно набросков на бумаге, общих описаний и постоянного общения без всеобъемлющей документации.

Когда прекратить писать ТЗ?

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

Я предлагаю определить основные ограничения для проекта и его стадию, а потом выбрать оптимальный объем прогнозирования, т.е. оптимальный объем и детализацию технического задания.

Эта статья входит в цикл статей о техническом задании:

1. Когда надо прекратить писать Техническое задание и начать делать проект? Дана схема как балансировать между чрезмерно подробным, а значит дорогим, ТЗ и слишком абстрактным, что ведет к рискам и ошибкам.
2. 5 причин написать ТЗ, где перечислены причины, которые подталкивают подробно описывать весь план работ до начала проекта.
3. 12 проблем при работе по техническому заданию в IT-продукте. Описаны проблемы, которые превращают написание ТЗ в потери для бизнеса.
4. Откровенное общение с заказчиком, где решился спор о том, на сколько подробным должно быть ТЗ.
5. Техническое задание как база знаний о проекте, где описано, что написание ТЗ — это потери для бизнеса.
6. Как и какое техническое задание писать при работе по Agile, где описывается, как использовать подходящие инструменты планирования, прекратить фиксировать объем работ надолго в будущее и строить коммуникацию вокруг бизнес-целей.