Как понять, какая модель жизненного цикла проекта даст наибольший эффект для конкретного проекта?

 
Рубрика:
Интересная информация
Направление:
Менеджмент
В избранное
Удалить из избранного
img
Максим Якубович
Директор по проектам компании КейТуБи. Бизнес-консультант.

За последний год меня часто спрашивали о том, как понять, даст ли использование одного из Agile-подходов какую-то выгоду для конкретного проекта.

Для того, чтобы ответить на этот вопрос, я предлагаю использовать формальную модель, предложенную PMI. Модель эта называется Agile Suitability Model. Почему я предлагаю использовать именно ее? На своих тренингах по управлению проектами я уже много раз делал с группами практические задания на тему выбора подхода к управлению конкретными проектами с помощью этой модели и убедился в ее простоте с точки зрения понимания аудиторией.

Итак, вам нужно понять, стоит ли использовать, например, Scrum, для проекта, на который вас назначили ответственным со стороны команды исполнителей.

В первую очередь, Вам надо запланировать совещание, на которое стоит пригласить Заказчика проекта, Спонсора проекта (если он есть у проекта), и пару человек из команды исполнителей.

Также стоит заранее предупредить участников, что совещание займет около 1 часа, к нему нужно распечатать диаграмму, приведенную ниже, и раздать ее каждому участнику:

11 (1).png

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

В ходе совещания модератор задает следующие вопросы:

Поддержка: Как вы считаете, поддерживает ли спонсор проекта (куратор) применение Scrum на данном проекте?

Если на совещании присутствует спонсор проекта, то он и отвечает на этот вопрос. Если ответ Да, то ставим 1 балл, если Нет, ставим 10 баллов, если ответ примерно такой: «не уверен, что Scrum нам поможет» , то ставим 5. Между 1 и 5, 5 и 10, есть другие цифры и спонсор может выбрать любую из них:

12.png

Доверие: Считают ли представители Заказчика, что команда сможет трансформировать их видение и потребности в продукт или услугу – при их поддержке и постоянной обратной связи?

Например, если группа считает, что команда 100% сможет создать продукт без разработки детальных ТЗ, но с использованием устных обсуждений требований и формулирования User Story, то ставим 1. Если есть сомнения, но вероятность оценивается от 90% до 10%, то ставим балл от 2 до 9, и, если группа уверена, что команда не сможет получить результат без письменной работы с требованиями, ставим 10.

доверие.png

Решения: Будет ли у команды автономия в принятии локальных решений по выполнению работы в проекте?

Если оценщики уверены в том, что владелец продукта отдаст принятие технических решений по поводу реализации требований команде, ставим 1, если есть сомнения, но вероятность оценивается от 90% до 10%, то ставим балл от 2 до 9, и, если группа уверена, что команда не сможет получить автономию в принятии технических решений, ставим 10.

решения.png

Далее группа отвечает на три вопроса, связанных с командой:

Размер команды: Оцените размер основной команды проекта по следующей шкале:
1-9 = 1; 10-20 = 2; 21-30 = 3; 31-45 = 4; 46-60 = 5; 61-80 = 6; 81-110 = 7; 111-150 = 8; 151 – 200 = 9; 201+ = 10.

Тут все однозначно, и неверную оценку поставить почти невозможно

даднн.png

Опыт: Рассмотрите опыт и навыки ключевых ролей в команде. Есть ли в команде по одному опытному члену команды на каждую роль?

Если в команде есть опытный Product Owner, реализовавший хотя бы 2 проекта в этой роли, Scrum master с опытом работы в 2-3 проектах в этой роли, и каждый участник команды участвовал хотя бы в 2-х проектах, использовавших Scrum, ставим 1.

Если хотя бы у одной роли отсутствует опытный участник, ставим 5 или оценку рядом. И если нет ни одного опытного участника – ставим 10.

опыт.png

Доступ: Будет ли у команды ежедневный доступ хотя бы к одному представителю заказчика/бизнеса для получения обратной связи и ответов на вопросы?

Группа оценивает, сможет ли Product owner отвечать день в день на вопросы команды разработки? Если да – ставим 1, если есть сомнения, ставим от 2 до 9, и, если есть уверенность, что нет – ставим 10.

доступ.png

И последний набор вопросов связан непосредственно с самим проектом.

Изменения: Какой процент требований возможно будет меняться каждый месяц?

Участники прогнозируют, какая доля из первоначально сформулированных требований к продукту проекта может измениться по ходу реализации проекта.  Если есть предположение, что более 50 % – ставим 1, если около 25% - ставим 5. Остальные оценки ставим исходя из того, что каждые 5% изменений – это оценка в плюс 1 балл. Например, для прогноза о том, что изменится 45 процентов требований, оценка будет 2.

изменения.png

Критичность: Рассмотрите потери, которые могут возникнуть из-за дефектов, определите, чем может закончиться провал.

Это самый сложный вопрос в третьем сете. Если группа предполагает, что в результате ошибки в работающей версии продукта могут погибнуть люди, ставим 10. Если погибнуть может 1 человек – ставим 6. Если ошибка приведет к потере большой суммы денег, ставим 5, и если ошибка приведет только к тому, что надо потратить десяток часов разработчиков на ее исправление – ставим 1.

криточность.png

Поставка: Может ли продукт разрабатываться и оцениваться по частям? Смогут ли представители заказчика/бизнеса своевременно давать обратную связь по инкрементам?

Тут все просто. Если вы оцениваете, что продукт моно разрабатывать небольшими кусочками, а затем эти части соединять как в конструкторе Lego, то ставим 1, если соединять можно, но сложнее, чем в конструкторе, ставим от 2 до 5. Если же оценщики считают, что разрабатывать инкрементами продукт почти невозможно (как, например, шампунь), то ставится оценка 10.

потсавка.png

После того, как все оценки нанесены на диаграмму, мы получаем некоторый профиль проекта.

Например, такой:

555.png

Для данного проекта я бы однозначно не рекомендовал использовать Scrum. Для него лучше использовать гибридную модель жизненного цикла (ЖЦ) проекта, так как 5 точек из 9ти находятся в области гибридной модели, 3 - в области предиктивной модели ЖЦ и лишь одна попала в круг Agile.

Вот такая довольно простая, но полезная модель для выбора подхода к жизненному циклу проекта. Ну, а выбор конкретной методологии после выбора модели жизненного цикла проекта, это уже вопрос другой статьи.

Удачи вам в выборе правильных моделей ЖЦ проектов!

__________________

А о том, как планировать адекватные сроки и бюджет проекта, организовать управление проектом и вносить изменения в ходе проекта, Максим будет рассказывать на своем курсе "Реализация проектов в срок и в бюджет", который стартует 22 июня. Подробнее

Другие статьи эксперта

Другие статьи по теме

Статьи
26-07-2020
Разработка стратегии развития предприятия
Статьи
15-06-2020
Разработка конкурентной стратегии предприятия
Статьи
20-05-2020
Этапы жизненного цикла организации по методологии Ицхака Адизеса
Статьи
10-05-2020
Как повысить цену для потребителей? 8 способов сделать это незаметно
Статьи
02-07-2020
43% — это много или мало?». Как посчитать и увеличить конверсию в рознице
img Виталий Сафронов
Статьи
20-07-2020
Бизнес-план: цели, задачи и основные этапы планирования
Статьи
29-06-2020
Корпоративные метаморфозы: опыт внедрения методологии Адизеса
Интервью
10-08-2020
Главное — "выдавливайте" скидки у поставщиков. Очень вредные советы для закупщиков
img Наталья Дешко
Статьи
22-09-2020
Чем больше тумана, тем легче уходить от ответственности - 5 признаков слабого руководителя
img Вероника Коппек
Статьи
16-10-2020
10 вредных советов по мотивации сотрудников от Вероники Коппек
img Вероника Коппек
25
Лет опыта в бизнес-образовании
700
Выполненных проектов в консалтинге
90%
Клиентов обращаются к нам повторно
+100
Корпоративных проектов ежегодно
>55k
Слушателей