Лекции по управлению программными проектами
Негативные последствия «агрессивного» расписания
В программостроении уже стало банальностью то, что разработчики без достаточного основания называют слишком оптимистичные сроки. Среди руководителей даже распространено неписаное правило: умножать на 2 оценку трудоемкости, которую сделал программист. Это пессимистичный подход. Реалисты умножают на π = 3.14 .
Действительно, так иногда приходится поступать, если это программист, который только вчера отладил свою первую программу «Hello world!». Но если помочь молодым специалистам научится анализировать задачу, проектировать решение, составлять план работы, эффективно его реализовывать и анализировать полученные результаты, то можно будет не вспоминать, чему равно число π.
Еще один распространенный источник занижения сроков — необоснованные ожидания на применение новых технологий и средств разработки. Эти ожидания, как правило, не оправдываются. Согласно статистике, приведенной Демарко, средняя производительность в программном производстве растет всего лишь на 3–5% в год.
Часто «агрессивное» расписание проекта появляется из-за того, что руководство и/или заказчик боятся переоценить проект, полагая, что согласно закону Паркинсона, работы по проекту займут все отведенное для него время. Следствием подобных опасений является, как правило, директивное занижение сроков реализации проекта.
Нереалистичность оценок — один из серьезнейших демотивирующих факторов для участников. Недооценка приводит к ошибкам планирования и неэффективному взаимодействию. Например, было запланировано тестирование, а релиз еще не готов. Следствие — простой тестировщиков увеличение трудозатрат.
Если расписание излишне агрессивное, то с целью сэкономить время, недостаточно внимания уделяется анализу требований и проектированию. Исправление ошибок, допущенных на этих этапах, приведет к существенным дополнительным затратам.
Половина всех ошибок программирования возникают из-за стресса, вызванного излишним давлением фактора сроков. Ошибки исправляются наспех, обходными путями. В результате будет получен большой проблемный код и постоянно растущие затраты на исправление ошибок и внесение изменений. Позднее обнаружение ошибок приводит к тому, что затраты на их исправление увеличиваются в 50–100 раз.
Мне пришлось наблюдать проект, который вместо первоначально слишком оптимистично запланированных шести месяцев растянулся на три года. Хотя, если бы он был адекватно оценен, то он мог бы быть реализован за один год. Нереальные сроки, постоянное давление, сверхурочные, авралы приводят к тому, что затраты на проект растут экспоненциально и неограниченно.
Если участники проектной команды адекватно мотивированы на выполнение проектных работ с наименьшими затратами, то, на мой взгляд, этого достаточно, чтобы проект был реализован в минимально возможные сроки. О мотивации мы еще будем говорить (см. ).
