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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

Упражнения

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

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

3. Когда в последний раз вы признавались, что впадали в отчаяние? Составьте список, за что вы больше всего переживаете в текущем проекте. Выберите свое самое большое опасение и поговорите с кем-нибудь о нем. Даже если вы поговорите об этом с другом за пивом, это поможет вам справиться с ситуацией.

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

5. Создайте визуальное представление вашего командного конвейера разработки программного кода по состоянию на сегодняшний день. Можно просто подойти к доске и на одной оси составить список всех программистов, а на другой проставить временные отметки. Перечислите следующие три работы, которыми, по утверждению программистов, они заняты, чтобы каждая из них заняла столько места, сколько она должна занять согласно рабочему графику. Как такая визуализация изменит ваши размышления об управлении проектом?

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

7. Многие не любят, когда следят за продвижением их работы. Какие стимулы можно предусмотреть для людей, чтобы они сами отслеживали состояние собственной работы? Почему спортсменам нравится вести статистику своих достижений, а людям, занятым в производстве, это не нравится?

8. Когда вы начинаете настаивать на официальном изменении технических требований, команда игнорирует ваши запросы и продолжает работать во вчерашнем режиме. Какой должна быть ваша реакция? Каков лучший способ перевода команды на новый режим работы?

Глава 15. Стратегия эндшпиля

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

Не забывайте, что у всех проектов, как правило, более одного крайнего срока. У каждого проекта есть промежутки времени, ведущие к концу какого-нибудь этапа или к завершению всего проекта. При этом возникает скрытая опасность, что команду станут усиленно подгонять, чтобы уложиться в срок, хотя она и так прилагает к этому запредельные усилия, понимая, что следующий срок тоже не за горами. Если команда полностью выложится и подойдет к началу следующего этапа в состоянии усталости, депрессии и стресса, то вероятность соблюдения очередного срока резко снизится. Винс Ломбарди (Vince Lombardi) однажды сказал, что накопленная усталость делает всех нас трусливыми. Когда мы измотаны, вернуть нас в работоспособное состояние не сможет никакое количество выпитого крепкого кофе. Как говорит Генри Кайзер (Henry Kaiser), то, как сыграна нота, столь же важно, как и то, какая это нота.