Требование однозначно и проверяемо, но после релиза проблема бизнеса не решена. Какую проверку аналитик пропустил?
Аналитик пропустил валидацию требования — проверку того, что оно действительно отражает потребность бизнеса и ведёт к нужному результату. Однозначность и проверяемость относятся в основном к качеству формулировки, но не доказывают полезность выбранного решения.
В работе с требованиями выделяют два разных класса ошибок. Первый возникает, когда требование сформулировано неясно, противоречиво или непроверяемо. Второй — когда требование описано качественно, но решает не ту проблему или не соответствует цели бизнеса.
Разделение верификации и валидации помогает не ограничиваться проверкой текста. Верификация отвечает на вопрос, правильно ли сформулировано требование, а валидация — то ли требование вообще нужно реализовывать.
Например, бизнес хочет сократить время обработки заявок. Аналитик фиксирует требование: «Система должна автоматически распределять новые заявки между операторами по заданному правилу». Оно может быть однозначным и иметь измеримый критерий приёмки.
Однако автоматическое распределение не решит проблему, если основная задержка возникает из-за ожидания согласования или нехватки полномочий у операторов. В результате команда реализует требование корректно, но бизнес-эффект не появляется.
При валидации аналитик связывает требование с исходной бизнес-проблемой, целью и ожидаемым эффектом. Нужно установить:
Полезная цепочка рассуждения выглядит так: проблема → бизнес-цель → потребность пользователя или бизнеса → требование → ожидаемый результат. Если связь между звеньями не подтверждена, требование нельзя считать обоснованным только потому, что его легко проверить.
Верификация проверяет внутреннее качество требования: отсутствие двусмысленности, полноту, непротиворечивость, проверяемость и согласованность терминов. Валидация проверяет внешнее соответствие: помогает ли требование достичь цели и отвечает ли оно реальной потребности.
Валидация не означает гарантии результата. Даже правильно обоснованное требование может дать слабый эффект из-за неверных данных, низкого использования функции или внешних факторов. Поэтому для значимых решений полезно заранее определить гипотезу эффекта, способ измерения и условия, при которых результат можно интерпретировать.
В контактном центре целью было сократить время ответа клиенту. Команда предложила требование автоматически назначать обращения свободным операторам.
Рассматривались три варианта. Первый — реализовать только автоматическое распределение: он прост для объяснения и относительно быстр, но не устраняет задержки при нехватке специалистов. Второй — увеличить штат: он может повысить пропускную способность, но требует постоянных затрат и не решает организационные причины ожидания. Третий — сначала разделить время обработки на ожидание, работу и согласование, а затем автоматизировать распределение только для подтверждённого узкого места.
Выбрали третий вариант. Анализ показал, что основная задержка возникала не при назначении обращения, а при передаче сложных случаев на согласование. Поэтому первоначальное требование признали технически качественным, но невалидным относительно заявленной бизнес-цели. После уточнения процесса автоматизация была направлена на сокращение времени согласования, а результат оценивали по медианному времени прохождения сложных обращений и доле обращений, уложившихся в целевой срок.
Нет. Подпись подтверждает согласование с конкретным представителем, но не доказывает связь требования с измеримой бизнес-целью. Заказчик мог предложить привычное решение, не проверив исходную проблему, интересы других групп или ожидаемый эффект.
Нужно дополнительно проверить источник потребности, затронутые роли, основания выбора решения и критерий полезности. Если требование является частью гипотезы, полезно зафиксировать, какое наблюдение подтвердит или опровергнет её.
Недостаточно. Изменение метрики может быть вызвано сезонностью, изменением состава обращений, политикой компании или другими инициативами.
Метрику следует связать с механизмом воздействия требования и, насколько возможно, сравнить сопоставимые сегменты, периоды или контрольную группу. Даже тогда результат подтверждает эффект решения с определённой степенью уверенности, но не заменяет исходную проверку потребности.
Сначала нужно разделить ошибку в обосновании и ошибку в реализации или условиях применения. Проверяют, сохранилась ли исходная проблема, используется ли функция, выполнены ли предположения, корректно ли измеряется результат и не возникли ли побочные ограничения.
Если проблема была определена верно, но механизм воздействия оказался слабым, требование или решение уточняют на основании новых данных. Нельзя автоматически заключать, что бизнес-потребность была ошибочной, так же как нельзя считать любое неудачное внедрение доказательством её отсутствия.