Название этой главы позаимствовано из шахмат. Шахматная партия делится на три этапа: начало (дебют), середина игры (миттельшпиль) и заключение (эндшпиль). В середине игры общая стратегия игрока становится очевидна и воплощается в последовательности его ходов. Большинство ходов партии происходит именно на этом этапе. Заключительная стадия — это завершение игры, когда ресурсов остается мало и каждый шаг на вес золота. В этой главе мы обсудим серединный этап проекта, а в следующей — финал.

Удача благоволит подготовленным умам.

Луи Пастер

«Середина игры» в проекте — это середина общего графика. Вы понимаете, что находитесь на этом этапе, когда что-то получается, а что-то нет, часть проблем удалось обнаружить и решить, но догадываетесь, что вас еще подстерегает немало трудностей. Середина игры — непростой период, потому что многое происходит одновременно и сложно сохранить ясность ума и разобраться в этом. Термин «туман войны» ввел в оборот Клаузевиц , имея в виду, что военные действия кажутся хаотичными, когда участвуешь в них, — это прекрасно подходит к «середине игры». Весь процесс разработки окутан туманом, и неопытным людям легко в нем заблудиться. Обязанность лидеров — провести команду через сомнения и неопределенности «середины игры» к финалу, когда ситуация снова прояснится.

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

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

Как вы понимаете, причиной провала проекта может стать масса факторов. Более того, ограничено время для поиска проблемы и еще меньше его остается для ее решения. Не говоря о том, сколько усилий нужно, чтобы уберечь «здоровые» части проекта от «заражения».

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

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

Хотя данная глава посвящена «середине игры», а следующая — завершению, изложенные в них методы часто пересекаются относительно того, как и когда их применять (например, завершение одного этапа можно считать серединой общего проекта). Итак, предупреждаю, что иногда буду переходить от одной темы к другой.

ВНИМАНИЕ!

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

ЛЕТИМ ВПЕРЕДИ САМОЛЕТА

Чтобы пилотировать крупные, опасные транспортные средства, нужна не только уверенная рука. Чем больше аппарат, которым вы управляете, и чем больше в нем людей, тем больше у него инерции. Как в проект-менеджменте, неопытные «водители» автомобилей, самолетов, авианосцев и других крупных машин недооценивают, сколько времени нужно, чтобы изменения «у штурвала» отразились на поведении объекта. Как показано на рисунке 14.1, траектория крупных транспортных средств (и проектов) значительно зависит от силы инерции и других факторов. Большинству не удается грамотно сформулировать ожидания по результатам своих действий, потому что они не понимают динамику того, чем управляют. Как в процессе торможения на льду, в проектах действует слишком много необъяснимых сил, усложняющих контроль над ситуацией.

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

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

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

ПРОВЕРКА РАБОТОСПОСОБНОСТИ

Для МП самый результативный способ «лететь впереди самолета» — ежедневно проверять работоспособность. Программисты используют эту проверку, чтобы убедиться в эффективности важных факторов кода (в терминологии С — подтверждение отсутствия ошибок). Прекрасная идея, потому что предположения — вещь опасная. Когда одна из проверок работоспособности кода провалится, можно не утруждать себя безнадежным поиском ложных улик (проблем, которых не существует) и задать более важные вопросы о том, почему неработоспособный элемент попал в систему.

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

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

Есть три способа сделать это: тактические вопросы, стратегические вопросы и прозрачная оценка прогресса. Последнюю мы обсудим в следующей главе. А сейчас поговорим о тактических и стратегических во­просах проверки работоспособности.

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

Я всегда пользовался следующим подходом: еженедельно выделял в своем графике полчаса для встречи с самим собой (если я не буду защищать свое время, то кто будет?). Я закрывал дверь, включал музыку и углублялся в список вопросов. Зачастую на это уходило всего несколько минут. Потом я мог заново выстроить приоритеты на день для себя или для команды. В некоторых командах я настаивал, чтобы этот опросник стал частью культуры, и проводил короткие сессии вопросов и ответов на внутренних собраниях.

ТАКТИЧЕСКИЕ (ЕЖЕДНЕВНЫЕ) ВОПРОСЫ, КОТОРЫЕ ПОМОГАЮТ БЫТЬ НА ШАГ ВПЕРЕДИ

• Каковы наши цели и обязательства? Они до сих пор актуальны? Каждый день предстоит делать столько работы, что вы и ваша команда неизбежно забываете о целях. Достаточно смотреть на них каждый день, чтобы двигаться в нужном направлении и корректировать свои приоритеты. Главное правило: если официальные цели не соответствуют реальным (например, из-за прихоти вице-президента или когда команда хочет делать то, что ей нравится), то они не актуальны. В этом случае возникает конфликт, при котором не избежать симптомов. Так вот, не ждите, когда они проявятся. Будьте на шаг впереди, особенно по вопросам, которые напрямую влияют на цели.
• Способствует ли наша сегодняшняя работа достижению целей? Взгляните на список задач, над которыми трудятся ваши программисты сегодня, завтра, на этой неделе. Насколько эти задачи способствуют достижению целей проекта и выполнению требований? Если это не понятно, то ваш корабль тонет. Поработайте с нужными программистами (или программистом), чтобы освежить понимание целей и ценности работы для их достижения. Затем скорректируйте одно из трех: либо цели, либо работу, либо и то и другое. Иногда это называют настройкой работы; как с подвеской автомобиля — нужно периодически проводить проверку, чтобы убедиться: все движется в одном направлении.
• Соответствует ли выполнение рабочих элементов требованиям и сценариям? Есть тысяча способов выполнить задачу без учета истинного духа и намерений проектировщиков. Любое грамотное проектное решение или спецификации непременно учитывают факторы рабочих элементов, которые соответствуют реальным клиентским сценариям. Однако программисты, которым нужно выполнить еще 15 других задач, не успевают уследить за всеми тонкостями удобства использования продукта, требований бизнеса, интеграции компонентов и визуального дизайна. Дизайнер интерфейса (или другой эксперт) должен активно проверять внесение изменений и ежедневную сборку, чтобы убедиться, что рабочие элементы удовлетворяют общим, а не только линейным требованиям.

СТРАТЕГИЧЕСКИЕ (ЕЖЕНЕДЕЛЬНЫЕ ИЛИ ЕЖЕМЕСЯЧНЫЕ) ВОПРОСЫ, КОТОРЫЕ ПОМОГАЮТ БЫТЬ НА ШАГ ВПЕРЕДИ

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

• Какова вероятность достичь следующего дедлайна, этапа или параметра с соответствующим уровнем качества? После расчета ресурсов для выполнения работы многое изменилось. Как люди относятся к делу теперь, когда проект идет полным ходом? Спросите себя и ключевых сотрудников команды, какова вероятность успешного достижения следующего дедлайна — 100%? 90%? 50%? Высокая? Средняя? Низкая? Будьте честны и попросите других о том же. Не давите на команду: не опускайтесь до обвинений и критики, словно вы пытаетесь доказать, что их расчеты никуда не годятся или им нужно больше стараться. Напротив, четко обозначьте, что вам нужны честные ответы, актуальные на данный момент. (Выявление причин сомнений и поиски виновного не вселят в людей уверенность в случае ее отсутствия. Нужно понимать опасения команды.)
• Какие коррективы необходимы, чтобы увеличить эту вероятность? Стопроцентная уверенность в соблюдении следующего дедлайна — крайне редкий случай для любого честного и разумного человека. Задавшись вопросом о вероятности выполнения задач, следует подумать, как точно соблюсти дедлайн. Проводить меньше собраний и реже отвлекаться от работы? Быстрее принимать решения и к тому же более грамотные? Отказаться от некоторых функций? Разъяснить цели? Составлять более грамотные обзоры кода? Что еще? Спросите сотрудников, которые наиболее активно участвуют в повседневной работе. Как можно чаще задавайте этот вопрос и внимательно относитесь к ответам.
• Как внести коррективы осторожно и изолированно? Дей­ствуйте ювелирно. Какие минимальные шаги необходимы для успешного решения проблемы и повышения вероятности выполнения задачи? Телефонный звонок? Электронное письмо? Визуализация важного решения? Уволить кого-то? Не бойтесь радикальных минимальных действий, если их достаточно, чтобы добиться результата. Если ювелирные действия невозможны, мыслите комплексно. Есть ли необходимость скорректировать цели? Изменения уже вносятся? Какой системный процесс или подход нужно подрегулировать? (См. следующий раздел .)
• Каковы самые серьезные или вероятные риски на сегодняшний день, следующую неделю или месяц? Как изменится ситуация, если эти риски оправдаются? Достаточно определить три или больше опасных или вероятных рисков, чтобы перейти к их предотвращению. Включив «радар», вы будете высматривать любые предупреждающие знаки, которые могут указывать на наличие проблем. Даже потратив всего 5–10 минут в неделю на перечисление вероятных рисков и возможной реакции на них, вы будете на шаг впереди. Сравнительно дешевая страховка для проекта, согласитесь!
• Как мог трансформироваться мир, пока я смотрел в другую сторону? Мой вице-президент или стейкхолдер все еще в строю? Изменились ли его цели? Ключевые игроки моей команды беспокоятся о том, чего я не знаю и что может повлиять на проект? Какие действия конкурента потребуют нашей ответной реакции? Ваши партнеры и зависимые стороны все еще в деле? Что не получается сегодня, но я рискую узнать об этом только завтра?

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

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

И напоследок три важных момента.

1. Если вы «отстаете от самолета», то должны знать об этом. Как мы уже говорили, графики — это лишь прогноз. Насколько вы уверены, что все необходимое будет сделано на этой неделе? На 80%? На 50%? Если вероятность 50 на 50 (или хуже), то вы отстаете; порог допустимых ошибок низкий, а ошибки обязательно будут, даже если их еще нет.
2. Видя, что другие «отстают от самолета», предложите поддерж­ку. Не отрицайте проблему: сообщите, что она вам известна, и постарайтесь помочь. Не позволяйте кому-либо из вашей сферы влияния пасть духом или паниковать. Храните спокойствие, помогите другим успокоиться и совместными усилиями опередите свой «самолет».
3. Не стесняйтесь попросить о содействии коллег или супервайзеров. Возможно, это единственный способ восстановиться и «полететь впереди самолета». Воспользуйтесь их помощью: они могут помочь приоритизировать ваше время и время команды, взять на себя часть работы или выслушать. Хватайтесь за предложенную руку и не стесняйтесь просить, чтобы вам ее про­тянули.

Подробнее о том, как справиться с кризисной ситуацией, читайте в .

ОСТОРОЖНОСТЬ ПРЕЖДЕ ВСЕГО

В середине процесса большинство действий — скромные, урезанные версии активности МП на этапе планирования и проектирования. Если нужно включить в работу ранее не учтенное требование, его формулировка и документирование занимают в два раза меньше времени, чем на этапе исследования (понять потребности, рассмотреть компромиссы, распределить приоритеты). Если вы что-то не занесли в спецификации, на решение этой проблемы также уйдет в два или три раза меньше времени, чем на изначальную формулировку спецификаций. В «середине игры» редко вводятся новые навыки — в ход идет более простая и быстрая версия тех, что вы применяли на ранних этапах. Однако не забывайте: скоростная работа порождает риск. Старайтесь не нарушить целостность проекта в результате своих действий!

Хотя поступать осмотрительно иногда сложно, ведь в «середине игры» самое главное — защититься. Процесс уже запущен, многие принятые решения могут противоречить новым действиям. К примеру, если в разгар строительства дома вы вдруг решите изменить план со стандарт­ного на геокупол, придется выбросить массу материала, признать ничтожными кучу усилий и, вероятно, начать работу чуть ли не заново в условиях сильнейшего стресса. Нужен опыт, чтобы понять, как изменение требований, отказ от функций или коррективы повлияют на исходный код и состояние команды.

Цель МП — выбирать безопасные действия. Он должен принимать такие решения, чтобы выполнять задачи проекта, которые могут измениться, и при этом свести к минимуму (хотя и не на 100%) возможный ущерб. Чем эффективнее действия МП, тем меньше негативного воздействия.

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

При обдумывании корректив (изменений в функциях, целях, требованиях) в «середине игры» обратите внимание на пять вопросов ниже.

1. Какую проблему мы пытаемся решить? Нам нужно решить ее, чтобы добиться успеха? Нам нужно решить ее на этом этапе проекта? Можем ли мы смириться с ней?
2. Эта проблема — симптом или причина? Достаточно ли устранить только симптом?
3. Мы понимаем состояние кода или команды достаточно хорошо, чтобы прогнозировать последствия?
4. Издержки, связанные с корректировкой (включая время на анализ состояния кода и команды, рассмотрение альтернатив и обеспечение политической поддержки для решения), перевешиваются преимуществами изменений? Искать и устранять причины симптомов иногда дороже, чем смириться с ними.
5. Что перевешивает: преимущества изменений или риски возможных новых проблем?

Решение предпринимать какие-либо действия или нет опирается на те же стратегии принятия решений, которые мы обсуждали в . Любые действия относительно проектирования, спецификаций, коммуникаций или политики требуют применения тактик, перечисленных в , , и . Отношение и подход те же, однако сроки и порог допустимой ошибки намного меньше. Отсутствие времени для рассмотрения различных вариантов решения означает две вещи. Во-первых, нужно опираться на информацию, полученную на этапе прототипов и проектирования; некоторые корректировки, которые вы рассматриваете сейчас, должны были всплыть уже тогда. Используйте знания команды, чтобы провести грамотный анализ. Во-вторых, будьте осторожны. Чем меньше вы знаете, тем больше рисков не видите. Чем дальше вы продвинулись по графику, тем выше требования для совершения каких-либо дей­ствий.

НАРУШЕННЫЕ ОБЯЗАТЕЛЬСТВА

Для проверки безопасности действий нужно рассмотреть обязательства, которые взяли на себя лидеры команды. Как мы обсудили в , доверие, которое МП получают от команды, зависит от того, как они выполняют свои обязательства. Видение, требования и график — все это формы обязательств лидеров команды, программистов и клиентов. Любыми действиями в «середине игры» можно аннулировать взятые на себя предыдущие обязательства.

Обязательно учитывайте эти обязательства, чтобы сохранить доверие команды при внесении изменений. Как сказал писатель Уоттс Хамфри, «если что-то меняется и влияет на обязательства одной из сторон, ей следует сделать предварительное уведомление и обсудить новые обязательства» . Изменения позволительны, но им должен предшествовать процесс переговоров, схожий с тем, который привел к изначальным обязательствам (видение, требования, график). Нет необходимости составлять документы или проводить масштабные собрания, но нужно информировать людей об изменениях и решить вместе с ними, как их реализовать.

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

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

КОНВЕЙЕР ПРОГРАММИРОВАНИЯ

Прагматичный взгляд на «середину игры» ставит во главу угла программистов, которые пишут коды. Проект движется вперед с каждой строкой кода (любимые функции, ненужные оптимизации и другие похожие операции не способствуют прогрессу). Все усилия по планированию и проектированию, предпринятые до начала разработки, направлены на создание этим специалистам необходимых условий для эффективной работы. Это называется конвейером программирования, и есть множество методов управления им .

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

В своей книге «Управление веб-проектами» (Web Project Management: Delivering Successful Commercial Web Sites, Morgan Kaufmann, 2001) Эшли Фридлейн называет этот процесс «инструктажем команды», а детали для следующей задачи, которую команде предстоит выполнить, — «инструкцией». Как пишет Фридлейн, «чтобы максимально увеличить эффективность и скорость развития, инструкции следует формулировать таким образом, чтобы они всегда опережали текущую работу. Как только задача выполнена, у вас уже должны быть готовы инструкции для следующего этапа». Они опираются на спецификации (если те еще актуальны), а также включают все новые факторы или изменения, о которых нужно знать программистам. Без активного инструктажа программистов в середине процесса любые обстоятельства могут замедлить или вовсе заблокировать работу конвейера: проблемы простоты использования; визуальный дизайн; рабочие элементы, выполненные другими разработчиками; маркетинговые, технические проблемы или внешние зависимости. МП, как специалисты, обладающие самыми разнообразными навыками, являются наиболее подходящими кандидатами на то, чтобы возглавить конвейер программирования, обозначить и решить проблемы и подготовить почву для работы программиста. (Им приходится выискивать расстроенных программистов, которые попали в тупик, но не признаются или не осознают этого.)

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

• Какие рабочие элементы активно кодируются? Блокируют ли какие-либо факторы работу программистов и мешают ли им доделать свои задачи? (Если да, устраните эти факторы.) Считайте, что по проекту объявлено чрезвычайное положение. Если программист не может активно писать код, проект не двигается с места. Нет ничего важнее, чем устранить затруднения, которые блокируют программистов. Спросите их: «Как помочь вам убрать это препятствие?» Они обязательно скажут. Если блокирующий фактор — зависимость (например, Фред должен доделать рабочий элемент № 6, чтобы Боб приступил к работе над элементом № 7), подумайте, какие другие задачи может выполнить программист в состоянии ожидания.
• Программист знает и понимает все необходимое для реализации рабочего элемента? Всегда есть вопросы и пробелы, которые всплывают только на этапе реализации. Одни программисты заранее предвидят эти проблемы и грамотно решают их, другие нет. МП или проектировщик должен активно участвовать в выявлении и закрытии всех пробелов. Иногда их можно прогнозировать: например, все ли проблемы, которые обсуждали на этапе проверки спецификаций по этому рабочему элементу, решены?
• Для каких следующих элементов будет писаться код? Здесь и начинается самое настоящее управление конвейером — умение быть на шаг впереди программистов (см. ). Если текущие рабочие элементы находятся в хорошем состоянии, внимание переносится на следующие по важности задачи проекта. Всегда стремитесь сначала выполнить самую значительную работу, даже если она самая сложная. По каждому элементу конвейера обдумайте, какие открытые вопросы могут затормозить деятельность программистов. Выявите и решите их.
• Выполнен ли последний рабочий элемент? Важно то, что получается на выходе программирования. Кто-то должен отслеживать воздействие изменений в билде и убедиться, что они дают именно тот результат, который нужен с точки зрения клиента. Улучшило функциональность или характеристики продукта завершение этого рабочего элемента? Команда тестирования дала добро? Все ли тесты были проведены? Проанализировал ли кто-нибудь ошибки и выяснил ли, что упустили? Ежедневные сборки (о которых мы поговорим в следующей главе) — простой способ отслеживать текущее состояние проекта, найти пробелы в выполненной работе и определить, чего не хватает. Чем масштабнее рабочий элемент, тем важнее эта работа.

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

АГРЕССИВНЫЙ И ОСТОРОЖНЫЙ КОНВЕЙЕР

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

Команда с агрессивным подходом может сделать основной акцент на конвейер, чтобы приоритизировать задачи. Вместо того чтобы разрабатывать сложный WBS по всем элементам, команда делает ставку на неизбежность изменений и на способность МП или ведущего программиста управлять конвейером. В таком случае риск выше: если конвейер забьется или не сможет на шаг обгонять команду, будут приняты неудачные решения, а время растрачено впустую. Подробнее о WBS и его применении к графику проекта читайте в «Абсолютном контроле над проектом» Стивена Дево (Total Project Control, Wiley, 1999) или любом качественном традиционном руководстве по проект-менеджменту.

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

Однако в конвейере важно не то, как вы действуете. Каждая методология предлагает альтернативный способ. Главное — эффективно управлять конвейером, чтобы нужные рабочие элементы были сделаны правильно и тратилось минимальное время на размышления о том, что делать дальше.

КОНВЕЙЕР ПРОГРАММИРОВАНИЯ СТАНОВИТСЯ КОНВЕЙЕРОМ ИСПРАВЛЕНИЯ ОШИБОК

На более поздних этапах проекта, после того как все рабочие элементы выполнены, планирование продолжается. Но вместо рабочих элементов конвейер работает с ошибками и дефектами, которые нужно исправить. Мы обсудим это в , когда речь пойдет о триаже — сортировке ошибок.

ОТСЛЕЖИВАЕМ ПРОГРЕСС

Простейший способ отслеживать прогресс в «середине игры» — список рабочих элементов: пока не будет завершен каждый намеченный в плане рабочий элемент (на адекватном уровне качества), не переходим к следующему этапу (рис. 14.5). Все «срединные» стратегии предполагают понимание состояния проекта, выбор верного направления для команды и обеспечение условий для успешного завершающего этапа. Расчеты по рабочим элементам — самые важные данные для этих решений.

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

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

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

КАК ПОПАСТЬ ПО ДВИЖУЩИМСЯ МИШЕНЯМ

Ни одно сражение не было выиграно исключительно благодаря плану — но ни одно из них не было бы выиграно без плана.

Дуайт Эйзенхауэр

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

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

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

Дан Ланер, генерал-майор армии обороны Израиля

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

Рисунок 14.6 показывает простой пример внесения корректировок, соответствующих движущимся целям. Проект начинается в точке А и должен закончиться в точке Б. Если через две недели после начала работы (возможно, по завершении первого короткого этапа) лидеры команды решат, что задачи Б изменились, проект следует скорректировать так, чтобы он соответствовал новому «пункту назначения». Еще через две недели вносятся новые корректировки и прокладывается новый курс. Часть работы придется выбросить в мусор, однако эта выброшенная часть будет меньше, если скорректировать направление на более раннем этапе проекта. Если эти действия совпадут с завершением или началом очередного этапа, у команды будет время поработать над проектным замыслом, чтобы компенсировать изменения, добавить рабочие элементы, модифицировать сделанную работу и внести коррективы пошагово.

Даже без грамотного разбиения на этапы и критические точки конвейер программирования поможет команде разработчиков управлять изменениями в середине проекта. Для программистов всегда остается буферное время. Чем больше времени заложено в конвейере (рис. 14.7), тем больше буфер. Если, конечно, предположить, что у кого-то (у МП или ведущего программиста) есть возможность управлять конвейером, команде не придется полностью тормозить процесс, чтобы изменить направление. Просто правильной работы конвейера должно быть достаточно.

Однако есть одно условие: изменения не должны радикально отличаться от изначального плана; он не дает слишком большого простора для маневров (рис. 14.7). Если новые требования или цели превышают определенную точку, приходится заново проводить работу по проектированию и исследованиям, а это выходит за рамки тех сроков, которые заложены в конвейер программирования (или в некоторых случаях — за рамки сроков, запланированных на следующий этап работы). К примеру, если изначальный план предполагал изготовление мини-духовки, вполне возможно скорректировать проект в его середине, изменить габариты, сделать духовку средних размеров — но вот ускоритель частиц или нефтяной танкер из нее уже никак не получится.

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

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

НЕОЖИДАННЫЕ РЕШЕНИЯ МЕНЕДЖМЕНТА

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

Зачастую такие изменения курса вызваны капризами менеджеров, клиента или конкурентов, а не логической обоснованностью. Иногда в вашей власти самостоятельно изменить направление, а порой нужно подождать, пока решение примет кто-то другой. В любом случае вы должны держать в голове примерный план: что делать, если грозящие изменения станут реальными. Предзнаменования того, что начальство скоро «спустит» директивы или конкуренты совершат нечто непредвиденное, обычно можно распознать за несколько дней или недель — если искать их, а не дожидаться, пока новость станет шоком для вашего проекта. Такого поворота событий не всегда реально избежать, но иногда все же можно.

Используя ту информацию, которой вы обладаете, периодически старайтесь угадать, как может измениться направление (поддержка новых технологий, новая функция, новая цель?), и подумайте, какие коррективы придется предпринять в этом случае. План может быть приблизительным — например, поговорите с ведущим программистом о том, чего ждать в будущем: «Фред, что нужно будет сделать, чтобы поддер­жать интерфейс приложения 2.0, помимо того, что мы уже используем?» Ваша цель — не составление нового «плана битвы», а получение примерного представления о том, как будет выглядеть этот путь, если вам и вашей команде придется пойти по нему. Пересмотрите свой список приоритизации по рабочим элементам () и проверьте: возможно, вы уже задумывались о новых задачах, которые придется выполнить.

Анализ воздействия изменений

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

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

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

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

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

Возможное направление изменений

Чем ближе проект к изначальным (или последним) целям, тем сложнее перестроиться и изменить направление. На рисунке 14.8 проект официально движется в сторону Б, однако ходят слухи, что направление изменится («?»). МП старается предположить, каким будет это изменение, и подстроиться под него. Он составляет примерный план реагирования со своими программистами.

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

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

УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ (КОНТРОЛЬ)

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

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

Самый простой способ управлять изменениями — сверхупрощенная версия процесса спецификаций. NASA и Microsoft называют ее DCR, или запрос об изменениях проекта (design change request). Другие распространенные названия — ECR, запрос о технических изменениях (engineering change request), ECO, приказ о технических изменениях (engineering change order), или CR, запрос об изменениях (change request).

Предлагаю простейший процесс.

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

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

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

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

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

РЕЗЮМЕ

• «Середина игры» и ее завершение соответствуют середине и концу проекта.
• Как только возникают трудности, ваша задача — выяснить, что пошло не так, и решить проблему. Повторяйте этот процесс до завершения проекта.
• Проекты представляют собой сложные нелинейные системы со значительной силой инерции. Бездействие и достижение того момента, когда проблема стала по-настоящему серьезной, лишь усугубят ситуацию.
• Когда проект выходит из-под контроля, вы «летите за самолетом», а это не самое подходящее место. Проверка работоспособности — легкий способ быть «впереди самолета». Есть тактические и стратегические проверки.
• Подумайте, какие действия следует предпринять, чтобы исправить ситуацию самым безопасным способом. Чем масштабнее действия и чем дальше продвинулся проект, тем выше риск.
• Конвейер программирования — способ управлять рабочими элементами на этапе реализации. Есть как агрессивные, так и более осторожные способы управления конвейером.
• Планирование по этапам и контрольным точкам и конвейер программирования дают возможность безопасно корректировать курс проекта.
• Контроль изменений (DCR) — способ регулировать среднеуровневые и низкоуровневые изменения в проекте.

УПРАЖНЕНИЯ

А. Находясь на середине проекта, спросите любых пятерых членов команды, насколько (в процентах) они уверены в графике. Теперь задайте тот же вопрос пятерым менеджерам. Сравните результаты и представьте их на собрании команды. Если этот опыт окажется полезным, повторяйте его еженедельно. Сохраняйте анонимность всех участников опроса, чтобы они могли честно высказывать свое мнение.

Б. Зачастую МП вынуждены «лететь за самолетом», потому что не могут контролировать график, бюджет и другие факторы, которые важны для проекта. Какие факторы, подвластные вашему контролю, позволяют занять более выгодную позицию — «впереди самолета»? Как информировать вашего босса и команду о факторах, которые влияют на вас, но не поддаются вашему контролю?

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

Г. Обозначьте три ближайших момента передачи работы — когда дела, которые вы выполняете, нужно передать другому человеку или, наоборот, принять от него. Что можно сделать по этим трем конкретным пунктам, чтобы повысить вероятность успешной передачи?

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

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

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

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

Отправить