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

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

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

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

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

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

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

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

 

Кто отвечает за подготовку технических условий

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

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

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

 

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

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

 

Описание окончательного замысла и его реализации

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

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

 

Упрощение хороших технических условий

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

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

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

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

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

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

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

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

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

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

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

 

Гарантия верного хода процесса

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

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

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

 

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

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

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

 

Технические условия – это для одного или для многих?

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

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

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

 

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

 

Какова мера достаточности

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

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

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

 

Как справиться с открытыми проблемами

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

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

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

• Когда эта проблема должна быть решена? Кто больше всех подходит для ее решения?

• Нельзя ли как-то изолировать проблему, может быть с помощью специфического компонента или сценария? Влияет ли она на общую функциональность или на весь проект в целом?

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

• Нельзя ли вообще проигнорировать эту проблему? Как это реально повлияет на пользователя с точки зрения самого приоритетного сценария его работы?

• Можно ли разбить проблему на более мелкие, которые могут (или должны) быть поручены другим специалистам?

• Кто или что мешает решению проблемы и были ли предприняты усилия для устранения этой помехи? (Ответ может скрываться в технической или политической сфере.)

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

Устранение пробелов в технических условиях

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

Рис. 7.1. Устранение пробелов, оставшихся при проектированиии составлении технических условий

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

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

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

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

• Каковы находящиеся в стадии рассмотрения альтернативные варианты решения этой проблемы?

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

• Относится ли проблема к центральному или ключевому компоненту? Когда программист должен воплотить его в жизнь? Можно ли спроектировать компонент позже, в стадии разработки? Принадлежит ли проблема к чему-нибудь, от чего, по имеющимся прикидкам, зависит ряд других компонентов?

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

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

 

Важность завершения подготовки технических условий

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

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

СОВЕТ

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

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

 

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

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

 

Как проводить обсуждение технических условий

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

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

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

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

 

Кто должен присутствовать и как все должно происходить

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

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

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

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

 

Список вопросов

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

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

Вот мой перечень вопросов, пересмотр и дополнение которого только приветствуется.

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

• Где самые узкие места проекта? Каковы самые слабые компоненты или элементы интерфейса? Почему они не могут быть улучшены?

• В чем самые сильные стороны проекта? В чем самые слабые? В чем мы более-менее уверены? Проецируются ли сильные стороны и уверенность в успехе на наиболее важные компоненты?

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

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

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

• Какие элементы замысла, скорее всего, могут подвергнуться изменениям? Почему?

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

• В чем суть основных опасений, касающихся технических условий со стороны руководителей проекта, программистов и тестировщиков? Есть ли такие опасения относительно отдельных функций?

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

• Удалось ли нам добиться соответствия требованиям относительно доступности и локализации пользовательского интерфейса?

• Каковы угрозы безопасности данного проекта? Почему бы их не устранить? Задокументированы ли эти угрозы в технических условиях, включая потенциальные средства восстановления (например, есть ли модели угроз)?

• Располагаем ли мы достоверными доказательствами, свидетельствующими о том, что конкретные пользователи могут успешно работать с данным интерфейсом?

 

В уже упоминавшейся книге «Sources of Power: How People Make Decisions» автор определяет два основных способа принятия решений: проведение исключительной и сравнительной оценок (табл. 8.1). При проведении исключительной оценки рассматривается и оценивается по определенным критериям первый же найденный вариант (хочется ли мне сегодня надеть эту зеленую рубашку?). Если он отвечает заданным критериям, то принимается в качестве решения, и человек, отвечающий за принятие решений, переходит к более важным проблемам. Если первый найденный вариант этим критериям не отвечает, рассматривается следующая идея или вариант, и процесс повторяется (а что, если все-таки надеть желтую рубашку?). Примером может послужить поиск туалета после выпитой литровой бутылки газировки или попытка найти местечко, где можно было бы перекусить после трехдневной голодовки. В этом случае вполне достаточно найти первый же попавшийся туалет или ресторан и в поиске еще одного подобного объекта смысла уже не будет.

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

Таблица 8.1. Два основных подхода к принятию решений

Проводить исключительную оценку имеет смысл в тех ситуациях, когда совсем неважно, каким именно должно быть решение, грандиозным или просто приемлемым. Автор относит такие ситуации к зоне безразличия, поскольку человек, принимающий решение, если соблюден основной оценочный критерий, относится к основным аспектам решения абсолютно безразлично. Способность определить момент, когда все возможные варианты находятся в зоне безразличия (рис. 8.1), поможет сэкономить в работе над проектом массу времени, позволяя свернуть дебаты и дискуссии на ранней стадии и сосредоточить усилия на сложных решениях, более достойных обдумывания. Хорошие специалисты по принятию решений не тратят время понапрасну на оптимизацию тех вещей, которые в этом не нуждаются. Как сказал Тайлер Дерден (Tyler Durden): «Не стоит уделять внимание тому, что не имеет значения».

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

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

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

 

Эмоции и ясность

Хотя эта тема и не столь популярна, но без эмоциональных и психологических проблем процесс принятия решений обойтись не может. Ритчард Ристак (Richard Restak), автор книги «The Secret Life of the Brain» (Joseph Henry Press, 2001), писал: «Ничто не обходится без эмоций». Осознаем мы это или нет, но нас постоянно преследуют опасения, желания и личные побуждения. Эмоциональный компонент присутствует даже в альтруистических побуждениях, вроде пожелания всего наилучшего для проекта или для работающих над ним людей.

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

 

Простой способ сравнения

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

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

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

Рис. 8.2. Список всех аргументов «за» и «против»

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

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

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

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

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

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

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

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

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

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

ПРИМЕЧАНИЕ

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

 

Обсуждение и оценка

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

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

 

Шерлок Холмс, бритва Оккама и размышления

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

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

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

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

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

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

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

 

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

Это относится не только к решениям – как правило, нам нравится получать доказательство каких-либо утверждений именно в числовой форме. Согласитесь, насколько полезнее и правдоподобнее звучит фраза: «Наша поисковая машина на 12 % медленнее обрабатывает запросы из трех слов», чем фраза: «Система работает медленно». Числовые данные придают процессу такую степень точности, которая недоступна простому человеческому языку. Более того, числовые данные зачастую требуются людям для поддержки их утверждений. Заявление: «Система работает медленно» – влечет за собой вопрос: «Как вы об этом узнали?» Недостаток в ответе специфических понятий или результатов исследований вызывает недоверие к заявлению или ставит его в исключительную зависимость от мнения или взглядов заявителя. Порой при наличии специфической информации можно ответить на важный вопрос или принять решение намного быстрее, чем при других обстоятельствах.

 

Данные не принимают решений

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

 

Данные легко истолковать неправильно

Второе заблуждение, касающееся данных, состоит в том, что все они добываются сходным образом. Но оказывается, что при работе с числами неверно истолковать информацию совсем не трудно. Как писал Даррел Хаф (Darrell Huff) в своей книге «How to Lie with Statistics» (W. W. Norton, 1993): «Секретный язык статистики, столь привлекательный для склонной к фактам культуры человеческого мышления, используется для порождения сенсаций, раздувания фактов, их запутывания и упрощения». Хаф показывает множество простых способов манипуляции одними и теми же данными для получения совершенно противоположных аргументов. Его советы повсеместно должны лечь в основу подготовки всех, кто принимает решения. Большинство трюков строится на пропуске важных деталей или на подтасовке информации, которая ложится в основу нужного утверждения.

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

 

Исследования в качестве аргументов

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

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

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

 

Точность не значит достоверность

Как и в последнем замечании об информации и данных, многие из нас забывают, в чем различие между точностью и достоверностью. Точность характеризует качество отдельного измерения, а достоверность показывает, насколько близко к реальности оказалось это измерение. То, что нам просто предлагают точное число (скажем, работа займет 5,273 дня), еще не означает, что оно окажется достовернее неточного числа (4 или 5 дней). Мы склонны путать точность и достоверность, поскольку допускаем, что если кто-то потратил время на вычисление столь конкретного числа, анализ лишь повысит шансы на то, что его расчеты верны. Загвоздка в том, что фиктивная точность ничего не стоит. Если я возьму с потолка данные, что прибыль в следующем году составит 5,5 миллиона долларов, и таким же способом выведу сумму затрат в том же году (2,35 миллиона долларов), я могу объединить эти догадки и выдать вполне убедительный прогноз на чистую прибыль в 3,15 миллиона долларов. Точная цифра? Конечно. Достоверная? Кто знает. Не задав вопроса: «Откуда вы это узнали?» или «Как были получены эти данные?» невозможно убедиться в том, что именно отражают эти десятичные знаки, достоверность или всего лишь точность. Заведите себе привычку безжалостно искоренять склонность других за счет точности пускать вам пыль в глаза.

 

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

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

 

Некоторые решения не дают выигрышных вариантов

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

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

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

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

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

 

Хорошие решения могут давать плохие результаты

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

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

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

 

Возможно, это звучит странно, но мне понадобилось немало времени, чтобы понять, какое значение имеют разговоры с людьми на их рабочих местах. Я постоянно болтал и шутил, но не считал общение на рабочем месте реальной работой. Мой жизненный опыт вселил в меня веру в то, что я должен решать все свои проблемы самостоятельно. В первый год службы в компании Microsoft я редко просил других высказывать их мнение или искал помощи у кого-нибудь, кто обладал более широкими познаниями. Я тихо переживал эту ситуацию и больше брал усидчивостью, чем головой. В то же время мне доводилось замечать, что оба моих первых руководителя Кен Дай (Ken Dye) и Джо Бельфиор (Joe Belfiore) вели себя как-то странно и проводили массу времени в разговорах с другими людьми. Я часто видел их сидящими в офисах разных людей и непринужденно болтающими. При моей занятости я удивлялся, как они позволяли себе тратить столько времени на болтовню. Будучи новичком, я не задавал вопросов, а просто навесил на них ярлык «экстравертов», который по тем временам я считал чуть ли не оскорбительным. Меня раздражало их поведение (когда же они, наконец, начнут работать, по крайней мере, не менее напряженно, чем я?), и я не видел в их времяпрепровождении никакого толку. Как же я тогда ошибался.

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

Рис. 9.1. Свидетельство того, что программисты не столь одиноки, как мы думаем

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

 

Взаимоотношения улучшают общение

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

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

В классическом труде Тома Петерса (Tom Peters) и Нэнси Остин (Nancy Austin) «A Passion for Excellence» (Warner Business Books, 1985) подобный стиль поведения назван руководством методом обхода (Management by Walking Around, MBWA). Он описан как основное качество удачливых руководителей, за которыми они наблюдали (методу MBWA посвящена целая глава их книги). Но правильно следовать этому стилю не так-то просто. Они рекомендуют выбрать для себя небольшую группу людей, у которых в команде разные роли и задачи, и заняться выстраиванием с ними неформальных взаимоотношений. Но еще важнее, что от вас потребуется понимание механизма здорового общения и хороших взаимоотношений, а также стремление к постоянному совершенствованию своих навыков в этом деле. Даже если вы не станете придерживаться для выстраивания взаимоотношений подходов MBWA, навыки общения и построения межличностных отношений пригодятся в любом деле.

 

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

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

 

Распределение ролей

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

Как заставить людей работать лучше

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

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

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

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

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

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

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

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

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

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

 

Мотивация

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

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

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

• Повышает качество создаваемого продукта.

• Увеличивает шансы на своевременное завершение работы над проектом.

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

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

• Освобождает людей от напрасной работы, защищает их от бестолковой политики или бюрократии.

• Позволяет упростить поддержку разработки.

• Повышает настроение или создает ощущение подъема у членов команды.

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

Формула хорошего процесса

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

Сначала рассмотрим стоимость процесса: время на выработку замысла процесса (DT), время на его освоение командой (LT), фактическое время выполнения работы при применении процесса, помноженное на частоту его применения (AT × N). Полная стоимость любого процесса равна:

DT + LT + ( AT × N ).

Теперь рассмотрим суммарную выгоду, получаемую от процесса: стоимость провалов, которых процесс позволит избежать (FC), помноженную на показатель вероятности возникновения этих провалов (FP) без внедрения процесса в пределах определенных временных единиц, и все это помноженное на количество таких временных единиц в проекте (T). Полная суммарная выгода равна

( FC × FP ) × T .

Таким образом, ценность процесса приблизительно равна:

(( FC × FP ) × T ) – ( DT + LT + ( AT × N )).

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

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

Кроме этого, вам следует оценить время действия выгод: зачастую оно может превышать время работы над отдельным проектом. Что еще более важно, вероятность провала в некоторых следующих проектах может возрасти до 100 %. Значение T имеет для формулы весьма важное значение: даже если вероятность провала (FP) низка, то чем продолжительнее временной интервал, тем больше шансов возникновения провала и тем больше возрастает ценность процесса, который его предотвращает. (Тем самым раскрывается еще одна основная сложность роли лидера: нужно решать, когда нести существенные краткосрочные затраты в расчете на менее существенную, но долгосрочную компенсацию. Она проявляется повсеместно: при найме работников, закупке оборудования и аппаратуры, обучении сотрудников и т. д. Что посеешь, то и пожнешь. Долгосрочные инвестиции являются единственным способом получения долгосрочных же улучшений.)

И последнее замечание по формуле: значение AT (фактическое время выполнения работы при применении процесса) намного важнее, чем это может показаться на первый взгляд. Удачный процесс может сократить время работы: если на самом деле происходит экономия времени, то при сравнении AT со временем, затрачиваемым на работу без применения процесса, будет получаться отрицательное число. В соответствии с формулой это изменит соотношение выгод и потерь. Например, если AT = 5 часов, но ранее на выполнение работы требовалось 7, то разница составит 2 часа. То есть на выполнение работы теперь понадобится на 2 часа меньше, и итоговая ценность процедуры значительно возрастет.

 

Как создавать и запускать процессы

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

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

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

 

Управление процессом снизу

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

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

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

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

 

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

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

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

 

Толковые электронные сообщения

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

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

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

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

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

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

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

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

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

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

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

 

Пример неудачного электронного сообщения

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

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

От : Джек Колоно.

Заранее благодарен,

Кому : Ведущему команды разработчиков.

Джек.

Тема : Резюме недавних дискуссий, связанных с разработкой проверочных процедур.

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

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

1. Проверки крайне важны. Они дают возможность определить, что нами реально создано.

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

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

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

 

Пример хорошего электронного сообщения

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

От : Джек Колоно.

Заранее благодарен,

Кому : Ведущему команды разработчиков.

Джек.

Тема : Новый проверочный процесс.

Окончательное предложение по новому проверочному процессу составлено и находится по адресу http://intman/proc/checkin/.

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

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

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

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

 

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

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

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

 

Искусство содействия

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

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

Содействие ( гл .) – действия, направленные на упрощение или облегчение какого-нибудь процесса.

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

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

 

Несколько советов относительно содействия

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

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

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

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

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

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

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

 

Три разновидности совещаний

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

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

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

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

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

 

Вред регулярных совещаний

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

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

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

 

Несколько советов относительно ведения совещаний

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

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

 Сидя или стоя. Один из приемов, позволяющих не затягивать совещание, – провести его стоя (например, собраться в холле или на свежем воздухе). Теоретически это заставит людей работать по существу и подымать вопросы, имеющие реальную ценность для обсуждения в составе группы. Такое совещание должно продлиться максимум минут 5–10. SCRUM предписывает постоянные ежедневные совещания для выяснения состояния процесса. На таком совещании задаются лишь три вопроса: Что сделано со времени предыдущего совещания? Что вам мешает? Что вы сделаете к завтрашнему совещанию? С такими бескомпромиссными обязательствами будет обеспечено присутствие на совещании даже самого капризного разработчика. Традиционные сидячие совещания нужно оставить для более мелких групп. Стоит хотя бы попробовать провести такое совещание в качестве эксперимента: при прочих равных условиях это вынудит людей принять во внимание, что совещанию, запланированному на один час, на самом деле столько времени не понадобится.

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

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

 Пунктуальность. Это понятие относится к стилю поведения, присущему высшему начальству. Если вице-президент имеет склонность к опозданиям, опаздывать будут и все остальные. Если же начальник пунктуален, все остальные тоже постараются ему соответствовать. Вы могли бы взять в привычку начинать совещания вовремя, но если на совещании отсутствуют важные персоны, при их появлении вам придется прерываться и повторять сказанное. Однако если опаздывающий – человек, равный вам по положению или ожидаемый вами докладчик, попробуйте подшутить над ним. Мой любимый прием – позвонить каждому опаздывающему в офис. Если он все еще там, слегка посмейтесь над ним по телефону, чтобы слышали все остальные: «Привет, Сэм. Мы сочли бы за честь видеть тебя в аудитории номер 5». Если его там нет, оставьте ему сообщение на автоответчике. Вызовите его по селектору и пусть все присутствующие в аудитории скажут в унисон: «Мы любим тебя, Сэм!» или пропоют ему Happy Birthday. Проделывайте это на каждом совещании с теми, кто опаздывает или приходит последним. Таким образом, вы начнете совещание со смешной нотки, а опоздавшие получат дополнительную мотивацию, чтобы прибывать вовремя.

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

 

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

Моя первая по-настоящему трудная ситуация возникла в 1996 году, когда я работал над функциями родительского контроля в IE 3.0. Мы обеспечивали поддержку стандартов W3C в системе родительского контроля, пытаясь создать первый веб-браузер, «умеющий» делать что-либо существенное для того, чтобы Интернет был более «безопасным». Я считал, что проект успешно продвигается, пока не состоялось первое обзорное совещание. Из десяти присутствующих девять были настолько разочарованы моими ответами на их вопросы, что даже не дослушали их до конца, и совещание приобрело неуправляемый характер. Все они были опытными разработчиками и создателями программных систем, и их вопросы были куда лучше моих ответов. Все казалось неправильным: люди кричали, а моя команда была деморализована. Через десять минут после начала совещания я понял, что произошла катастрофа. На двенадцатой минуте мне захотелось провалиться сквозь землю. К концу часа я едва мог оторвать взгляд от пола.

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

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

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

 

Как понять, что вы попали в сложную ситуацию

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

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

2. Возникла неразбериха в отношении масштабов отставания, его причин, того кто должен его ликвидировать; непонятно также, существует ли оно вообще. («Какой айсберг? Не вижу никакого айсберга».)

3. Непонятно, как подключить дополнительные ресурсы, чтобы устранить отставание. Могут возникнуть опасения, что принятие каких-нибудь мер или бездействие только ухудшит ситуацию. («Не стойте на месте, делайте же что-нибудь! Хотя нет, подождите… не делайте ничего, оставьте все как есть!»)

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

 

Перечень сложных ситуаций

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

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

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

 Срыв рабочего графика или нехватка ресурсов. Когда вероятность выполнения намеченного к следующей контрольной дате объема работ падает ниже 75 %, вера в успех теряется. Удачный исход возможен, но маловероятен. Возможная реакция: обратитесь к главам 2 и 14. Там вы найдете описание критериев выхода из подобных ситуаций и их возможную расстановку по приоритетам. Вам нужно либо урезать функциональность и добавить время к рабочему графику, либо проигнорировать всю доступную вашему пониманию логику развития событий, отписать завещание и все-таки попытаться любыми средствами выдержать сроки. Попробуйте прикинуть, нельзя ли каким-то образом изолировать риск срыва рабочего графика и убрать проблемный пункт с критического пути. А нельзя ли его обменять на что-нибудь менее важное из предстоящего этапа работы. Закон Брука (Brook) гласит, что привлечение дополнительной рабочей силы при угрозе срыва сроков может не оправдать ваших ожиданий.

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

 Смена направления. Руководство или складывающаяся рыночная ситуация может потребовать изменений. Для проекта в этом может и не быть ничего плохого (можно даже рассчитывать на некий прогресс), но и радоваться тут, пожалуй, особо нечему. В смену направления могут вмешаться бюджетные сокращения или новые общие цели. Возможная реакция: нужно выяснить, нельзя ли ограничиться изменениями отдельных компонентов? Выделите те технические условия или их части, которые все еще жизнеспособны, и сохраните их в конвейере разработки (см. главу 14), затем расположите по приоритетам все, что требуется изменить. Убедитесь в том, что вы не попадаете в сферу действия безапелляционного приказа; ведь сказать: «Сделайте X» – не одно и то же, что сказать: «Мы должны увеличить доход на 10 %». Первое является директивой, второе – решаемой проблемой. Добейтесь выяснения сути проблем и вмешайтесь в процесс, предлагая приемлемые для себя решения (см. далее раздел «Разрешение конфликтов и ведение переговоров»).

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

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

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

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

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

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

 

Практикуйтесь в преодолении трудностей

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

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

В отношении других сложных ситуаций можно сказать следующее: способов преодоления возможных проблем великое множество. Если вы хотите изучить их расширенный список, то лучший, из всех мне встречавшихся источников находится в главе 3 книги Стива Мак-Коннела (McConnell) «Rapid Development» (Microsoft Press, 1996). Вторым по ценности можно назвать бессистемный каталог , который в настоящее время является наиболее интересным и колоритным чтивом, правда, его труднее применить на деле и он не всегда отличается хорошим языком (что не удивительно, поскольку он относится к Вики-системам).

 

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

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

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

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

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

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

 

Все должны знать, кто принимает решения

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

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

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

 

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

 

Работа под давлением обстоятельств

Наиболее подходящим из найденных мной определений слову «давление» является следующее:

Давление ( гл. ) – принуждение, вынуждающее влияние или сила.

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

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

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

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

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

Естественное и искусственное давление

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

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

Рис. 11.1. Четыре разновидности давления

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

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

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

Давайте оставим в покое формулировки, чтобы понять, что у команды существует предел, при достижении которого она вообще перестает воспринимать какое-либо давление. На рис. 11.2 показана диаграмма, позаимствованная из первого тома «Systems Thinking» книги Джеральда Вейнберга (Gerald Weinberg) «Quality Software Management» (Dorset House, 1996). На ней показана кривая производительности труда команды, работающей под давлением. Некоторое время при повышении степени давления большинство людей и команд показывают рост производительности, но через какое-то время рост прекращается, а затем и вовсе начинается падение. Когда команда достигает максимального уровня производительности (известного также как красная черта, или порог производительности), никакое дополнительное давление не заставит команду работать усерднее, лучше или быстрее. Если продолжать давить дальше, в конечном итоге команда (или человек) «сломается», и дела пойдут намного хуже.

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

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

 

Чувства от чувств

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

Ладно, я был к вам несправедлив, но ведь сработало. В качестве компенсации позвольте преподнести вам драгоценный самородок из разряда описаний человеческого поведения. Вирджина Сатир (Virgina Satir), автор ряда книг по психологии и человеческому поведению, разработала простую модель, помогающую объяснить, почему люди иногда столь непредсказуемы. Попросту говоря, когда мы что-нибудь чувствуем (скажем, огорчение или обиду), у нас сразу же возникает какое-нибудь вторичное чувство о чувстве первичном, и именно это вторичное чувство и является побуждением к действию. Пусть, к примеру, я говорю вам, что от вас забавно пахнет. Тем самым я могу вас расстроить. Но то, что я вас расстроил, скорее всего, заставит вас разозлиться. Итак, вместо того чтобы продемонстрировать чувство досады, вы сможете выразить лишь вторичное чувство злости (простой пример такой ситуации показан на рис. 11.3). Чуть позже вы, наверное, сможете разобраться, что первичным было чувство досады, но буквально через миг все ваши чувства выражаются в ответной реакции на другие чувства.

В первом томе «Systems Thinking» книги «Quality Software Management» Вейнберг пошел еще дальше и объяснил, что у модели Сатир есть другое полезное следствие. Зачастую причиной вторичного чувства является вера в то, что нам преподавали, которая не совместима со здоровым эмоциональным поведением. Чувство злости, вызванное чувством досады, является не общим, а благоприобретенным поведением. На самом деле, согласно Вейнбергу, наши ответы на многие эмоции просто соответствуют тем проявлениям, которые сложились в процессе нашего собственного эмоционального развития.

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

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

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

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

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

Другие заметные писатели на тему человеческих эмоций, такие как Лео Ф. Баскалья (Leo F. Buscaglia) или Джон Брэдшоу (John Bradshaw), пришли к выводу, что чем крепче психическое здоровье и выше эмоциональная зрелость человека, тем глубже он осознает собственное эмоциональное состояние и состояние других людей, располагая более широким спектром возможностей реагирования на их эмоции. А это значит, что лидер, способный распознать эмоциональную модель поведения и воспользоваться различными способами управления ситуацией, получает больше шансов на успех.

 

Комплекс героя

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

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

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

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

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

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

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

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

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

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

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