Учет рабочего времени — почему, зачем и как

Учет рабочего времени — почему, зачем и как
Публикация компании SEADMEX
Библиотека / Управление проектами

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

Прежде чем перейти к этим важным темам, предлагаю спуститься еще на один уровень вниз и попытаться ответить на более фудаментальный вопрос — зачем мы это делаем? Ясное дело, что учет вызван какими-то объективными надобностями — иначе кто добровольно будет осложнять себе жизнь?

Очень интересно. Смущает только одно - полная оторванность от методологий разработки софта. Смущает, потому что существует такой вид деятельности, как bug-fixing и он напрямую зависит от того, как работает отдел тестирования. Интересно, можно предсказать, что в таком-то билде будет собрано столько-то багов, такой-то сложности, чтобы потом предсказать (спланировать) ресурсы, необходимые на их фиксинг?

Интересно, можно предсказать, что в таком-то билде будет собрано столько-то багов, такой-то сложности, чтобы потом предсказать (спланировать) ресурсы, необходимые на их фиксинг?

Да. На базе накопленной статистики по предыдущим итерациям и на анализе показателей состояния проекта.

PS
Есть и формальные методы - но это из области "стратосферы", имхо.

Да. На базе накопленной статистики по предыдущим итерациям и на анализе показателей состояния проекта.

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

Билды есть? :) При чём тут итерации?

Билды есть? :) При чём тут итерации?

Когда существуют итерации, то производится более-менее точное планирование, что должно войти из функционала. Когда есть только билды (а тем более ежедневные), то вряд ли можно провести планирование. Трудно будет соотносить между собой различные билды, чтобы предсказать, насколько то или иное изменение/дополнение кода повлияет на стабильность системы, основываясь только на информации по предыдущим билдам.
Ну ладно, как бы там ни было, я считаю, что учёт рабочего времени должен проводится не отдельно от процесса (определяемого методологией) разработки софта, а быть с ним в некоторым образом связан. Особенно, если в компании для разных проектов используются разные методологии. Например, для одного проекта RUP-based, а для другого XP. Итоговый результат учёта времени будет один и тот же, а вот прмежуточные, да и сам процесс регистрации и учёта, будут различны (IMHO).