Независимо от уровня вашего опыта, подготовленности или интеллекта, настанут дни, когда вы перестанете болтаться позади проекта. Научитесь отличать навалившуюся на вас рутину от бега вслед за уходящим составом – это не одно и то же. Есть вполне реальные шансы на то, что ощущение нехватки времени на выполнение существующего объема работ будет вашим частым спутником. Но если вы подготовили списки приоритетов (см. главу 13), то всегда будете знать, какая работа ожидает своего (то есть вашего) часа. Но если вы не успеваете и плететесь в хвосте проекта, вас неизменно охватит чувство безысходности, подавленности и даже апатии. Вы уверуете в то, что никакая сверхурочная работа не сможет вернуть вам контроль над проектом.
И, напоследок, еще три важных замечания:
1. Вы должны осознать тот факт, что плететесь в хвосте. Следует помнить, что рабочие графики носят вероятностный характер. Какова ваша уверенность в том, что с недельным объемом работы удастся справиться своевременно? 80 %? 50 %? Если шансы на то, что вы справитесь, составляют пятьдесят на пятьдесят (или хуже), значит, вы плететесь в хвосте, у вас слишком мал предел возможных ошибок и вы их обязательно наделаете, если уже не наделали.
2. Если вы видите, что в хвосте плетется кто-то другой, предложите свою помощь. Не стоит делать вид, что проблемы не существует: признайтесь в том, что она для вас очевидна, и попытайтесь оказать помощь. Не позволяйте тем, кто находится в сфере вашего влияния, колебаться или паниковать. Сохраняйте спокойствие, помогайте сохранять его другим и совместно работайте над тем, чтобы снова оказаться впереди.
3. Не стесняйтесь принимать помощь коллег или кураторов. Возможно, сторонняя помощь будет единственным средством снова обогнать паровоз. Пусть вам помогут разобраться с распределением вашего рабочего времени и определить, на что лучше потратить время команды, пусть заберут часть вашей работы или просто послушают, как вы будете «выпускать пар». Примите протянутую руку. Если вам ее не предложили, то попросите людей о помощи.
Чтобы больше узнать о том, как справиться с кризисной ситуацией, обратитесь к главе 11.
В миттельшпиле деятельность теряет свою масштабность, все самое трудное руководитель проекта уже сделал в период планирования или проектирования. Если какое-нибудь требование было упущено и его нужно включить в проект, то процесс его определения и документирования является повторением действий, предпринятых в период подготовки всего набора требований (осознать потребности, рассмотреть все «за» и «против», сформулировать требование и определить его приоритет). А если что-то было упущено в технических условиях, то решение этой проблемы представляет собой двойное или тройное повторение процесса выработки технических условий. В миттельшпиле применяется и ряд новых приемов, которые обычно являются упрощенными и приблизительными версиями уже применявшихся приемов. Проблема в том, что ускоренная работа порождает риск. В миттельшпиле осмотрительность (стремление максимально обезопасить свои действия) означает, что в результате предпринимаемых действий не должна быть случайно нарушена целостность проекта.
Из-за того что в миттельшпиле возникают различные обстоятельства, способные привести проект к краху, безопасность действий дается нелегко. Все находится в движении, многие решения уже приняты и вполне могут вступить в противоречие с любыми новыми действиями. Например, если при строительстве дома вы в самой середине процесса решили изменить план крыши со стандартного треугольного на куполообразный, вам придется пожертвовать затраченными на строительство материалами и усилиями и возможно приступить к новой работе под более высоким давлением. Чтобы научиться вносить изменения в требования, урезать функциональность или модифицировать замысел, оказывая существенное влияние как на ядро уже созданного программного кода, так и на команду разработчиков, требуется немалый опыт.
Осмотрительность должна стать целью любого руководителя проекта. Он должен действовать и вести себя так, чтобы с минимально возможным ущербом удерживать направление проекта в условиях изменяющихся целей. Обойтись вообще без ущерба невозможно, поэтому к нему следует быть готовым. Но чем эффективнее действия руководителя, тем слабее будет негативное воздействие на проект.
На рис. 14.3 показано, что чем дальше продвигается реализация проекта, тем труднее становится действовать осмотрительно. Причина кроется в том, что со временем вероятность удорожания последствий изменений возрастает: повышаются шансы на то, что уже готовые компоненты придется либо модифицировать, либо просто выбросить. Эти затраты неизбежны, но осмотрительность означает, что накануне принятия решения должно сложиться представлением о том, во что оно может вылиться.
Рис. 14.3. Проявить осмотрительность при внесении корректировок тем труднее, чем они масштабнее и(или) чем позже они предпринимаются
При рассмотрении корректировок в период миттельшпиля (при внесении изменений в характеристики, цели или требования) нужно ответить на следующие пять вопросов:
1. Какую проблему мы пытаемся решить? Нужно ли ее решать для успешного продвижения проекта? Нужно ли решать эту проблему именно на данном этапе работы? Нельзя ли мириться с ней и дальше?
2. Что представляет собой эта проблема, чем она является, симптомами или болезнью? Может быть, можно ограничиться устранением симптомов?
3. Достаточно ли имеющегося представления о состоянии программного кода или команды разработчиков, чтобы предсказать, как на них скажется корректировка?
4. Стоят ли затраты на корректировку (включая время на оценку состояния кода и команды, на рассмотрение альтернативных вариантов, на обеспечение политической поддержки решения) получаемой от нее выгоды? Поиск болезни и выработка решений по ее лечению может обойтись значительно дороже, чем мирное сосуществование с болезнью при условии минимизации внешних проявлений ее симптомов.
5. Может ли риск возникновения новых потенциальных проблем свести «на нет» весь выигрыш от вносимых изменений?
Решение о том, стоит ли предпринимать какие-либо действия, принимается в соответствии с той же стратегией принятия решений, которая была рассмотрена в главе 8. Любые действия, касающиеся проектирования, технических условий, общения или политики, требуют применения тактики, рассмотренной соответственно в главах 6, 7, 9 и 16. Подходы и позиции те же, а отпущенное время и право на ошибку значительно меньше. Дефицит времени на обдумывание возможных вариантов вынуждает поступать особым образом. Во-первых, нужно полагаться на данные, полученные ранее при изучении прототипов и конструкторских проработок. Часть рассматриваемых наработок берется именно оттуда, а имеющиеся у команды знания помогают провести анализ текущей обстановки. Во-вторых, нужно проявлять консерватизм. Чем меньше вы знаете, тем больше рисков остаются незамеченными. Чем дальше продвинулся ваш проект, тем выше должна быть планка предпринимаемых действий.
Неотъемлемым атрибутом осмотрительности является учет обязательств, которые руководитель проекта имеет перед командой. В главе 12 мы уже говорили, что доверие к руководителю со стороны команды определяется его способностью придерживаться своих обязательств. Формами обязательств между руководством, руководителями команд, программистами и заказчиками являются концептуальные документы, требования и календарный план. Любые предпринятые вами в миттельшпиле действия могут нарушить ранее взятые обязательства.
Чтобы сохранить доверие команды при внесения каких-нибудь изменений, вы должны уважительно относиться ко всем предыдущим обязательствам. Вот что по этому поводу говорит Уоттс С. Хэмфри (Watts S. Humphrey): «Если изменяется что-нибудь, влияющее на обязательства обеих сторон, об этом дается предварительное уведомление, и стороны договариваются о новых обязательствах[83]». Вносить изменения никто не запрещает, но они должны следовать за переговорным процессом, аналогичном тому, в котором создавался первый пакет обязательств (концепция, требования, календарный план). При этом не следует готовить проекты документов или собирать расширенные совещания, но поставить людей в известность об изменении обязательств и привлечь их к процессу принятия решения о характере предстоящих изменений нужно обязательно.
Если вы просите команду выбросить результаты двухнедельного труда, нужно быть уверенным, что цена этого шага учтена в принятом решении. Нужно объяснить команде все причины, по которым вносимые изменения считаются правильными, и раскрыть факторы, подкрепляющие это убеждение. Пригласите, по возможности, кого-нибудь из команды поучаствовать в обсуждении, проводимом перед принятием окончательного решения.
