Эта область компетенции отвечает за контакты с заказчиком и формирование его ожиданий. Такие контакты включают в себя PR, брифинги для высшего руководства и заказчиков, потребительский маркетинг, презентации, анонсы и премьеры продуктов. Формирование ожиданий – это ключевая задача кластера “Управление продуктом” начиная с момента, когда единое видение результатов проекта уже сформировано. Это очень важно, ведь именно удовлетворение ожиданий является определяющим фактором успеха или неудачи проекта.
Приведем пример. Допустим, заказчик в определенный день ожидает поставку проектной группой продукта, реализующего десять заранее оговоренных функций. Если в итоге поставляется продукт только с двумя функциями из этих десяти, то как заказчиком, так и проектной группой, проект будет считаться неудавшимся.
Однако, если менеджеры продукта постоянно поддерживают двухстороннюю связь с заказчиком на протяжении всего процесса разработки, внесение изменений в план может происходить в соответствии с ожиданиями заказчика, и это будет способствовать успеху проекта. Менеджеры продукта могут вовлечь заказчика в процесс принятия компромиссных решений и проинформировать его о нарастающих рисках и других трудностях. В отличие от предыдущего случая, заказчик может оценить ситуацию и согласиться с проектной группой в том, что реализация всех десяти функциональных возможностей в отведенное время не реалистична, и что наличие лишь двух из них является приемлемым компромиссом. При таком развитии событий реализация двух функций соответствует ожиданиям заказчика и обе стороны будут считать проект удавшимся.
Планирование продукта
Планирование продукта определяет требования и необходимые характеристики для последовательности версий решения. В задачи планирования продукта входит обеспечение быстрого понимания требований к решению со стороны менеджера программы или разработчика. Это включает в себя, во-первых, полное понимание текущих требований к решению: какие бизнес-нужды оно удовлетворяет, как заказчики будут его использовать, какие могут возникнуть проблемы сопровождения и какие альтернативные решения возможны. Во-вторых, это исследование дополнительных факторов, которые увеличили бы ценность решения для заказчика: возможность вхождения в новые сектора бизнеса, интеграция с другими системами, повышение производительности, преемственность, сокращение затрат на сопровождение и т.д. Зная это, разработчик плана продукта может рекомендовать для его последующих версий различные функциональные возможности и приоритеты их реализации.
Основные составляющие планирования продукта - исследовательская работа и анализ. Независимо от того, идет ли речь о понимании заказчика и нужд его бизнеса или о понимании условий конкуренции, важно уделять достаточно внимания соответствующим исследованиям и анализу. Такой подход также предотвращает непродуктивную трату ресурсов на реализацию ненужных элементов.
Ролевой кластер “Управление программой”
Основная задача этого ролевого кластера – обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований спонсора проекта к его результату. Для этого “Управление программой” контролирует календарный график проекта, объем работы и отведенный на проект бюджет. Рассматриваемый кластер обеспечивает своевременное достижение требуемых результатов и удовлетворение ожиданий спонсора на протяжении проекта. Ниже описываются области компетенции ролевого кластера “Управление программой”.
Управление проектом -
Мониторинг и управление бюджетом.
-
Составление сводного плана и сводного календарного графика проекта.
-
Организация управления рисками.
-
Содействие обмену информацией и достижению договоренностей внутри проектной группы.
-
Мониторинг прогресса и отчетность о состоянии проекта.
-
Управление выделением ресурсов.
Выработка архитектуры решения -
Организация высокоуровневого проектирования решения.
-
Управление функциональной спецификацией.
-
Определение рамок проекта и ключевых компромиссных решений.
-
Организация контроля производственного процесса.
-
Выработка рекомендаций по его совершенствованию.
Административные службы -
Организация процессов управления проектом и помощь лидерам команд (team leads) в их использовании.
-
Организация ряда административных служб, необходимых для поддержки эффективной работы команды.
Управление проектом
Будучи ответственным за календарный план, менеджмент проекта (project management) следит за всеми временными графиками внутри команды, контролирует их правомерность и интегрирует их в сводный календарный график проекта. Он, в свою очередь, подвергается мониторингу, и отчетность о ходе его выполнения направляется проектной группе и спонсору проекта.
Будучи ответственным за бюджет, менеджмент проекта организует его создание, собирая требования к ресурсам со стороны каждого из ролевых кластеров проектной группы. Менеджмент проекта должен быть вовлечен во все решения, касающиеся ресурсов (как людских, так и материальных). Также менеджмент проекта отслеживает соотношение реальных и плановых расходов и предоставляет отчеты о них проектной группе и спонсору.
В дополнение к этому в рамках данной области компетенции находится координирование ресурсов, содействие эффективному взаимодействию членов проектной группы и помощь в принятии ключевых решений.
Более детальную информацию об области компетенции “Управление проектом” и подходе MSF к управлению проектами, см. http://www.microsoft.com/msf/
Выработка архитектуры решения
“Выработка архитектуры решения” (solution architecture) – это область компетенции ролевого кластера “Управление программой”, ответственная за логический дизайн решения и описание его функций. Ее основная задача - обеспечение результативного и эффективного использования продукта потребителем для достижения своих целей.
Зоны ответственности “Выработки архитектуры решения” включают в себя:
-
Организацию высокоуровневого проектирования решения.
-
Управление функциональной спецификацией.
-
Определение рамок проекта и ключевых компромиссных решений.
Будучи ответственной за логический дизайн решения, “Выработка архитектуры решения” осуществляет жизненно важную связь между бизнес-стороной проекта (представляемой кластером “Управление продуктом” посредством концептуального дизайна) и технологической его стороной (представляемой кластером “Разработка” посредством физического дизайна). Эта область компетенции “опекает” функциональную спецификацию. Она стремится к достижению внутрикомандного консенсуса о дизайне и обосновывает выбранный подход перед заинтересованными в проекте сторонами. Данная область компетенции также отвечает за соответствие всех элементов дизайна изначальным требованиям (и, в конечном итоге, обеспечение бизнес-отдачи). Каждый элемент решения должен реализовывать некоторое требование: таким образом проектная группа может оценить последствия любых изменений дизайна для бизнес-полезности конечного продукта.
Мероприятия, проводимые “Выработкой архитектуры решения” включают в себя:
-
Создание концепции решения и его согласование с архитектурой предприятия заказчика; разработка стратегии версионирования продукта; выработка рекомендаций к планам сбора требований.
-
Сбор требований к интероперабельности (interoperability) решения, его соответствию корпоративной архитектуре и действующим нормативам; осуществление логического проектирования; составление “карты” соответствия (traceability map) элементов дизайна изначальным требованиям заказчика; создание функциональной спецификации; спецификация промежуточных версий продукта.
-
Управление изменениями функциональной спецификации; поддержка “карты” соответствия; разъяснение спецификации другим ролевым кластерам проектной группы и внешним заинтересованным лицам; связь с другими проектными группами для обеспечения интероперабельности.
-
Участие в процессе приоритезации; формирование ожиданий заинтересованных сторон.
-
Связь с архитектурной группой предприятия; корректирование требований к будущим версиям решения.
Работающие в данной области компетенции сотрудники должны быть образованными в технологическом плане и иметь большой опыт в сочетании со способностью сопоставлять технологические проблемы со стоящими за ними нуждами бизнеса. Хотя архитекторы решения могут положиться на опыт команды разработчиков в вопросах специфических технологий, они должны очень четко осознавать последствия тех или иных технических шагов и понимать их взаимосвязь и их влияние на среду внедрения. Также архитекторы решения должны быть в состоянии обсудить вышеупомянутые последствия с архитекторами заказчика и незамедлительно разрешить любые конфликты между предлагаемым решением и архитектурой предприятия заказчика.
Достарыңызбен бөлісу: |