Критерии приёмки открывают, когда проект слишком часто упирается в разрыв между «мы это сделали» и «это не то, что ожидали увидеть». Это особенно болезненно там, где требования выглядят понятными на словах, но не переводятся в проверяемый результат.
Что это за подход
Acceptance criteria полезны как проверяемые условия приемлемости результата. Для PM это способ заранее определить, по каким признакам работа будет считаться принятой, а не обсуждать это задним числом.
Когда он нужен
- результат легко трактуется по-разному;
- проект чувствителен к спорной приёмке;
- стейкхолдеры и команда используют разные формулировки ожиданий;
- нужно уменьшать ambiguity до начала реализации.
Когда он не нужен
- если работа слишком exploratory и пока не поддаётся точной фиксации;
- если критерии пишут ради шаблона без связи с реальной проверкой;
- если один общий критерий пытаются натянуть на все типы задач одинаково.
Что из него реально применимо для PM
- делать ожидания более проверяемыми;
- переводить требования в понятные признаки результата;
- снижать конфликт по качеству и полноте;
- улучшать handoff между требованием, реализацией и приёмкой.
Какие артефакты, ритуалы и правила важны
- связь критерия с конкретным результатом;
- проверяемость и конкретность формулировок;
- согласование до начала реализации;
- использование критериев в demo, тесте и приёмке.
Какие ошибки чаще всего делают при внедрении
- пишут критерии слишком абстрактно;
- дублируют требования без конкретизации результата;
- не возвращаются к критериям в момент проверки;
- путают acceptance criteria с DoD.
Чем можно заменить или упростить
- примерами ожидаемого поведения;
- коротким acceptance checklist для типовых задач;
- контрольными точками качества, если вопрос не в отдельной задаче, а в переходе этапа.