Ведение переговоров

Ведение переговоров

Почему иногда не получаются даже простейшие вещи?.
Я полагаю, что первопричиной таких ситуаций, как правило, является классическое «взаимонепонимание». «Как, разве вам это было нужно? Почему же вы не сказали?» Мы раздражены, мы пытаемся справиться с отчаянием. Но пока мы не разберемся, в чем здесь неправильность, мы обречены бесконечно повторять свой печальный опыт.
Интересно отметить, что такое взаимонепонимание редко возникает, если проведены переговоры. После взаимных уступок и выработки решения вероятность серьезного конфликта значительно уменьшается. Может быть, в этом и заключается главное. Весь фокус, возможно, в том, чтобы провести переговоры без собственно переговоров. Потому что, как всем нам известно, переговоры чреваты конфликтами, и совсем нежелательно, чтобы любой контакт приобретал такой характер.
В этой главе наш друг Роско Леруа излагает свой план.
Общение - это все.
Однажды мы с Роско сидели около печки и брюзжали на субботний дождь. Роско уже примерно полгода вел проект с участием некой группы разработчиков ПО, и, к моему удивлению, при этом не произошло.
никаких событий, достойных отметки на шкале Рихтера. Если учесть, что Роско взрывоопасен, как Везувий в августе,
я предположил, что что-то назревает.
- Роско, - решился я, - как это ты до сих пор не разогнал половину команды?.
- А зачем? - отвечал он. - Они, знаешь ли, хорошо работают. Если, конечно, уметь с ними разговаривать.
- Да неужели? - удивился я. - А что, разве беседы с программистами это что-то особое?.
- Вот тут ты ошибаешься сынок. Надо не беседовать с ними, аразговаривать. Начнешь беседы проводить, так и глазом не моргнешь, как начнешь выговоры им делать, а там и до беды недалеко.
Черт! Прижал меня так быстро, что я опомниться не успел. Но он был прав.
- Ладно, Роско, согласен. Но в самом деле, отличается ли общение с инженерами, особенно с программистами, от разговоров с другими людьми? Если да, то мне очень хотелось бы понять, в чем тут секрет.
Роско излагает свою теорию.
- Ну, дело вот в чем. Для начала надо отметить, что разработчики ПО хотят, чтобы к ним относились как к профессионалам. Они не просто нуждаются в уважении, как все люди, но требуют его, как доктора и другие профессионалы. Если считать их просто «программерами» или «хакерами», они разозлятся. Поэтому важно вести себя «с пониманием».
- Черт возьми, - высказался я, - ты говоришь так, будто речь идет об обращении с примадоннами.
- Не совсем так, - сказал он, и это удивило меня. - Пойми, разработка программ - это самая молодая из инженерных дисциплин. Всем известно, чем занимаются инженеры в машиностроении, строительстве, энергетике и химическом производстве, а в аэронавтике инженеров даже иногда называют учеными-ракетостроителями. Но не так много людей понимает, чем в действительности занимается инженер-программист. Проблема в том, что программисты часто ощущают себя эдакими Родни Дэйнджерфилдами в инженерии.
Поэтому я их слегка одергиваю.
- OK, - сказал я, - только не рассказывай мне про их комплекс неполноценности. Некоторые из них кажутся мне довольно невежественными.
- Так ты хочешь узнать что-то об общении или нет?.
Я был вынужден умолкнуть.
Мне надлежало слушать дальше.
Меня удивило, кстати, что Роско относит разработчиков ПО к «инженерам». Многие из тех, кто занят в софтверной индустрии, считают, что нам еще далеко до того, чтобы стать настоящей инженерной дисциплиной. Но я решил не дразнить гусей. Менеджерам приходится общаться с теми, кто проектирует и пишет наши программы, независимо от того, как мы именуем этих людей. И я знал, что если мне потребуется мнение Роско по этому предмету, он его выскажет. И, черт побери, если ему потребуется мое мнение, то он его тоже выскажет!.
Четыре шага.
- Метод общения с инженерами-программистами есть, и он состоит из четырех шагов. Вроде техасского тустепа, повторенного дважды.
Роско готовился к выступлению. Он несколько раз пыхнул сигарой и налил себе еще кофе.
- Если сделать эти четыре шага, то, скорее всего, тебе удастся спасти свою шкуру. Если же ты рискнешь какие-то из них пропустить, то от тебя живого места не останется. Так что слушай внимательно.
Шаг первый.
- Во-первых, запомни, что имеешь дело с инженерами. Инженеры обычно не любят вести светские беседы: они считают это бесполезной тратой своего времени. А время свое они ценят дорого. Поэтому прежде всего они хотят знать, в чем заключается задача.
- Ты хочешь сказать, что каждый разговор должен быть построен вокруг какой-то конкретной задачи? - спросил я.- А если я хочу обсудить с инженером перспективы?.
- Ну да, проблемы, перспективы - как вы, менеджеры, любите их называть. Ладно, назовем это вопросом, если тебе так больше нравится. Суть в том, что работа инженера заключается в решении задач, и если ты пришел с ним поговорить, то он, естественно, полагает, что у тебя есть задача, которую надо решить. Поэтому обычно я сразу просто говорю, что есть задача, которую я хотел бы обсудить, а потом просто говорю, в чем она состоит.
Мне показалось, что задание такой начальной точки отсчета для разговора может быть неплохой идеей. Чем ходить вокруг да около, лучше сразу выложить, зачем ты пришел. Поэтому я кивнул и стал ждать продолжения.
- Иногда он недовольно ворчит в ответ и быстро объясняет, почему твоя задача вовсе не является задачей. Иногда оказывается, что твоя информация была неверна. А иногда, что задача поставлена некорректно. Вполне уместно проявить настойчивость. Если сумеешь более четко описать задачу, то заслужишь некоторое уважение инженера. Не забывай, что инженер старается оценить как тебя самого, так и твою задачу. Он ни секунды не потратит на задачу, которую считает никчемной или нестоящей. Если у вас разногласия, лучше обсудить их, потому что пока он не будет убежден в том, что есть достойная задача, ты ничего от него не получишь.
Я вспомнил несколько дискуссий, во время которых я преждевременно забегал вперед. Естественно, каждый раз приходилось возвращаться и снова вести разговор, пока мы не достигали согласия относительно сущности проблемы. Есть у инженеров такая интересная особенность.
Шаг второй.
- Теперь, когда вы оба согласились, что проблема существует, необходимо определить права собственности, - продолжил Роско.
Права собственности? Роско явно успешно осваивал профессиональный жаргон.
- Дело вот в чем. Если это твоя проблема, тогда зачем ты пришел? Услышать совет или рекомендацию? Ты можешь их получить. Если же ты имел в виду, что это его проблема, ну, тогда ему, возможно, придется что-то сделать. Поэтому инженер, прежде чем обсуждать задачу дальше, хочет знать,чья это проблема?.
- Есть еще одна возможность, - сказал я. - Это может быть проблема не моя и не его, а кого-то постороннего.
- Да, возможно. Но тогда можешь быть уверен, что инженер скажет тебе что-то вроде: «А чего ты ко мне с этим пришел, если это не твоя проблема и не моя? Пусть он (посторонний) об этом и беспокоится.» Поэтому тебе придется объяснять, что это и к нему имеет отношение. Иначе он сочтет задачу неинтересной или не стоящей его времени.
Теперь я видел, что все не так просто, как мне казалось.
- Если это твоя проблема, то в лучшем случае можешь рассчитывать на внимательный анализ, возможно, рекомендацию, после чего лучше убраться из Доджа.
Инженер очень неохотно будет тратить свое время на твою проблему. Ну, вот такие они люди.
- С другой стороны, если ты считаешь, что это его проблема, придется приложить некоторые усилия, чтобы он признал это. Если инженер принимает на себя ответственность за проблему, он начинает действовать профессионально, чтобы решить ее. Поэтому инженеры неохотно встречают всякую новую задачу, которую ты им предъявляешь. Просто удивительно, на что они готовы пойти, лишь бы не признаться, что проблема касается их. Иногда они могут даже отрицать существование такой проблемы в принципе.
- Ага! - воскликнул я. - Вот почему тебе сначала понадобился шаг первый! Необходимо закрепить существование проблемы, чтобы она не улетучилась в процессе последующего обсуждения.
- Ты ухватил суть, - сказал Роско, - да, ухватил.
Итак, отметил я, вначале все просто. Устанавливаешь существование проблемы и убеждаешь инженера, что это его проблема. Первый тур техасского тустепа дался с легкостью.
- Окей, - сказал я, - как насчет второго тура?.
Шаг третий.
- Ну, чаще всего именно после этого все летит под откос, - сказал Роско. - Самое главное теперь не предлагать решение.
Черт меня подери, подумал я. Что такого ужасного в том, чтобы предложить решение?.
- Дело в том, что многие инженеры-программисты ощетиниваются при слове «требования». В прежние времена к ним приходили с готовыми идеями относительно способа реализации, называвшимися «требованиями» (requirements). Такая практика приводила к множеству ненужных конфликтов. Инженер желает знать, что должно быть сделано. Он не желает слышать от тебя, как это должно быть сделано. В конце концов, это то, за что ему платят деньги. Если ты бодро подходишь к нему с готовым решением, почти наверняка у вас возникнут разногласия. Есть и другая проблема, которая возникает, если предлагается готовое решение. Часто инженер, исходя из твоего «решения», пытается выяснить ход твоих мыслей и определить, что тебе нужно в действительности. При этом он может ошибиться. Поэтому, предлагая решение, ты создаешь дополнительный объем работы и подвергаешь риску все мероприятие.
- В таком случае, - стал думать я вслух, - откуда же берется решение?.
- По-настоящему толковые менеджеры, - продолжал Роско, - умеют «прощупать» своих инженеров и выяснить диапазон возможных решений. Они заводят разговор о возможных вариантах, их относительных выгодах и недостатках. Нет ничего плохого в том, чтобы изучить «пространство решений», но основным докладчиком должен быть инженер. И ради бога, не учи его держать карандаш в руке. В программировании практически всегда можно решить задачу массой способов. Инженеры тем и занимаются, что рассматривают альтернативные варианты, а потом пытаются выбрать из них лучший - то, что они называют оптимальным решением.
- Минуточку, - вмешался я, - а кто будет решать, какое решение лучшее?.
- Хорошее замечание, - ответствовал Роско. - «Лучшее» может означать то, которое «быстрее», «дешевле», «сопряжено с меньшим риском», «требует меньше сопровождения», «более искусно», «более элегантно», чем все другие, или выделяется еще какими-то достоинствами. Поэтому во время изучения пространства решений вместе с инженером нужно разобраться, что означает «лучшее» в твоем бизнес-контексте. Иначе можно получить технически «лучшее» решение, которое непригодно для твоих потребностей.
- Хорошо, - парировал я, - а если реализация решения требует слишком много времени?.
- Тоже верное замечание. Цель изучения пространства решений вместе с инженером состоит также в том, чтобы дать ему представление о том, какие ограничения ты вынужден наложить. При этом вы можете договориться о решении, которое каждого из вас удовлетворит лишь отчасти, но иногда это лучшее, чего можно достичь.
Так, посмотрим, что у нас получилось. Мы описали задачу, мы определили владельца, наметили пространство решений и обсудили некоторые альтернативы. Неплохо. Что осталось?.
Роско, конечно, читал мои мысли.
Шаг четвертый.
- Подведение итогов, - сказал Роско. - Когда имеешь дело с инженерами, всегда надо подвести итоги. Например, «какие будут следующие действия?» и «кто и что должен сделать и к какому сроку?» Если обсуждение заканчивается, а эти темы не затронуты, то результат почти всегда оказывается печальным.
- Почему? - поинтересовался я.
- Дело обстоит примерно так. Инженеры люди занятые. Задач у них всегда больше, чем времени на их решение. Часть этого времени ты у них уже отнял своими шагами с первого по третий. И оно будет потрачено впустую, потому что без шага четвертого все на том и закончится, как только ты выйдешь из комнаты.
- Как это? - вырвалось у меня.
- Ну посмотри: ты дал инженеру указание что-то сделать? Ты дал распоряжение, чтобы он действительно начал работу? Ты определил для новой задачи очередность относительно тех, над которыми он уже работает? Нет. Ничего этого ты не сделал. Поэтому ясно, что ты приходил, чтобы поговорить о задаче, а не чтобы ее решить. Если ты хочешь, чтобы инженер действительно что-то сделал, ты должен сказать об этом ясно и четко. Это надо выразить явно и недвусмысленно. И если он берет на себя обязательство что-то сделать, то, конечно, надо предложить ему установить срок. Потому что без срока это обязательство несерьезное. Далее, чтобы действительно завершить шаг четвертый, могут потребоваться еще некоторые действия. Инженер может потребовать дополнительные данные, попросить точнее описать объем работы и даже, возможно, представить это все ему в письменном виде. И ему может понадобиться еще некоторое время на размышление, после чего вы окончательно договоритесь по поводу реализуемого решения. Все это разумные требования. По крайней мере, ты теперь знаешь, что он занимается этой задачей, и можешь рассчитывать на результат.
Смотрим глубже.
Итак, рецепт Роско довольно прост:.
1.
Описать задачу и согласовать ее описание с инженером.
2.
Установить за инженером права собственности на задачу.
3.
Исследовать пространство решений под руководством инженера.
4.
Явно сформулировать и согласовать решаемую задачу, включая ее объем, приоритет и срок выполнения.
- Почему же, - спросил я у Роско, - этим простым рецептом не пользуются чаще?.
- Думаю, здесь играет роль то, что инженеры называют несоответствием импедансов.
Менеджеры многое считают само собой разумеющимся и делают массу предположений, которые попросту неверны. Иногда у них отсутствует правильная информация, часто они просто не знают, чего они не знают. Но поскольку они сами умные и знают, что инженеры тоже умные, им кажется, что существует общий контекст для обсуждения. Поэтому они забегают вперед. Часто они сразу перескакивают к решению, выполняя шаги третий и четвертый.
А инженер все еще мысленно находится на первых двух шагах. И дело не движется.
- Иногда можно сберечь время, если двигаться медленнее, - изрек Роско. - И, конечно, есть еще одна проблема. Часто решение, которое предлагает менеджер, сляпано на скорую руку, лишь бы срочно решить проблему. Это может быть дешевым выходом на короткое время. Вот тут инженер может разозлиться.
- Но почему? - спросил я.
- Ну, таковы они по натуре. Инженеры ненавидят делать одноразовые продукты. Уж лучше он потратит побольше времени, но сотворит надежное решение, которое не придется переделывать. Иногда вместо внимательного анализа инженерных компромиссов получаются просто заумные разговоры. Но для обсуждения таких вопросов с инженерами менеджер должен быть действительно хорошо подкован технически. Поэтому лучше не лезть со своим решением, а дать возможность инженеру предложить свои варианты.
Это пахнет политикой. Интересно, нет ли у Роско других предложений?.
- И еще одно. Следи за тем, чтобы не давать инженерам-программистам слишком много заданий одновременно. Они считают, что лучше всего работают, когда концентрируются на одной задаче, отдаваясь ей полностью.
Им известно, что такое многозадачность, но они не считают такой режим оптимальным для работы. И знаешь, - подмигнул он мне, - если они так считают, возможно, так оно и есть. Поэтому постарайся не проговориться, что у тебя хватит задач, чтобы завалить их работой выше крыши. От этого у них сразу портится настроение.
Довольно проницательно. Что там у нас еще в запасе?.
- В этих делах нужно быть деликатным. Помни, что твоя задача - наладить общение. Если твоему партнеру по диалогу покажется, что ты его поучаешь или пытаешься им манипулировать, пиши пропало. Общение с инженерами - это процесс, а не разовое действие. Диалог должен быть непрерывным. Нельзя раз поговорить с инженером, а потом забыть про него. Уже это одно свидетельствует о том, что нельзя оказывать на него слишком большое давление. Ты должен разговаривать с ним и дальше, если не на эту тему, то на другую.
- Поэтому, - сказал Роско, - я стараюсь установить такой порядок, когда парень знает, чего ждать дальше. Я рассматриваю это как организацию зоны комфорта. Если он знает, что сначала я постараюсь определить проблему и установить, в чьих интересах ее решение, он может подготовиться к соответствующему обсуждению. Может быть, нам хватит для этого пяти минут. И оба мы сэкономим время. Когда этот этап пройден, может состояться более интересный, с его точки зрения, разговор. Это уже шаг третий, на котором мы обсудим альтернативные решения. Тут уже он может блеснуть. И, конечно, он должен знать, что неизбежен шаг четвертый. Это покажет серьезность моих намерений, что я хочу не просто поговорить, а мне нужны какие-то действия. Повторюсь, что инженеры это уважают. Между прочим, если инженер сам придет к тебе поговорить, можешь предположить, что он будет действовать таким же четырехшаговым методом. Это потому, что инженеры примерно таким способом общаются друг с другом.
Ну, теперь все?.
Осталась еще одна вещь, которая тревожила меня в подходе, предложенном Роско.
- Роско, - сказал я, - мне кажется, что твой метод четырех шагов последователен по своей сути. Я знаю, что при итеративной разработке обсуждений должно быть много, как ты это уже отмечал. Но разве каждый разговор сам по себе не является «итеративным»?.
Роско улыбнулся.
- Ты, кажется, сразу хочешь стать «опытным участником», - сказал он. Было бы здорово, если бы я смог побольше людей заставить проходить эти четыре шага. Это был бы прогресс. Но ты прав, сынок. Иногда, добравшись до шага четвертого, приходится вернуться на третий шаг. Это происходит из-за того, что на четвертом шаге в реализации могут обнаружиться такие детали, что придется заново оценить решение, принятое на шаге три.
- Хорошо, - согласился я, - а не может при этом потребоваться вернуться еще дальше?.
- Разумеется, - ответил Роско. - Нетрудно заметить, что иногда на третьем шаге можно обнаружить альтернативное решение, которое потребует участия в работе кого-то еще. Это значит, что надо вернуться на второй шаг, чтобы найти нового собственника и убедить его.
- Значит, это все-таки итеративный подход, потому что я могу представить себе и такую ситуацию, когда придется вернуться вообще на первый шаг и заново сформулировать задачу, проведя обсуждение с третьей стороной, - высказал я предположение.
- Тут необходима осторожность, - сказал Роско. - Ты все правильно говоришь, но цель данного упражнения в том, чтобы подвести конечную черту, а не заниматься итерациями вечно. Некоторое количество итераций полезно, но твоя задача всегда в том, чтобы добраться до шага четвертого и выйти из него с планом действий. В противном случае не исключено, что тебе придется возносить молитвы у алтаря Владычицы Вечных Ревизий.
Эту ловушку я тоже заметил. Роско убедил меня в необходимости изменить стиль общения с инженерами-программистами. Даже если придется.
разговаривать с целой командой инженеров, я буду придерживаться тех же самых шагов: для перехода от разговора «один на один» к разговору «один со многими» потребуется еще больше организованности и дисциплины. Благодаря рецепту Роско группа должна с еще большей очевидностью убедиться в том, что у меня есть вполне организованный способ рассмотрения (и решения) задачи.
Я решил попытаться применить подход Роско и проверить, удастся ли мне развить свои способности к общению.
Резюме.
У инженеров есть одна опасная особенность, которую я наблюдал на протяжении многих лет и о которой необходимо помнить. Если описать им некоторую задачу, они всегда стараются рассмотреть ее в самом общем виде. Иными словами, им свойственно предполагать, что вы хотите решить «сразу всю проблему». Иногда это в шутку называют «преобразованием постоянного тока в дневное освещение», потому что в электротехнике ширина спектра частот может изменяться от нуля (постоянный ток) до бесконечности, т. е. далеко за пределами видимого света!.
Опасность сопряжена с двумя моментами. Во-первых, решать задачу для всего диапазона возможных значений параметров обычно гораздо труднее, чем для какого-то ограниченного его подмножества. Иногда общее решение вообще невозможно, хотя для какого-то ограниченного диапазона оно вполне осуществимо. Поэтому инженер может в бессилии развести руками, если не сообщить ему, что вас интересует решение только для некоторого конечного диапазона.
Во-вторых, и этот подводный камень еще коварнее, задача может иметь общее решение, а может не иметь, при этом инженер может суметь отыскать это решение, а может не суметь. В худшем варианте он считает, что решение есть, и пытается его найти, что ему не удается, потому что задача нерешаемая или он недостаточно способный. Это оборачивается большими расходами.
Наконец, есть вариант, когда проблема имеет общее решение и инженер достаточно способный, чтобы найти его. К несчастью, он ищет его слишком долго, и обходится это слишком дорого. Вам нужна лишь малая часть его результатов - одна десятая по объему и одна десятая по стоимости. Он горд собой, а у вас от всего этого остается неприятный осадок.
Единственный способ избежать этой дилеммы состоит в том, чтобы тщательно обсудить сущность задачи на шаге один и шаге три, а также обязательно определить, насколько общее решение вы можете себе позволить, на шаге четыре. Так что у вас есть много путей избежать этой ловушки. Не забывайте, что, как правило, невыгодно строить изгородь за $50, чтобы охранять лошадь, цена которой - $ 10.