Управление проектами: статьи

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

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

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

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

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

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

Управление рисками

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

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

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

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