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

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

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

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

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

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

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

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

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

Ключевые концепции модели процессов MSF

Для описания модели процессов MSF будут использоваться следующие концепции и термины:

Заказчики

MSF различает термины “заказчик" (customer) и “потребитель” (пользователь, user) продукта[†].

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

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

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

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

· Контракты. MSF признает первостепенную важность договорных и юридических отношений между заказчиком, его поставщиками и проектной командой и необходимость управления этими отношениями. Точка зрения MSF на управление поставками (Procurement management) отражена в “Белой книге” дисциплины управления проектами MSF. Однако существует множество других литературных источников, освещающих указанную предметную область, поэтому в данном документе тема управления поставками досконально не исследуется.

Заинтересованные стороны

Заинтересованные стороны (stakeholders) – это лица или группы лиц, чьи интересы затрагиваются результатами проекта[‡]. Не всегда цели и приоритеты различных заинтересованных сторон совпадают со стремлениями заказчика. Каждая заинтересованная сторона преследует цели и выдвигает требования, важные именно для нее.

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

Вот примеры заинтересованных сторон, представленных обычно в IT-проектах:

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

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

· Функциональные руководители (functional managers), обеспечивающие проектную группу необходимыми ресурсами.

Что есть решение?

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

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

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

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

На рис. 4 представлены основные элементы успешного решения.

Рисунок 4. Элементы решения

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

В дополнение к этому:

· Программно-технические средства /специально разрабатываемый код (custom code) могут быть как новыми, так и усовершенствованными версиями ранее разработанных компонент (в т.ч. содержащими вновь добавляемые элементы).

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

· Обучение затрагивает каждого, кто будет использовать или сопровождать решение после его внедрения.

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

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

· Внешние коммуникации включают в себя информирование внешних заинтересованных сторон о ходе внедрения решения и его влиянии на их интересы.

· Внедрение включает в себя процедуры установки/удаления внедряемого аппаратного и программного обеспечения, автоматизированные инструменты внедрения и сценарии “отката” (rollback) в аварийных ситуациях.

Создание базовых версий

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

Рамки проекта

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

Четкое очерчивание рамок предоставляет возможность:

· Разбиения долговременных планов на достижимые составляющие.

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

· Гибкости в планировании и реализации решения.

· Создания базиса для выработки компромиссов.

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

Термин “рамки” имеет два аспекта: рамки решения и рамки проекта. Несмотря на то, что между ними имеется тесная взаимосвязь, они не тождественны друг другу. Понимание различий между ними помогает эффективному управлению календарным графиком и стоимостью проекта.

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

Рамки проекта (project scope) определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения. Некоторые организации называют рамки проекта “описанием работы” (statement of work - SOW).

Формулирование рамок проекта позволяет проектной группе:

· Сфокусироваться на той работе, которую необходимо выполнить.

· Облегчить разбиение объемных и нечетких задач на меньшие, легко понимаемые.

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

· Облегчить распределение фронта работ среди субподрядчиков и партнеров проектной группы.

· Разграничить те части решения, за которые несет ответственность проектная группа, от других частей, за которые она ответственности не несет.

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

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

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

В силу свойственной IT-проектам неопределенности и рискованности, одним из ключевых факторов их успеха являются эффективные компромиссные решения (trade‑offs).

Треугольник компромиссов

Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник, показанный на рис. 5.

После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.

Рисунок 5. Треугольник компромиссов

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

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

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