Главный страх компаний, которые вернулись в офис, когда это стало возможным, — потеря контроля над командой. Высоковата получается цена ошибки, если разработчик с его-то зарплатой сидит и ничего не делает.
Но реалии таковы, что удаленка стала must have для найма. И как тогда контролировать? Что выбрать, чтобы наблюдать за сотрудниками — системы трекинга времени, средства трансляции рабочего стола?
А если мы скажем, что ничего? Не надо тратить ресурсы на лишний контроль. И деньги сэкономите, и людям поможете раскрыться.
Под катом рассказываем, как это у нас работает уже более 5 лет.
Если удава измеряют попугаями, то почему бы не измерить разработчика строчками или минутами?
Начнем с того, как делать не надо
Мы наблюдаем за коллегами по цеху, спрашиваем наших разработчиков о том, с чем им приходилось сталкиваться в своей практике на предыдущих проектах. Складывается ощущение, что чем серьезнее “закручивают гайки” в той или иной организации, тем легче при желании обойти внутренние правила, поскольку появляется ложная иллюзия контроля и на другие стороны разработки уже просто никто не смотрит.
Вот ТОП-6 бессмысленных идей о контроле команд:
- Бессмысленно снимать скриншоты рабочего стола. Беспокоитесь, что на экране разработчика должна быть открыта IDEA без каких-либо дополнительных окон с фильмами? А что ему мешает открыть IDEA, заставить мышку периодически дергаться и включить себе фильм на личном ноутбуке рядом? Отследить, что он ничего не делает, будет сложнее.
- Нет смысла использовать секундомер для очень детальной оценки рабочего времени, потраченного на каждую задачу. Количество потраченных секунд ничего не говорит о качестве решения и объеме выполненной работы. Иногда сложнейшую задачу можно сделать за 2 часа, а простой баг искать неделю. А с точки зрения командной работы в принципе важно не сколько человек потратил на решение, а уложился ли он в заданное время (собственную оценку или срок, поставленный на планировании). А еще решил ли он задачу качественно, чтобы она не вернулась ему обратно на доделку. Можно ведь сделать двухчасовую задачу за час так, что она вернется после тестирования еще на час (и это уже 2 часа плюс ресурсы QA и сдвиг планов).
- Нельзя измерять трудозатраты разработчика строками кода. 2 строчки кода могут “стоить” 5 минут времени или недели работы, в зависимости от сложности задачи. А сложность в этой метрике не заложена вообще.
- Не стоит измерять качество кода количеством “прилетевших” багов без учета характера этих багов. Иногда метрики количества багов на фичу или соотношения времени исправления багов и времени реализации фичи показывают правду о качестве кода. Но что делать в ситуации, когда баг прилетает из-за изменения требований (разработали все по старым требованиям, а тестировали по новым)? Кому в минус надо записать этот баг? И кто должен тратить ресурсы на разбор каждого бага, чтобы честно посчитать метрику?
- Не полезно вычитать время коротких перекуров из длительности рабочего дня. Периодические перерывы необходимы. Нельзя 8 часов просидеть на рабочем месте, не вставая. Есть режим труда и отдыха. На длинной дистанции (от 10 лет стажа и более) производительность будет лучше у человека со здоровыми привычками. А многие еще и думают над задачей во время этого короткого променада. Но если заставить специалистов точно рассчитывать время перекуров и “перечаев”, отрабатывая его в конце рабочего дня, можно пошатнуть их мотивацию. А она для проекта намного важнее. Да, человек отработает в итоге эти 25 минут, накопившиеся за день, но потеряет ощущение свободной работы в удовольствие.
- Не стоит загружать разработчиков лишними метриками, повлиять на которые они не могут. Даже банальное соотношение времени на реализацию фичи и времени, потраченного на исправление багов в ней, может и не характеризовать его код. Как мы отметили выше, надо разбираться в сути ошибки — быть может, там доступ к базе “сломался” во время тестирования? Если каждый раз человек будет бояться за свою судьбу на проекте из-за колебания этих метрик, комфортной работы не выйдет.
Лишние метрики, точный учет времени и прочие элементы контроля требуют поддержания определенных рабочих процессов. К примеру, если есть аналитика с точностью до секунды, кто-то и зачем-то должен ее использовать? А если есть по 100 фоток рабочего стола каждого специалиста за день, кому-то придется их смотреть. Так что все эти идеи не только создают ложное ощущение контроля над ситуацией, но и пожирают ресурсы, которые могли бы пойти на развитие проекта.
Мы так не работаем.
Контроль без контроля
Наш подход — оставить атмосферу максимально свободной, контролируя и подстраховывая проект незаметно. Это не значит, что контроля нет. Но он реализован на другом уровне и вписан в работу так, что нам не приходится тратить дополнительные ресурсы на обслуживание самой системы контроля. И все это опирается на профессионализм команд, подробную документацию на проектах и четкие требования — иными словами, нормальное разграничение полномочий, где люди с разными ролями не должны лезть в соседнюю область и могут положиться на решения друг друга.
Контроль на уровне мерж-реквеста
Мерж-реквест — лучший показатель эффективности работы специалиста. Но применять к нему какие-то универсальные метрики нельзя. Гораздо проще опираться на профессионализм тимлида.
В нашей практике проектные задачи максимально декомпозируются и раздаются желательно по одной в руки. Да, бывает когда в работе находятся две задачи. Но посмотрите в глаза правде — в какой-то один момент времени человек все равно размышляет над чем-то одним. Он не может левой рукой писать код по одной задаче, а правой — по другой. В итоге все равно приходим к практике “каждому по задаче”.
Когда тимлид хорошо знает код и команду, он с первого взгляда видит, сколько примерно займет решение той или иной задачи у конкретного человека. За задачу берется узкий специалист в этом вопросе, который сейчас на пике своей производительности? Или может ее дали новичку, который хорошо знает стек, но ему придется разбираться в проекте? Оценки в первом и во втором случае могут различаться в два раза, но это всегда более-менее понятная величина.
А изучение мерж-реквеста дает почву для размышлений о том, соответствует ли потраченное конкретным человеком время тем изменениям, которые он внес. Если работы на час, а задачу делали два дня — это повод поговорить. В остальных случаях все должно идти своим чередом. Разработка — сложная и творческая задача. Не надо напрягать лишним контролем тех, кто ей занимается.
Контроль на уровне человека
Это еще один уровень, за который ответственен тимлид.
Чтобы видеть в специалисте ответственное или, наоборот, безответственное отношение к работе, не надо быть психологом. Если человек сам оценивает, что сделает задачу за 2 часа, а потом каждый день на протяжении недели говорит “будет сегодня вечером”, — значит происходит что-то не то. Тимлид или вышестоящие менеджеры отлично замечают такие “звоночки” и идут смотреть статистику в Jira еще до того, как это стало критично для проекта. А дальше такие вопросы решаются в индивидуальном порядке.
Контроль на уровне команды
А на этом уровне контроля в нем фактически участвует вся команда.
У нас проекты никогда не пилит один человек. Но в то же время у нас нет команд по 100+ человек, где легко “спрятаться”. На каждый новый проект выходит команда из небольшого (минимально необходимого) количества людей с разными ролями — аналитики, фронт, бэк, тестирование, тимлид, менеджер проекта, владелец продукта и т.п. У каждого есть свой сегмент ответственности.
Предположим, один из них решил “залечь на дно” и ничего не делать. Это мгновенно отразится на проекте. Если свой выход пропустили аналитики — вся команда не знает чем заняться… Застрянет бэкенд — фронтенд это заметит, QA будет нечего тестировать — весь график проекта поползет, ведь результат, как бы это банально не звучало, зависит от каждого.
Если что-то пойдет не так, на дейли это будет заметно уже на следующий день — остальные участники команды поймут, что очередной этап не готов — следующему подхватывать нечего.
Контроль на уровне клиента
У нас есть не только собственный проект, но и совместные разработки с заказчиками. На таких проектах добавляется еще один уровень контроля — сбор обратной связи от клиента. Проектный менеджер с нашей стороны регулярно общается с клиентом, получая оценки работы команды и конкретных специалистов. Кстати, там же обсуждается, куда каждый из специалистов может вырасти в рамках проекта.
А зачем тогда тайм-шиты?
Все просто — это финансовая отчетность. Мы заполняем тайм-шиты для удобства финансовых консультантов. Глобально они больше никому не нужны.
Иногда данные из тайм-шитов используются для решения побочных задач. Но это не общая практика. Например, у нас была мысль сравнивать время, зафиксированное в этой отчетности, и оценку на планировании задачи, чтобы вывести некий “коэффициент ошибки” (и использовать в будущем планировании). Но проекты разные и люди в них участвуют разные — найти универсальный коэффициент будет сложно.
Также при заполнении тайм-шитов мы иногда пробуем списывать время, потраченное на митинги, на специальные задачи в Jira. Но в основном этим занимаются тимлиды и вышестоящие менеджеры, анализируя свой день. И обычно это их личная инициатива, которая не вводится в масштабах команды. Рядовому разработчику с 1-2 короткими созвонами в день нет смысла вводить такие сложности. Работая над одной задачей единовременно, он и созванивается либо по этой задаче, либо чтобы решить какие-то “корпоративные” вопросы (собеседование, например).
Как разбирать промахи, не закручивая гайки
Ошибок не совершает только тот, кто ничего не делает. У любого может временно просесть производительность из-за каких-то личных обстоятельств или профессионального выгорания. Главное не тиранить человека, особенно в этот момент, ведь он и так на нервах. Лишний контроль и тем более выливание негатива только создает большую напряженность.
Если разработчик ошибается, тимлид его подстраховывает, стараясь, чтобы факап минимально отразился на проекте, а потом уже разбирается, что произошло. Обычно достаточно убедиться, что человек знает о проблеме, и оставить его в покое, чтобы он сам разобрался. В отдельных случаях, например когда первый раз ошибается разработчик, который совсем недавно в команде, тимлид может подключиться параллельно, чтобы подстраховать проект. Но если про разработчика известно, что он всегда сам отлично справляется, тимлид может в этом и не участвовать. Главное, чтобы в среднем работа шла хорошо — чтобы после ошибок или падения производительности человек восполнял пробелы.