lahomie93, мне кажется, что лучшим выходом будет отказ от трекинга времени как такового. Да, ваши задачи решились бы тайм-трекингом, но все разбивается о человеческую психологию. Как результат: вы -- в стрессе (разрабы не хотят аккуратно трекать!), разработчики -- в стрессе (заколебал манагер со своей бюрократией), да еще и задачи ваши не решены, ибо нормального тайм-трекинга так и нет.
Давайте посмотрим, как можно легко решить ваши задачи другим образом:
1. Подсчет времени для расчета со сдельщиками
Тут тайм-трекинг не нужен вообще: сдельщик оценил задачу, по окончанию работ получил свои деньги.
2. Оценка маржинальности проекта
Тут он тоже не нужен: для сдельщиков затраты понятно как считать (п.1), для тех кто в штате -- есть фонд оплаты труда и то время, которое он был на проекте. Если человек работает на двух проектах одновременно, то пусть в табеле учета времени указывает сколько часов в день он потратил на тот или иной проект. Это не требует много времени, а главное -- разработчикам будет понятно, зачем они это делают (выставить счет заказчику), в отличие от тайминга по каждой задаче.
3. Накопление исторической базы для моделирования статистических методов оценки, типа Монте Карло
Просто забейте, это никогда не будет работать на уровне отдельных задач. Простой пример: разработчику надо сделать пять схожих задач, когда он взялся за первую, выяснились некоторые технические сложности, потребовался рефакторинг и тд. В итоге он на нее потратил вместо 3 часов 15 часов, а на остальные потратил по 2 часа. Ну и как это можно будет использовать? Никак.
Поэтому подобные статистические методы можно использовать только на уровне крупных блоков: типа на интеграцию со системой "Х" у нас обычно уходит полторые-две недели. И это будет вполне достаточная точность.
4. Понимание того как разработчик умеет делать оценку
Тут тоже тайм-трекинг не нужен: во-1, надо не понимать, как он ее делает, а улучшать ее точность. Для этого есть всякие методики типа планнинг-покера, использование идеальных часов и тд. Во-2, оценка -- вещь вероятностная и вам важна точность оценки не конкретной задачи, а точность оценки всего пула задач. Но тут обычный SCRUM прекрасно позволяет увидеть, насколько мы попадаем в оценку и предпринять необходимые управляющие действия, если нет.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Давайте посмотрим, как можно легко решить ваши задачи другим образом:
1. Подсчет времени для расчета со сдельщиками
Тут тайм-трекинг не нужен вообще: сдельщик оценил задачу, по окончанию работ получил свои деньги.
2. Оценка маржинальности проекта
Тут он тоже не нужен: для сдельщиков затраты понятно как считать (п.1), для тех кто в штате -- есть фонд оплаты труда и то время, которое он был на проекте. Если человек работает на двух проектах одновременно, то пусть в табеле учета времени указывает сколько часов в день он потратил на тот или иной проект. Это не требует много времени, а главное -- разработчикам будет понятно, зачем они это делают (выставить счет заказчику), в отличие от тайминга по каждой задаче.
3. Накопление исторической базы для моделирования статистических методов оценки, типа Монте Карло
Просто забейте, это никогда не будет работать на уровне отдельных задач. Простой пример: разработчику надо сделать пять схожих задач, когда он взялся за первую, выяснились некоторые технические сложности, потребовался рефакторинг и тд. В итоге он на нее потратил вместо 3 часов 15 часов, а на остальные потратил по 2 часа. Ну и как это можно будет использовать? Никак.
Поэтому подобные статистические методы можно использовать только на уровне крупных блоков: типа на интеграцию со системой "Х" у нас обычно уходит полторые-две недели. И это будет вполне достаточная точность.
4. Понимание того как разработчик умеет делать оценку
Тут тоже тайм-трекинг не нужен: во-1, надо не понимать, как он ее делает, а улучшать ее точность. Для этого есть всякие методики типа планнинг-покера, использование идеальных часов и тд. Во-2, оценка -- вещь вероятностная и вам важна точность оценки не конкретной задачи, а точность оценки всего пула задач. Но тут обычный SCRUM прекрасно позволяет увидеть, насколько мы попадаем в оценку и предпринять необходимые управляющие действия, если нет.