Кто такие эксперты?
Современные проекты в основном сложны. Если вам кажется, что проект прост, то вы, скорее всего, либо не обладаете полным набором необходимой информации, либо пользуетесь готовыми технологическими «строительными блоками», либо являетесь экспертом. Технический эксперт — это тот, кто разбирается в технологиях и способах их применения достаточно хорошо, чтобы его советы или его действия положительно влияли на проект в части качества результатов, рисков, бюджетов и прочих проектных параметров. Обычно технический эксперт вырастает (а, точнее, прорастает) «изнутри» своей индустрии. Технические эксперты из академических кругов, из финансовых кругов, из числа кабинетных менеджеров в дикой природе почти не встречаются. Исключения настолько редки, что проще предположить, что мы имеем дело с очередным шарлатаном-имитатором. Редкий Остап Бендер упустит возможность запудрить провинциальным шахматистам, пожрать на халяву и срубить легких деньжат. Но в этой статье мы не будем говорить о шарлатанах, а сосредоточимся на жизнедеятельности настоящих экспертов.
Помощь технического эксперта в проектах сводится к следующему набору действий, выполняемых в любых сочетаниях:
- Информационная поддержка принятия решений клиентом. Сюда входит подготовка аналитических записок, презентаций (включая их проведение), экспертных заключений и т.п., а также личное участие в совещаниях, конференциях, выставках и прочих очных мероприятиях, проводимых клиентом.
- Контроль качества технических проектов. Как правило, сюда входит работа с ТЗ, проектной документацией, графиками и т.п. вплоть до анализа профилей и резюме участников команды.
- Непосредственное участие в разработке проектных решений, от участия в мозговых штурмах до разработки проектной документации (или координации данной деятельности).
- Передача знаний, наставничество, внедрение лучших практик. Случается, что люди сами хотят научиться что-то делать лучше. Чаще всего этого хочет их начальство. Тем не менее, на технического эксперта возлагаются определенные надежды.
За перечисленные выше действия эксперт получает деньги. Очень часто эксперта приглашают на одну роль, но потом пытаются вынудить исполнять и другие роли из приведенного списка. Иногда это делается намеренно, чтобы получить работу бесплатно, но чаще всего это происходит непроизвольно по мере повышения доверия к эксперту. Подобное нужно ценить и быть готовым исполнять максимум предлагаемой работы. Разумеется, схемы оплаты труда эксперта должны быть гибкими и должны предусматривать подобные ситуации (например, быть почасовыми, как у адвокатов). Если эксперт внутренний (бедолага на ставке), то перечень его обязанностей формируются естественным образом в ходе проекта и естественным же образом постоянно растет. Что, впрочем, редко сказывается на его доходах.
Когда приглашают технического эксперта в проект, предполагается, что он уже «готовенький», и знает все, что требуется. Никого не волнует цена, по которой эксперту достались его знания, расходы, которые он понес, время, которое он потратил на обучение, изучение документации и систематизацию опыта. Эксперты не должны забывать об этом, обсуждая размеры оплаты своего труда, которую заказчик стремится рассчитать по «средней по больнице» ставке на специалистов с какого-нибудь рекрутингового сайта типа HH.
Чтобы не уходить слишком далеко от темы, далее по тексту мы будем предполагать, что эксперт достаточно хорошо мотивирован делать свою работу качественно.
Зачем кому-то манипулировать экспертным мнением?
Несмотря на то, что подобный вопрос звучит несколько наивно, важно очень хорошо понимать причины поступков людей. Не секрет, что технические люди редко обладают должным уровнем эмпатии и развитым эмоциональным интеллектом, позволяющим уверенно действовать в условиях сложных взаимоотношений внутри проектной команды. Технари склонны излишне рационализировать поведение других людей, искать (или даже изобретать) причины тех или иных поступков, предполагая, что все ключевые участники действуют исключительно в интересах целей и задач проекта. Вообще говоря, из того, что эксперт действует в интересах проекта, совершенно не следует, что этой же практики придерживаются прочие участники проекта. Люди в большинстве своем существа иррациональные, подверженные эмоциям. Если же они и принимают рациональные решения, то далеко не факт, что их рациональность распространяется на проект. Люди совершают поступки всегда в собственном индивидуальном контексте, состоящем из многих слоев — предыдущие события, отношения с другими, особенности характера, ожидания и общее видение будущего, ощущения и эмоции и т.п.
Рабочие лошадки проекта — инженеры, техники, программисты. По сравнению с экспертом эти люди обладают сравнительно узким кругозором и довольно однобоким пониманием ситуации. В этом нет ничего плохого, достаточно того, что каждый из них хорош в своем деле, зачастую требующем полного погружения и специализированных навыков. Иногда у специалистов возникают идеи. Специалистам их идеи кажутся несомненно заслуживающими внимания, они идут с ними наверх и получают там свой законный (или незаслуженный) ушат холодной воды на голову. Потому что в контексте всего проекта эти идеи могут потерять свою важность, их реализация может негативно сказаться на соседних областях проекта и все такое. Идеи «с мест» — первое место конфликта эксперта и линейных специалистов.
Противодействие линейных специалистов связано исключительно с защитной реакцией, которая возникает когда они чувствуют опасность. Каждый, кто действует в «поле», кто честно исполняет свои обязанности, принимает на свой страх и риск множество мелких, но важных решений. О которых менеджеры могут даже и не догадываться. Специалисты могут прятать свои «косяки», недоработки, могут бояться потерять влияние, авторитет. В плохо организованных коллективах линейные специалисты зачастую специально замыкают на себе ключевые вопросы, пытаясь тем самым еще больше упрочить свое положение в организации. Эксперт может без труда идентифицировать подобные узкие места и разрушить уютный мирок, создававшийся годами.
Люди зря считают себя рациональными существами. Под влиянием страха линейные специалисты чувствуют неприязнь к экспертам, а все, с чем приходится иметь дело — неконструктивная критика, вечная оппозиция ко всем нововведениям, даже саботаж — все это рационализация страха. Зачастую проще и эффективней работать со страхом как с первопричиной, нежели пытаться отбиваться от многочисленных нападок и неуместной критики, которые не кончатся никогда.
У менеджеров есть не меньше поводов опасаться экспертов. Особенно, если эксперт собирается давать советы в части методик и способов выполнения тех или иных задач. При реинжиниринге процессов неизбежно перераспределение влияния между участниками, а также его резкая девальвация в абсолютном значении. То есть, влияния становится меньше буквально у каждого менеджера. Неудивительно, что именно от мелких начальников мы получаем максимальный и яростный отпор.
Боссы покрупнее экспертов не боятся. Для них эксперт не угроза, но средство для достижения цели. Целью может быть выбор «карманного» исполнителя, выгодного для личного кармана технического решения, устранение конкурентов при дворе (в случае организационного реинжиниринга) и так далее. В придворной борьбе экспертное заключение является весьма существенным оружием, которое словно таран способно разрушить любые фортификационные нагромождения «дорогих коллег».
Приступаем к манипуляциям. Работа с письменными результатами
Результатами работы экспертов являются презентации и текстовые документы. Единственной доступной манипуляцией при работе с письменными документами является редактирование и искажение этих материалов. Не нужно опасаться серьезной редактуры — такие действия слишком заметны и требуют сопоставимых экспертных знаний. Обычно ограничиваются элементарными приемами:
- Выдергивание из контекста. Берем одну нужную нам табличку или страничку, даем ссылку на документ. Вряд ли кто-нибудь полезет изучать первоисточники. Например, если в документе или презентации есть таблица с «плюсами» и таблица с «минусами», очень просто взять либо то, либо другое в свой материал. Совет — не разбивайте плюсы и минусы на два разных слайда, делайте общую таблицу.
- Удаление неудобных абзацев или строк в функциональном анализе под видом «резюме». При умелом обращении такой способ творит чудеса, меняя изначальную идею до неузнаваемости. Совет — сшивайте абзацы логическими связями, почаще ссылайтесь на другие части документа. Приводите пронумерованные списки вместо буллитов и ссылайтесь на номера. Не бойтесь, если документ будет выглядеть немного странным, это все-таки не роман.
Крепко сшитый документ, содержащий резюме вначале и в конце, в котором на разные лады повторяется основная мысль, пронизанный ссылками на разделы, схемы и таблицы, станет настоящим адом для манипулятора, стремящегося исказить его суть при цитировании.
Если в презентации необходимо дать серию слайдов, последовательно раскрывающих какую-то мысль, используйте маленькие схемки в углу слайда, используйте приписку в заголовке «Слайд X из Y» и т.п. Годится любой прием, не позволяющий так просто
Манипулирование мнением эксперта «в реальном времени»
Экспертов часто приглашают на совещания, где они должны отвечать на вопросы, представлять свои материалы или просто присутствовать, придавая совещанию особый шик. Задача манипулятора в таком случае сводится к тому, чтобы вынудить эксперта сказать нужные слова, которые присутствующие должны запомнить и которые будут внесены в протокол (который, кстати, эксперт обычно даже не видит).
Как правило, в случае очных совещаний манипуляторами являются большие боссы. Такой босс может со скучающим видом слушать доклад эксперта, даже не задавая ему вопросы. Но как только эксперт скажет нужные слова, его прерывают и начинают запутывать.
Проще всего проиллюстрировать данный прием на примере. Допустим, есть два программных продукта — А и Б. Продукт А это многофункциональный монстр, он дороже в три раза и покрывает 100% требований, а также содержит еще 200% ненужных функций. Продукт Б дешевле в три раза, он более нишевой и покрывает 70% требуемых функций, требуя от компании добрать оставшиеся 30% с помощью других продуктов и их интеграции. Эксперт намерен предложить продукт Б, который с учетом всех дополнительных затрат выходит в два раза дешевле продукта А при покупке и в три раза дешевле в ходе эксплуатации. Но менеджер по продажам продукта А недавно зашел к одному из боссов с «интересным предложением».
Представим себе теперь, что на совещании эксперт докладывает о результатах своего исследования.
Эксперт: Продукт А является лидером рынка в своем сегменте, это мощное корпоративное решение…
Босс: Скажите, продукт А соответствует нашим требованиям на 100%?
Эксперт: Да, он соответствует нашим требованиям на 100%, но…
Босс: А продукт Б соответствует нашим требованиям на 100%?
Эксперт: Нет, продукт Б соответствует нашим требованиям на 70%, но…
Босс: Прошу занести в протокол, что продукт Б не соответствует в полном объеме нашим требованиям.
Занавес.
А теперь немного поможем нашему воображаемому эксперту не сесть в лужу в той же самой ситуации.
Эксперт: Несмотря на то, что продукт А является лидером рынка в своем сегменте, он обладает избыточной функциональностью по сравнению с продуктом Б…
Босс: Скажите, продукт А соответствует нашим требованиям на 100%?
Эксперт: Функциональность продукта А превышает наши требования на 200%, что негативно сказывается на его стоимости.
Босс: А продукт Б соответствует нашим требованиям на 100%?
Эксперт: Продукт Б покрывает большую часть наших требований (за деталями прошу обратиться к моему отчету), а также обладает широкими возможностями по интеграции для реализации полного объема функций с использованием вспомогательных программных продуктов, перечисленных на странице 123 моего доклада.
Занавес.
Хочется отдельно напомнить о различии понятий знание и навык. Мы знаем как нужно себя вести, что говорить, что делать. Но когда доходит до практики, мы почему-то поступаем не так, как нужно нам, а часто так, как нужно манипулятору. К сожалению, во время очных баталий на переговорах одних знаний недостаточно, необходимы прочные навыки применения знаний, которые формируются только на практике. Поэтому нет ничего зазорного в том, чтобы попасться на удочку манипулятора один, два или три раза. Но на четвертый раз нужно либо уже научиться, либо подумать о смене рода деятельности.
Манипулирование при помощи исходных данных
Самый распространенный способ манипулирования экспертным мнением со стороны больших и маленьких боссов. Эксперт в шахматной партии проекта является довольно сильной фигурой — если не ферзем, то офицером точно. Разница между проектом и шахматной партией заключается в том, что в проекте не все фигуры ходят так, как положено. Эксперт является исключением — он почти всегда ходит так, как положено. И манипуляторы этим его свойством активно пользуются.
Эксперт нацелен на успех проекта, на то, чтобы проект укладывался в определенные параметры (сроки, бюджеты и т.п.). В доверенной эксперту части проекта он стремится учесть и сделать все, что можно, для достижения цели, даже путем компромиссов. Именно склонность к компромиссам является ахиллесовой пятой эксперта. Необходимость компромисса возникает там, где невозможно «вписаться» имеющимися средствами. Эксперт в полной мере владеет техническим содержанием, знает слабые и сильные стороны тех или иных решений, знает пределы модификаций компонентов с учетом возможных технических рисков.
Чтобы вынудить эксперта принять определенное нужное манипулятору решение, достаточно поработать с внешними условиями и исходными данными. Таких возможностей у больших боссов предостаточно.
Вернемся к нашему примеру с продуктами А и Б. Эксперт при прочих равных, собирается предпочесть продукт Б. Но манипулятору требуется, чтобы эксперт добровольно посоветовал продукт А. Что может сделать манипулятор?
- Поработать в смежных областях. Например, собрать для эксперта отчеты о провальных внедрениях продукта Б и дополнить их отчетами о немыслимых успехах покупателей продукта А. Для этого достаточно взять реальные истории внедрения продукта Б и маркетинговые обещания по продукту А, которые внешне выглядят очень похоже, за исключением того, что первые — правда. Сюда же относится ссылка на успешный опыт эксплуатации продуктов А в соседних компаниях.
- Предложить эксперту заранее подготовленную форму для представления данных — например, набор критериев для функционального сравнения, включающий функции продукта А, которых заведомо нет у продукта Б. Подобное проще подать под видом «корпоративных стандартов».
- Поработать с проектными рисками в части сроков. Например, если поставка продукта Б занимает месяц, а продукт А отгружают за неделю, можно затянуть ситуацию, и обратиться за советом за три недели до дедлайна. Тогда эксперт не будет рассматривать продукт Б вообще.
- Поработать с проектными рисками в части бюджетов. Если дать эксперту понять, что компания битком набита сотрудниками, обученными использованию продукта А, а системные администраторы спят в обнимку с мануалами по продукту А и о другом слышать не хотят, то он учтет более низкие эксплуатационные затраты продукта А по сравнению с более дешевым по цене, но требующим переобучения сотрудников продуктом Б.
- Поработать с проектными требованиями. Нефункциональные требования «сверх ТЗ» — любимый прием. Ссылка на внешние требования, включая неформальные т.н. compliance. Самый распространенный случай — игра с информационной безопасностью. Тема эта мутная, допускающая ссылки на мифических и не очень «людей в погонах», их внезапно возникающие «непроходные требования», разнообразную «добровольную» сертификацию, ссылки на ГОСТы, допускающие вольные трактовки и т.п. Любой эксперт понимает, что трогать без веских на то оснований кормовую базу «специалистов по ИБ» выходит себе дороже.
- Поработать с объемами информации. Иногда эксперту сгружают тридцать томов технического проекта и дают три дня на анализ. Отказаться нельзя. Дать полноценное заключение — тоже.
Советы в к данному разделу банальны, но их нужно еще раз проговорить, чтобы в памяти сформировалась целостная картина.
Сравнивайте яблоки с яблоками. В таблицах сравнения функций продуктов крайне опасно оставлять пустые клетки с прочерками напротив названия функций. Редкий заказчик понимает необходимость той или иной функции, а прочерк понимает однозначно — это плохо. Прочерков должно быть меньше. Исключение может быть сделано только для анализа покрытия ТЗ. Но и там для каждого прочерка должна быть ссылка на другой продукт, закрывающий требования. Незакрытые требования в таблице — прямой путь в бан для продукта. Потому что по факту такие «прочерки» сгружают ответственность с эксперта на заказчика. И если эксперт знает, что делать с этой ответственностью, то заказчик не знает (именно поэтому он и нанял эксперта).
Проверяйте полученную информацию из независимых источников там, где это возможно. Больше общайтесь с простыми исполнителями — как правило, они не получают инструкций от менеджеров в части выдачи информации или, как обычно, берут на себя смелость трактовать эти инструкции по-своему.
Требуйте необходимую информацию в полном объеме! Важно при этом ясно понимать что вы вкладываете в понятие «полный объем» (в виде списка). Если это невозможно, в отчете в нескольких ключевых местах упомяните, что отчет готовится на основании не полного набора документов (обязательно перечислите какого). Не нужно освобождать манипулятора, который был обязан снабдить вас исходными данными, от ответственности за их полноту. Если вы имели роскошь предварительных переговоров с клиентом по вопросу организации экспертной работы, передавая ему список требуемых исходных данных, упомяните, что недостающие данные придется восполнять на интервью, что потребует увеличения длительности этапа предварительного сбора данных.
Чем проще вопрос, на который должен ответить эксперт, тем больше информации он должен перелопатить. Топ-менеджеров не интересуют детали. Им не нужно, чтобы вы вешали на них ответственность за выбор продукта А или продукта Б, компании А или компании Б. Если в результате вашей деятельности нет однозначного выбора, а есть только таблица сравнения на три тысячи строк, это равносильно отсутствию результата вообще. Понятно, что бывает заключение с входными параметрами: если X то А, а если Y, то Б. Но не нужно прятать за подобными «параметрами» свою несостоятельность или недостаток входных данных. Вы как эксперт получаете деньги за то, что упрощаете мир, а не за то, что делаете его сложнее.
P.S. Если захочется высказаться, прошу учесть, что в статье изложен структурированный личный опыт, поэтому, с одной стороны, она не претендует на универсальность, а с другой стороны, оспаривать личный опыт не имеет смысла, равно как и противопоставлять ему собственный личный опыт.
Автор: drosselmayer
