Читать онлайн «Искусство управления IT-проектами». Страница 94

Глава 14. Стратегия миттельшпиля

Название главы позаимствовано из шахматной терминологии. Шахматная игра делится на три части: дебют, миттельшпиль и эндшпиль. В ходах, которые игроки делают в миттельшпиле, раскрывается их основная стратегия. Именно в этой части игры делается основная часть всех ходов. Игра завершается эндшпилем, когда ресурсы уже на исходе и каждый ход на счету. Эндшпиль проекта рассматривается в следующей главе, а данную главу, которая посвящена миттельшпилю, хочется начать цитатой Луи Пастера: «Открытия приходят лишь к тем, кто подготовлен к их пониманию».

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

В простейшем представлении миттельшпиль, как и эндшпиль, целиком относится к проектному сопровождению высокого уровня:[82]

4. Если к концу дня все в проекте идет хорошо, значит, ваша цель на следующей день – сохранение этой тенденции.

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

6. Повторяйте предыдущие действия, пока проект не будет завершен.

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

По этим и другим причинам в миттельшпиле и эндшпиле уровень прилагаемых усилий и испытываемых стрессов очень высок. Команда работает ускоренными темпами, и право на ошибку тает с каждым днем. А по мере приближения к последней стадии проекта кому-то нужно понять, что для благополучного завершения правильнее не просто «нажать на тормоза», а притормаживать постепенно.

В данной главе и далее я буду придерживаться тех же предположений о методах работы, которые использовались в главе 2, поэтому перед тем, как двигаться дальше, имеет смысл еще раз просмотреть раздел «Решающие факторы и методологии» в главе 2.

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

ПРИМЕЧАНИЕ

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

Управление большими и весьма опасными объектами требует не только твердой руки. Чем больше управляемый объект и чем больше в нем людей, тем сильнее его инерционность. Новички, как в руководстве проектами, так и в управлении тяжелыми машинами (грузовиками, аэробусами, авианосцами и т. д.), недооценивают время реакции объекта на изменение положений органов управления. На рис. 14.1 показана траектория автомобиля или проекта, заметно изменяющаяся в зависимости от количества вовлеченной в процесс кинетической энергии и других сил. Многим людям не удается правильно выстроить свои предположения относительно последствий собственных действий. Причина часто кроется в том, что они не понимают, какие силы оказывают влияние на динамику тех объектов, с которыми им приходится иметь дело. Они напоминают ученика автошколы, впервые попавшего в занос на снежной дороге из-за того, что слишком много непонятных сил помешало ему справиться с управлением.

Рис. 14.1. Одни и те же действия могут привести к различным результатам в зависимости от инерционности проекта

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

Рис. 14.2. К ужасу тех, кто обязан контролировать ситуацию, корректирующие действия в ответ на влияние неизвестных сил могут иметь непредсказуемые (и зачастую неприятные) последствия

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

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

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

Если вы захотите бежать впереди паровоза, то вам следует постоянно проверять состоятельность ожидаемых вами условий. Как только вы обнаружите какую-нибудь фальшь, то сразу поймете, на что следует обратить внимание.