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

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

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

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

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

Разработка по частям (беспроектный проект)

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

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

 

Разделяй и властвуй (большие планы равны множеству мелких)

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

Там, где проекты усложняются из-за своей объемности или продолжительности, календарные планы делятся на части, каждая из которых имеет собственные периоды проектирования, разработки и тестирования. В экстремальном программировании (Extreme Programming, XP) такие части называются итерациями, в спиральной модели – фазами, а в некоторых организациях их называют этапами. Хотя в XP считается, что эти отрезки времени занимают всего несколько недель, а в спиральной модели счет идет на месяцы, в них заложена одна и та же фундаментальная идея: создание подробных календарных планов для ограниченных периодов времени.

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

Гибкий и традиционный методы

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

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

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

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

Рис. 2.2. Большой проект должен представлять собой последовательность более мелких проектов

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

 

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

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

 

Выстрел вслепую издалека

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

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

Барри Боэм (Barry Boehm) в 1988 году в своем эссе на тему разработки программных продуктов писал, что ошибки тем масштабнее, чем раньше при реализации проекта делались расчеты для календарного плана (рис. 2.3). Если все расчеты делались на ранней стадии, отклонения могут составлять до 400 % в обоих направлениях (подозреваю, что ошибки всегда работают против нас, стремясь отнять больше времени, чем мы ожидаем, хотя Боэм в своих данных этого не показал). В период проектирования по мере конкретизации решений расхождение сокращается, но остается еще весьма значительным. И только когда проект достигает стадии реализации, диапазон расчетов календарного плана приобретает разумные очертания, но даже тогда остается 20-процентный разброс вероятности планирования.

Рис. 2.3. Диапазон возможных отклонений от расчетных сроков в процессе реализации проекта (заимствовано из книги Боэма «Software Engineering Economics»)

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

 

Календарный план – это оценка вероятности

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

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

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

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

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

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

 

Расчет – дело тонкое

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

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

Весь мир держится на расчетах

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

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

 

Качественное проектирование – залог хороших расчетов

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

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

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

Вот несколько дополнительных советов, позволяющих добиться качественных расчетов:

 Установите базовые показатели доверия расчетам. Предположение – 40 % доверия, качественный расчет – 70 %, подробный и полный анализ – 90 %. Руководители команд должны прийти к соглашению, насколько точными должны быть расчеты, сколько времени отвести программистам для их проведения и как управлять риском неверных расчетов. Не заостряйте внимание на цифрах: пользуйтесь ими лишь для конкретизации качества расчетов. Расчет с 90-процентным доверием должен означать, что сроки выдерживаются в 9 случаях из 10. Если вы решите обратиться к команде с просьбой поднять качество расчетов, то должны подкрепить свою просьбу выделением дополнительного времени.

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

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

 Расчеты зависят от понимания программистами целей проекта. Расчеты основываются на программистской интерпретации не только проектировочных спецификаций (если таковые имеются), но также целей и параметров, заложенных в проект. Джеральд Вейнберг (Gerald Weinberg) в книге «The Psychology of Computer Programming» (Dorset House, 1971) отмечал прямое влияние недостаточно четко поставленных целей высокого уровня на низкоуровневые предположения, допускаемые программистами. Какой бы понятной ни была бы технологическая проблема, подходы программистов к ее решению могут в корне меняться в зависимости от общего замысла всего проекта.

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

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

 Существуют известные методы улучшения качества расчетов. Наиболее известным является метод PERT (Program Evaluation and Review Technique – метод оценки и пересмотра планов), в котором предпринимается попытка минимизировать риски путем вычисления усредненной величины из результатов лучшего, среднего и худшего расчетов. Этот метод хорош по двум причинам. Во-первых, всем дается понять, что расчеты сродни прогнозам, отражающим диапазон возможных результатов. Во-вторых, руководителям проектов дается возможность отрегулировать агрессивность или консервативность календарных планов (больший вес может придаваться низким или высоким оценкам).

 

Элементарные просчеты

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

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

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

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

• Допущены ли сотрудники к календарному плану и вменялось ли им (в мягкой форме) в обязанность регулярно отчитываться за проделанную работу?

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

• Чувствует ли команда причастность к календарному плану и ответственность за его выполнение? Если нет, то почему? Внесла ли команда свой вклад в составление календарного плана и в определение объема работ или все это было спущено им сверху?

• Чего больше было в действиях руководства командой, добавления требований по характеристикам продукта или помощи в их исключении? Говорили ли когда-нибудь руководители команды решительное нет новым объемам работ и предоставляли ли они своей команде разумную философию реагирования на новые (запоздавшие) требования?

• Находили ли сотрудники поощрение и поддержку, если говорили нет новым требованиям, если те шли вразрез с их целями и представлениями?

• Какая вероятность была заложена в расчеты? 90 %? 70 %? 50 %? Нашла ли она отражение в главном календарном плане высокого уровня? Был ли клиент, вице-президент или заказчик уведомлен об этом? Обсуждалось ли другое предложение, более затратное по времени, но имеющее более высокую вероятность соблюдения сроков?

• Имели ли место периодические согласования и пересмотры календарного плана со стороны руководителей команд и руководителей проекта?

• Учтено ли в календарном плане сокращенное рабочее время в период праздников. (Обычно череда праздников снижает продуктивность работы.) Учтены ли в плане наиболее вероятные разрушительные погодные явления (например, снежные заносы в Чикаго, торнадо в Канзасе или жара в Сиетле)?

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

• Была ли у расчетчиков достаточная практика или опыт в производстве расчетов времени, отводимого на работы?

 

Эффект снежного кома

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

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

Рис. 2.4. Эффект снежного кома

 

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

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

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

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

 

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

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

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

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

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

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

 

Как на планирование влияет его организация

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

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

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

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

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

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

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

 

Документы, разрабатываемые при обычном планировании

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

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

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

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

 Технические условия. В них формулируется конечный результат работ для определенной части проекта. Обоснованные технические условия вырабатываются на основе набора требований. Затем они многократно прорабатываются в процессе проектирования (см. главы 5 и 6), в ходе которого изменениям и уточнениям могут подвергаться и исходные требования. Выработка технических условий завершается, когда они обеспечивают работоспособный план, который в процессе разработки и управления проектом может быть использован для удовлетворения требований (степень их детализации должна быть полностью обговорена с разработчиками и управленцами). Технические условия должны унаследовать как можно больше идей, выдвинутых в концептуальных документах. Они определяют для проекта ответ на вопрос «как?», то есть как его реализовать с конструкторской и технической точек зрения. (Сценарии использования и карточки историй, применяемые в большинстве гибких методов, становятся чем-то вроде технических требований и условий.)

 Структурная декомпозиция работ (Work Breakdown Structure, WBS). Технические условия детализируют объем выполняемых работ, а документы структурной декомпозиции работ определяют, как группа разработчиков должна справляться с их выполнением. Что должно быть сделано в первую очередь? Кто этим займется? Что из себя будут представлять все индивидуальные рабочие задания и как можно отслеживать их выполнение? В зависимости от потребностей проекта эти документы могут быть оформлены предельно просто (в виде электронной таблицы) или довольно сложно (в виде диаграмм и средств выполнения). К разработке документов структурной декомпозиции работ относятся главы 7 и 13. Эти документы определяют для проекта ответ на вопрос «как?» с точки зрения группы разработчиков. (В некоторых методах гибкой разработки все задействованные карточки историй показываются на досках заданий, которые становятся чем-то вроде структурной декомпозиции работ.)

 

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

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

ВНИМАНИЕ

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

 

Взгляд бизнесмена

Деловой взгляд фокусируется на понятиях, влияющих на прибыли и убытки (Profit and Loss, P&L), учитываемые организацией. В эти понятия включаются продажи, прибыль, расходы, конкуренция и издержки. Каждый должен разбираться в своей прибыли и убытках – из прибыли выплачиваются зарплаты или оплачиваются контракты. Когда команда разработчиков не знает, как работает бизнес, многие решения, принимаемые руководством, им кажутся нелогичными или неинтересными. Поэтому в интересах тех, кто отвечает за бизнес-планирование, помочь понять всем другим, почему проект имеет право на существование с деловой точки зрения. В технической сфере деловую точку зрения представляют все, чьи должности именуются бизнес-аналитик, специалист по маркетингу, специалист по развитию бизнеса, планировщик номенклатуры изделий или старший менеджер.

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

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

• Почему этот проект необходим для нашего бизнеса?

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

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

• Что сможет побудить клиентов приобрести этот продукт или воспользоваться этими услугами? Что станет причиной такого поступка?

• Во что это обойдется (с точки зрения затрат людских и материальных ресурсов)? Сколько на это уйдет времени?

• Каков уровень возможных доходов (или снижения организационных и производственных затрат)? За какой период времени?

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

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

• Как проект поможет нам идти в ногу с конкурентами, обойти или превзойти их?

• На какие рыночные интервалы времени можно нацелить данный проект?

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

Маркетинг – слово совсем не ругательное

Самой несправедливой критике бизнесмены подвергаются в среде «технарей», где их обзывают «торгашами». Я думаю, что маркетинг в данном случае получает удар ниже пояса. В терминологии образовательной программы MBA (Master of Business Administration – магистр делового администрирования) маркетинг можно определить четырьмя «P»: Product (продукция), Price (цена), Placement (распространение продукта) и Promotion (продвижение продукта на рынке). Определение вида продукции и цены – процесс творческий. Его цель состоит в том, чтобы проработать идею продукции, продаваемой с прибылью и отвечающей потребностям определенного покупателя. Чтобы добиться в этом деле успеха, необходимы исследования, анализ и творческая работа. Распространение продукта (третья буква «P») подразумевает способы получения продукта покупателем. (Через веб-сайт? Через супермаркет? Из багажника автомобиля?)

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

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

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

 

Взгляд разработчика

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

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

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

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

• Что именно в соответствии с ним (проектом) требуется сделать?

• Как это будет работать? Как будет работать каждый компонент?

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

• Насколько надежны, эффективны, расширяемы и производительны существующие и нами создаваемые системы? Существуют ли пробелы между всем этим и требованиями проекта?

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

• Какие технологические процессы и подходы соответствуют данной команде и данному проекту?

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

• Чем мы восполним недостаток делового опыта? (Методом проб и ошибок, наймом на работу других специалистов, обучением своих специалистов? Или проигнорируем эти пробелы в надежде, что они волшебным образом исчезнут сами по себе?)

• Сколько времени займет создание продукта и каков при этом будет его уровень качества?

 

Взгляд потребителя

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

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

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

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

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

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

• Чем обычно заняты люди? (Не наши домыслы и не то, что они об этом рассказывают.)

• Какие проблемы они испытывают, стараясь заниматься своим делом? Что их ставит в тупик, смущает или расстраивает?

• Что им нужно или хотелось бы делать, но не представляется возможным?

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

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

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

• Какие основные идеи и концепции должны быть представлены в проекте, чтобы донести информацию до пользователей?

 

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

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

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

Рис. 3.2. Три взгляда на проект

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

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

В прежние годы я и сам порой оказывался втянутым в эти бессмысленные войны. Я был руководителем проекта создания поисковых функций в Internet Explorer 4.0. К нам были назначены два специалиста по развитию бизнеса, которые вели переговоры об использовании основных поисковых машин того времени (Excite, Yahoo! Lycos, AltaVista и т. д.). Мы вели споры с этими экспертами по бизнесу вокруг конструкторских решений, постоянно дебатируя о том, что важнее, интересы клиента или бизнеса. Каждый из нас верил в свою правоту (я выступал за коллектив проектировщиков и разработчиков, а они отстаивали точку зрения бизнесменов). Мы неделями спорили об одном и том же, всегда касаясь конкретных решений и никогда не отступая назад, что позволило бы разглядеть нашу общую скрытую философию, направленную на выпуск качественной продукции. Дела приобрели настолько плохой оборот, что для достижения компромисса пришлось привлечь нашего общего руководителя.

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

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

 

Баланс сил

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

Разумеется, примерное количество людей не определяет объем имеющихся у них полномочий. В армии Наполеона были тысячи солдат, но Наполеон был только один. В команде может быть 10 программистов и 1 специалист по маркетингу (10:1:0), но последний может иметь больше полномочий в рамках проекта, определяющих его роль или старшинство. Это означает, что руководитель в состоянии компенсировать натуральное соотношение, наделяя полномочиями тех, кто должен иметь больше влияние на проект. А поскольку сущность проекта со временем меняется, представители различных взглядов должны в разное время получать различный уровень полномочий. О том, как можно поручать принятие решений для достижения нужного баланса в нужное время, рассказывается в главе 12.

 

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

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

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

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

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

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

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

• Кто потенциально может стать новым покупателем и какие характеристики, сценарии работы или типы продукции нам нужно предоставить, чтобы превратить их в реальных покупателей? (Каковы демографические данные этих новых покупателей?)

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

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

• Присутствуют ли эти значимые возможности в новом продукте или линейке продуктов? Или связаны ли непосредственно с продуктом (линейкой продуктов) выявленные запросы?

• Существуют ли действенные бизнес-модели для использования нашего делового опыта и технологии в решении выявленных проблем или в удовлетворении запросов? (Смогут ли доходы превысить затраты в обозримом будущем?)

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

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

 

Ответы на правильные вопросы

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

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

 

Что делать при дефиците времени?

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

 

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

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

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

Рис. 3.3. Взаимосвязь между уровнями планирования

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

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

 

Повседневная работа

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

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

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

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

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

 

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

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

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

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

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

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

• Ведомственная информационная страница долго загружается, заставляя пользователя ждать.

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

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

• Результаты поиска трудно просматривать в существующем формате.

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

• Страница состояния не включает информацию об электронной почте, и пользователи не могут узнать, почему их электронная почта не работает.

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

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

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

 

Проблемы превращаются в сценарии

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

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

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

Итак, возможные характеристики проекта X:

• Часто востребуемые разделы можно будет легко обнаружить на домашней странице.

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

• Веб-сайт обеспечит простой автоматизированный доступ к защищенным услугам.

• Регистрационная страница позволит упростить безошибочный ввод информации.

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

• Интерфейс запросов к базе данных будет по надежности сопоставим с остальными компонентами системы.

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

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

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

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

 

Объединение деловых и технологических требований

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

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

 

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

Рассмотрение следующих вопросов поможет вам определить структурную сложность и трудоемкость вашего концептуального документа:

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

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

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

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

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

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

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

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

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

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

 

Общекомандные и индивидуальные цели

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

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

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

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

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

Рис. 4.2. Три уровня целей

Давайте в качестве примера возьмем некий проект создания корпоративного веб-сайта под названием «Гидра»:

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

• Общекомандные цели. Команда А будет отвечать за создание доступных и простых в применении систем поиска и учета. Команда Б будет отвечать за создание систем инвентаризации, учета внутренних ресурсов и перевозок.

• Индивидуальные цели. Фрэд (из команды А) будет заниматься проектированием и разработкой всех функций, необходимых для поисковой системы. Майк (из команды Б) будет курировать все работы по общему устройству веб-сайта и вырабатывать технические условия на создание интерфейса для «Гидры». Боб (из команды Б) будет заниматься проектированием и разработкой всех функций, необходимых для учета внутренних ресурсов и перевозок.

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

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

 

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

 

Простота

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

 

Целенаправленность

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

Для правильной формулировки целей широко используется деловой подход, выражаемый акронимом SMART (Specific, Measurable, Action-oriented, Realistic, Timely – точность, измеряемость, действенность, реалистичность, своевременность). Идея состоит в том, что если цель соответствует этим пяти требованиям, то, скорее всего, она достаточно хорошо определена для дальнейшего использования (тем не менее остаются субъективные рассуждения о том, насколько конкретной или реалистичной должна быть цель). При формулировке цели можно воспользоваться и другим приемом – отнестись к ней максимально придирчиво и задаться вопросом, не провалится ли проект, если его цель будет достигнута в точном соответствии с ее формулировкой. Затем нужно подумать, а нельзя ли более точно сформулировать цель, нет ли какой-нибудь дополнительной, уточняющей информации.

 

Консолидирующая способность

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

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

 

Вдохновляющая способность

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

 

Запоминаемость

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

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

 

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

 

Простота дается не легко

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

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

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

 

У хорошей разработки только один главный автор

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

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

 

Качество не определяется объемом

Следует понимать, что ясная мысль не требует многостраничного изложения. Самые действенные руководящие документы в мире не отличались большим объемом. Конституция США, включая Билль о правах, содержит всего лишь 7000 слов (около 6 страниц). Десять заповедей состоят из 300 слов. Великая хартия вольностей – из 5000. Светлые головы способны извлечь из идей самую суть и выразить их намного доходчивее любых описаний, занимающих вдвое больше места. Не следует путать понятия объема и качества. К сожалению, из-за того, что объем дается легче, чем качества, мы иногда поддаемся следующему искушению: «Если ничего хорошего не выходит, то можно выиграть хотя бы за счет объема, а вдруг никто не заметит разницы» (еще одна привычка в работе авторитетных комиссий). Итак, с учетом всего вышеизложенного, вполне уместно спросить меня о том, почему же я не сократил объем этой книги. Виноват, не смог.

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

 

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

Вот примеры вполне удачных концептуальных положений:

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

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

• В версии 5.5 Helpdesk Automated Services Site (HASS) будут учтены десять самых распространенных претензий, предъявленных пользователями из числа преподавателей и студентов университета, при этом исключаются любые негативные влияния на среднюю производительность, надежность или на время отклика системы.

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

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

2. Стоимость. Устройство должно стоить меньше, чем органайзер элитного класса (около 300 долларов США).

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

4. Синхронизация с персональным компьютером. Компьютер должен стать основным средством взаимодействия с пользователем.

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

 

Обоснование концептуальных положений и целей

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

 

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

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

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

 

Наглядное представление неочевидных вещей

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

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

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

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

 

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

Рис. 5.1. Проектирование зачастую выглядит как некий таинственный переход от первичного планирования к выработке технических условий

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

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

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

 

Качественные требования и ошибки

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

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

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

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

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

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

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

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

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

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

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

 

Исследование проекта

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

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

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

Рис. 5.2. Конструкторские замыслы возникают на основе формулировки задачи

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

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

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

 

Страх перед просчетами и размышления о прогрессе

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

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

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

 

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

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

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

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

 

С чем сравнивать, хорошо это или плохо?

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

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

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

 

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

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

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

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

 

Вопросы, концентрирующие внимание

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

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

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

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

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

 

Креативные вопросы

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

 

Риторические вопросы

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

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

 

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

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

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

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

 

Хорошие проекты рождаются из множества хороших идей

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

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

 У архитектора два самых главных инструмента: в студии – ластик, на строительной площадке – кувалда (Фрэнк Ллойд Райт).

 Самый важный инструмент физика – мусорная корзина (Альберт Эйнштейн).

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

 Неудач не бывает. Бывают лишь слишком ранние отказы от продолжения работы (Джонас Солк).

 Лучшие способы есть всегда, их только надо найти (Томас Эдисон).

 Неудача. Опять неудача. Почти что удача (Сэмьюэл Бэкет).

 Если хотите достичь успеха, удвойте квоту неудач (Том Уатсон, IBM).

 На одну страницу шедевра у меня приходится 99 страниц мусора (Эрнест Хемингуэй).

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

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

 

С подачи Оука Юксела (Ayca Yuksel) и Ванессы Лонгакрэ (Vanessa Longacre), двух бывших сотрудников компании Microsoft, вся наша троица записалась в общественный колледж в класс импровизационной комедии. После первого же дня я понял, что мой страх выставить себя на посмешище перед командой совершенно не обоснован. Я узнал, что большинство людей, если они учатся замечать что-нибудь вокруг себя (чему нас и учили в этом классе), смогут находить смешное во многих совершенно заурядных ситуациях. Учеба часто позволяет видеть вещи, обычно ускользающие от внимания, и строить взаимосвязи между ними.

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

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

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

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

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

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

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

 

Правила импровизации для генерации идей

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

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

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

1. Да, и вот еще что… Когда кто-нибудь другой предлагает некую мысль, допускается лишь одна реакция: «Да, и вот еще что <далее следует соответствующее продолжение>». Вашим первым побуждением должно стать продолжение его направления мысли. Обычно вы подхватываете его идею или точку зрения и продвигаете их дальше или меняете их направление, к примеру: «Мы можем использовать поисковое поле вот здесь…», «Да, и разумнее было бы после того, как пользователь что-нибудь ввел, перевести его взгляд в нужное место». Или: «Да, и вот еще что, здесь нужно воспользоваться тем самым новым поисковым движком, который мы создаем, и ускорить выдачу результатов». Все внимание направлено на то, чтобы развитие дискуссии шло в позитивном направлении и вырабатывалась привычка прислушиваться к другим участникам, помогая в развитии предложенных ими идей, а не выжидая благоприятного момента для высказывания собственных.

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

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

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

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

 

Другие подходы к генерации идей

Если вы не готовы к импровизационным играм или хотите подойти к генерации идей более прямолинейно, то вам подойдет ряд традиционных предложений:

 Подберите себе книгу по творческому мышлению. Существует немало хороших книг на выбор. Две мои самые любимые – «Thinkertoys» Майкла Майкалко (Michael Michalko) (Ten Speed Press, 1991) и «Six Thinking Hats» Эдварда Де Боно (Edward De Bono) (Back Bay Press, 1999). Существует множество других популярных книг, которые по-своему тоже хороши, но наибольшую пользу я сумел извлечь их этих двух.

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

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

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

 

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

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

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

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

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

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

Причины этого явления могут быть разными.

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

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

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

 

Изменения вызывают цепную реакцию

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

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

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

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

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

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

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

 

Творчество – процесс инерционный

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

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

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

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

Рис. 6.2. Пространство решения проблем расширяется и сужается в процессе проектирования под воздействием непредвиденной инерционности творческого процесса

 

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

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

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

Рис. 6.4. Когда идей много, справиться с ними нелегко

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

Рис. 6.5. Неплохо было бы сгруппировать идеи

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

• убрать дополнительные элементы управления, которыми никто не пользуется;

• улучшить формат страницы результатов поиска;

• использовать улучшенную поисковую машину HyperX;

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

• позволить пользователям устанавливать индивидуальные предпочтения в отношении внешнего вида страницы;

• открывать результаты в новом окне;

• устранить ошибки, замедляющие работу поисковой машины;

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

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

• Упростить:

• убрать дополнительные элементы управления, которыми никто не пользуется;

• улучшить формат страницы результатов поиска;

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

• Сориентировать на потребителя:

• позволить пользователям устанавливать индивидуальные предпочтения в отношении внешнего вида страницы;

• открывать результаты в новом окне.

• Реконструировать архитектуру:

• провести доводку системы обработки запросов (включить поддержку логического поиска);

• устранить ошибки, замедляющие работу поисковой машины;

• использовать улучшенную поисковую машину HyperX.

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

 

Оптимизация и расстановка приоритетов

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

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

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

 

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

 

С чего начинаются прототипы?

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

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

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

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

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

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

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

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

 

Прототипы для проектов с пользовательским интерфейсом

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

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

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

 

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

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

 

Прототипы – это опора программистов

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

Вот краткий перечень вопросов, на которые программисты должны ответить в данный период:

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

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

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

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

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

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

 

Альтернативные варианты повышают вероятность успеха

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

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

 

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

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

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

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

 Перечень работ. Перечень работ – это примерный эквивалент структурной декомпозиции работ (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).

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Рис. 14.1. Одни и те же действия могут привести к различным результатам в зависимости от инерционности проекта

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

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

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

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

 

Мыслите здраво

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

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

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

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

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

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

 

Тактические (ежедневные) вопросы, позволяющие бежать впереди паровоза

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

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

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

 

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

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

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

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

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

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

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

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

И, напоследок, еще три важных замечания:

1. Вы должны осознать тот факт, что плететесь в хвосте. Следует помнить, что рабочие графики носят вероятностный характер. Какова ваша уверенность в том, что с недельным объемом работы удастся справиться своевременно? 80 %? 50 %? Если шансы на то, что вы справитесь, составляют пятьдесят на пятьдесят (или хуже), значит, вы плететесь в хвосте, у вас слишком мал предел возможных ошибок и вы их обязательно наделаете, если уже не наделали.

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

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

Чтобы больше узнать о том, как справиться с кризисной ситуацией, обратитесь к главе 11.

 

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

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

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

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

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

При рассмотрении корректировок в период миттельшпиля (при внесении изменений в характеристики, цели или требования) нужно ответить на следующие пять вопросов:

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

2. Что представляет собой эта проблема, чем она является, симптомами или болезнью? Может быть, можно ограничиться устранением симптомов?

3. Достаточно ли имеющегося представления о состоянии программного кода или команды разработчиков, чтобы предсказать, как на них скажется корректировка?

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

5. Может ли риск возникновения новых потенциальных проблем свести «на нет» весь выигрыш от вносимых изменений?

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

 

Нарушение обязательств

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

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

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

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

 

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

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

В книге «Web Project Management: Delivering Successful Commercial Web Sites» (Morgan Kaufmann, 2001) ее автор Эшли Фридлейн (Ashley Friedlein) назвал это краткое совещание с командой и детализацию следующей части предстоящей работы инструктажем. Он писал: «Для достижения максимальной эффективности и скорости разработки ваши инструктажи должны быть построены так, чтобы всегда опережать текущее состояние дел. Как только часть работы будет завершена, у вас должен быть наготове инструктаж, относящийся к следующей части». Эти инструктажи готовятся на основе технических условий (не утративших своей актуальности), но включают в себя все новое или измененное, о чем должны знать программисты. Без активного инструктирования программистов в ходе миттельшпиля может возникать любое количество факторов, препятствующих завершению работ и замедляющих движение конвейера; к этим факторам относятся проблемы потребительских качеств, проработка внешнего дизайна, работы, выполняемые другими программистами, проблемы рыночного характера, технические проблемы или какие-то внешние зависимости. Поскольку руководители проектов зачастую обладают самым разнообразным набором навыков, никто лучше их не справится с запуском конвейера, с частичным или полным решением проблем и со сглаживанием шероховатостей прежде, чем с ними придется иметь дело программистам. (Сюда же относят и выявление несостоятельных программистов, находящихся в состоянии ступора и либо не признающихся в этом, либо еще не разобравшихся в своем состоянии.)

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

Успех этих дел определяется ответами на следующие четыре вопроса:

 Какие работы находятся в стадии выполнения? Существуют ли проблемы, не позволяющие программистам завершить текущие работы? Если они существуют, их надо устранить (естественно, проблемы, а не работы). Для проекта это авральное состояние. Если программист не может активно создавать программный код, проект останавливается. Нет ничего более важного, чем решение проблемы, застопорившей работу программиста. Задайте ему простой вопрос: «Как я могу помочь тебе решить проблему?» Если вы можете помочь, программисты обязательно поставят вас в известность Если блокирующая работу проблема заключается в какой-то зависимости (например, Фрэд должен завершить работу 6, прежде чем Боб приступит к работе 7), рассмотрите возможность загрузить программиста другой работой, пока проблема не будет снята.

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

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

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

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

 

Агрессивный и консервативный варианты производственного конвейера

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

Команда с агрессивной позицией в выборе приоритетов может в большей степени полагаться на конвейер по разработке кода. Вместо проведения сложной структурной декомпозиции всех работ команда делает ставку на внесение изменений и на способности руководителя проекта или ведущего программиста управлять конвейером. При этом возникает весьма рискованная ситуация: если конвейер даст задний ход или не сможет быть выстроен заранее, с опережением хода работ, это приведет к принятию далеко не самых лучших решений и к ненужной потере времени. Подробную информацию о качественном проведении структурной декомпозиции работ (WBS) при планировании проекта вы найдете в книге Стивена Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999) или в любых традиционных информационных источниках, касающихся руководства проектами.

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

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

 

Превращение конвейера по созданию кода в конвейер по исправлению ошибок

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

 

Отслеживание хода процесса

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

Тайные механизмы управления

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

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

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

 

Исследование влияния изменений

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

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

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

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

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

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

 

Потенциальная удаленность изменения

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

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

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

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

 

Контроль изменений

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

Дополнительно эти действия могут сочетаться с непосредственным запросом (как показано на рис. 16.6.). Другие возможные варианты включают способы использования требуемого вами влияния. Возможно, в присутствии Б, В и Г не возникнет необходимости или даже вообще не придется вести с А разговор по рассматриваемому вопросу. Поскольку вы пользуетесь их благоприятным мнением, можете переговорить с ними и обратиться к А со следующей фразой: «Я думаю, нам нужно исключить данную функцию. Я поговорил с Б, В и Г, и все они согласны со мной по этому вопросу». Конечно же, следует как можно точнее передать все ими сказанное и всегда стараться уладить вопрос в присутствии этих людей (намеренно возвращаясь к предыдущему разговору).

Рис. 16.6. Атака с флангов

Многоступенчатое влияние

Когда вы можете вступить в контакт с нужными людьми, опуститесь на одну ступень вниз по цепочке влияния или по иерархической лестнице. Если В – единственный, к кому может прислушаться А, но вы не в состоянии добиться аудиенции В, найдите людей, имеющих наибольшее влияние на В. Затем вступите в контакт с ними и изложите суть своего вопроса. С этой позиции вы можете двинуться дальше, до тех пор, пока ваше влияние не достигнет нужной цели (рис. 16.7).

Рис. 16.7. Многоступенчатое влияние

Косвенное влияние

В некоторых случаях лучше всего оказать влияние на власть предержащих путем запуска какого-то механизма, оставаясь при этом за сценой. Возможно, А находится двумя и более ступенями выше в вашей организационно-штатной структуре, и он может негативно отреагировать на прямое обращение к нему людей вашего уровня. Или же вы просто не нравитесь А, или он в данный момент на вас за что-то обижен (и вы думаете, что он не сможет отнестись к вам объективно).

В подобной ситуации следует заручиться поддержкой другого человека, чтобы он сделал запрос за вас. В этой роли может выступить ваш непосредственный начальник, коллега по команде или работающий на А человек, которому случается оказывать влияние на А в подобных вопросах.

Наименее изощренным способом решения задачи является проведение переговоров. Поговорите с В и посмотрите, согласится ли он с вами. Если согласится, спросите, не смог бы он поговорить об этом с А (рис. 16.8). Когда он пойдет к А, он не должен вводить А в заблуждение или лгать: он должен привести доводы, исходя из собственных позиций, поскольку он и в самом деле согласился с вами и с правомерностью вашего запроса. Если затем А потребует переговоров с вами или вы сами чуть позже попросите его аудиенции, ваши доводы будут полновеснее за счет влияния, оказанного В.

Рис. 16.8. Косвенное влияние

Совещания

На совещаниях создается довольно сложная политическая ситуация. Любой присутствующий может высказаться и задать вопросы, оказывая тем самым такое политическое влияние на дискуссию, которое может осложнить ситуацию. Если предстоит принимать какие-нибудь сложные решения, то до начала совещания нужно обязательно оценить, кто на нем будет присутствовать. Перед совещанием подумайте о том, какие вопросы на нем, скорее всего, будут подняты и какие варианты ответов захочется услышать каждому из присутствующих. Хорошее знание участников позволит дать неплохую оценку ожидаемому развитию событий и самостоятельно ко всему подготовиться. Если такой возможности нет, нужно навести справки. Попросите влиятельных людей, чье присутствие ожидается, поделиться своим мнением до начала совещания. Изучите заранее их отношение к обсуждаемым проблемам и самые важные вопросы, которые могут быть заданы, а затем либо внесите изменения, если это возможно, либо выстройте линию защиты существующего у вас плана. Если вы сами готовите повестку дня, внесите в нее соответствующие изменения.

Иногда инициатива собрать совещание может быть единственным средством поднять вопрос применения властных полномочий. Электронная почта для решения сложных и острых проблем вряд ли подойдет. Поводом для совещания может стать определение, что Салли нужно одновременно услышать мнение Боба и Майка, дабы убедиться, что к вашим рекомендациям стоит прислушаться. Эффективное проведение совещаний является своего рода искусством (см. главу 10), но в данный момент нужно уяснить, что чем лучше вы подготовитесь к ответам на возможные вопросы и к предстоящим дебатам, тем легче будет вести совещание без эксцессов и в нужном для вас направлении (рис. 16.9).

Рис. 16.9. На совещании может возникнуть непредсказуемая политическая ситуация

Пускай они думают, что это их идея

Изредка бывает так, что на почве чьего-то эгоизма вы можете высадить и прорастить свое собственное зерно. Все происходит примерно так: вы полагаете, что напрямую ваш запрос вряд ли пройдет. Поэтому, как только обнаружится проблема, вы затеваете дискуссию и запрашиваете помощь в поиске решения. Собственных ответов на поставленный вопрос вы не предлагаете, а вместо этого задаете вопросы и расставляете вехи, постепенно подводящие присутствующих к нужному для вас результату. Этот прием, как и всякая подтасовка, легко может привести к неприятным последствиям, тут требуются деликатность и мастерство импровизации, которыми обладают далеко не все. И все же я допускаю, что иногда этот номер вполне может пройти, в особенности с теми начальниками, которые любят считать, что они всегда правы.

Дополнительные источники

В предыдущий перечень попали лишь основные тактические приемы. Книгами по политической тактике забито множество книжных полок. Лучшим унифицированным средством на эту тему я считаю книгу Роберта Грина (Robert Greene) «The 48 Laws of Power» (Penguin 2001), но должен предостеречь: после прочтения книг Дейла Карнеги вроде «How to Win Friends and Influence People» (Pocket, 1990) вы почувствуете позывы применить все усвоенное на практике. Книга Роберта Сайолдини (Robert Cialdini) «Influence» (Perrenial, 1998) больше относится к маркетингу, чем к офисной политике, но некоторые изложенные в ней физиологические принципы могут быть применены и в этой сфере.

 

Последние рассуждения о руководстве проектом касаются игрового поля для проведения политических игр. Правила игры, которым будет следовать команда (как приобретается власть, как она применяется и распределяется), определяются теми людьми, в чьих руках сосредоточено больше власти. Неэтичные поступки, вроде различного рода подтасовок и введения окружающих в заблуждение, должны выявляться и наказываться теми, кто контролирует ход политического процесса. В сферу их интересов должно входить поддержание относительно честной ситуации на игровой площадке, когда нужные люди могут пользоваться политической системой в целях благополучного завершения проекта.

Однако если власть предержащие не заботятся о создании справедливой обстановки на игровом поле, то постижение правил игры и наведение порядка должно лечь на плечи одного из игроков. Вы должны либо предпринять попытку изменить правила игры, либо принять их в существующем виде. Если практика ввода в заблуждение и ведения нечестной игры является обычным делом, никакой закон не запрещает вам подыскать другую работу. Если вы хотите остаться в этой жесткой среде, то не стоит полагаться на чей-то необоснованный альтруизм. Я также не рекомендую следовать самым низменным стандартам и копировать чужое поведение: вы должны выбрать собственные морально-этические нормы. Но я хочу сказать, что вам обязательно нужно знать, какую игру и с кем вы ведете.

 

Создайте собственное игровое поле

Независимо от всех политических неприятностей, вы, как руководитель проекта, должны контролировать свое собственное игровое поле (рис. 16.10). Под вашим контролем находится также распределение властных полномочий в команде. У вас на выбор есть два основных варианта: превратить свое игровое поле в площадку для безопасной и честной игры, в которой участвуют самые умные люди, или позволить влиять на ваши дела проблемам и симптомам, характерным для большой команды. Последний вариант проще: можно вообще ничего не делать. А первый требует твердого руководства и применения множества тактических приемов, рассмотренных в данной книге.

Рис. 16.10. У вас всегда есть полномочия на определение собственного игрового поля

Хорошие руководители всегда находят способ защиты своей команды. Наряду с той истиной, что росту команды способствует опыт преодоления трудных ситуаций, хороший руководитель обеспечивает достаточную степень защиты людей, позволяя им эффективно работать без сложных испытаний и поиска возможных путей выхода. Кроме того, если и у вас имеется толковый руководитель, то он уберегает вас от проблем и ситуаций, активно работает в ваших интересах, создавая среду, в которой вам легче трудиться. Для осуществления подобного упреждающего руководства на любом иерархическом уровне требуется более интенсивный и зрелый подход к своей работе, но в этом и заключается суть хорошего руководства.

Поэтому если ваш руководитель не удостаивает вас частыми обращениями, то не стоит всем об этом сообщать. Только руководитель вправе решать, как управлять собственной командой. Не стоит переносить в свою работу отношения, привычки или тактику действий, которые вы считаете вредными. Объясните своей команде различия в стиле работы или в позициях, но не следуйте тому поведению, которое считаете непроизводительным.

Большинство советов, приведенных в этой главе и книге, применимы к любому уровню организационной иерархии. Если на вашем уровне цели не имеют достаточно четкого определения, вы всегда сможете определить их для своей команды. Если на вашем и на вышестоящем организационных уровнях отсутствует четко определенный порядок распределения ресурсов, вы можете установить собственный порядок на порученном вам участке работы. То же самое относится к планированию проекта, общению или приему решений. Если от предпринятых усилий вы сами не всегда будете получать прямую выгоду, то они, безусловно, положительно отразятся на работе всей команды. Ей будет легче работать продуктивнее, поскольку вы обеспечите эффективную структуру, отсутствующую во всей остальной организации.

В конечном счете, упреждающее руководство в вашей собственной сфере влияния является наилучшим способом укрепления собственного источника властных полномочий. Первоначально отличие ваших методов работы от методов вашего руководства может привести к утрате благосклонности с их стороны. Но со временем людям придется по вкусу созданное вами игровое поле. Они более охотно и продуктивно, чем с другими руководителями, будут работать с вами и на вас. В отличие от фактического положения всей остальной организации, качество работы вашей команды будет неуклонно расти.