Каталог решений - Приоритизировали, приоритизировали, да не выприоритизировали…

Итак, выдыхаю после конференции Infostart Event-2018 и продолжаю свой цикл статей про Agile. Меня, кстати, можно поздравить с получением сертификата PMI-ACP (Agile Certified Practitioner). Так что в своей статье опираюсь не только на свой опыт знакомства с различными проектами автоматизации и не только, но и на опыт, так сказать, мировых экспертов по проектным управлениям. Хочу сказать, что благодарна полученному обучению и подготовке — позволяет сложить картинку, что же такое этот Agile, и с чем его едят — как в проектах автоматизации, так и в разных других отраслях.  

Но это было лирическое отступление. А сегодня хочу остановиться на первом из двенадцати принципов Agile манифеста:

“Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения”.

И как раз вот здесь кроется одно из кардинальных отличий гибких методологий от “классического” подхода к проектному управлению — фокус внимания на том, чтобы поставить заказчику максимальную ценность. За счет чего это возможно?…

Шаг 1. Исполнитель замотивирован на выдачу  ценности максимально быстро

Важно, что обе стороны (и заказчик и исполнитель) должны быть готовы действовать в парадигме Win-Win (выиграл-выиграл) — то есть, чтобы один участник получил максимально подходящий продукт, а другой — достойную оплату за оказанные услуги. А не в более привычной Win-Lose (выиграл-проиграл) — когда каждый пытается прогнуть партнера на максимально выгодные для себя условия. По моему опыту, не все компании на рынке готовы к такому стилю сотрудничества. Но их число неуклонно повышается, повышая тем самым применимость Agile. И, с другой стороны, при внутренних проектах автоматизации атмосфера сотрудничества между бизнесом и ИТ-подразделениями встречается всё чаще — с чем, вероятно, и связан тот факт, что я знаю куда больше успешных применений “фреймворков подобных Scrum” именно во внутренних проектах внедрения.

Шаг 2. Собираем требования понятным заказчику способом — в виде пользовательских историй

Итак, за счет чего мы можем дать максимальную ценность? Нам, очевидно, нужно требования собрать,  и дальше требования приоритизировать.
Собирать требования Agile рекомендует в виде так называемых “User stories” — пользовательских историй — сценариев пользовательского поведения на деловом языке пользователя, которые система должна позволять реализовать, и которые сразу дополняются критериями приемки.
Классическая формулировка user story выглядит следующим образом:

As ____________ I want/have to _____________ so that ________________

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

Чем удобен формат user story? Их просто сформулировать пользователю, и сразу понятно как проверять их на выходе.
В моей практике часто бывает не просто строго выдерживать именно вот такой формат. Но попытка перейти на пользовательский язык сама по себе облегчает коммуникацию между заказчиком и исполнителем.

Шаг 3. Приоритизируем требования

Мы помним, что Agile предполагает много маленьких релизов. Поэтому в первый релиз войдут не все фичи, а только самые важные. Каким образом можно их приоритизировать? Есть разные подходы:

Простые схемы приоритизации.

Самые распространенные на практике. Мы просто присваиваем фичам приоритеты, например, по трехбалльной шкале: высокий, средний, низкий.
Что здесь важно: без четких критериев, что именно мы считаем “высоким” приоритетом, мы очень быстро скатимся к тому, что практически все фичи будут получать самый “высокий” приоритет, и система потеряет свой смысл. Как, например, потеряет свой смысл идея спец. транспорта, с проблесковыми маячками и с сиренами будут все машины на дороге. 

Приоритизация MoSCoW (привет жителям нерезиновой из северной столицы!)

Пользователям предлагается разделить заявленные фичи по тому, насколько они необходимы:
Must, Should, Could, Would like to have but not this time… 

Что здесь важно: важно не путать вещи, без которых система не будет работать технически, и вещи, которые “очень хочется” высшему руководству. Попытка запихать все задачи из серии “очень хочется” в категорию “Must” приводит к потере смысла всей нашей приоритизации.

Метод 100% 

По этому подходу каждому из ключевых заинтересованных лиц предлагается распределить 100% между полным функционалом разрабатываемой информационной системы — какие вы считаете наиболее важными, а какие — менее важными. На выходе наглядно видим, какой функционал является ключевым, а какой не столь обязательным. 
Что здесь важно: также, как и в других подходах к расстановке приоритетов, заказчики и пользователи часто находятся в ловушке своего искаженного восприятия. Они искренне считают, что знают, чего именно хотят до тех пор, пока мы не даем им именно то, о чем они попросили. Именно поэтому мы обращаем внимание на слова из Agile принципа “благодаря регулярной и ранней поставке ценного программного обеспечения…” — то есть мы как можно раньше делаем прототипы или частичные поставки, чтобы пользователи могли попробовать на практике, что же они попросили сделать-то. 

Анализ Кано

Анализ Кано по моему опыту больше подходит для маркетинговых исследований, чем для проектов автоматизации, но технически его вполне можно применять и при уточнении требований при внедрении.
Суть анализа — мы делим все потенциальные функции продукта на несколько категорий:
Threshold — Обязательные — без них продукт категорически не устраивает пользователя
Satisfiers — Ожидаемые добавление данных функций дает линейный рост удовлетворенности — чем больше функций, тем выше удовлетворенность пользователей
Exciters — Вызывающие восхищение — характеристики, превышающие ожидания клиента

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

1. Как вы отнесетесь к НАЛИЧИЮ этой функции у продукта?
2. Как вы отнесетесь к ОТСУТСТВИЮ этой функции у продукта?

На каждый вопрос можно дать несколько вариантов ответа:

• Мне нравится
• Я этого ожидаю
• Мне все равно
• Я могу с этим работать
• Мне не нравится

И в зависимости от ответов мы смотрим, к какой категории относится та или иная функция.

Шаг 4. Грамотно распределяем требования между релизами

Итак, мы так или иначе приоритизировали наши функции/наши пользовательские истории.
Что же мы теперь с ними делаем?
Мы определяем последовательность релизов. 
Самый минимальный набор функционала, без которого всё не будет работать — это “хребет проекта”
Минимальный осмысленный набор, включающий в себя ключевые функции, без которых и смысла не было затевать — это “ходячий скелет проекта”
А дальше уже проект будет обрастать “мясом”, которое войдет в следующие релизы…
 

Понятно, что полноценный Agile у нас возможен в первую очередь тогда, когда "хребет" и "ходячий скелет" относительно небольшие. Поскольку в крупных проектах внедрения, допустим, ERP-системы, может оказаться, что функции из категории Must будут разрабатываться больше года. Тогда нам может помочь прототипирование, шины для интеграции промежуточных результатов с работающими в настоящий момент продуктами и т. п. Но в любом случае, грамотная приоритизация позволит убедительнее ответить на запрос бизнеса "сделать всё и сразу"  фразой, вынесенной в анонс статьи — "сделаем сразу, но не всё" .  

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

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах