Процессы планирования

Возможный состав плана управления проектом:

• План управления содержанием
• План управления временем
• План управления стоимостью
• План управления рисками
• План управления качеством
• План управления закупками
• План управления коммуникациями
• План управления сотрудниками
• План управления конфигурациями
• Описание общих принципов планирования

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

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

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

Планирование содержания

Входы:

• устав проекта
• состав «плана управления проектом»

Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить конечный результат (продукт).

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

1. Собрать и финализировать требования
2. Сформировать концепцию
3. Создать ИСР (WBS)

Формирование концепции и создание ИСР (WBS) разделены еще двумя этапами из других областей знаний.

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

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

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

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

Лучшие проектные практики гласят:

• проект с неудовлетворенными ожиданиями заказчика не является успешным
• проект, результаты которого не используются конечными пользователями, не является успешным

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

Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.

По какому принципу можно отнести того или иного человека к «заинтересованным лицам»:

1. Это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).
2. Заинтересованным лицом всегда являются конечные пользователи продукта (ни в коем случае нельзя пренебрегать их интересами в проекте!).
3. Начальники членов вашей команды.
4. Те, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.
5. Последняя группа заинтересованных лиц – наиболее трудна к выявлению, однако порой вклад таких «серых кардиналов» очень велик. В качестве примера можно привести гипотетическую ситуацию, когда сын заказчика является в его глазах авторитетом в сфере информационных технологий и привлекается отцом к принятию принципиальных решений о внедряемых системах. При этом сын не является сотрудником ни одной из участвующих в проекте организаций (или, допустим, вообще еще школьник). Однако высказанные им советы имеют для папы больший вес, чем экспертные заключения его же сотрудников. Возможно, «добраться» до такого «заинтересованного лица» в ходе проекта вам и не удастся, но, знать (или, хотя бы, предполагать его существование) – достаточно важно.

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

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

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

Из наиболее распространенных можно выделить:

• Интервью
• Опросники
• Мозговые штурмы (в различных вариациях)
• Прототипирование

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

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

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

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

После того, как процесс запущен, и требования стали поступать – необходимо фиксировать их. Для этого рекомендуется обзавестись выделенным списком, называть его можно «матрицей требований». Пример такого документа приведен в Приложении3.

Матрица позволяет фиксировать – когда обнаружено требование, кто автор (кто высказал), насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор.

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

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

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

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

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

Факторы среды предприятия

Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта.

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

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

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

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

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

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