Таймтрекинг: стоит ли вести учёт рабочего времени программиста и если да, то как?

Для большинства IT-специалистов гибкий график — это общепринятая практика работы. Но есть нюанс: согласно Трудовому кодексу РФ, работодатель при этом просто обязан вести учёт рабочего времени. То есть в рамках правового поля вопроса о том, стоит ли вести этот учёт, вообще не стоит (подробнее: ТК РФ Статья 102. «Работа в режиме гибкого рабочего времени»).

В то же время нигде не написано, как именно это следует делать. Самый дешёвый и удобный способ — использование таймтрекера. Мы считаем, что таймтрекер — это не орудие контроля, а орудие свободы. Возможно, потому что сами некоторое время назад написали свой таймтрекер для учета рабочего времени, тщательно проработав этот вопрос: что удобно, что нет и так далее.

Во-первых, как мы уже сказали, если вы хотите работать по гибкому графику, таймтрекер даст вам такую возможность. Каждый сотрудник волен начинать работу, когда хочет, и соотносить время труда и отдыха, как ему удобно (соблюдая при этом заявленный рабочий график). Каждый сотрудник может работать там, где хочет, никого не заставляют торчать в офисе с 9 до 18. Это принципиально новый уровень доверия, что немаловажно — не возникает путаницы и не страдает производительность труда.

Во-вторых, и это самое важное, таймтрекер решает важнейший вопрос доверия между заказчиком и исполнителем. Тут все логично: тяжело целиком и полностью довериться исполнителю из далёкой России (если речь идет о зарубежных партнерах) и хочется иметь хоть какое-то (честно говоря, ложное) ощущение контроля.

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

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

Как сделать так, чтобы сотрудников это не раздражало? На наш взгляд, самое главное — это грамотное обоснование того, зачем и почему ведётся учёт рабочего времени. Если с самого начала у коллег нет вопросов «почему они должны…», то и в дальнейшем это не станет проблемой.

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

Убеждён, что специальные программы, в которых сотруднику нужно лишь нажать кнопку «старт» в начале работы и кнопку «стоп» в конце, а также программы, которые записывают экран рабочего устройства, действуют скорее как раздражающий фактор и, скорее, несут больше вреда. В первую очередь подобный подход оттолкнет очень востребованных в наши дни программистов (компании борются за лучшие умы, предлагая современные офисы, особый график, спортзалы, смузи и прочее — всё, чтобы привлечь и удержать сотрудника). Конечно, в определённых сферах доскональный контроль через специальные программы необходим, но мы стараемся доверять своим сотрудникам. Поэтому придерживаемся открытого диалога в рабочих процессах, разговорах на ежедневных stand-up, обсуждении сложностей при подготовках к релизам и т.д. Учёт рабочего времени по конкретным задачам ведём через плагин в Jira по каждому таску и проекту в «механически-доверительном» формате. На практике это означает, что каждый программист после выполнения задачи самостоятельно отмечает на доске затраченное на нее количество часов. Конечно, мы периодически проверяем указанные часы на объективность, но делаем это выборочно и доверяем сотрудникам. Они же, в свою очередь, понимают, что эти часы напрямую влияют на экономику компании, которая в конечном счёте отразится и на них, поэтому работают на совесть, а не на формальные показатели. Конечно, есть и те, кто пытается хитрить, с такими мы стараемся быстро прощаться, ведь такие люди нарушают наш важнейший принцип — доверительные и долгосрочные отношения с сотрудниками.

Всё зависит от условий, в рамках которых осуществляется работа специалиста. Самая простая причина, по которой стоит учитывать время, потраченное на проект разработчиком, — управление ресурсами. Чтобы понимать общую загрузку и иметь возможность планировать распределение ресурсов, необходимо списывать часы сотрудников, работающих над задачами в рамках разработки проекта. Загрузка рассчитывается как отношение списанных часов ко всем доступным рабочим часам за конкретный отчётный период. Это позволяет оценить, чью загрузку необходимо снизить, а кому можно добавить задач. Кроме того, учёт часов, потраченных на проект, позволяет проанализировать эффективность реализации проекта. Если потребовалось больше часов на разработку, чем предполагалось по предварительной оценке, то это должно стать сигналом для менеджера проекта и руководителя разработки. В командных методологиях разработки, таких как Scrum, таймтрекинг применяется редко, если не требуется удовлетворение остальных пунктов.

Еще одна причина, по которой необходимо использовать таймтрекинг, — разработка IT-продукта, который будет поставлен на баланс как актив компании. Учёт времени необходим для расчёта стоимости формирования начальной стоимости такого актива. Для этого списанные на продукт часы умножаются на диверсифицированную ставку по ролям, либо на среднюю ставку, согласованную по компании для разработки.

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

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

Но есть и серьёзные минусы. Отслеживание рабочего времени почти всегда подразумевает, что программист должен отработать определённое количество часов в день, и это может стать проблемой. В таких условиях многие люди бессознательно начинают думать о том, как «отсидеть» положенные 8 часов, и могут расходовать рабочее время менее рационально. Менеджерам и тимлидам при этом приходится постоянно проверять, как и на что расходуется каждый час. Это не только раздражает сотрудников, но и требует больше ресурсов.

Мы предпочитаем работать по другой схеме, предоставляя разработчикам самим решать, когда и сколько они будут работать. Главным критерием оценки их работы является результат, то есть объём и качество выполненных задач. Если требуется командное взаимодействие, участники проекта сами договариваются, как будут пересекаться в офисе.

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

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

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

Каждая компания сама для себя определяет, нужно ли вести учёт времени программистов. Все зависит от модели оплаты за проект: Fixed Price vs. Time and Materials. Не будем вдаваться в подробности и отличия, лучше расскажем про свой опыт.

У проекта есть цена, которую оплачивает клиент по предварительно согласованной смете. В этой смете мы всегда расписываем виды работ — во сколько клиенту обойдётся прототипирование и дизайн, вёрстка и бэкенд. Перед стартом проекта клиент уже знает, работы какого специалиста он оплатил и сколько времени это займёт. Естественно, вместе с перечнем работ в смете мы указываем и часы. Обычно с запасом на различные патовые ситуации — всегда в ходе разработки что-то может пойти не так, и потребуется дополнительное время, чтобы обнаружить причину конфликта и пофиксить проблему.

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

Для таймтрекинга мы используем ActiveCollab. Там нет встроенного таймера (есть отдельная приложуха, которую нужно устанавливать на ПК, но она не очень удобная, часто дает сбои) как, например, в Jira. Но нам это и не нужно. Не все специалисты горят желанием отписывать каждую минуту потраченного времени. За неделю можно выполнить задачу и записать время, потраченное на неё. Так мы не трекаем каждую секунду, проведённую за компьютером каждый день, а можем отметить просто в конце недели всё время, потраченное на задачу.

Эту практику мы ввели относительно недавно, и для многих ребят фиксирование времени на задачи стало достаточно болезненным. Но практически сразу приходит понимание, что это нужное и важное мероприятие, которое в дальнейшем помогает более качественно оценить проекты на стадии составления сметы и давать клиенту более конкретные цифры и в итоге определить рентабельность.
Сложнее тем компаниям, которые работают по принципу Time and Materials. На прошлых местах работы наша команда сталкивалась с тем, что нужно не просто трекать каждую минуту, потраченную на решение задачи, а еще и находиться под постоянным наблюдением. То есть на ПК каждого сотрудника стоит программа, которая делает скриншоты экрана каждые несколько минут и следит за движением мыши. И если ты просто отошёл за чашкой чая, не остановив учёт времени, программа сама отключается. В таких условиях тотального контроля работать довольно сложно, ведь каждому из нас иногда нужно несколько минут пофилонить, чтобы с новыми силами ринуться в бой.

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

Я видел обе крайности: и подобный завод, и его полную противоположность. Свобода тоже опасная штука. Команда может как самоорганизоваться в эффективную машину по решению задач, так и стать неуправляемой. О втором вы узнаете поздно, когда время и деньги уже будут потеряны.

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

Чтобы контролировать работу программистов, имеет смысл взять лучшее из scrum- и agile-подходов. Например, оценивать сложность задачи в числах Фибоначчи, попугаях, собаках, обсуждать эти оценки внутри команды или даже играть командой в planning poker. Из инструментов — только доска c задачами в любом виде и оповещения о выполнении задач членами команды. Через 2–4 месяца сработанная команда сможет довольно точно оценивать сроки и укладываться в них — каждому типу задач будет найден адекватный эквивалент в часах. Вот это уже поддаётся контролю и приносит ценность бизнесу. Только важно не уйти в карго-культ подхода. К примеру, если от ежедневных стендапов внутри команды нет пользы, делайте их реже, и они никого не будут раздражать.

Если программист сидит в офисе и работает по графику, то учёт рабочего времени уже сделан. Если работа проектная, то учитывать рабочее время программистов — необходимость, потому что появляется достаточно объективная метрика заработной платы — деньги за час работы. Есть 2 подхода: оценка времени на разработку до начала работ и после их окончания.

И в том и в другом случае есть свои подводные камни. В первом есть риск недооценки (или наоборот, переоценки — с запасом) сроков планируемых работ, во втором случае — риск «накрутки» реального рабочего времени. В своей работе фрилансером я предпочитал комбинировать 2 этих подхода. То есть сначала оценка фронта работ. Оплата 50 % от полученной суммы. Если потребуется больше времени по объективным причинам, то тогда объясняешь это заказчику и обычно проблем не возникает.

Ну если это не тот случай, когда планировал день работы, а тут вдруг месяц 🙂

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

Что касается раздражения, попробую ответить так:

1. При трудоустройстве в офис программисты уже согласились на подобную оценку их рабочего времени.
2. На проектной работе главное для программиста — уметь говорить с клиентом. Со всеми можно найти удобный компромисс оценки рабочего времени. Тогда никакого агрессивного отношения возникнуть не должно.
3. Если уж мы сталкиваемся с агрессией и раздражением, то нужно понять, из чего этот негатив произрастает. Чаще всего это является показателем некомпетентности разработчика. Но и тут есть разные механизмы «работы» с этой проблемой.

Также сейчас есть очень удобные сервисы для трекинга рабочего времени, например, Toggl. Там есть возможность заводить разные проекты для разных клиентов. Начинаешь работу — нажал кнопку «Старт», закончил на сегодня — «Стоп». Подписал, что сделал за это время. Дал доступ к этому проекту клиенту — он смотрит, что было сделано, за какой промежуток времени, тем самым контролируя процесс выполнения и имея возможность узнать, почему было затрачено столько времени на эту конкретную задачу.

Любой IT-бизнес рано или поздно задумывается об учёте времени программистов. Происходит это, как правило, когда команда и объём работы увеличиваются настолько, что руководство уже не может держать в памяти отдельные задачи отдельных разработчиков и вручную отслеживать прогресс по ним. При помощи учёта обычно хотят решить две задачи: вычислить фактическую трудоёмкость реализации и оценить вклад каждого сотрудника в неё, чтобы понять насколько он эффективен.

На этом этапе руководство часто совершает ошибку: всех разработчиков в конце каждого дня (недели) заставляют писать отчеты о проделанной работе, считая, что потратить 5–10 минут в конце рабочего дня — легко. На деле же этот подход при малой полезности очень сильно демотивирует разработчиков, которые такую активность воспринимают как пустую трату своего времени ради «глупой» формальности. Система при этом довольно быстро вырождается: отчёты часто просто копятся в хранилище без агрегации и анализа, а программисты, видя, что их никто не читает, начинают искажать реальную картину и вносят откровенную отсебятину.

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

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

Таймтрекинг — не самое эффективное средство для управления временем программиста. Прежде всего, сам показатель потраченного времени ни о чём не говорит. Программист может потратить большое количество дней, но так и не сделать того, что от него ждёт работодатель.

Альтернатива таймтрекингу — гибкое планирование в рамках Agile. Опишу наиболее частый сценарий такого планирования. При такой системе вся работа команды программистов дробится на двухнедельные спринты, в рамках которых каждому даются те задания, которые он должен выполнить с указанием количества пойнтов (пойнт — это, условно говоря, один день работы). Возможные значения пойнтов —  от 0.1 до 10. В процессе выполнения заданий спринта может оказаться, что количество пойнтов на задачу увеличилось или уменьшилось. При гибком планировании такие ситуации не редкость, тяжело заранее предсказать время, необходимое на задачу.

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

Рекомендую для ознакомления с принципами Agile книгу Дженнифер Грин и Эндрю Стеллмана «Постигая Agile. Ценности, принципы, методологии». Также для ознакомления с методами управления работой программистов интересна книга Дж. Ханк Рейнвотер «Как пасти котов. Наставление для программистов, руководящих другими программистами».

Вопрос в том, зачем мы учитываем рабочее время программиста. Я вижу два варианта. Первый — убедиться, что программист «занят делом во благо проекта и компании». Результат работы программиста редко может быть измерен объективно. Количество строчек кода? Количество закрытых задач? Количество проведённого времени на работе/за клавиатурой? Все эти показатели ничего не говорят о сути и качестве полученного решения. В случае, например, с землекопом можно заранее договориться о результате (размер траншеи) и потом его измерить, в разработке же такой подход малоприменим.

Если начать измерять работу программиста в каких-то условных единицах, то мы очень быстро можем прийти к тому, что именно эти условные единицы и будут оптимизироваться на рабочем месте. Измеряем строчки кода — получим увесистые программы, измеряем количество закрытых задач — задачи будут плодиться и закрываться как можно чаще. Измеряем количество времени, проведённого в редакторе, — тут тоже легко достичь показателя в 146 % при отсутствующем результате.

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

Второй вариант — узнать, на что же уходит время программиста. Он может работать на разных проектах или разных участках одного проекта, например, исправлять дефекты продуктивной системы и разрабатывать новую функциональность. И нам необходимо понимать соотношение затрат на разные проекты и разные виды работ, чтобы принимать взвешенные управленческие решения. Если мы видим, что ведущий разработчик тратит много времени на исправление незначительных дефектов вместо того, чтобы писать новую функциональность, можно усилить команду младшим специалистом и т. д.

Вести такой таймтрекинг можно двумя способами. Самый простой — использовать для всех активностей таск-трекер и брать отчёты оттуда. В этом случае таймтрекинг не заметен для разработчиков, но требует определённой дисциплины для регистрации всех активностей.

Другой вариант — ежедневный отчёт, который разработчик делает сам. Такой отчёт составляется в более-менее свободной форме и в него могут попадать задачи, которые обычно не учитываются (например, «рассказывал Ивану о возможностях фреймворка — 1 час»).

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

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

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

Для фрилансеров, для внештатных людей, альтернативой почасовому варианту оплаты является сдельная или проектная оплата, когда вы оцениваете стоимость каждой задачи и расплачиваетесь за выполненный «таск», не важно сколько времени на это потратил исполнитель.

Вариант почасовой оплаты мы выбираем при работе с более-менее постоянными фрилансерами, когда к ним идёт поток мелких задач, с которыми проблематично возиться, оценивая и согласовывая стоимость каждого мелкого таска.

Инструменты для учёта времени тут можно использовать любые, я не буду рекомендовать что-то конкретное, т. к. у нас в компании нет какого-то стандарта, каждый сотрудник учитывает время как и чем ему удобно, хоть секундомером. Главным инструментом тут является доверие — вы должны сработаться с этим человеком, доверять ему и его оценкам времени, т. к. проверить, сколько на самом деле ушло времени на работу, невозможно, любой инструмент можно обмануть. Желательно, чтобы у вас лично был опыт выполнения подобной работы, чтобы вы хотя бы ориентировочно понимали за сколько времени такое делается, сколько времени потратили бы вы сами. Если человек систематически даёт сильно завышенное время выполнения задач (по сравнению с вашими оценками) то это повод искать ему замену, не пытаясь выяснить в чём причина, — то ли он слишком медленно работает, то ли обманывает, для вас никакой разницы.

Если вы считаете, что не стоит вести таймтрекинг, то как контролировать программистов?

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

Попытка использования программ, которые учитывают, сколько времени программист провел за компьютером за рабочими задачами — признак слабого и глупого руководства. Глупого, потому что вы не понимаете, как живые люди воспринимают такой контроль. Получается, что вам не важно, насколько качественно человек работает, нравится ли ему этим заниматься, главное, чтобы он, как раб на галере, открутил вёслами положенное время. И не понимаете, что программисты — народ очень подкованный в компьютерах, программах и способах их обмана. Они найдут способ, чтобы программа показывала то, что вам нужно, но доверия между вами уже не будет. Слабого — потому что вы идёте по пути наименьшего сопротивления, не хотите тратить время на индивидуальную работу с людьми, не пытаетесь их вовлекать в работу, выстраивать рабочие процессы, выяснять существующие проблемы, а тупо хотите сразу получить результат. Собственно, это и есть ответ на вопрос, что делать и как контролировать программистов: не относитесь к ним как к массовой рабочей силе. Иначе и работать они будут, как на заводе. Вам нужно находить время на регулярное, желательно ежедневное, общение с каждым человеком. Вы должны знать, какие именно задачи он решает прямо сейчас. Интересоваться, как идут дела с текущей задачей, не застрял ли он где-то, не ходит ли по кругу, не бьётся ли головой о стену. Спрашивать, как он видит цепочку выполнения задачи, на какие этапы он её разбил, как оценивает по времени текущий этап, что можно сделать, чтобы сократить это время, думать, кто и чем может ему помочь. Если у вас нет времени на всё это — найдите того, у кого есть. Если вам лень всем этим заниматься — найдите себе другую работу.

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

1. Существует требование на уровне организации вести учёт рабочего времени и вообще «строго придерживаться официального графика».
2. Менеджер проекта имеет «склонность к паранойе» и хочет, чтобы все работали по 8 (а лучше по 10 часов, потому что он так делал в молодости). Как вариант у руководителя складывается ощущение, что сотрудники слишком много отдыхают, поздно приходят и рано уходят.
3. Модель контракта (Time and Material), при которой заказчик платит по реально отработанным часам сотрудника.
4. Матричная модель организации работы, где необходим учёт времени: на какой проект и сколько отработал сотрудник. Или же просто сотрудник работает на несколько проектов.
5. Необходимо понять, насколько наш процесс эффективен и правильно работает. Это некоторая разновидность пункта 2 с той разницей, что менеджеру интересно понять, являются ли честными и адекватными те оценки, которые отдают заказчикам.

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

Первую причину я предлагаю не рассматривать. На мой взгляд, требования к присутствию на рабочем месте чётко в ограниченное время актуально только для сотрудников, работающих с клиентами. Работники IT-сферы в своей массе не являются людьми, работающими с клиентами. Если же вам всё-таки необходимо присутствие команды в офисе строго 8 часов по каким-то причинам, то либо постарайтесь им объяснить, чем это важно для общего дела, либо будьте готовы к тому, что принципом работы станет: «я свои 8 часов сегодня отработал — встретимся завтра». Обычно, если организация ставит такие требования, то есть и механизм отслеживания. Но в общем случае применение этой практики без разбора даёт низкую эффективность.

Вторая причина сигнализирует о том, что руководитель неправильно построил управление проектом (вверенными ему разработчиками). Т. е. он не понимает сути оценки, не понимает текущего статуса задач и как мы вообще попадаем (или не попадаем) в обозначенный заказчику срок. Хотя это, может быть, и действительно менеджерская паранойя на тему «вы мало работаете». Но в этом случае я бы сначала предложил разобраться — а есть ли проблема?

Третью и четвёртую причину предлагаю рассмотреть вместе. Обычно, это требование относится не столько ко времени присутствия на работе, сколько ко времени суммарно отработанных часов и их правильному распределению между задачами. В данному случае у нас нет цели кого-то прижать или поймать на обмане. Поэтому мы вполне резонно можем попросить разработчиков списывать реально отработанные часы в системы трекинга задач (Jira/TFS или аналоги). Причина достаточно веская: менеджер не может догадаться, сколько и на какую задачу вы тратите. Фокус смещается с контроля за общим количеством к правильному распределению часов. Разработчики обычно спокойно относятся к такому подходу, и по окончанию работы над задачами, часы списываются. Конечно, придётся ещё поработать над его надстройкой — будут забывать или списывать слишком мало. Но в целом этот процесс работает. Кроме того, этот подход со списыванием фактически отработанного времени можно использовать, когда вам необходимо проверить правильность процесса.

Таким образом, перейдём к пятой причине — контроль процесса. Опять же мы видим, что фокус ставится на проверку изначальной оценки или на проверку скорости работы команды. Правильно выстроенный процесс всегда имеет в своём составе цикл контроля, по результатам которого необходимо производить корректировку. И команда, при должном объяснении и постановке цели, не саботирует этот процесс, а поддерживает его. Механизм такой же, как и в предыдущем абзаце — системы учёта задач.

В завершение хочется сказать, что процессы безусловно влияют на присутствие человека в офисе в то или иное время (например, при работе по SCRUM вам необходимо присутствие всех членов команды на ежедневном митинге и желательно в одном физическом месте). Но это не должно становиться рычагом влияния на людей для достижения цели отработки 8 часов в день. Ведь наша основная цель — это удовлетворённый заказчик с системой, которая решает его бизнес проблемы, а не пресловутые отработанные часы.

Мы ведем учёт рабочего времени всех специалистов. Это нужно не только компании, но и самим сотрудникам. Для постановки задач, контроля работы и таймтрекинга мы много лет используем систему Azure DevOps. Программисты фиксируют здесь 100 % своего рабочего времени. Дополнительно разработчики нашей компании создали собственную надстройку, где можно смотреть различные отчёты по сотрудникам и проектам. Для каждой задачи есть оценочное время выполнения. Работая над проектом, мы постоянно сравниваем планируемое и фактически затраченное время.

Таймтрекинг позволяет бизнесу:

1. Оценивать эффективность сотрудников и контролировать качество их работы. Если программист одновременно занят на нескольких проектах и получает задачи от нескольких менеджеров, отслеживать его текущую работу становится очень сложно. Система постановки задач и учёта рабочего времени помогает нашему руководству понять, чем занимался сотрудник в каждый конкретный момент времени. Посещение конференций, конф-коллы и встречи с клиентами также учитываются в системе.
2. Автоматизировать работу специалистов, напоминать им о сроках сдачи каждого проекта, невыполненных или незавершённых горящих задачах. Для этого достаточно настроить в системе мониторинга рассылку уведомлений.
3. Формировать отчёты и выставлять счета клиентам, с которыми компания работает по модели Time & Material. Например, если договор заключался на техподдержку или используются гибкие методики разработки. У нас таких проектов — более 80%.
4. Рассчитывать реальную себестоимость проекта для компании, когда сотрудничество с заказчиком ведут по модели Fix Price. Учёт рабочего времени исполнителей помогает подсчитать затраты агентства и оценить рентабельность проекта.
5. Гарантировать заказчикам прозрачность всех процессов. Наши клиенты получают доступ к рабочему процессу в Azure DevOps и могут наблюдать за каждой итерацией. Сотрудники отмечают задачи в реальном времени. Это помогает спрогнозировать срок сдачи каждого проекта, видеть ход его выполнения.

К слову, учёт рабочего времени полезен и самим сотрудникам. Подход помогает программистам вести личный тайм-менеджмент:

• фиксировать объёмы и количество задач;
• объективно оценивать объём работы на день, неделю, месяц, квартал;
• планировать собственную загрузку;
• эффективно распределять рабочее и личное время.

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

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

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

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

Оценить это без помощи инструментов для учёта рабочего времени будет весьма затруднительно.

Работодателю нужно грамотно подойти к учёту рабочего времени.

Заставлять сотрудников с хронометром в руках заполнять табличку — самое неблагодарное занятие. Лучше всего сделать процесс учёта времени не требующим никаких дополнительных регулярных манипуляций.

Ассортимент инструментов для учета времени очень широкий, у каждого есть свои преимущества и недостатки. Лучшим, на мой взгляд, является подход с применением плагинов к используемой IDE, браузерам и т. д.

Да, вести учёт стоит — хотя бы для адекватного планирования будущих проектов. Ведь для этого надо понимать:

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

Самым правильным будет при планировании брать эти данные не просто из памяти, а из ранее собранной статистики. Удобного «коробочного» инструмента для сбора такой статистики, к сожалению, я не знаю. В таск-трекерах есть возможность фиксировать затраченное на каждую задачу время, но эта информация, как правило, «привязывается» к конкретной задаче. В результате фиксируется время на разработку (включая первичное тестирование), но теряется информация об обсуждениях, планировании, возможно, и о времени на тестирование.

Мой опыт показывает, что самый результативный вариант — заполнение дневных отчётов в разрезе задач и видов работ. Хоть это обычно и не нравится самим разработчикам. Готовой удобной программы для такого учёта я не знаю — в нашей компании мы её разработали самостоятельно. Это «База учёта заявок», которую мы написали на 1С, используем уже 14 лет и постоянно развиваем.