«Нам нужна система, которая обрабатывает бронирования» — это не требование, а пожелание, и ни один разработчик не может оценить пожелание. Разрыв между тем, что клиент имеет в виду, и тем, из чего разработчик реально может строить, — это место, где большинство смет ломаются ещё до первой строки кода, потому что расплывчатое задание получает расплывчатую оценку, а расплывчатая оценка — семя каждого спора о границах проекта, который последует.
Разница между функцией и требованием
«Клиенты должны иметь возможность бронировать онлайн» описывает функцию. Это не говорит, что происходит, когда два клиента пытаются забронировать один слот одновременно, требует ли бронирование подтверждения или подтверждается мгновенно, что происходит, если оплата не проходит после удержания слота, или отличается ли отмена за час до визита от отмены за неделю. Каждый из этих пунктов — реальное решение с реальной стоимостью разработки, и ни один не виден в однострочном описании функции — они всплывают только когда кто-то начинает строить и вынужден гадать, либо останавливается и спрашивает.
Критерии приёмки превращают пожелание в то, что можно построить
Требование становится оцениваемым, когда конкретно указывает, как выглядит «готово»: при этом вводе — именно такой вывод; в этом граничном случае — именно такое поведение. «Клиент может забронировать приём» становится строимым, когда звучит ближе к «клиент выбирает доступный слот, получает подтверждение в течение 60 секунд, и слот становится недоступен другим клиентам в момент выбора, а не после завершения оплаты». Такой уровень детализации кажется избыточным для маленькой функции и необходимым в первый раз, когда неоднозначная функция вызывает двухнедельный спор о том, что было реально обещано.
Неоднозначности, надёжно вызывающие перерасход
Горшстка пробелов встречается почти в каждом недостаточно специфицированном проекте: что происходит при ошибке (пользователь не видит ничего, общее сообщение или конкретное), что происходит на границах обычного использования (ноль результатов, максимально допустимый ввод, повторная отправка), кто может видеть или редактировать что, и что должна делать система, когда два человека пытаются действовать с одной записью одновременно. Ничто из этого не экзотично — это обычные ситуации, постоянно происходящие в продакшене, — но именно эти ситуации однопараграфное задание никогда не упоминает, потому что они становятся очевидными только когда кто-то реально строит вещь.
Почему это защищает обе стороны, а не только разработчика
Детальное требование — не бюрократия ради бюрократии, а документ, к которому обе стороны могут вернуться, когда позже возникает разногласие. Без него «это не то, что мы просили» и «это именно то, что вы просили» — оба верных утверждения об одной и той же расплывчатой фразе, и решение этого стоит больше времени и доброй воли, чем стоило бы правильно записать требование с самого начала.
Правильная работа над этим в начале — часть того же решения купить, построить или настроить — потому что даже правильный подход даёт реально работающую систему только тогда, когда то, что строится, специфицировано достаточно чётко, чтобы это можно было построить.
Наша команда разработки превращает простое описание клиента в требования уровня критериев приёмки до всякой оценки, чтобы смета отражала то, что реально будет построено, а не догадку об этом.
