Как составить ТЗ (Техническое задание) на веб-приложение: Практическое руководство для Фаундеров

У большинства стартаперов и фаундеров история начинается одинаково: есть прорывная идея площадки, в голове нарисованы все экраны, а в Telegram-Избранном лежат ссылки на аналоги с пометкой "Сделать так же, только лучше".

А потом команда разработчиков или студия задает один вопрос: "Пришлите, пожалуйста, ТЗ". И процесс буксует. В этой статье мы разберем, как составить техническое задание на веб-приложение (SRS — Software Requirements Specification), не впадая в бюрократию по ГОСТу, но защитив себя от потери миллионов рублей на переделки.

---

1. Что такое ТЗ в современной разработке?

Толстые талмуды на 150 страниц ушли в прошлое. В методологии Agile, Техническое Задание — это живой документ-договорняк. Его цель — синхронизировать картинку в голове фаундера с картинкой в голове архитектора базы данных.

Зачем вам документ, если всё "и так понятно":

1. Защита от "сюрпризов": Разработчик сделал регистрацию только по email, а вы хотели по номеру телефона с СМС-кодом.
2. Точная смета: Без детализации экранов невозможно посчитать часы разработки. Вам назовут вилку от 1 до 5 млн рублей, и выберут верхнюю границу для страховки.
3. Обрезка MVP: Фиксация того, что мы НЕ ДЕЛАЕМ в первой версии.

---

2. Структура рабочего Технического Задания

Возьмите чистый Google Документ и заполните его по 6 ключевым блокам. Этого достаточно, чтобы передать проект системному аналитику для оценки.

Блок 1. Бизнес-контекст и Суть (Elevator Pitch)

Опишите суть проекта в 3 предложениях:

• Что делаем? (B2B маркетплейс автозапчастей).
• Кто покупает? (Оптовые базы, СТО).
• В чем наша фишка продукта? (Интеграция складов в реальном времени, вместо суточных прайс-листов).

Блок 2. Роли и User Stories (Сценарии)

Откажитесь от описания кнопок ("Должна быть красная кнопка"). Описывайте сценарии (US):

• Роль "Покупатель": Я хочу зарегистрироваться по ИНН компании, чтобы система сама подтянула мои реквизиты. Я хочу положить товар в корзину и выгрузить Счет на оплату в PDF.
• Роль "Менеджер": Я хочу видеть канбан-доску заказов. Я хочу менять статус заказа, чтобы клиенту уходила СМС-ка.
• Роль "Супер-Админ": Я хочу иметь возможность банить Покупателей и выгружать отчет по маржинальности за месяц.

Блок 3. Интеграции с внешними API (Критичный блок)

Укажите, с чем должно "общаться" ваше веб-приложение:

• Бухгалтерия: 1С:Предприятие (как часто синхронизировать?).
• Платежи: Эквайринг Т-Банка, ЮKassa.
• Телефония и Мессенджеры: Уведомления в Telegram, AmoCRM.
• Службы доставки: СДЭК, Яндекс.Доставка (расчет тарифа по габаритам).

Блок 4. Нефункциональные требования (NFRs)

Это то, о чем забывают фаундеры, но за что потом расплачиваются:

• Нагрузка: Ожидается 100 пользователей в день или 10 000 в секунду?
• Безопасность: Нужна ли двухфакторная аутентификация (2FA)? Как храним перс. данные (ФЗ-152)?
• Доступность: Приложение работает в браузере мобильного телефона (PWA/Адаптив), или это строгий Desktop-интерфейс для бухгалтеров?

[LEAD_AUDIT]

---

3. Топ-4 Ошибки при постановке ТЗ

1. "Сделайте аналог Авито/Wildberries": В Wildberries работают 5000 программистов, и система строилась 15 лет. Нельзя указать сервис-миллиардер как ориентир для MVP за 2 миллиона рублей. Указывайте конкретный узкий флоу (Flow), который вам нравится (например, "Сделайте корзину как в Яндекс.Лавке").
2. "Дизайн должен быть современным": Это субъективно. Прикрепите 3 ссылки на сайты, которые вам визуально нравятся (Референсы), и 3 ссылки, которые вы считаете уродливыми.
3. Отсутствие этапа "Глупого пользователя": Не описано, что должна делать система, если клиент ввел вместо ИНН слово "Котик". Упоминайте базовую валидацию.
4. Угроза бесконечного Scope Creep: Постоянное добавление новых "хотелок" в процессе разработки.

Резюме

Вам не нужно быть программистом, чтобы написать хорошее ТЗ. Ваша задача — описать бизнес-логику досконально. Как именно информация будет сохраняться в базу данных — решит IT-подрядчик.

В NBM-IT мы не требуем от клиентов идеальных ТЗ по ГОСТ 34. На этапе Presale наши системные аналитики сами проводят серию глубинных интервью с заказчиком, формализуют бизнес-процессы в BPMN-схемы и пишут понятное техническое задание, которое защищает ваш проект от выхода за рамки бюджета. Обсудите вашу идею с нашим техдиректором.