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

Question

[historydev]

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

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

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

Answer 1

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

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

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

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

Comments

[historydev]

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

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

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

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

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

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

[historydev]

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

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

Да, так же.

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

historydev,

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

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

Answer 2

[VoidVolker]

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