воскресенье, 29 ноября 2009 г.

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

В силу рабочих вопросов заинтересовалась подходами к разработке продуктов в различных компаниях. Набрела на MSF - Microsoft Solution Framework.
Документ очень интересный. Меня, в частности, заинтересовала "белая книга", в которой описывается Модель проектной группы MSF.

Отмечу несколько моментов:

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

- Управление продуктом
- Управление программой
- Разработка
- Тестирование
- Удовлетворение потребителя
- Управление выпуском

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


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

2. Еще одним ключевым моментом является сосуществование фазового и итерационного подхода в рамках одного проекта.

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

- выработка концепции (shared vision),
- планирование,
- разработка,
- стабилизация (тестирование),
- внедрение.

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


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

3. Документирование используется и имеет такой нюанс - спецификации по проекту должны быть "живыми".

Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. «Живые» документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту.
В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.


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

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

Поскольку речь идет от ПО, на внедрении ничего не заканчивается - в случае успеха последуют следующие версии продукта...


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

Модель проектной группы MSF по духу, не по сути, напомнила мне вычитанную где-то фразу, сразу скажу,за точность не ручаюсь:
В МС если разработчик идет по коридору и думает, то обязанность менеджера проекта - отодвинуть стул с его дороги, чтобы он мог додумать мысль до конца :)
Попросту говоря - дайте квалифицированным специалистам работать!

Вместе с тем подход далеко не идеален - думаю как раз наоборот:

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



Ссылки:

http://ru.wikipedia.org/wiki/Microsoft_Solutions_Framework
http://www.citforum.ru/SE/project/msf/

3 комментария:

bialix комментирует...

Про убирание стульев с дороги разработчиков -- это было у незабвенного нашего Джоэля.

gAmUssA комментирует...

У меня есть книга (бумажная) про MSF от Microsoft Press "Анализ требований и создание архитектуры решений на основе Microsoft.Net".
Если Вы в Москве, то мог бы на что-то поменяться :-)

Omega комментирует...

Я в Нижнем Новгороде :) Спасибо за название, книжку уже нашла на http://www.ozon.ru/context/detail/id/1615787/ :)