Искусство управления IT-проектами | страница 32



Навязчивая идея применения методологий на рабочем месте – еще один пример высокотехнологичной иллюзии. Она берет начало из веры в то, что технология – это единственное, что на самом деле имеет значение… Какими бы ни были технологические преимущества, они могут быть получены только за счет существенного ухудшения социального климата в команде разработчиков.

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

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

На что похож календарный план

Существует одно основное правило составления всех календарных планов – так называемое «правило трех частей». При всей его приблизительности и упрощенности оно предлагает самый простой подход к пониманию сути календарных планов. Если у вас уже есть опыт составления календарных планов, то немного потерпите, поскольку я представлю весь процесс в слишком упрощенном виде. Это делается, чтобы заложить элементарную основу для объяснения, что может не получиться, почему это может произойти и как с этим справиться.

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