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

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

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

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

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

• Миттельшпиль и эндшпиль соответствуют середине и завершению проекта.

• Если однажды работа над проектом не заладится, то определение причин случившегося и их устранение всецело ложится на вас. Повторяйте эту мысль на всем протяжении миттельшпиля.

• Проект представляет собой сложную нелинейную систему и обладает значительной инерционностью. Если выжидать обострения проблем перед тем, как предпринять какие-то меры, можно опоздать и тем самым значительно ухудшить ситуацию.

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

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

• Производственный конвейер по разработке программного кода представляет собой механизм управления работами в ходе реализации проекта. Существуют агрессивные и консервативные методы управления конвейером.

• Планирование отдельных этапов и применение конвейера по разработке программного кода предоставляют возможности для безопасной коррекции курса проекта.

• Механизм контроля изменений (с использованием запросов на изменение замысла) позволяет регулировать внесение в проект изменений среднего и низкого уровня.

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

2. Руководители проектов часто вынуждены бежать позади своего паровоза, поскольку не в состоянии контролировать график работ, бюджет или иные факторы, выводящие проект из-под контроля. Какие подконтрольные факторы могут помочь вернуться на авангардные позиции? Что можно сделать, чтобы проинформировать босса и команду о тех факторах, которые оказывают на вас влияние, но вышли из-под вашего контроля?