Заметки: Про оценки и календарь. Введение

Начинаю цикл заметок, посвященных оценкам и календарному планированию.

Оценки + календарь... Тех, кто работает с волшебными единорогами заказчиками, которые берут на себя все риски команды — тем такое не нужно. Их заказчик кладет портмоне на стол и говорит: возьмите сколько надо. Справедливости ради, надо признать, что все равно, работающие в таких условиях, занимаются планированием, но только неявным и более затратным (об этом будет отдельная заметка).

Как быть тем, кто лишен такого счастья и работает по обыкновенным стандартам взаимоотношений «заказчик — исполнитель»? Т.е. вынужден называть цену и сроки, пусть даже и интервальные. Понятно, что даже на FC проектах заказчик закладывает буфер ~20...30% на случай изменений. Ну или на случай ваших факапов. Да-да, заказчик закладывается и на это. Он будет, конечно, упираться, но оплатит ваши ошибки. Ему же тоже невыгодно работать с убыточной командой, не так ли?

Среднестатистический разработчик, осознанно или неосознанно, agile-ист он или «классик» — оценивает задачу по PERT-овскому трех-параметрическом принципу «могу и за столько» — «реально успею» — «дольше этого просто позор» (перевод вольный :). Причем, оценка очень часто ведется по принципу измерения стоимости реализации задачи в условных попугаях «я же умный, за неделю справлюсь», а не в планомерном осмыслении и проектировании реализации и оценки этой самой реализации для каждого из 3-х сценариев любой фичи любого проекта.
В любом случае, в проекте вам придется дать оценку бюджета и хуже того — календаря. Практик оценки и календарного планирования описано множество, но основной применяемый метод следующий (он же самый простой из мне известных):

1. Бюджет буферируется на некую условную оценку рисков. Некоторые пытаются выписывать риски по отдельности, но чаще всего — это очень формальный процесс и риски «назначаются» по тому же самому старому доброму pert-овскому принципу: в качестве бюджета задачи благоразумно берется «реально успею», а к ней плюсуется дельта между «реально» и «дольше этого просто позор». Причем, этот процесс часто происходит неосознанно, просто «так получается» :)
2. Если участников больше одного — бюджет задачи умножается на некий эмпирический или не очень «коэффициент внутрикомандного взаимодействия» от 1,3 до N в зависимости от числа участников.
3. Бюджет задачи делится на количество участников и на 8, после чего округляется в большую сторону — получаем количество рабочих дней.
4. Накладываем рабочие дни на календарь и минусуем выходные и праздники.
5. Все, календарь «готов».

Понятное дело, что этот подход — один из паттернов работы «на отвяжись». И даже если команда укладывается в 72% вероятности достижения «реально», то это вообще-то случайность — происходит обычное перераспределение усилий между задачами, где-то раньше, где-то позже — в итоге 36,6 по больнице получаются. Ну или не получаются, что бывает чаще — закон Паркинсона по выеданию буферов и рисков до того, как они реально понадобятся — никто не отменял :)

Продолжение следует...

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU