Салют! Теперь я хочу поделиться своим мнением на счет ТЗ на разработку в наших реалиях.
Знаете что меня до сих пор удивляет? Каждый год кто-нибудь обязательно скажет что ТЗ умерло. Agile победил, итерации рулят, зачем писать документ который устареет через месяц.
А потом тот же человек приходит с горящими глазами: “мы сделали не то, заказчик недоволен, кто виноват непонятно”. И знаете что выясняется? Нигде ничего не зафиксировано.
🥺 Я через это прошла. И не один раз.
Почему ТЗ ругают — и в этом есть доля правды
Классическое ТЗ по ГОСТ — это больно. Двести страниц которые пишутся месяцами, согласовываются вечность и устаревают к моменту подписания. Я видела такие документы. Толстые, красивые, абсолютно мёртвые — потому что никто их не читал. Включая тех кто писал.
Но проблема не в самой идее фиксировать требования. Проблема в том что ТЗ превратили в ритуал вместо инструмента.
Где без фиксации становится по-настоящему больно
Расскажу один кейс. Проект без нормальной документации — команда договорилась устно, доверяли друг другу, торопились. Через три месяца разработки заказчик увидел результат и сказал “это не то что я имел в виду”. Разработчики показали переписку — там действительно было сказано именно так. Заказчик был уверен что имел в виду иначе.
Кто прав? Оба. И никто. Потому что нигде не было написано однозначно.
Переделки, потраченные деньги, испорченные отношения. Agile тут ни при чём — просто люди не зафиксировали договорённости.
Что писать в 2026 году — конкретно
Не ГОСТ. Но и не “разберёмся по ходу”.
Хорошая документация сегодня выглядит иначе:
- Короче. Ровно столько сколько нужно для однозначного понимания. Иногда десять страниц, иногда три. Объём не равно качество.
- Живее. Документ который обновляется по ходу проекта в Confluence или Notion лучше замороженного артефакта после подписания.
- Конкретнее. Не “система должна быть удобной” а “пользователь создаёт заявку за три шага”. Не “быстрая загрузка” а “страница открывается не дольше двух секунд”.
- С акцентом на главное. Бизнес-цель, ключевые сценарии, критерии готовности, ограничения. Остальное по необходимости.
Когда без серьёзного документа нельзя
Есть ситуации где я бы не взялась за проект без нормального ТЗ:
- Госпроекты и тендеры - там это требование закона
- Фиксированный бюджет и фиксированный скоуп - нет документа, нет защиты ни для кого
- Интеграции с внешними системами - без чёткой спецификации две команды сделают два разных API и удивятся почему не стыкуется
- Высокая цена ошибки - производство, медицина, финансы
Здесь ТЗ не бюрократия. Это единственный способ не потерять деньги и репутацию.
Когда можно обойтись малым
- Внутренний продукт с гибким скоупом и заказчиком который всегда на связи
- Небольшая доработка существующей системы
- Стартап где всё меняется быстро и документ устареет раньше чем его дочитают
Но даже здесь - ключевые договорённости фиксирую всегда. Хотя бы коротким письмом после встречи. Это занимает десять минут и сколько раз спасало - не пересчитать.
Мой честный ответ после двенадцати лет
ТЗ в классическом виде — да, уходит. Но потребность которую оно закрывает никуда не делась.
Людям нужна общая картина. Нужно понимать что строят, зачем, для кого и как поймут что сделали правильно. Нужна точка к которой можно вернуться когда начнутся споры — а они начнутся всегда.
Называйте как хотите — ТЗ, спецификация, product brief, просто нормальный документ. Суть одна: договорённости должны существовать не только в головах участников.
Потому что головы у всех разные. И каждая искренне уверена что всё помнит правильно.
Как у вас на проектах — пишете или обходитесь?
Если пишите, ставьте - 👌
Если обходитесь, ставьте - 🙈
Если нравится тема и пост, ставьте любую из реакций - 🔥♥️👍
Источник: @ba_and_sa
💙 BA|SA | 💬 BA|SA