Как создать ТЗ для веб-приложения чек-лист
ТЗ для веб-приложения: чек-лист для фаундера, который не любит писать документы
У большинства фаундеров история примерно одна и та же. Есть идея сервиса, в голове — десятки экранов, в заметках — ссылки на «аналогов, только лучше», в чатах с партнёрами — обсуждения логики и тарифов.
А потом на сцену выходят разработчики и спокойно спрашивают:
«Пришлите, пожалуйста, ТЗ».
И всё. Настроение портится, проект откладывается «до того момента, когда будет время всё нормально описать».
Ниже — статья для тех, кто понимает, что хочет получить на выходе, но терпеть не может писать формальные документы. Это не «доклад по ГОСТу», а чек-лист, по которому можно за вечер собрать рабочее техническое задание на веб-приложение.
1. Что такое ТЗ на веб-приложение по-простому
Формальное определение простое: ТЗ — это документ, в котором описано, что нужно сделать, для кого, в каких условиях и с каким результатом.
По-простому:
ТЗ — это способ договориться с командой о том, что именно вы строите, чтобы не переделывать всё по три раза.
Хорошее ТЗ:
- снимает разночтения «мы думали, что будет по-другому»;
- помогает адекватно оценить сроки и бюджет;
- задаёт рамки: что попадает в первую версию (MVP), а что — «потом».
Важно: ТЗ не обязано быть идеальным. Лучше честный, но структурированный черновик, чем «идеальный документ, который вы пишете полгода».
2. Чек-лист: что обязательно должно быть в ТЗ
Ниже — структура, которую можно просто перенести в свой документ и заполнить. Это не строгий стандарт, а ориентир.
2.1. О компании и продукте
Пара абзацев, но по делу:
- чем занимается компания;
- кто целевая аудитория;
- в каком контексте будет жить веб-приложение (отдельный продукт, часть существующего сайта, внутренняя система и т.д.).
Пример:
Мы — сервис по доставке грузов B2B. Клиенты — интернет-магазины и оптовики. Сейчас заявки приходят из формы на сайте и по телефону, дальше всё ведётся в таблицах и переписках. Хотим перенести процесс в веб-приложение с личным кабинетом.
Этот блок помогает разработчикам не только «сделать кнопки», но и понять, под какие реалии они это делают.
2.2. Цели проекта
Здесь важно сформулировать бизнес-результат, а не «хочу красивое приложение».
Хорошие формулировки:
- сократить время обработки заявки с 2 дней до 2 часов;
- снизить количество ручного ввода данных менеджерами;
- дать клиенту возможность отслеживать статус без звонков;
- увеличить долю повторных заказов.
2–4 понятных цели — достаточно. Дальше по ним можно принимать продуктовые решения: что критично в первую очередь, а что можно отложить.
2.3. Роли пользователей и ключевые сценарии
Никаких UML-диаграмм не требуется. Достаточно ответить на два вопроса:
1. Кто будет пользоваться системой?
- клиент;
- менеджер;
- администратор / владелец проекта;
- партнёр (поставщик, подрядчик).
2. Что каждый из них будет делать?
Пример:
Клиент:
- зарегистрироваться и войти;
- создать заявку;
- загрузить документы;
- смотреть статусы;
- оплачивать.
Менеджер:
- видеть новые заявки;
- связываться с клиентом;
- менять статусы;
- оставлять внутренние комментарии.
Администратор:
- управлять пользователями;
- задавать тарифы и справочники;
- смотреть отчёты.
Такие сценарии — уже половина функциональных требований.
2.4. Функциональные требования
Здесь описывается, что именно умеет система. Не бойтесь простых формулировок.
Удобно разбить блок на подпункты:
Регистрация и авторизация
- вход по email / телефону;
- восстановление пароля;
- при необходимости — вход через внешние сервисы.
Личный кабинет клиента
- создание и редактирование заявки;
- список заявок и их статусы;
- сообщения от менеджера;
- загрузка файлов.
Админка / кабинет менеджера
- список заявок с фильтрами;
- карточка заявки с историей;
- изменение статуса;
- экспорт данных.
Уведомления
- что и кому отправляем (email, SMS, push);
- на каких ключевых событиях (новая заявка, смена статуса, приближение дедлайна).
Если сложно описывать «языком системного аналитика», можно так: «Пользователь заходит, видит кнопку “Создать заявку”, заполняет 5–7 полей и отправляет. После этого заявка должна появиться у менеджера в списке “Новые”».
2.5. Интеграции
Самый конфликтный блок, если его не проговорить заранее.
Ответьте на вопросы:
С какими системами нужно связать веб-приложение?
- 1С / бухгалтерия;
- CRM (Битрикс24, amoCRM, своя);
- платёжные сервисы;
- системы доставки;
- любые другие внешние API.
Какие данные должны ходить между системами?
- заявки и статусы;
- клиенты и сделки;
- счета, акты, оплаты.
Если каких-то деталей вы ещё не знаете — так и пишите. Важно хотя бы зафиксировать, что интеграции нужны и с кем.
2.6. Нефункциональные требования
Это пункт, который редко формулируют, но он сильно влияет на архитектуру и стоимость.
Что сюда попадает:
Нагрузка
- примерное количество одновременных пользователей;
- примерный объём операций в день (заявки, заказы, документы).
Скорость
- где критично время отклика;
- допустимы ли фоновые операции (например, расчёт стоимости).
Надёжность
- требуемое «время безотказной работы»;
- допустим ли ночной технический простой.
Безопасность
- работа с персональными данными;
- требования по журналированию действий пользователей;
- доступ к админке (IP-ограничения, двухфакторная авторизация и т.д.).
Даже если вы напишете в этом блоке лишь «ожидаем среднюю нагрузку, точные цифры пока неизвестны» — это уже лучше, чем ничего.
2.7. Дизайн и UX
Здесь не обязательно прикладывать готовые макеты, но полезно:
- указать, есть ли бренд-гайд (логотип, цвета, шрифты);
- дать 3–5 примеров интерфейсов, которые вам нравятся;
- описать, что категорически не нравится.
Пример формата:
- Нравится: минималистичные интерфейсы с большим количеством воздуха, как у [пример 1], [пример 2].
- Не нравится: перегруженные панели с десятком кнопок и мелким шрифтом.
Отдельно проговорите:
- критична ли мобильная версия (и в каком виде: адаптив или отдельное мобайл-решение);
- есть ли требования по доступности (контраст, крупные элементы, особенности целевой аудитории).
2.8. Отчёты и аналитика
Про отчёты вспоминают в последний момент, когда проект почти готов. Лучше заложить их сразу.
Ответьте на вопросы:
Какие показатели вы хотите видеть регулярно?
- количество заявок;
- конверсия по статусам;
- выручка;
- эффективность менеджеров.
В каком виде отчёты нужны?
- таблицы внутри системы;
- выгрузка в Excel;
- простые дашборды с графиками.
Хороший ориентир — вопрос к себе как к владельцу:
«Открыл систему утром — какие три цифры я хочу увидеть в первую очередь?»
2.9. Ограничения и «точно не надо»
Этот блок редко попадает в ТЗ, хотя именно он спасает от бесконечного расползания задач.
Сюда можно вынести:
Бюджет — хотя бы вилку;
Сроки — жёсткие даты (мероприятия, релизы, договорённости);
Технологические ограничения — например, необходимость использовать существующую инфраструктуру;
Идеи, которые сейчас точно не делаем:
- «Не делаем мобильное приложение в первой версии»;
- «Не вводим сложную систему ролей, начинаем с базовых».
Чёткий список «не делаем» помогает не перегружать MVP.
3. Как собрать ТЗ, если вы не любите писать
Фаундер не обязан превращаться в аналитика и лично оформлять идеальный документ. Рабочая схема может быть такой:
- Создать черновой документ Вынести туда пункты из чек-листа и коротко ответить на вопросы — тезисами, без красивых формулировок.
- Пройтись по нему голосом Обсудить черновик с партнёром, продукт-менеджером или подрядчиком. Можно записать голосовое или провести созвон.
- Передать оформление тем, кто привык к документам Аналитик или ведущий разработчик собирает финальное ТЗ на основе ваших ответов и уточняющих вопросов.
Ваша зона ответственности — смысл и решения, а не выравнивание списка в Word.
4. Частые ошибки в ТЗ на веб-приложение
Короткий анти-чек-лист:
- «Сделайте как у [известный сервис], только лучше» Без описания своей модели, процессов и аудитории.
- Нет приоритизации Всё важно, всё нужно «на вчера», нет разделения на MVP и вторую очередь.
- Сценарии пользователей не описаны Есть набор функций, но непонятно, как ими реально пользуются живые люди.
- Интеграции всплывают в последний момент На этапе разработки внезапно появляется «а ещё нужно, чтобы всё летело в 1С и обратно».
- Не сформулированы бизнес-цели Тогда любые споры превращаются в обсуждение вкуса, а не результата.
Если вы пройдётесь по чек-листу из предыдущего раздела, часть этих ошибок автоматически отпадёт.
5. Мини-шаблон, который можно скопировать
Ниже — короткий каркас. Его можно просто вставить в свой документ и заполнить.
Техническое задание на разработку веб-приложения «…»
1. О компании и продукте
Кто вы, чем занимаетесь, для кого создаёте приложение.
2. Цели проекта
2–4 измеримые бизнес-цели, которых хотите достичь с помощью приложения.
3. Роли и сценарии пользователей
Перечень ролей (клиент, менеджер, администратор и т.д.) и основные действия каждого.
4. Функциональные требования
4.1. Регистрация и авторизация
4.2. Личный кабинет клиента
4.3. Кабинет менеджера / админка
4.4. Уведомления
4.5. Прочий функционал
5. Интеграции
Список внешних систем и описание того, какие данные должны обмениваться.
6. Нефункциональные требования
Нагрузка, скорость, надёжность, безопасность, требования к доступности.
7. Дизайн и UX
Наличие бренд-гайда, референсы интерфейсов, требования по адаптиву и удобству.
8. Отчёты и аналитика
Какие отчёты и показатели нужны в системе.
9. Ограничения и «точно не делаем»
Бюджетная вилка, сроки, технологические ограничения, список идей «на потом».
ТЗ на веб-приложение не должно превращаться в отдельный проект на полгода. Достаточно один раз спокойно пройтись по таким пунктам, зафиксировать решения и отдать документ тем, кто будет по нему работать.