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

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

Существует множество различных систем планирования и управления, ориентированных на разработку программного обеспечения. Эти системы часто называют методологиями, то есть наборами методов, направленных на достижение конечного результата в конкретной области. Среди основных методологий разработки программных продуктов можно отметить водопадную и спиральную модели, ускоренную разработку приложений, экстремальное программирование и функционально-ориентированную разработку.[8]Все эти методологии призваны решать сходные проблемы организации и управления проектами. У каждой из них есть свои сильные и слабые стороны, и чтобы решить, какая именно методология подходит для тех или иных проектов, нужно обладать достаточными знаниями и опытом.

Однако целью главы, да и всей книги, не является сравнение различных методологий. Я полагаю, что есть концепции, положенные в их основу, и именно ими нужно овладеть, дабы добиться успеха при использовании любой методологии. Во всех случаях методологии нуждаются в корректировке и адаптации под особенности команды и проекта, а такая адаптация возможна только при наличии базовых знаний, более глубоких, чем знание самих методологий. Итак, если вы сможете воспринять и применить основополагающие идеи, рассматриваемые в данной главе и во всей остальной книге, то независимо от применяемой методологии ваши шансы на успех возрастут. Я намерен объяснить аспекты некоторых методов, по мере необходимости прояснения некоторых вопросов, но если вы коллекционируете информацию о методологиях, лучше обратиться к другим источникам.[9]

При всей своей важности для разработки программных средств методы не являются решающими факторами. Нет ничего хуже, чем слепо следовать наборам абсолютно несостоятельных правил только потому, что они изложены в популярных книгах или проповедуются многоуважаемыми гуру. Очень часто я убеждаюсь, что одержимость процессом – весьма тревожный знак, свидетельствующий о затруднениях в руководстве: это может быть попыткой переложить обычные проблемы и ответственность, с которыми сталкиваются руководители, на систему процедур и бюрократических приемов, подменяющих необходимость осмысленных руководящих действий. Возможно, намного более пагубным для команды разработчиков может стать пристрастие к методологии, которой в организации отводится чуть ли не первостепенная роль. Том Демарко (Tom DeMarco) в своей книге «PeopleWare» (Dorset House, 1999) («Человеческий фактор в программировании») отмечал:

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

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

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

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

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