За ответами менеджеры проекта обычно обращаются к архитекторам, затем к разработчикам, потом к тестировщикам и т.д. Даже имея сертификат Project Management Professional (PMP), менеджеры проекта часто ощущают зависимость от экспертов в предметной области. Кроме того, им приходится приспосабливать свои знания и навыки к специфике дисциплин IBM Rational Unified Process (RUP), поскольку коллективы разработчиков часто используют эту методологию.
В данной статье представлен взгляд на управление проектами в современной ИТ-ориентированной компании. Статья содержит обзор распространенных заблуждений относительно RUP как средства управления проектами, обсуждение точек пересечения RUP и стандарта Project Management Body of Knowledge (PMBOK) и описание способов уменьшения или полного устранения неоднозначностей, часто возникающих при совместном рассмотрении этих взаимодополняющих инфраструктур построения процессов. Завершает статью описание и обзор потенциального значения роли корпоративного менеджера проекта.
Мой опыт в качестве архитектора предприятия позволил мне включить в статью краткий обзор архитектурной составляющей управления проектом. Данная статья может помочь архитекторам, работающим в области ИТ, понять ожидания менеджеров проекта, а последним она даст возможность больше узнать о RUP и ИТ-архитектуре.
Что нам известно об управлении проектом
Согласно популярной интернет-энциклопедии, проект - это "временная деятельность, направленная на достижение определенного результата, создание определенного уникального продукта или услуги". Для выполнения любого проекта требуются ресурсы, в том числе трудовые и финансовые. Цель дисциплины управления проектом заключается в организации данных ресурсов и управлении ими способом, обеспечивающим создание продукта или услуги при соблюдении объема, уровня качества, сроков и стоимости.
Несмотря на то, что стиль управления проектом приблизительно соответствует используемой методологии жизненного цикла разработки программного обеспечения (например, водопадный метод, итеративный подход, быстрая разработка (Rapid Application Development, RAD), Agile), любой проект включает следующий набор работ:
- Планирование, анализ и проработка целей проекта
- Оценка рисков и управление рисками
- Определение трудозатрат и выделение ресурсов
- Получение трудовых и материальных ресурсов
- Организация работы путем распределения задач и руководство работами
- Анализ достигнутых результатов
- Проектное прогнозирование
- Управление качеством
- Предотвращение и разрешение проблем
- Завершение проекта
- Управление коммуникациями
- Отслеживание состояния выполнения работ и подготовка отчетности
Институт управления проектами (PMI), основанный в конце 1960-х годов, является одной из ведущих организаций в области управления проектами. Институт насчитывает более 220 тысяч членов, включая 160 тысяч сертифицированных специалистов из более чем 170 стран. В PMI была разработана одна из наиболее всеобъемлющих программ сертификации профессионалов по управлению проектами (PMP), предусматривающая несколько уровней.
PMP - наиболее признанная в мире, если судить по числу сертифицированных специалистов, программа сертификации менеджеров проекта. Программа предусматривает три уровня сертификации - уровень ассоциированного менеджера проекта, уровень менеджера проекта и ученую степень в области менеджмента программ.
PMBOK представляет собой сборник типовых процессов, знаний и лучших методов работы, являющийся общепризнанным стандартом в области управления проектами. Он включает пять групп процессов (например, инициации и планирования) и девять областей знаний (например, управление содержанием и управление сроками), применимых в большинстве предметных областей от строительства до разработки программного обеспечения. PMBOK описывает процессы в терминах входов (input artifacts), инструментов и методов. Методы потребляют и производят артефакты-входы и используют инструменты.
Среди множества различных ролей менеджеров только одна имеет уточнение "...проекта". В динамичной среде современного бизнеса эта роль стоит особняком, поскольку требует от исполнителя понимания уникальных свойств проектов и особенностей принципов управления, характерных для предметной области. В случае разработки программного обеспечения такие свойства и особенности выражаются терминами "итеративный", "управляемый архитектурой" и "направленный на снижение рисков".
В отличие от проектной деятельности, являющейся временным и разовым мероприятием, многие операционные задачи повторяются, при этом каждое повторение имеет одно и то же базовое содержание (не путать с итеративной разработкой, при которой задачи повторяются, но различаются содержанием или отдельными деталями). Примером операционной деятельности являются функции управления трудовыми ресурсами и запасами, при решении которых управление сводится к обеспечению адекватного ежедневного и последовательного выполнения текущих задач. Люди, являющиеся исполнителями данной роли, могут занимать различные управленческие должности и решать типовые задачи управления.
В отличие от ролей функциональных руководителей, роль менеджера проекта создана специально для решения уникальных задач. Менеджер проекта, таким образом, должен понимать область своей ответственности, а также выбирать и применять оптимальный процесс управления для создания продукта или услуги в срок и в пределах заданных ограничений. Эти задачи, в сочетании с работами по инициации и завершению проектов, составляют неотъемлемую часть обязанностей менеджера проекта и являются отличительной стороной его роли по сравнению с ролями других менеджеров предприятия.
Исполняющий обязанности менеджера проекта
Часто получается так, что новый проект не имеет выделенного менеджера. Повсеместно встречается ситуация, когда обязанности менеджера проекта частично или в полном объеме принимает на себя опытный член группы. Несмотря на то, что в общем случае наличие временного или частично занятого менеджера проекта лучше, чем его полное отсутствие, существование исполняющего обязанности менеджера в течение длительного времени считается неправильным, поскольку подвергает риску непрерывность и последовательность принятия решений. Более того, временным менеджером проекта зачастую становится член группы, не имеющий достаточного опыта или мотивации для исполнения дополнительных обязанностей, что приводит к несоответствию результата проекта ожиданиям или к полному фиаско.
Нередко роль менеджера проекта совмещается с ролью архитектора решения или технического руководителя. Несмотря на то, что такое совмещение часто приносит негативные результаты, оно может оказаться вполне оправданным в случае, если проектная группа невелика (обычно не более 10 участников). Преимуществом наличия в группе технического менеджера проекта является то, что он может осуществлять грамотное планирование проекта за счет глубокого понимания требований и/или принципов проектирования программного обеспечения. Это, в свою очередь, может устранить эффект "испорченного телефона" в группе разработки. Недостаток данного подхода заключается в том, что технический менеджер проекта может не иметь времени, достаточного для планирования проекта, не говоря уже о полном охвате и управлении всеми аспектами проекта.
Проекты могут быть настолько сложны и масштабны, что управлять ими становится практически невозможно. Распространенным решением этой проблемы является организация иерархической структуры управления проектом, самый верхний уровень которой называется программой, а последующие уровни представляют собой проекты. Управление программой является особой разновидностью управления проектами, рассматривающей совокупность проектов как единое целое и в то же время не упускающей из виду состояние выполнения каждого проекта в отдельности. К основным обязанностями менеджера программы относятся деление содержания программы на отдельные управляемые фрагменты (проекты), документирование и управление зависимостями проектов, планирование и выполнение эскалации и делегирования.
Современная организация представляет собой достаточно сложную сущность, в которой на регулярной основе происходит выполнение работ без оформления их в виде проектов. Одним из примеров является реализация архитектуры предприятия и ее различные этапы, такие как разработка концепции, разработка бизнес-сценариев и анализ бизнес-процессов. Некоторые их этих функций могут быть довольно сложными и, следовательно, трудными для управления, если им своевременно не были заданы жесткие границы. Эксперты предметной области, например архитекторы, инженеры процессов и консультанты редко обладают навыками, необходимыми для решения задач, стоящих перед менеджером проекта предприятия. Данное обстоятельство определяет необходимость роли менеджера проекта предприятия, о которой я подробно расскажу ниже.
Основные заботы менеджера проекта
Хотя некоторые менеджеры проекта выглядят более рациональными, информированными, склонными к доверию или опытными, чем другие, каждый из них сталкивается с одними и теми же проблемами. Самые важные из них перечислены ниже.
Менеджеры проекта разочаровываются в своих архитекторах, получая от них оценки трудозатрат с запасом в 20, 50 или даже все 100%. Несомненно, многие отрасли достигли уровня развития при котором измерения, оценки и план проекта могут быть получены исключительно на основе стандартной терминологии, высокоуровневого описания содержания работ и отраслевых норм производительности. Зная об этом, менеджер проекта может ожидать того же самого и в индустрии разработки программного обеспечения. Подобные ожидания, однако, зачастую оказываются неоправданными. В ИТ-индустрии, где всё, начиная с инфраструктур и платформ и заканчивая методологиями и инструментами, находится в состоянии постоянного развития, получение результатов адекватной точности требует глубокого понимания требований.
В современной индустрии разработки программного обеспечения значительный объем работ может быть оценен с приемлемой точностью только в том случае, если оценка основана на детальных, структурированных, разработанных с учетом конкретной методологии требованиях [4] и использует нормы производительности, основанные на результатах ранее успешно завершенных проектов, выполненных одной и той же группой и с использованием одних и тех же технологий. Оценки, сделанные архитекторами, очень часто основываются или на неструктурированных требованиях (что нехорошо), разработанных на основе аналогичных существующих решений (что плохо) или на оценках трудозатрат, полученных от проектных групп (что еще хуже).
Являясь посредником между организацией-заказчиком и проектной группой, менеджер проекта часто оказывается между молотом потребностей и наковальней действительности. Примером, особенно наглядно демонстрирующим данный разрыв, является несоответствие выделенных ресурсов оценке затрат. В большинстве случаев данная проблема возникает из-за того, что в момент распределения бюджета организации требования были не просто не поняты, а даже еще не собраны. Фактически проектной команде предлагается понять, что может быть разработано в данных обстоятельствах. Менеджеру проекта в такой ситуации остается надеяться на то, что оценки, сделанные архитектором перед началом проекта, окажутся верными.
Часто успех проекта зависит от правильности выбора и применения методологии. В отличие от строительства и производства, при разработке программного обеспечения существует широкий выбор методологий любого стиля и на любой вкус - от очень формальных до очень гибких. Менеджер проекта редко принимает участие в выборе методологии, но практически всегда отвечает за правильное следование ей. Таким образом, менеджер проекта должен проявить прагматизм и волю к сотрудничеству когда дело дойдет до выбора методологии для использования в проекте.
По роду своей деятельности большинство менеджеров проекта неспособно дать объективную оценку решениям по архитектуре и проектированию. Вместо этого они вынуждены положиться на мнение кого-либо из членов группы - обычно им является архитектор или ведущий разработчик. Неудивительно, что каждый менеджер проекта стремится выстроить безупречные отношения с этим коллегой. Архитектор, оказывающий содействие менеджеру проекта при принятии решений и подготовке соответствующей документации, должен понимать последствия упомянутой зависимости и относиться к этому с пониманием.
В некоторых организациях бюрократия и политика берут верх над конструктивной логикой. Замечательно когда и проектная группа и группа менеджеров одинаково мотивированы. В этом случае они скорее всего выберут "минималистичный" метод реализации, который позволит прагматично подойти к распределению областей ответственности между всеми участниками. Если же обязанности распределены недостаточно прозрачно, менеджеру проекта следует прибегнуть к использованию подхода, основанного на четко определенном владении и распределении ответственности, например, на модели RACI (Responsible Accountable Consulted Informed). Безусловно, хорошие отношения с архитектором и спонсором проекта никогда не помешают, но и заменой четко сформулированной иерархии ответственности они быть не должны. Четкая структура ответственности - страховочная сетка для менеджера проекта, которая к тому же делает процесс прозрачным для остальных участников проектной группы.
Распространенные заблуждения относительно RUP
Беседуя с менеджерами проекта я часто отмечаю их неуверенность и колебания когда дело касается применения задач управления проектами при использовании RUP. Больше всего меня удивляет их поверхностное понимание концепций и принципов этой методологии. Как правило большинство из них немедленно вспоминают, что RUP является итеративным процессом, но в то же время не понимают и не могут оценить базовые возможности и практические выгоды, которые дает применение данной методологии. Ниже приведены заблуждения, с которыми мне чаще всего приходилось сталкиваться, и мои комментарии по этому поводу.
Заблуждение: RUP является альтернативой стандарту PMBOK
Как это ни печально, RUP часто принимают за конкурента стандарта управления проектами PMBOK. Возможно, в основе этого непонимания лежит определение RUP как методологии, "обеспечивающей организованный подход к распределению задач и обязанностей в организации, занимающейся разработкой", вполне соответствующее управлению проектами. В данном случае это определение не только не может считаться показательным, но и совершенно неверно истолковано.
Хотя управление проектами входит в число девяти основных дисциплин RUP (рисунок 1), организации, применяющие эту методологию, могут быть также заинтересованы в наличии базовой инфраструктуры управления проектами. Соответствующая дисциплина RUP подробно рассматривает отдельные аспекты обязанностей менеджера проекта, относящиеся к планированию его работы и выполнению задач, особенно в части планирования итераций. В отличие от PMBOK, RUP не рассматривает управление проектами как основной процесс. Кроме того, RUP полностью оставляет без внимания некоторые важные задачи управления проектами, такие как управление трудовыми ресурсами, планирование ресурсов и оценка затрат, эскалация и управление коммуникациями.
Заблуждение: RUP - это только варианты использования
Анализ вариантов использования, несомненно, является одним из базовых методов RUP, поскольку реализует такую ключевую доктрину как итеративная разработка, способствующая снижению рисков. Но было бы неверным ставить знак равенства между моделированием и анализом вариантов использования и RUP в целом, поскольку эта методология позволяет использовать и другие нотации и методы до тех пор, пока они совместимы с ее базовыми принципами в контексте итеративного жизненного цикла. Анализ вариантов использования особенно полезен при описании приложений, активно взаимодействующих с пользователями и другими приложениями, но может оказаться менее полезным при разработке приложений или решений других типов, например тех, чье взаимодействие с пользователями сведено к минимуму или тех, при описании которых не требуется каждый раз заново моделировать взаимодействие (это относится, например, к коробочным продуктам). Применение вариантов использования вне сферы разработки программного обеспечения также может не оказаться разумной альтернативой, чего нельзя сказать о собственно RUP как инфраструктуре построения процессов и своде лучших методов работы.
Подводя итог вышесказанному, RUP представляет собой не только среду для управления вариантами использования, но и является конфигурируемой инфраструктурой построения процессов, которая может быть использована для итеративной и поэтапной разработки проектов. В более широком контексте методологии организации работы предприятия, который поддерживается IBM Rational Method Composer, работы, унаследованные от RUP, совместно с работами, заимствованными из других методологий и стандартов, могут использоваться для сборки процессов, полностью соответствующих индивидуальным потребностям организации.
Заблуждение: RUP отвлекает внимание от управления проектами
Поскольку менеджер проекта несет ответственность за проект и наделен полномочиями руководителя, многие считают его роль весьма значительной. Несмотря на то, что наличие у менеджера адекватных полномочий является одним из важнейших факторов успеха любого проекта, особенности высокоспециализированной индустрии разработки программного обеспечения таковы, что успех здесь зависит больше от профессионализма различных специалистов, в отличие, например, от сферы транспорта или массового производства. Следовательно, к роли менеджера проекта в индустрии разработки программного обеспечения следует относиться иначе. В свою очередь RUP не является процессом управления проектами, а сама индустрия разработки программного обеспечения не является тем местом, где можно управлять с помощью военных методов. В RUP роли дисциплин сбалансированы.
Центральная роль в RUP принадлежит дисциплине управления проектами, унаследованной от PMBOK. В типовом жизненном цикле RUP задачи управления проектом начинают выполняться ранее задач других дисциплин. Фактически, как показано на рисунке 1, эти задачи могут начать выполняться даже до официального старта проекта RUP (подробнее об этом ниже). С некоторыми предосторожностями и после анализа содержания проекта, основанного на требованиях, PMBOK можно использовать в качестве основного процесса, на котором будут строиться итерации, как показано на рисунке 1.
Рисунок 1. Дисциплина управления проектами RUP, разработанная на основе PMBOK
Важной особенностью RUP является то, что методология не принимает во внимание проблемы бюрократии и политики [2], что позволяет сосредоточиться на решении наиболее важных проблем - если только процесс управления проектом не сводится к последовательности команд "прячься", "надо" или "давай, давай", а направлен на создание профессиональных коллективов и управление ими. В этом случае RUP определенно способен помочь.
Другой вопрос, является ли RUP наилучшим решением проблемы. Некоторые организации настолько далеки от понимания и правильного применения стандартов управления проектами, что вряд ли могут достичь улучшения путем немедленного перехода на методологию жизненного цикла разработки программного обеспечения, такую как RUP. Вместо этого им следует рассмотреть возможность реинжиниринга существующих процессов, систем и методов путем применения структурной модели архитектуры предприятия, такой, как схема Захмана (Zachman Framework), для ликвидации отставания от индустрии. Это может помочь им лучше понять и документировать текущее состояние ИТ-архитектуры с последующей эволюцией в сторону применения единой нотации моделирования, например UML и в конечном итоге придти к использованию методологии жизненного цикла разработки программного обеспечения, подобной RUP.
Заблуждение: RUP сложнее водопадного метода
Если бы водопадный метод работал на практике так же хорошо, как выглядит в теории, управлять проектами с его помощью было бы легче, чем с помощью RUP, в первую очередь из-за отсутствия необходимости планировать итерации и управлять ими. Хотя это так только в теории.
Например, в инженерном деле вообще и в разработке программного обеспечения в частности никто не может быть уверен в том, что первоначальный проект и, соответственно, план работ по реализации будут оставаться в неизменном виде достаточно долго, не говоря уже обо всей продолжительности проекта. В действительности практика многочисленных проектов свидетельствует об обратном. Постепенное улучшение является неотъемлемой чертой инженерного дела, где, в отличие от строительства или производства, первоначальный проект имеет мало шансов на долгое существование, а динамика индустрии только ускоряет процесс внесения изменений.
Другим ложным предположением является вера в то, что проблему любой сложности можно решить с помощью подхода "Большого взрыва". Экспериментально (и научно) доказано, что рост сложности требует экспоненциального роста трудозатрат, что в свою очередь приводит к повышению затрат времени и росту требований к профессиональной подготовке специалистов. В основе RUP, напротив, лежит концепция снижения сложности путем деления задач на меньшие по объему, но важные по значению подзадачи, последовательно вносящие изменения в требования пользователей. Результат каждой из них имеет определенную ценность для заинтересованных лиц. Считается, что проект, включающий многочисленные подзадачи - "псевдопроекты" и, следовательно, итеративный подход в целом, требует больше трудозатрат на управление. Но дополнительные трудозатраты дают результат в виде повышения надежности в результате чего снижаются общие затраты на реализацию. На практике итеративный подход как правило добавляет уверенности группе разработчиков и снижает себестоимость проекта.
Управление проектами в итеративной среде является признанным профессиональным навыком, основанным на хорошем понимании принципов поэтапного проектирования, разработки требований и основ управления рисками. Стандарты управления проектами, такие как PMBOK, постепенно адаптируются к поэтапной сущности разработки программного обеспечения и приводят свои задачи и правила в соответствие с концепцией итеративного управления. RUP, в свою очередь, пытается облегчить управление проектными рисками, одобряя раннее вмешательство и планирование, основанное на требованиях, что позволяет достигать лучших результатов, хотя и требует повышенных трудозатрат.
Заблуждение: В RUP отсутствуют четкие условия начала и завершения проекта
Некоторым менеджерам проекта (по моим наблюдениям, это утверждение справедливо и для других менеджеров) не совсем очевиден момент начала проекта RUP и, в меньшей степени, момент его завершения. Менеджеры проекта часто спрашивают, выполняются ли в ходе жизненного цикла RUP задачи инициации проекта PMBOK, такие как привязка содержания проекта к стратегическим целям и обеспечение финансирования проекта.
Заслуживает упоминания (повторного) тот факт, что RUP представляет собой методологию разработки решений, которая берет за основу четко сформулированную потребность в разработке решения определенной бизнес-проблемы. Данная методология используется для решения проблем отдельной группы лиц, функционирующих в определенной части организации и участвующих в ограниченной части ее бизнес-процесса. Следовательно, работы, которые менеджеры проекта пытаются найти в RUP, лежат вне этой методологии. Однако некоторые из них нередко выполняются в ходе фазы начала проекта RUP и относятся как правило к дисциплине бизнес-анализа. Данный способ архитектурного планирования может считаться "антишаблоном" проектирования архитектуры предприятия, который к тому же противоречит PMBOK, в котором результаты анализа являются входом процессов принятия решений, выполняющихся в ходе инициации (рисунок 2).
Рисунок 2. Дисциплины RUP, PMBOK и Enterprise
Многие организации до сих пор не обзавелись группами разработки архитектуры предприятия, способными выполнить аккуратную трассировку стратегических решений к возможностям и компонентам разрабатываемых продуктов. К сожалению, область архитектуры предприятия (Enterprise Architecture), которая поддерживается такими методиками, как The Open Group Architecture Framework (TOGAF) и Catalyst, довольно медленно осваивается индустрией разработки программного обеспечения. Отчасти в силу низких темпов освоения, отчасти из-за существующих противоречий относительно их назначения, методики разработки архитектуры предприятия недостаточно полно описывают процессы перехода от собственно архитектуры предприятия к проекту решения. Процессы и инструменты дисциплин "Управление портфолио" и "Управление изменениями", служащие для решения разнообразных задач управления административным путем не предоставляют полной поддержки принятия решений на основе архитектурных соображений.
Rational Method Composer как способ расширения RUP до законченного процесса жизненного цикла масштаба предприятия является попыткой снятия части этих ограничений путем предоставления обширной процедурной и информационной поддержки, которая может быть выборочно использована для получения специализированного процесса, поддерживающего переходы между фазами методологии. Rational Method Composer включает руководство по объединению бизнес-целей, результатов анализа архитектуры бизнеса [TOGAF, Enterprise Unified Process (EUP) и другие] с запросами заинтересованных лиц и функциональными требованиями [RUP, Feature Driven Development (FDD), Scrum], а также с управлением ресурсами (PMBOK) и существующими системными архитектурами (Zachman). Для наиболее популярных моделей управления предприятием [например, Department of Defense Architecture Framework (DoDAF) или Capability Maturity Model Integration (CMMI®)], разновидностей архитектур решения и шаблонов реализации [например, сервисно-ориентированная архитектура (SOA), управляемая моделью разработка систем (MDSD) или разработка коробочных продуктов (COTS)] приведены эталонные процессы, подходящие для применения в проекте любого масштаба (путем адаптации RUP для малых, средних и больших проектов соответственно). Кроме того, все больше и больше важных для отрасли процессов реализуется в виде дополнительных модулей (недавно так был реализован процесс для TOGAF).
Заблуждение: RUP не включает оценку трудозатрат
Многие менеджеры проекта жалуются, что RUP не делает оценку. И это на самом деле так. RUP представляет собой инфраструктуру разработки процессов, не содержащую и не предлагающую никаких конкретных методов оценки. Тем не менее, в RUP можно найти некоторые полезные указания на то, где и как проводить оценку.
При работе с ранними версиями RUP ощущалась сильная нехватка указаний по проведению оценки. Но с появлением Rational Method Composer и с развитием нескольких моделей проведения оценки этот недостаток исчез. В Rational Method Composer оценка представлена как в виде отдельных элементов, которые при необходимости могут быть включены в специализированный процесс, так и в виде частей эталонных процессов, предназначенных для различных методологий и типов проектов [например, RUP для проектов по обеспечению и RUP для разработки на основе имеющихся активов (asset-based development)]. Кроме того, существует ряд разработанных сторонними производителями исполняемых модулей расширения функциональности Rational Method Composer, таких как, например, модуль Quantitative Software Management (QSM) Measurement and Estimation. Вышеупомянутый модуль предназначен для расчета оценок как при прохождении ключевых контрольных точек процесса, так и по необходимости. Модуль может выполнять расчеты на основе значительного числа параметров, включающих метрики среды, процессов и проекта.
Текущая версия RUP включает библиотеку, содержащую руководство по оценке, основанной на функциональных точках с применением вариантов использования и метода wideband DELPHI. Модуль расчета оценки QSM реализует улучшенную модель Putnam Lifecycle и принимает в качестве параметров такие метрики как количество функций (function counts, FC) или количество строк кода (software lines of code, SLOC). К сожалению, в Rational Method Composer не представлены методы, основанные на экспертной оценке и обучении. Остальные потенциально полезные методы также большей частью оставлены без внимания.
Важной особенностью Rational Method Composer является равенство подходов к оценке и к остальным методам, таким как анализ вариантов использования или модульное тестирование. Эта особенность заставляет разработчиков процессов и менеджеров проекта считать оценку необязательной (хотя и важной) работой, которая может при необходимости выполняться как в определенный момент процесса, так и в любое время по усмотрению ответственных лиц.
Заблуждение: в RUP не ведется регистрация событий
Дисциплина управления проектами основана на собственных стандартах и сводах лучших методов, таких как PMBOK и Projects in Controlled Environments (PRINCE2). В этом с ней схожа работа по аудиту (Audit). В базовом процессе RUP данная работа является частью дисциплины конфигурационного управления и управления изменениями. Подобно работам по управлению проектами, работы по управлению изменениями начинаются на ранних этапах проекта. Работы по этой дисциплине включают конфигурационное управление, управление запросами на изменение, управление статусами и управление измерениями. Каждая из этих работ формирует входные данные для работ по аудиту.
Одной из причин для беспокойства здесь является то, что работами по конфигурационному управлению и управлению изменениями зачастую пренебрегают в пользу работ по управлению требованиями, анализу и проектированию, а также реализации, поскольку они считаются более важными для конечного результата. Такое ограниченное мышление дорого обходится проектам и организациям. Поэтому менеджер проекта должен следить за своевременностью и эффективностью выполнения работ по любым дисциплинам. В RUP нет недостатка в указаниях относительно того, что и когда должно быть выполнено.
Заблуждение: жизненный цикл RUP основан на фазах
Забудьте об итерациях - большинство проектов, которые мне довелось наблюдать, использовало RUP только как красивую этикетку, лишь изредка продвигаясь дальше определения фаз и применения вариантов использования для описания взаимодействия с пользователями и системами.
Менеджеру проекта очень тяжело принять решение об организации проекта в виде нескольких итераций, результатом каждой из которых является продукт промышленного качества. Можно утверждать, что планирование итераций является одной из самых сложных задач менеджера проекта. Правильное планирование итераций требует гибкости, доверия, знания предметной области и опыта в использовании методологии. При этом фазы кажутся более легкими для понимания, поскольку обеспечивают четко определенное пространство, в котором менеджер проекта может разместить задачи. Каждая фаза RUP заканчивается четко определенной основной контрольной точкой - это правило является краеугольным камнем эталонной архитектуры этого процесса и выполняется для любого проекта независимо от его размера, типа или сложности. В то же время итерации, заканчивающиеся вспомогательными контрольными точками, могут различаться от проекта к проекту.
Контрольные точки позволяют менеджерам проекта "сверять часы" со своими техническими группами и отчитываться перед своими руководителями. Важным моментом является то, что они совпадают с моментом завершения работ над наиболее важными артефактами и, следовательно, могут и должны использоваться при составлении плана проекта и принятии решений о его продолжении или прекращении.
К основным контрольным точкам, большинство которых имеет место в основном в пределах одной итерации, относятся:
- Цели жизненного цикла
- Архитектура жизненного цикла
- Первоначальные функциональные возможности
- Выпуск продукта
Второстепенные (но не являющиеся крайне незначительными) контрольные точки совпадают с завершением работ над основными релизами продукта.
Для RUP как инфраструктуры разработки процессов понятие итерации, несомненно, является более важным, чем понятие фазы. Деление на фазы часто создает у специалистов, в том числе и у менеджеров проекта, ложное представление о том, что сбор требований происходит в фазе начала, разработка - в фазе построения, а ввод в эксплуатацию - в фазе внедрения, что больше напоминает водопадный метод нежели RUP. Не совсем удачным здесь является сходство фаз RUP с жизненным циклом возведения здания, позаимствованным из строительной индустрии. Преобладающая в строительстве модель производственного процесса по своей природе имеет последовательный характер, тогда как модель, преобладающая в инженерном деле, является цикличной [6].
Заблуждение: необходимо устанавливать соответствие между PMBOK и RUP
Заниматься поиском соответствий между RUP и PMBOK не обязательно, однако, если в ходе проекта эти стандарты будут использоваться совместно, некоторого рода сравнение все же потребуется. На верхнем уровне установить соответствия несложно, но практика показывает, что каждый проект немного отличается от остальных. Сначала необходимо выбрать один из двух стандартов в качестве базового. Я настоятельно рекомендую RUP, несмотря на то, что обычно основным процессом является PMBOK. Это связано с тем, что RUP специально создавался как процесс разработки программного обеспечения, тогда как PMBOK представляет собой не привязанный к конкретной отрасли подход к управлению проектами. После того как индивидуальная версия метода разработана и настроена, процесс производства, построенный на основе RUP с учетом PMBOK, может быть выпущен в виде практического пособия, чего невозможно было бы достичь иным способом.
Если между процессам решено установить соответствие, не следует опускаться ниже уровня детализации, к которому стремится менеджер проекта. Некоторые менеджеры проекта готовы дойти даже до установления соответствия между отдельными задачами и артефактами. Я считаю, что достаточно лишь согласиться о принципах установления соответствия между элементами жизненного цикла, а сэкономленное время направить на выполнение рекомендаций RUP по планированию проекта. В таблице приведены соответствия между элементами жизненного цикла стандартов RUP и PMBOK.
Соответствие между элементами RUP и PMBOK
| RUP | PMBOK |
|---|---|
| Фаза (Phase) | Фаза (Phase) |
| Основная контрольная точка (Major Milestone) | Контрольное событие (Milestone) |
| Итерация (Iteration) | Проект (Project) |
| Второстепенная контрольная точка (Minor Milestone) | Контрольное событие (Milestone) |
| Дисциплина (Discipline) | Область знаний (Knowledge Area) |
| Работа (Activity) | Группа процессов (Process Group) |
| Результат работы (артефакт, промежуточный/вспомогательный артефакт) [Work Product (Artifact, Deliverable)] | Результат поставки (Deliverable) |
| Задача (Task) | Процесс (Process) |
Коллизии на уровне артефактов и привнесенная избыточность составляют лишь часть потенциально возможных сложностей, с которыми группе разработки процесса или проектной группе придется столкнуться при использовании гибридного подхода. Удачным примером тому является документ "Устав проекта" (Project Charter) PMBOK, который, как отмечают некоторые менеджеры проекта, "замещается" артефактами RUP "Бизнес-сценарий" (Business Case) и "Концепция" (Vision). Несмотря на то что гибридный подход может оправдывать использование смешанного набора артефактов, принадлежащих обоим стандартам, я настоятельно рекомендую в целях обеспечения трассируемости использовать набор артефактов RUP, а артефакты PMBOK при необходимости формировать на их основе.
Некоторых менеджеров проекта расстраивает тот факт, что RUP допускает эволюцию многих артефактов через фазы и итерации и позволяет им находиться в частично завершенном виде в течение большего времени, чем допускается PMBOK. Здесь важно заметить, что RUP тем не менее не допускает бесконечной эволюции артефактов и использует строгие принципы и критерии прохождения артефактами контрольных точек. Последние версии стандарта PMBOK также не исключают использования поэтапного подхода, выраженного принципом "продолжающегося совершенствования".
Заблуждения: RUP является процессом, готовым к применению "из коробки"
Зачастую менеджеры, так же как и многие другие участники ИТ-проектов, принимают RUP за фиксированный процесс, немедленно готовый к применению. Вероятно, такое понимание данной методологии зародилось на ранних периодах ее эволюции, когда RUP еще был монолитным процессом, предназначенным для узкой категории проектов (главным образом, проектов разработки ПО "с нуля") и не имел достаточной гибкости относительно масштабов проекта (все проекты считались скорее большими). Кроме того, в тот момент RUP не имел адекватных описаний и руководств по применению, возможности индивидуальной настройки также отсутствовали. Несмотря на то, что все эти ограничения давно устранены, представление о RUP как о строго формальном и негибком процессе до сих пор сохранилось.
Ситуация еще сильнее изменилась в лучшую сторону с появлением Rational Method Composer. В последних выпусках RUP проекты стали делиться по размеру (и, пожалуй, по уровню формализма) на "RUP для малых проектов", "RUP для проектов среднего размера" и "RUP для больших проектов". Специальные модули, такие как "RUP для коробочных продуктов" и "RUP для бизнес-моделирования" могут использоваться для получения специализированных процессов производства требуемого масштаба на основе базовой версии RUP. Помимо готовых расширений, при создании специализированного процесса может быть использована внутренняя нормативно-справочная документация компании, материалы, заимствованные из других методологий, инфраструктур и лучших практик, таких как PMBOK или Information Technology Infrastructure Library (ITIL®) и, кроме того, модули расширения RMC.
Заблуждение: в RUP отсутствует процесс "инициации"
Менеджеры проекта часто ожидают от RUP помощи в выполнении административных задач, таких как получение одобрения на выделение средств и формирование личной заинтересованности высшего руководства. Кроме того, многие менеджеры проекта предпочли бы иметь в своем распоряжении дополнительный отрезок времени для решения этих вопросов перед фазой начала RUP. Однако попытка внесения подобных изменений в жизненный цикл RUP противоречила бы принципам данной методологии.
Если бы целью изменений являлось расширение фазы начала, это наложило бы ограничения на использование ресурсов, что противоречит принципу параллельного выполнения и принципу эффективности процесса. Принятие ключевых решений, не основанных на требованиях, может привести к поверхностным или неполным результатам или к полному отсутствию таковых. Четкое планирование проекта возможно только на основе структурированных требований, которые обычно формируются в ходе фазы проектирования.
Если же причиной является желание выиграть побольше времени на бизнес-анализ или политические игры, к RUP это не имеет отношения. Возможно, решение проблемы можно найти в области архитектуры предприятия. Последняя имеет более широкие цели, чем RUP и, кроме того, Rational Method Composer содержит руководство по преобразованию концептуальных целей и бизнес-метрик, содержащихся в документах "Концепция предприятия" (Enterprise Vision), "Бизнес-сценарий" (Business Case) и других документах по планированию в спецификацию бизнес-технологии и предложения по разработке решений. Методологии архитектуры предприятия включают руководства по анализу структуры и процессов предприятия, определению цели и границ, оценке ресурсов, архитектурному анализу, идентификации и определению приоритетов решения, а также выбору способа реализации. Кроме того, дополнительную поддержку можно найти в области управления портфелем проектов. Вполне естественно, что при наличии налаженных процессов управления портфелем проектов функции отбора проектов и осуществления общего контроля становятся частью рабочего порядка, что способствует устранению любых предубеждений в отношении методологии реализации решения.
Некоторые из перечисленных мер могут потребовать от организации нового взгляда на управление проектами, который, возможно, будет отражен в формате роли менеджера проекта предприятия. Далее мы обсудим этот вариант.
Менеджер проекта предприятия: роль в процессе развития
Оправдано ли создание в организации роли менеджера проекта предприятия? Возможно, имеет, если рассматривать развитие предприятия как один длительный процесс - из тех, что создают спрос на TOGAF и другие методики реализации архитектуры предприятия.
Естественно, что при реализации архитектуры предприятия в ходе одного или нескольких проектов, каждый проект будет включать весь жизненный цикл разработки архитектуры предприятия или его часть. Несмотря на то, что первый подход может выглядеть соблазнительно, использовать его не рекомендуется, поскольку это может привести к чрезмерному затягиванию продолжительности проекта. Может показаться, что с его помощью удастся сократить накладные расходы, связанные с бюрократическими процедурами инициации и завершения проектов, но тот факт, что завершение проекта может занять годы, делает данный подход не самым практичным (и демонстрирует противоречие RUP, согласно рекомендациям которого проекты должны иметь умеренную продолжительность).
Поэтому более разумным подходом является деление процесса реализации архитектуры предприятия на несколько проектов разумной продолжительности. Эти проекты могли бы, например, охватывать одну или несколько фаз реализации архитектуры предприятия и выполняться как параллельно, так и последовательно с наложениями. Например, при использовании TOGAF ADM могут быть запущены три проекта для формулирования концепции (Фаза А), разработки архитектуры (Фазы B-F), управления процессом разработки решения и управления изменениями (Фазы G-H).
Организация должна сама определить, требуется ли ей выделенный менеджер проекта предприятия для решения вопросов, связанных с архитектурой или будет достаточно возложить дополнительные обязанности на архитектора предприятия [1]. Конечное количество проектов, необходимое для реализации архитектуры предприятия, должен определить менеджер проекта предприятия (или архитектор). При этом необходимо принять во внимание такие факторы как уровень мотивации для внесения изменений, способность организации достигать результата, производительность при выполнении аналогичных проектов в прошлом, продолжительность цикла реализации архитектуры предприятия в прошлом и ее оценка для текущего проекта. Практика решения данной проблемы показывает, что у архитекторов предприятия достаточно других забот (таких как вопросы собственно архитектуры), а это может создать при выполнении ими дополнительных обязанностей сложности которые будет не так-то просто разрешить.