Тема отвечает на вопрос, почему подробное техническое задание не защищает от ошибки и с каким минимумом можно идти в разработку. Тридцать страниц требований описывают решение, которое ещё никто не проверял, и снимают с автора ответственность за результат.
Ключевая мысль. В PAF требования пишут в конце, а не в начале. Сначала команда находит разрыв между текущим и нужным состоянием, собирает набор изменений и ищет доказательства.
Потом атакует аргументы на отдельной встрече — PAF называет её «питчингом доверия», — и изменения с низкой уверенностью выбрасывают. Требования формируют только по тем, что выжили.
Если потребность принёс сам заказчик в явном виде, проверять её не нужно: работа сразу начинается с проверки решения. На груминге аналитику и техлиду задают один вопрос: «Что здесь мы считаем верным, но не проверяли?» Ответы становятся задачами на выяснение, а не новыми страницами документа.
Как читать материалы:
- «Ловушка тяжёлого ТЗ: 30 страниц документации вместо 2-недельного теста» — полный разбор: почему полнота не равна ясности, как документ подменяет эксперимент и как исправить процесс. Короткая версия — для пересылки команде.
- «DIBB: как Spotify превратил „хотелки“ в проверяемые ставки» — цепочка данные → инсайт → убеждение → ставка. Возьмите оттуда вопрос «откуда мы знаем, что это нужно делать?» как фильтр входящих запросов перед тем, как писать требования.
Связанные темы: «Боль вместо буквальной просьбы» — что записать до требований, и «Решения при неопределённости» — как дёшево проверить допущения.
