Когда будет сделано

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

Обычно, для планирования проекта мы берем старшего инженера и просим проект запланировать. Человек уходит на неделю в пещеру, изучает, разбивает проект на задачи, выясняет зависимости, оценивает каждую задачу в днях и возвращается с числом: 42.

Чем более опытный профессионал тем больше буфера заложено в оценку. Потому что лучше выкатить раньше, чем протянуть срок. Здесь кроется первая ошибка. Если вы не допускаете проскальзывания сроков, то ни о каком точном планировании речи быть не может. Вы постоянно будете добавлять буфер, чтобы успеть наверняка. В английском есть идиома to sandbag — дословно — огораживаться мешками с песком. Чтобы защититься от наводнения или пуль.

Точное планирование, как и любое предсказание дается со степенью уверенности:

 — 85%, что мы выкатим проект к указаной дате.
 — Клиент вредный, давай по 95% посчитаем. Сколько надо еще времени

Как получить оценку, да чтобы еще с разной степенью уверенности. Не просить же инженера выдумать такое распределение?

Выдумывать не нужно. Все необходимое у вас уже, скорее всего есть. 1) Вам нужно знать сколько тикетов в неделю закрывает команда. Для этой статистики нужно брать проектные тикеты, а не все подряд, типа багфиксов. Такой статистики нужно как минимум за 7 прошлых недель. 2) Дальше вам нужно знать сколько тикетов предстоит сделать. Важно, чтобы тикеты были нарезаны в разумном диапазоне и не отличались на 500% друг от друга. 3) Вам нужно знать, сколько всего людей будет работать на проекте минимум и максимум.

Вот и всё.

Если вы хотите улучшить качество предсказания, то желательно добавить 1) время, которое вы тратили на тикеты в прошлом (lead time) и 2) расхождение с планом в прошлых проектах. Иногда начинаешь проект на 10 задач, а заканчиваешь с 40.

Эти данные загружаем в симулятор Монте-Карло. Этот симулятор я подсмотрел в рассылке для менеджеров в Амазоне. Сам симулятор работает прямо в браузере и никуда ваши данные не отправляет.

Симулятор прогоняет десятки тысяч возможных исходов вашего проекта и дает вам график распределения вероятности исходов. Те самые проценты, которые можно показывать заинтересованным лицам.

[иллюстрации так же в комментариях]

Таблица вероятности.

График распределения вероятности.

По моему опыту заинтересованным лицам и парировать нечем. Данные выглядят очень убедительно и взяты не с потолка, а из статистики работы команды.

В моем случае 100% совпали с оценкой программиста, только дата была далеко дальше дедлайна и нас гарантировано бы начали уговаривать придумать дату ближе к дедлайну. Крыть бы нам было нечем.

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

Не откладывайте на потом, как это сделал я. Вам нужно всего 7 недель данных. Попробуйте в понедельник, хоть прямо на том проекте, который у вас уже в процессе.

Пост: https://teamleadtalks.com/koghda-budet-sdelano/

Вступайте в сообщество.