Глава 1. Управление программными проектами

Конспект Pankaj Jalote "Управление программным продуктом на практике"

Каждый год выполняется примерно 1 000 000 проектов, на общую сумму $600 000 000 000. Приблизительно 33% превышают стоимость и отстают по срокам более, чем на 125%. Наиболее важными причинами провала является неправильное управление проектом.

1. маловразумительные цели,
2. плохое планирование,
3. необходимость использования новых технологий,
4. отсутствие методологии управления проектом и
5. недостаточная численность персонала.

Первые три связаны с управлением проектом, последние две - риски проекта, которыми необходимо управлять в ходе управления проектом. При управлении проектом используется множество процессов, каждый из которых решает только локальные задачи управления, например:

1. Оценивание трудоемкости
2. Управление рисками
3. Мониторинг проекта
4. Управление конфигурацией и т.д.

Но неясно, как объединить их в один реально выполнимый процесс. Требуется сбалансированный процесс, охватывающий управление всем проектом от начала до конца. 1.1. Процессы и управление проектом 
Деятельность в программном проекте ведется в основном в двух измерениях: в области инженерии и в области управления проектом. Измерение инженерии имеет дело с проектированием, программированием, тестированием и т.п. Измерение управления проектом связано с надлежащим планированием и контролем действий инженерии, которые позволяют достичь целей проекта по стоимости, срокам и качеству. Для простых проектов не требуется высокий уровень формализма при их выполнении. Для более сложных проектов необходим определенный уровень формализма при выполнении проекта, а также строгость планирования и отслеживания запланированных задач. Формализм требует применять четко определенные процессы, поэтому результаты зависят от устойчивости этих процессов. Формализм еще более усиливается, если в процессах используются количественные подходы. Технически процесс для задачи включает последовательность шагов, которой нужно придерживаться при выполнении данной задачи. Однако для любой организации процессы, которые она рекомендует использовать своим инженерам и менеджерам проектов,— не просто последовательности шагов: они заключают в себе то, что инженеры и менеджеры проектов узнали об успешно выполненных проектах. Через процессы преимущества накопленного опыта передаются всем сотрудникам организации, в том числе новичкам. Такие процессы помогают менеджерам и инженерам подражать прошлым успехам и избегать просчетов, ведущих к провалам. Процессы инженерии определяют как выполнить работу. Процессы управления проектом определяют, как

• Установить контрольные точки
• Организовать персонал
• Управлять рисками
• Отслеживать продвижение вперед и т.д.

Менеджеры проектов хотят использовать процессы управления проектом, но только в том случае, если они построены рационально и помогают им лучше выполнять проект. Но их возмущают излишне бюрократизированные процессы, не сильно полезные в работе. Поэтому необходимо создавать облегченные процессы, которые помогают лучше планировать и контролировать проект и могут быть гибко использованы в различных ситуациях. Почему менеджеры проектов должны придерживаться процессов (С.Д.Шибулал):

1. Процессы представляют коллективное знание. Их использование повышает шансы на успех
2. Процесс может включать несколько дополнительных шагов, но никогда нельзя знать заранее, каким путем будет развиваться ситуация, поэтому использование коротких путей повышает риски выполнения проекта.
3. Не пользуясь процессами, нельзя предсказать результаты проекта.
4. Вы и ваша организация не сможете обучаться, если не будете пользоваться предопределенными процессами.
5. Процессы снижают уровень опасений. Контрольные перечни неизбежно охватывают 80% того, что необходимо сделать. Вам остается проработать только 20%.

1.2. Управление проектами и CMM 
CMM - the Capability Maturity Model. CMM для ПО является системой понятий, которые пытаются ответить на вопрос, какие должны быть характеристики эффективных процессов, не предписывая никаких конкретных процессов. CMM может использоваться для оценки процесса разработки ПО в организации и для определения его недостатков. Другой стандарт - ISO 9001.

  1.2.1. Обзор CMM 
Незрелость процессов разработки ПО означает, что проекты выполняются без многих необходимых правил, а результаты проекта зависят в значительной степени от руководителя проектом и команды. При использовании зрелых процессов проект выполняется в соответствии с определенными процессами. В этом случае результат меньше зависит от людей и больше от процесса. Чем более зрелые процессы используются, тем более предсказуемы результаты, тем лучше контролируется проект. Устойчивость процесса проекта (process capability) - диапазон результатов проекта, которые получаются как следствие исполнения проекта согласно этого процесса. Производительность процесса (process performance) - фактический результат процесса, полученный в результате использования этого процесса. Таким образом производительность (эффективность) процесса зависит от его устойчивости. Уровень зрелости процессов - определенная стадия, на которой находятся процессы организации, которой соответствуют определенные характеристики. Ключевая область процесса (key process area, KPA) - характеристика каждого уровня зрелости, это те области, на которые организация должна обращать внимание, чтобы поднять свои процессы до данного уровня зрелости (отображены на диаграмме). Чтобы организация достигла уровня определенного уровня зрелости, она должна соответствовать всем KPA это уровня и всем KPA нижних уровней.

  1.2.2. Ключевые области процесса (KPA) для управления проектами 
Каждая KPA задает цели, которым процессы организации должны соответствовать. Также задается Ключевые практики (key practices) - группа действий, которые вместе соответствуют целям KPA.

  Уровень 2 
В таблице перечислены все цели для KPA уровня 2. Почти все внимание отдается управлению проектом.

KPA	Цели
Управление требованиями (управленческая область)	Требования к ПО контролируются для определения базовой линии разработки ПО и управления разработкой В соответствии с требованиями поддерживаются планы разработки ПО, продукты и действия
Планирование программного проекта (управленческая область)	Оценки документируются для использования в процессах планирования и отслеживания проекта Планируются и документируются действия и обязательства по проекту Участвующие группы и отдельные лица принимают на себя обязательства, связанные с проектом.
Отслеживание и надзор за проектом (управленческая область)	Фактические результаты и характеристики сравниваются с планами разработки ПО Если фактические результаты существенно отклоняются от планов, то вносятся поправки, и управление этим процессом не заканчивается до его закрытия Изменения в обязательствах согласовываются с заинтересованными группами и отдельными лицами
Управление субподрядами на разработку ПО (управленческая область)	Главный подрядчик и субподрядчик договариваются о взаимных обязательствах Главный подрядчик отслеживает фактические показатели выполнения обязательств в соответствии с договоренностями Главный подрядчик и субподрядчики поддерживают постоянное взаимодействие Главный подрядчик отслеживает фактическую производительность субподрядчика в соответствии с обязательствами
Обеспечение качества ПО (техническая область)	Планируются действия, обеспечивающие качество ПО Проверяется строгое соответствие программных продуктов и действий применяемым стандартам, процедурам и требованиям Заинтересованные группы и отдельные лица информируются о действиях и результатах, обеспечивающих качество ПО Вопросы несоответствия, которые не могут решиться внутри проекта, направляются высшему менеджменту
Управление конфигурацией ПО (техническая область)	Планируется деятельность по управлению конфигурацией ПО Определяются, контролируются и делаются доступными избранные программные рабочие продукты Контролируются изменения в определенных программных рабочих продуктах Заинтересованные лица информируются о содержании и состоянии базовой линии проекта

Исходя из этих целей:

• создается и поддерживается план управления проектом.
• Оцениваются, согласно плана, характеристики выполняемого проекта. Если фактические показатели значительно отклоняются от плана, принимаются соответствующие меры.
• Требования должным образом документируются, а изменения требований координируются.
• Осуществляется контроль всех рабочих продуктов. Внесение изменений в продукты выполняется через планомерное управление конфигурацией.
• Для гарантирования выполнения процесса проводятся аудиты и экспертизы.
• Работа по субподрядам должным образом отслеживается.

  Уровень 3 
Применяется специализированная версия стандартного процесса, повторно используются активы проекта, данные и опыт планирования из предыдущих проектов. Заинтересованные стороны взаимодействуют между собой посредством точно определенных интерфейсов и механизмов. Для определения ошибок в рабочих продуктах организовываются экспертизы, их проведение и выполнение доработок по их результатам имеют достаточную поддержку. В таблице указаны KPA уровня 3, которые относятся к управлению проектами:

KPA	Цели
Интегральное управление разработкой ПО	Определенный для проекта процесс разработки ПО является специализированной версией стандартного процесса разработки ПО в организации Проект планируется и исполняется в соответствии с определенным для него процессом разработки ПО
Межгрупповая организация	Требования заказчика согласовывается всеми заинтересованными сторонами Все стороны согласовывают взаимные обязательства Стороны определяют, отслеживают и разрешают межгрупповые вопросы
Экспертизы специалистов	Планируется проведение экспертиз Определяются и устраняются ошибки в программных рабочих продуктах

Уровень 4 
На этом уровне устойчивость процесса понимается на количественном уровне. Устойчивость процесса используется для установки количественных целей проекта. Данные по производительности постоянно собираются и сравниваются со статистическими данными по производительности в завершенных проектах. При значительных отклонениях применяются корректирующие действия, которые позволяют восстановить контроль над проектом. Ключевой аспект этого уровня - постоянное применение приемов статистического контроля процесса, поэтому можно оценить каждое действие и при необходимости откорректировать его. Приведены только две KPA

KPA	Цели
Количественное управление процессом	Планируются действия по количественному управлению процессом Производительность процесса, определенного для проекта, контролируется в количественном отношении Устойчивость стандартного процесса в организации известна в количественном измерении
Управление качеством ПО	Планируются действия по управлению качеством ПО в проекте Определяются измеряемые цели качества ПО и из приоритеты Измеряются фактические показатели качества программных продуктов и принимаются действия по их достижению

  Уровень 5 
Области этого уровня нацелены на улучшение устойчивости процесса. Наибольшее внимание заострено на предупреждении ошибок путем систематического анализа причин возникновения ошибок и принятием мер для их предупреждения. Предупреждение ошибок позволяет сэкономить на исправлении возникших ошибок.

  1.3. Управление проектами в компании InfoSys 
1.3.2. Поддержка проектов со стороны SEPG 
SEPG - software engineering process group. Отвечает за координацию всей деятельности, связанную с процессами, в том числе за определение, совершенствование, размещение процессов. Также управляет всей информацией, связанной с использованием процессов и базовой линией устойчивости процесса. Также формирует независимый канал для мониторинга выполнения проекта и отправки отчетов менеджменту по вопросам процесса и качества. Также занимается внедрением процессов в обычную практику. Выделяется сотрудник, который является членом команды проекта и отвечает за качество продукта. Также предоставляет помощь при планировании, обучении. Также проводит экспертизу плана управления проектом.

  1.3.3. Привлечение к проектам старших руководителей 
Менеджер проекта отвечает за проект от начала и до конца, с определения требований и до поставки и установки продукта. Он отчитывается бизнес-менеджеру. Бизнес-менеджер отчитывается главе подразделения. Для разрешения ситуаций, с которыми не может справиться руководитель проекта, привлекается старший менеджмент. Команда проекта может поднять вопрос перед бизнес-менеджером. Бизнес-менеджер также контактирует с заказчиком. Старшие руководители принимают участие в аудите проекта. Им информация доступна посредством двух систем: обзора проекта старшим менеджментом и интегральному управлению проектами. Согласно этому, старшие менеджеры должны периодически проводить аудит проектов и выдавать рекомендации руководителям проектов.

  1.3.4. Обучение менеджеров проектов 
Все новые сотрудники проходят 3-4 месячную ознакомительную обучающую программу:

1. Курсы по инженерии и технологиям
2. Профессиональная этика бизнеса,
3. Правила ведения переписки
4. Публичные выступления
5. Жестикуляция, мимика, …

  Для кандидатов в лидеры модулей ПО/менеджеров проектов:

1. Техническая программа
   1. 5-ти дневная программа по планированию, мониторингу, … проектов.
   2. 2-х недельные курсы по определению требований, документированию, проверке, …
   3. 5-ти дневная программа по оцениванию, управлению командой, общению с заказчиками, лидерству, социальной и деловой этике разных стран, и т.д.
2. Обучающая программы
   1. Разнообразные аспекты управление. PM обучаются, когда позволяет их календарный план.
   2. Рабочие семинары по созданию команды.

  1.3.5. Процесс управления проектом 
Процесс управления проектом:

1. Планирование проекта
2. Выполнение проекта
3. Закрытие проекта

  Планирование проекта
Руководитель проекта изучает контрактные обязательства и разрабатывает план по их выполнению. План проекта:

• Определение процесса жизненного цикла
• Оценивание трудоемкости и сроков работ
• Подготовка детального графика задач
• Управление качеством
• Управление конфигурацией
• Управление рисками

Менеджер проекта:

• Выполняет административные и подготовительные задачи.
• Создает план и график проекта
  • Определяет цели проекта
  • Устанавливает подходящий стандартный процесс выполнения проекта
  • Адаптирует стандартный процесс к требованиям проекта
  • Определяет процесс управления изменениями в требованиях
  • Оценивает трудоемкость
  • Планирует людские ресурсы и структуру команды
  • Определяет ключевые точки проекта и создает график работ
  • Определяет цели качества и план их достижения
  • Разрабатывает план предупреждения ошибок
  • Выявляет риски и разрабатывает план по их смягчению
  • Определяет план измерений для проекта
  • Определяет план обучения для проекта
  • Определяет процедуры отслеживания проекта
• Выполняет экспертизы плана и графика работ по проекту
• Получает одобрение плана и графика работ от вышестоящего руководства
• Создает план управления конфигурацией и проводит его экспертизу
• Ориентирует команду проекта в соответствии с планом управления проектом

К этим работам привлекаются: заказчик, представитель SEPG и бизнес-менеджер по этому направлению. Входом процесса является одобренный контракт или проект. Выходы - документированный план проекта и его экспертиза.
  Выполнение проекта
Включает

• Выполнение плана проекта,
• Отслеживание состояния проекта
• Внесение корректировок в любой момент, когда характеристики проекта отклоняются от пути, проложенного планом.
• Мониторинг состояния
• Мониторинг качества проекта
• Проведение необходимых корректирующих шагов.

Менеджер проекта:

• Выполняет проект согласно плана проекта
• Отслеживает состояние проекта
• Вместе с вышестоящим руководством проверяет состояние проекта
• Анализирует ошибки и выполняет действия по их предупреждению
• Отслеживает соблюдение процесса, определенного для проекта
• Анализирует ошибки и выполняет действия по их предупреждению
• Отслеживает выполнение на уровне программы
• Проводит экспертизы в контрольных точках этапов и при необходимости изменяет план

Члены команды выполняют задачи согласно плана проекта. Вход процесса - одобренный план проекта Выход процесса - поставка всех рабочих продуктов и приемка их заказчиком.

  Закрытие проекта
Включает планомерное завершение проекта после приемки заказчиком. Основная цель - изучение полученного опыта для дальнейшего усовершенствования процесса. Анализ данных: система показателей, для будущего использования собирается все, что было накоплено процессом, шаблоны и инструкции, фиксируются полученные уроки. Подведение итогов - групповая деятельность, в которой участвуют руководитель проекта, представитель SEPG, другие члены команды, чтобы каждый мог получить и оценить полученный опыт. Вход процесса - приемка заказчиком работ. Выход процесса - проведение заключительного совещания, отчет о закрытии проекта, собранные данные о выполнении проекта. 


1.5. Итоги

• Процессы для различных аспектов управления проектом не следует рассматривать изолированно. В сбалансированном процессе практики интегрируются без помех.
• Процессы организации должны включать ее лучшие практики, чтобы помочь новым проектам воспроизвести достигнутые в прошлом успехи и избежать неудач.
• На верхнем уровне процесс управления проектом включает три стадии:
  • Планирование
  • Исполнение
  • Закрытие
• Для эффективного выполнения проектов менеджеры проектов должны получить поддержку и помощь от SEPG в выполнении процессов, в от вышестоящего руководства - в мониторинге и разрешении проблем. Менеджеры проектов должны пройти качественное обучение.
• Многие ключевые области процесса на всех уровнях зрелости CMM для разработки ПО непосредственно ориентированы на управление проектом.