Контроль над продвижением проекта

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

Чтобы преуспеть в этой деятельности, менеджер проекта дол­жен уметь отличать реальный прогресс от «кажущегося» прогрес­са. Многие менеджеры проектов давно усвоили, что синдром «выполнено на 90%» является опасной иллюзией, и они знают, что в безнадежном проекте не менее опасно утверждать «мы выполнили анализ и проектирование на 100%, но еще не закончили написание кода и не тестировали его». Практичной и эффектив­ной альтернативой это дилемме является принцип «ежедневной сборки» («daily build»).

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

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

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

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

В то время как вряд ли кто-нибудь вправе претендовать на «изобретение» данного подхода, известно, что он впервые стал популярным во время разработки операционной системы Windows NT. Можно также отметить, что при разработке Windows 95 использовался принцип «ежедневной сборки»; заключитель­ная бета-версия перед выпуском конечного продукта была реали­зована в августе 1995 г. и называлась «Проект 951».

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

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

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

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

Оценка риска выполняется обычно путем оценок сложности разрабатываемой системы или продукта, а также клиентской сре­ды и среды проектной команды. Сложность продукта можно оце­нить в терминах объема (например, количества функциональных точек), ограничений производительности, технической сложнос­ти и т.д. Риск, связанный с клиентской средой, определяется в ос­новном такими факторами, как число пользователей, вовлечен­ных в проект, их уровень квалификации, значение разработки для пользовательского бизнеса, вероятность того, что внедрение новой системы (если оно произойдет) приведет к реорганизации, и т.д. Наконец, риск, связанный со средой проектной команды, зависит от ее способностей, опыта, морального состояния и фи­зического/эмоционального здоровья.

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

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

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

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

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

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

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

7.9.