Правила работы удаленной слаженной команды

В 2014 году я был одним из 5 удаленных разработчиков в Skyeng. Сейчас у нас 80 разработчиков из разных городов и стран и все мы по-прежнему работаем удаленно. Почему так сложилось? У удаленной команды много преимуществ. Нам проще нанимать и удерживать людей. В России компаний, готовых формировать штат таким образом, очень мало. А талантливых людей в Томске, Новосибирске, Благовещенске, Красноярске много. Они могут работать в крутой компании, но не могут уехать из родного города. Работа с нами для них – золотой шанс. К тому же нам проще масштабировать – не нужно открывать офисы, чтобы подключить город в свою компанию.

Однако при всех плюсах многие видят в организации удаленной работы массу проблем.

Я выбрал топ-3 вопросов, которые мне задают очень часто и о которых мы сегодня поговорим.

Во-первых, как сделать единую команду? Ведь мы не сидим все вместе в одной комнате, у нас нет командного духа.

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

И наконец, как контролировать, что разработчики действительно работают, а не пьют пиво и лежат на диване?

Как нам сделать, чтобы все чувствовали себя частью одной команды?

Используйте видео

Начнем с того, что мы общаемся по видеосвязи. Мы должны видеть друг друга и понимать, что мы работаем с настоящими людьми. Поэтому любые планерки и разговоры – это всегда видеосвязь. Но не только. У нас есть правило – ставить на аватарку в Slack свою реальную фотографию, а не значок или пейзаж с закатом. Это тоже помогает держать в голове, что твой коллега – не функция, а реальный человек.

Выстраивайте коммуникацию

Чтобы сотрудники не чувствовали себя оторванными от команды, мы продумываем коммуникации. Например, профиль в том же Slack полагается заполнять. Это помогает избавиться от лишних вопросов вроде какой у тебя email?.

У нас вообще есть целый набор правил для эффективной коммуникации.

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

Во-вторых, у нас налажена асинхронная модель общения. Мы никого не заставляем отвечать сразу же, в течение пяти минут. Когда половина сотрудников в Питере, а половина – в Таиланде, это просто невозможно. У нас все процессы выстроены так, что мгновенный ответ не требуется практически никогда.

Кроме того, мы разделяем потоки информации. Мы используем Slack и у нас есть каналы подразделений, каналы команд, каналы проектов, каналы эдхок обсуждений. Мы стараемся сделать так, чтобы каждый подписался на тот канал, который ему нужен, а не на все подряд. Иначе сотрудник утонет в этом потоке информации.

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

Встречайтесь чаще

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

Приведите команду к общему знаменателю

Смешивать удаленщиков и тех, кто работает в офисе – ошибка. Я сам работаю удаленно, у нас есть офис и я не люблю, когда на общем созвоне я, как голова профессора Доуэля на ноутбуке, общаюсь с людьми. Либо мы все работаем удаленно, либо мы все работаем в офисе.

Что делать с мотивацией?

Дайте контекст

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

Объясните разработчику, зачем он делает свои задачи

Это не всегда очевидно. Например, у нас был скрипт, который нужно было ускорить. Учителя ждали выплат но 7 часов, хотя это могло произойти за 5 минут. По закону больших чисел из 7 000 преподавателей какая-то часть увольнялась к вечеру, потому что им казалось, что так долго ждать неудобно. Одно дело - просто сидеть с абстрактным скриптом, и совсем другое – понимать, что это напрямую влияет на людей.

Проводите аналитические стендапы

Разработчикам важно понимать, что именно их фича дала пользователям. Аналитика рассказывает, что конкретно зашло, а что нет. У нас практически у всех команд есть метрики и каждый видит, на какие показатели он можешь влиять.

Как контролировать разработчиков?

Давайте свободу

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

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

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

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

Обеспечьте прозрачность

Слишком много свободы без прозрачности – это хаос. Поэтому мы стараемся сделать так, чтобы все знали, что у нас происходит. Менеджер заходит на доску – и как на ладони. Для этого у нас есть боты, которые заставляют разработчиков проставлять актуальные статусы, чтобы это не делал тимлид.

Оценивайте результат

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

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