Моделируйте будущее или Теория Вероятности в действии (по мотивам статьи Joel Spolsky)

Ссылка на оригинал статьи с объяснением принципа Доказательного Планирования (в оригинале Evidence Based Scheduling - EBS)

• Joel Spolsky Evidence Based Scheduling

• Перевод на русский от @vadim_ig

Какую проблему удалось решить?

Из опыта работы в "Кровавом Enterprise" плечом к плечу с Менеджером Продукта, перед поступлением очередной задачи в работу, у меня интересовались, сколько на нее уйдет времени (внезапно). Это, можно сказать, напрягало тем, что такая оценка должна затрагивать все возможные факторы "торможения". Соберу в список некоторые из них:

• Неоднократное выяснение деталей до того момента, как задача станет "прозрачной"

• Перерывы в работе по разным причинам

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

Решение

Чтобы получить прогноз для конкретной задачи по срокам, достаточно иметь статистику по аналогичным задачам, каждая из которых должна иметь: 1) дату старта исполнителем; 2) дату прогноза от исполнителя; 3) дату фактического ее завершения (которую нужно потом двигать по мере доработки задачи). Таким образом, процесс планирования сроков фичи перед тем как разработчик возьмет задачу в работу должен основываться на двух вопросах к нему:

1. Какова сложность фичи по шкале от 1 до 5?

2. Сколько времени тебе нужно для ее выполнения?

Далее следует вопрос самоконтроля эффективного менеджера - зафиксировать даты старта и фактического завершения этой задачи (это важно!). С момента завершения первой задачи, можно предсказывать будущее, с учетом ошибок разработчика, основываясь на предыдущем опыте работы с ним: Чем больше задач набирается в опыт, тем точнее прогноз.

Да, кстати, важный момент! Прогноз исполнителя не должен основываться на аналитически расчитанном прогнозе программы (рекурсия и в этом случае не принесет пользы, если Вы понимаете, о чем я).

Следствие - всегда результат принятых решений (ц)

? Демо

Хотел собрать обратную связь насчет реализации демо версии.

Пару слов о том, как я использую эту программу в своей работе:

1. Создаю новую таску, назначенную на исполнителя, который оценивает ее навскидку:

   а) субъективная оценка сложности от 1 до 5 - возможно, эту оценку можно скорректировать по факту выполнения задачи (думаю, по итогам ретроспективы в момент завершения таски - самое время);

   б) субъективные сроки выполнения (первоначальная дата обещания от исполнителя) - ее потом менять нет смысла, т.к. это основа метода;

   в) фиксирую дату старта выполнения - она должна соответствовать факту старта;

2. ⚡ Если такая задача не первая! Получаю прогноз по методике EBS на самый худший вариант развития - это тот самый срок, который следует озвучить Продукт Менеджеру;

3. Фиксирую фактическую дату завершения задачи - это именно тот параметр, который следует скорректировать в случае, если задача потребовала доработки для более точной статистики и, как следствие, более точной оценки последующих задач.

При наличии статистики, перед постановкой задачи можно прикинуть, насколько "обманет" испытуемый исполнитель:

Основная задача - отобразить наиболее неблагоприятный расклад

Конструктивная критика приветствуется в комментариях