Искусство управления IT-проектами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

• Составление технических условий в корне отличается от проектирования как такового.

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

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

• Проведение обсуждения – простейший способ определения уровня технических условий и контроля их качества.

Упражнения

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

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

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

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

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

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

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

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

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

Глава 8. Как принимать хорошие решения

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

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

Я думаю, что применительно к руководству проектами ошибочные решения чаще всего принимаются не по бестолковости или неопытности, а просто из-за неправильного распределения усилий на принятие всех необходимых решений. Сначала нужно принять некое метарешение по распределению времени и сил на принятие всех остальных решений. Чтобы преуспеть в таком высокоуровневом решении, нужны опыт и готовность рассматривать все ошибки и извлекать из них уроки. (Для развития мастерства можно проделывать различные упражнения,[45] но я никогда не видел и не слышал, что их можно рассматривать в качестве основных компонентов каких-либо курсов по обучению информатике или руководству проектами.)

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

Любопытно, что при преподавании в университетах «искусства принятия решений» студенты обычно изучают методы теории полезности или анализируют дерево решений, когда вариантам выбора назначаются числовые значения, для которых выполняются вычисления (другим часто преподаваемым методом является анализ затрат и результатов). Подобные упражнения включаются во многие программы по совершенствованию управления бизнесом (Master of Business Administration, MBA[46]). Однако принятию высокоуровневых решений и анализу других практических решений за пределами учебного класса внимания уделяется мало. Методы, подобные анализу дерева решений, требуют определения общего количества элементов, что неплохо срабатывает только для решений в области финансовой деятельности, но практически неприменимо в областях проектных, стратегических и организационных решений.

Неудивительно, что из всех опрошенных мною руководителей проектов очень немногие прошли формальное обучение принятию решений, а из тех, кто обучался этому, очень немногие считали, что полученные знания являются часто востребованными. Это курьезное наблюдение согласуется с тем, что написал Гэри Клейн (Gary Klein) в своей книге «Sources of Power: How People Make Decisions» (MIT Press, 1999): «…к курсам по формальным методам принятия решений нужно относиться скептически. На них преподаются методы, которые людьми используются крайне редко». В продолжение этой мысли Клейн объяснил множество различных путей принятия решений опытными пилотами, пожарными и травматологами, показав, насколько редко они на практике применяют вычитанные из учебников формальные методы. Это не означает, что подобные методы так уж плохи, только вот в учебниках довольно редко описываются свидетельства тех, кто их применяет, или доказательства их эффективности по сравнению с другими методами.

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

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

Оценка значимости решения (что поставлено на кон)

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

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

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

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

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

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

 Каким является «окно благоприятных обстоятельств»? Затягивание принятия решения будет чревато последствиями; пути окажутся закрытыми, и вариантов не останется. Так уж сложилось в этом мире, что на принятие более важных решений не всегда отводится больше времени. Иногда приходится принимать жесткие стратегические решения быстро из-за того, что слишком сужено так называемое «окно благоприятных обстоятельств». А иногда скорость принятия решения куда важнее самого решения.[48]

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

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

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

Поиск и оценка вариантов

В уже упоминавшейся книге «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-му веку, когда он начал использоваться в качестве средства улаживания дебатов. Затем, столетия спустя, Бенджамин Франклин применил эту методику для принятия собственных решений, поэтому ее популяризацию в США предписывают именно ему.[49]

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

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

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

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

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

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

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

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

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

ПРИМЕЧАНИЕ

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

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

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

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