Статьи о разработке ТЗ

ТЗ решает несколько задач:

• Фиксация требований — что именно нужно сделать;
• Оценка бюджета — можно точно рассчитать стоимость;
• Сравнение подрядчиков — все оценивают одно и то же;
• Контроль результата — есть критерии приёмки;
• Защита от споров — документ фиксирует договорённости.

Разработка ТЗ включает:

• Интервью с заказчиком — выявление требований;
• Анализ бизнес-процессов — как работает система сейчас;
• Проектирование — архитектура, модули, БД;
• Описание функционала — что система должна делать;
• Описание интеграций — с чем связывать;
• Критерии приёмки — как проверить результат;
• Сроки и этапы — план работ.

Стоимость зависит от сложности проекта:

• Простое ТЗ (лендинг, небольшая доработка) — от 15 000 ₽;
• Среднее ТЗ (корпоративный сайт, веб-приложение) — от 40 000 ₽;
• Сложное ТЗ (CRM, интеграции, мобильное приложение) — от 80 000 ₽;
• ТЗ по ГОСТ 34.602-2020 — от 100 000 ₽.

Точная стоимость — после обсуждения проекта.

Сроки зависят от сложности:

• Простое ТЗ — 2-3 дня;
• Среднее ТЗ — 5-7 дней;
• Сложное ТЗ — 2-3 недели;
• ТЗ по ГОСТ — 3-4 недели.

ГОСТ 34.602-2020 — государственный стандарт, который определяет структуру и содержание технического задания на создание автоматизированных систем. Используется для проектов в госсекторе и крупных корпорациях.

Структура ТЗ по ГОСТ включает:

• Общие сведения — наименование, заказчик, исполнитель;
• Назначение и цели — зачем создаётся система;
• Характеристика объекта — что автоматизируется;
• Требования к системе — функционал, надёжность, безопасность;
• Состав и содержание работ — этапы;
• Порядок контроля и приёмки — критерии.

Да. Для коммерческих проектов ГОСТ не обязателен. Можно использовать свободный формат, который включает все необходимые разделы, но без строгой структуры стандарта.

Свободный формат удобнее для Agile-проектов, где требования могут меняться в процессе. ГОСТ подходит для проектов с фиксированными требованиями и строгой отчётностью.

В разработке участвуют:

• Заказчик — владелец продукта, который знает бизнес-требования;
• Бизнес-аналитик — выявляет и формализует требования;
• Технический архитектор — проектирует систему;
• Разработчик — оценивает реализуемость;
• Тестировщик — формулирует критерии приёмки.

Критерии приёмки — это измеримые условия, при выполнении которых результат считается принятым. Например:

• Функциональные — «пользователь может оформить заказ за 3 шага»;
• Производительность — «страница загружается за 2 секунды»;
• Безопасность — «данные передаются по HTTPS»;
• Совместимость — «работает в Chrome, Firefox, Safari».

Без критериев приёмки невозможно объективно проверить результат.

Да. ТЗ — основа для тендера. Все подрядчики оценивают один и тот же объём работ, что позволяет сравнить предложения объективно.

Для тендера ТЗ должно быть:

• Полным — все требования описаны;
• Однозначным — нет двусмысленных формулировок;
• Измеримым — критерии приёмки проверяемы.

Требования могут меняться. Варианты:

• Дополнительное соглашение — изменения фиксируются отдельно;
• Гибкое ТЗ — для Agile-проектов требования описаны в виде User Stories;
• Резерв — в ТЗ закладывается запас на изменения.

Чек-лист проверки ТЗ:

• Полнота — все требования описаны;
• Однозначность — нет двусмысленных формулировок;
• Реализуемость — технически возможно;
• Измеримость — критерии приёмки проверяемы;
• Согласованность — нет противоречий между разделами.

Да, даже для небольшого проекта ТЗ полезно. Оно может быть кратким (2-3 страницы), но должно включать:

• Цель — зачем делается проект;
• Функционал — что должно быть;
• Критерии приёмки — как проверить результат.

Это защитит от недопонимания и споров.

ТЗ оформляется в виде документа:

• Титульный лист — название, заказчик, исполнитель, дата;
• Содержание — разделы;
• Основная часть — требования;
• Приложения — схемы, макеты, примеры.

Формат — Word, PDF или Confluence. Важно, чтобы документ был версионирован.

User Story — это описание требования с точки зрения пользователя. Формат: «Как [роль], я хочу [действие], чтобы [цель]».

Пример: «Как покупатель, я хочу добавить товар в корзину, чтобы оформить заказ».

User Stories используются в Agile-проектах вместо традиционного ТЗ.

Acceptance criteria (критерии приёмки) — условия, при которых User Story считается выполненной. Формулируются как чек-лист.

Пример для «добавить товар в корзину»:

• Кнопка «В корзину» есть на странице товара;
• При нажатии товар добавляется в корзину;
• Счётчик корзины увеличивается;
• Появляется уведомление об успехе.

Прототип и ТЗ дополняют друг друга:

• Прототип — визуальное представление, как будет выглядеть;
• ТЗ — описание, как будет работать.

Оптимально: сначала прототип для согласования UX, потом ТЗ для описания функционала.

ТЗ — это документ, на который можно ссылаться:

• Напомнить о договоре — ТЗ часть договора;
• Зафиксировать отклонения — что не соответствует;
• Потребовать исправлений — в рамках ТЗ;
• Обратиться в суд — если подрядчик отказывается.

Да. ТЗ — это документ, который можно передать другому подрядчику. Он описывает требования, а не то, как их реализовывать.

Это одно из главных преимуществ ТЗ: вы не привязаны к одному исполнителю.

Стоимость оценивается по:

• Объёму работ — сколько модулей, страниц, интеграций;
• Сложности — какие технологии, есть ли нестандартные задачи;
• Срокам — срочность влияет на цену;
• Рискам — закладывается резерв.

В разработку ТЗ входит:

• Интервью — 2-3 встречи с заказчиком;
• Анализ — изучение бизнес-процессов;
• Проектирование — архитектура, модули;
• Документ — ТЗ в согласованном формате;
• Согласование — правки до утверждения;
• Передача — документ в Word, PDF.

Да, бизнес-аналитик — ключевой участник. Он:

• Выявляет требования — задаёт правильные вопросы;
• Формализует — превращает «хотелки» в требования;
• Документирует — пишет ТЗ;
• Согласовывает — работает с заказчиком и командой.

Чек-лист полноты ТЗ:

• Цели — зачем создаётся продукт;
• Пользователи — кто будет использовать;
• Функционал — что система должна делать;
• Интерфейсы — как выглядит;
• Интеграции — с чем связывать;
• Данные — что хранить;
• Безопасность — требования к защите;
• Производительность — нагрузка, скорость;
• Критерии приёмки — как проверять.

Scope creep — расширение объёма работ без соответствующего увеличения бюджета и сроков. ТЗ помогает избежать:

• Фиксирует объём — что входит, что нет;
• Процедура изменений — как добавлять новые требования;
• Критерии приёмки — что считается выполненным.

Да, ТЗ — основа для оценки. По нему можно:

• Рассчитать бюджет — сколько будет стоить;
• Оценить сроки — сколько времени займёт;
• Сравнить подрядчиков — все оценивают одно и то же.

Процесс:

1. Оставьте заявку на бесплатную консультацию;
2. Обсудим проект, задачи, цели;
3. Предложим формат ТЗ и сроки;
4. Подпишем договор и начнём работу.

Разрабатываем ТЗ для проектов из разных отраслей: e-commerce, SaaS, медицина, финансы, логистика, образование, производство. Адаптируем подход под специфику вашего бизнеса.