Письмо 05 - Сложность управления проектом

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

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

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

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