Представлено сравнение трех подходов к проектированию ПО: 1) PMBOk PMI 3 Edition; 2) Microsoft Solution Framework; 3) Экстремальное управление проектами

1. Современные подходы к
управлению ИТ-проектами
Евгений Пикулев, PMP
директор ЗАО «Инверсия-Урал».
eugenpik@rambler.ru

2. Содержание
1. Введение
2. PMBOK
3. Microsoft Solution Framework
4. Экстремальное управление проектами
5. Выводы

3. Успешные проекты нечасты в ИТ
Проваленные Проблемные Успешные
2005 23% 49% 28%
2000 28% 46% 26%
1995 40% 33% 27%
1990 31% 53% 16%
Статистика по 30,000 проектам по разработке ПО в американских компаниях.
Источник: The Standish Group International, Extreme Chaos, The Standish Group International, Inc., 2000
Успешные проекты – вовремя и в рамках бюджета был выполнен весь намеченный фронт работ.
Проблемные – не уложились в сроки, перерасходовали бюджет и/или сделали не все, что требовалось.
Проваленные – не были доведены до конца.

4. Как управлять
ИТ-проектом?
Какие подходы
применять?
Как получить
результат?

5. Подход PMI
(PMBoK, Third Edition)

6. Области знаний PMBoK
Интеграция
Поставки
Содержание
Риски
Управление проектом Время
Коммуникации
Стоимость
Персонал Качество

7. Процессы по областям знаний
Кол-во
процессов
 Управление содержанием (Scope) 5
 Управление сроками (Time) 6
 Управление стоимостью (Cost) 3
 Управление коммуникациями 4
(Communication)
 Управление персоналом (Human Resources) 4
 Управление качеством (Quality) 3
 Управление рисками (Risk) 6
 Управление поставками (Procurement) 6
 Управление интеграцией (Integration) 7 (!)
-----
44

8. Много процессов, которыми надо
управлять
Planning Processes
Core Processes
5.2 6.1
Scope Activity 6.2
Planning Definition Activity 6.4
From the Schedule
Sequencing
Initiating Development
Processes
6.3
7.1 Activity 7.3
Resources Duration Cost
5.3 Estimating
Scope Planning Budgeting
Definition
7.2
Cost To the
From the Estimating Executing
Controlling 4.1 Processes
Processes 11.1 Project Plan
Risk Management Development
Planning
Facilitating Processes
8.1 11.2 11.3 11.3 11.5
Quality Risk Qualitative Risk Quantitative Risk Risk Response
Planning Identification Analysis Analysis Planning
9.1 9.2 10.1 12.1 12.2
Organisational Staff Communications Procurement Solicitation
Planning Acquisition Planning Planning Planning
Source: PMI’s Project Management Body of Knowledge (PMBOK®), 2004

9. Пример планирования проекта
Расписание

10. Пример планирования проекта
Ресурсы

11. Пример планирования проекта
Risk planning
Communications planning
Quality planning
Procurement planning
Project plan document
Стоимость

12. Плюсы и минусы
 Best practise  Большое количество
 Проработанная процессов.
методика  «Водопадная»
 Институт по модель.
сертификации.  Нет специфических
 Хорошая подходов к процессам
проработанность ИТ (ITIL-ITSM)
ряда разделов  Не подходит к плохо
(риски, earned value) структурированным
проектам

13. Подход Microsoft
(Microsoft Solution Framework)

14. MSF и MOF
 MSF = Microsoft Solutions Framework
 Подход Microsoft к управлению
ИТ-проектами:
 Проекты разработки ПО
 Проекты развертывания инфраструктуры
 MOF = Microsoft Operations Framework
 Подход Microsoft к управлению
ИТ-процессами (операциями) на предприятии

15. MSF и MOF
Microsoft Solutions Framework
Microsoft Operations Framework

16. Модель процессов
Внедрение
завершено
Готовность решения Концепция проекта
утверждена утверждена
Разработка Планы проекта
завершена утверждены
Разработка

17. Промежуточные вехи
Внедрение
завершено
Внедренное решение стабилизировано
Ядро проектной группы сформировано
Внедрение на местах завершено
Черновой вариант концепции
Ключевые компоненты развернуты проекта составлен
Готовность решения Концепция проекта
утверждена утверждена
Пилотное внедрение завершено Верификация технологий
осуществлена
Контрольное тестирование завершено
Базовая версия функциональной
спецификации создана
Версии-кандидаты
Базовая версия сводного плана
Тестирование приемлемости для
проекта создана
потребителей завершено
Базовая версия сводного календарного
Точка достижения нуля графика проекта создана
Среды разработки и тестирования
Точка конвергенции
развернуты
Разработка Планы проекта
завершена утверждены
Концепция подтверждена
Промежуточная версия 1 завершена
Промежуточная версия 2 завершена
Промежуточная версия N завершена

18. Плюсы и минусы
 Гибкая методология  В России практически
 Апробирована не развита.
Microsoft  Нет руководителя
 Модель команды проекта.
 Больше  Многовато специфики
соответствует циклу (ежедневные сборки)
разработки ПО  Потребуется
 Концентрация на внедрить модель
экономической MOF
отдаче

19. Подход Дуга де Карло
(Экстремальное управление
проектами)

20. Определение экстремального
проекта
 «Экстремальный проект – это
комплексное, высокоскоростное, самокорректи
рующееся предприятие, во время работы над
которым люди взаимодействуют в поисках
желаемого результата в условиях крайней
неопределенности, постоянных изменений и
сильного стресса.»
Дуг де Карло

21. Природа экстремальных
проектов
 Жесткие сроки, установленные сверху
 Скептическое отношение команды к возможному успеху
 Неприязнь к управлению проектами и другим процессам
 Вечно недоступный спонсор проекта
 Неудовлетворительные условия работы
 Отсутствие прямой власти над членами команды
 Занятость членов команды в других проектах
 Высокая текучесть сотрудников в компаниях
 Многообразие требований со стороны
менеджеров, спонсоров и заказчиков, которые имеют
различные и порой противоречивые интересы в результатах
проекта
 Недостаток полномочий членов команды для принятия
решений.
 Стрессовое состояние команды в связи с ненормированным
рабочим днем и непредсказуемостью ситуации.

22. Ментальная модель проекта
Рис.1 Ментальная модель традиционного проекта
Рис.2 Ментальная модель экстремального проекта

23. Роль руководителя ЭП

24. Плюсы и минусы
 Антикризисный  Не является
подход методологией.
 Сильная роль PM.  Большое количество
 Эффективна в рисков и стрессов.
«созревших»  90% успеха проекта
компаниях. зависит от PM.
 Экстремальное  Нет акцента на
программирование. качестве.

25. Статистика Standish Group

26. Относительная важность областей знаний
Software & Communications
40
35
Overall Relative
30
Importance
25
20
15
10
5
0 HR ScopeIntegration Tim e Cost Com m . Quality RiskProcurem ent
Knowledge Area
Source: Standish Group

27. Относительная важность областей знаний
Construction & Engineering
40
35
Overall Relative
30
Importance
25
20
15
10
5
0 Tim e Cost Quality Com m .IntegrationProcu. HR Risk Scope
Knowledge Area
Source: Standish Group

28. В качестве вывода
Хорошие КОМАНДЫ являются
НЕОБХОДИМЫМ, но не достаточным
условием успешной реализации ИТ-проекта.

29. Спасибо за внимание !