Ссылка на оригинал статьи с объяснением принципа Доказательного Планирования (в оригинале Evidence Based Scheduling - далее будет фигурировать как EBS)
- Joel Spolsky Evidence Based Scheduling
- Перевод на русский
Суть проблемы планирования
Из опыта работы в "Кровавом Enterprise" плечом к плечу с Менеджером Продукта, перед поступлением очередной задачи в работу, у меня интересовались, сколько на нее уйдет времени (внезапно). Такая оценка должна затрагивать все возможные факторы "торможения", к примеру:
- Неоднократное выяснение деталей до того момента, как задача станет "прозрачной"
- Перерывы в работе по разным причинам
- Фактор непредсказуемости изменений ТЗ (добавление требований в процессе разработки фичи)
Да, слишком абстрактно, и эти пункты можно детализировать на много факторов, но сама проблема свелась к учету их всех неявным образом. Условно, будем считать, что проблема локализована (Вы удивитесь, но детали, действительно не так важны).
Каким я вижу решение
Чтобы получить прогноз для конкретной задачи по срокам, достаточно иметь статистику по аналогичным задачам, каждая из которых должна иметь четыре параметра:
- Дату старта исполнителем;
- Дату прогноза от исполнителя;
- Дату фактического ее завершения (которую потом
можнонужно двигать по мере доработки задачи); - Грейд задачи (сложность фичи по мнению исполнителя) - также может повышаться по мере разработки. Есть категория задач, в процессе реализации которых происходит рост сложности в связи с добавлением требований со стороны бизнеса. Таким образом, любая задача может перейти в категорию более сложных и ее прогноз при этом будет скорректирован.
Шаг 1: Два вопроса при постановке
- Какова сложность фичи по шкале от 1 до 5?
- Сколько времени тебе нужно на ее выполнение?
Шаг 2: Контроль дат
Далее следует вопрос самоконтроля эффективного менеджера - зафиксировать даты старта и фактического завершения этой задачи (это важно!). С момента завершения первой задачи, можно предсказывать будущее, с учетом ошибок разработчика, основываясь на предыдущем опыте работы с ним: Чем больше задач набирается в опыт, тем точнее прогноз.
Да, кстати, важный момент!
Прогноз исполнителя НЕ должен основываться на аналитически расчитаных значениях. Оценить должен именно исполнитель - именно его прогнозы имеют ценность для анализа.
Шаг 3: Результат анализа
Следствие - всегда результат принятых решений (из фильма "Разрабы")
А теперь посмотрим, что мы имеем:
- Предполагаемая дата лучшего сценария (обычно, мало кого интересует)
- Предполагаемая дата "среднего по больнице" сценария (наиболее бесполезный, кмк - см. спойлер ниже)
- ⚡ Предполагаемая дата худшего сценария - самая ценная информация при стратегическом планировании сроков фичи (*)
(*) Поправка в 2024: периодически возвращаясь к интересной задаче, пришел к выводу, что это не совсем верный подход (см. спойлер ниже)
Инструкция и Демо
Хотел бы собрать обратную связь насчет работы демо версии - мнение можно оставить здесь.
Пару слов о том, как я использую этот инструмент в своей работе:
- Создаю новую таску, назначенную на исполнителя, который оценивает ее навскидку:
- а) субъективная оценка сложности от 1 до 5 - возможно, эту оценку можно скорректировать по факту выполнения задачи (думаю, по итогам ретроспективы в момент завершения таски - самое время);
- б) субъективный срок выполнения;
- в) фиксирую дату старта выполнения - она должна соответствовать факту старта;
⚡ Если такая задача не первая! Получаю прогноз по методике EBS на самый худший вариант развития -
это тот самый срок, который следует озвучить Продукт Менеджеру(в обновленной версии все иначе, см. обновления в конце);Фиксирую фактическую дату завершения задачи - это именно тот параметр, который следует скорректировать в случае, если задача потребовала доработки для более точной статистики и, как следствие, более точной оценки последующих задач.
При наличии статистики, перед постановкой задачи можно прикинуть, насколько "обманет" испытуемый исполнитель:
В процессе работы каждый исполнитель обрастает собственным уникальным грейдом (можно сказать, коэффициент качества планирования):
- Меньше единицы - сотрудник ответственный либо перестраховывается;
- Больше единицы - сотрудник черезчур самоуверенный;
Теоретически, можно было бы выстроить рейтинг-лист в виде отсортированного списка сотрудников с отображением, кто из них свободен в данный момент либо когда вероятнее всего освободится. Из этого списка можно делать вывод, кому из Ваших коллег можно с большей вероятностью успеха доверить в ближайшее время ответственную задачу с "горящими сроками".
Продолжение следует...
🚀 Обновления 2024
Более удачный UX
- Estimated (заявленный сценарий) - прогрессбар доходит до 100%, дата заявлена исполнителем (никакой магии);
- The Worst (худший сценарий) - значение ожидаемой даты основано на той задаче, которая была завершена исполнителем с минимальной скоростью;
- 💥 Sensed ("ощущаемый") - это новый прогрессбар, значение даты, соответствующей 100% рассчитано как среднее между теми сценариями, скорости выполнения которых отличаются не слишком сильно (в него НЕ входят те задачи, которые завершены исполнителем аномально быстро или аномально медленно). Логика простая: Человек работает, как правило, [плюс-минус] с одной скоростью - алгоритм должен ее "ощутить". Как именно: если среди возможных вариантов скоростей его работы встречаются два с минимальным отклонением - это повод искать ещё варианты с примерно таким же отклонением. В итоге, найденные варианты образуют "скопления", среднее значение которых можно учитывать как наиболее вероятное.
Более удачный DX
- "Чем проще, тем лучше" - чисто клиентский билд для раздачи NGINX-ом. Как показала практика, простые проекты живут дольше, деплой проще и быстрее, инфраструктура без особых затрат
- Более современный стек технологий (за 5 лет кое-что изменилось)
Более удачный UI
- За основу взят MUI v6.x