Планирование и контроль проекта

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

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

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

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

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

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

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

Часто выделение распознаваемых контрольных результатов для указания в базовом плане становится достаточно сложной задачей, особенно в организациях с низким уровнем зрелости процессов. Качество и полнота контрольного результата должны быть подтверждены незаинтересованной и достаточно квалифицированной стороной или участником проекта, цели которого не совпадают с целями проектной команды. В большинстве организаций, реализующих ИТ-проекты, этим участником является служба защиты информации и подразделение, осуществляющее эксплуатацию будущей системы, — они не заинтересованы в поставке недоработанного продукта (он увеличивает их риск) и располагают необходимой квалификацией для его контроля. Безусловно, более корректным является выделение для этих целей подразделения, специализирующегося на контроле качества и тестировании.

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

Если руководство не сделает соответствующих выводов по опыту реализации проекта, столкнувшегося с подобными затруднениями, то и каждый последующий проект превратится в аналогичную каторжную процедуру. Если порядок реализации проектов в организации, во избежание данных сложностей, будет предусматривать контроль результата только проектной командой и руководителем проекта (например, согласование и утверждение документов внутри проектной команды), то необходимого для эффективного контроля конфликта интересов не будет, ценность такого контроля будет крайне низкой и базовый план перестанет выполнять свою функцию. Каждая контрольная точка в этом случае станет жертвой «правила 10—50—90» (если руководитель проекта говорит, что приступил к работе, то, скорее всего, даже не видел задачу, если говорит, что сделал 50%, то, скорее всего, только начал, если говорит, что заканчивает работу, то, вероятно, находится в середине пути). Именно поэтому такую низкую контрольную ценность имеют самостоятельно подготавливаемые контрольные периодические отчеты руководителя проекта. Информационную контрольную ценность имеют только результаты, подтвержденные независимой и квалифицированной стороной.

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

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

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

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

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

При составлении базового и рабочего планов широко применяется формализованный подход, основанный на многоуровневой декомпозиции результата и отдельных работ — иерархическая структура работ (ИСР, WBS). Этот подход исходит из того, что перед стартом работ по проекту весь их состав может быть детально запланирован на уровне элементарных операций, а результат сколь угодно сложного проекта является полностью определенным как по полноте, так и по показателям качества. Это допущение не является верным в случае, когда мы пересекаем границу сложности (см. гл. 2). И результат, и состав работ не являются полностью предсказуемыми в случае сложных проектов. Реализуя проект, мы постоянно движемся в сторону уточнения цели и состава работ, достигая полной определенности только в момент утверждения акта сдачи-приемки и завершения проекта.

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

Отдельные работы, возлагаемые на конечных исполнителей в проекте, могут быть детализированы до элементарных (неделимых). Они — продукт декомпозиции систем и работ. На практике принимают эффективную длительность мероприятий рабочего плана в 1—2 недели. Обратите внимание на то, что эта длительность соответствует рекомендуемой SCRUM-методом длительности спринтов.

Поскольку рабочий план служит для планирования и координации множества отдельных работ, то его объем в реальных проектах может быть достаточно большим. Количество отдельных работ в рабочих планах измеряется сотнями и тысячами. Например, в проекте длительностью 1,5 года с количеством отдельных исполнителей 10 человек, выполняющих свои работы двухнедельными «спринтами», количество пунктов рабочего плана составит не менее 300 (здесь учтено то, что длительность реальных элементарных работ составляет от недели до 2 и что исполнители по проекту не всегда выполняют работу непрерывно).

С рабочим планом и ИСР связано важное для проектного управления понятие критического пути (англ, critical path method, СРМ). Так называют инструмент планирования проекта, который основан на определении наиболее длительной последовательности задач от начала проекта до его окончания с учетом их взаимосвязи.

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

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

При планировании используют разнообразные виды диаграмм. На рис. 7.1 представлены основные типы сетевых диаграмм: работы в узлах и работы в дугах.

Рис. 7.7. Сетевая диаграмма с работами в узлах и сетевая диаграмма.

с работами в дугах На диаграмме (рис. 7.2) возможны два пути от старта к финишу проекта: первый путь через вехи 1, 3, 4 или второй путь S₂ через вехи 2, 4. Длительность t пусть задана в днях. Соответствующая суммарная длительность работ (контрольные точки (вехи) не имеют самостоятельной длительности) составляет:

• • для пути S₁ = t₁ + t₃ + t₅ + t₆=l + 2 + l + 3 = 6 дней;
• • для пути S₂ = t₂ + t₄ + t₆ = 3 + 4 + 3 = 10 дней.

Следовательно, критическим является путь S2.

На диаграмме (рис. 7.1) с работами в узлах приведены следующие обозначения, несущие дополнительную информацию:

• • N — номер задачи или работы в проекте;
• • Т — время, необходимое для выполнения задачи;
• • ES (early start) — дата, раньше которой нельзя начать выполнение работы, учитывая сроки выполнения предшествующих задач;
• • EF (early finish) — дата, раньше которой нельзя завершить выполнение задачи, учитывая сроки выполнения предшествующих задач;

• • LS (late start) — дата, позднее которой нельзя приступить к выполнению задачи, учитывая сроки завершения проекта;
• • LF (late finish) — дата, позднее которой нельзя завершить задачу, учитывая сроки завершения проекта;
• • FL (floating days) — разница между датами ES и LS образуют резерв времени на работу для отдельной задачи.

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

Рис. 7.2. Сетевая диаграмма с работами в дугах для вычисления критического пути.

Для иллюстрации определений и их вычисления рассмотрим упрощенный проект «Разработка и внедрение автоматизированной системы „Домашний банк“». Для достижения цели проекта необходимо выполнить следующие задачи (табл. 7.1, рис. 7.3).

Таблица 7.1

Разработка и внедрение автоматизированной системы «Домашний банк».

Задачи 1, 2, 3 должны выполняться последовательно, хотя они и не конфликтуют по ресурсам (выполняются разными исполнителями). Разработка программного обеспечения возможна после разработки требований, а установка системы возможна только завершения разработки.

Рис. 7.3. Сетевая диаграмма с работами в узлах для проекта разработки и внедрения автоматизированной системы «Домашний банк».

Задача 4 не зависит от задач 1, 2, 3 ни по результатам, ни по исполнителям (будем считать, что предмет договора с клиентом не зависит от требований к системе и наоборот).

Ранний старт задачи 1 и задачи 4 совпадает и равен первому дню проекта (ES_г = ES₄ = 1).

Ранний финиш задачи 1 равен раннему старту плюс время исполнения задачи 1 (FFj = 1 + 30 = 31).

Ранний старт задачи 2 равен дню, следующему, за ранним финишем задачи 1 (ES₂ = EF_х + 1 = 32). Ранний финиш задачи 2 равен ее раннему старту плюс время исполнения (FF₂ = 32 -I- 40 = 72).

Ранний старт задачи 3 равен дню, следующему, за ранним финишем задачи 2 (FS₃ = FF₂ + 1 = 73). Ранний финиш задачи 3 равен ее раннему старту плюс время исполнения (FF₃ = 73 + 5 = 78).

Критическим является путь через работы 1, 2, 3 с общей длительностью 78 дней. Следовательно, планируемый срок проекта равен 78 дням.

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

Если за плановый срок проекта принимаем 78 дней (срок может быть задан внешними условиями), то поздним финишем задач 3 и 4 будет значение 78.

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

Для задач критического пути поздний старт и ранний старт равны, поздний финиш и ранний финиш, также, равны. Резерв задач критического пути равен 0.

Поздний старт задачи 4 равен разности между значением ее позднего финиша и времени исполнения (IS₄ = LF₄ — 30 = 78 — 30 = 48).

Резерв времени задачи 4 равен разности между ее поздним стартом и ее ранним стартом (FL₄ = LS₄ — FS₄ = 48 — 1 = 47).

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

Точно оценить время исполнения отдельных задач в реальных проектах бывает достаточно тяжело. Часто эта задача становится нереализуемой. Для учета вероятностного характера оценки длительности и ресурсоемкости работ рекомендуется производить планирование в два прохода (прямой и обратный) с определением для каждой работы резерва времени исполнения, а также вероятностной оценки длительности (англ, project evaluation and review technique, PERT).

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

Таблица 7.2

План работ проекта «Домашний банк».

На рис. 7.4 непрерывными горизонтальными полосами, вытянутыми по оси времени, обозначены выполняемые работы. Сверху буквами П, В, С, Ч, П, соответственно, обозначены рабочие дни недели.

Первичный вариант диаграммы Ганта не содержал информации о связях задач. В конце XX в. типовые диаграммы обогатили информацией о связи задач между собой. На рис. 7.5 представлены примеры таких связей. Связь задач в диаграмме позволяет автоматизированно управлять изменением сроков задач во всем плане проекта при корректировке отдельных (например, в MS Project). Если эти связи не установлены, то при изменении длительности одной задачи вы будете вынуждены корректировать и уточнять сроки всех задач в плане.

Рис. 7.4. Диаграмма Ганта для проекта разработки и внедрения автоматизированной системы «Домашний банк».

Рис. 7.5. Примеры связи задач.

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

Примером связи «старт — старт» может служить связь между задачами «тестирование» и «исправление замечаний». Исправление замечаний может начаться только после того, как стартовала работа по тестированию и начали появляться первые замечания к системе.

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

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