«Нам нужен маркетплейс, как Wildberries, только для B2B» — примерно так звучит каждое второе техническое задание, которое мы получаем. Остальные начинаются со слов «нам нужно что-то типа Notion, но для нашей ниши».
Эти формулировки — не ТЗ. Это мечты. И проблема не в том, что вы не технарь. Проблема в том, что вы думаете о продукте, а не о его деталях.
Сегодня расскажу, как превратить «маркетплейс как Wildberries» в документ, по которому разработчики смогут реально работать. Без технических знаний.
Почему плохое ТЗ — это дорого
Расчёт простой:
- Баг, найденный на этапе написания требований: 1 час работы аналитика
- Баг, найденный на этапе разработки: 5–10 часов переделок
- Баг, найденный после запуска: 20–50 часов + потеря пользователей
Каждая неопределённость в ТЗ — это потенциальный баг. Чем раньше её закрыть, тем дешевле.
Метод «переводчика смыслов»: суть
Идея простая: вместо того чтобы думать о технологиях, думайте о людях и их действиях.
У каждой функции продукта есть: 1. Кто делает это действие (пользователь, администратор, система) 2. Что именно делает (конкретный глагол) 3. Зачем это нужно (какую проблему решает) 4. Что происходит дальше (следующий шаг в сценарии) 5. Что может пойти не так (граничные случаи)
Это и есть «перевод» от бизнес-смысла к техническому требованию.
Пошаговая инструкция
Шаг 1. Определите роли пользователей
Прежде чем описывать функции, ответьте на вопрос: кто будет пользоваться продуктом?
Запишите всех участников системы. Не "пользователи вообще", а конкретные роли.
Пример для платформы онлайн-курсов: - Ученик - Преподаватель - Администратор платформы - Гость (незарегистрированный пользователь)
Для каждой роли нужно понять: что она может делать, чего не может, и что видит на экране.
Шаг 2. Опишите сценарии через user story
User story — это одна строчка по шаблону:
Как [роль], я хочу [действие], чтобы [цель].
Примеры:
- Как ученик, я хочу видеть прогресс по курсу, чтобы понимать, сколько осталось до завершения.
- Как преподаватель, я хочу загружать видео к уроку, чтобы ученики могли просматривать материал.
- Как администратор, я хочу видеть статистику продаж за выбранный период, чтобы планировать маркетинг.
Напишите 20–50 таких историй. Именно столько нужно для нормального MVP.
Шаг 3. Детализируйте каждую историю через вопросы
Для каждой user story задайте себе пять вопросов:
1. Что пользователь видит на экране?
Не "страницу курса", а конкретно: название, описание, список уроков, кнопка "начать", прогресс-бар, рейтинг, отзывы?
2. Какие действия он может совершить?
Список кнопок и интерактивных элементов.
3. Что происходит после каждого действия?
Описываем следующий шаг — не "открывается новая страница", а что именно на ней.
4. Что может пойти не так?
Пользователь ввёл неправильный пароль. Загрузка видео зависла. Оплата не прошла. Для каждого случая нужен сценарий.
5. Что нельзя делать в этом разделе?
Ученик не должен видеть курсы других учеников. Преподаватель не должен видеть оплаты. Ограничения часто важнее функций.
Шаг 4. Составьте список экранов
После детализации историй выпишите все уникальные экраны (страницы или состояния) продукта.
Пример для EdTech:
- Лендинг (незарегистрированный пользователь)
- Страница регистрации / входа
- Каталог курсов
- Страница курса (с описанием, покупкой)
- Личный кабинет ученика (список купленных курсов, прогресс)
- Урок (видео + материалы + тест)
- Результат теста
- Страница преподавателя (управление курсами)
- Загрузка урока
- Аналитика для администратора
Этот список — скелет вашего продукта. Если экраны не перечислены, разработчики придумают их сами.
Шаг 5. Опишите бизнес-правила
Бизнес-правила — это логика, которая не видна на экране, но управляет продуктом.
Примеры: - Доступ к следующему уроку открывается только после завершения предыдущего. - Рефанд возможен в течение 7 дней после покупки, если просмотрено менее 30% курса. - Преподаватель получает выплату на 15-й день месяца, следующего за продажей.
Без этих правил разработчики напишут то, что им кажется логичным. Это не всегда совпадает с тем, что нужно вам.
Шаг 6. Расставьте приоритеты
Напротив каждой user story поставьте метку: - Must have — без этого продукт не работает - Should have — важно, но можно запустить без этого - Nice to have — хорошо иметь, но не срочно
Это позволит срезать бюджет, если нужно, без потери сути продукта.
Что НЕ нужно писать в ТЗ (если вы не технарь)
- Конкретные технологии ("нужен React, PostgreSQL, Redis")
- Архитектурные решения ("микросервисы, REST API v3")
- Структуру базы данных
Это — зона ответственности разработчиков. Ваша зона — бизнес-логика и пользовательский опыт.
Исключение: если у вас есть конкретные ограничения (например, интеграция с существующей 1С или нужна совместимость с конкретной платёжной системой) — это нужно указать.
Шаблон структуры ТЗ
1. Цель продукта (1–3 предложения)
2. Целевая аудитория (роли, кто пользуется)
3. Что НЕ входит в первую версию (важно!)
4. Список экранов с кратким описанием
5. User stories по ролям (с детализацией)
6. Бизнес-правила
7. Интеграции (что с чем должно работать)
8. Нефункциональные требования:
- Ожидаемое количество пользователей
- Скорость загрузки
- Устройства (мобильные, десктоп, оба)
9. Открытые вопросы (то, что ещё не решили)
Да, пункт 9 важен. Лучше честно написать "мы ещё не решили, как работает реферальная программа", чем не написать ничего и получить неожиданную реализацию.
Частые ошибки
«Интерфейс должен быть удобным»
Это не требование. Что значит удобный? Опишите конкретно: максимум 3 клика до целевого действия, форма регистрации — 3 поля, не 10.
«Система должна работать быстро»
Быстро — это сколько? Страница загружается за 2 секунды или за 5? Это разная архитектура и разная цена.
«Сделайте как у конкурентов, только лучше»
Конкуренты потратили годы и миллионы на свой продукт. Определите, какую конкретную функцию вы хотите воспроизвести — и опишите её.
Описание дизайна вместо функций
«Кнопка должна быть синей» — это не ТЗ, это мокап. ТЗ описывает поведение, а не внешний вид.
Если нет времени делать самому
Есть ещё один путь: услуга «Переводчик смыслов». Мы работаем так: вы рассказываете нам о своём продукте в свободной форме (звонок на 1–2 часа), наш аналитик задаёт все нужные вопросы и превращает разговор в полноценное ТЗ с user stories, списком экранов и приоритетами.
Результат — документ, по которому уже можно получать адекватные оценки от разработчиков. Стоимость — фиксированная, срок — 5 рабочих дней.
Пишите в @hexbit_requests_bot — расскажем подробнее.
Следующая статья: разбор кейса — как мы запустили онлайн-запись для барбершопа за 24 дня. Что пошло не так и как мы это исправили.