Agile PMO: эффективный и ценностно ориентированный Проектный офис

14 Сен 2015

Проектный офис Agile PMO

За последние два десятилетия было разработано и опробовано множество различных гибких методологий и подходов. Из них в последние 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 проявляется ещё и в том, что эту методологию можно видоизменять или использовать по частям
  • Итеративная схема работы хороша до тех пор, пока команда имеет возможность в случае необходимость изменять длительность спринтов
  • Иногда, когда общение напрямую с клиентом по каким-то причинам невозможно, его роль может играть менеджер по маркетингу или менеджер продукта
  • Правила и процедуры не делают проекты, их делают люди. В каждом индивидуальном случае разработанная методика должна быть в первую очередь удобна командам проекта.

Смотрите также:

 

Оригинал: http://pmworldjournal.net/wp-content/uploads/2015/08/pmwj37-Aug2015-Nir-the-agile-pmo-second-edition.pdf


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Rambler's Top100 Яндекс.Метрика Рейтинг@Mail.ru