Наука побеждать

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

Это -- базовые определения из широко известного руководства по основам знаний в управлении проектами (A Guide to the Project Management Body of Knowledge -- PMBOK), выпускаемого Project Management Institute.

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

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


Основа основ

Машина должна работать, человек -- думать.Принцип корпорации IBM

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


Схема организации работ и диаграмма Гантта

Разработка любого проекта начинается с составления списка работ или, говоря языком менеджеров, построения иерархической структуры его компонентов (Work Breakdown Structure -- WBS) в виде блок-схемы или таблицы. Основной проблемой при этом является верная детализация. Если она будет излишне подробной, это приведет к необходимости управления проектом на микроуровне, что займет много времени. Если задачи слишком масштабные, с ними будет трудно эффективно справляться. Как правило, нормальной считается детализация работ на уровне нескольких дней.

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

Сила диаграммы Гантта -- в ее способности наглядно отобразить состояние каждого вида деятельности сразу. Это, в первую очередь, -- средство представления отчетов. Для управления ходом проекта используются более мощные средства, описанные ниже, -- CPM, PERT и некоторые другие.


CPM -- Critical Path Method

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

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

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

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

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

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

Эта методика была разработана для сложных, но довольно понятных проектов. Однако существуют проекты с высокой неопределенностью сроков выполнения, где метод срабатывает не слишком хорошо. Альтернативой является планирование проектов по методике PERT, которая позволяет для каждого действия определить диапазон продолжительности.


PERT

Program Evaluation and Review Technique, или PERT -- сетевая модель, позволяющая учесть неопределенность длительности каждого действия. Методику разработали примерно в то же время, что и CPM (в конце 1950-х годов) для крупного военного проекта США с тысячами подрядчиков. В ней принята нумерация событий, причем каждое последующее по времени имеет больший номер. Обычно шаг номеров -- 10, чтобы можно было вставить дополнительные события (как нумерация строк в ранних версиях Basic). Действия помечаются буквами, а рядом указывается их предполагаемая продолжительность (рис. 2).

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

Ожидаемое время продолжительности каждого действия может быть приблизительно оценено как (О + 4В + П) / 6. Это расчетное время и указывается на сетевом графике.

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

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


Соотношение "время -- затраты"

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

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

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

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

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

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


Люди и риски

Любая система, зависящая от человеческой надежности, ненадежна.
Второй закон ненадежности Джилба

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


Project Risk Management

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

Можно выделить две стадии процесса PRM -- оценка риска (Risk Assessment) и управление риском (Risk Control).

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

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

В бизнесе принципы PRM всегда используются при планировании любых перемен. Обычно они связаны с изменением объемов продаж, денежных потоков, производства или ассортимента продукции. Замечено, что если за ходом таких проектов не следить специально, бизнес часто самопроизвольно возвращается к прежнему, более привычному состоянию.


Проблемы человеческие

Лучшие менеджеры проектов уже уяснили для себя -- что бы ни говорили о качествах руководителя, все сводится к одному -- лидерству. Еще ни один проект не провалился из-за недостатков диаграммы Гантта или слабого средства построения расписания. Многочисленные курсы и учебники посвящены тому, как управлять проектом. Но очень мало говорится о лидерстве, которое в руководстве проектами подразумевает работу с конечным клиентом, распределение ресурсов, вдохновление команды проекта, а также грамотное использование привлеченных средств. Это дает возможность сформулировать следующий постулат: в течение хода проекта его руководитель фактически выполняет функции СЕО и, очевидно, должен обладать его качествами.

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

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

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

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

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


Проект закончен. Всем спасибо?

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

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

Инструментальные средства и методы руководства проектом. Какие средства и как использовались? Насколько удобными они были для выполнения именно этого проекта? Потребовалось ли обучение членов команды и какие встречались сложности?

Организация и структура. Какие группы и отделы в основном осуществляли проект? Как назначались и выполнялись задачи? Как распределялись ресурсы? Какие понадобились изменения структуры в ходе проекта?

Качество результатов проекта. Некоторые или даже многие работы в ходе проекта могут быть нестандартны. Они должны всесторонне рассматриваться -- с точек зрения конечного пользователя, методов, инструментальных средств, МП, администрации и т. д. Вовремя ли и в пределах ли установленного бюджета выполнен проект? Каков был уровень расходов? Какую сумму составили незапланированные расходы?

Методы разрешения конфликтов. Были ли конфликты в любой области? Каковы причины их возникновения? Что сделано для разрешения проблемы?

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


Творчество по струнке

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

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


CMM и CASE

CASE-технологии (Computer-Aided Software/System Engineering) определяются как совокупность методологий анализа, проектирования, разработки и сопровождения сложного ПО. Их основное назначение -- отделить проектирование ПО от его кодирования и последующих этапов внедрения. Это весьма специфический случай применения методов управления проектами, и разработчики ПО часто сталкиваются с серьезными проблемами при попытках внедрить CASE в своих компаниях.

Одним из подходов, который в значительной степени позволяет преодолеть трудности, является использование сравнительно новых концепций "модели зрелости потенциальных возможностей" (Capability Maturity Model -- CMM). CMM была разработана в Software Engineering Institute в конце 80-х годов как практическая методика и заставила разработчиков ПО и системных аналитиков по-новому взглянуть на программные проекты.

Основная идея заключается в том, что CASE не должен использоваться до тех пор, пока не будет достигнут определенный уровень зрелости организации. В этом отношении CMM может рассматриваться как своеобразная структура, перечень вопросов и методология действий для внедрения CASE, основанная на предпосылке, что идеальный процесс разработки ПО должен быть предсказуемым. Согласно одному из идеологов CMM, Уотсу Хэмфри (Watts S. Humphrey), организациям необходимо сделать следующие пять шагов, чтобы улучшить процесс разработки ПО:

1. Понять текущее состояние их процессов разработки.

2. Разработать видение того, как должно быть.

3. Составить список действий по совершенствованию в порядке приоритета.

4. Разработать план выполнения этих действий.

5. Обеспечить ресурсы для реализации этого плана.

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

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

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

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

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

Оптимизационный уровень. Организация имеет основу для длительного совершенствования и оптимизации процесса.

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

Использование CASE на уровне 1 дает небольшой эффект -- автоматизация плохо определенного процесса неизбежно дает плохо определенные результаты. На уровне 2 (типовых моделей) начинается использование инструментальных средств руководства проектом. На уровне 3 CASE может применяться для моделирования, а на 4--5 основная польза от него заключается в том, что с его помощью обеспечивают необходимые количественные показатели проектов.

Разумеется, введение CASE не должно являться самоцелью. Это не более чем одно из возможных средств в усовершенствовании процессов. Точно также и CMM -- не очередная панацея. Она имеет и слабые стороны, главная из которых заключается в односторонних отношениях (отсутствии обратной связи) между зрелостью процессов разработки и использованием CASE (в данном случае) или других методов разработки. Иными словами, нельзя исключить вариант, когда внедрение CASE в какой-то степени повлияет на формирование более высокого уровня зрелости по CMM.


Заключение

Пять "китов" прошлого века -- иерархическая структура компонентов проекта, диаграмма Гантта, методы определения критического пути CPM и PERT, а также соотношение "время--затраты" -- основа, на которой строится большинство современных проектов. Оценка рисков позволяет существенно повысить вероятность успешного и своевременного окончания работ. Роль лидера команды -- менеджера проекта -- трудно переоценить, и вовсе не тривиальной задачей является поиск подходящей кандидатуры, способной возглавить большой проект.

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

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