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

Ссылка на оригинал статьи с объяснением принципа Доказательного Планирования

• Joel Spolsky Evidence Based Scheduling

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

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

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

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

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

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

Решение

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

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

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

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

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