Отчитываться за каждый час написания кода. Все мы слышали про подобные практики, многие даже сталкивались. А на самом ли деле это эффективно? Чего боится менеджер? Почему подобная отчетность может сильно ухудшить продуктивность команды? Давайте обсудим это в сегодняшней статье.

Введение

Доброго времени суток, коллеги! Я Макс Нечаев, 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

Комментарии (11)


  1. ABHuman
    13.07.2023 06:23
    +4

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

    Интересно, а куда делись эти заводы сейчас и про какие неработающие процессы идёт речь? На заводах стали работать по удалёнке?

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

    Так приведите их и обоснуйте чем они лучше.

    Полагаю, что главная ценность — это вовремя доставлять функциональности приложений и сервисов. 

    Бизнес - это про деньги, маркетинг - это про подсаживание на постоянные траты для вашего продукта. А тут я вижу какой-то юношеский максимализм. Вы правда считаете, что всегда нужно делать приложения без багов? Тогда вы остались в нулевых. ;)

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


    1. npolivanov
      13.07.2023 06:23
      +6

      «Так приведите их и обоснуйте чем они лучше.»

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

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

      «Трекинг ведут не для постоянного отслеживания, а для анализа, если вдруг такой понадобится. »

      Если трекер делает скрин экрана, то это большой перебор. Следить чтобы работник работал - 8 часов, тоже перебор.


      1. ABHuman
        13.07.2023 06:23

        доверять работнику и смотреть по сделанной работе

        Это вы очень зря про доверие. Смотреть по сделанной работе - это если у вас есть КПИ, строчки кода и т.д., иначе руководство должно разбираться в КАЖДОЙ узконаправленной должности и понимать ценность сделанной работы, а ещё важнее в творческой составляющей. И это совсем уж оторвано от реальности. Это как по количеству нот судить о музыкальном произведении.

        В любом случае команда увидит, кто ничего не делает и будет требовать результат.

        Это если вы работаете командами а ля Скрам и т.п., это частный случай! А ведь разработка бывает не только в АйТи.

        Если трекер делает скрин экрана, то это большой перебор. Следить чтобы работник работал - 8 часов, тоже перебор.

        Перебор через что? Зависит от задачи и методов поощерения или наказания. Если вам укажут на исследования, которые подтвеждают, что отвлечения на другие задачи мешает достижению результата, то что вы в ответ аргументируете? Сам автор говорит, что офис его отвлекает, а дом этого нет. Противоречим сами себе получается.

        Ну давайте представим, что вам во время операции хирург вдруг бросает всё и уходит, мотивируя, что это перебор. Есть виды работ, где это необходимо, охранник за пультом, например, а лучше представьте себе авиадиспетчера. Только 21 век во многих профессиях ещё не настал и вряд ли настанет так быстро.

        И первое препятствие - это отсутствие умения объективно оценивать работу. Но так мы с вами до "Капитала" договоримся.


        1. Vanirn
          13.07.2023 06:23

          >Смотреть по сделанной работе

          В чём тут проблема? Работа «сделана» означает что она принята потребителем этой работы, в случае производства это другой отдел. Кроме потребителей есть такой древний отдел под названием «Контроль качества», контролирует работу на соответствие заданным параметрам ещё до приёмки её заказчиком.

          «КПИ» и прочие нововведения можно оставить высоко эффективным менеджерам. Есть работа измеряемая, к примеру количество единиц продукции в единицу времени, и не измеряемая – любая разработка. Но некоторым эффективным менеджерам очень хочется измерить и такую работу – отсюда появляются KPI на количество строчек кода / текста / исследований, закрытые задач и прочие удивительные показатели.

           

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

           

          Откуда вы взяли что Скрам живёт не только в АйТи разработке? Он отлично себя чувствует и в разработке реального продукта. Но я не спорю, российская промышленность далека от передовых технологий…


      1. ABHuman
        13.07.2023 06:23

        методы мониторинга времени как на заводе, совершенно не подходят к современной разработке.

        А вы точно знаете методы мониторинга на заводе, а автор? Я в подавляющем большинстве встречаю как раз стереотипы про работу заводов, особенно, когда в мнении все заводы усреднили и поставили на них штамп.

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

        Кстати, на заводе очень сильно распространена сдельная оплата труда. Иногда есть нормы производства, от которых зависит конкретная зарплата сотрудника. А часы как раз включают, когда кто-то особо одарённый сэкономил своим решением миллионы, а делится с ним не хотят собственники.


  1. Abobcum
    13.07.2023 06:23

    Хочу заметить, что 8 часов работы в офисе на самом деле занимают 12 часов реального времени. А если учесть время сна, то это практически весь день.


  1. Vanirn
    13.07.2023 06:23

    Кто-то очень умный сказал: «Чем больше отчётности, тем меньше доверия».

    Несколько мыслей по этой теме:
    Подобный учёт рабочего времени порой «сводит на нет» внутри командное взаимодействие между коллегами – каждый озабочен об отчёте за потраченное время на помощь друг другу.

    Оценка трудозатрат на разработку (хоть ПО, хоть машина) совершенно отличается от оценки трудозатрат на производство уже разработанного изделия.

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

    У меня и у многих моих коллег такая система отчётности вызывает ощущения взаимодействия с работодателем по типу «раб – надзиратель».

    PS: Довелось мне работать в одной компании с разработкой реального осязаемого продукта. Как-то раз сменилось начальство (не буду уточнять которое из них было более эффективным), а новое ввело правильно повременного отчёта за день, формата: задача – потраченное время.
    Не малая часть персонала «разбежалась» уже в течение нескольких месяцев после такого нововведения. Хотя одна очень сообразительная сотрудница уже через пару недель навострилась писать отчёта на всю неделю вперёд по понедельникам, но всё равно ушла через полгода.
    Я же после введения такого отчёта полностью перестал заниматься работой в нерабочее время, а занимался я тогда маркетингом. Поначалу писал отчёт по полчаса-час в день, а через месяц так же приспособился и навострился ваять их за 10 минут.


    1. tommyangelo27
      13.07.2023 06:23

      Подобный учёт рабочего времени порой «сводит на нет» внутри командное взаимодействие между коллегами – каждый озабочен об отчёте за потраченное время на помощь друг другу.

      Я с таким сталкивался в реале. Чтобы написать вопрос чуваку в Слаке нужно сразу же, вместе с вопросом, отправлять ссылку на тикет в Джире. Иначе ответа можно и не дождаться.


  1. KongEnGe
    13.07.2023 06:23

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

    А с аналитикой жить проще всем сторонам: одни видят, что оговоренное время нанимателю продали, рассовав его по задачам; а наниматель видит, что какие-то задачи идут дольше, чем ожидалось, и может начинать вентилировать вопрос с качеством планирования (в первую очередь, учета подводных камней внешне простых задач).


  1. Metotron0
    13.07.2023 06:23

    Работодателю так удобнее. Зная, что работник будет работать 4-5 часов из восьми, делим его дневную ставку на восемь и платим за 4-5 настоящих часов. Профит. Можно даже умножить ставку раза в полтора, всё равно будет профит.

    А если работник начнёт четырёхчасовые задачи трекать как восемь, то к нему возникнут вопросы.