Искусство управления IT-проектами - [17]

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

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

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

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

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

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

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

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

Рис. 2.1. Простейшая схема календарного плана, созданного по правилу трех частей

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