×Закрыть

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

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

Проблема

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

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

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

Выбор метода

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

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

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

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

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. Намерение решить проблему, а не человека.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. Profit.

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

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

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

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

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

Успехов!

LinkedIn

51 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

Якобы кейз с CI совершенно неинформативен. Вот пример:

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

Капитан Очевидность решил не посвящать читателей в «вежливо, ясно» и «суть», а ведь именно здесь была бы ценность статтьи, но нет.

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

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

Поскольку я занимаюсь проблемой комуникации лет может десять а то и больше, одним из самых интересных гайдов по комуникации считаю about.gitlab.com/handbook/communication. Конечно не всё подойдет всем, но какой-то общий знаменатель по этому поводу можно поставить. Лично у себя веду упрощенную версию подобного хендбука с примерами как хорошей, так и плохой коммуникации.

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

Ответ очень прост и сложен одновременно — единоразовыми или даже серийными тренингами никак. Это нужно проповедовать, зачастую долго и упорно, пока эффективная коммуникация не станет частью командной культуры. Причём всё это должно работать top->bottom.

Спасибо, Максим, полезная статья.

После него уже не может быть отмазок «я не умею», «не могу», «не знаю как».

довольно наивное утверждение

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

Главное, чтобы с той стороны так же не думали)

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

причём это старый армейский принцип «если что-то может быть понято неправильно оно будет неправильно понято» (к) (тм)

ЗЫ: кстати да это американская фишка «всё сделано как для тупых» например всё те же ж ПДД и соотв. дорожная ифраструктура вот написано прямо на асфальте причём правильными «растянутыми» буквами «slow» и всё понятно зато любимые советские задачки из экзаменов по ПДД «кто проедет первым а кто за ним» (к) (тм) вы шо дебилы нах. так вообще строить простите чтобы там надо было стоять и думать «я справа или слева и куда вообще дорога делась?» но для советского менталитета это нормально как известно советские люди самые умные и самые читающие в мире ))

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

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

Леша, всегда есть путь легче, но вы ж инженер, а не формошлеп, я надеюсь

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

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

т.е. вы хотите сказать конкретных примеров нет? ))

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

щетаю они обиделись ))

Так а зачем на код посмотреть хотели в итоге?

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

В моей практике плохие сообщения — это те, которые не несут никакой ценности адресату. Ну вот например с CI.
— CI stopped working, please help. (никаких деталей, что где когда?)
— CI does not run after my morning commit? It happened twice this week, I told you guys already to fix it! (passive aggressive, эмоциональный контекст, нет смысла)

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

Hi Mike,

The CI failed to run after my commit XXXX on pipeline YYYY. The following errors come in the log:
... (some stacktrace trash) ...

I've tried to resolve with these things:
1. ...
2. ...
3 ...

Please assist and welcome to ping me or my colleagues for any further details.

Cheers,
Brian

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

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

Должно быть:

— CI stopped working,

fiksite ssuki!

Робити надлаштування над спілкуванням в команді потрібно далеко не завжди. З досвіду менеджери часто переоцінюють важливість вербального спілкування і недооцінюють можливості інструментів, таких як звичайний git. Переоцінка пов’язана з особистим досвідом, так в менеджерів прийнято працювати, курси і т.д. де наголошують на важливості спілкування в команді. При налаштованому процессі, і злагодженій команді 90% ефективного спілкування між розробниками зводиться до перегляду пулл реквестів і резолву конфліктів в коді.

Привет, Миша. Спасибо за комментарий, обрати внимание на кейсы, которые мы разбирали с ребятами. Они как раз об общении в таск-трекерах и гите)

Так, я думаю що Ви розібрались в тому що робите, і дякую що поділились. Мій коментар це скоріше застереження для тих хто буде намагатись використати Ваш досвід в непідходящому кейсі. Наприклад погана комунікація може мати глибші першопричини. Як от продакт овнер не встигає за командою розробників. Або задачі які взаємоблокують розробників, або змушують їх часто перетинатись в функціоналі один одного. Команда QA не знає версії коду який тестує, її просто немає на сторінці. DevOps має час тільки на поточні операції, але немає часу на покращення деплойментів. Або дуже банальна проблема — низька якість коду. Ці кейси точно приведуть до проблем з комунікацією, але тут це буде тільки ’проекція’ реальних проблем. Коли цих проблем немає, а є продакт овнер який розумно розбиває рішення на проекти, проекти на модулі, і знає як це все працює, і сенйорні розробники — комунікація буде на висоті. Але не тому що для вирішення якогось питання знадобилось 1 пленінг і 3 повідомлення в slack, а не 1 пленінг і 5 повідомлень, і навіть не тому що ці 3 повідомлення більш інформативні і грамотні. Сподіваюсь Ви розумієте про що я)

Софт скилы — треть успеха, хард скилы и английский — без них никуда. Нет такой профессии «хороший парень»)

так, є така професійна хвороба в менеджерів, пояснювати проблеми софт скілами і шукати їх вирішення також софт скілами. дуже і дуже поширена. Насправді тільки кілька разів стикався з реальними проблемами з комунікаціями за всю карь‘єру. Коли на прохання щось заімплементити людина регулярно відповідала — ні, я не хочу)

Нет такой профессии «хороший парень»)

конечно есть! и это пиэм! ))

А как часто бывает(бывало),что после тренингов чз некоторое время всё вернулось на свои места?

Почти всегда, если потом не продолжают обучение в работе.

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

5 из 100 с первого раза обычно. С остальными нужно продолжать. В итоге всё одно останутся 5 из 100, которые не смогут, не будут и т.п.

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

Привет,Макс.Спасибо.Мне кажется,что тут главное терпение и еще раз терпение)

У нас было 3 локации, 55 разработчиков и и команда разработки на стороне клиента, а ещё комментарии в таск-трекере, комментарии в системе контроля версий, рабочий мессенджер, письма, конференционные звонки. Не то, чтобы это всё было нужно для проекта, но раз начал нагружать сотрудников совмещением обязанностей, то иди в своём увлечении до конца. Единственное, что меня беспокоило — это разработчики, общающиеся напрямую с клиентом. В мире нет никого более беспомощного, безответственного и безнравственного, чем программист после тренингов. И я знал, что довольно скоро мы в это окунёмся.

Орнул в голосину, спасибо)

Полная фигня

Да нет, не фигня, но самолюбования и балшита много — это да.
Но тему важную он поднял и описал один из путей ее решения.

описал один из путей ее решения.

Это какой? Пусть программисты по два-три часа рожают письма кастомеру?

А вот чтобы не рожали учить нужно. В чем разница в письме кастомеру или соседу по галере?

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

Соседу можно написать 3 магических слова, а кастомеру нужно изобретать что-то типа «к сожалению, данная идея малоосуществима и довольно рискованная, потому что...»

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

У тебя часто в жизни в письмах кто-то водой разливается?
Ты собираешься ждать ответы 5 дней?

Соседу можно написать 3 магических слова, а кастомеру нужно изобретать что-то типа «к сожалению, данная идея малоосуществима и довольно рискованная, потому что...»

Нахуя дохуя нахуярили? Расхуяривайте! Так?
Только это совсем не деловая переписка.

У тебя часто в жизни в письмах кто-то водой разливается?

Любые менеджеры почти всегда. 1 из 100 будет по делу, остальные море воды и иногда по делу.

Ты собираешься ждать ответы 5 дней?

Правило деловой переписки — ответ в течение суток.
Просто редкий птица долетит ... человек прочитает полностью и ответит на всё. Такова психика людей.

Нахуя дохуя нахуярили? Расхуяривайте! Так?
Только это совсем не деловая переписка.

Быстро! Эффективно! Работает!

Просто редкий птица долетит ... человек прочитает полностью и ответит на всё. Такова психика людей.

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

Быстро! Эффективно! Работает!

Быстро! Эффектно! НЕ Работает!

Возможно, что неполностью или нечетко

И ты в итоге тоже нечетко сделаешь и неполностью?

Быстро! Эффективно! Работает!

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

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

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

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

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

P.S. Этот коммент я писал 15 минут, при этом:
— я писал его на родном языке — я не боюсь ошибок
— человек которому я его адресую, тоже в совершенстве владеет этим языком — я не боюсь, что мои возможные ошибки будут совсем неправильно поняты
— мы находимся в едином культурном пространстве, и, например, понимаем о чем посыл про сексуальные предпочтения

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

Андрей, Вы правильно уловили суть, собраны базовые советы для людей, которые хотят улучшить soft skills. Soft skills потому так и называются, что их легко и быстро прокачать. Человеку, который никогда не видел снега стоит рассказывать и про его желтые оттенки)

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

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

и вот тут я повис. большинство из них вообще не качаются, как-то work ethic, потому что могут вести к ценностным конфликтам. да и вообще:
Soft skills are important job-related skills that involve little or no interaction with machines and whose application on the job is quite generalized. © это про происхождение термина.

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

Дуже круті стаття і кейс. :)

Дякую автору за те, що поділився.

С Божьей помощью, спасибо

наконец-то об этом написали! Спасибо.

Саша, спасибо, что почитал)

Подписаться на комментарии