1 / 65

Успешные проекты нечасты в IT

Проваленные. Проблемные. Успешные. 23%. 49%. 28%. 2000. 28%. 46%. 26%. 1998. 40%. 33%. 27%. 1995. 31%. 53%. 16%. 1994. Успешные проекты нечасты в IT. Статистика по 30,000 проектам п о разработке ПО в американских компаниях

coral
Download Presentation

Успешные проекты нечасты в IT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Введение в Microsoft Solutions Framework В.Л.Павлов,vlpavlov@ieee.org

  3. О докладчике • В.Л.Павлов • Опытруководства IТ-проектами • Проекты длительностью до 2 лет • Коллективы 100и более человек • Интернациональные и распределенные команды • Сертификаты • MSF Practitioner • MCT, MCSD for .NET, MCSD • CompTIA Certified IT Project+ • Член ACM, IEEE и PMI

  4. Результаты внедрение методик управления IT-проектами Данные опроса Center for Business Practices за 2002г. 42% опрошенных организаций входит в список Fortune 1000

  5. Немного терминологии • Проект (project) – ограниченная временными рамками деятельность, цель которой состоит в создании уникального продукта или услуги • Решение (solution)- скоординированная поставка набора элементов (таких как программно-технические средства, документация, обучение и сопровождение), необходимых для удовлетворения некоторой бизнес-потребности конкретного заказчика

  6. Проекты (projects) Уникальные цели, структура и задачи Толчок к изменениям Новый уникальный продукт или услуга Неоднородная команда Даты начала и конца Процессы (operations) Неизменные цели и задачи, стабильная структура Поддержание статус-кво Стандартный продукт или услуга Однородная команда Происходит постоянно

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

  8. MSF иMOF Microsoft Solutions Framework Планируем Эксплуатируем Создаем Внедряем Microsoft Operations Framework

  9. Эволюция MSF • Первоначальная версия MSF увидела свет в 1994 г. • В 2002 г. была опубликована последняя версия MSF (v3.0) • MSF “взрослеет” подобно другим продуктам Microsoft • Windows XP намного более зрелый продукт,чем Windows 95, аналогичная тенденция наблюдается и для MSF

  10. Структура MSF ДВЕ МОДЕЛИ Модель Проектной Группы МодельПроцессов ТРИ ДИСЦИПЛИНЫ Дисциплина управленияПроектами Дисциплина управленияРисками Дисциплина управленияПодготовкой

  11. Структура MSF • MSF состоит из двух моделей и трех дисциплин • Они подробно описаны в 5+1whitepapers • http://www.microsoft.com/rus/msf • http://www.microsoft.com/msf • Начинать изучение MSF нужно с моделей, затем переходя к дисциплинам

  12. Основные признаки неуспешных проектов Мы не могли получить информацию, которая была нужна для дальнейшей работы Проект не уложился в бюджет и сроки Мы не понимали ясно, что нужно делать Результат проекта оказался непредсказуем, мы продолжали обнаруживать новые проблемы Проект не оправдал наши ожидания – мы не довольны Мы не знали, как наша работа влияла на работу других членов нашей команды Конечный результат не соответствует первоначальному видению Проект слишком сложендля пользователя

  13. Модель проектной группы MSF(Ролевые кластеры и стоящие перед ними цели) Достижение результата в рамках проектных ограничений (бюджет, сроки и т.п.) Удовлетворенные заказчики Управление программой Создание продукта в соответствии со спецификацией Управление продуктом Разработка Команда соратников Удовлетворение потребителя Тестирование Повышение эффективности пользователя, увеличение потребительской ценности продукта Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены Управление выпуском Беспроблемное внедрение и сопровождение продукта

  14. Program Management ProductManagement Development UserExperience Test ReleaseManagement MSF Team Model Delivering the solution within project constraints Satisfied customers Building to specification Enhanced user effectiveness Approval for release only after all quality issues are identified and addressed Smooth deployment and ongoing operations

  15. Структура ролевых кластеров Пример Role cluster (role) Program management Functional areas Project management Solution architecture Responsibilities Drive overall solutiondesign Manage functionalspecification Tasks Maintain traceabilitymapLiaise with otherproject teams oninteroperabilityissues

  16. Управлениепрограммой Управление продуктом Разработка Удовлетворениепотребителя Тестирование Управление выпуском Модель проектной группы Управление проектомВыработка архитектуры решенияКонтроль производственного процессаАдминистративные службы Бизнес-приоритетыМаркетингПредставление интересов заказчикаПланирование продукта Технологическое консультирование Проектирование и осуществление реализацииРазработка приложенийРазработка инфраструктуры ОбучениеЭргономикаПредставление интересов пользователяГрафический дизайнИнтернационализацияОбеспечение технической поддержкиОбщедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями) Планирование тестовРазработка тестовОтчетность по тестам ИнфраструктураСопровождениеБизнес-процессыУправление выпуском готового продукта

  17. Масштабирование модели проектной группы • В одном ролевом кластере может быть много людей • Один человек может взять на себя несколько ролей • Большие коллективы: • Создаем группы направлений • Создаем функциональные группы • Малые коллективы: • Используем таблицу совместимости ролей

  18. Большой коллектив Руководящая группа Управление программой Управление продуктом Разработка Лидер группы Удовлетворение потребителя Тестирование Управление выпуском Управление программой Управление программой Удовлетворение потребителя(функциональная группа) Разработка Разработка Удовлетворение потребителя Удовлетворение потребителя Тестирование Тестирование Управление программой Разработка клиентских компонент(группа направления) Разработка средств обмена сообщениями(группа направления) Разработка Удовлетворение потребителя Тестирование Разработка средств печати (группа направления)

  19. - - + + ± - - ± ± + - - - - - ± - + + + ± - + ± + + - + ± ± Таблица совместимости ролей Управление продуктом Управление программой Управление выпуском Удовлетворение потребителя Разработка Тестирование Управление продуктом Управление программой Разработка Тестирование Удовлетворение потребителя Управление выпуском + Допустимо ±Нежелательно -Нельзя

  20. Удовлетворение потребителя Управление программой Разработка Управление продуктом Тестирование Минимальный коллектив Управлениевыпуском

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

  22. MilestoneMSF Role Cluster Vision/scope approved Product management Project plans approved Program management Scope complete Development User experience Release readiness approved Testing Release management Deployment complete Release management Различные кластеры играют ведущую роль на различных фазах

  23. Вехи (milestones) в MSF • Вехи – это точки синхронизации, оценки достигнутого прогресса и коррекции • Вехи – это НЕ точки “замораживания” окончательных и бесповоротных проектных решений • Результаты (Deliverables) являются “физическим доказательством” того, что веха была достигнута • Главные вехи (major milestones) означают переход от одной фазы к другой • Вспомогательные (внутренние) вехи (interim milestones) помогают провести декомпозицию работ и отслеживать прогресс • Для каждого проекта может быть свой спектр вспомогательных вех • MSF описывает некий “типичный” набор вспомогательных вех

  24. Вехи как точки принятия решений и механизм самосовершенствования • Milestone review meetings • Выработка соглашений между customer, stakeholders, sponsors и командой проекта • Принятие go/no-go решений • Post-milestone review meetings • Обмен полученным опытом, извлечение уроков • Уточнение/модификация используемого производственного процесса для последующих фаз и проектов

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

  26. Версия 3 Версия 2 Итеративный подход Минимизируем риски, разбивая большие проекты на несколько версий Функциональность Версия 1 Время

  27. Для каждой фазы модели процессов MSF определяет: • Что (какие артефакты) является результатом этой фазы • Над чем работает каждый из ролевых кластеров на этой фазе

  28. Vision/Scope Approved Baseline Project Plan Approved Conceptual Design Logical Design Physical Design Место проектирования в процессе

  29. Время Ресурсы Возможности Дисциплина управления проектами • Проект (project) – ограниченная временными рамками деятельность, цель которой состоит в создании уникального продукта или услуги • Управление проектами (project management) – это область знаний, навыков, инструментария и приемов, используемых для достижения целей проектов в рамках согласованных параметровкачества, бюджета, сроков и прочих ограничений

  30. Дисциплина управления проектами MSF • Накопленные человечеством знания по управлению проектами систематизированы в стандарте ANSI PMI PMBOK 2000 • Не все из описанных в PMBOK методик необходимы для IT-проектов, кроме того, ряд специфичных для IT концепций отсутствуют в PMBOK • Дисциплина управления проектами MSF служит своеобразным мостиком между MSF и PMBOK

  31. Project Management Institute (PMI) • Международная общественная организация • Создана в 1969 г • Более ста тысяч членов • Подразделения в более чем 100 странах, в т.ч. России и Украине • Штаб-квартира в Пенсильвании (США) • http://www.pmi.org

  32. Guide to the Project Management Body of Knowledge • Введение в Свод знаний по управлению проектами • Текущая версия опубликована в 2000г • Русский перевод пока есть только для предыдущей (96г) версии • Стоит $36

  33. PMBOK содержит описания 39 процессов, сгруппированных в 9 областей знаний: • Управление интеграционными процессами • Управление объемом работ в проекте • Управление временем • Управление стоимостью • Управление качеством • Управление персоналом • Управление коммуникацией • Управление закупками и контрактами • Управление рисками

  34. Как в PMBOK описываются процессы • Каждый процесс относится к одной из 9 областей знаний (управление рисками, качеством и т.п.) • Каждый процесс относится к одной из 5 групп процессов (планирование, исполнение и т.п.) • Для каждого процесса специфицируется (см. пример на следующем слайде): • Что является входными данными • Какими методами осуществляется процесс • Что является результатом процесса • Задается определенный порядок следования процессов

  35. Инициирование проекта • Формальное признание необходимости осуществления проекта, выделение на него ресурсов, назначение менеджера проекта и т.п. • Главные результаты: • Утвержден project charter – устав проекта • Назначен менеджер проекта

  36. Инициирование проекта Методыинструменты Входы Выходы Стратегический план Критерии отбора проектов Описание продукта Историческая информация Устав проекта Официально утвержденный менеджер проекта Ограничения Допущения Методики отбора проектов Экспертная оценка

  37. Проектные ограничения • "Любую техническую проблему можно преодолеть, имея достаточно времени и денег" (закон Лермана) СЛЕДСТВИЕ: • "Вам никогда не будет хватать либо времени, либо денег"

  38. Управлениеизменениями • Мы не можем избежать изменений в проекте • Но мы можем заранее договориться о приоритетах,которыми будем руководствоваться при реагировании на изменения • Для этого используется матрица компромиссов Фиксируется Согласовывается Принимается Ресурсы Время Возможности

  39. Управление ожиданиями заказчика Конус неопределенности показывает, как меняется точность оценок стоимости проекта по мере его осуществления. Важно, чтобы заказчик понимал это

  40. WBS связывает спецификации, планы и календарные графики проекта

  41. Управление снабжением Управление рисками Управление персоналом Управление коммуникацией Планирование и мониторинг Управление рамками проекта Управление календарным графиком Управление стоимостью Управление качеством В MSF нет роли “менеджер проекта” Деятельность по управлению проектом распределяется между лидерами группи ролевым кластером“Управление программой” Лидеры групп Управление программой Управление продуктом Разработка Тестирование Удовл. потребителя Управление выпуском на уровне всего проекта на уровне подгрупп

  42. Дисциплина управления рисками Мы не боремся с рисками – мы ими управляем • Итеративный процесс • Осуществляется на протяжениивсего проекта • Базируется на посылке о присутствиирисков в любом проекте • Нацелена на проведение профилактических мероприятий

  43. 2 Анализиприоритезация Формулировка риска 1 Выявление Список рисков 3 5 Планирование Коррекция Главные риски 6 Извлечение уроков Мониторинг База знаний о рисках 4 Дисциплина управления рисками

  44. Каждый шаг описывается очень детально:

  45. Дисциплина управления подготовкой Определение Знания, умения, способности Оценивание Осмысление Корректировка

  46. MSF включает в себя: • Фундаментальные принципы • Foundational Principles • Ключевые концепции • Key Concepts • Испытанные методики • Proven Practices

  47. Фундаментальные принципы MSF • Распределение ответственности при фиксации отчетности • Clear accountability, shared responsibility • Наделяйте сотрудников необходимых полномочий • Empower team members • Концентрируйтесь на бизнес-приоритетах • Focus on business value • Единое видение • Shared project vision • Проявляйте гибкость – будьте готовы к переменам • Stay agile, expect change • Поощряйте свободное общение • Foster open communications • Извлекайте уроки из всего • Learn from all experiences • Инвестируйте в качество • Invest in quality

  48. MSF не навязывает использование других продуктов Microsoft • Например, для организации процесса производства ПО можно использовать MSF и при этом применять инструменты Borland • На следующих слайдах приводятся рисунки с сайтов Borland и Microsoft

  49. Средства Borland для организации работы над проектом

  50. MSF Сравниваем взгляды Microsoft и Borland на жизненный цикл проекта

More Related