Как подобрать людей, понимающих друг друга с полуслова

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

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

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

Руководитель проекта был бы в этом проекте отличным исполнителем, а вот как руководитель проекта – не справился. Не справился с коммуникациями в проекте.

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

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

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

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

Итак, для начала немного статистики. Ведущая международная организация в области управления проектами PMI (Project Management Institute) утверждает, что до 90% времени руководителя проектов занимают коммуникации. Собственно работа руководителя проекта (в идеальном случае) состоит в том, чтобы грамотно организовать работу специалистов, входящих в команду проекта, а не самому, засучив рукава, браться за лопату.

Следующий вывод – уже мой: в 90% проектов плану коммуникаций отводится недостаточно внимания. Часто он просто не составляется вообще. Хотя грамотно подготовленный план коммуникаций проекта (а также план эскалаций) может заранее снять некоторые острые вопросы и сберечь для команды время и нервы. По моему опыту, совмещенный план коммуникаций/эскалаций можно разместить на одной странице формата А4, и он будет рабочим документом.

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

• Проблема 1. Два человека должны работать совместно, в команде. Как быстро определить, смогут ли они качественно общаться между собой? Не всегда есть время на то, чтобы съесть вместе пуд соли.
• Проблема 2. Более сложная. Совместимость одного человека с группой людей (например, руководителя проекта и команды проекта). Зная о возможных конфликтах в будущем, можно снизить риски этих конфликтов.
• Проблема 3. Есть группа людей – команда, которым работать вместе. И в начале проекта неизвестно, все ли члены команды смогут эффективно общаться между собой.

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

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

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

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

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

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

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

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

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

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

Классификация мира

• Люди
• Ценности и результаты
• Процессы и процедуры
• Вещи и действия
• Время
• Место

Размер информационного блока

• Крупный
• Мелкий

Способ мышления

• Детализация
• Аналогия
• Обобщение

Ведущая сенсорная репрезентативная система

• Визуальная
• Аудиальная
• Кинестетическая

Фокус сравнений

• Сходство
• Сходство на различие
• Различие
• Различие на сходство
• Различие на новое

Мотивация

• К позитиву
• От негатива

Референция или фокус силы

• Внутренняя
• Внешняя
• Другие
• На контекст

Время: ориентация

• Прошлое
• Настоящее
• Будущее

Время: продолжительность

• Включенное время
• Сквозное (точное) время

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

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

1. Сравнение двух участников проекта между собой – процент совместимости по коммуникациям. Если процент чрезвычайно низкий – попробовать заменить напарника (ротация в рамках проектных задач).

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

3. Определение того, кто из команды проекта может оказаться источником конфликтов/некачественных коммуникаций. Для этого программа сравнивает профиль «каждого с каждым» и выдает результат в виде матрицы, подсвечивая красным возможные проблемы с коммуникациями.

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

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

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

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

Впервые статья была опубликована на Executive.ru в рубрике «Творчество без купюр». Реанонсирована в контентном блоке в рамках специального проекта редакции.