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

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

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

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

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

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

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

На рис. 14.7 изображена приблизительная модель, отражающая число изменений проекта; в очерченной области представлено предусмотренное планом пространство изменений, которые команда может выдержать без новой серьезной работы. Такая же диаграмма может быть составлена на микроуровне для каждой работы. В зависимости от подходов, примененных программистом, его план будет иметь различные уровни охвата изменений требований или замысла, относящихся к данной работе.

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

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

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

Используя имеющуюся информацию, старайтесь периодически выстраивать правильные предположения о возможных изменениях в направлении работ (Поддержка конкретной технологии? Новая характеристика? Новая цель?) и представлять, хотя бы в общих чертах, какие поправки потребуется внести для достижения цели. Эти представления могут быть весьма приблизительными, полученными, к примеру, в ходе разговора с ведущим программистом о том, что такие изменения моли бы повлечь за собой: «Фрэд, что нам нужно будет сделать для поддержки набора API версии 2.0 вдобавок к тем функциям, которые мы уже используем?» Ваша цель заключается не в составлении нового плана битвы, а в получении представления о том, как будет выглядеть дорога, по которой, возможно, придется идти вам и вашей команде. Еще раз просмотрите перечень работ (см. главу 13) и выясните, как в него впишется новая работа, которой, возможно, придется заняться.