Анцупов Артемий Кириллович

Администратор проектовПРОЕКТНЫЕ СЕРВИСЫ

Москва, 28 апреля 2016 г.

Agile PMO: Гибкий проектный офис

2

Главный персонаж

32010 2011 2012 20130

1

2

3

4

5

6

Показатели ростаCompany Pear ltd. China Inc.

Проблема

4

Причина

Company

The Firm

China Inc.

0 5 10 15 20 25 30

Время до выхода продукта на рынок, мес.

Время до выхода продукта на рынок, мес.

5

Анализ проблем

• Превышение сроков задач

• Переработки

• Недостаток координации

• Неполное исполнение содержания

6

Решение

• Внедрение Scrum!• Ускорение процесса разработки• Повышение качества кода• Улучшение коммуникаций с

Заказчиком

7

Спустя 2 года

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

• Инвестиции в тренинги и коучинг по гибкому управлению проектами

• Во всём софтверном направлении внедрён фреймворк Scrum

8

Результат

+ -

Оторванность от стратегии

Изоляция от остальной компании

Диссинхронизация

Улучшение качества кода

Повышение производительности

9

Консультанты

10

Встреча с заинтересованными сторонами

Команда «Scrum-фанатики»Scrum-мастераКоманды проектов

Команда «Традиционалы»Менеджеры проектов

Сотрудники Проектного офиса16 человек

11

Взаимные обвинения

Команда «Традиционалы»:⁻ В просрочках виноваты Scrum-фанатики!⁻ Они не хотят поменять ничего в Scrum-подходе, даже если так нужно!⁻ Не могут предоставить ни одного отчёта об успехе (да вообще никакой

отчётности)!

Команда «Scrum-фанатики»:⁻ Традиционалы вмешиваются в нашу работу!⁻ Переводят людей на другие проекты!⁻ Являются на daily stand-up’ы и обвиняют нас в просрочках и перерасходе!⁻ Везде лезут со своим «контролем» и насильно проводят свои изменения!

12

Проводники изменений

1. Руководитель Проектного офиса (Лидер изменений):• Опытный• Квалифицированный• Давно работает в компании• Доверяют обе группы

2. Консультанты3. Сотрудники Проектного офиса

• Команда за проведение изменений

13

Первоочередные задачи

• Создать атмосферу взаимодействия и доверия

• Повысить прозрачность результатов спринтов Scrum-команд

• Защитить Scrum-команды от внешнего вмешательства

• Увеличить длину спринта для лучшей координации с хардверными командами проекта

14

Сопротивление

• Scrum-фанатики сопротивлялись увеличению спринта

• Традиционалы сопротивлялись отдалению от проектов и потери власти

15

Формирование Agile PMO

• Бывший руководитель проектного офиса (Лидер изменений)

• Часть сотрудников Проектного офиса

• «Поддержавшие» изменения проектные менеджеры

16

Happy End!

• Agile PMO эффективно работает и по сей день, работая передаточным звеном и посредником между «Традиционалистами» и «Scrum-фанатиками»

• Company смогла наконец повысить свои целевые показатели и эффективно соперничать на рынке с конкурентами

• Консультанты создали ещё немало Проектных офисов и выявили различные виды и сценарии для Agile PMO

17

Сценарий 1: «Крупные корпорации»

• Иерархическая матричная организация

• Жёсткая вертикальная система контроля портфеля проектов

• Agile-командам трудно адаптироваться

18

Сценарий 1: «Крупные корпорации»

• Проблема: жёсткий контроль проектов, применение водопадной методики

• Возможное решение: Проектный офис-посредник

• Задача офиса: Подготовка отчётности необходимого формата и оценка плана

• Владелец продукта может быть членом Проектного офиса

• Процессы инициации и закрытия проекта могут быть переданы Проектному офису

19

Сценарий 2: «Зарегулированные отрасли»

• Высокий уровень стандартизации и государственного регулирования

• Государственные предприятия или органы государственной власти

• Agile только в отдельно взятых командах

20

Сценарий 2: «Зарегулированные отрасли»

• Проблема: строгий контроль, документация всего, включая риски

• Возможное решение: Административный проектный офис

• Задача офиса: Документирование деятельности команды

• Проектный офис участвует в работе команды, собирая нужную для документации информация

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

21

• Разработка сложных интегрированных продуктов

• Большое количество компонентов, как программных, так и аппаратных

• Жёсткие регламентированные требования

• Мало места для маневра и гибкости

• Наиболее сложный сценарий

Сценарий 3: «Комплексные продукты с жёсткими требованиями»

22

Сценарий 3: «Комплексные продукты с жёсткими требованиями»

• Проблема: Гибкость ограничена описанием продукта и аппаратной его частью

• Возможное решение: Поддерживающий гибридную методологию Проектный офис

• Задача офиса: Лидерство и аккумуляция технических и административных компетенций

• Разработка индивидуального подхода итеративной разработки

23

Сценарий 4: «ИТ-департаменты в компаниях»

• Поддерживают функционирование организации

• Постоянные изменения в расписании

• Неожиданно появляющиеся проблемы

• Совмещение функций разработки и техподдержки

24

Сценарий 4: «ИТ-департаменты в компаниях»

• Проблема: Отсутствие Владельца продукта

• Возможное решение: Проектный офис-Владелец продукта

• Задача: Сбор и уточнение заявок от подразделений, планирование работы и распределение нагрузки между командами

• Необходим буфер для экстренных задач

• Длина спринта может меняться

• Kanban вместо Agile

25

Выводы

• Можно пробовать внедрять Agile самостоятельно, но привлечение консультантов значительно повышает шансы на успех

• Перед выбором модели Agile PMO важно определить его конфигурацию, нельзя просто копировать чужие модели

• Крупные корпорации - Проектный офис встраивает Agile-проекты в общую водопадную систему управления проектами

• Зарегулированные отрасли - Проектный офис снимает с Agile-команд административную нагрузку по документированию

• Комплексные проекты (hard & soft) – координация между hard и soft командами и поддержка гибридной методологии

• ИТ-департаменты – выполнение функции централизованного Владельца продукта

Контакты

Компания «Проектные сервисы»

г. Москва, проспект Вернадского, д.29, пом. I, офис 4.

Тел.: +7 (495) 240-90-80

www.pmservices.ruinfo@pmservices.ru