К книге
Антихрупкость в ITРаздел I. Управление IT-продуктами. Глава 5. Когда надо прекратить писать техническое задание и начать делать продукт?. Критерии, на которые стоит ориентироваться
24%
Раздел I. Управление IT-продуктами. Глава 5. Когда надо прекратить писать техническое задание и начать делать продукт?. Критерии, на которые стоит ориентироваться
36

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

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

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

Рис. 22. Точность прогноза при высокой цене ошибки

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

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

Рис. 23. Нахождение баланса между оценкой и стоимостью оценки

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

Если проект находится в стадиях Старт или Рост[34] (подробности в видео Асхата Уразбаева «Как сохранить гибкость бизнеса»), то для него критично время эксперимента (рис. 24).

Рис. 24. Жизненный цикл продукта

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

Рис. 25. Окно возможностей для написания эффективного ТЗ

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

Предыдущая главаГлава 36 из 149Следующая глава