Итак, выдыхаю после конференции 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 - Вызывающие восхищение - характеристики, превышающие ожидания клиента
Как проводится анализ?
Мы опрашиваем заказчиков и потенциальных пользователей продукта про интересующие нас функции.
- Как вы отнесетесь к НАЛИЧИЮ этой функции у продукта?
- Как вы отнесетесь к ОТСУТСТВИЮ этой функции у продукта?
На каждый вопрос можно дать несколько вариантов ответа:
- Мне нравится
- Я этого ожидаю
- Мне все равно
- Я могу с этим работать
- Мне не нравится
И в зависимости от ответов мы смотрим, к какой категории относится та или иная функция.
Шаг 4. Грамотно распределяем требования между релизами
Итак, мы так или иначе приоритизировали наши функции/наши пользовательские истории.
Что же мы теперь с ними делаем?
Мы определяем последовательность релизов.
Самый минимальный набор функционала, без которого всё не будет работать - это “хребет проекта”
Минимальный осмысленный набор, включающий в себя ключевые функции, без которых и смысла не было затевать - это “ходячий скелет проекта”
А дальше уже проект будет обрастать “мясом”, которое войдет в следующие релизы...
Понятно, что полноценный Agile у нас возможен в первую очередь тогда, когда "хребет" и "ходячий скелет" относительно небольшие. Поскольку в крупных проектах внедрения, допустим, ERP-системы, может оказаться, что функции из категории Must будут разрабатываться больше года. Тогда нам может помочь прототипирование, шины для интеграции промежуточных результатов с работающими в настоящий момент продуктами и т. п. Но в любом случае, грамотная приоритизация позволит убедительнее ответить на запрос бизнеса "сделать всё и сразу" фразой, вынесенной в анонс статьи - "сделаем сразу, но не всё" .
Коллеги, интересен ваш опыт. Как вы обычно обходитесь с требованиями пользователей? Какие подходы работают, какие - нет?
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
