Разбор техник BABOK: Критерии приемки и оценки

Одной из наиболее распространенных причин конфликтов между заказчиком, аналитиками и командой разработки является различие в понимании того, когда решение можно считать успешно реализованным. Для одних участников проекта достаточно того, что функционал был разработан в соответствии со спецификацией. Для других важна возможность использовать решение в повседневной работе. Для третьих критерием успеха является достижение запланированных бизнес-показателей.

Техника BABOK «Критерии приемки и оценки» (Acceptance and Evaluation Criteria) предназначена именно для устранения подобных разночтений. Она позволяет заранее определить, каким образом заинтересованные стороны будут принимать результаты работы и по каким признакам будет оцениваться успешность решения после его внедрения.

Несмотря на внешнюю простоту, эта техника является крайне важной в практике бизнес-анализа. Во многих организациях критерии приемки ограничиваются набором тест-кейсов или формулировками вроде «система должна работать корректно». В результате проект может быть формально завершен, но при этом не принести ожидаемой бизнес-ценности.

Сущность техники

BABOK определяет критерии приемки и оценки как набор условий, позволяющих определить, удовлетворяет ли решение установленным требованиям и достигает ли ожидаемых результатов бизнеса.

Техника включает две взаимосвязанные, но различающиеся между собой категории критериев.

Критерии приемки отвечают на вопрос:

Можно ли считать результат работы выполненным и готовым к передаче заказчику?

Критерии оценки отвечают на другой вопрос:

Принесло ли внедренное решение ту пользу, ради которой оно создавалось?

Первый тип критериев ориентирован преимущественно на поставку решения, второй — на достижение бизнес-результатов.

Это различие является фундаментальным. Решение может полностью удовлетворять критериям приемки и одновременно провалиться с точки зрения критериев оценки.

Например, новая CRM-система может успешно пройти приемочное тестирование, содержать весь согласованный функционал и быть введенной в промышленную эксплуатацию. Однако если время обработки заявки осталось прежним, а конверсия продаж не изменилась, бизнес может посчитать проект неудачным.

Место техники в жизненном цикле требований

BABOK связывает эту технику сразу с несколькими задачами жизненного цикла бизнес-анализа: валидацией требований, анализом потенциальной ценности решения, измерением эффективности решения и анализом показателей эффективности.

На практике это означает, что работа с критериями начинается значительно раньше этапа тестирования.

Распространенной ошибкой является попытка сформулировать критерии приемки после завершения разработки. В этом случае критерии превращаются в механизм оправдания уже реализованного решения, а не в инструмент управления ожиданиями.

Опытные бизнес-аналитики стараются определить основные критерии еще на этапе формирования требований и вариантов решения.

Фактически критерии становятся мостом между тремя уровнями проекта:

  • бизнес-потребностью
  • требованиями к решению
  • измерением результата внедрения

Если хотя бы одно из этих звеньев отсутствует, появляется риск создания функционала ради самого функционала.

Основные элементы техники

Критерии приемки

Критерии приемки описывают условия, выполнение которых позволяет считать конкретное требование, функцию или решение завершенными.

Они могут относиться к:

  • функциональному поведению системы
  • качественным характеристикам
  • ограничениям
  • требованиям безопасности
  • требованиям производительности
  • требованиям к интеграциям
  • требованиям к пользовательскому интерфейсу

Хороший критерий приемки обладает несколькими свойствами:

  • однозначность
  • проверяемость
  • измеримость
  • отсутствие субъективных оценок
  • возможность независимой проверки результата

Плохой пример:

Система должна быстро открывать карточку клиента.

Хороший пример:

Карточка клиента должна открываться не более чем за две секунды при нагрузке до 500 одновременных пользователей.

Плохой пример:

Интерфейс должен быть удобным.

Хороший пример:

Пользователь должен иметь возможность создать заявку не более чем за пять действий без перехода между разделами системы.

Критерии оценки

Критерии оценки используются уже после внедрения решения.

Они позволяют определить:

  • достигнуты ли бизнес-цели
  • изменилась ли эффективность процессов
  • оправдались ли инвестиции
  • следует ли продолжать развитие решения

В отличие от критериев приемки, критерии оценки практически всегда связаны с измерением бизнес-показателей.

Например:

  • снижение времени обработки заказа с 15 до 7 минут
  • уменьшение количества ошибок ввода на 60%
  • сокращение затрат на сопровождение на 20%
  • увеличение количества обработанных заявок на одного сотрудника на 30%
  • повышение удовлетворенности клиентов до уровня не ниже 4,5 баллов из 5

Практический пример применения техники

Предположим, компания внедряет портал самообслуживания клиентов.

Формальный подход к приемке может выглядеть следующим образом:

  • регистрация работает
  • восстановление пароля работает
  • пользователь может создать обращение
  • пользователь может посмотреть историю обращений

Проект успешно завершается.

Через полгода выясняется, что нагрузка на контактный центр не снизилась, а клиенты продолжают звонить операторам.

Причина заключается в отсутствии критериев оценки.

Если бы они были определены заранее, они могли бы выглядеть следующим образом:

  • доля обращений через операторов должна снизиться на 40%
  • не менее 60% клиентов должны использовать портал повторно
  • среднее время решения типового вопроса должно сократиться на 50%
  • удовлетворенность пользователей не должна быть ниже 4 баллов из 5

В таком случае команда была бы вынуждена задуматься не только о наличии функций, но и об удобстве их использования.

Использование в Agile

В Agile-среде критерии приемки чаще всего существуют в виде Acceptance Criteria внутри пользовательских историй.

Например:

User Story

Как клиент банка я хочу самостоятельно блокировать карту через мобильное приложение, чтобы не обращаться в контактный центр.

Критерии приемки:

  • пользователь может выбрать карту из списка
  • блокировка выполняется не более чем за пять секунд
  • пользователь получает подтверждение операции
  • операция фиксируется в истории действий
  • при отсутствии связи операция не выполняется и пользователь получает уведомление об ошибке

Несмотря на широкое распространение подобных критериев, критерии оценки в Agile-проектах часто игнорируются.

В результате команды прекрасно измеряют velocity и количество закрытых задач, но не способны ответить на вопрос, изменилась ли ситуация для бизнеса после поставки функционала.

Типичные ошибки

Наиболее распространенной ошибкой является использование в качестве критериев субъективных формулировок:

  • удобно
  • быстро
  • качественно
  • современно
  • интуитивно понятно
  • достаточно надежно

Подобные критерии неизбежно приводят к спорам на этапе приемки.

Вторая ошибка заключается в смешении критериев приемки и бизнес-целей.

Например:

Увеличение продаж на 15%.

Это не критерий приемки функционала интернет-магазина, а критерий оценки эффективности решения.

Третья ошибка связана с отсутствием владельца критерия. Если никто не отвечает за измерение показателя после внедрения, критерий оценки остается исключительно декларативным.

Четвертая ошибка заключается в использовании критериев, измерение которых невозможно или экономически нецелесообразно.

Например:

Система должна повысить лояльность сотрудников.

Если организация не располагает инструментами измерения лояльности, подобный критерий не имеет практической ценности.

Хорошие и плохие практики

  1. Хорошей практикой является совместная разработка критериев бизнес-аналитиком, заказчиком, представителями бизнеса и командой реализации. Плохой практикой является ситуация, когда критерии формулируются исключительно бизнес-аналитиком или исключительно разработчиками.

  2. Хорошей практикой является привязка каждого критерия к конкретному требованию или бизнес-цели. Плохой практикой является существование отдельного списка критериев, не связанного ни с требованиями, ни с целями проекта.

  3. Хорошей практикой является определение базового значения показателя до начала изменений. Невозможно измерить эффект внедрения, если организация не знает исходного состояния процесса.

Практические рекомендации

Опытные бизнес-аналитики обычно придерживаются нескольких простых правил.

Во-первых, каждый критерий должен отвечать на вопрос:

Как именно мы поймем, что достигли успеха?

Во-вторых, критерий должен быть проверяемым независимым участником проекта.

В-третьих, желательно использовать числовые показатели вместо качественных характеристик.

В-четвертых, критерии оценки следует определять одновременно с формированием бизнес-кейса проекта.

В-пятых, полезно заранее определить период измерения эффекта. Некоторые решения начинают приносить результат через несколько недель после внедрения, другие требуют нескольких месяцев для адаптации пользователей.

Ограничения техники

Критерии приемки и оценки не способны компенсировать недостатки плохо сформулированных требований или отсутствие понимания бизнес-целей.

Кроме того, существуют инициативы исследовательского характера, для которых заранее определить измеримые критерии крайне сложно. Это особенно характерно для инновационных продуктов, экспериментальных сервисов и некоторых проектов цифровой трансформации.

В подобных ситуациях критерии формулируются итеративно и уточняются по мере накопления информации.

Вместо заключения

Техника BABOK «Критерии приемки и оценки» является одним из ключевых механизмов перехода от обсуждения функциональности к обсуждению ценности решения.

Критерии приемки позволяют определить момент завершения работ и избежать конфликтов между поставщиком и заказчиком. Критерии оценки позволяют понять, достигла ли организация тех целей, ради которых были потрачены время, деньги и ресурсы.

Практика показывает, что эффективность бизнес-анализа часто определяется не качеством написанных требований, а способностью заранее ответить на один простой вопрос: что должно произойти, чтобы мы признали проект успешным?