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

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

Методология выбирается руководителем проекта в начале проекта взависимости от целей и ограничений проекта. Что позволяет ему определиться с необходимыми инструментами и принципами для выстраивания производственного процесса. Что приводит к предсказуемому и прогнозируемому результату.

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

• цели и задачи

• требования к результат по итогу выполнения

• команда и её компетенции

• ограничения: сроки, бюджет, состав работ, качество

• ожидания заказчика и заинтересованных сторон

• риски

• индустрия

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

Очень часто, в качестве примера, применяемые методологии сравнивают с рецептом приготовления пищи. Можно пожарить курицу с картошкой на сковородке, а можно запечь в духовке, при этом вкус будет сильно отличаться. А если при этом предварительно курицу замочить в чем–то (например, в соевом соусе) и добавить специй, то вкус будет совершенно другой. Таким образом правильный подбор ингредиентов приведет к разному результату.

В данной статье будут рассмотрены следующие методологии: Waterfall, Agile и Метод критического пути.

Различные методологии отличаются друг от друга следующим параметрами:

• Этапами

• Ролями

• Рабочим процессом (workflow)

• Применяемыми практиками

• Инструментами

• Метриками

Waterfall — методология «водопада» или каскадная модель. Разработана в 1970 г. и является «традиционным» подходом к управлению проектами. Проекты выполняются поэтапно и в последовательном порядке — подобно тому, как водопад течет по скоплению камней. Нельзя переходить к следующему шагу, не закончив текущий. Результат работы демонстрируется заказчику после завершения разработки продукта.

Этапы Waterfall: аналитика (и дизайн), проектирование, разработка, тестирование, эксплуатация (и поддержка).

Agile

Под Agile понимается семейство гибких методологий: Scrum, Scrumban, Kanban, Lean, XP, FDD, TDD, SoS, LeSS, SAFe, AgilePM, которые соответствуют основным принципам agile–манифеста (http://agilemanifesto.org/iso/ru/manifesto.html) и различаются отдельными инструментами и подходами к управлению. Это философия управления проектами, чтобы иметь возможность плавно вносить изменения.

Ценности Agile:

1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с клиентом важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

Отличная инфографика, которая иллюстрирует ценности и принципы Agile:

В agile–проекте основное внимание направлено на получение ценности для клиента. В таких проектах сложные процессы разделены и роли распределены. Что позволяет работать небольшими командами.

В качестве примера одной из гибких методологий семейства Agile рассмотрим Scrum.

Scrum — самая популярная методология ведения проектов из семейства agile. Это итеративная модель разработки. Команда состоит из 7 (плюс–минус 2 человека), работает небольшими фиксированными итерациями — спринтами. Спринт может быть от от одной до четырех недель. Каждый спринт представляет из себя определенный цикл разработки, который включает планирование, аналитику, дизайн, разработку и тестирование. По результату каждой итерации заказчику (или пользователям) демонстрируется результат работы команды, от которого команда получает обратную связь. Новые требования, при необходимости, можно включить в новый цикл.

Роли в Scrum:

• scrum master — обеспечивает выстраивание процессов внутри команды, следил за выполнением принципов Scrum, убирает препятствия для выполнения работы.

• development team — непосредственно команда разработки,

• product owner — либо является сам заказчиком либо общается с заказчиком, а также обзщается с заинтересованными лицами, управляет backlog продукта.

В Scrum существуют следующие артефакты и события:

Kick-off — первая встреча по проекту. На ней руководитель проекта рассказывает про проект, как будет выстроен рабочий процесс, иерархия, обязанность, роли и правила. Бывает внутренний kick-off — встреча команды, внешний kick-off — первая встреча с заказчиком.

Backlog продукта - список желаемых функций продукта. Владелец продукта согласовывает состав каждого спринта и говорит какие фичи он хочет увидеть в следующей версии продукта.

Backlog спринта — список функционала, который надо реализовать в спринте. Разрабатываемые функции набираются из backlog продукта.

Backlog grooming — актуализация backlog. В конце спринта команда и владелец продукта встречаются для актуализации backlog продукта и следующего спринта. Потому что в процессе работы какие–то фичи теряют актуальность, какие–то фичи появились в результате эксплуатации версии продукта и получения обратной связи, задачи из прошлого спринта переносятся в новый в виду того, что команда не успела реализовать в течении предыдущего спринта.

Daily-meeting - это ежедневное 15-минутное совещание, которое проходит в одно и тоже время. Каждый человек в команде должен ответить на 3 вопроса: 1. Что ты сделал вчера? 2. Что ты будешь делать сегодня? 3. Что мешает тебе реализовать задачи, запланированные на сегодня?

Демонстрация — показ разработанного функционала по итогу спринта в виде рабочей версии продукта.

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

Burndown chart — диаграмма сгорания задач, инструмент для контроля выполнения плана. График используется для отслеживания програсса как по спринту, так и проекту в целом.

Метод критического пути

Критический путь — это последовательность действий, которые должны быть выполнены в проекте. Это цепочка действий: без выполнения текущей задачи нельзя приступить к следующей. При сдвиге сроков выполнения одной задачи, то сдвигается срок сдачи всего проекта.

Для построения критического пути необходимо выполнить следующие действия:

1. Определить основные задачи проекта. Составить список всех работ, которые нужно выполнить для завершения проекта. Самое простое это построить иерархическую структуру, на которой проект будет состоить из крупных частей (например, система или эпики), а каждая часть из более мелких частей (фичи).

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

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

4. Оценить время выполнения. Определяется длительность, указывается даты начала и окончания работ по задачам. Это поможет правильно распределить ресурсы и уточнить последовательность выполнения.

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

1. Какую задачу нужно сделать, прежде чем приступить к этой?

2. Что нужно завершить одновременно с этой задачей?

3. Какие задачи следует выполнять сразу после этой?

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

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

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

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

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

Инфраструктурные проекты в IT: менеджер проекта работает с командами для решения связанных с IT проблем внутренней инфраструктуры в компании. Например, проект по установке нового программного обеспечения в компании, обновлению сетей или помощи в развертывании служб облачных вычислений.

Разработка программного обеспечения (ПО): руководитель проектов по программному обеспечению координируют проектные группы для разработки нового ПО и обновлений уже существующего ПО.

Здравоохранение: менеджер проектов в области здравоохранения руководит проектами в медицинских учреждениях. Здесь необходимо хорошо разбираться в законодательстве в области здравоохранения.

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

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

Особенности этапов в методологиях Waterfall и Agile представлены в таблице 1

Таблица 1

Проекты, в которых используется Waterfall:

• Проекты со строгими ограничениями (фиксированный проектный «треугольник»: сроки, бюджет, функционал) и ожиданиями или с очень небольшим количеством ожидаемых изменений.

• Проекты в строительстве, машиностроении, медицине, космонавтике с обширной базой документов (ГОСТ и т.д.), на основе которых сформированы требования. Проекты, где один этап должен быть завершен, прежде чем могут начаться другие, или когда сроки, бюджет, правила или другие факторы требуют, чтобы ваш проект имел предсказуемый результат.

Проекты, в которых используется Agile:

• проекты с высокой степенью неопределенности,

• где необходимо «попробовать идею» или запустить MVP продукта,

• где нет видения конкретного результата.

Проекты, в которых используется Метод критического пути:

• Сложные проекты с большим количеством задач и взаимосвязи друг с другом, при этом часть задач могут быть не связаны. Например, проект по запуску сайта: разработка самого сайта, подготовка контента, разработка дизайна акций и сбор аналитики для будущей рекламы.

Waterfall

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

• Понятный процесс для команды проекта и заказчика.

• Фиксированные сроки и стоимость.

• Планирование проекта от начала и до конца происходит на начальном этапе.

• Основным инструментом планирования является диаграма Гантта, по которой легко показывать динамику проекта.

• Ведется подробная документация.

Недостатки:

• Нельзя вносить изменения — любые корректировки или новые «хотелки» заказчика потребует пересмотр уже выполненных этапов.

• Тестирование производится в конце проекта, поэтому ошибки на ранних этапах приведут к катастрофическим последствиям для проекта в целом.

• Результат проекта доступен только по итогу выполнения проекта.

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

Agile

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

• быстрое реагирование на изменения,

• снижение рисков за счет обратной связи от заказчика или пользователей,

• контролируемое качество разработки,

• управляемый процесс разработки — возможность повышения скорости разработки,

• ориентация на ценность для заказчика/пользователей,

• достижение задач клиента,

• прозрачность для участников.

Недостатки:

• высокая вовлеченность представителей бизнеса,

• участники команды должны быть высокомотивированны и профессиональны,

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

Метод критического пути

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

• Прозрачность и подробность планирования — весь план визуализирован, понятно в каком порядке и какие задачи будут выполнены

• Приоритеты — отображение какая задача более приоритетная

• Минимизация рисков за счет расстановки приоритетов

Недостатки:

• Плохая адаптация к изменениям — для новых задач потребуется пересмотр диаграммы

• Постоянное отслеживание соотнесение возможности выполнения следующих задач с имеющимися ресурсами на данный момент

• Для планирования требуется четкая постановка задачи и большой опыт в управлении

Риск менеджмент план

В PMBOK управление рисками происходит в 4 этапа:

1. Идентификация — выявление рисков.

2. Анализ — преоретизация рисков от более к менее серьезным.

3. Планирование — что будем делать, чтобы риск не случился, а если случится, то план работы с риском.

4. Мониторинг и контроль.

Идентификация рисков

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

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

Анализ рисков

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

Планирование рисков

Для каждого риска формируется стратегия (план А и план Б), которой будет придерживаться менеджер и два плана действий.

Различают несколько основных стратегий работы с рисками:

1. Стратегия передачи. Риск передается либо на сторону заказчика либо на третью сторону (подрядчик, партнер, страховая). Сюда относим риски, на которые мы не можем повлиять и не зависят от нас.

2. Стратегия принятия. Это риски, которые мы не можем передать на сторону и за которые ответственна наша компания. При этом различают пассивное и активное принятие. Активное — резерв времени и денег на устранение последствий рисков, пассивное — еще один план на случай срабатывания риска.

3. Стратегия уклонения. Это исключение риска из проекта. По сути отказ от работ, в связи с которыми могут материализоваться риски.

4. Стратегия снижения. Это уменьшение вероятности наступления рисков.

Мониторинг и контроль

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