Embed Size (px)
DESCRIPTION
Представлено сравнение трех подходов к проектированию ПО: 1) PMBOk PMI 3 Edition; 2) Microsoft Solution Framework; 3) Экстремальное управление проектами
Citation preview
Современные подходы к управлению ИТ-проектами
Евгений Пикулев, PMP
директор ЗАО «Инверсия-Урал».
Содержание
1. Введение
2. PMBOK
3. Microsoft Solution Framework
4. Экстремальное управление проектами
5. Выводы
Успешные проекты нечасты в ИТ
Статистика по 30,000 проектам по разработке ПО в американских компаниях.
Источник: The Standish Group International, Extreme Chaos, The Standish Group International, Inc., 2000
Успешные проекты – вовремя и в рамках бюджета был выполнен весь намеченный фронт работ.
Проблемные – не уложились в сроки, перерасходовали бюджет и/или сделали не все, что требовалось.
Проваленные – не были доведены до конца.
2005
2000
1995
1990
28%23% 49%
26%28% 46%
27%40% 33%
16%31% 53%
УспешныеПроблемныеПроваленные
Как управлять ИТ-проектом?
Какие подходыприменять?
Как получитьрезультат?
Подход PMI (PMBoK, Third Edition)
Управление проектом Время
Интеграция
Содержание
Стоимость
Риски
Персонал
Коммуникации
Качество
Поставки
Области знаний PMBoK
Управление содержанием (Scope) 5 Управление сроками (Time) 6 Управление стоимостью (Cost) 3 Управление коммуникациями 4
(Communication) Управление персоналом (Human Resources) 4
Управление качеством (Quality) 3 Управление рисками (Risk) 6 Управление поставками (Procurement) 6 Управление интеграцией (Integration) 7 (!) ----- 44
Кол-во процессов
Процессы по областям знаний
5.2ScopePlanning
5.3ScopeDefinition
6.1ActivityDefinition
7.1ResourcesPlanning
6.2 ActivitySequencing
6.3ActivityDurationEstimating
7.2Cost Estimating
6.4ScheduleDevelopment
7.3CostBudgeting
4.1Project PlanDevelopment
From the Initiating Processes
From the Controlling Processes
Core Processes
Planning Processes
To theExecutingProcesses
8.1QualityPlanning
9.1OrganisationalPlanning
11.2RiskIdentification
11.3 Qualitative RiskAnalysis
11.5Risk ResponsePlanning
9.2StaffAcquisition
10.1Communications Planning
Facilitating Processes
12.1ProcurementPlanning
12.2SolicitationPlanning
11.3 Quantitative RiskAnalysis
11.1 Risk Management Planning
Много процессов, которыми надо управлять
Source: PMI’s Project Management Body of Knowledge (PMBOK®), 2004
קוד
1
2
3
4
5
6
Software Project
Analysis
Design
Build
Test
Implementation
11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 022001 2002 2003 2004 2005
Расписание
Пример планирования проекта
קוד שם פעילות
1 Software Project
2 Analysis
3 Design
4 Build
5 Test
6 Implementation
Software Project
JohnAnalysis
DavidDesign
LisaBuild
JohnTest
SuzanImplementation
10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 012001 2002 2003 2004 2005
Ресурсы
Пример планирования проекта
קוד שם פעילות
1 Software Project
2 Analysis
3 Design
4 Build
5 Test
6 Implementation
$ 100,000Software Project
$ 15,000 John
Analysis
$ 10,000 David
Design
$ 40,000 Lisa
Build
$ 20,000 John
Test
$ 15,000 Suzan
Implementation
10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 012001 2002 2003 2004 2005
Стоимость
Risk planningCommunications planningQuality planningProcurement planningProject plan document
Пример планирования проекта
Плюсы и минусы
Best practise Проработанная
методика Институт по
сертификации. Хорошая
проработанность ряда разделов (риски, earned value)
Большое количество процессов.
«Водопадная» модель.
Нет специфических подходов к процессам ИТ (ITIL-ITSM)
Не подходит к плохо структурированным проектам
Подход Microsoft (Microsoft Solution Framework)
MSF и MOF
MSF = Microsoft Solutions Framework Подход Microsoft к управлению
ИТ-проектами: Проекты разработки ПО Проекты развертывания инфраструктуры
MOF = Microsoft Operations Framework Подход Microsoft к управлению
ИТ-процессами (операциями) на предприятии
MSF и MOF
Microsoft Operations Framework
Microsoft Solutions Framework
ЭксплуатируемВ
нед
ряе
м
СоздаемП
лан
ир
уем
Модель процессов
Планы проекта утверждены
Разработка завершена
Готовность решения утверждена
Внедрение завершено
Концепция проекта утверждена
Выработка
концепцииВнедр
ение
Разработка
Пл
анир
ован
иеС
табилизация
Промежуточные вехи
Планы проекта утверждены
Разработка завершена
Готовность решения утверждена
Внедрение завершено
Концепция проекта утверждена
Пилотное внедрение завершено
Контрольное тестирование завершено
Версии-кандидаты
Тестирование приемлемости для потребителей завершено
Точка достижения нуля
Точка конвергенции
Верификация технологий осуществлена
Базовая версия функциональной спецификации создана
Базовая версия сводного плана проекта создана
Базовая версия сводного календарного графика проекта создана
Среды разработки и тестирования развернуты
Внедренное решение стабилизировано
Внедрение на местах завершено
Ключевые компоненты развернуты
Ядро проектной группы сформировано
Черновой вариант концепции проекта составлен
Концепция подтвержденаПромежуточная версия 1 завершена
Промежуточная версия 2 завершенаПромежуточная версия N завершена
Плюсы и минусы
Гибкая методология Апробирована
Microsoft Модель команды Больше
соответствует циклу разработки ПО
Концентрация на экономической отдаче
В России практически не развита.
Нет руководителя проекта.
Многовато специфики (ежедневные сборки)
Потребуется внедрить модель MOF
Подход Дуга де Карло (Экстремальное управление
проектами)
Определение экстремального проекта
«Экстремальный проект – это комплексное, высокоскоростное, самокорректирующееся предприятие, во время работы над которым люди взаимодействуют в поисках желаемого результата в условиях крайней неопределенности, постоянных изменений и сильного стресса.»
Дуг де Карло
Природа экстремальных проектов Жесткие сроки, установленные сверху Скептическое отношение команды к возможному успеху Неприязнь к управлению проектами и другим процессам Вечно недоступный спонсор проекта Неудовлетворительные условия работы Отсутствие прямой власти над членами команды Занятость членов команды в других проектах Высокая текучесть сотрудников в компаниях Многообразие требований со стороны менеджеров,
спонсоров и заказчиков, которые имеют различные и порой противоречивые интересы в результатах проекта
Недостаток полномочий членов команды для принятия решений.
Стрессовое состояние команды в связи с ненормированным рабочим днем и непредсказуемостью ситуации.
Ментальная модель проекта
Рис.1 Ментальная модель традиционного проекта
Рис.2 Ментальная модель экстремального проекта
Роль руководителя ЭП
Плюсы и минусы
Антикризисный подход
Сильная роль PM. Эффективна в
«созревших» компаниях.
Экстремальное программирование.
Не является методологией.
Большое количество рисков и стрессов.
90% успеха проекта зависит от PM.
Нет акцента на качестве.
Статистика Standish Group
0
5
10
15
20
25
30
35
40
Ove
rall
Rel
ativ
e Im
po
rtan
ce
HR ScopeIntegration Time Cost Comm. Quality RiskProcurement
Knowledge Area
Относительная важность областей знаний Software & Communications
Source: Standish Group
0
5
10
15
20
25
30
35
40
Ove
rall
Rel
ativ
e Im
po
rtan
ce
Time Cost Quality Comm.IntegrationProcu. HR Risk Scope
Knowledge Area
Относительная важность областей знаний Construction & Engineering
Source: Standish Group
В качестве вывода
Хорошие КОМАНДЫ являются НЕОБХОДИМЫМ, но не достаточным условием успешной реализации ИТ-проекта.
Спасибо за внимание !
