Не то. Всегда.
За 16 лет в IT я принял тысячи таких ТЗ с той стороны стола. И сам их писал, когда нанимал подрядчиков. Скажу прямо: 80% правок рождаются не из-за криворукого исполнителя. А из-за того, что заказчик не сформулировал, чего хочет.
Плохое ТЗ — это не про код. Это про коммуникацию. Разберём, как писать так, чтобы получить результат.
🎯 Сначала — задача, а не решение
Главная ошибка: люди пишут «как сделать», не объяснив «зачем».
«Сделай кнопку зелёной и по центру» — это решение. А задача — «нужно, чтобы люди чаще нажимали на заказ». Разница огромная.
Когда исполнитель понимает цель, он предложит вариант лучше твоего. Когда получает только приказ — сделает буквально и разведёт руками.
Пиши так:
- Какую проблему решаем.
- Кто пользователь и что он должен сделать.
- Как поймём, что получилось (метрика, действие, результат).
Цель наверху. Детали — ниже.
🧩 Дроби на конкретику до боли
«Удобный личный кабинет» — это ни о чём. У каждого «удобный» своё.
Хорошее ТЗ не терпит абстракций. Каждое расплывчатое слово — это будущая правка.
Был у меня проект: клиент написал «каталог должен быстро грузиться». Мы сделали за 2 секунды. Он ждал 0,5. Скандал на ровном месте — потому что «быстро» не измерили.
Заменяй оценочное на измеримое:
- «современный дизайн» → примеры трёх сайтов, которые нравятся.
- «много товаров» → до 5000 позиций.
- «адаптив» → перечисли устройства и разрешения.
Если что-то можно понять двумя способами — его поймут неправильно.
🖼️ Показывай, а не только описывай
Текст врёт. Картинка — нет.
Один скриншот референса экономит десять абзацев описания и три круга правок. Собери примеры: что нравится, что бесит, что близко по духу.
Прикладывай:
- Референсы (и объясняй, ЧТО именно нравится в них — цвет, структура, тон).
- Антипримеры — «так не делать».
- Схему экранов или простой прототип, хоть от руки.
Когда обе стороны смотрят на одну картинку — спорить не о чем.
⏳ Зафиксируй границы и приоритеты
Здесь ломаются даже опытные. ТЗ без границ превращается в болото, куда сползает всё подряд.
Чётко раздели:
- Что входит в работу (must have).
- Что желательно, но не критично.
- Что НЕ делаем в этом этапе.
Последний пункт спасает бюджеты. Без него любая «маленькая доработка» становится бесплатной обязанностью исполнителя в глазах заказчика.
И да — пропиши процесс правок. Сколько кругов входит в стоимость, что считается новой задачей. Это не жадность. Это защита обеих сторон.
🚫 Чего в ТЗ быть не должно
Не пиши то, в чём не разбираешься, тоном приказа. «Используй React, а не Vue» — если ты не знаешь разницы, ты просто связываешь руки специалисту.
Бизнес, который лезет в технические решения, не понимая рынок IT, становится лёгкой добычей. Либо переплачивает, либо получает мусор под видом «сделали как просили».
Твоя зона — задача, результат, ограничения, дедлайн, бюджет. Его зона — как это технически реализовать.
Не путай роли. Хорошее ТЗ описывает пункт назначения, а не диктует маршрут по каждому повороту.
📌 Вывод: ТЗ — это не документ, а разговор
Лучшее ТЗ рождается в диалоге. Ты пишешь черновик — исполнитель задаёт вопросы — вы уточняете вместе. Если специалист молча взял ТЗ и ушёл — насторожись. Значит, либо ему всё равно, либо он не понял.
Правки не появляются в конце. Они закладываются в начале — в момент, когда ты поленился объяснить.
Я разбираю такие ситуации подробнее в Телеграме — там можно скинуть своё ТЗ в комментарии и получить от меня разбор лично, чего на Дзене я физически не успеваю: мой Телеграм. Если удобнее ВКонтакте — залетай в сообщество, там та же кухня без иллюзий: сообщество ВК
А если проект уже завис в бесконечных правках или нужен сайт, аудит и трезвый взгляд со стороны — посмотри мои работы и напиши: портфолио на сайте
Сохрани статью и открой перед тем, как отправишь следующее ТЗ. А в комментариях напиши свою фразу-абстракцию, из-за которой прилетал вагон правок — разберём вместе.