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

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

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

О восхождении на высокие горы.

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

Рассмотрим некоторые детали подробнее.

Уяснение объема задач как первый шаг планирования.

В обоих видах деятельности хорошо выполненное планирование увеличивает шансы на успех. Первым шагом хорошего планирования является уяснение объема задач. Если речь идет о восхождении на гору, на этом этапе оценивается ее высота, относительная сложность местности, особые погодные условия и т. д. Едва ли можно себе представить, что в ответ на вопрос о высоте горы, на которую хотят подняться альпинисты, они ответят: «Когда заберемся, тогда и будет ясно!» Точно так же команда разработчиков должна представлять себе объем работы, за которую они берутся: насколько велика эта гора? Сколько понадобится строк кода, драйверов специальных устройств, необычных интерфейсов пользователя, какие нужны характеристики производительности? Ни сама бригада, ни ее руководители никогда не смогут предвидеть все трудности, но самые заметные характеристики задачи должны быть определены и зафиксированы, чтобы учесть их при последующем планировании.

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

Отбор участников.

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

Есть один фактор, который более всего способствует снижению риска, это опыт. Чем больше вы найдете людей, которые уже забирались на горы такого типа, тем лучше для вас. Альпинисты, побывавшие на вершинах многих гор, в большей мере обладают здравым смыслом, исходя чисто из дарвинистского подхода! Это называют «алгоритмом выбора проводника на Аляске»: если есть выбор, остановитесь на том проводнике, который дольше всех занимается своим делом. У старых моряков есть поговорка: «отличный моряк благодаря своему отличному здравому смыслу избегает таких ситуаций, в которых ему понадобится его отличное мастерство». То же можно сказать об альпинистах и менеджерах программных разработок. Лучше призвать на помощь смекалку, чтобы избежать трудностей, чем справляться с ними ценой героических усилий. Самым простым признаком наличия здравого смысла является опыт. Ищите тех, кто уже делал это раньше и успешно. При прочих равных берите тех, кто благополучно пережил восхождение на крутую гору, а не тех, кто никуда не поднимался.

Вы можете себе представить восхождение на Эверест без шерпов?.

Организация команды.

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

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

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

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

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

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

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

• Недостаток ресурсов.

• Излишек ресурсов.

• Неправильно выбранный тип ресурсов, а значит, подъем бесполезного груза.

Если восхождение совершают 10 человек за четыре дня, то нужен один тип ресурсов, а если это 15 человек и две недели, то положение совершенно иное.

Чтобы решить эту задачу, необходимо знать следующее:.

• Маршрут движения.

• Места промежуточных привалов.

• Примерное время выхода в место привала с заданным количеством людей.

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

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

Верстовые столбы или аршинные колышки?.

Итак, я сторонник приблизительного восходящего планирования при общем согласии команды относительно времени прохождения основных контрольных точек. И я считаю, что очень важно контролировать время фактического их прохождения. При этом контрольные точки не должны быть слишком близки или, наоборот, слишком разнесены. Если восхождение рассчитано на 1-2 дня, то контрольные точки обычно отстоят одна от другой на несколько часов. При восхождении в Гималаях важные контрольные точки должны, по моему мнению, отстоять на дни. Для программного проекта продолжительностью от 18 до 24 месяцев правильным кажется выбор контрольных точек с промежутком в 3-4 месяца. Это соответствует примерно шести или около того контрольным точкам на весь проект. Если избран итеративный подход к разработке, то в порядке вещей иметь около шести «контрольных точек», даже если итераций больше. Например, двухгодичный проект может иметь 10 итераций, но только шесть из них потребуют самого тщательного контроля руководства по своем завершении.

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

Контроль и учет.

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

Учет рисков.

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

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

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

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

Решительность.

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

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

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

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

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

Общая цель.

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

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

Смотреть дальше.

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

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

Конкуренция может быть причиной неразумного поведения.

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

Обычные причины провалов.

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

• Попытка слишком быстро взойти на вершину.

Аналог: Нереалистичный график работ.

• Попытка взойти на вершину с явно недостаточными ресурсами. Аналог: Недостаток хороших работников или инструментов.

• Чрезмерная численность команды; трудности материально-технического обеспечения и коммуникаций оказываются непосильными. Аналог: Слишком много посредственных разработчиков по отношению к первоклассным разработчикам.

• Затягивание экспедиции; команды, слишком долго остающиеся в горах, теряют живость, энергию и устремленность; усталость берет верх. Кроме того, может просто не хватить ресурсов.

Аналог: Никогда не завершающиеся программные проекты; они длятся так долго, что техническое задание меняется, иногда многократно.

• Движение по неверному маршруту, несмотря на новую информацию.

Аналог: Игнорирование результатов первых итераций. Отсутствие корректировки планов в ходе проекта.

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

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

• Неспособность действовать согласно плану в пределах допустимых отклонений.

Комментарий: Иногда оказывается суммарным эффектом многочисленных мелких неудач, а не одного крупного провала.

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

Комментарий: Одинаково плохо и в конторе, и в горах.

• Отсутствие резервов для критических ситуаций.

Комментарий: Обычно в некоторой мере такой резерв обеспечивается опытными участниками: они знают, как действовать в случае неожиданностей.

Составляющие успеха.

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

• Успешные команды успешно осуществляют планирование, а не одержимы им.

Комментарий: Небольшой, но толковый план всегда лучше, чем обилие деталей.

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

Аналог: Завершите работу прежде, чем изменятся технические требования.

• Талант оценивать поступающие данные в реальном времени и вносить в план должные изменения в должное время.

Аналог: Использовать итеративную разработку, собирать систему на ранних этапах и часто и корректировать план на основе этих данных.

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

Комментарий: Необходимо равновесие и общее умонастроение.

• Сверка с разумно подробным планом.

Комментарий: Необходимо обнаруживать наступление неприятностей и знать, какие принимать меры.

• Лидеры демонстрируют зрелость и здравомыслие.

Комментарий: Необходимо знать, когда натянуть вожжи, а когда их ослабить.

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

Аналог: Интересно было бы узнать, какова статистика для руководителей программных проектов.

• Стойкость: способность приложить все силы в трудных обстоятельствах.

Аналог: Существенно, например, при поиске трудно обнаружимой ошибки в программе.

• Сосредоточенность: команда не теряет из виду четко обозначенную цель.

Комментарий: Все участники знают что, зачем, когда и где.

• Творческий подход: готовность к экспериментированию и способность получать искреннее удовольствие от своей работы. Комментарий: Как и везде в жизни.

Человеческий фактор.

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

Резюме.

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

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

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