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

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

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

Вторая, более коварная, причина срыва графиков состоит в том, что отставание происходит медленно и постепенно. Фредерик Брукс давнымдавно отметил, что отставание проекта на год состоит из задержек на один день. Если первую контрольную точку вы пройдете с опозданием на неделю или две, то скорее всего вы уже никогда не наверстаете упущенное, и все последующие точки пройдете с таким же или еще большим опозданием. Это та пресловутая смерть от разрезания на тысячу кусков, и даже при самом усердном управлении ее трудно избежать. Но если вы, менеджер программного проекта, еще и ослабите внимание, то пеняйте на себя!.

Роско формулирует задачу: насколько вы опоздаете?.

Мы уже знакомы с Роско Леруа,

бывшим горным инженером, старым и сварливым. Был унылый дождливый день, когда он остановил свой пикап у моего дома и побежал к входной двери, хлопая на ветру дождевиком. «Вот и солнце всходит», - подумал я.

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

он помог не одному техническому менеджеру спасти свою шкуру.

- Ну, - начал я, - как продвигается новая карьера в управлении программными разработками?.

«Так, похоже, что мы друг друга не понимаем»

, - заговорил Роско. После такого начала у меня перед глазами возникли солнечные очки дорожного босса из «Хладнокровного Люка». Хотелось бы, чтобы конец был не таким, как в кино.

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

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

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

Джо отчасти возвращает свои позиции.

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

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

«Я тебя понял, сынок, - ответствовал Роско. - Но вот что я скажу. Эти оценки по ходу дела могли бы становиться более точными. По двум причинам. Во-первых, во время работы ты должен чему-то научиться и поумнеть, а, во-вторых, оставшихся дел становится все меньше и меньше. В начале у тебя куча неопределенностей и масса дел. Зато больше времени, чтобы успеть исправить ошибки. Тут мне надо еще немного подумать».

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

Роско возвращается.

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

На этот раз Роско был гораздо спокойнее.

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

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

Непостижимо. Опять квадратный корень? Возможно ли? У него что никаких трюков не осталось в запасе?.

-На самом деле тут есть пять разных случаев, - сообщил он далее. Я разобрался со всеми.

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

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

улыбнутся ему и т. д., и закончит он раньше. Может быть, даже на квадратный корень раньше. Бывает.

Я вспомнил, как был смущен, когда в последнюю нашу беседу не смог привести таких примеров.

- Это все хорошие случаи, - добавил он.

Список негодяев по Роско.

Но есть еще 75%. Они составляют три других случая.

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

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

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

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

График Роско.

После этого Роско гордо извлек диаграмму, показанную на рис. 11.1. Он был горд, что смог воспользоваться своей новой игрушкой - Microsoft Excel. «Хороших парней я пометил «очень хорошо» и «отлично». Задержки от одного до двух квадратных корней я пометил «нуждается в помощи». Два других патологических случая тоже ясно помечены».

«Вот оно. Граница между «очень хорошо» и «отлично» есть «вовремя». Все, что понадобилось, это один лист бумаги».

И Роско откинулся на стуле, как бы завершив излагать свои доводы.

Рис. 11.1. Командование проектами.

Последнее возражение.

«Что ж, Роско, - отвечал я, - ты, как всегда, разобрался в сути. Мне понравился твой количественный подход к прогнозированию задержки. Но в твоей теории есть одно упущение».

Роско немедленно встрепенулся. Он любит, когда ему бросают вызов.

«Вот незадача: как я узнаю, к какой категории относится мой менеджер проекта? Если я знаю, что он ас в этом деле, то все в порядке. Но если я никогда не работал с ним раньше?».

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

Тут я сострил по поводу огрызка его карандаша, о чем тут же пожалел.

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

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

«Так вот, насчет программного обеспечения: я постараюсь привлечь их к нескольким подпроектам и заданиям разной длительности. Разумеется, вначале каждой итерации итеративного проекта необходимо оценить срок. И каждую оценку я записываю. А потом я смотрю, какого результата они добились».

«В результате я получаю кучу точек на своем графике прогнозов и фактических результатов. Кое-кто уверенно попадает в одну и ту же зону. Замечательно. Они прошли калибровку».

«Результаты других размазаны по всему полю. Я бы на твоем месте сел с ними и попытался разобраться. Либо через некоторое время они станут предсказуемыми, либо придется послать их подальше. И ты сам знаешь, что делать с категориями перестраховщиков и «больше двух квадратных корней». Только следи, чтобы дверь не хлопнула их по заднице, когда они будут выходить».

«Это средство весьма полезно для тех, кто попадает в зону «требуется помощь». Необходимо показать им, что они должны делать, чтобы мы стали зарабатывать деньги благодаря им, а не терять их. Это поставит перед ними цель, к которой надо стремиться. Они должны научиться не выходить за пределы одного квадратного корня, какой бы ни была их оценка срока».

«Видишь ли, Джо, - сказал он, сев поудобнее и улыбаясь, - мне не так важен результат, как его предсказуемость. Меня устроит задержка на один квадратный корень, лишь бы я знал, что это мои максимальные потери. Тогда я справлюсь».

Что бы я ни придумал, разделает меня под орех.

Заключительный выстрел Роско.

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

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

«Поэтому мы и говорим о «переходе к коротким ударам».

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

Я очень надеюсь, что Роско не бросит свою новую карьеру. Он должен еще многому научить нас.

Резюме.

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

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

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

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

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