Несмотря ни на что, MSF получила признание в узких кругах специалистов, которым она действительно нужна, проектных менеджеров, аналитиков и архитекторов. Причиной тому отчасти была первая буква аббревиатуры - «М», ведь никто не может сказать, что Microsoft не умеет выпускать софт. Значит и методика от Microsoft должна работать. Другая причина признания MSF в том, что несмотря на свою монструозность, она содержит массу интересных и полезных вещей. Например, модель проектной группы MSF, или методика управления рисками (я знаю многих менеджеров, которые используют Excel шаблон MSF Risk Mitigations несмотря на наличие всяческих продвинутых инструментов именно из-за его простоты и удобства).
Одна из таких полезных вещей – треугольник компромиссов (tradeoff triangle), и связанная с ним матрица компромиссов (tradeoff matrix).
Треугольник компромиссов отражает в виде красивой метафоры хорошо известную всем, он жестоко попираемую на практике зависимость между ресурсами, временем и объемом работ (или реализованными возможностями) в проекте.
Принципы здравого смысла особенно часто и с особой жестокостью попираются на этапе предпроекта. Когда идет определение объема работ (scope) и сроков проекта мы часто слышим начальствующий глас - «проект должен быть завершен к концу финансового года», «бюджет не позволяет взять третьего программиста», «тестировщиков не будет, тестируйте силами программистов» и т.д. В такой ситуации процесс предварительного планирования, согласования скоупа и сроков проходит в бесконечных переговорах, в ходе которых у команды постепенно вырисовывается безрадостная перспектива очередного безнадежного проекта.
Направить анализ и планирование в конструктивное русло и помогает треугольник компромиссов. Для начала всем следует согласиться с тем, что ресурсы сроки и скоуп - это три взаимозависимых параметра. Затем следует выработать стратегию, которой вы (заказчик и проектная команда) будете придерживаться при планировании. Эта стратегия выражается в матрице компромиссов. В чем ее суть?
У нас есть три параметра планирования: ресурсы, время, функционал, и три стратегии для них: фиксировать, оптимизировать, «как получится».
Крестики можно расставлять как вздумается, главное соблюдать основное правило заполнения матрицы компромиссов - в каждой строке и в каждом столбце может быть только один крестик. Это значит, что к каждому параметру мы применяем только одну стратегию. Что означают эти стратегии?
«Фиксируем» (constarain) - данным параметром не может управлять ни заказчик ни проектная команда. По взаимной договоренности (или из-за внешних ограничений) этот параметр принимается неизменным.
«Оптимизируем» (optimize) - управление данным параметром отдается заказчику. По сути дела этот параметр тоже фиксируется, но не столь жестко. Данный параметр наиболее важен заказчику и он стремится добиться нужного ему значения.
«Как получится» (accept) – управление данным параметром отдается проектной команде, поскольку данный параметр менее важен для заказчика. Очевидно, что когда одна переменная зафиксирована, а вторая подвергается оптимизации, значение третьей переменной определяется значениями первых двух. Термин «как получится» для перевода с английского “accept” придумал использовать не я. Его использовали в старом учебнике к экзамену 70-100, и мне он кажется наиболее подходящим в данной ситуации.
Наиболее часто используется стратегия когда фиксируются ресурсы, оптимизируется время, а функционал – «как получится». Хотя иногда бывает необходимым зафиксировать время или функционал (чаще для коробочных продуктов).
В любом случае, я рекомендую включать матрицу компромиссов в план управления проектом, или в тот документ, который его заменяет. Назовите ее «Стратегией управления проектом» или «Стратегией планирования». Добейтесь чтобы заказчик ее подписал. И показывайте ее, как крестное знамение, всякий раз, когда у заказчика возникает желание «добавить еще один отчетик» или перенести сроки выпуска релиза.
Комментариев нет:
Отправить комментарий