Доверие ( сущ .) – устойчивая уверенность в честности, способности или характеристике личности.

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

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

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

 

Доверие строится на обязательности

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

Уоттс С. Хэмфри (Watts S. Humphrey) в своей книге «Managing the Software Process» (Addison Wesley, 1989) во главу угла удачного управления проектами поставил способность руководителя быть обязательным в своих делах и работать так, чтобы выполнять взятые на себя обязательства. Хэмфри настолько верит в важность этого положения, что дал строгое определение признаков действенности принятых обязательств. Вот предложенный им перечень в слегка скорректированном виде.

Признаки действенности обязательств

1. Человек, принимающий на себя обязательства, делает это по доброй воле.

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

3. Обязательства являются соглашением сторон о том, что, кем и когда будет сделано.

4. Обязательства принимаются открыто и публично.

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

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

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

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

 

Непоследовательность ведет к утрате доверия

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

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

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

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

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

 

В данной книге описываются две модели власти. Развернутую форму мы рассмотрим чуть позже, в главе 16. А здесь я остановлюсь на более простой, но действенной форме функциональной власти.

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

 

Не уповайте лишь на предоставленную вам власть

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

Однажды я столкнулся с ситуацией, поставившей меня на распутье между предоставленной и заслуженной властью. Было это во времена Internet Explorer 2.0, когда я получил свое первое назначение – пост руководителя программы по разработке серьезного программного продукта. В первый же день я был представлен двум программистам, с которыми я должен был вместе работать, Биллу и Джею. Джей вел себя приветливо, а Билл – молчаливо и угрюмо. В организации у него был очень высокий авторитет (уровень 13 на жаргоне Microsoft тех времен, выше уровня для программиста быть не могло). Я вспоминаю, что сидел в его кабинете и разглядывал его, сидящего за столом напротив. Я говорит минут десять, а он в ответ не промолвил ни слова. Он просто откинулся в кресле и уставился на меня.

Я вышел к доске в надежде, что это поможет разговорить Билла. Безрезультатно. Он бросал лишь саркастические или двусмысленные и нелицеприятные реплики, наподобие «Да неужели?» и «Ничего себе… и как вы только до такого додумались». Он просто играл со мной как кошка с полудохлой мышкой. Но я был самонадеянным 23-летним молодым человеком и понятия не имел, что мне делать, несмотря на всю мою убежденность в том, что я могу что-то из себя изобразить. Билл, со своей стороны, был закаленным ветераном, ранее прошедшим подобную процедуру с десяток раз. Я и вправду был уверен, что в его сознании проносятся лишь две мысли: «Зачем жизнь свела меня с этим парнем?» и «Какое место из всех, встречавшихся мне идиотов, он занимает, первое или второе?» Первая встреча закончилась моим бормотанием в стиле, позаимствованном прямиком из учебного видеокурса, о том, как здорово все сложилось, что мы будем работать вместе. (Уверен, этот пассаж убедил его в серьезности моих притязаний на первое место.)

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

 

Работа по приобретению заслуженной власти

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

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

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

 

Убеждение сильнее диктата

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

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

 

При необходимости покажите свою власть

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

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

 

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

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

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

 

Передача полномочий

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

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

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

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

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

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

 

Золотое правило – поступай с людьми так, как хочешь, чтобы они поступали с тобой – вполне подходит и к деятельности руководителей. Наиболее охотно выполняются те распоряжения руководителей, которым они сами неукоснительно следуют. Будучи существами социальными, мы в течение всей своей жизни изучаем манеры поведения преимущественно на основе поступков окружающих нас людей. Зачастую мы лучше учимся в процессе наблюдения за людьми, которых уважаем или чьи действия вызывают наше восхищение, а затем вольно или невольно пытаемся копировать их поведение. В интересах обретения доверия лидерам проекта следует быть примером того самого поведения, которого они добиваются или желают получить от других сотрудников. Майкл Джордан (Michael Jordan) среди прочих своих качеств создавал себе репутацию упорной работой над собой. Хотя он был самым высокооплачиваемым и наиболее известным баскетболистом NBA, немногие могли похвастаться такой же напряженной добросовестной работой. Глядя на него, игроки ниже классом отказывались от возможности отпроситься с тренировки или провести меньше времени в гимнастическом зале. Лидер задавал модель поведения, которой другие были вынуждены следовать.

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

 

Лидер сам определяет реакцию

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

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

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

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

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

 

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

Когда в дверях моего офиса появлялся виновник какой-нибудь проблемы, я обычно пытался (правда, не всегда успешно) направить свою мысль по трем направлениям:

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

2. Как мне определить характер проблемы? Можно ли вообще что-либо исправить? Каковы возможные варианты действий? Каким должно быть мое личное участие? Наверное, мне нужно дать ему все необходимые советы, но, по возможности, натолкнуть его на самостоятельное решение, как со всем этим справиться. И, конечно же, мне нужно убедиться в том, что он окончательно не потерял голову. Не стоит посылать его в бой, если вероятность гибели составляет 99 %, так руководители не поступают.

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

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

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

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

 

Никогда не рубите с плеча

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

 

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

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

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

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

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

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

 

Типовые списки приоритетов

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

Для большинства проектов используются три наиболее важных типовых списка, содержащих расставленные по приоритетам цели, характеристики и работы (рис. 13.1). Цели проекта обычно являются частью концептуального документа (см. главу 4) или вытекают из него. Списки характеристик и работ появляются в результате проектирования (см. главы 5–7). Поскольку каждый из данных перечней наследует структуру приоритетов своего предшественника, чтобы заново уточнить приоритет каждого уровня и сопоставить уровни, вызывающие сомнения, можно организовывать обсуждения. Хотя не все решается в спорах, они гарантируют, что все принятые решения действительно касаются важных вопросов.

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

Рис. 13.1. Три наиболее важных списка приоритетов

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

 

Первоочередные и все остальные приоритеты

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

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

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

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

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

 

Приоритеты – это сила

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

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

• Какую проблему мы пытаемся решить?

• Если проблем несколько, то какая из них представляет наибольшую важность?

• Как данная проблема соотносится с нашими целями или влияет на них?

• Каков простейший способ исправить ситуацию, позволяющий достичь наших целей?

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

 

Станьте генератором приоритетов

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

Но вместо мелочной опеки («Делай это. Не делай то. Не делай так. Ты что, уже сделал? Ну, и что теперь делать?») я доводил до сознания подчиненных, что моя задача – в нужный момент помочь им расставить приоритеты. Поскольку они не имели такого же широкого взгляда на проект, какой был у меня, я должен был помочь им хотя бы на какое-то мгновенье увидеть, как все, чем они занимались, соотносится с проектом в целом. Когда весь день уходит на отладку модуля или на тестирование компонента программы, весьма полезно выслушать объяснение общих положений проекта и заверения в том, что находишься на правильном пути. Порой, чтобы убедиться, что все «держат руку на пульсе», хватало и полуминутного разговора.

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

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

 

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

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

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

 

Учитесь говорить «нет» по-разному

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

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

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

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

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

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

 

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

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

Придерживаться здравого смысла и оценивать окружающую обстановку особенно важно в следующих ситуациях:

• Настраивая и побуждая людей к действию.

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

• Улаживая споры или отыскивая выходы из тупиковых ситуаций.

• Проводя переговоры с представителями других организаций или учреждений.

• Требуя дополнительные ресурсы.

• Убеждая людей в чем-нибудь.

• Разбираясь с отчетами (с персоналом).

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

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

 Насколько развито у сотрудников коллективное чувство юмора? Какие темы закрыты для шуток или вопросов? Как другие справляются деликатными (сложными, спорными) темами или решениями?

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

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

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

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

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

 

Партизанская тактика

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

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

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

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

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

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

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

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

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

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

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

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

 

Управление большими и весьма опасными объектами требует не только твердой руки. Чем больше управляемый объект и чем больше в нем людей, тем сильнее его инерционность. Новички, как в руководстве проектами, так и в управлении тяжелыми машинами (грузовиками, аэробусами, авианосцами и т. д.), недооценивают время реакции объекта на изменение положений органов управления. На рис. 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): «Если изменяется что-нибудь, влияющее на обязательства обеих сторон, об этом дается предварительное уведомление, и стороны договариваются о новых обязательствах». Вносить изменения никто не запрещает, но они должны следовать за переговорным процессом, аналогичном тому, в котором создавался первый пакет обязательств (концепция, требования, календарный план). При этом не следует готовить проекты документов или собирать расширенные совещания, но поставить людей в известность об изменении обязательств и привлечь их к процессу принятия решения о характере предстоящих изменений нужно обязательно.

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

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

 

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

Следить за слаженным функционированием конвейера входит в обязанность руководителя проекта. Программисты и сами могут управлять работой конвейера, решая, кто чем должен заниматься, но руководитель проекта все равно будет отвечать за то, чтобы команда программистов в процессе выполнения работ получала всю необходимую поддержку. Он может отслеживать ход процесса, проводить совещания, надоедать всем своими требованиями о выполнении принятых решений или в отдельных случаях заниматься устранением оставшихся проблем, касающихся замысла проекта (рис. 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): «Метод управления изменениями в проекте зависит от… масштабов и сути проекта. Как правило, чем проект крупнее и сложнее и чем жестче заданы технические условия, тем тверже нужно управлять изменениями». Если ваша команда не уделяла достаточного внимания процессу выработки технических условий, то она, скорее всего, не станет противиться и изменениям, ей просто нечем будет возразить.

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

Простейший путь управления изменениями представляет собой значительно упрощенную версию процесса выработки технических условий. NASA и Microsoft называют его запросом на изменение замысла (Design Change Request, DCR). Другие распространенные названия: запрос на изменение разработки (Engineering Change Request, ECR), заказ на изменение разработки (Engineering Change Order, ECO) или просто запрос на изменение (Change Request, CR).

В упрощенном виде все происходит следующим образом:

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

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

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

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

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

 

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

Рис. 15.2. Внутри этапов имеются ключевые даты, которые нужно отследить, наметить и наделить критериями выхода

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

В каждом этапе есть три основных перехода:

 Завершение проектирования (завершение подготовки технических условий). Команда готова к созданию программного кода изделия. Сделано все необходимое для начала реализации проекта: выработаны технические условия, созданы прототипы, составлено краткое изложение замысла. (При этом совсем не обязательно иметь окончательно выработанные технические условия, достаточно иметь в готовности лишь тот объем, который считается необходимым для начала работы, скажем, 20 или 90 %.) Работы по проектированию могут продолжаться (см. раздел «Конвейер по созданию программного кода» главы 14), что-то может переделываться и пересматриваться, но основы в необходимом объеме должны быть заложены.

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

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

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

 

Определение набора критериев выхода

Критерии выхода не должны быть слишком сложными (хотя и могут быть таковыми). Тем не менее в наборе критериев выхода должны содержаться следующие элементы:

• Перечень завершаемых работ.

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

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

• Перечень всего, что не нужно делать, даже если у кого-то сложилось иное мнение (проверка на здравый смысл).

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

Обычно критерии выхода означают, что сделано следующее:

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

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

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

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

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

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

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

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

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

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

• Достичь 80-процентных показателей потребительских качеств, относящихся к приоритетам первой очереди.

• Пройти все тесты первой очереди в автоматическом и ручном режимах.

• Пройти 80 % тестов второй очереди в автоматическом режиме.

• Классифицировать все найденные ошибки.

• Исправить все ошибки, относящиеся к приоритетам первой и второй очереди.

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

 

Почему соблюдение сроков напоминает посадку самолета

Цель промежуточных этапов не только в том, чтобы выдержать определенный срок, но и в том, чтобы настроить команду на следующий этап (или на выпуск следующего варианта). Соблюдение сроков – это не только вопрос хронологии: риск, которому подвергается надежность программного кода и выполнение следующего этапа (если таковой имеется), зависит от плавности движения к контрольной дате.

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

Угол снижения

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

Рис. 15.3. Характерный пример графика выполнения этапа с неправдоподобными допущениями

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

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

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

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

Рис. 15.4. Реализация графика зачастую расходится с планом. Как с этим справиться – целиком зависит от критериев выхода

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

Почему не срабатывает изменение угла снижения

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

 

Почему все становится хуже

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

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

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

Рис. 15.5. Самые сложные ошибки почему-то обнаруживаются и устраняются ближе к концу этапа. А это значит, что подход к конечной дате не выглядит прямолинейным – скорее это кривая линия на шкале прогресса (см. рис. 15.6)

Рис. 15.6. Обобщенная, но реалистичная диаграмма угла сближения, в которой предполагается, что работа идет с равномерным напряжением сил

 

Примерное руководство по достижению нужного угла сближения

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

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

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

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

 Не пейте Kool-Aid. Вычертить диаграмму совсем не трудно. Вы можете начертить линию где угодно, не сообразуясь с реальным положением вещей, и вполне вероятно, что вам даже удастся убедить других в том, что в форме линий, которые вы нарисовали, присутствует некая логика. Поставьте себя на место пилота нашего самолета: смогли бы вы полететь под этим углом, исходя из имеющихся у вас сведений? Подымите красный флаг; признайтесь в ошибках. Защитите свою команду от крушения при посадке. Если ваш подход излишне консервативен, то самое страшное, что может случиться, – это преждевременное завершение этапа, в то же время при слишком агрессивном подходе может произойти масса неприятностей.

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

 

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

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

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

 

Ежедневная сборка

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

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

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

Подобные тесты на качество, известные также как проверочные тесты сборки (Build-Verification Tests, BVT), должны быть включены в набор критериев завершения этапа. На ранних стадиях этапа эти критерии могут быть более мягкими, чем критерии выхода; например, вполне приемлемым может быть получение всего лишь одной «хорошей» сборки в неделю. Однако по мере приближения команды к завершению работы над какой-нибудь функцией или характеристикой критерии должны становиться все более жесткими. Ежедневные сборки и тесты на качество всегда позволят вам иметь и показатели качества, и инструменты управления его уровнем.

 

Устранение ошибок и дефектов

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

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

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

 Приоритетность. Все должно быть проще простого. Приоритет 1 – ошибка должна быть устранена; приоритет 2 – ошибка по возможности должна быть устранена; приоритет 3 – устранение ошибка желательно, но не обязательно; приоритет 4 – ошибка вряд ли будет устранена.

 Серьезность. Насколько серьезно влияние данной ошибки? Серьезность 1 – потеря данных, крах системы, проблемы безопасности; серьезность 2 – основная функция не работает так, как ожидалось (предписывалось); серьезность 3 – неосновная функция не работает так, как ожидалось (предписывалось). Серьезность отличается от приоритетности. Например, может быть серьезная ошибка сценария, приводящая к отказу в работе браузера (серьезность 1), но поскольку она проявляется лишь при семикратном наборе слова «PAPAYA!» одними заглавными буквами в поле ввода электронного адреса на странице регистрации, у нее низкий приоритет (серьезность 1, но приоритет 4).

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

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

 Область действия. Для крупных проектов ошибки должны быть классифицированы по месту их проявления (по области действия). Тогда их можно будет отслеживать не только по исполнителям, которым поручено их устранение, но и по компонентам проекта.

 Данные о том, кто обнаружил ошибку. Имя человека, обнаружившего ошибку, с указанием контактной информации.

 Статус. Ошибка может иметь только четыре состояния: активна, исправлена, решена или закрыта. Активной считается ошибка, которая еще не исправлена и требует внимания. Исправленной ошибка становится, когда программист решает, что она исправлена. Решенной ошибка становится лишь тогда, когда обнаруживший ее человек согласится с тем, что она исправлена, или с тем, что ее исправление можно отложить. Статус закрытой свидетельствует о том, что ошибки больше нет и команда тестировщиков данный факт подтвердила.

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

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

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

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

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

 

Диаграмма активности

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

Даже при наличии самой простой базы данных по учету ошибок можно опрометчиво решить, что на ее основе предельно просто составлять различные виды диаграмм и делать сложные аналитические выкладки. Не стоит слишком увлекаться, имеет смысл составить только самые основные виды диаграмм. Более сложные запросы зачастую носят отвлеченный характер («Гляньте-ка! Наш уровень исправленных ошибок соответствует уровню дождливых дней в Испании!»). Прежде чем тратить свое время впустую на выдумывание новых видов детальных отчетов, задайтесь следующими вопросами:

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

2. Как ответы на эти вопрос могут помочь нам выдержать нужные сроки или достичь нужного качества? Как эти ответы помогут нам достичь определенного критерия выхода или целей проекта?

3. Если числа растут, что это реально означает? Ухудшение? Прежнее состояние?

4. Поможет ли это в конце каждого дня (недели) понять, насколько мы приблизились к завершению?

Стремитесь к простоте

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

 Активные. Общее количество активных, то есть не исправленных или не решенных ошибок.

 Поступившие. Общее количество обнаруженных на данный момент ошибок (до классификации).

 Исправленные. Общее количество исправленных на данный момент ошибок.

Рис. 15.7. Основная диаграмма активности по устранению ошибок

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

 

Оценка тенденций

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

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

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

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

 

Полезные показатели при работе над ошибками

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

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

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

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

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

 Коэффициент ответных отказов. Вейнберг (Weinberg) называет темп рецидивов, вызванных исправлением ошибок, коэффициентом ответных отказов (Fault Feedback Ratio, FFR). Если каждая исправленная ошибка вызывает появление двух дополнительных ошибок, коэффициент FFR равен 2,0. Согласно утверждениям Вейнберга, приемлемым коэффициентом является число от 0,1 до 0,3. Если это число больше, значит, качество работы должно быть повышено (и/или снижен темп работы). Многие базы данных ошибок дают возможность связать новые ошибки с уже существующими, позволяя отслеживать показатель FFR. Но я никогда не сталкивался с автоматизацией этого процесса, все строилось на субъективных оценках тех, кто занимался классификацией в масштабе всего проекта. (Учтите, что иногда исправление одной ошибки просто вскрывает существование других ошибок. К FFR это не имеет никакого отношения.)

 

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

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

 

Аналитические совещания

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

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

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

Аналитические совещания с участием заказчиков или клиентов

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

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

 

Классификация

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

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

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

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

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

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

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

Рис. 15.8. По мере развития эндшпиля классификация все более централизуется

Ежедневная или еженедельная классификация

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

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

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

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

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

Целенаправленная классификация

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

 Низкое соотношение числа классифицированных ошибок к числу активных. Если на 500 активных ошибок приходится лишь 200 классифицированных, то невозможно узнать серьезность оставшихся 300 ошибок. Кто знает, все они могут оказаться ошибками с приоритетом первой очереди, вызывающими полный крах системы, или двойниками уже существующих ошибок. Целенаправленная классификация может иметь особую задачу по ликвидации всех неклассифицированных ошибок к определенному сроку (к завтрашнему полудню). Ели эта проблема приобрела для команды хронический характер, задачей может стать не оставить ни одной активной неклассифицированной ошибки старше определенного количества часов (например, 24 часов).

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

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

 

Военный совет

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

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

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

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

Рис. 15.9. Власть военного совета в ходе эндшпиля постепенно усиливается

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

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

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

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

 

Заключительный период разработки программного продукта – сложный и утомительный процесс. Джим МакКарти (Jim McCarthy) в книге «Dynamics of Software Development» (Microsoft Press, 1995) ссылается на него как на работу с желеобразной массой. При каждом исправлении ошибки вы как будто бы снова и снова прикасаетесь к большому кубу из желе, после чего некоторое время ожидаете, пока он перестанет трястись. Чем больше вы к нему прикасаетесь, тем больше различных вариаций его сотрясений и тем сложнее наложение колебаний, возникающих от этих сотрясений. Веб-сайт или программный продукт – это, по существу, сложнейший набор взаимосвязанных частей, и при каждом изменении одной из них вы вызываете всевозможные новые волны в его поведении. Но в отличие от желе в программном продукте не так то легко понять, когда закончатся эти сотрясения. Код не обладает прозрачностью. Понять, к чему приведет даже одно небольшое изменение, можно только после проверки качества и тщательного ручного исследования сборки.

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

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

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

 Баланс нуля ошибок. Когда количество активных и санкционированных (военным советом) к исправлению ошибок становится нулевым, говорят, что команда дошла до баланса нуля ошибок (Zero Bug Bounce, ZBB). Балансом это состояние называется потому, что как только обнаружится очередная ошибка, у команды уже не будет «нуля ошибок». Есть несколько симпатичных теорий относительно дистанции, разделяющей ZBB и текущий выпуск продукта, но ни одна из них не проработана в достаточной степени, чтобы попасть на страницы этой книги.

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

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

 

Кандидат на выпуск

Первая сборка проекта, которая отвечает всем критериям выхода, называется кандидатом на выпуск (Release Candidate, RC). Как только появится такая сборка, должен быть добавлен новый критерий выхода: какие из найденных в этой RC-сборке проблем могут стать основанием для создания второго кандидата на выпуск? Если такого критерия не существует, следует предположить, что RC-сборка прошла все проверочные тесты и тесты на качество и может быть выложена в Интернете или помещена на компакт-диск и доставлена заказчикам.

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

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

 

Процесс обкатки и связанные с ним действия

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

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

 

Проектная постпрограмма

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

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

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

 

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

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

Рис. 16.1. Личная мотивация должна соответствовать целям проекта. Чем меньше будет соответствий, тем пагубнее окажется воздействие проводимой политики

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

Рис. 16.2. Споры о власти могут возникать из альтруистических побуждений. Два равных по положению человека могут иметь элементарные разногласияпо поводу наилучшего применения властных полномочий

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

Рис. 16.3. Чем больше расхождение интересов, тем выше вероятность злоупотребления властью

 

Процессуальные причины злоупотребления властью

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

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

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

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

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

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

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

 

Мотивационные причины злоупотребления властью

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

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

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

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

 Неприязнь или месть. Я не хочу работать с Фрэдом или я пытаюсь отомстить Фрэду за то, что «он мне сделал», работая над предыдущим проектом.

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

 

Предотвращение злоупотреблений властью

Лучший способ сократить проявление негативных симптомов – применять власть, увязывая эти действия с целями проекта. Если каждый обращается к одним и тем же основным целям и выстраивает собственные цели, пользуясь единым источником (см. главу 4), то любые политические напряженности будут сведены к минимуму. Хотя в отношении средств достижения этих целей могут вестись споры, все будут бороться за достижение единых результатов. Чтобы усилить эти позиции на любой стадии проекта, каждый должен быть в состоянии открыто задать следующие вопросы:

• Каковы наши цели на данную неделю, месяц, на проект в целом?

• Существует ли какой-нибудь конфликт между общими целями и целями подгруппы? Как мы можем с ним справиться или полностью его разрешить?

• Как и кем будет приниматься это конкретное решение?

• Способствует ли способ применения ваших и моих властных полномочий для решения наших общих задач или задач команды?

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

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

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

 

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

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

 

Выясните, что вам нужно

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

• ресурсы (деньги, время, персонал);

• полномочия в принятии решений;

• возможность повлиять на решение, находящееся в чьей-то компетенции;

• корректировка чьих-то целей в поддержку ваших или приведение в соответствие с вашими целями;

• корректировка ваших собственных целей для их лучшей согласованности с целями других участников процесса;

• консультации, обмен опытом или поддержка.

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

Управление руководством

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

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

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

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

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

• На каком уровне и с какой периодичностью мне требуется ваше участие (Вообще не требуется? Ежеквартальное подведение итогов? Ежедневный доклад о состоянии дел? Еженедельные встречи с глазу на глаз? Все это требует уточнения.)

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

 

Кто обладает полномочиями на то, чтобы удовлетворить все ваши потребности?

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

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

Восприятие их точки зрения

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

Взгляните на ситуацию с его точки зрения, постарайтесь понять, насколько в его взгляды вписываются ваши потребности и цели. Свяжите ваш запрос с высокоуровневым проектным требованием или целью, с которой он обязан считаться. Поймите, что вместо того чтобы сказать: «Мне нужен другой программист», вы можете со всей ответственностью заявить: «Для достижения целей X и Y моей команде нужен другой программист. В нашем проектном плане не предусмотрены три требования, пришедшие на прошлой неделе, в результате чего наши цели теперь находятся под угрозой». Не стоит лгать или вводить человека в заблуждение. Будьте готовы к тому, чтобы пересмотреть свои потребности, если требуемым ресурсам в проекте есть лучшее применение. (Но в таком случае у вас могут спросить, какие цели и устремления должны подвергнуться корректировке в свете лучшего варианта использования этих ресурсов. «Я полагаю, что наши цели должны претерпеть изменения. Теперь цель X утратила свою актуальность. Данные ресурсы лучше направить на достижение цели Z». Мудрый начальник должен вас отметить за столь проектно-ориентированное мышление.)

К чьему мнению они прислушиваются и кому доверяют?

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

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

Иллюзия коллективной власти

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

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

 

Оценка обстановки

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

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

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

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

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

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

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

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

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

 

Тактика влияния на власть предержащих

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

Непосредственный запрос

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

Рис. 16.5. Непосредственный запрос

Неформальная беседа

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

Использование влияния (атака с флангов)

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

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

Дополнительно эти действия могут сочетаться с непосредственным запросом (как показано на рис. 16.6.). Другие возможные варианты включают способы использования требуемого вами влияния. Возможно, в присутствии Б, В и Г не возникнет необходимости или даже вообще не придется вести с А разговор по рассматриваемому вопросу. Поскольку вы пользуетесь их благоприятным мнением, можете переговорить с ними и обратиться к А со следующей фразой: «Я думаю, нам нужно исключить данную функцию. Я поговорил с Б, В и Г, и все они согласны со мной по этому вопросу». Конечно же, следует как можно точнее передать все ими сказанное и всегда стараться уладить вопрос в присутствии этих людей (намеренно возвращаясь к предыдущему разговору).

Рис. 16.6. Атака с флангов

Многоступенчатое влияние

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

Рис. 16.7. Многоступенчатое влияние

Косвенное влияние

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

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

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

Рис. 16.8. Косвенное влияние

Совещания

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

Иногда инициатива собрать совещание может быть единственным средством поднять вопрос применения властных полномочий. Электронная почта для решения сложных и острых проблем вряд ли подойдет. Поводом для совещания может стать определение, что Салли нужно одновременно услышать мнение Боба и Майка, дабы убедиться, что к вашим рекомендациям стоит прислушаться. Эффективное проведение совещаний является своего рода искусством (см. главу 10), но в данный момент нужно уяснить, что чем лучше вы подготовитесь к ответам на возможные вопросы и к предстоящим дебатам, тем легче будет вести совещание без эксцессов и в нужном для вас направлении (рис. 16.9).

Рис. 16.9. На совещании может возникнуть непредсказуемая политическая ситуация

Пускай они думают, что это их идея

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

Дополнительные источники

В предыдущий перечень попали лишь основные тактические приемы. Книгами по политической тактике забито множество книжных полок. Лучшим унифицированным средством на эту тему я считаю книгу Роберта Грина (Robert Greene) «The 48 Laws of Power» (Penguin 2001), но должен предостеречь: после прочтения книг Дейла Карнеги вроде «How to Win Friends and Influence People» (Pocket, 1990) вы почувствуете позывы применить все усвоенное на практике. Книга Роберта Сайолдини (Robert Cialdini) «Influence» (Perrenial, 1998) больше относится к маркетингу, чем к офисной политике, но некоторые изложенные в ней физиологические принципы могут быть применены и в этой сфере.

 

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

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

 

Создайте собственное игровое поле

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

Рис. 16.10. У вас всегда есть полномочия на определение собственного игрового поля

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

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

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

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