Что такое хорошее ТЗ и чем оно отличается от ТЗ от менеджера
Слышу это часто. И каждый раз уточняю: «А разработчики с этим ТЗ работают? Без переспросов?»
Ответ обычно один: «Ну... не совсем».
1. ТЗ от менеджера — это не ТЗ
Менеджер — хороший человек. Он умеет общаться с клиентами, знает бизнес, понимает, что нужно заказчику.
Но он не знает, как это описать для разработчика.
Поэтому его ТЗ выглядит так:
«Сделать личный кабинет, чтобы клиенты могли видеть свои заказы и скачивать счета. Ну, как у всех».
Это не ТЗ. Это пожелание.
Разработчик читает это и думает:
- Что значит «видеть заказы»? Список? Детали? Статусы?
- Какие счета? В каком формате?
- «Как у всех» — это у кого?
Он не знает. И начинает додумывать.
2. Как это выглядит в реальной жизни
Без имён и лиц — правило конфиденциальности неизменно.
Работал я в роли тимлида над одним действительно претенциозным проектом. Но руководство — это, к слову, частая боль — говоря «делай», вмешивалось в процесс.
Взяло проджект-менеджера, не понимающего в разработке от слова «совсем». Аргументация при приеме на работу феерична: "У меня сын изучает программирование". Понятней и лучше руководству не становилось ни на йоту. Но при этом менеджер регулярно вызывался на ковёр к руководству, и они согласовывали новшества, которые это самое руководство хотело бы видеть.
Сегодня, и это главное, потому что завтра передумывали или меняли придуманное накануне.
В итоге «ТЗ», которое получалось, было переполнено прилагательными и деепричастными оборотами. «Документ» писался в Word, и предполагалось, что нужно по нему сделать что-то, что придумало руководство.
Жаль, что телепатией я не обладаю.
3. Хорошее ТЗ — это инструкция для разработчика
Хорошее ТЗ отвечает на все вопросы до того, как разработчик начал писать код.
- Что именно должно быть на экране?
- Какие данные откуда берутся?
- Куда они передаются?
- Что происходит, если пользователь нажал не туда?
- Как система должна вести себя при ошибке?
В хорошем ТЗ разработчик не переспрашивает. Потому что всё уже написано.
4. Чем отличается ТЗ от менеджера от хорошего ТЗ
| Что | ТЗ от менеджера | Хорошее ТЗ |
|---|---|---|
| Структура | Нет структуры — просто текст | Чёткая структура: цели, требования, сценарии, ограничения |
| Сценарии | «Пользователь заходит и видит» | «Если пользователь авторизован → видит список заказов. Если не авторизован → видит форму входа» |
| Данные | «Показываем заказы» | «Показываем поля: номер, дата, сумма, статус. Данные из таблицы orders по user_id» |
| Интеграции | «Связать с 1С» | «При создании заказа отправляем данные в 1С по API. Формат JSON. Адрес: …» |
| Ошибки | «Чтобы работало» | «Если 1С не отвечает — показываем сообщение "Сервис временно недоступен" и записываем ошибку в лог» |
| Переспросы | Разработчик переспрашивает каждые 10 минут | Разработчик берёт и делает |
| Переделки | 2–3 раза | 0–1 раз |
5. Почему менеджер не может написать хорошее ТЗ
Потому что менеджер мыслит бизнес-категориями, а не техническими.
Он не знает:
- Что такое API.
- Как работает база данных.
- Что значит «оптимизировать запрос».
- Какие ошибки могут возникнуть на стыке систем.
И это нормально. Это не его работа.
Его работа — понимать бизнес. Моя работа — превращать это понимание в инструкцию для разработчиков.
6. Что я делаю с ТЗ от менеджера
Если вы даёте мне ТЗ от менеджера — я не выкидываю его в мусорку.
Я беру его как основу. Я читаю, задаю вопросы, уточняю, дополняю.
Я превращаю «сделать личный кабинет» в:
- Описание всех экранов.
- Список полей и их типов.
- Схему базы данных.
- Описание интеграций.
- Сценарии ошибок и исключений.
- Декомпозицию задач для разработчиков.
В итоге вы получаете ТЗ, по которому разработчик работает без переспросов.
7. Хорошее ТЗ — это «контракт». А контракт не подразумевает изменений на бегу
ТЗ — это не просто документ. Это контракт между бизнесом и разработкой.
Мы утверждаем ТЗ, и разработчики действуют по задачам, сформированным исходя из него.
Любое вмешательство — это:
- Срыв сроков.
- Изменение логики.
- Не задокументированные процессы в работе создаваемого ресурса.
- Изменение структуры в коде.
Пример
Представьте, вы строите загородный дом.
Вы утвердили проект, и рабочие начали копать котлован. И тут вы придумали, что нужна ещё дополнительная веранда и подвал в 2 раза больше, чтобы «Хаммер» поместился и кессон под ним был.
Что скажут рабочие? Мы — культурные люди, и не станем приводить тут вероятные цитаты. Но даже если они согласятся, срок сдачи сдвинется. Безусловно. А дом будет отвечать просчитанным нормам безопасности? Вот это вряд ли.
В разработке ровно та же ситуация. Хороший CTO или толковый проджект-менеджер обязательно скажут об этом руководителю.
Но выход есть. Бизнес меняется — сайт должен отвечать требованиям.
Все «хотелки» документируются и включаются в разработку только после изменений в ТЗ и интеграции задач для разработчиков в трекер.
Бизнес должен понимать: это — 100% сдвиг сроков.
8. Как это работает правильно
| Действие | Результат |
|---|---|
| Утвердили ТЗ | Разработка идёт по плану |
| Появилась новая хотелка | Документируем, оцениваем, включаем в новый этап |
| Изменяем ТЗ | Сроки сдвигаются. Это нормально. |
| Не меняем ТЗ | Сроки не сдвигаются. Заказчик получает то, что заказал. |
9. Как отличить хорошее ТЗ от плохого (чек-лист)
| Признак | Плохое ТЗ | Хорошее ТЗ |
|---|---|---|
| Можно передать разработчику и уйти? | Нет | Да |
| Разработчик переспрашивает? | Да, постоянно | Нет |
| Описаны все сценарии? | Нет | Да |
| Описаны ошибки? | Нет | Да |
| Есть структура БД? | Нет | Да |
| Есть описание интеграций? | Нет | Да |
| Задачи разбиты? | Нет | Да |
| Переделки после сдачи? | 2–3 раза | 0–1 раз |
| Изменения в процессе | Хаос | Чёткий процесс через изменение ТЗ |
10. Итог
| Что вы думаете | Что на самом деле |
|---|---|
| «У нас есть ТЗ» | У вас есть пожелание, а не ТЗ |
| «Менеджер написал, разработчик разберётся» | Разработчик не разберётся. Он будет додумывать. |
| «ТЗ — это просто текст» | ТЗ — это инструкция для разработчика |
| «Мы сэкономим на ТЗ» | Вы заплатите за переделки |
| «Мы можем менять ТЗ в процессе» | Можете. Но сроки сдвинутся. Это ваше решение. |
Нужно хорошее ТЗ?
Если у вас есть ТЗ от менеджера — я могу его доработать.
Если у вас нет ТЗ — я могу написать его с нуля.
Если вы не уверены, что у вас хорошее ТЗ — я могу проверить.