"Ваше ТЗ - мусор, и вот почему"

Жёсткое техническое задание выглядит как "надёжная опора".Чем подробнее всё описали, тем меньше рисков. По крайней мере, так принято считать.

На практике всё часто работает наоборот.

Проект формально идёт по ТЗ, команда честно делает «всё как договорились», а на выходе получается продукт, который либо УСТАРЕЛ ещё до релиза, либо ЛИБО НЕ РЕШАЕТ ЗАДАЧУ БИЗНЕСА. И в этот момент всем становится немного не по себе.

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

Меня зовут Кирилл, учусь в НИУ ВШЭ, работаю продуктовым-аналитиком в цифровом агентстве и регулярно вижу, как строгое следование ТЗ становится причиной провалов, хотя изначально оно должно было от них защищать...

Жёсткое ТЗ почти никогда не появляется из вредности или желания усложнить процесс.Чаще всего за ним стоит понятное желание снизить риски.

ТЗ даёт ощущение контроля: объём работ зафиксирован, сроки понятны, цена согласована. Кажется, что если всё описано заранее, то проект становится предсказуемым.

В этом месте обычно никто не ошибается.Ошибки начинаются чуть позже - когда это ощущение контроля принимают за реальность.

Любой цифровой продукт делается не за неделю. Пока идёт разработка, меняются рынок, приоритеты бизнеса и понимание пользователя. В итоге команда может идеально реализовать требования, которые уже не совсем актуальны.

Формально всё сделано правильно.Фактически - продукт опоздал.

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

В таких проектах часто «всё сделано по ТЗ», но при этом никто не может честно сказать, зачем именно так.

Изменения всё равно происходят - в любом проекте.Разница лишь в том, готовы ли вы к ним.

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

ТЗ отвечает на вопрос «что нужно сделать».Продуктовая работа 0 на вопрос «зачем это делается и какую ценность должно создать».

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

Проблема не в документе. Проблема в том, что он подменяет собой работу с ценностью.

В одном из проектов для ООО "Лисички" ТЗ было проработано идеально: десятки страниц, согласованные сценарии для прода, чёткие формулировки и KPI. Команда аккуратно шла по документу и формально делала всё правильно.

Проблема выяснилась позже: пользователи вели себя иначе, ключевые сценарии не работали, а часть функций оказалась ненужной. Изменить решение было уже сложно - проект был «заперт» в ТЗ.

В итоге продукт соответствовал документу, но перестал соответствовать задаче бизнеса. Банальный пример: идеальное ТЗ не спасает, если его нельзя пересмотреть вовремя.

На практике лучше всего работает не одно «идеальное» ТЗ, а простая система:

Гибкость здесь - не хаос, а управляемая неопределённость.

Со временем я пришёл к простой модели.

Жёстко фиксируются бизнес-цель, метрики успеха и ограничения по срокам и бюджету. Гибкими остаются способы реализации, детали пользовательских сценариев и решения, которые могут измениться после тестов.

И обязательно есть точки пересмотра, где можно честно сказать:«Это не работает - давайте менять», а не искать виноватых.

Жёсткое ТЗ само по себе не зло. Зло - ожидание, что оно избавит от необходимости думать, тестировать и адаптироваться.

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