Апр. 30

Как научить команду общаться. Прием для менеджеров

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

Проблема

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

Парню надо помочь и обучить, но что-то заставило меня не делать этого «с места в карьер». А что, если ко мне на проект выйдет еще один разработчик с такой проблемой, а потом еще один и еще?

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

Выбор метода

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

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

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

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

I. Адресность — общайся с тем, кто действительно может решить проблему.

II. Своевременность — общайся тогда, когда можно повлиять на ситуацию.

III. Аргументированность фактами — во время общения опирайся исключительно на факты.

IV. Намерение решить проблему, а не человека — целью общения должно быть решение проблемы, а не самоутверждение.

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

Является ли такое общение адресным? — Нет, он не с DevOps-ами общается.

Является ли своевременным? — Нет, CI-то уже лежит, и время мы только теряем.

Аргументированно ли такое общение фактами? — Да, факт на лицо.

Соблюден ли принцип «Намерение решить проблему, а не человека»? — Ну нет.

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

Создание тренинга

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

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

Вот наш чеклист от идеи к результату:

0. Утвердить бюджет с руководством компании.

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

В нашем случае тренинг занимал полтора часа и компенсировался контракторам по обычному рейту.

1. Создать презентацию.

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

Первый — зачем этот тренинг нужен компании и проекту понятно, а вот нафига он разработчику? Во время тренинга, для того, чтобы объяснить, я делаю вот что:

Уточняю у группы, какие скилы нужны для работы. Это Hard Skills, Soft Skills, английский.
Уточняю, понимает ли группа отличие Hard Skills от Soft Skills.
Говорю о том, что тренинг нацелен на повышение Soft Skills.
Потом показываю две картинки и спрашиваю, кого бы вы скорее взяли на работу?

Специалиста 1

Специалиста 2

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

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

Повторю принципы еще раз:

I. Адресность.
II. Своевременность.
III. Аргументированность фактами.
IV. Намерение решить проблему, а не человека.

Лучшие практики разбираем для следующих каналов:

Комментарии в таск-трекере.
Комментарии в системе контроля версий.
Общение в чатах.
Конференционные звонки.

Приведу пример разбора лучших практик для канала конференционные звонки:

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

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

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

Пример кейса:

2. Провести презентацию для пилотной группы.
3. Поправить презентацию.

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

4. Сделать презентацию о презентации ПМ’ам на проекте.

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

5. Разбить команду на группы 6-8 человек.

В нашем случае получилось 9 групп.

6. Провести презентацию всей команде в короткий срок.

Если презентацию могут проводить 3-4 ПМ’а, то можно и за неделю управиться.

7. Собрать обратную связь.

С помощью гугл формы. Тут можно поиграться, понять отношение команды к таким инициативам, самому тренингу, конкретному ПМ’у.

8. Profit.

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

Еще пару выводов

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

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

Надеюсь было полезно. Если что-то нужно осветить подробнее — пишите в комментарии или стучитесь в Facebook.

Успехов!