Разговоры в курилке: как эволюционирует общение с ростом компании

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

Эта статья была написана по следам выступления Дмитрия. Здесь мы рассмотрим, как эволюционирует общение внутри компании по мере её роста, и какие проблемы возникают на каждом этапе.

Badoo, как и любая другая компания время от времени сталкивается со стандартными проблемами разработки:

• низкая производительность,
• снижение качества продукта,
• аварии и факапы.

Можно к этим трём добавить любые другие. Когда в Badoo начинают анализировать, в чём причина всех этих проблем, чаще всего произносятся такие фразы: «Я не получил твоё письмо» или «Меня часто отвлекали». или «Мы друг друга недопоняли, я не знал, что это важно».

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

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

Представим, что это два микросервиса, которые между собой общаются по сети. Сеть в какой-то момент может затупить, начать терять пакеты и т.д. Ситуация, когда у вас два сервиса — это ещё цветочки. Когда архитектура разрастается, сервисов (или человек) становится пять, количество точек отказа вырастает в квадратичной зависимости. Для пяти человек это уже 10, а если взять 100 человек, то точек отказа станет 5 тысяч.

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

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

Некоторые проблемы возникают уже на этом этапе. Рассмотрим три из них:

• личное общение порождает Context switch,
• решения, принятые в разговоре, забываются,
• излишнее доверие к коду или действиям хорошо знакомого коллеги.

Многие узнают себя на этой картинке. Что здесь происходит?

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

Для того, чтобы понять, в чем состоит эффект, нам понадобится немного знаний о мозге, в частности о префронтальной коре.

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

Еще одной интересной функцией префронтальной коры является то, что она в себе содержит операционную память. Существует правило 7±2, которое иллюстрирует способность человека держать в операционной памяти 7±2 однородных элементов. Если говорить о программировании, то там может быть, например, стек вызова функций в коде, над которым программист сейчас работает, или уровни вложенности кода, или просто список открытых файлов. Получается что-то вроде Cache. Когда человека отвлекают на любую другую задачу, этот Cache очень быстро сбрасывается. Для того чтобы его восстановить, вам приходится пройти все те шаги, которые вы проходили раньше, чтобы этот Cache заполнить.

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

Люди редко пребывают в состоянии потока 30-40 минут или больше. Скорее всего, человек в ближайшее время отвлечется, прочитает ваше сообщение и будет готов помочь. Понятно, что это должно работать в обе стороны: человек должен понимать, что такое правило в вашей небольшой команде принято. Если даёт понять, что занят (надел наушники, капюшон — что угодно), то его трогать сейчас не надо. Он ожидает, что если будет действительно что-то очень срочное, то к нему подойдут и по плечу постучат. А если этого не делают, он может выключить уведомления в чатах и включить их только тогда, когда он выйдет из состояния потока.

Ситуация обычно выглядит так: два программиста смотрят в код в попытке разобраться, что здесь вообще происходит. Решение совершенно неочевидное: «Я помню, что мы вроде так не делали, но кто-то же сделал!» И дальше они пытаются по каким-то commit message понять, что там происходило.

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

Можно добавить ссылку на тикет или сам тикет в commit message, когда будете выяснять, кто же это сделал, вы найдете ссылку на тикет, в котором зафиксировано:

• кто присутствовал при принятии решения,
• что обсуждали,
• что решили.

Это ещё одна проблема, которая возникает на этапе стартапа. Вовсе не значит, что доверие — это плохо. Но иногда, когда мы доверяем человеку просто потому, что хорошо знаем его, это приводит к неожиданным эффектам.

Представим себе ситуацию, что вы сидите вдвоём с коллегой, 9 вечера — поздно уже. Он хочет домой, но вам еще что-то надо выкатить на продакшен. У вас есть какая-то обычная процедура, как такие вещи выкатывать на продакшен. Но вы устали, он устал, вы знаете, что он ни разу ещё ничего не ронял, и думаете: «Да ладно! Поехали!» И следующие два часа, вместо того, чтобы поехать домой спать, вы чините продакшен. Потому что где-то бомбануло после того, как вы выкатили обновления.

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

Чтобы снизить вероятность ошибки в разработке, необходимы три вещи:

• Формальные требования к коду и процессу, зафиксированные письменно, чеклист.
• Ретро по результатам инцидентов с фокусом на возможное излишнее доверие.
• Тимлид, поддерживающий культуру в команде! Он должен помнить о первых двух пунктах и соблюдать их.

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

Здесь появляются новые проблемы, которых не было на этапе стартапа:

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

По мнению Дмитрия Марущенко каналы коммуникации по степени назойливости можно отсортировать следующим образом:

• телефон,
• личное обращение,
• чат,
• email,
• комментарий (в тикете, Вики).

Чем выше канал в списке, тем больше этот способ общения вмешивается в деятельность человека и отвлекает его. Интересно, что на первом месте здесь находится телефон. Не для всех это очевидно.

Для того, чтобы проиллюстрировать, почему он на первом месте, вспомним господина Паркинсона, того, кто придумал законы Паркинсона. В одной из своих книг он описал ситуацию: сидит начальник у себя в кабинете и решает проблемы своих посетителей. Человек приходит к нему в кабинет, садится перед начальником, открывает рот, начинает рассказывать о сути своей проблемы, и тут звонит телефон. Начальник поднимает трубку: «Да. Да-да-да. Сейчас мы это решим». И начинает решать какие-то проблемы по телефону. Через 5 минут кладет трубку: «Да, извините, отвлекся, продолжаем». Посетителю ничего не остается, кроме как начать всё заново. Но через 2 минуты ситуация повторяется: снова звонит телефон, снова начальник берет трубку, и посетитель уже понимает, что так дело не пойдет. Он встает, выходит из кабинета, идет на ресепшен и просит телефон этого начальника. Ему дают телефон, он звонит и за 3 минуты решает свою проблему.

Почему это происходит? Именно потому, что телефон отвлекает гораздо больше, чем, например, личное общение.

Личное обращение: вы подошли к человеку и видите, что он занят делом. Есть шанс, что вы, как человек разумный, отойдёте и вернётесь чуть позже. Телефон — это как если бы вы подошли к человеку и, встав рядом с ним, начали его дергать: «Дмитрий! Дмитрий!! Дмитрий!!!». Дмитрий рано или поздно просто вынужден будет отвлечься.

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

Примерно так иногда выглядит рабочий день Дмитрия:

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

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

Тут может помочь автоматизация в виде ботов и мессенджеров. Боты могут, например, парсить входящие сообщения в групповых или в личных чатах, и докидывать туда автоматическое сообщение. Например, вы в Jira упомянули какой-то тикет, и у вас появляется дополнительное сообщение с основной информацией по тикету. Очень полезная вещь! Если у вас есть возможность разработать себе такую штуку, сделайте это.

Есть огромное количество слов и фраз, которые разные отделы понимают по-своему, даже если они звучат одинаково. А ещё многие любят злоупотреблять аббревиатурами. И это тоже проблема.

Представьте себе, что у вас есть тикет, состоящий из сплошных аббревиатур. Человек, который недавно пришёл в компанию и который ещё не знаком со всеми аббревиатурами, очень хочет на такой тикет ответить тоже аббревиатурой из 3 букв.

Зачастую вы не понимаете, что делает другой отдел: «Мы работаем, а они непонятно за что зарплату получают». Часть людей вы вообще видите два раза в год: один раз на зимнем корпоративе, а другой раз на летнем корпоративе.

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

Например, в Badoo три разных отдела занимаются Machine Learning, но они работают в своих узких областях. До недавнего момента налаженной коммуникации между ними не было. Чтобы решить эту проблему в компании сделали следующее:

• Weekly digest — в интересной форме! Важно, чтобы дайджесты выходили в интересной форме. Иначе их никто не будет читать
• Внутренние семинары. Такие семинары в Badoo проводятся по пятницам. Любой, кто сделал клёвый функционал или разобрался в клёвом фреймворке, просто собирает коллег в большой переговорке или на кухне и рассказывает о том, что он сделал, со слайдами.
• Блоги в Confluence. Продакт-менеджеры Badoo ведут блоги в Вики Confluence. Там собирается в том числе thanks history от благодарных пользователей.
• Статьи, доклады. В Badoo любят писать статьи и делать доклады для Хабра или для конференций. Таким образом сотрудники компании обмениваются знаниями.

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

Никто никого не призывает открывать в офисах курилки! Но нельзя отрицать, что такое явление существует. Этим можно отлично пользоваться. Такими курилками могут выступать общие кухни, кофе-points и т.д.

В Badoo выработали несколько правил для совещаний, чтобы они не превращались в пустую трату времени:

• Совещания должны быть полезными! У каждого совещания должна быть цель и агенда, оно должно решать вполне конкретную проблему.
• Участниками совещаний обязательно должны быть люди, принимающие решения и сотрудники, обладающие знаниями для принятия решений. Никого больше на совещании быть не должно! Иначе всё превращается в холивары.
• Кворум! Это значит, что все люди, которые нужны для принятия решения, должны присутствовать на этом совещании. Если кого-то нет, то его мнение должно быть каким-то образом получено заранее: в письменном виде, онлайн по Скайпу и т.д. Ещё один вариант — отсутствующего представляет человек, наделённый полномочиями для принятия решений.
• Действия по итогам! По итогам каждого совещания должно быть принято решение: что, кто и когда делает, как выполнение решения контролируется.
• Follow-up письмо. Решение, принятое на совещании, должно быть зафиксировано письменно.

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

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

Люди, которые находятся в разных офисах, могут чувствовать:

• недостаток личного общения,
• разделение на свой-чужой,
• меньше доверия к коллегам из других офисов.

А вот, что помогает сотрудникам Badoo справляться с проблемой географической разделённости:

• командировки,
• совместные мероприятия,
• видеосвязь, постоянный телемост,
• кросс-офисные совещания с видеосвязью,
• кросс-офисное код-ревью,
• общие чаты.

Между Москвой и Лондоном разница во времени всего 3 часа, а летом вообще 2 часа. С одной стороны, разница не большая, но, с другой стороны, она сужает окно, когда вы можете пообщаться со своими коллегами. Зимой из 8 часов рабочего времени остаётся всего 5. Тут же вылезают проблемы с бронированием переговорок и т.д.

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

Есть способы смягчить эти проблемы:

• Сдвиг времени работы. Разница между Москвой и Лондоном нивелируется просто тем, что в Москве начинают работать чуть попозже, а в Лондоне чуть раньше — так расширяется окно для возможных совещаний и личного общения.
• Перевод части коммуникаций в онлайн. Это не очень хорошо, но, тем не менее, решает часть проблем, с этим связанных.
• Подготовка backlogs задач и списка вопросов к началу рабочего дня, когда разница 8 часов и более.

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

Проблемы с языковым барьером всем очевидны:

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

Как в Badoo решают эти проблемы?

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

Используйте жесты, переводчик на телефоне и т.д. Иногда можно использовать слова на родном языке. Мы все говорим на IT-сленге, в котором половина слов заимствована, и они звучат очень похоже. А ещё можно найти «подстраховку». Это человек, который, возможно, не знает вашей предметной области, но отлично знает язык. Когда вы начинаете коряво изъясняться, он слышит, что вас могут не так понять, и чуть-чуть поправляет.

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

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

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

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

Обратите внимание на три простых инструмента, которые помогут вам слышать и понимать коллег:

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

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

C 2007 года мы организуем конференции для разработчиков. В этом году решили провести Product Fest — профессиональную конференцию для тех, кто делает цифровые продукты. Присоединяйтесь! Собираемся 9 декабря в SAP Digital Space.

Продажа билетов уже стартовала, цена сейчас минимальная, но со временем будет расти. В программе — прикладные доклады по продуктовым практикам. Будем делиться не только историями успеха, но и историями провалов, расскажем о полезном опыте смежных индустрий. Подписывайтесь на наши соцсети: Facebook, Telegram, VK. Там мы будем знакомить вас с будущими спикерами, разыгрывать крутые штуки, тестировать гипотезы и спрашивать вашего совета, например, с кем проводить интервью.