Исправлена ​​ошибка распределения времени

Question

Клиент попросил нас дать оценку времени для каждой найденной ошибки.

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

Я не фанат выделения времени на ошибки, просто потому что:

1. Обычно неточно. Очень трудно понять, сколько времени потребуется, чтобы исправить.
2. Пустая трата времени.
3. Влияет на качество кода
4. Создает больше ошибок в долгосрочной перспективе (Мы можем упустить некоторые вещи в нашей попытке завершить его к крайнему сроку).

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

Как вы распределяете время своим ошибкам? Это эффективно? Стоит времени и усилий?

Answer 1

Единственный ответ, который я могу дать, - быть крайне консервативным. Угадай, сколько времени это займет, и умножь свое предположение на четыре. Используйте это как свою оценку. Как вы сказали, очень трудно понять, сколько времени потребуется, чтобы все исправить, и лучше сказать, что это займет больше времени, чем на самом деле, чем быть пойманным, «нарушая свой срок», потому что вы недостаточно консервативны. *

Answer 2

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

Итак, сначала мы довольно хорошо объясняем нашу позицию. В вашем примере это будет примерно так:

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

Однако я считаю, что стоит попытаться оценить, сколько времени займет исправление каждой ошибки. Причина этого заключается в том, что вы должны понимать, сколько времени займет исправление всех ошибок. Вы не сможете получить точную оценку, если у вас нет оценки того, сколько времени потребуется для исправления отдельных деталей. Конечно, это могут быть приблизительные оценки (оцениваются не дольше, чем потратить час на исследование проблемы) - вы не хотите тратить слишком много времени на оценку. Тогда я обычно учитываю дополнительные 20%. Скажем, оценки ошибок составляют 3 дня, 5 дней и 2 дня. Затем я сообщу клиенту, что мы сможем исправить ошибки за 12 дней. Тогда, конечно, вам, возможно, потребуется добавить больше времени для тестирования и повторной упаковки вашего продукта, прежде чем вы сможете дать ему результат.

Answer 3

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

Думайте об этом с точки зрения управления яростью клиента . Если вы скажете им, что исправление ошибок займет совсем немного времени, а в итоге они займут 3 месяца, ваш клиент будет счастлив с вами сейчас и в будущем будет в ярости.

Если вы скажете им, что на исправление ошибок уйдет 3 месяца, а на исправление у них уйдет 3 месяца (что и будет), ваш клиент будет в ярости сейчас и будет доволен вами в будущем.

Я обычно говорю, что ошибки не займут совсем никакого времени (2-3 дня кажутся хорошим умиротворяющим числом).

Answer 4

Если это ошибки, которые были обнаружены и сообщены, тогда вы сможете составить оценку времени, чтобы исправить ее (и время повторного тестирования). Достоверность оценки, вероятно, будет пропорциональна времени, которое вы тратите на оценку, возможно, объясните эту стоимость клиенту.

Если есть несколько связанных небольших сообщений об ошибках, возможно, вы могли бы свернуть их в один сводный отчет. Это может избежать попыток клиента выбрать и исправить ошибки на основе индивидуальных оценок.

Answer 5

Обычно мы соглашаемся, какие ошибки должны быть исправлены для определенного выпуска, а затем определяем временные рамки для исправления всех ошибок. Для каждой отдельной ошибки существует много неопределенности / изменчивости в том, сколько времени может потребоваться исправить, но это имеет тенденцию усредняться с большим количеством ошибок. Для некоторых известных вам ошибок может потребоваться больше времени, например, можно дать некоторые оценки, например, если вам нужно написать симулятор или тестовый фреймворк для него.

Answer 6

Почему бы просто не выбрать несколько полос для серьезности ошибки, например 1 час, 1/2 дня, 1 день, 1 неделя и назначьте против них. Как правило, у вас возникает чувство ошибки, о которой вы даже не подозреваете, и укажите наихудшую цифру!

Я бы не подумал, что вам захочется оценить на более тонком уровне, чем этот, по причинам, которые вы указали (слишком много времени для расследования и т. Д.)

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

Ни при каких обстоятельствах это не должно приводить к тому, что вы генерируете больше ошибок. Вы не должны торопиться с часами, чтобы исправить это. Если вы оценили 1 день, и это заняло 10 часов, это нормально. Если вы оценили 1 неделю, и это заняло 2 часа, хороший результат!

Это просто упражнение в оценке!

Answer 7

Вы правы, оценки, как правило, неточны.

Может быть, вы хотите спросить их, сколько стоит каждый баг, если он нефиксирован. Затем вы можете выполнить соответствующее вычисление, чтобы выяснить, нужно ли их когда-либо исправлять, и сколько времени вы (или реально) можете выделить для каждой ошибки.

Answer 8

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