📜Точное следование ТЗ не спасает проект. Или как не прятаться за бумажкой

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

И вот сидишь ты, смотришь на результат, и хочется выть. Потому что формально разработчик прав, он сделал всё по инструкции, а по факту — проект не работает. Клиент недоволен, команда в стрессе, а виноватых нет.

⚖️ Если ТЗ стал законом то это дорога в ад, но с указателями

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

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

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

🧠 Здравый смысл — тот самый, который забыли добавить

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

Я всегда говорю своим клиентам: «ТЗ — это всего лишь справочная информация, чтобы вникнуть в проект». Оно не объясняет, что, если пользователь ввёл неверный номер телефона, ему нужно показать понятную ошибку, а не просто «Ошибка 403».

Здравый смысл — это когда разработчик видит, что кнопка не ведёт к оплате, и говорит: «Слушайте, тут явно что-то не так, давайте добавим логику».

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

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

🤝 Командная ответственность важнее буквы закона

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

Один мой знакомый продавал ПО для логистики. В ТЗ было прописано, что приложение должно выгружать отчеты из Excel. Разработчики сделали. Отчёты начали выгружаться, но в них не было сортировки по дате, не было суммирования, не было понятных названий колонок. На вопрос «почему?» ответили: «А в ТЗ этого не было». Итог, как все понимают, печальный. Клиент ушёл к конкуренту. Потому что ему нужен был не Excel, а работающий инструмент, а команда просто отбила ТЗ и забыла про бизнес-цель.

Если бы они включили голову и сказали: «Ребята, давайте мы сразу сделаем нормальное решение, чтобы вы не переделывали» — проект бы выиграл, а так спрятались за бумажкой и проиграли все.

🛠️ Делаем по ТЗ, но без формализма

Есть несколько простых правил, которые помогают не скатиться в формализм:

1. Правило первое — договориться заранее. В начале проекта обсудить: «Мы делаем не буквально, а по смыслу. Если видим, что что-то нелогично или неудобно — мы говорим, а не ждём обновления ТЗ».
2. Правило второе — задавать вопросы. Если в ТЗ что-то неясно — не додумывать, а уточнять. Но не перекладывайте ответственность, а предлагайте решения: «Смотрите, здесь можно сделать так или так. Как лучше?»
3. Правило третье — думать о пользователе. Каждый раз, когда делаешь шаг, спрашивать себя: «А удобно ли это будет тому, кто будет использовать систему?». Если нет — пересобирать всё заново.
4. Правило четвёртое — брать ответственность. Если ты видишь, что проект идёт не туда, ты не прячешься за «а я же делал по ТЗ», а бьёшь тревогу. Потому что, если провалится проект — это общий провал.

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

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

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