Техническое задание на разработку веб-приложения: как составить и что включить

Что такое ТЗ и почему без него разработка веб-приложения становится рискованнее

Техническое задание фиксирует, какой продукт должна разработать команда и по каким признакам стороны поймут, что результат соответствует ожиданиям. Это рабочий документ между бизнес-задачей и реализацией, а не формальность перед началом программирования.

В ТЗ описывают не только экраны и функции. В нём также могут быть пользовательские роли, бизнес-правила, интеграции, требования к безопасности, производительности, данным и приёмке результата.

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

Проблемы с требованиями действительно считаются одной из распространённых причин неудачных проектов. В исследовании PMI по управлению требованиями почти половина неуспешных проектов не достигала целей в том числе из-за недостатков работы с требованиями. Но эту статистику корректнее использовать как аргумент в пользу системной проработки требований, а не как универсальный процент провала IT-проектов.

ТЗ обычно создаётся совместно. Представители бизнеса формулируют цели и ограничения, аналитик структурирует требования, дизайнер прорабатывает пользовательские сценарии, а разработчики и QA проверяют реализуемость и тестируемость требований.

“

Мы не ждём от заказчика готового технического задания. На старте нам важнее понять бизнес-задачу, пользователей и ограничения. Уже после этого команда может превратить вводные в документ, по которому действительно можно проектировать, оценивать и разрабатывать продукт.

Ксения Положенцева (CEO, X Studio)

Из каких разделов состоит техническое задание на разработку веб-приложения

Структура ТЗ зависит от проекта, но документ должен отвечать как минимум на четыре вопроса: зачем создаётся продукт, что он должен делать, какие ограничения нужно учитывать и как будет приниматься результат.

Для веб-приложения обычно полезно включить следующие блоки:

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

Цели проекта

В начале стоит зафиксировать не только формулировку «разработать веб-приложение», но и задачу бизнеса.

Например:

«Создать B2B-портал, через который дилеры смогут самостоятельно оформлять заказы, видеть остатки и получать документы без обращения к менеджеру».

Такая формулировка помогает команде понимать, зачем существует каждая функция.

Пользователи и роли

Нужно перечислить типы пользователей и доступные им возможности.

Например:

• клиент;
• менеджер;
• администратор;
• партнёр.

Если у ролей разные права, это необходимо описать отдельно.

Функциональные и нефункциональные требования

Функциональные требования описывают, что должна делать система, а нефункциональные определяют характеристики её работы. Оба типа требований важны для разработки.

Функциональные требования

Например:

• пользователь может зарегистрироваться;
• пользователь может восстановить пароль;
• менеджер может создать заказ;
• администратор может заблокировать аккаунт;
• система отправляет уведомление после оплаты.

Полезно описывать не только основное действие, но и исключения.

Что происходит, если email уже зарегистрирован? Что видит пользователь при неуспешной оплате? Может ли отменённый заказ снова перейти в работу?

Нефункциональные требования

К ним относятся:

• производительность;
• безопасность;
• доступность;
• резервное копирование;
• требования к браузерам и устройствам;
• работа при определённой нагрузке;
• требования к журналированию и мониторингу.

Фраза «приложение должно быстро работать» практически бесполезна. Лучше определить измеримый показатель для критичных сценариев или хотя бы зафиксировать предполагаемую нагрузку и условия использования.

Архитектура и технологический стек в ТЗ

Техническое задание не обязательно должно заранее фиксировать конкретный язык, фреймворк и архитектуру, если бизнес не имеет объективных ограничений на технологии.

В исходном ТЗ часто встречается подход:

«Frontend - React, backend - Node.js, база данных - PostgreSQL».

Но если выбор технологий ещё не обоснован, такая детализация преждевременно ограничивает команду.

Вместо этого можно определить требования:

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

После этого архитектор или техническая команда выбирает подходящий стек.

Если же компания уже использует определённую инфраструктуру или поддерживать продукт будет внутренняя команда на конкретном стеке, технологические ограничения действительно стоит зафиксировать.

Также не стоит выбирать в ТЗ между SPA и PWA как между взаимоисключающими вариантами. SPA описывает устройство клиентского приложения, а PWA - набор возможностей веб-приложения. Один продукт может одновременно использовать оба подхода.

Интеграции и внешние системы

В ТЗ нужно перечислить внешние системы, с которыми приложение должно обмениваться данными, и желательно описать сам сценарий интеграции.

Например:

• amoCRM;
• Битрикс24;
• 1С;
• ЮKassa;
• системы аналитики;
• сервисы доставки;
• email и SMS-провайдеры;
• внешние API партнёров.

Недостаточно написать «интеграция с CRM». Нужно определить хотя бы направление обмена данными и ключевые сущности.

Например:

«После регистрации нового пользователя приложение создаёт контакт в CRM и передаёт имя, телефон, email и источник регистрации».

На этапе оценки команда также проверяет, существует ли нужный API и предоставляет ли сторонняя система необходимые возможности.

Как составить ТЗ на веб-приложение

Подготовку ТЗ лучше начинать с бизнес-задачи и пользовательских сценариев, а технические детали добавлять после обсуждения с командой разработки.

Рабочая последовательность выглядит так:

• Сформулировать цель продукта.
• Определить пользователей и роли.
• Описать ключевые пользовательские сценарии.
• Выделить функции первой версии.
• Зафиксировать интеграции и работу с данными.
• Добавить нефункциональные требования.
• Определить критерии приёмки.
• Провести техническое ревью требований.
• Согласовать границы проекта.

Для MVP не нужно подробно описывать функции, которые планируются только после проверки гипотезы.

Лучше отдельно зафиксировать:

Входит в первую версию: регистрация, каталог, оформление заказа.

Не входит: программа лояльности, рекомендации, мобильное приложение.

Такой подход помогает защитить первую версию от постоянного расширения объёма работ.

“

Хорошее ТЗ не должно быть максимально длинным. Оно должно снимать неоднозначность. Иногда чёткий пользовательский сценарий и измеримые критерии приёмки полезнее нескольких страниц общего описания функции.

Ксения Положенцева (CEO, X Studio)

Как описывать критерии приёмки

Критерии приёмки определяют конкретные условия, при которых функция считается реализованной правильно. Они связывают требования бизнеса, разработку и тестирование.

Вместо:

«Пользователь может зарегистрироваться».

Можно описать:

«Пользователь вводит имя, email и пароль. После успешной регистрации создаётся аккаунт, на email отправляется подтверждение, пользователь переходит на экран личного кабинета».

Также стоит определить ошибки:

• email уже используется;
• пароль не соответствует требованиям;
• сервис отправки писем временно недоступен.

Критерии приёмки не обязательно описывать как техническую реализацию. Их задача - определить наблюдаемый результат.

Частые ошибки при постановке задачи разработчикам

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

Чаще всего встречаются следующие ошибки:

• формулировки вроде «современный дизайн», «быстрая работа» или «удобный кабинет» без критериев;
• отсутствие приоритетов;
• попытка включить в MVP весь будущий продукт;
• отсутствие требований к ошибочным сценариям;
• забытые интеграции;
• отсутствие требований к безопасности и нагрузке;
• заранее выбранный стек без технического обоснования;
• отсутствие критериев приёмки;
• отсутствие списка того, что не входит в проект.

Ещё одна ошибка - писать ТЗ полностью без участия технической команды. Бизнес может хорошо описать необходимый результат, но не знать об ограничениях стороннего API, особенностях данных или технических рисках.

Поэтому перед финальной оценкой требования стоит проверить вместе с разработчиками и тестировщиками.

Шаблон технического задания на разработку веб-приложения

Для большинства проектов можно использовать следующую структуру как основу и расширять её по мере необходимости.

1. Общая информация

Название продукта, цель проекта, бизнес-контекст.

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

Кто пользуется системой и какие типы пользователей существуют.

3. Пользовательские сценарии

Какие основные задачи должен выполнять каждый пользователь.

4. Функциональные требования

Полный перечень функций текущей версии.

5. Требования к данным

Какие данные создаются, хранятся, изменяются и удаляются.

6. Интеграции

Системы и сервисы, с которыми взаимодействует приложение.

7. Нефункциональные требования

Производительность, безопасность, нагрузка, доступность, резервное копирование.

8. UX/UI

Прототипы, макеты, адаптивность, требования к интерфейсу.

9. Технические ограничения

Обязательная инфраструктура, языки или платформы, если такие ограничения действительно существуют.

10. Критерии приёмки

Условия, при которых функциональность считается реализованной.

11. Границы проекта

Что входит в текущий этап и что сознательно отложено.

12. Порядок изменения требований

Как согласуются новые функции и изменения уже утверждённого объёма.

Как согласовать ТЗ с подрядчиком и зафиксировать его юридически

В договорной модели ТЗ часто оформляют как приложение к договору, чтобы связать согласованный объём разработки с обязательствами сторон. Но конкретная юридическая схема зависит от самого договора и модели работы.

Российские IT-юристы IT-Lex отмечают, что технические задания обычно оформляются отдельными приложениями к договору на разработку ПО. При этом порядок изменения требований можно предусмотреть по-разному: отдельным письменным соглашением, электронной перепиской или через систему управления проектом, если такой механизм закреплён в договоре.

Поэтому неверно универсально утверждать, что любое изменение обязательно требует отдельного дополнительного соглашения.

Для Fixed Price проекта обычно важно жёстче зафиксировать:

• объём;
• результат;
• сроки;
• стоимость;
• критерии приёмки;
• порядок работы с дополнительными требованиями.

При Time & Materials требования могут уточняться итеративно, а отдельные задачи фиксироваться в backlog или таск-трекере. Но и в такой модели договор должен описывать, как именно стороны согласовывают задачи, оценки и результат.

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