Методология ведения проектов MSF

В своей проектной деятельности мы руководствуемся методологией MSF (Microsoft Solution Framework)  (https://learn.microsoft.com/en-us/previous-versions/tn-archive/bb497060(v=technet.10)?redirectedfrom=MSDN)

 

MSF состоит из двух моделей и трех дисциплин

Модели:

• • модель проектной группы
  • модель процессов

Дисциплины

• • Управление проектами
  • Управление рисками
  • Управление квалификацией

 

Модель проектной группы

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

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

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

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

Основополагающие принципы MSF 

1. Свободная коммуникация.

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

2. Общее видение

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

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

3. Полномочия и ответственность

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

4. Разделяйте ответственность

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

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

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

5. Сотрудничайте с клиентом и сосредоточьтесь на предоставлении бизнес-ценности

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

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

6. Гибкость и перемены

Будьте готовы к переменам и оставайтесь гибкими.

Любая разработка программного обеспечения требует времени. Это означает, что на каком-то этапе работы требования заказчика могут измениться — к этому стоит быть готовыми.

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

7. Инвестируйте в качество

Успех команды зависит от того, насколько каждый специалист осознает свою ответственность за продукт. Чтобы обеспечить высокое качество решения, на протяжении всего проекта работает группа тестирования — в ее задачи входит раннее выявление ошибок и недочетов. Обнаруженные баги надо исправлять как можно скорее, чтобы они не повлияли на разработку. Microsoft Solution Framework требует, чтобы в планы и графики изначально вносилось время на устранение недостатков. Только в этом случае можно уложиться в срок.

8. Учитесь на опыте

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

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

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

 

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

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

1. Команда соратников
2. Сфокусированность на нуждах заказчика
3. Нацеленность на конечный результат
4. Установка на отсутствие дефектов
5. Стремление к самосовершенствованию
6. Заинтересованные команды работают эффективно

 

Проектные роли

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

Несмотря на множество ролей, модель MSF подходит не только большим коллективам, но и маленьким командам: в этом случае каждый участник берет на себя несколько ролей. 

Методология MSF подчеркивает, что все роли — равноправны, и ни один член команды не может считаться более влиятельным или принимать решения единолично.

Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же — построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта.

В каждую проектную группу входят такие ролевые кластеры:

1. Бизнес-аналитик (product manager)

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

2. Менеджер проекта (project manager)

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

3. Архитектор (program manager)

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

4. Разработчик (developer)

Кажется, что роль разработчика — самая незатейливая. Рабочая лошадка: создает код и воплощает идеи клиента, трансформированные в техническое задание усилиями бизнес-аналитика и архитектора. И придерживается сроков, установленных проект-менеджером. 

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

5. Тестировщик

Задача тестировщика — выявить в продукте баги, проблемы и неудачные решения, которые могут негативно сказаться на качестве и снизить ценность приложения для клиента. Тестировщик обязан понимать и учитывать контекст применения программного продукта: кто, как и для чего будет его использовать на стороне заказчика. Если функция X выполняется корректно и выдает правильный результат, но его получение занимает в среднем час, тестировщик может признать ее работу неудовлетворительной — зная, что клиенту требуется выполнять эту функцию 20–30 раз в день. 

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

6. Релиз-менеджер

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

7. Удовлетворение заказчика (user experience)

Обучение, эргономика, графический дизайн, техническая поддержка.

 

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

В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:

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

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

MSF не предоставляет конкретных рецептов управления проектами и не содержит объяснений разнообразных методов работы, которые применяют опытные менеджеры. Принципы MSF формируют такой подход к управлению проектами, при котором:

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

Как следует из вышесказанного, одна из характерных особенностей MSF — отсутствие должности менеджера проекта!

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

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

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

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

 

Модель процесса MSF

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

Но структура у всех процессов одна и та же:

 

Milestone	Primary Driver(s)
Vision/Scope Approved	Product Management
Project Plans Approved	Project Management
Scope Complete	Development and User Experience
Release Readiness Approved	Test and Release Management
Deployment Complete	Release Management

 

По окончании каждого этапа процесса (milestone) команда рассматривает результаты своего труда и отвечает на вопросы «Сделали ли мы все, что планировали?», «Работает ли решение так, как нужно заказчику?», «Готовы ли мы двигаться дальше или необходимо уделить внимание доработкам?». Чтобы перейти на следующий этап, необходимо дать большинство положительных ответов.

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

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

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

 

Этапы процесса (итерации):

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

2. Планирование (Planning)
Задачи, которые необходимо выполнить в ходе итерации, разбиваются на подзадачи, определяется сложность их реализации, устанавливаются сроки и назначаются ответственные. В планы закладывается время на тестирование и исправление дефектов, а также предварительно намечается, как именно будет проходить тестирование.

3. Разработка (Developing)
На данном этапе MSF создается программный код новой функциональности в соответствии с концепцией и утвержденными планами.

4. Стабилизация (Stabilizing)
К делу подключаются тестировщики. После тестирования выявленные баги и недочеты возвращаются разработчикам для исправления. 

5. Внедрение (Deploying)
Очередной релиз программного продукта передается заказчику и устанавливается на клиентских компьютерах. 

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

 

Дисциплины MSF

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

Это целый набор навыков и компетенций, в том числе:

• Комплексное планирование всех этапов и аспектов проекта;
• Контроль изменений
• Определение и отслеживание рамок и ограничений проекта
• Управление бюджетом, расходами и ресурсами;
• Получение нужных ресурсов, выделяемых на проект

• Управление контрактами и поставщиками, а также закупка ресурсов проекта.

• Организация командных и внешних коммуникаций.

• Содействие процессу управления рисками.

• Составление и отслеживание графиков

• Документирование и отслеживание процесса управления качеством команды.

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

 

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

Риски — это факторы и события, которые могут оказать негативное влияние на проект. Даже в перспективе. В MSF есть специальный процесс, который помогает выявлять, отслеживать и минимизировать риски. Он состоит из шести шагов.

1. Определение рисков

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

2. Анализ и расстановка приоритетов

Насколько серьезную угрозу представляет выявленный риск для проекта? Возможно ли избежать проблем? Требуются немедленные действия или время терпит? Необходимы ли дополнительные ресурсы, например время на поиск решения?

Все эти вопросы обсуждаются коллегиально. 

3. План и график

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

4. Отслеживание и отчет

Придерживаться принятого плана неукоснительно — половина дела в MSF. Любое изменение в проекте может повлечь новые риски или рецидив старых. Отслеживание рисков помогает держать их под контролем и своевременно пересматривать тактику борьбы с ними.

5. Контроль

Контроль — это исполнение планов в отношении рисков и связанных с ними отчетов. 

6. Знание

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

 

Управление квалификацией

Эта дисциплина занимается вопросами профессионального роста и подготовки специалистов.

 

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

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

Процесс управления квалификацией включает четыре этапа:

1. Определение необходимых квалификаций

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

2. Оценка сотрудников

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

3. Повышение квалификации

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

4. Подведение итогов

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

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