Разбор ситуации(кейса) 3 для ПМа. Оценка даты завершения и размера команды.

Продолжая разбор кейсов для ПМа. Третий кейс будет про оценку планируемой длительности проекта и размер необходимой команды.

Вот ссылки на предыдущие разборы кейсов

Условие кейса

Вы собираетесь начинать новый проект как ПМ, у вас есть достаточно подробное описание объема работ в виде ИСР (иерархической структуры работ) с оценкой каждого пакета работ в часах.
Общая оценка проекта в часах — 3800.
— Бекенд — 1500 часов
— фронтенд — 1000
— тестирование — 600 часов
— ПМ/БА — 400 часов
— остальные 300 часов — на коммуникацию, риски, релиз и прочее (буфер).

Дата начала проекта — 1 июля. Дизайнер или кто-то ещё не нужен (клиент предоставляет)

Вас просят составить календарный план проекта и рассчитать исходя из 2х вариантов:
1) рассчитать дату планируемого окончания проекта. Бекенд и фронтенд будет по 2 человека, нет жесткого дедлайна.
2) рассчитать размер команды. Бюджет есть на весь проект, но есть дедлайн — 3 месяцев на всё, от начала до приемки и закрытия контракта.

Решение

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

Для визуализации календарного плана проекта я буду использовать диаграмму Ганта, составленную с помощью инструмента MS Project. Если вы ещё не работали с MS Project, то можете подробнее почитать здесь.

Расчет даты окончания проекта

Рассмотрим различные случаи для расчетов:

1. Работы по разработке не параллелятся, критический путь — все задачи разработчиков по цепочке одна за  другой

В этом случае, расчет по цифрам из кейса дает нам дату окончания проекта
без буфера (запаса) — 7 ноября (то есть чуть больше 4х месяцев),
с буфером — на неделю позже — 15 ноября

Что важно отметить при таком расчете:

  • загрузка людей, которые не пишут непосредственно код, то есть QA, PM, BA на проекте будет не на полный день и это может составлять определенную проблему для того, кто управляет расписанием и занятостью ресурсов в вашей компании. 
  • одновременная работа 2х людей над одной и той же задачей скорее всего будет не так эффективно, как просто время одного человека поделить на 2, как в этом расписании, поэтому финальную дату проекта можно брать только как грубую оценку длительности проекта
  • по расписанию фронтенд закончит раньше чем бекенд, если начнет с ним одновременно, поэтому в реальности начала работ фронтенда будет отложено, чтобы закончить одновременно или даже немного после бекенда из-за зависимостей

2. Некоторые работы можно выполнять параллельно, когда каждый из разработчиков работает над отдельной задачей автономно

В этом случае, расчет по цифрам из кейса дает нам дату окончания проекта
без буфера — 18 ноября (то есть чуть больше 4х месяцев),
с буфером — на неделю позже — 25 ноября

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

В большинстве компаний, которе занимаются заказной разработкой ПО, такой проект будет считаться маленьким. Если оценку длительности надо дать быстро, то составлять календарный график и диаграмму Ганта нет необходимости.
Достаточно взять самый длинный участок работ, в нашем случае это бекенд — 1500 часов, затем узнать, на сколько разработчиков параллелится работа, сколько у нас доступно разработчиков.  Разделив 1500 на 168 (один мифический человеко-месяц), получим сколько всего человеко-месяцев нам надо — в нашем случае практически 9. Поделив 9 на 2 разработчика мы получим 4,5 месяца, что соответствует варианту 2 без буфера (1е июля — 18е ноября). Если мы добавим буфер, то получим тот же результат, как и при создании календарного графика.

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

Расчет размера необходимой команды

При наличии ограничения в виде дедлайна — наша задача определить насколько вообще реально, даже имея неограниченные ресурсы, уложиться в эти ограничения по срокам.

Как говорится, девять женщин не родят ребенка за месяц, так и в некоторых случаях становится понятно, что работу невозможно распараллелить на нужное количество разработчиков из-за внутренних зависимостей.

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

Три месяца из условий — это 504 часа одного разработчика, не считая буфера на коммуникации, риски и прочие потери. В реальности мы можем смело рассчитывать что только 400 часов из этих 504 будут потрачены продуктивно.

В некоторых случаях, из-за наличия зависимостей, часть работ проекта с меньшей оценкой в часах будет заканчиваться дольше, чем другая часть с большей оценкой. Например, если мы начнем делать фронтенд, только после того как будет закончена как минимум половина бекенда.

Возьмем самую длинную работу проекта — для нашего кейса допустим что все же бекенд будет делаться дольше всего.  Посчитаем: если мы разделим 1500 на 504 идеальных часа, то получим, что нам надо 3 бекенд разработчика, чтобы закончить за 3 месяца, но в таком случае у нас не остаётся никакого резерва и мы очень сильно рискуем. Нам не стоит говорить, что нам надо меньше чем 4 бекенд разоработчика, чтобы не оказаться в неприятной ситуации по ходу выполнения проекта.

Возможно мы просто подключим 4го бекенд разработчика на проект только со 2го месяца, например, чтобы снизить расходы, хотя намного менее рискованно подключать его сразу и снизить размер команды после 2х месяцев, когда станет понятно, что мы с большой вероятностью в сроки попадаем. В начале проекта мы не знаем, какой точно буфер нам будет нужен. С течением проекта необходимый буфер будет меньше.  Очень сложно обосновать и продать клиенту слишком большой буфер.

Посчитаем другие части проекта: Фронтенд. 1000 поделить на 504 — та же история, вроде нужно 2, но лучше иметь 3х разработчиков, чтобы повысить свои шансы уложиться в дедлайн.

Тестирование. Исходя из того, что у нас уже примерно 7 разработчиков (фронт + бекенд), нам понадобится как минимум 2 тестировщика, чтобы тестирование не стало узким местом проекта и не начало тормозить разработку. Простым подсчетом, что 504 * 2 = 1008 мы понимаем, что количество часов на тестирование, при таких сжатых сроках будет недостаточно. Именно поэтому средний процент на тестирование в индустрии — 25-30% от количества часов разработки. Вам придется прийти к заинтересованным лицам проекта либо вашему руководству и показать им необходимое увеличение бюджета исходя из ваших наглядных расчетов. Попытка сэкономить и остаться с оригинальным бюджетом сильно повысит риски проекта не уложиться в ограничения по срокам.

Аналогично ПМ и БА на двоих должны иметь хотя бы один полный день, чтобы обслуживать команду такого размера. Количество часов, необходимых для них двоих вместе будет равно 504, это тоже больше 400 часов из условия и, как и в случае с тестировщиками, вам необходимо будет донести до спонсоров проекта необходимость увеличения бюджета или принятия повышенных рисков — одно из двух.  

Итоговая команда

  • Бекенд разработчики — 4
  • Фронтенд разрабтчики — 3
  • Тестировщики — 2
  • ПМ/БА — 1 или, если каждую из ролей выполняет отдельный человек, то 2, каждый на пол ставки

Дополнительное чтение по теме

  1. PMBOK® Guide – 6е издание, Глава 6 — Управление сроками проекта
  2. Сергей Архипенков — «Оценка трудоемкости и сроков разработки ПО«
  3. Tom Demarco and Timothy Lister – «Deadline. Роман об управлении проектами», «Человеческий фактор. Успешные проекты и команды», «Вальсируя с медведями»
  4. Dr. Cristoph Steindl, IBM – Estimation in Agile Projects 
  5. Настройка представления Диаграмма Ганта