Название главы позаимствовано из шахматной терминологии. Шахматная игра делится на три части: дебют, миттельшпиль и эндшпиль. В ходах, которые игроки делают в миттельшпиле, раскрывается их основная стратегия. Именно в этой части игры делается основная часть всех ходов. Игра завершается эндшпилем, когда ресурсы уже на исходе и каждый ход на счету. Эндшпиль проекта рассматривается в следующей главе, а данную главу, которая посвящена миттельшпилю, хочется начать цитатой Луи Пастера: «Открытия приходят лишь к тем, кто подготовлен к их пониманию».
Миттельшпиль проекта находится в середине общего рабочего графика. Он наступает, когда часть компонентов уже работает, а часть – нет, некоторые вопросы изучены и решены, а другие еще ничем не проявились. В миттельшпиле множество событий происходит одновременно, затрудняя ясное представление о том, насколько благополучно они развиваются. Термин туман войны, введенный Клаузевицем[81] для характеристики впечатлений о хаотичности военных действий, как нельзя лучше подходит к миттельшпилю. Такой же туман неизбежно окутывает и команду, всецело занятую разработкой, поэтому неопытным специалистам в нем легко затеряться. Провести команду через неопределенность миттельшпиля и вывести ее к эндшпилю, где все снова становится на свои места, – основная обязанность руководителей команды.
В простейшем представлении миттельшпиль, как и эндшпиль, целиком относится к проектному сопровождению высокого уровня:[82]
4. Если к концу дня все в проекте идет хорошо, значит, ваша цель на следующей день – сохранение этой тенденции.
5. Если в какой-то из дней в проекте начинаются проблемы, ваша цель – найти причину, а затем предпринять необходимые действия для того, чтобы проект снова вошел в нужную колею. На это может уйти несколько часов, дней или недель.
6. Повторяйте предыдущие действия, пока проект не будет завершен.
Очевидная сложность заключается в бесчисленном количестве причин, по которым работа над проектом может не заладиться. Хуже того, на выявление этих причин отводится весьма краткий срок, а на их устранение, возможно, и того меньше. Не считая тех усилий, которые нужно приложить, чтобы защитить от всяческих напастей благополучно развивающиеся части проекта.
По этим и другим причинам в миттельшпиле и эндшпиле уровень прилагаемых усилий и испытываемых стрессов очень высок. Команда работает ускоренными темпами, и право на ошибку тает с каждым днем. А по мере приближения к последней стадии проекта кому-то нужно понять, что для благополучного завершения правильнее не просто «нажать на тормоза», а притормаживать постепенно.
В данной главе и далее я буду придерживаться тех же предположений о методах работы, которые использовались в главе 2, поэтому перед тем, как двигаться дальше, имеет смысл еще раз просмотреть раздел «Решающие факторы и методологии» в главе 2.
Хотя материалы данной главы в основном посвящены миттельшпилю, а следующей – эндшпилю, эти главы во многом перекликаются в том, как и когда должны применяться описываемые технологии (например, эндшпиль одного из этапов может рассматриваться как часть миттельшпиля всего проекта). Поэтому не удивляйтесь, если иногда при изложении материала я буду совершать экскурсы вперед и назад по этим казалось бы разным темами.
ПРИМЕЧАНИЕ
Описание механизмов управления миттельшпилем и эндшпилем, приводимое в этой и следующей главах, дано в масштабе довольно крупного производства. Если вам встретятся ситуации, не подходящие к масштабу вашего проекта, то вы их можете пропустить. Я не думаю, что предлагаемые здесь рекомендации можно целиком применить к какому-нибудь отдельно взятому проекту. Тем не менее я пытаюсь предложить вам наиболее ценные сведения, применимые не только к вашему текущему проекту, но и к любым другим проектам, которыми вам, возможно, еще предстоит заниматься.
Бежать впереди паровоза
Управление большими и весьма опасными объектами требует не только твердой руки. Чем больше управляемый объект и чем больше в нем людей, тем сильнее его инерционность. Новички, как в руководстве проектами, так и в управлении тяжелыми машинами (грузовиками, аэробусами, авианосцами и т. д.), недооценивают время реакции объекта на изменение положений органов управления. На рис. 14.1 показана траектория автомобиля или проекта, заметно изменяющаяся в зависимости от количества вовлеченной в процесс кинетической энергии и других сил. Многим людям не удается правильно выстроить свои предположения относительно последствий собственных действий. Причина часто кроется в том, что они не понимают, какие силы оказывают влияние на динамику тех объектов, с которыми им приходится иметь дело. Они напоминают ученика автошколы, впервые попавшего в занос на снежной дороге из-за того, что слишком много непонятных сил помешало ему справиться с управлением.
Рис. 14.1. Одни и те же действия могут привести к различным результатам в зависимости от инерционности проекта
При потере управления люди, призванные контролировать ход событий, обычно впадают в панику. Они могут не осознавать этого (утратившие самообладание крайне редко признаются в своем состоянии), но факт остается фактом. Первой реакцией на происходящее обычно становятся решительные действия, направленные на выправление возникшей ситуации. Но поскольку люди так и не поняли, какие силы участвуют в данном процессе, эти корректирующие действия, как правило, оказываются чрезмерными (рис. 14.2). К тому времени, когда они понимают, что наделали, требуются новые корректирующие действия, которые не заставляют себя ждать. А поскольку они руководствуются той же самой логикой, которая уже привела их к столь забавной ситуации, возникают все новые и новые проблемы.
Рис. 14.2. К ужасу тех, кто обязан контролировать ситуацию, корректирующие действия в ответ на влияние неизвестных сил могут иметь непредсказуемые (и зачастую неприятные) последствия
Когда движение самолета, автомобиля или проекта становится нестабильным, резкие управляющие действия становятся опасными, даже для тех, кто обладает завидным мастерством и опытом. (Разумеется, небольшие проекты более податливы и управляемы, но у них также имеется некоторая инерционность.) Нестабильность делает непредсказуемыми результаты многих действий, потому что слишком часто и слишком быстро происходят разного рода изменения. В такой обстановке хорошее управление проектом во многом заключается в том, чтобы быть на один-два шага впереди самого проекта, прикладывая все усилия, необходимые в первую очередь для того, чтобы не попасть в подобную ситуацию.
У летчиков-истребителей есть одно образное выражение, прекрасно описывающее состояние пилота, у которого нет дара предвидения: он летит позади самолета. Это значит, что пилоту не удается быть хотя бы на шаг впереди того, что происходит с его самолетом, и он становится жертвой совокупности сил, воздействующих на его истребитель. Проекты, как и полеты на мощных самолетах, требуют управления множеством взаимодействующих сил. Все они относятся к нелинейным системам, а значит, изменение одного из параметров (скорости, угла, режима, цели) может привести не к одному, а к множеству эффектов или повлиять на систему более существенно, чем ожидалось, поскольку воздействию параллельно подвергается множество различных факторов или людей. Отсюда следует предостережение: даже при работе над стабильным, но скоротечным проектом непростая природа, присущая как программной среде, так и самой команде разработчиков, предполагает непредвиденность последствий любых управляющих действий. Иногда эти последствия ничем себя не проявляют в течение нескольких дней или даже недель. Когда же отложенные последствия наконец проявятся, то легко можно предположить, что их проявления были вызваны какими-то другими совсем недавними причинами, и тогда эффективное решение проблемы будет затруднено.
Мыслите здраво
Для руководителей проектов наиболее эффективным способом бежать впереди паровоза может стать ежедневный контроль логики собственных действий. Программисты называют проверку правильности важных блоков кода санитарным контролем (в терминологии языка С можно вспомнить о функции assert()). Если учесть, что предположения – вещь крайне опасная, то ценность этой идеи не вызывает сомнений. Когда одна из санитарных проверок программного кода закончится неудачей, можно будет не искать черную кошку в темной комнате (несуществующую проблему), а задаться более существенным вопросом: почему в систему было введено абсурдное условие?
Если вы захотите бежать впереди паровоза, то вам следует постоянно проверять состоятельность ожидаемых вами условий. Как только вы обнаружите какую-нибудь фальшь, то сразу поймете, на что следует обратить внимание.
Сложность в том, что существует множество других аспектов, доступных проверке на разумность подходов. Одновременно проверять цели, рабочие графики, технологические решения, моральный климат, позиции конкурентов, бюджет и политику просто невозможно (хотя подобное утверждение для некоторых не вполне адекватных руководителей сдерживающим фактором не является). Подвергать команду ежедневным пыткам, заставляя подтверждать состоятельность десятков случайных предположений, – роковая ошибка. Чем больше вы подталкиваете свою команду к подтверждению предположений, состоятельность которых, в общем-то, не вызывает сомнений, тем меньше вы ей доверяете и тем больше вы тратите ее рабочее время понапрасну. Желание узнать о состоянии проекта нужно удовлетворять, не нанося вреда самому этому состоянию.
Для этого существует три способа: тактические вопросы, стратегические вопросы и прозрачные для команды показатели прогресса. Все, что касается измерений, рассматривается в следующей главе, а здесь давайте сосредоточимся на тактических и стратегических вопросах, касающихся контроля разумности подходов.
Процесс довольно прост: заведите себе краткий перечень вопросов, которые помогут вам бежать впереди паровоза, и задавайте их, совершая своеобразный ритуал. Тактические вопросы задавайте раз в день, стратегические – раз в неделю. Вы можете задавать их самому себе или привлекать к ответам конкретных специалистов своей команды. Следует также поощрять специалистов, у которых имеется опыт и способности к самостоятельному общему анализу ситуации, и сопоставлять их результаты с вашими.
Я делал это так: включал в свой рабочий график еженедельное получасовое совещание с самим собой (кому как не мне распоряжаться собственным временем?). Я запирался в кабинете, настраивался и просматривал свой перечень вопросов. Часто на это уходило всего несколько минут. После этого я мог соответственно скорректировать приоритеты своего рабочего дня или рабочего дня своей команды. Некоторые команды я подталкивал к тому, чтобы подобный опрос стал частью их производственной культуры, а сам проводил лишь сокращенный вариант такого опроса и оглашал ответы в ходе совещаний.
Тактические (ежедневные) вопросы, позволяющие бежать впереди паровоза
Каковы наши цели и обязательства? Не нуждаются ли они в уточнении? Большая загруженность повседневной работой неизбежно приводит к тому, что вы и ваши сотрудники теряют из виду цели проекта. Простой ежедневный просмотр этих целей восстанавливает целенаправленность и приоритетность действий. Для команды более важным является несовпадение официальных целей с реальными (скажем, по прихоти вице-президента) или командными (когда команда искренне считает, что работает над чем-то совершенно выдающимся), в таком случае цели требуют уточнения. Если цели не уточнены, в команде возникает конфликтная ситуация, последствия которой обязательно проявятся. Не стоит дожидаться явных признаков, если конфликт очевиден, они неминуемо проявятся. Опережайте события, особенно в вопросах, которые непосредственно касаются целей проекта.
Является ли наша сегодняшняя работа вкладом в стоящие перед нами цели? Посмотрите, чем занимались ваши программисты сегодня, вчера, на этой неделе. Можно ли явно проследить их вклад в достижение целей или в выполнение требований? Если нет, значит, ваш лайнер сбился с курса. Нужно поработать с конкретными программистами (или программистом) и освежить представление каждого из них о целях и о ценности работы, направленной на их достижение. Затем следует уточнить одно из трех: цели, работы или все вместе. Иногда это называется корректировкой направления работ. Аналогично схождению колес на автомобиле вам нужно проводить периодические проверки и убеждаться, что все колеса имеют единое направление.
Соответствуют ли уже выполненные работы существующим требованиям и сценариям функционирования конечного продукта? Есть тысяча способов завершить какую-нибудь работу, так и не добившись полного соответствия духу и букве проектного замысла. Любой хороший замысел или технические условия должны определять все необходимое для того, чтобы работы соответствовали сценариям реальных действий пользователя. Тем не менее программист, занятый выполнением, скажем, пятнадцати работ, зачастую забывает о тонкостях потребительских качеств, деловых требованиях, интеграции компонентов и визуальных решениях. Если же работать под наблюдением специалиста по дизайну интерфейса (или других специалистов), то специалист ежедневно сможет просматривать контрольные показатели и убеждаться в том, что работы удовлетворяют не только отдельным, но и общим требованиям.
Стратегические (еженедельные или ежемесячные) вопросы, позволяющие бежать впереди паровоза
Стратегические вопросы часто ставятся на совещаниях руководящего состава. Если у вас проводятся еженедельные или ежемесячные обсуждения состояния проекта, вопросы такого рода вполне достойны быть в центре внимания руководства. Но они подойдут и отдельному руководителю проекта, работающему в какой-нибудь узкой сфере.
Какова текущая вероятность уложиться в сроки к очередной дате (контрольной точке, сроку поставки), обеспечив приемлемый уровень качества? С тех пор как были сделаны расчеты трудозатрат, многое изменилось. Как теперь в процессе самой работы люди ощущают ее объем? Задайте вопрос себе и ключевым представителям своей команды, какова вероятность успешного соблюдения очередного срока. 100 %? 90 %? 50 %? Высокая? Средняя? Низкая? Постарайтесь честно ответить на этот вопрос и попросите об этом же других. Проявите лояльность к команде: не превращайте все в обвинения и упреки, пытаясь доказать несостоятельность их оценок или необходимость более интенсивной работы. Лучше дайте всем понять, что вам нужны честные ответы на вопросы о реальном состоянии дел. (Выяснение причин неуверенности или поиск виновных не устранит факт сомнений. Нужно стремиться познать, в чем суть этих сомнений.)
Какие коррективы следует внести для повышения этой вероятности? Вряд ли можно добиться от психически нормального и честного человека стопроцентной веры в соблюдение очередного срока. Следом за вопросами о вероятности неизменно должны идти вопросы о том, как добиться ее повышения. Сократить количество совещаний и перерывов? Ускорить выработку решений? Урезать функциональность? Найти лучшие решения? Прояснить цели? Улучшить анализ создаваемого кода? Что еще? Спросите об этом людей, имеющих непосредственное отношение к решению повседневных первоочередных задач. Вмените себе и команде в обязанность активное участие в проработке этих вопросов и поиске ответов на них.
Как провести более точную и адресную корректировку? Ваше мышление должно быть в первую очередь хирургическим. Что нужно сделать по минимуму для решения проблемы и повышения вероятности успеха? Позвонить по телефону? Послать сообщение по электронной почте? Рассекретить важное решение? Кого-нибудь уволить? Не бойтесь идти на решительные меры, если ничего другого не остается. Если хирургические методы недоступны, нужно мыслить шире. Может быть, стоит скорректировать цели? Изменить контрольные показатели? Какие системные процессы или позиции можно скорректировать для устранения причин и следствий? (См. следующий раздел.)
Каковы на данный момент (на следующую неделю, месяц) наиболее значимые или вероятные риски? Могут ли они застать нас врасплох? Если вам удастся определить, в чем могут заключаться хотя бы три-четыре наиболее опасные и наиболее вероятные рискованные ситуации, вы уже сделаете большой шаг навстречу их предупреждению; вы сможете настроиться на их отслеживание и станете обращать внимание на любые признаки их наступления. Если тратить на составление перечня возможных рисков и возможных ответных шагов всего 5–10 минут в неделю, это уже будет означать, что вы начинаете бежать впереди паровоза. Этот вид подстраховки зачастую не требует особых затрат: каких-то несколько минут в неделю позволят приобрести довольно мощную защиту от неприятностей.
Как без моего ведома может измениться ситуация? Держит ли руку на пульсе мой вице-президент или куратор? Не изменились ли его цели? Нет ли чего-нибудь такого, чем озабочены ключевые игроки моей команды, о чем я не знаю и что, окажись они правы, может повлиять на проект? Что такого сделал наш конкурент, на что следовало бы ответить? Выполняется ли мониторинг наших отношений с партнерами и смежниками? Чего не удалось сделать сегодня, что я могу не заметить до завтра? Обычно, чтобы получить ответ на этот вопрос, нужно сделать пару коротких телефонных звонков или походить по коридору. Только не вздумайте при этом заниматься мелочной опекой, впадать в паранойю или нагонять страх на окружающих. Наводите справки от случая к случаю, не создавая лишнего ажиотажа. Более того, поощряйте и вознаграждайте тех людей, кто заранее собирает для вас эту информацию (выполняя свои или чужие обязанности).
Независимо от уровня вашего опыта, подготовленности или интеллекта, настанут дни, когда вы перестанете болтаться позади проекта. Научитесь отличать навалившуюся на вас рутину от бега вслед за уходящим составом – это не одно и то же. Есть вполне реальные шансы на то, что ощущение нехватки времени на выполнение существующего объема работ будет вашим частым спутником. Но если вы подготовили списки приоритетов (см. главу 13), то всегда будете знать, какая работа ожидает своего (то есть вашего) часа. Но если вы не успеваете и плететесь в хвосте проекта, вас неизменно охватит чувство безысходности, подавленности и даже апатии. Вы уверуете в то, что никакая сверхурочная работа не сможет вернуть вам контроль над проектом.
И, напоследок, еще три важных замечания:
1. Вы должны осознать тот факт, что плететесь в хвосте. Следует помнить, что рабочие графики носят вероятностный характер. Какова ваша уверенность в том, что с недельным объемом работы удастся справиться своевременно? 80 %? 50 %? Если шансы на то, что вы справитесь, составляют пятьдесят на пятьдесят (или хуже), значит, вы плететесь в хвосте, у вас слишком мал предел возможных ошибок и вы их обязательно наделаете, если уже не наделали.
2. Если вы видите, что в хвосте плетется кто-то другой, предложите свою помощь. Не стоит делать вид, что проблемы не существует: признайтесь в том, что она для вас очевидна, и попытайтесь оказать помощь. Не позволяйте тем, кто находится в сфере вашего влияния, колебаться или паниковать. Сохраняйте спокойствие, помогайте сохранять его другим и совместно работайте над тем, чтобы снова оказаться впереди.
3. Не стесняйтесь принимать помощь коллег или кураторов. Возможно, сторонняя помощь будет единственным средством снова обогнать паровоз. Пусть вам помогут разобраться с распределением вашего рабочего времени и определить, на что лучше потратить время команды, пусть заберут часть вашей работы или просто послушают, как вы будете «выпускать пар». Примите протянутую руку. Если вам ее не предложили, то попросите людей о помощи.
Чтобы больше узнать о том, как справиться с кризисной ситуацией, обратитесь к главе 11.
Действуйте осмотрительно
В миттельшпиле деятельность теряет свою масштабность, все самое трудное руководитель проекта уже сделал в период планирования или проектирования. Если какое-нибудь требование было упущено и его нужно включить в проект, то процесс его определения и документирования является повторением действий, предпринятых в период подготовки всего набора требований (осознать потребности, рассмотреть все «за» и «против», сформулировать требование и определить его приоритет). А если что-то было упущено в технических условиях, то решение этой проблемы представляет собой двойное или тройное повторение процесса выработки технических условий. В миттельшпиле применяется и ряд новых приемов, которые обычно являются упрощенными и приблизительными версиями уже применявшихся приемов. Проблема в том, что ускоренная работа порождает риск. В миттельшпиле осмотрительность (стремление максимально обезопасить свои действия) означает, что в результате предпринимаемых действий не должна быть случайно нарушена целостность проекта.
Из-за того что в миттельшпиле возникают различные обстоятельства, способные привести проект к краху, безопасность действий дается нелегко. Все находится в движении, многие решения уже приняты и вполне могут вступить в противоречие с любыми новыми действиями. Например, если при строительстве дома вы в самой середине процесса решили изменить план крыши со стандартного треугольного на куполообразный, вам придется пожертвовать затраченными на строительство материалами и усилиями и возможно приступить к новой работе под более высоким давлением. Чтобы научиться вносить изменения в требования, урезать функциональность или модифицировать замысел, оказывая существенное влияние как на ядро уже созданного программного кода, так и на команду разработчиков, требуется немалый опыт.
Осмотрительность должна стать целью любого руководителя проекта. Он должен действовать и вести себя так, чтобы с минимально возможным ущербом удерживать направление проекта в условиях изменяющихся целей. Обойтись вообще без ущерба невозможно, поэтому к нему следует быть готовым. Но чем эффективнее действия руководителя, тем слабее будет негативное воздействие на проект.
На рис. 14.3 показано, что чем дальше продвигается реализация проекта, тем труднее становится действовать осмотрительно. Причина кроется в том, что со временем вероятность удорожания последствий изменений возрастает: повышаются шансы на то, что уже готовые компоненты придется либо модифицировать, либо просто выбросить. Эти затраты неизбежны, но осмотрительность означает, что накануне принятия решения должно сложиться представлением о том, во что оно может вылиться.
Рис. 14.3. Проявить осмотрительность при внесении корректировок тем труднее, чем они масштабнее и(или) чем позже они предпринимаются
При рассмотрении корректировок в период миттельшпиля (при внесении изменений в характеристики, цели или требования) нужно ответить на следующие пять вопросов:
1. Какую проблему мы пытаемся решить? Нужно ли ее решать для успешного продвижения проекта? Нужно ли решать эту проблему именно на данном этапе работы? Нельзя ли мириться с ней и дальше?
2. Что представляет собой эта проблема, чем она является, симптомами или болезнью? Может быть, можно ограничиться устранением симптомов?
3. Достаточно ли имеющегося представления о состоянии программного кода или команды разработчиков, чтобы предсказать, как на них скажется корректировка?
4. Стоят ли затраты на корректировку (включая время на оценку состояния кода и команды, на рассмотрение альтернативных вариантов, на обеспечение политической поддержки решения) получаемой от нее выгоды? Поиск болезни и выработка решений по ее лечению может обойтись значительно дороже, чем мирное сосуществование с болезнью при условии минимизации внешних проявлений ее симптомов.
5. Может ли риск возникновения новых потенциальных проблем свести «на нет» весь выигрыш от вносимых изменений?
Решение о том, стоит ли предпринимать какие-либо действия, принимается в соответствии с той же стратегией принятия решений, которая была рассмотрена в главе 8. Любые действия, касающиеся проектирования, технических условий, общения или политики, требуют применения тактики, рассмотренной соответственно в главах 6, 7, 9 и 16. Подходы и позиции те же, а отпущенное время и право на ошибку значительно меньше. Дефицит времени на обдумывание возможных вариантов вынуждает поступать особым образом. Во-первых, нужно полагаться на данные, полученные ранее при изучении прототипов и конструкторских проработок. Часть рассматриваемых наработок берется именно оттуда, а имеющиеся у команды знания помогают провести анализ текущей обстановки. Во-вторых, нужно проявлять консерватизм. Чем меньше вы знаете, тем больше рисков остаются незамеченными. Чем дальше продвинулся ваш проект, тем выше должна быть планка предпринимаемых действий.
Нарушение обязательств
Неотъемлемым атрибутом осмотрительности является учет обязательств, которые руководитель проекта имеет перед командой. В главе 12 мы уже говорили, что доверие к руководителю со стороны команды определяется его способностью придерживаться своих обязательств. Формами обязательств между руководством, руководителями команд, программистами и заказчиками являются концептуальные документы, требования и календарный план. Любые предпринятые вами в миттельшпиле действия могут нарушить ранее взятые обязательства.
Чтобы сохранить доверие команды при внесения каких-нибудь изменений, вы должны уважительно относиться ко всем предыдущим обязательствам. Вот что по этому поводу говорит Уоттс С. Хэмфри (Watts S. Humphrey): «Если изменяется что-нибудь, влияющее на обязательства обеих сторон, об этом дается предварительное уведомление, и стороны договариваются о новых обязательствах[83]». Вносить изменения никто не запрещает, но они должны следовать за переговорным процессом, аналогичном тому, в котором создавался первый пакет обязательств (концепция, требования, календарный план). При этом не следует готовить проекты документов или собирать расширенные совещания, но поставить людей в известность об изменении обязательств и привлечь их к процессу принятия решения о характере предстоящих изменений нужно обязательно.
Если вы просите команду выбросить результаты двухнедельного труда, нужно быть уверенным, что цена этого шага учтена в принятом решении. Нужно объяснить команде все причины, по которым вносимые изменения считаются правильными, и раскрыть факторы, подкрепляющие это убеждение. Пригласите, по возможности, кого-нибудь из команды поучаствовать в обсуждении, проводимом перед принятием окончательного решения.
Не бойтесь вносить изменения. Перемены ведут к улучшению, и они неизбежны. Однако существует множество различных вариантов изменений и много различных способов для руководителя по их внедрению в работу команды. Если раньше проект шел на запад, а теперь вдруг понадобилось, чтобы он пошел на север, для поворота команды на север от вас потребуются те же навыки, которые применялись для того, чтобы заставить команду двигаться на запад (хотя придется вдвое увеличить скорость и наполовину избавиться от формализма). Вернитесь к главам 3, 4, 11 и 12 и почитайте изложенные в них инструкции по руководству в условиях перемен.
Производственный конвейер по созданию программного кода
Прагматичный взгляд на миттельшпиль фокусируется на работе программистов, создающих код. Единственный способ поступательного движения связан с тем, что с каждой написанной строкой программного кода проект приближается к своему завершению (бесконечная возня с любимой функцией, ненужная оптимизация и тому подобное прогрессу не способствуют). До того как программисты приступят к созданию кода, либо они сами, либо кто-то другой затрачивает усилия на планирование и проектирование, целиком направленные на подготовку для них эффективной последовательности работ, выполняемых до тех пор, пока тикают часы проекта. Это называется производственным конвейером по созданию программного кода, для управления которым существует масса различных технологий.[84]
Следить за слаженным функционированием конвейера входит в обязанность руководителя проекта. Программисты и сами могут управлять работой конвейера, решая, кто чем должен заниматься,[85] но руководитель проекта все равно будет отвечать за то, чтобы команда программистов в процессе выполнения работ получала всю необходимую поддержку. Он может отслеживать ход процесса, проводить совещания, надоедать всем своими требованиями о выполнении принятых решений или в отдельных случаях заниматься устранением оставшихся проблем, касающихся замысла проекта[86] (рис. 14.4). Руководителю проекта, вероятно, придется действовать, опережая на несколько дней программиста, завершая подготовку замысла и «подпитывая» производственный конвейер. Если руководитель проекта отвечает за нескольких разработчиков, ему понадобится тщательнее распределять свое рабочее время, чтобы успеть справляться с запросами нескольких конвейеров (вот почему ведущий программист должен хотя бы часть этих функций взять на себя).
В книге «Web Project Management: Delivering Successful Commercial Web Sites» (Morgan Kaufmann, 2001) ее автор Эшли Фридлейн (Ashley Friedlein) назвал это краткое совещание с командой и детализацию следующей части предстоящей работы инструктажем. Он писал: «Для достижения максимальной эффективности и скорости разработки ваши инструктажи должны быть построены так, чтобы всегда опережать текущее состояние дел. Как только часть работы будет завершена, у вас должен быть наготове инструктаж, относящийся к следующей части». Эти инструктажи готовятся на основе технических условий (не утративших своей актуальности), но включают в себя все новое или измененное, о чем должны знать программисты. Без активного инструктирования программистов в ходе миттельшпиля может возникать любое количество факторов, препятствующих завершению работ и замедляющих движение конвейера; к этим факторам относятся проблемы потребительских качеств, проработка внешнего дизайна, работы, выполняемые другими программистами, проблемы рыночного характера, технические проблемы или какие-то внешние зависимости. Поскольку руководители проектов зачастую обладают самым разнообразным набором навыков, никто лучше их не справится с запуском конвейера, с частичным или полным решением проблем и со сглаживанием шероховатостей прежде, чем с ними придется иметь дело программистам. (Сюда же относят и выявление несостоятельных программистов, находящихся в состоянии ступора и либо не признающихся в этом, либо еще не разобравшихся в своем состоянии.)
Рис. 14.4. Окончательная детализация технических условий (замысла) может проверяться или завершаться параллельно руководителем проекта или проектировщиком. Это придает смысл понятию производственного конвейера по созданию программного кода
Успех этих дел определяется ответами на следующие четыре вопроса:
Какие работы находятся в стадии выполнения? Существуют ли проблемы, не позволяющие программистам завершить текущие работы? Если они существуют, их надо устранить (естественно, проблемы, а не работы). Для проекта это авральное состояние. Если программист не может активно создавать программный код, проект останавливается. Нет ничего более важного, чем решение проблемы, застопорившей работу программиста. Задайте ему простой вопрос: «Как я могу помочь тебе решить проблему?» Если вы можете помочь, программисты обязательно поставят вас в известность Если блокирующая работу проблема заключается в какой-то зависимости (например, Фрэд должен завершить работу 6, прежде чем Боб приступит к работе 7), рассмотрите возможность загрузить программиста другой работой, пока проблема не будет снята.
Обладает ли программист всеми знаниями и понятиями, необходимыми для того, чтобы текущая работа шла в русле технических условий? Всегда есть такие вопросы и пробелы, которые проявляются только в процессе выполнения работы. Способности к самостоятельному устранению таких пробелов у программистов развиты по-разному, у кого-то лучше, у кого-то хуже. Руководитель проекта или проектировщик должен быть способен сам или с чьей-нибудь помощью обнаружить и устранить эти пробелы. Иногда их можно предвидеть, к примеру, если в процессе обсуждения технических условий проблемы, касающиеся данной работы, так и остались нерешенными.
Какова следующая группа выполняемых работ? Вот тут-то и начинается настоящее управление конвейером: нужно всегда идти на шаг впереди программистов (см. рис. 14.4). Если текущие работы оформлены хорошо, нужно перенести внимание на следующие работы производственного конвейера. Эти следующие работы должны рассматриваться в качестве очередного наиболее важного этапа реализации проекта. Нужно всегда стараться сделать самую ответственную работу в первую очередь, даже если она окажется самой трудной. Для каждой ставящейся на конвейер работы нужно учесть возможность проблем, которые могут замедлить или застопорить работу программиста, когда он к ней приступит. Эти проблемы нужно выявить и разрешить.
Была ли реально завершена последняя работа? Этот вопрос касается выполненных работ. Кому-то нужно следить за результатами контрольной проверки работы и удостовериться в том, что она отвечает всем ожиданиям заказчика. Действительно ли последняя из выполненных работ наделила продукт требуемыми функциональностью и поведением? Согласна ли с этим команда тестировщиков? Прошли ли все блочные тесты? Занимается ли кто-нибудь элементарным обнаружением ошибок, чтобы отследить все упущения? Ежедневные сборки (которые будут рассмотрены в следующей главе) представляют собой простой способ отслеживания всех этих вопросов, поскольку всегда можно проверить текущее состояние проекта, обнаружить пробелы в законченном продукте и понять, что необходимо доработать. Чем сложнее работа, тем важнее становятся эти обстоятельства.
У одних программистов чувство ответственности за свой конвейер больше, у других – меньше. Многие будут тщательнее выискивать проблемы одного рода (технические) и стараться игнорировать или откладывать до поры до времени проблемы другого рода (относящиеся к бизнесу и политике). Частью ваших взаимоотношений с каждым программистом должно стать понимание, сколько сил вам нужно приложить, чтобы управлять его конвейером. Кем именно это будет сделано, не так уж и важно. Активно проверять качество работ может кто-то другой. (Это относится к назначению ролей, о чем рассказывалось в главе 9.)
Агрессивный и консервативный варианты производственного конвейера
Иногда конвейеру разработки кода нужно опережать команду программистов всего лишь на три работы (если на каждую работу требуется два дня, то на выполнение трех таких работ понадобится больше недели). Чтобы прийти к согласию по поводу следующей логической последовательности работ, вполне может хватить и свободной дискуссии между руководителем проекта и программистами. (Или, если есть главный критический путь или график Гантта, в котором отражены не только прошлые недели, конвейер можно загрузить с его помощью.) Таким образом, создается вполне достаточный по объему буфер, позволяющий программисту и руководителю проекта своевременно подобрать подходящую работу вместо той, которая застопорилась из-за той или иной не решенной своевременно проблемы, и продолжить выполнение, пока проблема не будет решена.
Команда с агрессивной позицией в выборе приоритетов может в большей степени полагаться на конвейер по разработке кода. Вместо проведения сложной структурной декомпозиции всех работ команда делает ставку на внесение изменений и на способности руководителя проекта или ведущего программиста управлять конвейером. При этом возникает весьма рискованная ситуация: если конвейер даст задний ход или не сможет быть выстроен заранее, с опережением хода работ, это приведет к принятию далеко не самых лучших решений и к ненужной потере времени. Подробную информацию о качественном проведении структурной декомпозиции работ (WBS) при планировании проекта вы найдете в книге Стивена Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999) или в любых традиционных информационных источниках, касающихся руководства проектами.
Для команд с более консервативными подходами управление конвейером представляет собой спокойное выполнение работ согласно их первоначальному перечню, созданному в процессе планирования. Конвейер может быть составлен на недели или месяцы с использованием в качестве источника первоначального плана при организации конвейера для каждого программиста. Не исключая возможности небольших поправок, ожидается, что первоначальный план останется жизнеспособным, по крайней мере, до следующей контрольной точки. С началом следующего контролируемого этапа составляется новый перечень работ как часть общего плана, и процесс повторяется. Итак, в зависимости от того, насколько коротким должен быть контролируемый рабочий этап или насколько стабильным должен быть проект, можно выполнять предварительное планирование конвейера.
Однако для конвейера способ организации – не самое главное. Альтернативные способы предлагаются чуть ли не в каждой методологии. Главное, чтобы конвейер эффективно управлялся, все необходимые работы производились должным образом и не тратилось лишнее время на выяснение того, какая работа должна выполняться следующей.
Превращение конвейера по созданию кода в конвейер по исправлению ошибок
На поздних стадиях проекта, когда завершены все работы, производственный конвейер продолжает функционировать. Изменяется характер работ: вместо программ на конвейер ставятся ошибки и дефекты, требующие исправления. В главе 15 мы еще поговорим об этом, когда будем рассматривать установку очередности – процесс принятия решений по обработке ошибок.
Отслеживание хода процесса
Простейшим табло для отслеживания хода миттельшпиля является перечень работ: пока все запланированные работы не будут завершены (с приемлемым уровнем качества), миттельшпиль не закончится (рис. 14.5). Все стратегии миттельшпиля включают определение состояния проекта, поддержание правильного курса в действиях команды и настройку проекта на успешный эндшпиль. Количество завершенных работ – наиболее существенная информация для подобного определения.
Рис. 14.5. Миттельшпиль не закончится до тех пор, пока не будут завершены все запланированные работы. Эндшпиль начнется только после их завершения. Приоритет всего, что не является показателем хода завершения работ, должен быть ниже
Я рекомендую использовать самое простое представление о состоянии проекта, один из вариантов которого показан на рис. 14.5, и выставить его на всеобщее обозрение (в крупных проектах следует показывать также процент завершения работ по разделам). Если у команды есть обычный веб– или wiki-сайт, на нем ежедневно и на видном месте нужно публиковать итоги выполнения работ. Также нужно повесить в центральном проходе большую классную доску и нарисовать на ней точно такую же диаграмму. Все еженедельные подведения итогов или крупные совещания команды должны открываться кратким обзором состояния работ всей команды. Поскольку работы могут завершиться за один-три дня, диаграмма вроде той, что изображена на рис. 14.5, должна отображать ход работ практически на ежедневной основе. Нужно приучить людей регулярно обращаться к диаграмме и отслеживать все самые последние и намечающиеся отметки о выполненных работах.
Разумеется, на диаграмме должны прослеживаться и вторичные данные, относящиеся к состоянию работы, к примеру, количество дней, оставшихся до ее завершения, количество оставшихся рабочих дней каждого задействованного в ее выполнении программиста и т. п. Но они должны отображаться не в ущерб наглядности. В миттельшпиле намного важнее предоставить команде возможность получить общее представление о ходе проекта. У отдельных программистов зачастую имеется представление о собственных локальных областях и о всех областях, с которыми им повседневно приходится соприкасаться.
Существует, конечно, немало того, что следует знать об эффективном отслеживании хода проекта. Более глубоко эта тема рассмотрена в следующей главе, в которой особое внимание уделено ошибкам и дефектам.
Работа в условиях смещения целей
Ни одна из битв не была выиграна в точном соответствии с планом, но не было и ни одной битвы, выигранной без него.
Постоянная смена направлений, в которых движется проект, стала одним из самых сильных аргументов в пользу коротких циклов и других элементов экстремального программирования (Extreme Programming, XP). Использование коротких циклов разработки позволяет проекту реагировать на существенные изменения направлений без потери предыдущих наработок, а все усилия по планированию и проектированию могли быть сосредоточены на вполне осязаемом коротком отрезке времени. Все это, по-моему, имеет глубокий смысл, поскольку дает возможность нацелиться на достижение череды краткосрочных побед. Но есть еще одна истина, о которой следует помнить: долгосрочные планы, даже самые приблизительные, облегчают внесение краткосрочных и среднесрочных изменений.
Смысл в том, что в момент изменения целей, требований или замысла, первоначальный план редко отбрасывается полностью. А все изменения делаются в соответствии с некоторой основной идеей, которой проект соответствовал до этого. Чем тщательнее разработан первоначальный план, пусть даже он носил весьма приблизительный характер, тем больше можно на него ориентироваться и тем быстрее могут быть внесены соответствующие поправки. Из этого следует, что с самого начала лучшей гарантией против непостоянства, связанного с изменениями, послужит вполне реальный план, поправки в который можно будет вносить уже в ходе реализации проекта. Вот что думает по этому поводу генерал-майор Дэн Лэйнер (Dan Laner), командующий израильскими силами обороны:
Я считаю, что сражение никогда не развивается по плану. План является лишь общей базой для внесения изменений. Очень важно, чтобы план был известен всем, тогда в него легче будет вносить изменения… современное сражение слишком изменчиво, и решения нужно принимать очень быстро, далеко не всегда сообразуясь с планом. Но, по крайней мере, все будут знать, каким было исходное состояние, и [тогда] более-менее поймут, к чему вы все ведете.
Особенность использования планов в условиях ожидаемого смещения целей состоит в том, чтобы не допускать слишком долгой работы без обновления плана. Если подобрать подходящие интервалы, смещение целей реально не отражается сразу на всем: просто наблюдается направление их движения с конкретной скоростью за определенное время. Если в проекте намечено несколько контрольных точек, или этапов (см. главу 2), они станут естественными интервалами для внесения поправок (а если на каждом этапе запланировано время на проектирование, то вы сможете вернуться к первому этапу, в который нужно внести поправки). Даже внутри трех– или шестинедельных этапов вы сможете отыскать одну-две промежуточные точки для вычисления новой траектории движения проекта относительно любых возможных изменений целей или требований. Поэтому продолжительность этапов должна соответствовать степени изменчивости проекта: чем чаще меняется его направление, тем короче должен быть этап.
На рис. 14.6 показан простой пример внесения изменений, связанных с корректировкой маршрута в направлении смещающейся цели. Проект стартовал в точке А и закончится, предположительно, в точке Б. Если через две недели после начала проекта (возможно, к завершению короткого этапа) руководители команды решат, что цели для Б изменились, направление проекта тоже должно сместиться, чтобы выровняться по точке Б. Еще через две недели будут внесены новые поправки и произойдет новая коррекция курса. Какая-то часть работ пропадет, но чем раньше будет изменено направление движения, тем меньше окажутся потери. Если перемещения совпадут с концом одного и началом другого этапа, у команды будет время, чтобы заняться проектированием, компенсирующим возникшие изменения, добавить работы, необходимые для модификации сделанного, и внести поправки в продолжительность этапов.
Рис. 14.6. Цели, требования и ограничения могут меняться, но если понятны скорость и направление этих изменений и вслед за ними предприняты соответствующие промежуточные шаги, процесс изменений будет управляемым
Даже если перемещения не совпадут с границами этапов, производственный конвейер по созданию программного кода поможет команде разработчиков придать этим промежуточным коррективам управляемый характер. Поскольку смены курса происходят на выходе из конвейера, опережая ход работ команды программистов, для происходящих изменений имеется некий буфер. Чем больше в конвейере заложено опережение по времени (рис. 14.7), тем больше объем этого буфера. Конечно, если предположить, что существует человек (руководитель проекта или ведущий программист), который уделяет достаточно времени управлению конвейером, то чтобы изменить направление, команде не обязательно полностью останавливаться. Для этого нужно, чтобы в конвейере (в его правой части) был предусмотрен достаточный объем предстоящей работы.
Рис. 14.7. В каждом плане имеется область охвата, определяющая количество допустимых изменений. Чем продуманнее план (и чем лучше в нем предусмотренывозможные изменения), тем больше область охвата
Однако тем самым предполагается, что изменения не будут радикально расходиться с первоначальным планом: в нем предусмотрен лишь вполне определенный диапазон возможных перемещений, то есть область охвата (см. рис. 14.7). Если новые требования или цели противоречат конкретному плану, нужно проводить новые серьезные проектные работы и исследования независимо от опережения, заложенного в конвейер (или, в отдельных случаях, от времени, выделенного на проектирование следующего этапа). Например, если первоначальный план предусматривал изготовление тостера, то в миттельшпиле вполне возможно скорректировать проект на изготовление духовки средних размеров, но никак не ускорителя элементарных частиц или нефтеналивного танкера.
На рис. 14.7 изображена приблизительная модель, отражающая число изменений проекта; в очерченной области представлено предусмотренное планом пространство изменений, которые команда может выдержать без новой серьезной работы. Такая же диаграмма может быть составлена на микроуровне для каждой работы. В зависимости от подходов, примененных программистом, его план будет иметь различные уровни охвата изменений требований или замысла, относящихся к данной работе.
У диаграммы, изображенной на рис. 14.7, есть одна странная, хотя и незначительная особенность. Хронологическая последовательность представлена на ней вертикально, подразумевая, что область охвата со временем может предоставить больше возможностей для передвижений, что в корне неверно. Более точным будет представление, что область охвата изменяется, расширяясь и сужаясь в зависимости от того, в какой стадии проект находится. Обычно эта область сужается по мере близости работы к завершению. Но каждое перемещение вносит коррективы в действующий план, а вместе с ним и в возможности охвата будущих перемещений.
Тайные механизмы управления
Благополучные организации, успешно работающие над проектами, планируют большинство изменений высокого уровня таким образом, чтобы они совпадали по времени с границами этапов (поскольку, опять же, протяженность этапов у них приблизительно соизмеряется со степенью изменчивости проекта или организации). Руководство проявляет терпеливость и зрелость, чтобы дождаться окончания этапа и только после этого заставить команду перестроиться и скорректировать свои действия. Но даже в таких организациях могут быть указания, предписывающие вносить изменения на ходу, без выделения времени на подготовку.
Часто такие коррекции курса вызваны не существующими решениями, а «разборками» в управленческих структурах, требованиями заказчика или результатами конкурентной борьбы. Временами вы сами вправе потребовать изменения направления, а иной раз вы просто должны дождаться чьего-нибудь решения. Так или иначе, у вас всегда должен быть наготове примерный план на тот случай, если потенциальные изменения станут реальностью. Если постоянно быть начеку, то можно заранее, за несколько дней или недель, увидеть предзнаменования грядущих перемен, еще до того как от руководства поступят серьезные решения или конкуренты изменят свой курс в верном направлении. Добыча информации, необходимой для защиты проекта от внезапных атак, зависит от сложившихся взаимоотношений и вашего искусства политика. Тогда можно будет избежать эффекта неожиданности, правда, такое удается далеко не всегда.
Используя имеющуюся информацию, старайтесь периодически выстраивать правильные предположения о возможных изменениях в направлении работ (Поддержка конкретной технологии? Новая характеристика? Новая цель?) и представлять, хотя бы в общих чертах, какие поправки потребуется внести для достижения цели. Эти представления могут быть весьма приблизительными, полученными, к примеру, в ходе разговора с ведущим программистом о том, что такие изменения моли бы повлечь за собой: «Фрэд, что нам нужно будет сделать для поддержки набора API версии 2.0 вдобавок к тем функциям, которые мы уже используем?» Ваша цель заключается не в составлении нового плана битвы, а в получении представления о том, как будет выглядеть дорога, по которой, возможно, придется идти вам и вашей команде. Еще раз просмотрите перечень работ (см. главу 13) и выясните, как в него впишется новая работа, которой, возможно, придется заняться.
Исследование влияния изменений
Если вероятность изменений возрастает, вы можете скорректировать работу в конвейере, чтобы подготовиться к ним наилучшим образом. В шахматной стратегии существуют, по крайней мере, два различных подхода к планированию ходов:
Консервативный. Ищите такие ходы, которые откроют наибольшее количество последующих ходов и сохранят возможность выбора вариантов.
Агрессивный. Целиком придерживайтесь одной стратегической линии, не вызывающей у вас сомнений, и навязывайте противнику свою игру.
При работе над проектами (как и при игре в шахматы), когда вы чувствуете превосходство над противником (например, над тайнами руководства или над конкурентами) нужно придерживаться агрессивной политики. Когда вы не чувствуете своего превосходства, лучше придерживаться консервативной политики. Нацеливание команды на консервативные действия может незначительно снизить темп работ, но такова будет цена получаемой страховки. Иногда агрессивная политика вынуждает других людей принимать определенные решения, и если вам любой ценой нужно добиться их быстрого принятия, агрессивное поведение пойдет вам на пользу, даже если ваши политические позиции будут ослаблены.
Но учтите, что рассматриваемые поправки не всегда предполагают выделение дополнительного времени на разработку программного кода. Они могут выражаться в альтернативном алгоритме, таком же надежном, но при каких-то важных обстоятельствах более гибком. Нужно задать программисту или команде простой вопрос: «Послушайте, ребята. Я подозреваю, что наш заказчик (или вице-президент) собирается заставить нас ввести поддержку совсем другой схемы использования базы данных. Просмотрите все, над чем вы работаете, и если есть разумные способы подготовиться к этим изменениям в ходе работы, займитесь их реализацией. Но не вносите ради этого существенных изменений и не жертвуйте качеством. Понятно?»
Иногда это сделать невозможно, поскольку ответ на подобный вопрос может отнять немало времени на исследования. Но бывает и так, что все оказывается намного проще. Например, программист может заранее предвидеть такое развитие событий или иметь разумные взгляды, основанные на его понимании программного кода. Подготовка команды в этом направлении может стоить вам всего лишь простого пятиминутного разговора. Может быть, более важным будет следующее обстоятельство: чем лучше вы понимаете цену возможных изменений, тем весомее будут ваши аргументы, чтобы наложить на них вето (или в подходящем случае выступить в их поддержку).
Потенциальная удаленность изменения
Также следует заметить, что чем ближе проект подходит к достижению первоначального (или последнего актуального) набора целей, тем дальше он оказывается от возможности успешной реализации любых поправок или успешного изменения направления. На рис. 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. Кто-нибудь (скажем, руководитель проекта) составляет краткое изложение сути изменения, включая его взаимосвязь с целями или требованиями проекта, обоснование и разъяснение замысла предстоящего изменения. (Поощряется также включение в документ оценки возможных рисков, связанных с воздействием изменения на проект.) Все это редко занимает больше одной-двух страниц. Для сопровождения запроса на изменение замысла, к которому прикладывается этот документ, должен быть назначен ответственный исполнитель (или все это должно быть сделано в рамках существующего метода сопровождения возникающих проблем).
2. Программист, тестировщик или любой другой специалист, на работу которого изменение окажет существенное влияние, должен внести свой вклад в краткое изложение, прилагаемое к запросу, и согласиться с тем, что необходимость изменения обоснована, а его замысел приемлем. Программист предоставляет свои расчеты по разработке, тестировщик – по тестированию (или составляет приблизительный план тестирования).
3. Запрос на изменение замысла выносится на рассмотрение небольшой группы руководителей команд (см. главу 15) или руководителя группы, который дает или не дает «добро» на изменение. Если изменение принимается, то оно рассматривается как дополнительная работа, запрос доводится до команды (а сама работа поручается соответствующему программисту). Рабочие графики и другая проектная документация должны быть обновлены с учетом произведенного изменения. Если изменение отклоняется, то запрос без сожаления выбрасывается в ближайшую урну и навсегда исчезает из проекта.
Последний шаг может быть пропущен, если команда невелика по составу и имеет четкое распределение ролей. Тогда все можно свести к встрече соответствующих людей, обсуждению мнений и принятию решения на внесение изменения. Но если изменение вводит проект в ступор, влияет на работу других программистов или требует выделения дополнительных ресурсов, к решению нужно привлекать руководителей команды.
Изменения всегда обходятся дороже, чем их оценки, проведенные программистами и тестировщиками. Они сопровождаются неожиданными побочными эффектами, воздействующими на остальных специалистов команды разработчиков, и могут отвлечь руководителя проекта от управления конвейером и от других не менее важных дел. Поскольку выработка замысла предстоящего изменения ведется в ускоренном режиме, вероятность ошибок и неудач возрастает. Не редко одно изменение влечет за собой необходимость в других изменениях. Мое обобщенное отношение к изменениям выражается в следующем: лучше использовать короткие этапы разработки с хорошо продуманным замыслом и возможностью некоторых изменений, чем запланировать рабочий график, в котором ожидается множество изменений. Чтобы не сталкиваться с запросами на изменение, люди в команде должны быть всецело настроены на разрешение всех связанных с замыслом проекта проблем уже на самой ранней стадии.
Выводы
• Миттельшпиль и эндшпиль соответствуют середине и завершению проекта.
• Если однажды работа над проектом не заладится, то определение причин случившегося и их устранение всецело ложится на вас. Повторяйте эту мысль на всем протяжении миттельшпиля.
• Проект представляет собой сложную нелинейную систему и обладает значительной инерционностью. Если выжидать обострения проблем перед тем, как предпринять какие-то меры, можно опоздать и тем самым значительно ухудшить ситуацию.
• Когда проект выходит из-под контроля, это означает, что вы начинаете бежать позади своего паровоза, что крайне нежелательно. Контроль здравомыслия – простейший способ оставаться впереди. Существуют как тактические, так и стратегические вопросы, помогающие контролировать логику действий.
• Подумайте, что можно сделать для выправления ситуации наиболее безопасным образом. Чем масштабнее эти действия и чем ближе проект к своему завершению, тем они опаснее.
• Производственный конвейер по разработке программного кода представляет собой механизм управления работами в ходе реализации проекта. Существуют агрессивные и консервативные методы управления конвейером.
• Планирование отдельных этапов и применение конвейера по разработке программного кода предоставляют возможности для безопасной коррекции курса проекта.
• Механизм контроля изменений (с использованием запросов на изменение замысла) позволяет регулировать внесение в проект изменений среднего и низкого уровня.
Упражнения
1. Если проект находится в миттельшпиле, отберите случайным образом пять человек из вашей команды и попросите их выразить в процентах, насколько они уверены в выдерживании календарного плана. Сделайте то же самое с пятью менеджерами. Сравните результаты и доведите их на совещании команды. Если такая практика окажется полезной, повторяйте этот процесс еженедельно. Чтобы добиться искренности ответов, сохраняйте анонимность всех отобранных вами людей.
2. Руководители проектов часто вынуждены бежать позади своего паровоза, поскольку не в состоянии контролировать график работ, бюджет или иные факторы, выводящие проект из-под контроля. Какие подконтрольные факторы могут помочь вернуться на авангардные позиции? Что можно сделать, чтобы проинформировать босса и команду о тех факторах, которые оказывают на вас влияние, но вышли из-под вашего контроля?
3. Когда в последний раз вы признавались, что впадали в отчаяние? Составьте список, за что вы больше всего переживаете в текущем проекте. Выберите свое самое большое опасение и поговорите с кем-нибудь о нем. Даже если вы поговорите об этом с другом за пивом, это поможет вам справиться с ситуацией.
4. Какие следующие три пункта той работы, которой вы занимаетесь, готовы для передачи кому-нибудь другому или наоборот, готовы для того, чтобы забрать их у кого-то? Что можно сделать именно с этими тремя пунктами на передачу, чтобы повысить их шансы на успешную реализацию?
5. Создайте визуальное представление вашего командного конвейера разработки программного кода по состоянию на сегодняшний день. Можно просто подойти к доске и на одной оси составить список всех программистов, а на другой проставить временные отметки. Перечислите следующие три работы, которыми, по утверждению программистов, они заняты, чтобы каждая из них заняла столько места, сколько она должна занять согласно рабочему графику. Как такая визуализация изменит ваши размышления об управлении проектом?
6. Если вас настораживают тайные механизмы управления, как можно обеспечить получение сведений о возможных изменениях на самой ранней стадии? Кого вы можете сделать своим разведчиком?
7. Многие не любят, когда следят за продвижением их работы. Какие стимулы можно предусмотреть для людей, чтобы они сами отслеживали состояние собственной работы? Почему спортсменам нравится вести статистику своих достижений, а людям, занятым в производстве, это не нравится?
8. Когда вы начинаете настаивать на официальном изменении технических требований, команда игнорирует ваши запросы и продолжает работать во вчерашнем режиме. Какой должна быть ваша реакция? Каков лучший способ перевода команды на новый режим работы?