{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Время кодить. Тайм-трекеры в айти-компании

В условиях пандемии удаленная работа перестала быть привилегией отдельных компаний. Удаленно и бесконтактно у нас теперь ВСЕ. Для айти это не то что бы сильное потрясение, но все же некоторые моменты стали восприниматься острее. В частности, контроль рабочего времени.

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

Однако, работа по таймеру — очень и очень холиварная тема среди самих программистов.

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

Мы провели анонимный опрос в нескольких IT-компаниях: 80% программистов крайне негативно относятся к самому факту контроля рабочего времени. Они не против отчитываться пост-фактум, сколько времени потратили на ту или иную задачу, но само ощущение «большого брата» крайне угнетает.

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

Что хорошего?

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

Во-первых, можно сделать график более гибким. К примеру, работник должен отработать 40 часов за неделю — он вправе сам решать, дробить ли их на 5 рабочих дней по 8 часов, или же 4 дня по 10 часов, тем самым, выделив себе +1 свободный день в неделю. Тот самый life-work balance в действии. Но здесь и работодателю важно сохранять гибкость, не зацикливаясь на стандартном графике с 9 до 18.

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

Личный опыт программиста

В нашей digital-студии 2UP есть разработчик, который уже несколько лет работает на проекте с жестким таймером: ровно 8 отработанных часов, скриншоты экрана каждые 4 минуты, и отслеживание активности. Мы спросили его, каково это — находиться под постоянным контролем, как долго он к этому привыкал, и видит ли какие-то плюсы в таймере. Вот мнение из первых уст.

Привыкал к такому режиму работы он несколько месяцев. Минусы обнаружились сразу же:

«…отрабатывать 8 часов по таймеру, оказалось, совсем не равно 8-ми часовому рабочему дню. Делая перерыв на обед, плюс небольшие перерывы на перекур, рабочий день достигал 10 часов, прежде чем таймер показывал заветные 8 часов».

Иногда приходится бороться со своей забывчивостью, принося в жертву свободное время:

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

При этом, определенные плюсы работы под таким контролем все же есть:

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

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

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

«За несколько лет уже привык контролировать свой рабочий день по нему, и глядя на цифры таймера, можно понимать, что рабочий день подходит к концу. На слишком жесткие условия, типа фотографирование лица программиста через веб-камеру, я бы не согласился. Хотя, смотря какая оплата и ответственность, конечно же».

Как работаем мы

Как руководитель, я наверное все же «ЗА» тайм-трекеры. В нашей компании учет времени — это, в первую очередь, элемент оцифровки рабочих процессов, а не способ контроля каждого сотрудника.Используя таймеры, мы знаем, сколько времени программист тратит на ту или иную задачу. И если видим, что почему-то на аналогичный таск уходит больше времени, то начинаем разбираться. Может, это выгорание, и ему нужен отпуск. Или же его отвлекают сопутствующие задачи.

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

Для клиентов на time&material мы используем внутренний таймер нашей CRM — Active Collab. Чтобы в случае каких-то недопониманий или недовольств по поводу низкой скорости работы, мы могли предоставить детальный отчет.

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

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

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

А как вы относитесь к тайм-трекерам? Время=деньги? Или излишняя мера контроля?

0
74 комментария
Написать комментарий...
Эдуард Балагуров

Часы пытаются посчитать, чтобы убедиться в том, что программист работал. Ведь работа по проекту может длиться достаточно долго. При этом очевидно, что проверяющий с высокой долей вероятности ничего в коде не понимает. 

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

Ответить
Развернуть ветку
Николай Кузнецов

Скажу еше один секрет. Программист работает, даже когда не нажимает на клавиши. Когда обсуждает проблему с коллегами на обеде. Когда идет на работу и в своей голове подумывает архитектуру проекта, например. Это время, пока он думает над задачей, ему никто не оплатит. По вашей логике, прораммисту надо платить за набор буков в редакторе кода? 

Ответить
Развернуть ветку
Эдуард Балагуров

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

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

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

Отказаться от любого вида контроля процесса работы целесообразно для обеих сторон только в одном случае. Если работа оплачивается за результат, а цена утверждена заранее и не подлежит изменению. 
Но мне кажется, что в статье речь идет о людях, которым оплачивают фактически время. Значит программист подстрахован от того, что работа может сильно затянуться по объективным причинам, ведь ему всё равно заплатят за время.

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

Ответить
Развернуть ветку
71 комментарий
Раскрывать всегда