Здравствуйте, hrensgory, Вы писали:
H>А убытки фирмы покрывать менеджер будет или разработчик ) ?

По моему мнению разработчик точно не должен отвечать за деньги в этом случае. Так что остается — менеджер. Обычно реально в аутсорсе менеджеры и разруливают выставление счетов заказчику, им и отвечать...

H>Вообще не очень понятная тема, "сколько заняло исправление" (читай — во
H>что обошлось фирме) и "сколько выставить заказчику" это обычно не одно и
H>то же, непонятно почему не хватает двух полей: оценочная и фактическая
H>длительность работ по задаче.

По мне дак фактическая длительность нафиг не нужна. Ну только если использовать ее для внутренней статистике и учитывать не в дурацких минутах, а в днях (минимум половина дня)... А счет выставлять заказчику по оценочной. Ну и вообще вот тут дельные советы дали — Re[11]: Система учета рабочего времени для исполнителя (прогр

Автор: _ABC_
Дата: 25.02.15

В общем, изначальную идею учета времени — выкинуть нафиг (как и предполагалось с самого начала)

Вячеслав Педак

Здравствуйте, Mr.Delphist, Вы писали:

MD>А на кой <censored> Вам этот учёт? Вы что продаёте, продукт или репорты о расходе времени? Если какой-то товарищ тратит слишком много времени на выдаваемые ему задачи, то одно их двух: либо он плохо к ним подходит, либо эстимейт задач занижен.
MD>- если такое повторяется у данного товарища регулярно, возникает вопрос о его квалификации
MD>- если такое повторяется у многих товарищей регулярно, что-то не так с эстимейтами
Я добавлю еще и третий вариант:
-товарищ низко мотивирован, посему (например) занимается подработками в рабочее время, за счет чего мало внимания уделяется основным работам.

Теперь по теме:
Учет времени, который ТС желает организовать, ИМХО не имеет практического значения.
Для Заказчика важно определить затраты времени на тот или иной bug-fix.
В этом случае логично ввести несколько критериев сложности (и трудозатрат) для bug-fix-ов.
Оценить среднее время по каждому типу bug-fix-а — например:
1) Низкой сложности — пол дня (4 часа);
2) Средней сложности — один день (8 чесов);
3) Высокой сложности, проблемный — два дня (16 чесов).
Для девелопера важно эстимайтить даже НЕ ВРЕМЯ, затраченное не исправление, а уровень сложности, то есть выбрать один из вышеуказанных типов.
Дла ПМ-а останется только сопоставить время с типом bug-fix-а и сообщить соответствующую инфу Заказчику.

Здравствуйте, es3000, Вы писали:

E>2) есть какие-нибудь системы, которые позволяют это делать? Желательно, чтобы они как-то были связаны с трекером

Посмотрите Task Coach, может подойдет. Считает время, и, если хочется, даже деньги. Связи с трекером нет, но возможна коллективная работа.

P.S. Всю ветку не осилил, может уже предлагали...

Здравствуйте, es3000, Вы писали:

J>>в чем разница — забиллите Вы 4ч 50м по $80/hr = за $386.66
J>>или 8ч по 49$ = $392

E>Разница в том, что зная реальный результат (4ч 50м по $80/hr), ты под него подогнал стоимость за 8ч.
E>А если бы ты не знал реального результата, как бы высчитал стоимость 1 часа для 8-часового дня?
E>Это первое.

Коллеги, а сколько вы при этом заплатите программисту и как вы будете эту сумму рассчитывать?