На прошлой неделе я увидел парочку БФТ на работе. Там… пу-пу-пу… Потом прочитал пару комментариев в других ТГ-каналах: «Разработчики не читают текст длинного БФТ», «Хорошую фичу можно и без БФТ сделать, если тебе не мешают». Решил это обсудить.

За 15 лет я писал много документов разной длины и структуры и считаю, что БФТ на 50 листов никто не читает. Ни разработчик, ни тестировщик, ни стейкхолдер. Его сканируют по диагонали, а потом идут на созвон и спрашивают: «А что мы вообще делаем?»

БФТ на 50 листов пишется не для того, чтобы его читали. Он пишется, чтобы в случае провала можно было сказать: «Ну я же всё описал, вот, страница 27, пункт 3.1.2». Это алиби, а не инструмент.

Что реально должно быть в БФТ: Я для себя вывел формулу, которую использую в работе. БФТ - это не простыня. Это 5 блоков:

1️⃣ Какая цель фичи? Пишу по SMART. 2️⃣ Пользовательские сценарии (CJM / User Story) Описываю текстом + делаю UML Activity Diagram для тех, кому проще читать схемы. 3️⃣ Логика • Основная и альтернативные сценарии / исключения • Зависимости от других систем/фич • Особенности по платформам 4️⃣ Метрики успеха. Как поймём, что получилось? 5️⃣ Доп. материалы. Что нужно для реализации: • документы от партнёров / API • тексты для интерфейсов • макеты

Если не учитывать п.5, то всё остальное может уместиться: • на 1 лист для небольших фич • на 10-15 листов для чего-то крупного. Причём у меня UML будут занимать половину этого объёма.

Задача продакта - не написать энциклопедию. Не прикрыть себя. А убедиться, что команда поняла, зачем, для кого и что именно мы делаем.

БФТ на несколько листов + 15 минут созвона с командой работают лучше, чем ТЗ на 50 страниц без созвона. Проверено. Неоднократно.

А как у вас? Вы пишете короткие и чёткие БФТ? Или длинные документы, которые никто не читает? А может, просто созвон и фича пошла в работу?