Журнал · Процесс

Как написать
ТЗ для разработчика

~10 минут чтения Дмитрий Спиридонов

ТЗ (техническое задание) — главный документ проекта. От его качества зависит, получите ли вы то, что хотели, и заплатите ли столько, сколько обещано. Плохое ТЗ — это +30% к смете в виде «непредвиденного» и срыв сроков. Разберём, как написать ТЗ, чтобы оно работало на вас, а не против.

Что должно быть в ТЗ

  1. Цель проекта — что должен делать продукт, зачем нужен
  2. Целевая аудитория — кто пользователи, какие у них боли
  3. Функциональные требования — что должен уметь продукт
  4. Нефункциональные требования — скорость, безопасность, нагрузка
  5. Структура и навигация — карта сайта или приложения
  6. Дизайн-требования — стиль, референсы, ограничения
  7. Интеграции — с какими внешними системами
  8. Контент — кто и как готовит тексты, изображения
  9. SEO и аналитика — требования к индексации, метрикам
  10. Сроки и бюджет — реалистичные рамки

5 типичных ошибок

1. Слишком общо

«Нужен интернет-магазин, как у Wildberries». Это не ТЗ. Какие категории? Какая оплата? Какая доставка? Каждое слово должно расшифровываться. Расплывчатые формулировки — гарантия раздувания сметы.

2. Слишком детально

Описывать тип кнопки до пикселя в ТЗ — лишнее. ТЗ должно описывать ЧТО, не КАК. Подрядчик выбирает технологии. Иначе ограничиваете его пространство и теряете в качестве.

3. Без приоритетов

Все требования помечены «обязательно». На деле есть critical, important, nice-to-have. Подрядчик не угадает, что урезать первым, если время кончается.

4. Нет критериев приёмки

«Сайт должен быть удобным» — неприёмлемая формулировка. Удобный — это сколько секунд до целевого действия? Какая конверсия? Чёткие метрики защищают обе стороны.

5. Без user stories

Не «нужна форма заявки», а «как клиент, я хочу оставить заявку за 30 секунд, чтобы получить расчёт стоимости». User story показывает контекст и помогает дизайнеру/разработчику принять правильное решение.

Помогу составить ТЗ

Если ТЗ ещё нет — заполните бриф своими словами, я переведу в нормальный документ за 2-4 часа. Это часть моей работы, не за отдельные деньги.

Заполнить бриф →

Шаблон ТЗ

Для типового проекта на 100-300 тыс. ₽ хватит документа на 5-8 страниц. Структура:

Раздел 1. О компании и продукте

  • Что за бизнес и какие услуги
  • Текущая ситуация: что есть сейчас, что мешает
  • Цель проекта одним предложением

Раздел 2. Целевая аудитория

  • Сегменты: 2-3 типа пользователей
  • Их боли и потребности
  • 3-5 user stories для каждого сегмента

Раздел 3. Функциональные требования

  • Список фичей в формате «как пользователь, я хочу X»
  • Каждая фича с приоритетом: critical / important / nice-to-have
  • Acceptance criteria для каждой

Раздел 4. Технические требования

  • Стек предпочтений (если есть)
  • Производительность: TTFB, LCP, скорость загрузки
  • Нагрузка: ожидаемые пользователи в день / месяц
  • Безопасность: HTTPS, 2FA, аудит

Раздел 5. Дизайн

  • Стилевые рамки: цвета, шрифты, тон
  • 5-10 референсов с комментариями
  • Что нравится / не нравится в текущем дизайне

Раздел 6. Интеграции

  • Список внешних систем: 1С, CRM, платёжки, доставка
  • Документация API (если есть)
  • Контакты технических представителей

Раздел 7. Сроки и бюджет

  • Желаемая дата запуска
  • Диапазон бюджета
  • Гибкость: что важнее — срок или цена

Можно обсудить голосом

Если проще рассказать словами — пишите в Telegram. За 20 минут я задам нужные вопросы и составлю ТЗ за вас.

Открыть @deemkend →

Что НЕ нужно в ТЗ

  • Технические детали реализации. Не «использовать React» — разработчик выберет.
  • Дизайн пикселей. «Кнопка 240×56» — это дело дизайнера.
  • Сроки разделения работ. «Дизайн 3 недели, разработка 4» — пусть подрядчик предложит.
  • Список технологий. Если знаете, пишите как «предпочтения», не как требование.

Хотите помощь с ТЗ?

Заполните мой бриф — это упрощённый формат ТЗ. Я переведу его в полноценный документ за 2-4 часа, как часть проекта.

Заполнить бриф →
← Вернуться в журнал