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

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

Рис. 14.8.

Если вы знаете о предстоящих изменениях, но не знаете, когда они наступят, вы можете наметить курс в соответствии со своими предположениями о том, какими они будут

В ходе реализации проекта эти таинственные изменения по-прежнему остаются на уровне слухов. По мере продвижения проекта к точке Б сложность реализации возможных изменений растет. С каждой новой строкой программного кода остается все меньше возможностей для поддержки возможного альтернативного направления. Чем ближе подбирается проект к финальной точке Б

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

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

Контроль изменений

Некоторые команды активно контролируют и отслеживают любые изменения замысла, в результате которых появляются новые или исчезают имевшиеся работы. Такие команды начинают контролировать ситуацию, как только технические условия проходят формальное обсуждение. Они опасаются, что если изменения будут вноситься в замысел без проведения соответствующих процедур, то может получиться, что какие-нибудь существенные и совершенно неудачные, а может быть даже вредные решения окажутся принятыми без ведома компетентных специалистов. В зависимости от сложившейся культуры и целей вашей команды вы можете вводить, а можете и не вводить практику контроля изменений. Как отмечал Фридлейн (Friedlein): «Метод управления изменениями в проекте зависит от… масштабов и сути проекта. Как правило, чем проект крупнее и сложнее и чем жестче заданы технические условия, тем тверже нужно управлять изменениями[87]». Если ваша команда не уделяла достаточного внимания процессу выработки технических условий, то она, скорее всего, не станет противиться и изменениям, ей просто нечем будет возразить.

Тем не менее даже для команды, участвующей в ряде формальных процессов, изменения становятся тем чувствительнее, чем ближе проект к завершению. Без организации процесса, направленного на поддержание связей, отслеживание и контроль изменений, беспрепятственно закрыть проект будет очень непросто. Чем опытнее команда, тем раньше она позаботится о контроле изменений. Этот процесс не обязательно должен иметь отношение к периоду эндшпиля: по мере приближения к нему риски, равно как и желание справиться с ними, возрастают.

Простейший путь управления изменениями представляет собой значительно упрощенную версию процесса выработки технических условий. NASA и Microsoft называют его запросом на изменение замысла (Design Change Request, DCR). Другие распространенные названия: запрос на изменение разработки (Engineering Change Request, ECR), заказ на изменение разработки (Engineering Change Order, ECO) или просто запрос на изменение (Change Request, CR).

В упрощенном виде все происходит следующим образом:

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

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