Файл: Треугольник компромиссов интернет проекта (Создание базовой версии).pdf
Добавлен: 06.07.2023
Просмотров: 28
Скачиваний: 1
Введение
В свое время, Microsoft, решив внести свою лепту в методологию разработки ПО, создала Microsoft Solutions Framework (MSF) – методологию от Microsoft. Возможно сказалось стремление переплюнуть RUP и обойти IBM в извечной конкурентной борьбе, возможно были другие причины, но методика получилась весьма тяжеловесной. Вечным свидетельством тому, служит учебник для подготовки к экзамену 70-100 в который сполна напихали этого MSF.
Несмотря ни на что, MSF получила признание в узких кругах специалистов, которым она действительно нужна, проектных менеджеров, аналитиков и архитекторов. Причиной тому отчасти была первая буква аббревиатуры - «М», ведь никто не может сказать, что Microsoft не умеет выпускать софт. Значит и методика от Microsoft должна работать. Другая причина признания MSF в том, что несмотря на свою монструозность, она содержит массу интересных и полезных вещей. Например, модель проектной группы MSF, или методика управления рисками.
Одна из таких полезных вещей – треугольник компромиссов (tradeoff triangle), и связанная с ним матрица компромиссов (tradeoff matrix).
Создание базовой версии
В модели процессов MSF базовая версия (baseline) – это известное и зафиксированное состояние чего-либо, используемое для последующего сравнения. Это понятие встречается в MSF весьма часто. Программный код, конфигурации серверов, планы и календарные графики, спецификации, руководства пользователей и бюджет – вот лишь часть тех составляющих проекта, для которых MSF рекомендует использовать базовые версии. Не имея базовых версий, нет возможности управлять изменениями.
Рамки проекта
Рамки (scope) – это сумма всех составляющих проекта, которые должны стать результатом работы над ним, а также все предоставляемые услуги, имеющие отношение к проекту. Рамки проекта определяют, что должно быть сделано для реализации единого видения. Они являются результатом компромисса между сформулированными целями и условиями реальности и отражают приоритезацию заказчиком имеющихся требований к создаваемому решению. Частью процесса определения рамок проекта является вынесение менее важной функциональности из текущего проекта в планы на будущее.
Четкое очерчивание рамок предоставляет возможность:
- Разбиения долговременных планов на достижимые составляющие.
- Определения функциональности, добавляемой в каждую из выпускаемых версий решения.
- Гибкости в планировании и реализации решения.
- Создания базиса для выработки компромиссов.
Необходимо определить рамки как для производимой работы и набора предоставляемых услуг, так и для функциональности создаваемого решения.
Термин “рамки” имеет два аспекта: рамки решения и рамки проекта. Несмотря на то, что между ними имеется тесная взаимосвязь, они не тождественны друг другу. Понимание различий между ними помогает эффективному управлению календарным графиком и стоимостью проекта.
Рамки решения (solution scope) определяют функциональность решения и его возможности (включая те, что не относятся к программному обеспечению). Возможность (функциональность, составляющая, feature) – это требуемый или желаемый аспект программного или аппаратного обеспечения. Например, предварительный просмотр перед печатью может быть возможностью текстового процессора; шифрование почтовых сообщений – возможностью почтовой программы. Сопроводительные руководства пользователей, интерактивные файлы помощи, операционные руководства и обучение также могут быть составляющими (features) решения.
Рамки проекта (project scope) определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения. Некоторые организации называют рамки проекта “описанием работы” (statement of work - SOW).
Формулирование рамок проекта позволяет проектной группе:
- Сфокусироваться на той работе, которую необходимо выполнить.
- Облегчить разбиение объемных и не четких задач на меньшие, легко понимаемые.
- Выявить специфическую работу, не увязанную напрямую с реализацией какой-либо составляющей проекта (например, подготовка текущих отчетов).
- Облегчить распределение фронта работ среди субподрядчиков и партнеров проектной группы.
- Разграничить те части решения, за которые несет ответственность проектная группа, от других частей, за которые она ответственности не несет.
- Обеспечить персонификацию ответственности за создание и поддержку каждой из составляющих решения. Зачастую (особенно в больших проектах) существуют составляющие, поставка которых не входит в задачи проектной группы. Например, проектная группа может разрабатывать корпоративную систему управления снабжением, которая взаимодействует с системой управления ресурсами предприятия. Задача по интеграции двух систем входит, безусловно, в рамки решения, но она может не быть в рамках проекта, разрабатываемого командой.
Управление компромиссами
Управление рамками проекта критично для его успеха. Неудачи многих ИТ проектов, включая затягивание сроков и перерасход средств, обусловлены плохой организацией управления их рамками. Эта деятельность должна включать в себя раннее определение рамок проекта, хорошо организованные мониторинг его хода и управление изменениями.
В силу свойственной IT-проектам неопределенности и рискованности, одним из ключевых факторов их успеха являются эффективные компромиссные решения (trade offs).
Треугольник компромиссов
Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник, показанный на рис. 1.
После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.
Рисунок 1. Треугольник компромиссов
Нахождение верного баланса между ресурсами, временем разработки и возможностями – ключевой момент в построении решения, должным образом отвечающего нуждам заказчика.
Иногда заказчики не хотят, чтобы в жертву приносились определенные (не необходимые) возможности продукта. Изображенный выше треугольник помогает проиллюстрировать им суть имеющихся ограничений и служит инструментом поиска компромиссных решений.
Реализуемая функциональность должна иметь качество не ниже определенного уровня. Параметр качества может быть изображен в виде четвертого измерения, превращающего треугольник в тетраэдр (треугольную пирамиду). Хотя снижение порога качества (quality bar) дает возможность сократить затрачиваемые ресурсы/время и увеличить функциональность решения, это ведет, безусловно, к неизбежно плохому результату.
Матрица компромиссов проекта
Другое весьма полезное средство для управления проектными компромиссами – матрица компромиссов проекта (project tradeoff matrix), показанная на рис. 2. Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях. В определенных случаях из этой приоритезации могут делаться исключения, но в целом следование ей облегчает достижение соглашений по спорным вопросам.
Нельзя произвольно сокращать функциональность решения. Как проектная группа, так и заказчик должны тщательно проанализировать все имеющиеся в проекте ограничения и быть готовыми идти на обусловленные ими уступки.
Рисунок 2. Матрица компромиссов
«Фиксируем» (constarain) - данным параметром не может управлять ни заказчик ни проектная команда. По взаимной договоренности (или из-за внешних ограничений) этот параметр принимается неизменным.
«Оптимизируем» (optimize) - управление данным параметром отдается заказчику. По сути дела этот параметр тоже фиксируется, но не столь жестко. Данный параметр наиболее важен заказчику и он стремится добиться нужного ему значения.
«Как получится» (accept) – управление данным параметром отдается проектной команде, поскольку данный параметр менее важен для заказчика. Очевидно, что когда одна переменная зафиксирована, а вторая подвергается оптимизации, значение третьей переменной определяется значениями первых двух. Термин «как получится» для перевода с английского “accept” придумал использовать не я. Его использовали в старом учебнике к экзамену 70-100, и мне он кажется наиболее подходящим в данной ситуации.
Наиболее часто используется стратегия когда фиксируются ресурсы, оптимизируется время, а функционал – «как получится». Хотя иногда бывает необходимым зафиксировать время или функционал (чаще для коробочных продуктов).
Возможны такие логические взаимосвязи:
- Зафиксировав ресурсы, мы согласовываем календарный график и принимаем результирующий объем функциональности решения.
- Зафиксировав ресурсы, мы согласовываем функциональность решения и принимаем результирующие сроки.
- Зафиксировав объем функциональности решения, мы согласовываем затрачиваемые ресурсы и принимаем результирующие сроки.
- Зафиксировав объем функциональности решения, мы согласовываем календарный график и принимаем результирующие затраты ресурсов.
- Зафиксировав календарный график, мы согласовываем затраты ресурсов и принимаем результирующую функциональность решения.
- Зафиксировав сроки, мы согласовываем объем функциональности решения и принимаем результирующие затраты ресурсов.
Принципиально важно наличие у проектной группы и заказчика единого, однозначного взгляда на матрицу компромиссов проекта.
Вывод
Подытожим. Методология очень интересна, если не сказать больше. Ее можно использовать как эффективный инструмент, подходя к нему с творческой изобретательностью и осмысленностью. Нет, наверное, такой методологии управления, строгое соответствие которой, обеспечит успешность проекта. Не нужно воспринимать MSF как догму или панацею. Можно её адаптировать под свои нужды или использовать только фрагменты или концепции применимые в Вашем проекте.