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

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

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

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

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

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

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

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

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

3. Запрос на изменение замысла выносится на рассмотрение небольшой группы руководителей команд (см. главу 15) или руководителя группы, который дает или не дает «добро» на изменение. Если изменение принимается, то оно рассматривается как дополнительная работа, запрос доводится до команды (а сама работа поручается соответствующему программисту). Рабочие графики и другая проектная документация должны быть обновлены с учетом произведенного изменения. Если изменение отклоняется, то запрос без сожаления выбрасывается в ближайшую урну и навсегда исчезает из проекта.

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

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

Оглавление книги