Agile PMO: эффективный и ценностно ориентированный Проектный офис
14 Сен 2015
За последние два десятилетия было разработано и опробовано множество различных гибких методологий и подходов. Из них в последние 5 лет наибольшую популярность заслужила методология Scrum, благодаря простоте в использовании, удобстве и эффективному продвижению методологии. Успех методики Scrum в области разработки софта привёл к заимствованию и использованию методики в других отраслях. К сожалению, большинство из организаций за пределами ИТ-отрасли просто не приспособлены к использованию гибких методологий. Более того, в своей изначальной форме Scrum вообще не подходит для некоторых организаций.
Концепция Agile-Scrum слишком привлекательна, чтобы её игнорировать. Но для внедрения за пределами ИТ-индустрии её необходимо адаптировать.
Комплексные сценарии для Agile
Основное препятствие для достижения выгод от Agile-Scrum в отраслях и компаниях, не связанных с ИТ, состоит в том, чтобы интегрировать методику в уже существующую вертикальную систему контроля. Эта система абсолютно естественна и нормальна для организаций с классической «водопадной» методологией. Авторы статьи выделяют 4 типа организационных предпосылок и ситуаций, затрудняющих внедрение Agile:
- Глобальные корпорации. В этих иерархических матричных организациях система контроля работы портфеля «сверху-вниз» укоренилась очень прочно и глубоко. Гибким «свободолюбивым» методикам будет очень сложно реализовать себя в таких жёстких рамках. Особенно сложным моментом для адаптации для таких организации является отсутствие планирования в Agile в классическом его понимании.
- Сильно зарегулированные организации. В некоторых отраслях уровень стандартизации и госрегулирования выше, чем в других. К таким отраслям относится фармацевтика, аэрокосмическая отрасль или производство медицинского оборудования. В таких организациях отдельные команды разработчиков могут применять методики Agile-Scrum, но весь общий процесс должен строится по «водопадной» методологии, для того чтобы можно было его отслеживать, контролировать и вовремя формировать необходимую отчётность.
- Разработка комплексных продуктов с жёсткими требованиями. Разработка сложных интегрированных продуктов, включающих множество различных компонентов, как физических, так и программных, зачастую производится по жёстким предопределённым требованиям заказчика. В таких продуктах пространство для манёвра выше, чем в описанных ранее случаях, но оно всё равно невелико.
- ИТ-департаменты в организациях. Задача таких подразделений в поддержке функционирования организации в областях, связанных с информационными технологиями. Постоянные изменения в расписании, связанные с решением неожиданных проблем – нормальная практика для этих подразделений. Реализация принципа фиксированных итераций (time boxing) и невмешательства в работу команды в таких условиях практически невозможна.
На практике часто встречается комбинация описанных выше предпосылок, что ещё сильнее усложняет внедрение методологии Agile. Например, несложно представить себе глобальную корпорацию, занимающуюся разработкой комплексных продуктов в зарегулированной отрасли.
Один из возможных путей решения данной проблемы с учётом описанных выше сценариев – создание Проектного офиса (Agile PMO), который будет посредником между независимыми Agile командами и остальной организацией, работающей по классической водопадной методологии.
В таблице 1 приведены сценарии для создания и организации работы подобного офиса для каждого из описанных сценариев.
Таблица 1: Проектный офис Agile – путь к гибридной организации
| Сценарий | Проблема | Возможное решение | Комментарии | Советы |
| Большая глобальная корпорация | Жёсткий контроль работы проектов, применение «водопадной» методики; | Проектный офис, который станет буфером между командой и организацией; | Основной задачей офиса станет подготовка отчётности необходимой формы. Перевод документации в необходимый компании формат, а также оценка выполнения плана; | Владелец продукта может быть членом Проектного офиса; Процесс инициации и закрытия проекта можно передать Проектному офису; |
| Сильно зарегулированные отрасли | Строгий контроль и необходимость документации всего, включая риски продукта; | Административный Проектный офис, занимающийся документацией; | Управление рисками продукта, основанными на жизненном цикле, проводится вместе с командой проекта В журнал продукта добавляются нефункциональные данные, требуемые для контроля и отчётности. Его ведёт Проектный офис Персонал Проектного офиса отслеживает соответствие продукта требованиям; | Административные функции Проектного офиса позволяют команде проекта действовать гибче; Административный персонал Проектного офиса может также выступать в качестве дополнительного владельца продукта, чтобы отслеживать соответствие требованиям; |
| Разработка комплексных продуктов с жёсткими требованиями | Гибкость ограничена описанием продукта (product scope) не даёт реализовать гибкие принципы Agile. Разработка аппаратного обеспечения также не всегда укладывается в философию Agile; | Проектный офис ведёт журнал продукта, взаимодействуя с различными компонентами продукта. Основная цель – поддержка гибридного процесса разработки Agile и традиционного линейного; | Наиболее сложный из перечисленных сценариев. Для успешной реализации необходим широкий набор технических и административных компетенций, а также лидерство. Практика показывает, что при креативном подходе даже в «жёстких» продуктах применение Agile возможно. Жёсткие требования обычно допускают изменения показателей в рамках 20%; | Максимум ценности при таком сценарии в разработке индивидуального гибридного подхода; Итеративный подход позволит повысить гибкость процесса разработки, однако это не всегда возможно; |
| ИТ-департаменты в организациях | Постоянные изменения в плане работ, затруднение планирования из-за частых экстренных задач; Отсутствие настоящего владельца продукта; | Проектный офис берёт на себя роль владельца продукта — собирает заявки от функциональных подразделений, планируя работу и распределяя нагрузку команд; | Многие ИТ-департаменты разочаровались в Agile. Неудачные попытки применения методологии привели к изматыванию команд и формированию у них образа Agile как манипуляцией командами ради повышения производительности без реальной административной поддержки; | Для таких условий лучше подходит Kanban; Итеративная схема работы может дать положительный результат, однако необходимо внедрить определённый буфер для экстренных задач в каждом спринте; Длина спринта может меняться; |
Чтобы решить ситуацию в течение двух лет с переменным успехом предпринимались внедрить у себя Scrum. Они инвестировали в обучение и развитие персонала, однако совместить Scrum с портфельным управлением и отчётностью никак не удавалось. Результатом этого стал отрыв Scrum-команд от остальной организации и стратегических целей. Также Scrum-команды, занимавшиеся в основном разработкой программного обеспечения были оторваны и практически не взаимодействовали с подразделениями, разрабатывавшими само оборудование, что сказывалось на качестве конечного продукта и вызывало необходимость переделывать код. Это приводило к упомянутым проблемам – отставанию по срокам и перерасходу бюджета.С частью описанных сценариев авторам статьи пришлось столкнуться во время работы с глобальной компанией, занимающейся разработкой мобильных технологий. Их продукты разрабатывались с отставанием по срокам, с перерасходом бюджета и не соответствовали изначальным требованиям. Это частое явление для многих компаний-разработчиков.
Опыт создания Проектного офиса Agile
Авторы статьи, выступавшие в качестве консультантов, для решения проблемы организовали совещание, на котором собрали шестнадцать стейкхолдеров: владельцев продуктов и проектных менеджеров. По их словам, аудиторию, где все собрались, разделяла невидимая, но ощутимая стена, отделявшая владельцев продуктов и Scrum-мастеров от проектных менеджеров и членов Проектного офиса. Во время встречи, каждая группа критиковала другую и обвиняла во всех проблемах. Члены Scrum-команд обвиняли «традиционалов» во вмешательстве в их работу: изменении требований, переводе людей из команды проекта, изменении процесса контроля, а также в появлении на ежедневных встречах команды и обвинении их в не достижении результатов. Проектные менеджеры и члены Проектного офиса, в свою очередь, винили «Scrum-фанатиков», в срывах сроков, неготовности к изменениям, отсутствии прогресса и отчётов о состоянии проекта.
Для того, чтобы реализовать интеграцию методов необходимо было сперва создать атмосферу доверия для проведения изменений. Сначала был найден лидер в Проектном офисе, которого признавали и которому доверяли члены обеих групп. Вместе с ним был разработан план изменений. Он включал в себя ряд задач.
Во-первых, необходимо было увеличить прозрачность и измеримость еженедельных достижений Scrum-команд и защитить их от вмешательства во время спринтов. Во-вторых, решено было увеличить адаптивность и продолжительность спринтов для синхронизации и интеграции с процессом разработки аппаратного обеспечения. Это решение вызвало негативный отклик со стороны лидеров Scrum-команд, однако, в таком процессе угодить всем невозможно. Защита от вмешательства вызвала недовольство со стороны «традиционалов». Они боялись потерять контроль над проектом.
После того, как эти изменения были внедрены, авторы проекта, вместе с руководителем Проектного офиса наладили процесс формирования отчётности по проектам Проектным офисом. Для этого необходимо было перевести документацию Agile-Scrum в форму, используемую всей остальной организацией: диаграммы сгорания, пользовательские истории, и журнал проекта. После того, как эти и многие другие функции принял на себя Проектный офис, он стал полноценным Проектным офисом Agile.
На следующем этапе было решено усилить интеграцию между разработчиками программного и аппаратного обеспечения. Для этого были созданы мультидисциплинарные команды по внедрению элементов Scrum и Kanban в командах аппаратного обеспечения.
Благодаря этим изменениям в течение года удалось существенно сократить издержки и время, необходимое для создания продукта.
Проектный офис Agile или Agile PMO стал основным проводником изменений и сыграл ключевую роль в достижении результатов проектов.
Вот основные принципы, которые необходимо помнить при создании Agile PMO:
- Внедрение Agile-Scrum в ограниченной форме обязательно должно учитывать основное преимущество методологии – её гибкость и адаптивность
- Нет единого решения – каждый случай требует индивидуального подхода
- Гибкость Agile проявляется ещё и в том, что эту методологию можно видоизменять или использовать по частям
- Итеративная схема работы хороша до тех пор, пока команда имеет возможность в случае необходимость изменять длительность спринтов
- Иногда, когда общение напрямую с клиентом по каким-то причинам невозможно, его роль может играть менеджер по маркетингу или менеджер продукта
- Правила и процедуры не делают проекты, их делают люди. В каждом индивидуальном случае разработанная методика должна быть в первую очередь удобна командам проекта.
Если вы хотите изучить гибкие подходы к управлению проектами, тогда регистрируйтесь на открытый базовый тренинг “Agile Certified Professional”!
Вы также можете оставить заявку на тренинг в корпоративном формате.
Смотрите также:
- Консалтинг: Проектный офис: Создание и развитие
- Аутсорсинг: Аутсорсинг функций Проектного офиса
- Исследование: Проектный офис: Новое исследование ESI 2015
- Статья: Программное обеспечение для управления проектами по Agile
- Статья: Офис управления проектами как инструмент повышения эффективности организации
- Статья: Офис управления проектами и методология Scrum