Почему ТЗ — это не документ, а процесс
О синхронизации ожиданий до того, как они разойдутся в коде
Типичная ситуация
— Мы же всё обсудили, почему сделали не так?
— Мы сделали ровно то, что было в ТЗ.
— Но это не то, что мы имели в виду!
ТЗ часто воспринимают как формальность. Документ, который нужен «для юристов» или «чтобы было». Написали, подписали, забыли. Потом удивляемся, почему результат не соответствует ожиданиям.
Проблема не в том, что ТЗ плохое. Проблема в том, что ТЗ — это не документ. Это процесс синхронизации между двумя картинами мира.
Две картины мира
У заказчика в голове — образ результата. Размытый, эмоциональный, связанный с бизнес-целями. «Хочу, чтобы было удобно. Чтобы клиенты не путались. Чтобы мы видели всё в одном месте».
У исполнителя в голове — технические решения. Конкретные, детальные, связанные с реализацией. «База данных, API, интерфейс, авторизация, хостинг».
ТЗ — это попытка перевести с языка бизнеса на язык технологий. И, как любой перевод, он требует диалога, уточнений, итераций.
Почему документ не работает
Классическое ТЗ — это попытка заморозить понимание в одной точке времени. Но понимание меняется:
Документ, написанный 3 месяца назад, может быть устаревшим. Но если он «подписан» — обе стороны чувствуют себя связанными.
ТЗ как живой процесс
Альтернативный подход: ТЗ — это не документ, а серия разговоров с фиксацией.
Фиксация нужна — но не как «контракт, который нельзя менять», а как «текущее понимание, которое мы оба разделяем».
Практические техники
1. Вопрос «А что, если нет?»
Для каждой функции спрашиваем: «Что произойдёт, если этого не будет?». Помогает отделить must-have от nice-to-have.
2. Сценарии вместо списков
Вместо «система должна позволять фильтровать заявки» — «Маша-оператор открывает панель, видит 200 заявок, ей нужно найти все от клиента X за последнюю неделю».
Правило: Если не можете описать сценарий с конкретным человеком — вы ещё не понимаете, что делаете.
3. Прототипы до кода
Figma, Balsamiq, даже бумажные скетчи. 10 минут на прототип могут сэкономить 10 часов разработки.
4. Регулярные синхронизации
Не «сдали через 3 месяца», а «показываем каждую неделю». Маленькие корректировки дешевле большого переделывания.
Цена недопонимания
Час на уточнение требований стоит дешевле, чем день на исправление в коде. День на исправление в коде стоит дешевле, чем неделя на откат в продакшене.
Итого
ТЗ — это не документ, который «сдаёшь и забываешь». Это инструмент синхронизации, который работает только в процессе.
Хорошее ТЗ — не то, которое на 50 страниц. Хорошее ТЗ — то, после которого обе стороны видят одну и ту же картину.
Проверить просто: попросите заказчика и исполнителя независимо описать результат. Если описания совпадают — ТЗ работает. Если нет — нужен ещё один разговор.
Нужна помощь с ТЗ?
Помогаю формулировать требования так, чтобы результат соответствовал ожиданиям. Не документы ради документов — а понимание ради результата.