Библиотека

Наши друзья

Менеджмент.com.ua .:. Интернет-портал для управленцев Consulting.ru Организация времени - тайм менеджмент и управление временем

О сайте

Проект “Vernikov.ru” — это библиотека, содержащая в себе уникальную и качественную подборку аналитических материалов по вопросам экономики, менеджмента и информационных технологий. Материалов в Интернете очень много. Мы не пытаемся опубликовать всё. Мы экономим Ваше время и публикуем только лучшее.

Помимо доступа к материалам, на сайте “Vernikov.ru” любой посетитель, столкнувшись с новыми и сложными задачами, может быстро и бесплатно получить консультацию у профессионалов.

Microsoft Solutions Framework. Модель проектной группы MSF. вер. 3.1

Автор: Microsoft 30 Сентября 2009, 12:35

Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь.

Чтобы скачать книгу одним файлом, нажмите здесь.

Введение

MSF и MOF предлагают проверенные годами рекомендации и методики по эффективному планированию, разработке, внедрению и сопровождению бизнес решений. Они позволяют максимизировать успешность и эффективность IT проектов на протяжении всего жизненного цикла информационных технологий. В основе предлагаемых концепций лежит обширный опыт, полученный Майкрософт при осуществлении больших проектов в области программного обеспечения, опыт консультантов Майкрософт, а также лучшие из методик, наработанные мировой IT индустрией. Этот материал опубликован в виде “Белых книг” , пособий, программного инструментария, шаблонов, учебных примеров и учебных курсов. Рекомендации и методики представлены в виде двух дополняющих друг друга областей знаний (bodies of knowledge).

Microsoft Solutions Framework

Бизнес-решения должны создаваться с учетом поставленных сроков и в рамках отведенного бюджета. Этого легче добиться, применяя утвердившийся, проверенный подход. MSF предлагает испытанные методики для планирования, создания и внедрения успешных решений в IT индустрии. Он не содержит жестких инструкций; вместо этого предлагается гибкий и масштабируемый подход, способный удовлетворить нужды организации или проектной группы любого размера. Рекомендации MSF состоят из применимых для большинства проектов принципов, моделей и дисциплин по управлению людьми, процессами и технологическими элементами.

Для получения дальнейшей информации по MSF , см. http://www.microsoft.com/msf

Microsoft Operations Framework

MOF предлагает рекомендации, помогающие обеспечить надежность (reliability), доступность (availability), удобство в сопровождении (supportability) и управляемость (manageability) IT решений, построенных на базе продуктов и технологий Майкрософт. Принципы, модели и дисциплины MOF затрагивают кадровые, технологические и технические вопросы, относящиеся к управлению сложными (complex), распределенными (distributed), разнородными (heterogeneous) IT-системами.

Для получения дальнейшей информации по MOF, см. http://www.microsoft.com/mof

Информация об IT Infrastructure Library (ITIL) – сборнике наиболее хорошо зарекомендовавших себя методик, являющихся базой MOF, может быть получена на сайте http://www.itil.co.uk/index.html

Основы модели проектной группы MSF

Модель проектной группы MSF разрабатывалась в течение нескольких лет и возникла в результате осмысления недостатков пирамидальной, иерархической структуры традиционных проектных групп.

В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу сплачивают единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться. Этот документ описывает различные ролевые кластеры (role clusters) внутри проектной группы, определяя их цели и области компетенции. Также даются рекомендации по использованию подхода Майкрософт к формированию проектной группы при масштабировании модели как для малых, так и для больших и сложных проектов.

Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы.

Основные принципы

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

Распределение ответственности при фиксации отчетности

MSF сочетает распределение ответственности за выполняемую работу со строго определенной отчетностью о ее исполнении.

Модель проектной группы MSF основывается на утверждении о равноправности ролей в команде. Каждый ролевой кластер представляет уникальную точку зрения на проект, и в то же время никто не в состоянии успешно представлять все возможные взгляды, отражающие качественно различные цели. Для разрешения этой дилеммы команда соратников (команда равных, team of peers), работающая над проектом, должна иметь четкую форму отчетности перед заинтересованными сторонами (stakeholders) при распределенной ответственности за достижение общего успеха.

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

Наделяйте членов команды полномочиями

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

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

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

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

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

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

  • Наделяйте членов проектной группы полномочиями, необходимыми для исполнения их обязанностей. Это означает, что у членов проектной группы есть ресурсы, необходимые для их работы, соответствующие полномочия и понимание их пределов. При этом члены проектной группы должны знать об имеющихся путях эскалации (escalation) принятия решений по вопросам, выходящим за рамки их компетенции.
  • Будьте готовы принимать обязательства перед другими. Такая готовность включает в себя осознание и понимание последствий принятия обязательств и их влияния на текущую загруженность и ресурсы. Как результат, принятие больших обязательств не должно происходить прежде, чем все их последствия  хорошо поняты. Вместо этого члены проектной группы должны брать меньшие обязательства, суть которых им хорошо ясна. Например, перед тем как взяться за большую задачу сотрудник может попросить время на ее обдумывание. Успешное исполнение малых обязательств придает членам команды уверенность друг в друге.
  • Четко определяйте взятые обязательства. Это позволяет избежать недопонимания, которое может повредить уверенности членов команды друг в друге.
  • Прилагайте максимум оправданных усилий для исполнения взятых на себя обязательств. Если проектная группа включает в себя людей из различных организаций, их понимание оправданности может отличаться. Например, некоторые члены проектной группы могут считать приемлемой работу в выходные дни. Другие же могут допускать это только в крайних случаях, или же могут испытывать затруднения с доступом к рабочим местам в неурочное время.
  • Когда выполнение обязательства находится под угрозой, прямо говорите об этом. Неизбежно будут возникать случаи, когда ситуация меняется. Это может случиться из-за изменения приоритетов или непредвиденного события; или же просто выполнение поставленной задачи потребует больше времени, чем предполагалось. Раннее предупреждение позволяет другим членам команды, зависимым от вашей работы, скорректировать свои планы. Возможно, они даже смогут предложить подход к решению возникшей проблемы.

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

Концентрируйтесь на бизнес-приоритетах

Модель проектной группы MSF отстаивает необходимость принятия решений проектной группой на основе полного понимания бизнеса заказчика и при активном его участии в реализации проекта. Ролевой кластер “Управление продуктом” (product management) действует по отношению к проектной группе как представитель заказчика и зачастую формируется из сотрудников организации-заказчика. Кластер “Управление продуктом” представляет бизнес-сторону проекта и обеспечивает его согласованность со стратегическими целями заказчика. В обязанности кластера “Управление продуктом” входит контроль за полным пониманием интересов бизнеса при принятии ключевых проектных решений.

Ролевой кластер “Управление выпуском” (release management) непосредственно ответственен за беспрепятственное внедрение проекта и его функционирование. Этот ролевой кластер берет на себя связь между разработкой решения, его внедрением и последующим сопровождением, обеспечивая информированность членов проектной группы о последствиях их решений.

Единое видение проекта

MSF отстаивает необходимость выработки единого видения (shared vision) проекта, формирующего целостный подход проектной группы к разработке IT-решения.

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

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

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

Проявляйте гибкость – будьте готовы к переменам

MSF исходит из того, что все вокруг непрерывно меняется. Невозможно изолировать IT проекты от этих изменений. От начала до завершения проекта модель проектной группы MSF гарантирует присутствие всех командных ролей и их вовлеченность в процесс принятия решений, обусловленных происходящими переменами. Эта модель поощряет гибкость (agility) при работе в условиях постоянного возникновения новых задач и потребностей. Участие всех ролей в процессе принятия решений обеспечивает рассмотрение вопросов с учетом полного спектра точек зрения.

Поощряйте свободное общение

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

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

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

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

Ключевые концепции

Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts), представленных в этом разделе.

Команда соратников

Концепция “команды соратников” (teem of peers) означает равноправное положение каждой из ролей в команде. Это способствует свободному общению, увеличивает командную ответственность и предопределяет равную важность каждой из шести качественных целей. Чтобы достичь успеха в рамках команды соратников (команды равных), каждый из ее членов, независимо от роли, должен нести ответственность за качество продукта, понимать интересы заказчика и сущность решаемой бизнес-задачи.

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

Сфокусированность на нуждах заказчика

Удовлетворение нужд заказчика – главный приоритет любой хорошо работающей проектной группы. Концентрация на нуждах заказчика (customer-focused mindset) означает обязательное понимание его бизнес-задач и стремление к их решению со стороны команды. Одним из способов определения успеха такого внимания к заказчику является способность отследить связь каждого элемента в дизайне системы с соответствующим ему исходным требованием заказчика или пользователя (trace each feature in the design back to a customer or user requirement). Другим ключевым моментом в удовлетворении нужд заказчика является его активное участие в проектировании решения и получение его отзывов в ходе процесса разработки. Это позволяет проектной группе и заказчику успешно согласовывать свои ожидания и потребности.

Нацеленность на конечный результат

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

Первый шаг в достижении достойного уровня качества – это рассматривать собственную работу в качестве самостоятельного проекта или же вклада в какой-либо больший проект. MSF выступает за наделение проектов индивидуальными чертами. В результате члены проектной группы начинают чувствовать себя членами команды, а не обособленными работниками. Например, в Майкрософт для достижения этого проектам дают имена. Такой подход помогает выделить проект и его команду, усилить в ней чувство ответственности и создать механизм, формирующий в команде моральный дух. Печать названия проекта на футболках, кофейных чашках и других сувенирах помогает создать и укрепить дух команды. Это особенно полезно в проектах, над которыми работают “виртуальные коллективы”, составленные из работников различных подразделений организации.

Осознав свой вклад в проект, вам будет легко понять, что всякий ожидаемый от вас результат может рассматриваться как конечный продукт. Принципы и методики, применимые к созданию продуктов “вообще”, например, предлагаемые MSF, могут помочь вам преуспеть в этом.

Установка на конечный продукт (product mindset) также означает, что получению конечного результата проекта уделяется больше внимания, чем процессу его достижения. Из этого не следует, что сам процесс может быть плох или непродуман – просто он существует для получения конечной цели, а не ради себя самого. Когда внимание к конечному продукту становится частью производственной культуры, каждый член коллектива начинает ощущать ответственность за результат проекта.

В своей презентации 1991-го года бывший менеджер программы Майкрософт Chris Peters так описывал эту концепцию применительно к разработке программного обеспечения:

“У каждого ... совершенно одинаковая работа. Она имеет одно и то же название. И это – поставка продукта. Ваша работа – это не написание программного кода. Ваша работа – это не тестирование. Ваша работа – это не составление спецификаций. Ваша работа – это поставка продукта. Это как раз то, чем занимается команда разработчиков.

Ваша роль как разработчика или тестировщика вторична. Я не говорю, что это не важно, но это вторично по отношению к вашей настоящей работе, которой является поставка продукта.

Когда вы просыпаетесь утром и приходите на работу, вы говорите: “Что является приоритетом – мы создаем продукт или пишем программный код?” Ответом является: мы создаем продукт. Не пытайтесь создавать код – создавайте продукт”.

Установка на отсутствие дефектов

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

Установка на отсутствие дефектов (zero-defect mindset) – это стремление к высочайшему уровню качества. Она означает, что цель команды – выполнение своей работы с максимально возможным качеством, причем таким образом, что если от команды потребуют поставить результат завтра, она будет способна поставить что-то работающее. Необходимо понимание того, что каждый день продукт должен быть практически готов к поставке. Это не означает поставку программного кода, полностью свободного от дефектов. Но это означает, что продукт отвечает требованиям качества (quality bar), установленным спонсором (sponsor) проекта  и принятым проектной группой на этапе выработки концепции.

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

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

Стремление к самосовершенствованию

Стремление к самосовершенствованию (willingness to learn) – это приверженность идее неустанного саморазвития посредством накопления опыта и обмена знаниями. Оно позволяет членам проектной группы извлекать пользу из отрицательного опыта сделанных ошибок, равно как и воспроизводить успехи, используя проверенные методы работы других людей. Проведение по окончанию основных фаз проекта открытых обсуждений его состояния и доброжелательный, но объективный анализ проекта после его окончания – это ключевые компоненты модели процесса MSF. Проектные группы, выделяющие время на анализ результатов своей работы и извлечение из них уроков, создают базу для постоянного самосовершенствования и долговременного успеха. Кроме того, Майкрософт успешно развивает культуру самосовершенствования, включая анализ извлеченных уроков и обмен знаниями в планы индивидуальной работы сотрудников.

Заинтересованные команды работают эффективно

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

MSF стремится к созданию заинтересованности и высокого морального духа команды. Люди, работающие в Майкрософт, воспринимают это как одну из основных характеристик компании. Приведем некоторые методы стимулирования такой заинтересованности:

  • Создавайте у членов команды единое видение решаемой задачи.
  • Формируйте индивидуальность команды, используя названия проектов и знаки отличия команды – брелки, футболки, чашки и т. д.
  • Ближе знакомьтесь с коллегами, используя для этого неформальные встречи и мероприятия.
  • Для создания командного духа организуйте мероприятия, на которых люди могут ближе познакомиться друг с другом. Как правило, такие встречи проводятся вне офиса.
  • Убедитесь, что личные цели и стремления членов команды не остаются без внимания. Например, это может быть создание возможностей для личного и профессионального роста или забота о том, чтобы должностные обязанности не оказывали негативного влияния на личную жизнь.
  • Наделяйте членов команды реальными полномочиями; прислушивайтесь к их мнениям.
  • Празднуйте успехи команды.

Испытанные методики

Следующие испытанные методики (proven practices) являются общими средствами достижения успеха команд, практикующих MSF.

Малые многопрофильные проектные группы

Малые многопрофильные команды (small, multidisciplinary teams) имеют ряд несомненных преимуществ. Одно из них – большая оперативность действий в сравнении с крупными коллективами. Поэтому при работе над большими проектами лучше создавать команды команд – набор малых групп, работающих параллельно. При этом работники, являющиеся экспертами в определенных областях или имеющие специфические функции, получают полномочия действовать в рамках своих областей компетенции.

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

Коллективная работа

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

В своей книге Microsoft Secrets, посвященной Майкрософт, Michael A. Cusumano и Richard W. Selby пишут:

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

Также соседство рабочих мест помогает команде укрепить чувство сплоченности и единства.

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

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

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

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

Жизненно важная составляющая виртуальной команды – это уверенность каждого её члена в возможности положиться на других, что достигается выработкой общей корпоративной культуры, неустанной управленческой работой и – как только это становится возможным – переносом работы в одно место (или хотя бы совместным отдыхом).

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

  • могут работать самостоятельно;
  • обладают лидерскими качествами;
  • имеют необходимые для создания продукта профессиональные навыки;
  • способны передавать свои знания коллегам;
  • могут помочь в развитии эффективных методов работы.

Всеобщее участие в проектировании

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

Обзор модели команды MSF

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

Шесть ролевых кластеров модели проектной группы – это “Управление продуктом” (product management), “Управление программой” (program management), “Разработка” (development), “Тестирование” (test), “Удовлетворение потребителя” (user experience) и “Управление выпуском” (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же – построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.

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

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

Ролевой кластер

Цель

Область компетенции

Функции

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

Удовлетворенные заказчики

Маркетинг

Бизнес-отдача (бизнес-приоритеты)

Представление интересов заказчика

Планирование продукта

Выступает в роли представителя заказчика

Формирует общее видение/рамки проекта

Организует работу с требованиями заказчика

Развивает сферы применения в бизнесе

Формирует ожидания заказчика

Определяет компромиссы между параметрами “возможности продукта / время / ресурсы”

Организует маркетинг, PR и евангелизацию

Разрабатывает, поддерживает и исполняет план коммуникаций

Управление программой

Достижение результата в рамках проектных ограничений

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

Выработка архитектуры решения

Контроль производственного процесса

Административные службы

Управляет процессом разработки с целью получения готового продукта в отведенные сроки

Формулирует спецификацию продукта и разрабатывает его архитектуру

Регулирует взаимоотношения и коммуникацию внутри проектной группы

Следит за временным графиком проекта и готовит отчетность о его состоянии

Проводит в жизнь важные компромиссные решения

Разрабатывает, поддерживает и исполняет сводный план и календарный график проекта

Организует управление рисками

Разработка

Создание продукта в соответствии со спецификацией

Технологическое консультирование

Проектирование и осуществление реализации

Разработка приложений

Разработка инфраструктуры

Определяет детали физического дизайна

Оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна

Разрабатывает или контролирует разработку элементов

Подготавливает продукт к внедрению

Консультирует команду по технологическим вопросам

Тестирование

Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены

Планирование тестов

Разработка тестов

Отчетность по тестам

Обеспечивает обнаружение всех дефектов

Разрабатывает стратегию и планы тестирования

Осуществляет тестирование

Удовлетворение потребителя

Повышение эффективности пользователя, увеличение потребительской ценности продукта

Обеспечение технической поддержки

Обучение

Эргономика

Графический дизайн

Интернационализация

Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями)

Представляет интересы потребителя в команде

Организует работу с требованиями пользователя

Проектирует и разрабатывает системы поддержки производительности

Определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта

Определяет требования к системе помощи и её содержание

Разрабатывает учебные материалы и осуществляет обучение пользователей

Управление выпуском

Беспроблемное внедрение и сопровождение продукта

Инфраструктура

Сопровождение

Бизнес-процессы

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

Представляет интересы отделов поставки и обслуживания продукта

Организует снабжение проектной группы

Организует внедрение продукта

Вырабатывает компромиссы в управляемости и удобстве сопровождения продукта

Организует сопровождение и инфраструктуру поставки

Организует логистическое обеспечение проектной группы

Удовлетворенные заказчики

Успешный проект должен порождать решение, удовлетворяющее заказчиков и потребителей. Можно полностью уложиться в отведенное время и бюджет, но при этом потерпеть полную неудачу, если нужды заказчиков не будут удовлетворены.

Достижение результата в рамках проектных ограничений

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

Создание продукта в соответствии со спецификацией

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

Одобрение выпуска продукта лишь после того, как все дефекты выявлены и улажены

Любое программное обеспечение содержит дефекты. Однако все дефекты должны быть обнаружены и улажены (address) до того, как продукт выпущен. Улаживание дефекта может подразумевать различные решения, начиная от устранения и заканчивая документированием способов его обхода (work-around). Поставка продукта с известным дефектом, но с описанием способов его обхода предпочтительнее поставки продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом, как для проектной команды, так и для заказчика.

Повышение эффективности пользователя, увеличение потребительской ценности продукта

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

Беспроблемное внедрение и сопровождение продукта

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

Ролевые кластеры модели проектной группы

Рисунок 1.    Ролевые кластеры модели проектной группы MSF

Ролевой кластер “Управление продуктом”

Ключевая цель ролевого кластера “Управление продуктом” (product management) – довольные заказчики. Проект не может считаться успешным, если он не привел к удовлетворению потребностей заказчика. Однако, прежде всего, заказчик должен быть идентифицирован и понят! В некоторых случаях заказчиком может являться не та сторона, которая спонсирует проект (т.е. поддерживает затраченные на него усилия и покрывает расходы). Следовательно, должно быть сделано четкое различие между этими сторонами и произведен анализ требований каждой из них в целях успешного взаимодействия с ними обеими. Лишь после этого может быть сформулирован набор требований и ожиданий, которым должны следовать соответствующие проектные роли. Возможна ситуация, когда проектная группа уложилась в бюджет и сроки, но успех все же не достигнут, так как не удовлетворены бизнес-нужды заказчика.

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

Для достижения своей цели ролевой кластер “Управление продуктом” должен содержать в себе следующие области компетенции: планирование продукта (product planning), бизнес-отдача (business value), представление интересов заказчика (customer advocacy) и маркетинг (marketing).

Области компетенции

Маркетинг

  • Проведение маркетинговых и PR акций, нацеленных на (потенциальных) клиентов.
  • Демонстрация своих конкурентных преимуществ.
  • Обеспечение попадания продукта в соответствующие каналы дистрибуции, гарантирующие его максимальную доступность для потребителя.
  • Консультирование потребителя для создания у него позитивного впечатления от покупки и использования продукта.

Бизнес-отдача

  • Определение и контроль обусловленности работы над проектом с точки зрения бизнеса.
  • Контроль (в т.ч. количественный) получения заказчиком бизнес-отдачи от проекта.

Представление интересов заказчика

  • Выработка общего видения проекта и решения.
  • Обмен информацией с заказчиком и формирование его ожиданий.

Планирование продукта

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

Маркетинг

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

Бизнес-отдача

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

Чтобы получить хороший результат, менеджеры продукта должны накапливать знания о бизнесе заказчика, факторах успеха и ключевых используемых метриках. Получение этой информации может рассматриваться как бизнес-анализ, выявляющий ключевые составляющие успеха. Только зная, что принесет заказчику отдачу, а что – нет, вы сможете спроектировать и построить подходящее решение (solution). Все чаще инвестиции в область информационных технологий подвергаются скрупулезным проверкам, и многие IT-проекты требуют тщательного изучения финансовой обоснованности. Проведение анализа соотношения затрат и прибыли существенно увеличивает шансы удовлетворения заказчика. Определение финансовых результатов – неотъемлемая часть процесса инвестирования в IT проект.

Представление интересов заказчика

Эта область компетенции отвечает за контакты с заказчиком и формирование его ожиданий. Такие контакты включают в себя PR, брифинги для высшего руководства и заказчиков, потребительский маркетинг, презентации, анонсы и премьеры продуктов. Формирование ожиданий – это ключевая задача кластера “Управление продуктом” начиная с момента, когда единое видение результатов проекта уже сформировано. Это очень важно, ведь именно удовлетворение ожиданий является определяющим фактором успеха или неудачи проекта.

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

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

Планирование продукта

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

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

Ролевой кластер “Управление программой”

Основная задача этого ролевого кластера – обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований спонсора проекта к его результату. Для этого “Управление программой” контролирует календарный график проекта, объем работы и отведенный на проект бюджет. Рассматриваемый кластер обеспечивает своевременное достижение требуемых результатов и удовлетворение ожиданий спонсора на протяжении проекта. Ниже описываются области компетенции ролевого кластера “Управление программой”.

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

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

Выработка архитектуры решения

  • Организация высокоуровневого проектирования решения.
  • Управление функциональной спецификацией.
  • Определение рамок проекта и ключевых компромиссных решений.

Контроль производственного процесса

  • Организация контроля производственного процесса.
  • Выработка рекомендаций по его совершенствованию.

Административные службы

  • Организация процессов управления проектом и помощь лидерам команд (team leads) в их использовании.
  • Организация ряда административных служб, необходимых для поддержки эффективной работы команды.

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

Будучи ответственным за календарный план, менеджмент проекта (project management) следит за всеми временными графиками внутри команды, контролирует их правомерность и интегрирует их в сводный календарный график проекта. Он, в свою очередь, подвергается мониторингу, и отчетность о ходе его выполнения направляется проектной группе и спонсору проекта.

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

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

Более детальную информацию об области компетенции “Управление проектом” и подходе MSF к управлению проектами, см. http://www.microsoft.com/msf/

Выработка архитектуры решения

“Выработка архитектуры решения” (solution architecture) – это область компетенции ролевого кластера “Управление программой”, ответственная за логический дизайн решения и описание его функций. Ее основная задача - обеспечение результативного и эффективного использования продукта потребителем для достижения своих целей.

Зоны ответственности “Выработки архитектуры решения” включают в себя:

  • Организацию высокоуровневого проектирования решения.
  • Управление функциональной спецификацией.
  • Определение рамок проекта и ключевых компромиссных решений.

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

Мероприятия, проводимые “Выработкой архитектуры решения” включают в себя:

  • Создание концепции решения и его согласование с архитектурой предприятия заказчика; разработка стратегии версионирования продукта; выработка рекомендаций к планам сбора требований.
  • Сбор требований к интероперабельности (interoperability) решения, его соответствию корпоративной архитектуре и действующим нормативам; осуществление логического проектирования; составление “карты” соответствия (traceability map) элементов дизайна изначальным требованиям заказчика; создание функциональной спецификации; спецификация промежуточных версий продукта.
  • Управление изменениями функциональной спецификации; поддержка “карты” соответствия; разъяснение спецификации другим ролевым кластерам проектной группы и внешним заинтересованным лицам; связь с другими проектными группами для обеспечения интероперабельности.
  • Участие в процессе приоритезации; формирование ожиданий заинтересованных сторон.
  • Связь с архитектурной группой предприятия; корректирование требований к будущим версиям решения.

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

Контроль производственного процесса

Область компетенции “Контроль производственного процесса” (process assurance) ролевого кластера “Управление программой” обеспечивает контроль за следованием проектной группой производственным процессам, нацеленным на достижение высококачественного результата. При этом основное внимание уделяется выявлению и устранению первопричин дефектов. “Контроль производственного процесса” имеет две основные зоны ответственности:

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

Эта область компетенции осуществляет следующую деятельность:

  • Разработка внутрипроектных производственных протоколов и процессов.
  • Консультирование по вопросам эффективного использования производственных процессов; контроль реализации процессов; определение их адекватности; выработка рекомендаций по совершенствованию процессов.

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

Административные службы

Эта область компетенции ролевого кластера “Управление программой” ответственна за реализацию процессов по управлению проектом и за административную поддержку проектной группы.

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

Ответственность административных служб включает в себя:

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

Администрация проекта осуществляет:

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

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

Ролевой кластер “Разработка”

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

В дополнение к функции непосредственной разработки решения на данный ролевой кластер возлагаются обязанности по технологическому консультированию проектной группы. В этом качестве разработчики занимаются подготовкой исходных данных для проектирования и выбора технологического инструментария решения. Также ролевой кластер “Разработка” создает функциональные прототипы для проверки правильности принятых решений и уменьшения рисков.

В качестве создателей решения разработчики осуществляют низкоуровневое проектирование решения и его элементов, оценивают трудозатраты на реализацию и затем осуществляют построение самого решения. Разработчики сами оценивают собственные затраты и отслеживают расписание, поскольку их повседневная деятельность сопряжена с различными нештатными ситуациями. Эта концепция называется оцениванием снизу вверх (bottom-up estimation) и является фундаментальной частью философии MSF. Цель данной концепции состоит в достижении большей обоснованности календарного плана и увеличении чувства ответственности тех, кто определяет сроки этого плана, и от чьей производительности зависит его выполнение.

Технологическое консультирование

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

Проектирование и осуществление реализации

  • Соотнесение архитектуры решения с архитектурой предприятия.
  • Создание и реализация логического и физического дизайна решения.

Разработка приложений

  • Программирование составляющих решения в соответствии с проектной документацией.
  • Анализ и обсуждение программного кода (code reviews) с целью обмена знаниями и опытом.
  • Осуществление тестирования модулей (unit testing) в соответствии с планом и в координации с ролевым кластером “Тестирование”.

Разработка инфраструктуры

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

Технологическое консультирование

Область компетенции “Технологическое консультирование” (technology consulting) служит ресурсом разрешения технических проблем. Выполняя роль технологических консультантов, разработчики должны предоставлять необходимую информацию для проектирования, оценки и верификации технологий; проводить предварительные исследования с целью минимизации рисков.

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

Проектирование и осуществление реализации

Область компетенции “Проектирование и осуществление реализации” (implementation architecture and design) связана с набором задач, относящихся к определению архитектуры решения и его проектированию.

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

MSF предлагает трехуровневый процесс проектирования: концептуальный дизайн (conceptual design), логический дизайн (logical design) и физический дизайн (physical design). “Управление программой” и “Управление продуктом” совместно осуществляют концептуальный дизайн. Он включает в себя сценарии использования (user scenarios), высокоуровневый анализ требований к удобству эксплуатации (usability), концептуальное моделирование данных и начальный выбор используемых технологий. Разработчики же занимаются логическими и физическими аспектами дизайна решения. Данная деятельность требует адекватных технологических знаний и умения определить влияние того или иного технологического выбора на создаваемое решение.

Разработка приложений

Область компетенции “Разработка приложений” (application development) связана с задачами разработки программных приложений в рамках проекта. Главные цели этой области компетенции – создание составляющих решения в соответствии с проектной документацией, проведение тестирования модулей, исправление дефектов, выявленных в процессе тестирования и осуществление интеграции всех компонент в окончательный продукт.

Разработчики вносят свой вклад в выработку стандартов и досконально следуют им в процессе работы над решением. Они также осуществляют анализ и обсуждение программного кода (code reviews), чтобы оценить качество проделанной работы. Проведение такого анализа позволяет членам проектной группы делиться накопленными знаниями и опытом, воплощая в жизнь фундаментальный принцип MSF – извлечение уроков на уровне команды. От разработчиков требуется проведение надлежащего тестирования модулей (unit testing) и адекватное документирование этого процесса. Такая работа осуществляется в тесной связи с ролевым кластером “Тестирование”, который планирует и производит независимую оценку качества решения.

Разработка инфраструктуры

Область компетенции “Разработка инфраструктуры” (infrastructure development) связана с задачами разработки системной инфраструктуры и инфраструктуры программного обеспечения, входящего в состав решения. Системная инфраструктура включает в себя сетевую инфраструктуру, клиентские и серверные компьютеры и все сопутствующие компоненты. Инфраструктура программного обеспечения включает в себя операционные системы клиентов и серверов, а также программные продукты, обеспечивающие необходимые сервисы (например, службы каталогов, системы обмена сообщениями, базы данных, интеграция приложений предприятия, администрирование системы, администрирование сети и т.д.).

Команда разработчиков создает инфраструктуру в соответствии с проектной документацией. Это включает в себя настройку технологических средств решения, как например, настройку сети и систем “клиент-сервер”. Составляющие инфраструктуры подвержены влиянию требований к приложениям и наоборот. Например, если критическими факторами являются надежность и производительность, может быть необходимым использование кластеризации (clustering) и балансирования загрузки (load balancing) серверов. Операционные системы и системные продукты, в среде которых будет использоваться решение, должны быть соответствующим образом установлены, сконфигурированы и оптимизированы. По окончании проведения необходимого тестирования и стабилизации компоненты инфраструктуры внедряются на широкой основе. Это внедрение осуществляется ролевым кластером “Управление выпуском”, который обеспечивает удовлетворение требований к инфраструктуре решения.

Ролевой кластер “Тестирование”

Задача ролевого кластера “Тестирование” (test) – одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Но нужно обнаружить и уладить (address) все из них до того, как продукт выпущен. Улаживание дефекта может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта (work-around). Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом – как для проектной команды, так и для заказчика.

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

Планирование тестов

  • Разработка методологии и плана тестирования.
  • Участие в установлении стандарта качества (quality bar).
  • Разработка спецификаций тестов.

Разработка тестов

  • Разработка и поддержка автоматизированных тестов (automated test cases), инструментов и скриптов.
  • Проведение тестов с целью определения состояния проекта.
  • Управление билдами (manage the build process).

Отчетность о тестах

  • Доведение до сведения проектной группы информации о качестве продукта.
  • Мониторинг найденных ошибок с целью обеспечения их улаживания до выпуска продукта.

Планирование тестов

Данная область компетенции (планирование тестов – test planning) ролевого кластера “Тестирование” формулирует методологию нахождения и урегулирования проблем качества продукта.

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

Существенная часть работы данной области компетенции заключается в участии в выработке требуемого уровня качества (quality bar) продукта. Эта деятельность включает в себя предоставление проектной группе метрик контроля качества и критериев успешности решения.

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

Разработка тестов

Эта область компетенции (разработка тестов – test engineering) ответственна за предусмотренные планом тестирования мероприятия,  направленные на нахождение и урегулирование всех проблем качества создаваемого продукта. В их числе – работа по созданию и поддержке тестовых сценариев (test cases), разработка средств, скриптов и документации процесса тестирования, управление ежедневными билдами (daily builds), проведение на них тестов с целью четкого определения уровня завершенности продукта.

Отчетность о тестах

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

Чтобы все найденные проблемы были разрешены до окончательного выпуска продукта, проводится их мониторинг (tracking). Регулярно осуществляется документирование состояния проблем (включая задания по их разрешению, приоритеты, методы урегулирования и возможные пути их обхода), что позволяет проектной группе постоянно иметь текущие данные о качестве продукта и детальный анализ тенденций его изменения.

Ролевой кластер “Удовлетворение потребителя”

Цель этого ролевого кластера (удовлетворение потребителя - user experience) – повышение эффективности использования продукта. Кластер состоит из шести областей компетенции: общедоступность (accessibility), интернационализация (internationalization), обеспечение технической поддержки (technical communications), обучение пользователей (training), удобство эксплуатации (usability) и графический дизайн (graphic design). В рамках каждой из своих областей компетенции ролевой кластер “Удовлетворение потребителя” имеет несколько зон ответственности, необходимых для потребительского успеха решения. Ниже следует их перечисление.

Общедоступность

Учет требований общедоступности (доступности для людей с недостатками зрения, слуха и т.п.) в дизайне решения.

Интернационализация

Улучшение качества и удобства эксплуатации решения в иноязычных средах.

Обеспечение технической поддержки

  • Проектирование и разработка документации для служб поддержки (настольные руководства сотрудников служб поддержки, базы знаний и т.д.)
  • Наполнение системы помощи.

Обучение пользователей

Выработка и реализация стратегии обучения пользователей.

Удобство эксплуатации (эргономика)

  • Сбор, анализ и приоритезация требований пользователей (user requirements).
  • Анализ и обсуждение дизайна продукта.
  • Разработка сценариев и примеров использования (usage scenarios and use cases).
  • Представление интересов потребителя в проектной группе.

Графический дизайн

Дизайн пользовательского интерфейса.

Общедоступность

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

Требования общедоступности должны учитываться на всем протяжении разработки решения и обычно включают:

  • Добавление пункта об общедоступности в спецификацию каждого элемента решения.
  • Включение разделов об общедоступности в систему помощи.
  • Обеспечение полноты документации по общедоступности.
  • Обеспечение наличия документации по общедоступности (accessibility) в общедоступных (accessible) форматах.

Интернационализация

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

Глобализация

Глобализация (globalization) – процесс проектирования и разработки решения, при котором предусматривается возможность его локализации без изменения самого решения и излишней работы. Другими словами, выпущенное решение должным образом глобализировано, если возможна его локализация с минимальными издержками.

Локализация

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

Обеспечение технической поддержки

“Обеспечение технической поддержки ” занимается разработкой системы документирования и поддержки решения.

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

Дополнительная задача “Технической поддержки” – проектирование и разработка документации к решению, что может включать в себя разработку руководств по его установке, модернизации, использованию и улаживанию возникающих трудностей.

Обучение

Эта область компетенции обеспечивает повышение производительности пользователя путем обучения его навыкам, необходимым для эффективного использования решения. Это достигается применением действенной стратегии обучения. Задача разработки такой стратегии возлагается на ролевой кластер “Удовлетворение потребителя”.

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

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

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

Удобство эксплуатации (эргономика)

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

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

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

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

Графический дизайн

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

Ролевой кластер “Управление выпуском”

Цель этого ролевого кластера – беспрепятственное внедрение и сопровождение продукта. Эта роль служит связующим звеном между проектной группой и группами процессов сопровождения. Данный ролевой кластер включает в себя следующие области компетенции:

  • Инфраструктура (infrastructure)
  • Сопровождение (support)
  • Бизнес-процессы (operations)
  • Управление выпуском готового продукта (commercial release management).

“Управление выпуском”:

  • выполняет посреднические функции между группами разработки и сопровождения;
  • выбирает инструментарий внедрения и способствует его автоматизации и оптимизации;
  • устанавливает операционные критерии готовности продукта к выпуску;
  • участвует в разработке дизайна, отвечая за управляемость (manageability), удобство сопровождения (supportability) и удобство внедрения (deployability) конечного продукта;
  • организует обучение персонала сопровождения;
  • подготавливает и создает систему сопровождения опытного внедрения (pilot deployment);
  • планирует и обеспечивает поточный выпуск продукта (deployment into production);
  • контролирует соответствие результатов стабилизации продукта критериям приемлемости.

Инфраструктура

  • Планирование инфраструктуры предприятия.
  • Координация использования помещений и кросс-географическое планирование (центры данных, лаборатории, филиалы и периферийные офисы).
  • Разработка правил и инструкций для согласованного управления инфраструктурой.
  • Обеспечение инфраструктурного обслуживания проектной группы (серверы, стандартные образы дисков для рабочих станций, установка программного обеспечения).
  • Организация снабжения проектной группы аппаратным и программным обеспечением.
  • Создание тестовых и испытательных сред (test and staging environments), воспроизводящих рабочую среду (production environment).

Сопровождение

  • Обеспечение связи и обслуживания заказчиков и потребителей.
  • Управление соглашениями об уровне услуг (SLA – service level agreement) и обеспечение их надлежащего исполнения.
  • Организация оперативного разрешения пользовательских проблем и нештатных ситуаций.
  • Предоставление команде разработчиков обратной связи.
  • Разработка процедур действия в нештатных ситуациях.

Бизнес-процессы

  • Управление учетными записями.
  • Поддержка средств обмена сообщениями, баз данных, телекоммуникаций и сетей.
  • Системное администрирование.
  • Управление брандмауэром (firewall); администрирование системы безопасности.
  • Обслуживание приложений.
  • Интеграция серверов.
  • Поддержка служб каталогов.

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

  • Регистрационные коды продукта; процесс верификации регистрации.
  • Управление лицензиями.
  • Подготовка дистрибутивных комплектов.
  • Управление каналами дистрибуции продукта.
  • Печатные и электронные публикации.

Инфраструктура

Данная область компетенции включает в себя ряд задач, связанных с организацией инфраструктуры поддержки. Её характеристики сходны с характеристиками ролевого кластера “Инфраструктура” (infrastructure) MOF (Microsoft Operation Framework).

Сопровождение

Эта область компетенции следит за тем, чтобы создаваемое и внедряемое решение было удобным в сопровождении. Её характеристики сходны с характеристиками ролевого кластера “Сопровождение” (support) MOF.

Бизнес-процессы

Эта область компетенции связана с рядом операционных задач, которые должны выполняться при осуществлении проекта. Она ответственна за то, чтобы создаваемое и внедряемое решение было согласованным с имеющими к нему отношение бизнес процессами. Её характеристики сходны с характеристиками ролевого кластера “Бизнес процессы” (operations) MOF.

Управление выпуском конечного продукта

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

Масштабирование модели проектной группы

В своей книге “Rapid Development” бывший разработчик программного обеспечения Майкрософт Steve McConnell пишет:

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

Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия.

Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т.н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.

Группы направлений

Каждый ролевой кластер проектной группы имеет одну или несколько составляющих, образующих иерархическую структуру (желательно, максимально простую). Например, тестировщики подотчетны менеджеру тестирования.

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

В “Rapid Development” Steve McConnel писал:

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

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

Рисунок 2.    Группы направлений

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

Функциональные группы

Функциональные группы – это группы, существующие внутри ролевых кластеров. Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции. Например, в Майкрософт группа управления продуктом обычно включает специалистов по планированию продукта и специалистов по маркетингу. Как первая, так и вторая сферы деятельности относятся к управлению продуктом: одна из них сосредотачивается на выявлении качеств продукта, действительно интересующих заказчика, а вторая – на информировании потенциальных потребителей о преимуществах продукта.

Аналогично, в команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс пользователя, бизнес-логика или объекты данных. Часто программистов разделяют на разработчиков библиотек и разработчиков решения. Программисты библиотек обычно используют низкоуровневый язык C и создают повторно используемые компоненты, которые могут пригодиться всему предприятию. Создатели же решения обычно соединяют эти компоненты и работают с языками более высокого уровня, такими как, например Microsoft® Visual Basic®.

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

Объединение ролей

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

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

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

Рисунок 3.    Объединение ролей в малых проектах

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

Знак “-” на пересечении столбца со строкой означает, что сочетание соответствующих ролей недопустимо, за исключением случаев, когда это абсолютно необходимо, и когда связанные с этим риски могут быть уменьшены эффективными планами их предотвращения и смягчения последствий. Ясно, что имеются различные уровни конфликтов между ролями, что делает модель проектной группы динамичной и затрудняет объединение ролей. Однако на практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.

Эскалация и подотчетность

Модель проектной группы не есть организационная структура

При применении модели проектной группы MSF постоянно возникает вопрос: “Кто ответственен?” Из организационной структуры всегда ясно, на ком лежит та или иная ответственность, и кто кому подотчетен. В противоположность этому, модель проектной группы MSF описывает ключевые роли и задачи в команде, но не определяет управленческую структуру с точки зрения административных полномочий персонала. Во многих случаях проектная группа состоит из людей, принадлежащих разным организациям, и они могут быть административно подотчетны различным руководящим лицам.

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

Внешняя координация – на ком лежит ответственность?

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

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

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

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

Рисунок 4.    Коммуникации

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

Заключение

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

Поясняя это, Steve McConnell в “Rapid Development” пишет:

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

Для получения дальнейшей информации, см.:
Microsoft Solutions Framework: http://www.microsoft.com/msf/
Microsoft Operations Framework: http://www.microsoft.com/mof/

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

Данный обзор носит чисто информативный характер. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, НИ ЯВНО ВЫРАЖЕННЫХ, НИ ПОДРАЗУМЕВАЕМЫХ, В СВЯЗИ С ДАННЫМ ДОКУМЕНТОМ.

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

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

© Корпорация Майкрософт (Microsoft Corp.), 2002. Все права защищены.

Microsoft и Visual Basic являются охраняемыми товарными знаками корпорации Майкрософт в США и других странах.

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

Перевод данного документа на русский язык был осуществлен в 2003 г. корпорацией eLine Software (http://www.elinesoftware.com). Другие документы по MSF на русском языке доступны в Internet по адресу: http://www.microsoft.com/rus/msf .

Защитный код
Обновить