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

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

На рис. 14.6 показан простой пример внесения изменений, связанных с корректировкой маршрута в направлении смещающейся цели. Проект стартовал в точке А и закончится, предположительно, в точке Б

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

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

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

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

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

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

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

Тайные механизмы управления