Трекинг времени и его влияние на эффективность разработки
Отчитываться за каждый час написания кода. Все мы слышали про подобные практики, многие даже сталкивались. А на самом ли деле это эффективно? Чего боится менеджер? Почему подобная отчетность может сильно ухудшить продуктивность команды? Давайте обсудим это в сегодняшней статье.
Введение
Доброго времени суток, коллеги! Я Макс Нечаев, Senior iOS разработчик в крупном фуд-тех стартапе Катара. Я хочу обратить ваше внимание, что эта статья является некой аналитикой, пропущенной через призму моего опыта и опыта многих друзей-разработчиков. Это не истина. Пожалуйста, пишите своё мнение в комментариях. Статья наоборот написана, чтобы призвать вас, господа, к рассуждениям, спорам и к поиску консенсуса (если это возможно).
Проблематика
Сейчас я попробую донести основную мысль, которая натолкнула меня на написание данной статьи. Два года назад я работал в одной из компаний Санкт-Петербурга, которая занималась разработкой мобильных приложений на заказ. Работа было на сто процентов удаленной. А эффективность сотрудников базировалась не только на количестве и качестве выполненной работы, но и на забитых в специальном календаре часах.
Как выглядел мой день? В первую очередь я открывал календарь — бронировал первый час и ставил, какой задачей занимаюсь. Затем бронировал митинги. Затем опять работу. По сути своей это некий сервис, чтобы ты вписывал каждую минуту своего рабочего дня.
Для меня это показалось странным, но поработать там я хотел, поэтому смирился и стал жить по этим правилам.
Спустя время я стал находить интересные лазейки и читы для работы по такой схеме.
Небольшое отступление…
Сам я с этим не сталкивался, но многие из вас думаю, что имели подобный опыт. Во многих компаниях вы должны трекать время работы, прямо включать «специальный секундомер» (time tracker) и работать. Более того, что некоторый софт делает скрины вашего экрана, но что еще хуже, что есть софт, который делает фотографии с вашей веб-камеры. Кто сталкивался с таким, напишите в комментарии ваше моральное состояние после такой работы, будет интересно почитать.
Наконец хочу подойти к сути этого пункта, в чем проблема?
Постоянный контроль снижает творческий потенциал
Складывается внутреннее ощущение, что твоим днём управляет кто-то другой, но не ты
В тяжелые дни, когда работа не идёт, через силу заставляешь себя сидеть, чтобы не выглядеть «раздолбаем» перед работодателем
Со временем появляются чит-коды, которые помогают обойти систему
Общая мотивация пропадает
Складывается ощущение, что тебе не доверяют
Думаю, что если сложить эти пункты и добавить еще 2–3 подобных, то складывается очень неприятная картина типичного рабочего дня.
Призываю вас не соглашаться, пишите в комментариях своё мнение и опыт.
Восьмичасовой рабочий день
Последние несколько лет я работаю только удаленно. Никаких офисов. Работа дома для меня предельно эффективна. Меня никто не отвлекает. Первым делом я составляю пул задач, что сделать, как сделать, сколько энергии уделить этому. После чего я откладываю в сторону абсолютно всё, что может меня отвлекать. Я создаю ветку, погружаюсь в код и… бам, прошло 3–4 часа, задачи на сегодня почти все выполнены. В статьях это обычно называют состоянием потока. Когда ты погружаешься настолько внимательно в работу, не отвлекаясь ни на что, что не замечаешь, как пролетает время и задачи.
У этого есть обратная сторона, после сильной мозговой активности нужно обязательно отдыхать. Например я не могу каждый день писать код по 8 часов подряд в состоянии потока, это выше моих сил. Иногда, когда этого требует ситуация — да, это норма, но не каждый день. Иначе вечером чувствую себя выжатой губкой, которая не хочет ничего в жизни.
Помимо своего опыта я общался с другими разработчиками и уловил такую мысль, в среднем программист пишет код около 4–5 часов в день, не больше. Если меня читают менеджеры, ребят, это нормально. 4–5 часов позволят решить бОльшую часть задач, при этом не выгореть через 2–3 месяца. Иногда в эти 4–5 часов входят и митинги.
Сколько времени в день вы реально пишете код?
А теперь предлагаю окунуться в офисную жизнь. В историю, когда ты приходишь на работу с утра и первым делом заходишь за кофе и выпечкой. Потом здороваешься со всеми и общаешься. Кто-то выходит на перекур. В течение дня кто-то дёрнет в одну сторону, кто-то в другую. Состояние потока достигнуть сильно сложнее, но вот отвлекающих факторов может быть масса.
Работая в офисе, мы как правило сидим там настоящие 8 часов в день (даже 9, если считать массовый выход на обед). Но как бы парадоксально это ни было, на кодинг мы тратим всё те же 4–5 часов.
К чему это всё?
Вывод тут только один.
Ладно, теперь серьёзно. Показатель времени никогда не являлся показателем эффективности. На своём опыте могу смело сказать, что 4–5 часов работы из дома для меня сильно эффективнее 9 часов из офиса. Но с точки зрения многих работодателей двадцатых годов 21 века — работа из дома и офиса эквивалентна.
На мой субъективный взгляд, трекать время сотрудника «нужно» только для того, чтобы убеждать себя, что сотрудник что-то делает и на связи. Не более.
Чтобы по-настоящему отслеживать эффективность разработчиков стоит дать им свободу времени, но следить за оценками задач. Если у вас есть грамотный продакт или проджект, который постоянно на связи с командой, то это его ответственность следить за тем, как закрываются реальные задачи. Не эфемерные слоты в специализированных календарях и тайм-трекерах, а настоящие бизнесовые истории.
Полагаю, что главная ценность — это вовремя доставлять функциональности приложений и сервисов. Делать это качественно, без багов. Выполнять работу в поставленные оценки времени. Какая разница, что конкретно сейчас делает разработчик, если он поставляет вовремя свою работу и приносит бизнесовую ценность работодателю — увеличивает доход компании.
Я хочу донести, что на мой взгляд, куда важнее трекать умение разработчика грамотно оценивать задачи и выполнять их в срок, писать чистый и масштабируемый код, пропускать минимум багов на QA этап. Ну, а если разработчик не может этого и не хочет учиться, то заставлять его сидеть по таймеру — как минимум глупо. Ведь такой разработчик не принесет business value.
Вывод
Коллеги, мы живем в 21 веке, мы разрабатываем современные продукты и сервисы на новых технологиях, мы вводим процессы, мы стараемся развиваться каждый год.
Процессы, которые были на заводах в 20-ом веке могут не работать сейчас и это нормально. Я действительно считаю, что история с трекингом времени разработчика и со строгим восьмичасовым днём — это прошлое. Сейчас есть огромное количество способов грамотно следить за эффективностью команды. Кажется, что те, кто просто вводит слежение за временем, не хочет разбираться в зерне эффективности.
Но и всегда важно понимать…
Это просто мнение на Хабре, что думаете вы? Какие наиболее эффективные практики используете сейчас? По каким-либо личным вопросам, я всегда открыт в ТГ: maxnech
