Как выбрать метод управления проектом: классический подход или Agile

Классическое управление по PMI

Классическое управление ИТ-проектом по PMI (Project Management Institute) ставит перед командой две задачи:

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

Процесс выглядит так. Менеджер проекта (project manager, ПМ, руководитель проекта) еще до старта работ договаривается с заказчиком об основных целях и ограничениях, фиксирует их в уставе и следит за тем, чтобы планы не выходили за ограничения. Он же управляет рисками и устраняет все препятствия, чтобы выполнить все задачи в срок.

После формирования устава ПМ вместе с командой собирает требования от основных заинтересованных лиц, анализирует, оценивает реализацию задач и затем распределяет их на этапы, формирует гибкие планы и уточняет их на протяжении всего проекта.

Экономика образования Управление проектами – что это и как научиться

Преимущества

• Фиксация требований на старте и стабильность содержания проекта.
• Предсказуемость процесса разработки. Качественная проработка требований и видения продукта на ранних стадиях проекта позволяет сэкономить время и силы на исправлении недочетов и решении проблем в дальнейшем.

Подводные камни/риски

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

Классическое управление по PMI можно использовать, когда:

• заинтересованные лица имеют четкое видение результата — конечный продукт;
• составлено подробное техническое задание на разработку;
• есть жесткие ограничения по сроку и бюджету проекта;
• реализация проекта предполагается по формату договора fixed price.

Это могут быть проекты:

• доработки существующей системы по готовому техническому заданию;
• проекты с четко установленными требованиями.

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

Гибкие методологии Agile: Scrum и Kanban

Главные цели Agile-подходов

• Ценность. Любая работа в Agile должна нести ценность для конечного пользователя.
• Скорость проверки ценности. Основной смысл гибкости — возможность проверки ценности за минимальные сроки.

Преимущества

• Быстрый жизненный цикл разработки.
• Гибкость в принятии решений для улучшения итогового продукта.
• Регулярное получение обратной связи от заинтересованных сторон открывает возможность вносить корректировки в реализацию проекта или в функциональность разрабатываемого продукта.

Подводные камни/риски

• Отсутствие четкого плана затрудняет управление ресурсами и планирование.
• Все заинтересованные стороны должны работать в тесном сотрудничестве, чтобы каждый знал об изменениях, задачах и их актуальности.
• Предъявляются более высокие требования к команде.

Гибкие методологии работают, когда:

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

Наиболее популярные методы работы/подходы к управлению в философии Agile: Scrum и Kanban.

Scrum

Основа работы по scrum — спринты длительностью от одной недели до месяца, в рамках которых команда обязуется взять приоритизированный набор задач из бэклога и создать инкремент (работоспособную часть ИТ-продукта, которая будет нести определенную ценность). По завершению спринта команда презентует результаты основным стейкхолдерам и владельцу продукта, после чего они все вместе принимают решение о дальнейших шагах.

Экономика образования Что такое Scrum и как правильно использовать его в рабочем процессе

Сам процесс изображен на рисунке.

Фото: scrumtrek.ru

Преимущества

• Удовлетворенность конечного пользователя — главное, а значит есть высокие шансы создать востребованный у целевой аудитории ИТ-продукт.
• Если у кого-то из членов команды возникнет проблема и он об этом сообщит на еженедельной планерке или ретроспективе, команда приложит все усилия, чтобы помочь ему и реализовать спринт в срок.
• Scrum предоставляет возможность быстрого тестирования гипотез.

Подводные камни

• Этот подход не признает ограничений: формируется видение продукта, и все участники идут к его реализации.
• Каждый участник должен быть «командным игроком», активно брать на себя ответственность и уметь самоорганизовываться. За понимание ценностей этого подхода ответственен scrum-мастер. Он может взрастить самоорганизованную команду, но на это потребуется определенное время.
• Scrum не предоставляет возможности на старте проекта определить стоимость, сроки и содержание. На старте можно сказать, сколько будет стоить первый спринт и что в рамках него будет сделано. Но в процессе реализации собираются определенные метрики, позволяющие ретроспективно измерить производительность, мощность и количество работы, которую команда может реализовать за спринт. Исходя из этого, можно оценить скорость работы на 3–4 спринта вперед и спрогнозировать сроки.

Scrum можно использовать для:

• управления крупными проектами и опытной командой, которая умеет расставлять приоритеты и имеет четкое представление о требованиях проекта;
• проектов по разработке сложных программных продуктов в условиях частого изменения требований;
• проектов по созданию ИТ-продукта, нацеленного на пользователя.

Kanban

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

Экономика образования Что такое канбан и как не «похоронить» проект в Trello

Преимущества

• Его можно адаптировать под конкретные процессы. Между to-do и done могут быть разные колонки, команда может их определять самостоятельно и строить процесс так, как ей удобно.
• Быстрая поставка ценности. В Scrum команда «заливает» фичи на production только в конце спринта, в Kanban — после приемки тестировщиком, как правило, раз в несколько дней. Это позволяет быстрее узнать, «зашла» фича пользователям или нет. Если нет, можно найти ошибку и понять, как ее решить.
• Этот метод ограничивает количество задач, над которыми команда может работать в один момент времени. Здесь виден прогресс и минимизируются застои. Все это позволяет сокращать время работы над задачей и повышать качество результата.

Подводные камни

• Если не соблюдать основные принципы и игнорировать ограничения, есть риск скатиться в хаос, тогда предстоит выполнить много ненужных усилий.
• Метод рассчитан на достижение краткосрочных целей. Работа выстраивается на решении актуальных задач. Их приоритет может корректироваться под воздействием обстоятельств.

Kanban можно использовать для:

• узкопрофильных команд;
• реализации конкретных задач по проектам, которые требуют улучшений;
• доработки уже выпущенного в пользование продукта.

Узнайте, как привести проект к успеху, на курсе от ProductStar

Какой метод выбрать для управления проектом

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

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

Фото: Руководство к своду знаний по управлению проектами PMBOK

Как выбрать метод

• Ситуация № 1. Низкая неопределенность требований и низкая техническая неопределенность.

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

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

Пример проекта: разработка ИТ-системы на основе коробочного решения с минимальными изменениями доступного из коробки функционала.

• Ситуация № 2. Средняя неопределенность требований и средняя техническая неопределенность

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

В таких случаях для управления проектом подойдут гибкие Agile-подходы. Работа итерациями и создание определенного рабочего инкремента позволяет на ранних стадиях обкатать продукт и своевременно внести корректировки. Опыт многих команд показывает: такой подход позволяет сократить объемы потерь и доработок, поскольку команда получает регулярную обратную связь.

Пример проекта: разработка корпоративного сайта.

• Ситуация № 3. Высокая неопределенность требований и высокая техническая неопределенность

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

Другой вариант — стартовать по концепции Lean Startup. Она позволяет с минимальными вложениями протестировать гипотезу: создать прототип, собрать обратную связь от пользователей, определить, интересен ли продукт целевой аудитории, и наметить план его развития.

Пример проекта: создание приложения для мобильного устройства с блоком считывателя радиосигналов. Главная фича — распознавание размеров и других параметров объекта по фотографии, сделанной устройством. В ходе предпроектного исследования удалось проверить гипотезу о возможности внедрения алгоритма machine learning в приложение и протестировать функционал считывания радиосигналов в полевых условиях. Команда убедилась, что задача имеет понятное техническое решение, тем самым снизила уровень технической неопределенности.

Как показывает наша практика, при выборе метода управления проектом стоит обратить внимание на:

• тип оплаты по договору: по гибким методам, особенно по Scrum, можно работать по Time&Material, то есть проводить оплату проекта по факту отработанных часов;
• роли и состав команды;
• жесткие дедлайны;
• пожелания клиента.