Работа большой распределенной команды: преимущества удаленки (13 фото)

У удаленной работы есть два важных преимущества:

- эффективность, прежде всего по части коммуникаций. Около 70% времени решения задач разработки уходят на коммуникации, только 30% — на написание кода.
- найм и удержание классных разработчиков. Предлагая удаленную работу, мы обеспечиваем себе преимущество: можем нанимать людей, которые не хотят или не могут переезжать из своего города или страны. Например, я сам живу в самом лучшем городе в мире – Калининграде. Сколько еще крутых IT-компаний могут предложить мне удаленную работу? Ответ: около нуля.

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

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

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

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

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

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

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

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

3 — у нас много команд, иногда одна команда заказывает что-то другой, и ей нужно оценить ориентировочную и итоговую стоимость работы: посмотреть, сколько потрачено времени и умножить на базовую ставку;

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

У прозрачности есть несколько важных компонентов: актуальные статусы, актуальные remaining estimates, актуальный бэклог. Обеспечив все это, мы избавляемся от бесконечных вопросов от тимлида к разработчику, от продакта к тимлиду и т.д. из серии «когда это будет сделано», «сколько осталось» и «когда на проде». Все всегда можно посмотреть в таск-трекере.

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

Могу точно сказать, что здесь все статусы актуальные и все estimates расставлены верно, но у читателей сразу возникает вопрос: почему пустая колонка code review? Неужели не делаете? Делаем, но мы нашли способ, как обеспечить быстрое прохождение code review.

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

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

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

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

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

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

Ну а еще надо поднимать вовлеченность – ежедневные встречи, планирование и ретроспектива, один на один, вимбоксинги и квартальные презентации (это на самом деле не скучно). Недавно начали играть в Counter-Strike, сначала играли внутри команды, а на днях обыграли маркетинг.

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

Вот пример нашего рефакторинг-митапа:

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

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

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

Начнем с тикетов в Джире. Мы используем стандартную Agile практику, у нас практически все тикеты формулируются не задачами (что надо сделать), а проблемами (пользовательский опыт). Это важно при удаленной работе. Вот пример фикса:

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

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

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

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

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

Ну и наконец – Гоша Live. Наш директор раз в месяц собирает всех сотрудников в онлайне и рассказывает о глобальных результатах и планах, после чего проходит сессия Q&A.

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

Самый большой отрыв по времени сейчас – +7 от Москвы. Это не проблема для митапов в 11 по Москве, а дальше кейсы решаются договоренностями. Если случилось такое, что тебе надо прямо через минуту получить ответ, значит, что-то не так с процессами, их надо перестроить. У нас нет ситуаций, когда надо здесь и сейчас решить рабочий момент. Если же это форс-мажор, то он никак к часовым поясам не привязан, все равно может случиться и среди ночи.

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

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

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

Ответ простой: слак – это дешево, а живое общение – дорого. Вы сидите в офисе, работаете, делаете задачу; тут коллега тыкает в плечо и задает вопрос, вы отвлекаетесь, начинаете отвечать. Да, есть практика красной папки, которую можно положить на стол, чтобы вас не трогали, но она тоже работает не так хорошо, как хотелось бы. Изменим ситуацию: человек подходит к соседу и начинает с ним тихо о чем-то говорить, вы слышите какие-то ключевые слова типа «вимбокс», думаете, что сейчас они что-то решат без вас, невольно начинаете прислушиваться и отвлекаетесь от своей задачи. Или идете на кухню, видите Глеба, ваша воспитанность не позволяет просто пройти мимо, вы говорите: «Привет, Глеб, как там дела с аналитикой?» и Глеб 15 минут рассказывает про все свои задачи. Вы с ним потеряли по 15 минут. В офисе смазана граница между работой и коммуникацией, и коммуникации часто бессодержательны.

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

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

Мы пытаемся сделать коммуникации супер-адресными. Если у нас есть канал на всю команду, он предназначен только для того, что нужно/интересно всем, туда нельзя постить по отдельным проектам. Любое сообщение всегда адресовано конкретным людям, которым оно нужно. В больших каналах у нас запрещено использовать теги @channel и @here. У каждого канала должно быть понятное описание и именование по конвенции: название команды, подразделение команды, цель. Есть даже специальная слак-полиция, которая прибегает через две минуты, если, например, назвать канал не по конвенциям. Они же отвечают за то, чтобы у каждого была аватарка с фото. Я видел другие команды, где вместо аватарок с лицами использовались стандартные значки из Слака. Сразу возникало ощущение, что это внутренний технический инструмент, а не общение с людьми.

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

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

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

Вимбоксинги надо правильно организовать. Если вы назначите такие встречи и спросите “Кто хочет выступать?”, то с высокой вероятностью выяснится, что никто. Мы задаем другой вопрос – “Кто про что хочет послушать?” И участники команды говорят: я хочу послушать Глеба, потому что мне интересно узнать о его аналитических инструментах. Или: я хочу послушать Диму, потому что он сделал интересную задачу по поиску. Дальше голосуем за каждую тему, если собрали достаточно голосов, то говорим человеку: тебе придется рассказывать. Пока отказов не получали, проводим раз в неделю или две.

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

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

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

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

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