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

Бизнес-критичность — это степень влияния данной задачи или требования на функционал целевой системы. Можно выделить следующие уровни бизнес-критичности.

1. Blocker — эта задача стоит на пути у других задач. Например, если вы разрабатываете онлайн магазин, то запилить движок, на котором вы размещаете товары, будет блокером.
2. Сritical — без этой задачи системой невозможно пользоваться. Совсем. Для онлайн магазина кнопка «купить» скорее всего будет критичным функционалом.
3. Major — без этой задачи систему можно запускать, но польза сильно пострадает. В примере с онлайн магазином, это, наверное, «корзина». То есть, купить товар можно, но только по одной штучке со страницы товара. Очень неудобно.
4. Minor — без этой задачи функционал можно запускать. Польза страдает, но не сильно. В примере с онлайн магазином это может быть функционал сравнения товаров.
5. Trivial — это «бантики». Пожелания, которые не влияют на бизнес-функционал. В нашем онлайн-магазине это может быть функционал смены темы в зависимости от национальных праздников. Прикольно, конечно, но можно спокойно пережить.

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

Бизнес-критичность помогает резать скоуп

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

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

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

После этого говорим: «Дорогой заказчик, мы очень хотим принести вам пользу, поэтому мы подписали с вами „джентльменское соглашение“. Но наши ресурсы ограничены, поэтому мы сделаем для вас все задачи критикал и мэйджор, а остальные, сорри, когда вы у нас докупите работ».

Так я сократил объем бэклога примерно на 30%.

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

Да, и не путайте с приоритетом

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