Выступление Артемия Анцупова, эксперта компании ПРОЕКТНЫЕ СЕРВИСЫ на конференции ГОС-Agile в Аналитическом центре при Правительстве РФ.

1. Анцупов Артемий Кириллович
Администратор проектов
ПРОЕКТНЫЕ СЕРВИСЫ
Москва, 28 апреля 2016 г.
Agile PMO: Гибкий проектный офис

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

3. 30
1
2
3
4
5
6
2010 2011 2012 2013
ПОКАЗАТЕЛИ РОСТА
Company Pear ltd. China Inc.
Проблема

4. 4
Причина
0 5 10 15 20 25 30
Company
The Firm
China Inc.
Время до выхода продукта на рынок, мес.
Время до выхода продукта на рынок, мес.

5. 5
Анализ проблем
• Превышение сроков задач
• Переработки
• Недостаток координации
• Неполное исполнение содержания

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

7. 7
Спустя 2 года
• Проведено полное переобучение и
переформирование софтверных
команд
• Инвестиции в тренинги и коучинг по
гибкому управлению проектами
• Во всём софтверном направлении
внедрён фреймворк Scrum

8. 8
Результат
+ -

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

10. 10
Встреча с заинтересованными сторонами
Команда «Scrum-фанатики»
Scrum-мастера
Команды проектов
Команда «Традиционалы»
Менеджеры проектов
Сотрудники Проектного офиса
16 человек

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

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

13. 13
Первоочередные задачи
•Создать атмосферу взаимодействия и доверия
•Повысить прозрачность результатов спринтов
Scrum-команд
•Защитить Scrum-команды от внешнего
вмешательства
•Увеличить длину спринта для лучшей
координации с хардверными командами
проекта

14. 14
Сопротивление
•Scrum-фанатики сопротивлялись увеличению спринта
•Традиционалы сопротивлялись отдалению от
проектов и потери власти

15. 15
Формирование Agile PMO
• Бывший руководитель проектного офиса (Лидер изменений)
• Часть сотрудников Проектного офиса
• «Поддержавшие» изменения проектные менеджеры

16. 16
Happy End!
• Agile PMO эффективно работает и по сей день, работая передаточным звеном и
посредником между «Традиционалистами» и «Scrum-фанатиками»
• Company смогла наконец повысить свои целевые показатели и эффективно
соперничать на рынке с конкурентами
• Консультанты создали ещё немало Проектных офисов и выявили различные виды
и сценарии для Agile PMO

17. 17
Сценарий 1: «Крупные корпорации»
• Иерархическая матричная
организация
• Жёсткая вертикальная система
контроля портфеля проектов
• Agile-командам трудно
адаптироваться

18. 18
Сценарий 1: «Крупные корпорации»
• Проблема: жёсткий контроль проектов, применение водопадной
методики
• Возможное решение: Проектный офис-посредник
• Задача офиса: Подготовка отчётности необходимого формата и оценка
плана
• Владелец продукта может быть членом Проектного офиса
• Процессы инициации и закрытия проекта могут быть переданы
Проектному офису

19. 19
Сценарий 2: «Зарегулированные отрасли»
• Высокий уровень стандартизации и государственного регулирования
• Государственные предприятия или органы государственной власти
• Agile только в отдельно взятых командах

20. 20
Сценарий 2: «Зарегулированные отрасли»
• Проблема: строгий контроль, документация всего, включая риски
• Возможное решение: Административный проектный офис
• Задача офиса: Документирование деятельности команды
• Проектный офис участвует в работе команды, собирая нужную для
документации информация
• Проектный офис может выступать в качестве дополнительного владельца
продукта, для отслеживания требований

21. 21
• Разработка сложных интегрированных продуктов
• Большое количество компонентов, как программных, так и аппаратных
• Жёсткие регламентированные требования
• Мало места для маневра и гибкости
• Наиболее сложный сценарий
Сценарий 3: «Комплексные продукты с жёсткими
требованиями»

22. 22
Сценарий 3: «Комплексные продукты с жёсткими
требованиями»
• Проблема: Гибкость ограничена описанием продукта и аппаратной
его частью
• Возможное решение: Поддерживающий гибридную методологию
Проектный офис
• Задача офиса: Лидерство и аккумуляция технических и
административных компетенций
• Разработка индивидуального подхода итеративной разработки

23. 23
Сценарий 4: «ИТ-департаменты в компаниях»
• Поддерживают функционирование
организации
• Постоянные изменения в
расписании
• Неожиданно появляющиеся
проблемы
• Совмещение функций разработки
и техподдержки

24. 24
Сценарий 4: «ИТ-департаменты в компаниях»
• Проблема: Отсутствие Владельца продукта
• Возможное решение: Проектный офис-Владелец продукта
• Задача: Сбор и уточнение заявок от подразделений, планирование
работы и распределение нагрузки между командами
• Необходим буфер для экстренных задач
• Длина спринта может меняться
• Kanban вместо Agile

25. 25
Выводы
• Можно пробовать внедрять Agile самостоятельно, но привлечение консультантов
значительно повышает шансы на успех
• Перед выбором модели Agile PMO важно определить его конфигурацию, нельзя
просто копировать чужие модели
• Крупные корпорации - Проектный офис встраивает
Agile-проекты в общую водопадную систему управления проектами
• Зарегулированные отрасли - Проектный офис снимает с
Agile-команд административную нагрузку по документированию
• Комплексные проекты (hard & soft) – координация между hard и soft командами
и поддержка гибридной методологии
• ИТ-департаменты – выполнение функции централизованного Владельца
продукта

26. Контакты
Компания «Проектные сервисы»
г. Москва,
проспект Вернадского, д.29, пом. I,
офис 4.
Тел.: +7 (495) 240-90-80
www.pmservices.ru
info@pmservices.ru