Анцупов Артемий Кириллович
Администратор проектов
ПРОЕКТНЫЕ СЕРВИСЫ
Москва, 28 апреля 2016 г.
Agile PMO: Гибкий проектный офис
2
Главный персонаж
30
1
2
3
4
5
6
2010 2011 2012 2013
ПОКАЗАТЕЛИ РОСТА
Company Pear ltd. China Inc.
Проблема
4
Причина
0 5 10 15 20 25 30
Company
The Firm
China Inc.
Время до выхода продукта на рынок, мес.
Время до выхода продукта на рынок, мес.
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.ru
info@pmservices.ru

Артемий Анцупов "Agile PMO"

  • 1.
    Анцупов Артемий Кириллович Администраторпроектов ПРОЕКТНЫЕ СЕРВИСЫ Москва, 28 апреля 2016 г. Agile PMO: Гибкий проектный офис
  • 2.
  • 3.
    30 1 2 3 4 5 6 2010 2011 20122013 ПОКАЗАТЕЛИ РОСТА Company Pear ltd. China Inc. Проблема
  • 4.
    4 Причина 0 5 1015 20 25 30 Company The Firm China Inc. Время до выхода продукта на рынок, мес. Время до выхода продукта на рынок, мес.
  • 5.
    5 Анализ проблем • Превышениесроков задач • Переработки • Недостаток координации • Неполное исполнение содержания
  • 6.
    6 Решение •Внедрение Scrum! • Ускорениепроцесса разработки • Повышение качества кода • Улучшение коммуникаций с Заказчиком
  • 7.
    7 Спустя 2 года •Проведено полное переобучение и переформирование софтверных команд • Инвестиции в тренинги и коучинг по гибкому управлению проектами • Во всём софтверном направлении внедрён фреймворк Scrum
  • 8.
  • 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! • AgilePMO эффективно работает и по сей день, работая передаточным звеном и посредником между «Традиционалистами» и «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