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

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

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

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

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

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

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

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

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

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

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

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