ТЗ на фичу: требования, user stories и критерии приёмки
Предмет
Что здесь работа, а не файл
ТЗ разваливается не на формулировках, а на требованиях без источника и без проверяемого критерия. Здесь 14 требований, у каждого — откуда оно взялось и как проверить, что сделано. Отдельный лист «вне scope»: у каждого «не входит» есть причина, иначе команда строит лишнее.
Требования: ID, источник, приёмка, приоритет
Критерий приёмки: по чему работа считается сделанной
| Источник у требования | Интервью, тикет поддержки, встреча или политика продукта — иначе требование не пишется |
|---|---|
| Критерий приёмки Given/When/Then | Спор о готовности решается проверкой, а не мнением продакта |
| Минимизация данных, 152-ФЗ ст. 5 ч. 5 | Если фича трогает персональные данные, в требовании стоит основание и оно проверяется до старта |
Как идёт работа
- 1
Собрать входы
Интервью, тикеты поддержки, встречи, политика продукта — всё, что станет источником
- 2
Разложить на требования
ID, формулировка, источник, приоритет MoSCoW, риск
- 3
Написать приёмку
Для каждого — проверяемый сценарий, а не «должно работать»
- 4
Обозначить границы
Лист «вне scope»: что не входит и почему — это тоже требование
- 5
Проверить на персональные данные
Найти требования, где появляются данные человека, и поставить основание
Агент делает. Вы решаете.
| Агент сводит требования | Разбирает интервью и тикеты, вытаскивает требования, ставит источник и приёмку |
|---|---|
| Агент проверяет полноту | Ищет требования без источника и без критерия приёмки — это дырки, а не мелочи |
| Вы решаете приоритет | MoSCoW — предложение агента; чем жертвовать, решает продакт |
| Вы отвечаете за границы | Что не входит в фичу — решение человека: агент показывает цену каждого «да» |
Подключения
Что подключим
Статус каждой системы назван честно: обещание — с условием и сроком
Задачи и бэклог
подключим: доступ к порталу задач, срок — два дня; требования уходят в трекер, а не в переписку
Почта и тикеты
подключим: отдельный ящик поддержки, срок — день; тикеты становятся источником требований
Документы и таблицы
подключим: доступ к папке, срок — день; ТЗ и таблица требований лежат у вас
Мессенджер команды
подключим: бот в рабочем чате, срок — день; статус и вопросы по требованиям — там же
Данные
Откуда берутся цифры
Интервью и записи
Цитаты с таймкодом — источник требования, а не пересказ
Тикеты поддержки
Каждое повторяющееся обращение — кандидат в требование
Политика продукта
Сроки хранения, пороги, правила — оттуда берутся ограничения
Норма
152-ФЗ — основание для требований о данных, а не украшение документа
Как проверить
Три проверки ТЗ
Возьмите любое требование и спросите: откуда оно. Если ответ «нам кажется» — требование некачественное. Затем попросите критерий приёмки и проверьте, можно ли его проверить не споря. И посмотрите лист «вне scope»: если он пуст, границы не определены.
Развилка: три пути и их последствия
| А: полное ТЗ | 14 требований с приёмкой — команда строит без догадок; цена: две недели на документ |
|---|---|
| Б: короткое ТЗ и гипотеза | Три требования и проверка на прототипе — быстрее, но риск переделки выше |
| В: без ТЗ | Требования живут в голове продакта — команда переспрашивает, приёмка становится вкусовой |
Границы
Что агент не делает
ТЗ не решает, что строить: приоритет и границы — за продактом. Оно не заменяет техзадание на интеграцию и не описывает архитектуру — это работа архитектора. Юридическую оценку по персональным данным даёт юрист: агент только помечает требования, где данные человека появляются, и ставит основание. И ни одно требование не утверждается автоматически.
Возражения
Что обычно спрашивают до входа
У нас нет интервью, только тикеты
Тикет — тоже источник. Хуже, когда источником становится «мне кажется»
Команда не будет читать длинное ТЗ
Поэтому таблица требований и короткий документ: 14 строк читаются за пять минут
Агент придумает требования
Без источника требование просто не попадает в таблицу — это проверяется по столбцу «источник»
Частые вопросы
Что такое критерий приёмки на практике
Одна фраза «дано — когда — тогда», которую можно проверить, не споря о вкусах
Зачем лист «вне scope»
Чтобы через месяц никто не сказал «а мы думали, это входит». Причина важнее самого списка
Как связаны ТЗ и прототип
Прототип проверяет требование до разработки: если на прототипе непонятно — требование сформулировано плохо
Что с персональными данными
Требования, где появляются данные человека, помечаются основанием 152-ФЗ и проверяются до старта
Куда дальше
Соседние компетенции
Прототип интерфейса до дизайнера
Проверить требование на экране, не дожидаясь дизайнера
Разбор рынка перед фичей
Откуда берётся решение, что фича вообще нужна
Roadmap и приоритет бэклога
Куда ставить фичу в квартале и что снять ради неё
- Рубли без VPN
- Договор с ИП
- Данные в России
- Чтение по умолчанию
- Токены в подарок
Роли
Принесите интервью и тикеты — заберёте ТЗ с приёмкой
Агент сведёт требования, поставит источник и критерий приёмки, покажет границы.