Как в корпоративном секторе ведётся учёт времени на задачу?

Question

[historydev]

Начал в день А, закончил в день Б и это будет итоговым временем?
Или разбивается на сектора по типу N времени думал, N времени заняла реализация?

В первом случае всё тривиально, задача поступила в день Б - считай начал, дальше без учёта выходных полагаю появляется диапазон А<->Б.

А второй случай бывает?

Answer 1

[Алексей Уколов]

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

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

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

Comments

[historydev]

Да, задача большая и непонятная, а так-же в ней много переменных.
- А паузы на отдых?

Разве системное отслеживание не выявит узких мест?

Например если работник делает все задачи быстрее остальных, но его код такое дерьмо, что ревью и правки занимают пару дней, хотелось бы его выкинуть)

[Алексей Уколов]

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

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

[historydev]

Алексей Уколов, А себя как мониторите? Так-же?

[Алексей Уколов]

Да, так же.

[Сергей Водаков]

historydev,

Например если работник делает все задачи быстрее остальных, но его код такое дерьмо, что ревью и правки занимают пару дней, хотелось бы его выкинуть)

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

Answer 2

[VoidVolker]

Более-менее точный результат - только через тайм-трекинг. Начал работать на задачей - кликнул "старт". Остановился на перерыв - "стоп". Закончил - перевёл статус задачи в "завершено". По мере работы/необходимости добавляются комментарии с деталями. Соответственно в таск-менеджере в отдельной колоночке показываются затраты времени на задачу.

Answer 3

[AndreyKeer]

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

Задача начинается, когда сотрудник приступает к ее выполнения и запускает трекинг нажав кнопку "Старт", а требуется переключится на другие задачи нажимается кнопка "Стоп". По факту выполнения данной задаче назначается статус "Выполнена". Соответственно суммируется все интервалы, что будет соответствовать фактическим трудозатратам на данную задачу.

Рекомендую протестировать насколько приложение для учета задач, вот неплохая подбора российских тайм трекеров: bitcop.ru/blog/top-24-tajm-trekerov-dlja-kontrolja...