В условиях пандемии удаленная работа перестала быть привилегией отдельных компаний. Удаленно и бесконтактно у нас теперь ВСЕ. Для айти это не то что бы сильное потрясение, но все же некоторые моменты стали восприниматься острее. В частности, контроль рабочего времени.
Как контролировать своих программистов удаленно — каждая компания решает самостоятельно. Америку не открою, если скажу, что большинство используют тайм-трекеры. Вроде бы все просто и прозрачно: начал работу — включил таймер, закончил — выключил.
Однако, работа по таймеру — очень и очень холиварная тема среди самих программистов.
В нашей практике даже были случаи, когда разработчики бойкотировали все инструменты контроля времени: намеренно не включали таймеры, или же накручивали нереальное количество затраченных часов.
Мы провели анонимный опрос в нескольких 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. Чтобы в случае каких-то недопониманий или недовольств по поводу низкой скорости работы, мы могли предоставить детальный отчет.
Так что для нас таймеры — это необходимость. Главное, не злоупотреблять!
Я крайне негативно отношусь к попыткам чрезмерно контролировать сотрудников: кто на каких сайтах сидит, кто какие мессенджеры открывает. Вот это уже нарушение границ, на мой взгляд.
Когда человек выполняет свои задачи, выполняет их качественно и укладывается в сроки, то руководству должно быть все равно, смотрит ли он в перерывах ютюб, или вообще кодит под сериал. И такое у нас было, да.
А как вы относитесь к тайм-трекерам? Время=деньги? Или излишняя мера контроля?
Часы пытаются посчитать, чтобы убедиться в том, что программист работал. Ведь работа по проекту может длиться достаточно долго. При этом очевидно, что проверяющий с высокой долей вероятности ничего в коде не понимает.
Выводы: заказчику/работодателю важно отслеживать именно динамику работы на ежедневном режиме. Не ежечасном, а именно ежедневном. И именно уровень динамики. Например, понимать количество знаков, которые прибавились или изменились сегодня в коде/ТЗ/что угодно. Вот если бы была программа, которая фиксировала бы только это, то не было бы никаких трений между работником и работодателем.
Коммиты чем не показатель?)
Что такое "коммиты"?
Это фиксация изменений в программном коде) Если есть коммит, значит с кодом работают)
Но тут тоже не все однозначно: например, когда что-то разрабатываешь, коммиты как правило содержат много строк кода. А, например, если ищешь ошибку, то можешь целый день потратить на поиск проблемного места и в итоге изменить всего одну строчку. Заказчик же, разумеется, если не понимает специфики, будет в недоумении, почему за целый рабочий день программист написал всего одну строчку кода(а часто и вовсе один символ:))
Когда грузчик загружает или разгружает вагон, то его работа оценивается либо по весу, либо по объему. Потому что можно грузить вату, а можно гвозди. Оценка происходит по тому параметру, который формирует больше цену.
Аналогично и здесь можно придумать не один параметр, а два или больше. Например, для исправления очевидно важнее результат. При этом найти ошибку в 10 знаках и 10 тысячах знаках - это разный уровень сложности.
Я написал свой комментарий про отслеживание динамики не как сформированное ТЗ, а как концепцию, которая отвечает целям заказчика намного ближе, чем таймер.
Если мы говорим про ошибки в печатном тексте, то да.. а если это касается бизнес-логики, то тут ошибка может быть даже не в самом коде, а в подключенной библиотеке или в несовместимости версий двух библиотек, к примеру. И тем не менее это будет баг на проекте и его как-то надо фиксить и тратить рабочее время.
Везло с тем, что на трёх проектах, где я пока побывал, начальство требовало результат, а не палило сколько времени ты отсидел в офисе. Когда в Сбере начали заворачивать гайки (типа любое время, проведённое за пределами рабочего пространства здания не учитывается в тайм-трекере) я очень быстро нашёл себе давно работодателя с эффективным менеджментом,а не дефективным)
Алексей, чтобы исправить любую ошибку, придется нажать кнопку. И я же выше написал, что исправление ошибки единственно правильно отслеживать по результату. Ошибка ли это в коде или в несовместимости версий библиотек - не важно же.
Вообще оценивать работу по результату безусловно хорошо. Но проекты иногда могут занимать недели и месяцы. В этом случае всё равно должна быть промежуточная отчетность. Ну если только программист не работает всё это время за свой счет, чтобы получить оплату за готовый результат.
Перед тем,как нажать кнопку надо подумать...
Что это меняет?
Думать не обязательно надо за компом + как трекер будет считать мозговую активность? По движению мышки?
Если мы говорим о результате, то промежуточным результатом в целом проекте может быть нажатие кнопки. "Мозговая активность" - процесс. Нажал кнопку - получил результат.
Если долго нет никакого результата, то заказчик/работодатель получает сигнал о том, что надо принять решение - либо продолжить сотрудничество с программистом, либо искать нового.
Меня такие трекеры выбивают из колеи. Именно те,которые контролируют процесс, а не постфактум.
Ощущение,что висит дамоклов меч, из-за этого совершаешь больше ошибок и ощущаешь перманентный стресс, особенно если задача требует подумать дольше 10 минут.