Скотт Беркун - Искусство управления IT-проектами

5. Может ли риск возникновения новых потенциальных проблем свести «на нет» весь выигрыш от вносимых изменений?

Решение о том, стоит ли предпринимать какие-либо действия, принимается в соответствии с той же стратегией принятия решений, которая была рассмотрена в главе 8. Любые действия, касающиеся проектирования, технических условий, общения или политики, требуют применения тактики, рассмотренной соответственно в главах 6, 7, 9 и 16. Подходы и позиции те же, а отпущенное время и право на ошибку значительно меньше. Дефицит времени на обдумывание возможных вариантов вынуждает поступать особым образом. Во-первых, нужно полагаться на данные, полученные ранее при изучении прототипов и конструкторских проработок. Часть рассматриваемых наработок берется именно оттуда, а имеющиеся у команды знания помогают провести анализ текущей обстановки. Во-вторых, нужно проявлять консерватизм. Чем меньше вы знаете, тем больше рисков остаются незамеченными. Чем дальше продвинулся ваш проект, тем выше должна быть планка предпринимаемых действий.

Неотъемлемым атрибутом осмотрительности является учет обязательств, которые руководитель проекта имеет перед командой. В главе 12 мы уже говорили, что доверие к руководителю со стороны команды определяется его способностью придерживаться своих обязательств. Формами обязательств между руководством, руководителями команд, программистами и заказчиками являются концептуальные документы, требования и календарный план. Любые предпринятые вами в миттельшпиле действия могут нарушить ранее взятые обязательства.

Чтобы сохранить доверие команды при внесения каких-нибудь изменений, вы должны уважительно относиться ко всем предыдущим обязательствам. Вот что по этому поводу говорит Уоттс С. Хэмфри (Watts S. Humphrey): «Если изменяется что-нибудь, влияющее на обязательства обеих сторон, об этом дается предварительное уведомление, и стороны договариваются о новых обязательствах [83]». Вносить изменения никто не запрещает, но они должны следовать за переговорным процессом, аналогичном тому, в котором создавался первый пакет обязательств (концепция, требования, календарный план). При этом не следует готовить проекты документов или собирать расширенные совещания, но поставить людей в известность об изменении обязательств и привлечь их к процессу принятия решения о характере предстоящих изменений нужно обязательно.

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

Не бойтесь вносить изменения. Перемены ведут к улучшению, и они неизбежны. Однако существует множество различных вариантов изменений и много различных способов для руководителя по их внедрению в работу команды. Если раньше проект шел на запад, а теперь вдруг понадобилось, чтобы он пошел на север, для поворота команды на север от вас потребуются те же навыки, которые применялись для того, чтобы заставить команду двигаться на запад (хотя придется вдвое увеличить скорость и наполовину избавиться от формализма). Вернитесь к главам 3, 4, 11 и 12 и почитайте изложенные в них инструкции по руководству в условиях перемен.

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

Следить за слаженным функционированием конвейера входит в обязанность руководителя проекта. Программисты и сами могут управлять работой конвейера, решая, кто чем должен заниматься, [85]но руководитель проекта все равно будет отвечать за то, чтобы команда программистов в процессе выполнения работ получала всю необходимую поддержку. Он может отслеживать ход процесса, проводить совещания, надоедать всем своими требованиями о выполнении принятых решений или в отдельных случаях заниматься устранением оставшихся проблем, касающихся замысла проекта [86](рис. 14.4). Руководителю проекта, вероятно, придется действовать, опережая на несколько дней программиста, завершая подготовку замысла и «подпитывая» производственный конвейер. Если руководитель проекта отвечает за нескольких разработчиков, ему понадобится тщательнее распределять свое рабочее время, чтобы успеть справляться с запросами нескольких конвейеров (вот почему ведущий программист должен хотя бы часть этих функций взять на себя).