Искусство управления IT-проектами - читать онлайн книгу. Автор: Скотт Беркун cтр.№ 120

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

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

Агрессивный. Целиком придерживайтесь одной стратегической линии, не вызывающей у вас сомнений, и навязывайте противнику свою игру.

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

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

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

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