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

Известная шутка: на второй день работы над проектом программисты заявляют, что они сделали 90%, и эти 90% остаются до последнего дня перед сдачей проекта, после чего программисты обнаруживают, что для доделки оставшихся 10% требуется еще 6 месяцев. Как избежать этой ловушки? Правильным контролем за ходом проекта.

Удивительно, но многие компании в качестве критерия объема проделанных работ используют процент от выделенных на проект средств! Более корректные единицы измерения (например, число строк кода) тоже подходят далеко не всегда. Можно написать миллиарды строк кода, и при этом проект останется недоделанным.

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

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

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

Дополнение корпорации Cutter.

Как оценивается объем будущего проекта? Нередко это напоминает игру в числа.

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

Но в результате проект заканчивается неудачей.