Зачем вообще нужно техническое задание
Техническое задание фиксирует общее понимание продукта между заказчиком и разработчиками: какие задачи он решает, как работает и что должно быть готово к сдаче.
Без ТЗ фраза «сделайте удобный каталог» для заказчика означает «быстрый поиск с фильтрацией по 20 характеристикам и подсказками», а разработчик понимает её как «простой список товаров из базы данных в алфавитном порядке». ТЗ устраняет двусмысленность и фиксирует критерии готовности.
Оптимальная структура ТЗ для веб-проекта
- Вводная часть и цель продукта: Коротко опишите, какую проблему решает продукт и кто его основные пользователи.
- Роли пользователей: Например: Гость, Зарегистрированный клиент, Менеджер заказов, Администратор системы.
- Описание экранов и сущностей: Перечень ключевых страниц и блоков с указанием того, какие данные отображаются и какие действия доступны.
- Внешние интеграции: Какие сервисы требуется подключить (шлюз эквайринга, SMS-провайдер, Telegram-бот).
- Нефункциональные требования: Требования к скорости загрузки, языковым версиям и адаптивности под мобильные экраны.
Формула User Story: говорим на языке пользы
Описывайте функции через короткие пользовательские сценарии:
Как [роль пользователя],
Я хочу [выполнить конкретное действие],
Чтобы [получить измеримую пользу или результат].
Пример: «Как менеджер по закупкам, я хочу отфильтровать список оборудования по статусу «На складе», чтобы быстро сформировать коммерческое предложение клиенту».
Такая формулировка сразу объясняет инженерам контекст задачи и позволяет предложить оптимальное техническое решение.
Пример требования с критериями приёмки
Для записи в мастерскую фразу «сделать онлайн-запись» можно разложить на проверяемые условия.
- Клиент видит услуги, длительность и доступные интервалы.
- После выбора времени указывает имя и контакт для подтверждения.
- Сервер проверяет, что интервал ещё свободен.
- При успешной записи создаётся одна заявка и появляется номер подтверждения.
- Если уведомление сотруднику не доставлено, запись сохраняется и доступна в расписании.
- При занятом интервале клиент получает понятное сообщение и может выбрать другой.
Теперь заказчик и разработчик проверяют одну и ту же последовательность. Отдельно остаётся согласовать отмену, перенос, график работы и права администратора.
Какие материалы приложить
Подготовьте пример реального документа с удалёнными персональными данными, перечень полей, макеты важных экранов и список внешних систем. Для каждой интеграции укажите ответственного за доступ и тестовую среду.
Для переноса данных приложите небольшой обезличенный фрагмент выгрузки. Колонки с одинаковым названием иногда хранят разные форматы, поэтому одного перечня полей недостаточно.
Проверка перед передачей
Прочитайте документ как новый сотрудник. Понятно ли, кто выполняет каждое действие, какие данные вводит и что происходит при ошибке? Есть ли ограничения для чужих записей? Описаны ли мобильный сценарий, резервное копирование и способ приёмки?
Если требование нельзя проверить, добавьте наблюдаемый результат. Вместо «быстро работает» согласуйте конкретную операцию, объём данных, условия проверки и допустимое время. Число выбирайте вместе с командой исходя из задачи.