Роль руководителя проекта в RUP

Зайцев С.Л.

Оглавление

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

Миссия руководителя проекта

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

Сложная роль

"Персонал, продукт, процесс, проект - именно в этом порядке", - вот как тот же Роджер Прессман определяет функциональные границы управления проектами разработки ПО.

  • Персонал. Разработка ПО является очень ресурсоемкой и зависит, главным образом, от навыков персонала и от координации работ между сотрудниками. Многие из задач руководителя проекта связаны с персоналом и будут фокусироваться в основном на группе разработчиков.
  • Продукт. До тех пор, пока не будут четко определены цели и функциональные границы ПО, не следует ничего планировать, изучать или создавать. И хотя руководитель проекта не определяет всех деталей требований, ваша роль состоит в том, что убедиться в постановке целей и организации отслеживания хода работ в соответствии с этими целями. Для решения этих задач необходимо интенсивное общение как внутри самой команды разработчиков, так и с внешними партнерами.
  • Процесс. Если кто-нибудь и имеет полное понимание процесса разработки ПО, то это именно руководитель проекта. Управление проектом является самим воплощением процесса. Применение или неприменение RUP не имеет совершенно никакого значения, если управление процессом разработки недостаточно грамотно. Процесс разработки, с поддержкой правильно выбранных инструментальных средств, является общей дорожной картой, понимаемой и используемой всеми членами группы разработки.
  • Проект. И лишь после этого, двигаясь в запланированном направлении, руководитель проекта управляет самим проектом, и, по мере необходимости, занимается планированием, контролем, мониторингом и коррекцией траектории движения проекта. Руководитель проекта занимается динамическим управлением и адаптацией.

Руководителю программного проекта следует полагаться только на результаты, а не на героические усилия, искренние намерения, использование правильного процесса или же неотступное следование "учебнику". Поэтому на протяжении всего жизненного цикла разработки руководитель проекта должен фокусировать свое внимание на окончательных или на каких-либо промежуточных результатах, приближающих процесс к успешному завершению. Проект RUP является результатом совместных усилий нескольких сторон, среди которых и руководитель проекта. Учитывая динамический контекст итеративной разработки, роль руководителя проекта отражается скорее фразой "направлять и адаптировать", чем "планировать и отслеживать выполнение" (практика, обычно используемая при работе над обычными проектами).

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

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

Один человек или группа?

Вероятно, при работе над большими проектами роль руководителя проекта придется выполнять нескольким сотрудникам.

Мы склоняемся к мнению, что на должность руководителя проекта следует назначать одного сотрудника. И в большинстве от малых до средних проектов (от 3 до 15 человек), только один сотрудник будет выполнять эту роль. Но RUP описывает руководителя проекта не как персону, а как роль, которую эта персона будет выполнять, и есть вероятность, что при работе над большими проектами эту роль будут выполнять несколько персон. Тем не менее, разумно существование лишь одного явного лидера проекта, но, управляя проектом, этот сотрудник не должен ощущать потребности в выполнении всех задач RUP.

Прежде всего, может существовать небольшая группа сотрудников, осуществляющая руководство проектом. Один сотрудник может заниматься планированием; другой - иметь дело с некоторыми ключевыми коммуникационными интерфейсами, с менеджерами по продукту или заказчиком; еще один может отслеживать ход внутренних работ. Следует иметь в виду, что некоторые из этих специализаций уже учтены в RUP, где определены более одной роли руководителя; существуют роли руководителей с соответствующей специализацией, например, менеджер по конфигурации, менеджер по развертыванию, менеджер по тестированию и инженер по процессу разработки.

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

В крупных проектах некоторые группы могут быть сформированы для выполнения определенных управленческих задач более формальным образом и для поддержки руководителя проекта:

  • Для мониторинга хода работ по проекту: Руководство (Project Review Authority - PRA) и Совет по управлению изменениями (Change Control Board - CCB)
  • Для запуска и оптимизации процесса разработки: руководство по разработке продукта (Software Engineering Process Authority - SEPA, иногда также называемое SEPG)
  • Для создания определения и адаптации инструментальных средств, руководство по среде создания программного продукта (Software Engineering Environment Authority - SEEA)

Эти группы формируются из сотрудников, имеющих соответствующую квалификацию и полномочия, иногда из людей, работающих в режиме полной занятости, и функционируют по мере необходимости, обеспечивая поддержку управленческой группы.

Управление проектом

"Управление проектом является результатом приложения знаний, навыков, применения инструментальных средств и техник к проектным задачам с целью достижения соответствия потребностям и ожиданиям лиц, заинтересованных в проекте."

Достижение и даже превышение результатов, ожидаемых от проекта со стороны заинтересованных лиц, несомненно, включает балансирование между взаимопротивоположными требованиями

  • Функциональные границы, время, затраты и качество.
  • Заинтересованные лица, как внешние, так и внутренние, с различными потребностями и ожиданиями.
  • Идентифицированные требования (потребности) и неидентифицированные требования (ожидания).

Функциональные границы процесса управления проектом в RUP

Здесь следует сделать важное замечание. Методология RUP сознательно не затрагивает всех аспектов управления проектами, фокусируясь главным образом лишь на технических аспектах.

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

Аналогично, RUP не затрагивает никаких финансовых вопросов, таких как бюджет, распределение, учет или составление отчетов. Кроме того, в RUP не рассматриваются юридические или договорные вопросы, приобретение и сбыт, лицензирование и работа с субподрядчиками. Также RUP не имеет дела с некоторыми административными вопросами, связанными с персоналом, финансами и проектами.

Для всех этих тем во всем мире существует широкий диапазон практик, вместе с легко доступной обширной информацией, не связанной конкретно с разработкой ПО.

Одним из наиболее ценных источников информации является Руководство к совокупности знаний по управлению проектами (PMBOK) , разработанное с помощью Института управления проектами (PMI) и принятая комитетом IEEE в качестве Стандарта 1490-1998, Адаптация руководства PMI для PMBOK.

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

План разработки продукта (SDP)

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

Мы считаем, что в настоящее время руководитель проекта должен уделять максимальное внимание следующим направлениям:

  1. Четко сформулировать планы проекта (ожидания со стороны руководства проектом) в различных областях: функциональные границы, время, затраты, качество, процесс.
  2. Понять, что может неблагоприятно повлиять на эти планы с течением времени; т.е. проанализировать риски, возникающие при отклонении проекта от указанных планов.
  3. Отслеживать ход выполнения работ для контроля того, насколько проект соответствует намеченному плану, с использованием максимально объективных метрик.
  4. Пересматривать любые из этих планов, если проект значительно отклоняется от намеченного графика.
  5. И в заключение - учиться на своих ошибках, чтобы организация не повторяла их при последующих итерациях или в следующем проекте.

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

  • План проекта и планы итераций (см. Раздел 12)
  • План тестирования
  • План конфигурационного управления
  • План контроля метрик проекта
  • Риски
  • План документирования
  • Определенный процесс, который будет использован в проекте - описание процесса разработки проекта

Для лучшей ясности, визуализации и отчетности План разработки программного обеспечения может быть отнесен к формальным (обязательным) артефактам проекта.

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

  • Запись о результатах рецензирования
  • Список вопросов
  • Оценка статуса проекта

Одним из важных аспектов SDP является более точное определение процесса, который будет использовать проект: в этом и состоит роль описания процесса разработки проекта. Руководитель проекта также должен установить и поддерживать соответствующую степень формальности, или адекватного для данного проекта "уровня церемониальности", как называет его Грейди Буч. И это описание процесса разработки также будет эволюционировать с продвижением проекта, основываясь на уроках, полученных при каждой итерации.

Итеративная разработка

Итеративная разработка является лейтмотивом данной статьи, но не помешает сказать об этом еще раз. В итеративной обработке вам не нужно, однажды составив план, затем заниматься лишь мониторингом проекта, пытаясь удержать его в рамках запланированных затрат. Вы планируете и затем перепланируете, делая это снова и снова. Таким образом, вы можете оказаться в ситуации, отличной от той, которая прогнозировалась в первоначальном плане, но вы найдете, что эта ситуация будет не хуже планируемой, или же более скромной, но вместе с тем более реалистичной, что естественно лучше, чем отсутствие каких-либо результатов.

Если вы никогда не руководили итеративным проектом, то вполне вероятно, что первоначально вы будете в замешательстве.

Риски

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

Метрики

Другим ключевым словом для руководителя проекта RUP являются метрики. Во избежание увода в сторону за счет субъективности или недостатка знаний, руководитель проекта устанавливает некоторые объективные критерии для отслеживания (более или менее автоматического) некоторых аспектов проекта. Эти критерии могут использоваться для сбора таких характеристик, как затраты, уровень завершенности (как много функциональности реализовано), покрытие тестирования (как много протестировано), и дефекты (обнаруженные и исправленные), а также отслеживания изменений этих показателей со временем. Другие полезные метрики предназначены для отслеживания изменений во времени: объемы брака или переработки, или хаотические изменения в требованиях, которые могут отслеживаться с помощью хорошей системы конфигурационного управления. Опытный руководитель проекта захочет максимально автоматизировать сбор подобных метрик, чтобы высвободить больше времени для задач, требующих более интенсивного межличностного общения.

Метрики, собранные для текущего проекта и для предшествующих проектов, являются тем, что сможет помочь группе разработчиков провести оценку, в частности оценку объема работ. Эти оценки лежат в сфере совместной ответственности руководителя проекта и остальной группы разработки. Руководитель проекта не должен устанавливать эти метрики в одностороннем порядке.

Задачи руководителя проекта

Итак, чем же конкретно по методологии RUP занимается руководитель проекта?

В RUP все задачи сгруппированы по темам:

  • Задачи по запуску нового проекта
  • Задачи по определению и вовлечению всех элементов Плана разработки продукта
  • Задачи по запуску, выполнению и закрытию проекта, фазы или итерации
  • Задачи по мониторингу проекта

Запуск нового проекта

Основываясь на первоначальном документе Концепции системы, руководитель проекта разрабатывает первоначальное экономическое обоснование, сопоставляющее функциональные границы проекта (вместе с ожидаемой продолжительностью и затратами) и потенциальную прибыль. Концепция системы отражает истинный смысл требований: чего именно вы хотите достичь. В Экономическом обосновании формулируются основные причины реализации данного проекта. Прежде чем проект будет инициирован и утвержден, Концепция системы и Экономическое обоснование проекта должно быть пересмотрено много раз. Следует как можно раньше начать идентификацию рисков, т.е. любых событий, которые могут неблагоприятно повлиять на проект или вообще привести к невозможности его завершения. Эти риски будут первостепенными вопросами, решением которых следует заняться на следующей итерации проекта.

Создание плана разработки продукта

В зависимости от функциональных границ и размера проекта, руководитель проекта будет создавать некоторые или же все SDP. Организация может уже иметь разработанные готовые для использования шаблоны, с уже заполненными готовыми сегментами, которые будут более подходящими, чем уже имеющиеся в RUP.

Имеются два важных раздела SDP:

  • Планирование времени и ресурсов, в плане проекта и плане комплектования штатов (которые будут более подробно описаны в главе 12).
  • Спецификация процесса, который будет использовать проект: создаваемые артефакты и уровень церемониальности и формальности, приводимые в описании процесса разработки проекта. Это включает определенные руководства, руководства по стилю программирования, а также соглашения, используемые в проекте.

Другие планы описывают конфигурационное управление, документирование, тестирование, инструментальные средства, и т. п. атрибуты разработки.

Запуск и закрытие фаз и итераций

Руководитель проекта будет проводить более подробное планирование объема работ и целей фаз и итераций, указав критерии успеха, которые будут использованы для оценки работы на соответствующих этапах. Эти задачи потребуют расширенного взаимодействия со всеми членами группы, не могут быть выполнены в башне из слоновой кости. Каждая фаза и итерация потребуют соответствующего комплектования персоналом с последующим распределением задач среди членов группы.

После завершения итерации (или фазы с основными этапами), руководитель проекта получит доступ к результатам итерации или фазы, и сравнит их с ожидаемыми результатами, приведенными в SDP. Расхождения приведут к пересмотру планов или к формированию других функциональных границ проекта. Сам процесс может быть улучшен.

Например, при обзоре предварительно идентифицированных рисков ("Интеграция технологии X со связующим ПО Y"), вы пришли к выводу, что вы действительно успешно интегрировали эту технологию в прототип и протестировали ее, устранив таким образом данный риск.

Мониторинг проекта

В качестве непрерывно выполняемой задачи руководитель проекта будет использовать некоторые индикаторы для отслеживания хода проекта и сравнения его с планами. Это может делаться на различных уровнях формальности и использовать комбинацию метрик (такую как обнаружение дефектов и процент их устранения) и рецензий (неформальных и формальных) для оценки соблюдения планов и достижения качества продукта.

Например, если частота обнаружения дефектов значительно падает, это является сигналом о том, что (а) работы по тестированию ведутся неэффективно, (b) что новые сборки системы не привносят какой-либо существенной функциональности, или же (c) продукт просто становится стабильным.

Существует, по крайней мере, одна оценка за итерацию, и кое-что более формальное при закрытии фазы, так как эти главные этапы проекта могут включать некоторые стратегические решения, относящиеся к выполнению проекта. Эти этапы являются моментами, когда могут рассматриваться отмена или значительное изменение функциональных границ проекта.

Нахождение своей роли в RUP

Для того, что начать работу с RUP, жизненно важно, чтобы руководитель проекта хорошо понимал концепцию итеративной разработки и жизненный цикл RUP (фазы и итерации). Кроме того, существуют некоторые ключевые концепции: управление рисками, качество, метрики, а также то, как описывается процесс (роли, задачи, артефакты). При необходимости обратитесь за определениями в словарь RUP. Если вы хорошо знакомы с тематикой руководства проектами, но незнакомы с итеративными проектами разработки ПО, то основной объем обучения можно получить в области RUP, относящейся к планированию, в частности планированию итеративных проектов.

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

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

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

Заключение

Следование определенному процессу, такому как экземпляр RUP, ни в коем случае не является для руководителя проекта путем уклонения от ответственности и отказа от чувства здравого смысла. Эта работа не является механической разработкой каких-либо артефактов, описанных в RUP, в надежде на то, что процесс пойдет в правильном направлении. Задача не состоит в распределении всех задач RUP для членов группы с последующим выражением недоумения, "Да я же просто следовал RUP! Совершенно не понимаю, почему проект провалился". Для достижения успеха вам следует выбрать в RUP правильный набор артефактов, правильные методы и техники, и адаптировать их к вашему контексту. Вы должны обладать глубоким пониманием проекта и продукта, и уметь работать с архитектором, аналитиками, разработчиками и тестировщиками.

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

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

Итак, подведем итоги:

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

Ресурсы для руководителя проекта

Дополнительная литература

  • Murray Cantor. Software Leadership: A Guide to Successful Software Development. Boston: Addison-Wesley, 2002.
  • Tom Gilb. Principles of Software Engineering Management. Reading, MA: Addison-Wesley, 1988.
  • James A. Highsmith. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York: Dorset House Publishing, 2000.
  • IEEE Standard 1490-1998. "Adoption of the PMI Guide to the Project Management Body of Knowledge." New York: IEEE, 1998.
  • IEEE Standard 1058-1998. "Standard for Software Project Management Plans." New York: IEEE, 1998.
  • Steve McConnell. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1997.
  • Fergus O’Connell. How to Run Successful Projects. Upper Saddle River, NJ: Prentice-Hall, 1994.
  • PMI. Guide to the Project Management Body of Knowledge (PMBOK Guide). William R. Duncan (editor). Newton Square, PA: Project Management Institute (PMI), 2000.

Web-ресурсы


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=4682