Сергей Бобровский,
Планета КИС

Cтатья была опубликована на сайте PC Week/RE 00/07

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

Есть такая замечательная методика — Cost/ Schedule Control Systems Criteria (C/SCSC), разработанная в середине 60-х годов МО США для контроля за ходом выполнения работ компаниями-подрядчиками (в некомпьютерных областях). Она позволяет простыми способами отслеживать этот процесс и первоначально основывалась на 35 критериях. В дальнейшем C/SCSC несколько раз улучшалась, на ее основе был создан ряд новых методологий, однако она не теряет актуальности и сегодня, особенно с ростом интереса к подобным разработкам со стороны софтверных компаний.

В самом упрощенном (но все равно полезном) виде с помощью C/SCSC можно контролировать ход выполнения проекта по двум наиболее важным критериям — срокам и бюджету. Центр логистики ВВС США в Оклахоме (первая государственная организация США, сертифицированная в 1996 г. по четвертому уровню CMM), насчитывающий 600 сотрудников, использует эту методику с 1985 г., и за 15 лет ни в одном из множества своих проектов не превысил сроки и бюджет. А среди его проектов — такие, например, как создание системы управления оружием для бомбардировщиков B-1 и B-2.

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

Ход выполнения проекта отслеживается на графике с нормализованными осями "сроки — бюджет".

(C/SCSC рекомендует применять несколько критериев оценки. Центр логистики начинал с четырех критериев, это были, в частности, различные индексы производительности. Сегодня он использует 10 критериев, планируя увеличить их число до 64.)

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

Допустим, в некоторый момент времени (сегодня) проверяется выполненный объем работ (пропорциональный освоенному бюджету или трудозатратам). Соответствующая точка отмечается на линии "сегодня" и через нее проводится прямая 2. Это значение несколько ниже запланированного (точки пересечения линии "сегодня" с прямой 1), что говорит о замедлении темпа работ. Место пересечения прямой 2 с линией, определяющей бюджет проекта (верхняя граница зеленого прямоугольника), обозначит момент завершения проекта. По его отклонению от планируемой величины получим прогнозируемую задержку срока.

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

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

Вычисляемые на основе показателей "сроки/бюджет" различные индексы в соответствии с C/SCSC могут находиться в зеленой (нормальной), желтой (опасной) и красной (критической) зонах. В нашем случае показателей два. Если только один из них расположен в зеленой зоне, то проект еще можно закончить в сроки и уложиться в бюджет; когда показатели находятся в желтой и красной зонах, проект, скорее всего, постигнет неудача. Оба показателя в красной зоне — провал проекту гарантирован.

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

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

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

В Интернете имеется немало материалов, посвященных C/SCSC. Можно порекомендовать, например, сайт www.baz.com/kjordan/ swse625/htm/tp-py.htm.

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

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

Национальный разведывательный отдел ЦРУ (National Reconnaissance Office) в сотрудничестве с институтом программной инженерии SEI (автором методологии CMM) решил повысить качество ведения проектов, связанных с созданием распределенных систем контроля и управления для МО США, насчитывающих миллионы строк кода на Си++ и работающих на сотнях серверов. Была проведена масштабная работа по анализу и выявлению наиболее важных и часто встречающихся рисков по 77 критериям. Вот их краткий список (в порядке убывания важности):

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

По результатам анализа SEI выработал ряд рекомендаций. Для эффективной борьбы с рисками надо:

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

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

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

Сплошная линия: "Заказчик задержит оплату (комм. директор Будкин)". Линия с короткими пунктирами: "Возможно появление ошибок в системе из-за плохой организации процесса тестирования (рук. проекта Дубкин)". Линия с длинными пунктирами: "Неустраненная ошибка в модуле А приведет к проблемам в работе модулей Б и В (программист Пупкин)".

Подобные графики желательно сделать разных типов — наглядные формы визуального информирования дают более полное представление о структуре рисков и быстрее помогают находить способы их устранения.

Мы рассмотрели две самые важные области стратегического управления проектами — управление ходом выполнения проекта и риск-менеджмент. Теперь представим ситуацию из жизни: начинающий руководитель проекта, начитавшись статей некоего Симеона Бобрикова в международном издании кондитеров "Пищевик", в котором почему-то стали появляться публикации на тему управления проектами, находит материалы по CMM и C/SCSC, прилежно изучает их, рисует замечательный график "сроки — бюджет", приходит к начальнику, и тот говорит: "Да, прекрасный план, все отлично, только... Срок должен быть не 12 месяцев, а 8, и расходы — не 50 тыс. долл., а 25". С этого момента начинается всем нам знакомое реальное управление проектами. Как поступать в таких ситуациях?

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

Об этом мы поговорим в следующий раз.