“У нас есть ТЗ. Менеджер написал”. Слышу это часто. И каждый раз уточняю: “А разработчики с этим ТЗ работают? Без переспросов?”

Ответ обычно один: “Ну… не совсем”.

Давайте разберёмся, чем отличается “пожелание” от “инструкции”. Это как отличить рецепт “приготовьте что-нибудь вкусное” от инструкции “взять 200 г муки, 2 яйца, замесить тесто, выпекать 30 минут при 180 градусах”.

Менеджер - хороший человек. Он умеет общаться с клиентами, знает бизнес, понимает, что нужно заказчику. Но он не знает, как это описать для разработчика. Поэтому его ТЗ выглядит так: “Сделать личный кабинет, чтобы клиенты могли видеть свои заказы и скачивать счета. Ну, как у всех”.

Это не ТЗ. Это пожелание.

Разработчик читает и думает: что значит “видеть заказы”? Список? Детали? Статусы? Какие счета? В каком формате? “Как у всех” - это у кого? Он не знает. И начинает додумывать.

Менеджер мыслит бизнес-категориями, а не техническими. Он не знает про API, базы данных, оптимизацию запросов, ошибки на стыке систем. И это нормально. Это не его работа. Его работа - понимать бизнес. Моя - превращать это понимание в инструкцию для разработчиков.

Если вы даёте мне ТЗ от менеджера - я не выкидываю его в мусорку. Я беру как основу. Задаю вопросы, уточняю, дополняю. Превращаю “сделать личный кабинет” в описание экранов, список полей, схему БД, интеграции, сценарии ошибок, декомпозицию задач. В итоге разработчик работает без переспросов. Хорошее ТЗ отвечает на все вопросы до того, как разработчик начал писать код. Что именно должно быть на экране? Какие данные откуда берутся? Куда передаются? Что при ошибке? В хорошем ТЗ разработчик не переспрашивает.

Потому что всё уже написано.

ТЗ от менеджера: нет структуры, вместо сценариев - “пользователь заходит и видит”, вместо данных - “показываем заказы”, вместо интеграций - “связать с 1С”. Разработчик переспрашивает каждые 10 минут. Переделки - 2–3 раза. Хорошее ТЗ: чёткая структура, сценарии (“если авторизован → видит список”), данные (“поля: номер, дата, сумма из таблицы orders”), интеграции (“отправляем JSON на адрес…”), обработка ошибок. Разработчик берёт и делает. Переделки - 0–1 раз.

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

Что вы думаете: “У нас есть ТЗ”. Что на самом деле: пожелание. “Менеджер написал, разработчик разберётся” - не разберётся, будет додумывать. “Мы сэкономим на ТЗ” - заплатите за переделки.

Сайт: https://tzlab.pro