Как скрестить ежа и ужа? Использование PMBoK и scrum в одном проекте

Уж сколько копий сломано по поводу того, какую методологию лучше использовать для управления проектами: PMBoK или agile?

Я решил написать о своем опыте скрещивания PMBoK и scrum для управления одним проектом. Это  значит, что  для управления одним и тем же проектом мы использовали как методы и инструменты из PMBOK,так и ритуалы, роли и артефакты из scrum.

Как вы уже догадались, это был ИТ-проект. Связан он был с внедрением модулей ERP-системы.

Я руководил программой проектов по автоматизации бизнес-процессов компании на базе ERP, которую мы разрабатывали с нуля на платформе 1С 8.2. 

В состав программы входили следующие проекты:

1. Разработка модуля оперативного учета для ключевого сервиса компании
2. Разработка модуля оперативного учета для остальных сервисов компании
3. Разработка модуля управленческого учета
4. Перевод бухгалтерских программ с платформы 1С 7.7 на платформу 1С 8.2
5. Внедрение модулей оперативного и управленческого учета, интеграция с бухгалтерскими программами
6. Развитие модулей оперативного и управленческого учета

До того как я впервые столкнулся с проектом разработки software, для управления проектами я использовал только методы и инструменты PMBoK. 

При руководстве проектом разработки модуля оперативного учета для экспедиторской компании я понял, что инструментов PMBoK мне не хватает, чтобы выстроить результативный процесс разработки продукта. Дело было в 2010 году, и в Интернете уже было полно информации о гибких методологиях разработки. Побывав на конференции руководителей проектов, я понял, что сильно отстал от жизни, т.к. прогрессивные РМ-ы уже давно использовали scrum.

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

Я подумал, что у меня есть шанс попробовать одну из гибких методологий, и проекту от этого хуже не будет. Мы собрались всей немногочисленной командой (на тот момент нас было пятеро), и я рассказал ребятам про scrum. После часовой презентации мы обсудили первые шаги для начала внедрения: надо было создать product-backlog, решить, кто будет scrum-master, а кто – product owner, определиться с длиной спринта и найти какой-нибудь тул для автоматизации управления тремя артефактами scrum.

Первые три проекта к этому моменту уже завершались, и мы собирались сдавать работающие продукты заказчику проекта. Следующим на очереди был проект внедрения разработанных модулей. В этом проекте мы должны были перевести 5 офисов компании на работу в новой информационной системе с полным отказом от старой системы. Продукты проекта: работающая информационная система с отлаженными шлюзами и с перенесенными данными из старой учетной системы, обученные пользователи, отчеты с верифицированными данными, политики и процедуры, необходимые для работы информационной системы. Для управления пакетом работ «работающий программный продукт с перенесенными данными из старой системы» мы и решили использовать scrum. Общее управление проектом я решил организовать с помощью PMBoK, в частности, использовались Устав проекта, модель проекта в MS Project, реестр рисков проекта, план антирисковых мероприятий и т.д.

Описывать использование PMBoK в этой статье не буду. Хочу рассказать о том, как мы внедряли scrum. Роль scrum-master я взял на себя, ибо как руководителю проекта мне эта роль показалась наиболее близкой по роду деятельности ) Роль владельца продукта мы поручили нашему бизнес-аналитику, который работал на фрилансе. Для автоматизации работы с артефактами мы выбрали Jira и плагин GreenHopper. Надо заметить, что наш ИТ-отдел (отвечавший за всю «железячную» часть и работу всего софта, кроме 1С) сразу ответил нам отказом на просьбу взять на поддержку сервис Jira. Поэтому нам пришлось администрировать его своими силами. Мы прожили с Jira большую половину проекта, однако в середине проекта нас покинул один из ключевых разработчиков, который администрировал Jira, и мы решили поискать облачное решение. Проанализировав пять облачных сервисов, мы остановили свой выбор на облачном решении от devprom. С этим решением мы и завершили проект, на нем же был сделан еще один проект по scrum. Через год после начала использования этого продукта мы написали собственное решение на базе 1С 8.2 для управления проектами по scrum и автоматизации процессов поддержки программного продукта по ITIL. Сейчас пользователи ERP могут публиковать пожелания прямо в модуле, в котором они работают, а оттуда они автоматически затягиваются в модуль управления проектами в бэклог продукта. Это жутко удобно и экономит кучу времени, которое требовалось на обработку пожеланий из e-mail и других электронных источников. В этом же модуле ведется работа с бэклогами, планированием и контролем спринтов, инцидентами и проблемами, учет релизов и конфигураций.

В процессе написания этой заметки я открыл записи по первым спринтам и понял, что на тот момент я не мог понять, как правильно считать focus factor. Сейчас это смешно, но мне понадобилось время, чтобы разобраться с этим вопросом :) Ну и Бог с ним, зато в отчете по первой ретроспективе ребята отметили, что процесс разработки после внедрения scrum стал «более систематизированным».

Что у нас не сразу получилось при внедрении scrum?

Первое – это роль владельца продукта, которую привлеченный бизнес-аналитик в полной мере выполнять не мог. Для него оказалось трудным выстроить работу по приоритезации требований с привлечением представителей бизнеса. К тому же он ленился принимать результаты спринтов. Мне пришлось взять на себя роль владельца продукта, но через какое-то время я понял, что быть одновременно scrum-master и product owner довольно сложно – нужно при планировании спринта каждый раз спрашивать себя: кто ты сейчас, скрам-мастер или владелец продукта? Тебе нужно больше функционала запихать в спринт или спланировать его так, чтобы взятые командой обязательства были реальны? С этими противоречиями можно жить, но на их решение уходит энергия. Через какое-то время мы предложили роль владельца продукта руководителю одного из филиалов компании, и она согласилась. Решения по приоритетам пожеланий принимались чаще всего коллегиально на совещании ТОПов, но ответственность за наличие приоритетов нес владелец продукта. Правда, у него так же, как и у бизнес-аналитика, не было времени на приемку работ и обычно эта работа делегировалась кому-то из подчиненных.

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

Третье – это ретроспективы. Если в проекте внедрения мы проводили их не после каждого спринта, то на этапе промышленной эксплуатации они вошли в нашу жизнь легко и непринужденно. Каждый месяц мы подводили итоги по нашим KPI и обсуждали, что нужно сделать, чтобы улучшить их значения. Обсуждения заканчивались протоколом со списком задач и ответственными, capacity спринта при этом урезалось на время, необходимое для реализации задач, связанных с улучшением наших процессов и KPI.

Как мне кажется, опыт скрещивания ежа и ужа был удачный. Я планирую продолжать микшировать PMBoK и scrum на проектах, где это будет уместно. И я собираюсь практиковать другие методологии и фреймворки управления проектами, когда придет время и будет повод.