Как эффективно работать с удаленными разработчиками - опыт Skyeng

Директор по продукту онлайн-школы Skyeng Харитон Матвеев написал для vc.ru колонку о том, как организовать удаленную работу с разработчиками: плюсы, проблемы, особенности и рекомендации.

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

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

Зачем нужна удаленка

Очевидное преимущество - экономия расходов на содержание офиса - не главное. Главное - это возможность выбора среди большего числа претендентов: закон больших чисел в действии. Когда мы работали в минском офисе, мы должны были искать разработчиков среди миллиона жителей города. В Москве у нас уже был выбор в десять раз больше. С удаленкой мы имеем поле в 200 миллионов человек - весь СНГ к нашим услугам. Таким образом, шанс найти идеального работника заметно повышается.

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

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

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

Особенности поиска сотрудников

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

Проблема коммуникации

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

Объясним на простом примере. Есть программист Вася, он ИП, пишет программы в одиночку. Производительность его труда мы примем за условную единицу. Бизнес у Васи идет в гору, он решает нанять второго программиста, теперь они работают вдвоем. Однако суммарная производительность их труда вовсе не превращается в двойку, она оказывается на уровне от 1,5 до 1,8 единиц производительности одинокого Васи. Все остальное время тратится на коммуникации между двумя программистами.

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

Люди тратят около 70% своего рабочего времени на общение и лишь 30% - собственно на производительную деятельность. И это вовсе не катастрофа - это нормальная работа, но соотношение наглядно показывает важность выстраивания эффективной системы коммуникации между сотрудниками. Потому что если коммуникации просядут всего на 10%, то производительность труда обрушится в полтора раза; напротив, незначительное повышение эффективности общения приведет к заметному ускорению работы.

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

Поэтому эффективная разработка - это в первую очередь эффективная система коммуникаций.

Что нужно сделать:

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

Каналы коммуникации

Мы выделяем три вида общения.

1. Документация

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

Это своего рода театр одного актера: как правило, один человек наполняет канал данными, остальные участники читают (и своевременно получают уведомления об изменениях). В идеале коммуникации должны максимально мигрировать в документацию: чем полнее все описано в Confluence или в тикете JIRA, тем меньше времени будет тратиться на обсуждение деталей в чате.

2. Переписка и чаты

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

3. Голосовая и видеосвязь

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

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

Сила прерываний

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

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

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

Мотивация

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

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

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

Удаленка эффективнее офисной работы?

Мы считаем, что да.

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

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

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

Если грамотно подобрать инструменты и настроить коммуникацию, она будет отнимать значительно меньше времени, чем при работе в офисе. А следовательно, вырастет эффективность и производительность труда.

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

Чек-лист эффективной коммуникации

• На удаленке люди друг друга не видят, это создает ощущение изоляции. Поэтому, как бы нелепо это ни выглядело, нужно, чтобы у всех в Slack, Jira и Confluence были аватарки. Они «очеловечивают» общение, делают его более личным. И еще мы активно поощряем использование «реакций» (что-то типа эмотиконов).
• По той же причине во время звонков и конференций по Skype мы всегда используем камеры. Причем подходим к этому достаточно серьезно - например, следим за светом, чтобы лицо не оказывалось в тени.
• Не забываем приветствовать в общем канале Slack всех новых сотрудников. Им приятно, а коллеги в курсе, кто это. И поздравляем с днем рождения - это лучше делать в Skype.
• В удаленной разработке важна прозрачность - надо знать, кто чем занят: вчера, сегодня, завтра. Поэтому необходимо потратить время на настройку дашбордов в JIRA.
• Важна грамотная организация и навигация по документам, иначе в них нет смысла. Например, конвенции для программистов должны быть внятно структурированы, чтобы новый сотрудник без труда нашел все, что ему нужно, а не читал все подряд.
• В Slack у нас есть множество каналов, покрывающих разные области работы. Важно, чтобы сотрудники научились писать в нужные каналы - этот навык приходит не сразу. Он похож на раздельный сбор мусора - сперва непривычно и неудобно, но понемногу все привыкают.
• Добавлять в каналы надо только нужных людей, а не всех, кому «интересно». Это избавляет от лишних прерываний.
• Необходимо, чтобы сотрудники научились пользоваться инструментом «Наблюдатели» (Watchers). Каждый человек, создавая и редактируя документ, должен понимать, кому этот документ нужен. Если человек подписан на что-то, он получает уведомления об изменениях. Необходимо прививать эту культуру - чтобы нужные люди сами следили за нужными вещами, иначе они не знают, что где происходит, у них начинают различаться картины мира, начинаются проблемы, а решать недопонимание - очень и очень дорого.
• Очень полезен инструмент упоминания кого-либо в сообщении (@), он присутствует во всех системах. У упомянутого сотрудника он повысит приоритет сообщения; он ответит в том канале, где он был упомянут, и все, кому нужно, увидят эту переписку. Если писать в личку - придется потом не забыть все скопировать.
• Наконец, надо не забывать копировать переписку в тикет JIRA. Обсудили, нашли решение, копи-пейст, теперь в курсе все, кому это нужно. Никому не придется ничего дополнительно объяснять, никаких мискомуникаций не случится. То же касается и апдейтов документации в Confluence по итогам переговоров.