Стоит ли вести учет рабочего времени?

Вопрос учета времени работы программиста встает достаточно часто. Причины, заставляющие менеджеров об этом задумываться, могут быть достаточно разные. Специалист в области управления требованиями, проектами и soft skills Luxoft Training Вадим Качуровский расскажет, кому важно вести учет и как это помогает в работе.

Итак, приведем несколько причин почему все же нужен учет:

1. Существует требование на уровне организации вести учет рабочего времени и вообще «строго придерживать официального графика».

2. Менеджер Проекта имеет «склонность к паранойе» и хочет, чтобы все работали по 8 (а лучше по 10 часов, потому что он так делал в молодости). Как вариант у руководителя складывается ощущение, что сотрудники слишком много отдыхают, поздно приходят и рано уходят.

3. Модель контракта (Time and Material), при которой заказчик платит по реально отработанным часам сотрудника.

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

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

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

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

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

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

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

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

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

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