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

В феврале 2020 года наш COO Алексей Лихачев выступил с докладом на конференции TeamLead Conf 2020 в Москве. Он поделился опытом компании Evrone по успешному управлению удаленными командами.

Evrone с первого дня существования создана для удаленной разработки. У нас есть несколько офисов в разных городах и странах, но «удаленка» — это ключевая особенность Evrone на протяжении последних 10 лет.

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

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

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

Разработчики оставляют после себя много цифрового следа. В том числе:

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

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

Задачи

Первый вопрос, на который должен ответить тимлид: «Что делает разработчик?». Чтобы было легко ответить на этот вопрос, мы ввели правило: в каждый момент времени в Jira у каждого разработчика «взята» одна задача.

Не должно быть пустых или заваленных тасками столбцов «В работе» — только одна актуальная задача. Если тимлид видит, что Jira неактуальна, он выходит из тени и подсказывает разработчику, что нужно исправить.

Трудозатраты

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

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

Коммиты и пуши

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

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

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

Код-ревью и результат

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

Мы в Evrone иногда практикуем ранние код-ревью. Также мы смотрим на результат работы на препродакшене, стейджинге и продакшене.

Важный момент — у нас в компании все разработчики могут ревьюить код друг друга. Ни один сеньор не ответит джуну на его комменты: «Отстань, мальчик». В Evrone такое представить невозможно.

Slack и ERP

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

На высоком уровне контроля — корпоративная информационная система позволяет ответить на вопрос чем будет занят разработчик через 1-2 месяца.

Коммуникация каждый день

Daily meeting позволяет быстро узнать о том, что разработчик возможно делает не то, что нужно. Этот инструмент в Evrone используется по стандартной, привычной многим схеме методов разработки Agile: «Что делал, что буду делать, какие были проблемы». Дополняя рассказ разработчика на daily meeting другими цифровыми следами, тимлид может быстро уловить ситуацию расфокусировки у коллеги.

Contribution Activity

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

Внимательность и проактивность

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

Взаимные оценки

Примерно раз в 3 месяца мы рассылаем разработчикам короткий опросник и просим оценить коллег по критерию соответствия ожиданиям: «Не дотягивает», «Нормально», «Превосходит ожидания».

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

Оценка сроков

Мы в Evrone оцениваем сроки разработки с двух сторон. Сперва свою оценку предлагает сотрудник. Затем в нее приходит тимлид, и со своей стороны помогает лучше оценить задачу: где-то взять больше времени, предчувствуя неочевидную проблему, где-то — ускориться. Мы почти не используем групповую оценку сроков (за исключением случаев, когда разработчики сами хотят «поиграть» в нее). Задача — не загнать разработчика как скаковую лошадь, а помочь выбрать такие сроки, которые он сможет выдержать. Также инструмент Remaining Estimate в Jira наглядно показывает, в каких задачах «поплыли» сроки.

Оценка квалификации

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

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

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

Конференции и митапы

Мы в Evrone позволяем каждому разработчику раз в год бесплатно посетить конференцию из большого списка. Компания берет на себя все затраты: перелеты, билеты, проживание. По тому, какую конференцию выбирает разработчик, тимлид косвенно может сделать вывод о его направлении развития. Например, некоторые наши бэкенд-специалисты выбрали в 2020 году QA-конференции — это значит, что им интересно смотреть на то как развивается мир вокруг.

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

Анонимный фидбэк

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

Вместо вывода

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

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