Статья

Как оценить задачу в проектном менеджменте и не ударить в грязь лицом?

Идеолог качества, экономист Джозеф Джуран подчеркивал, что 85% проблем качества в компаниях происходит из-за системы менеджмента, и только 15% — по вине исполнителей. Другой американский ученый, Эдвард Деминг утверждал, что менеджеры ответственны за 96% факапов, а исполнители — лишь за 4%. Получается, что в большинстве проблем виноват менеджмент. 

Улучшить неутешительную статистику помогает правильная оценка проектов. Один из трендов на западном рынке, который постепенно становится все более популярным и в наших IT-компаниях — оценка задач в Story Points. Вместе с Agile Project Manager Юрием Кукой разбирались в методах оценки проектов и принципах работы в Story Points.

Динамика за пять лет показывает, что из всех проектов успешны только 30%. Остальные 70% либо остаются незаконченными, либо же на выходе не соответствуют ожиданиям заказчика. 


Основной причиной факапов является то, что команда неправильно оценила свои усилия, соответственно, не вложилась в дедлайн и бюджет. Предсказать будущее невозможно, но основываясь на своем опыте и исторических данных (yesterday weather), ты можешь дать определенную экспертную оценку (forecasting), которая поможет избежать провалов.


Какие бывают методы оценки задач?

Существует пять методов оценки: экспертная, сравнительная, параметрическая, оценка по трем точкам и оценка “снизу-вверх”. Важно уметь комбинировать их в зависимости от ситуации. 


На графике мы видим две шкалы. Первая показывает, насколько оценка быстрая и “грязная”, вторая — насколько ожидание соответствует реальности.

1) Экспертная оценка

Самая быстрая и неточная. Мы собираемся командой и спрашиваем специалиста в определенной области: “Сколько времени займет данный проект?”. Он отвечает, например: “Месяц” или “Полгода”. На основе полученной информации мы строим графики и road maps. Экспертная оценка позволяет получить грубый эстимейт (от - 25 до +75), но давать прогноз заказчику на его основе не стоит.

2) Оценка по трем точкам 

Более точная и сложная. Вычисляется по формуле. Наиболее вероятную оценку реализации проекта умножаем на 4, складываем с оптимистической и пессимистической оценкой. Полученный результат делим на 6. Далее определяем коэффициент отклонения: вычитаем из пессимистической оценки оптимистическую и делим на 6.


Что такое оптимистическая и пессимистическая оценки? Рассмотрим на примере твоей дороги на работу. Оптимистическая оценка: если все светофоры будут гореть зеленым, ты доберешься до офиса за 20 минут, наиболее вероятная — 30 минут, пессимистичная — если в городе пробки, произошло ДТП или перекрыто движение  — 50 минут. По вышеуказанной формуле получаем среднее значение — 31,6 минут и коэффициент отклонения — 5 минут.  Таким образом, с вероятностью 68% ты приедешь на работу в диапазоне 31,6 ± 5 минут. Если умножить коэффициент отклонения на 2, то вероятность попадания — уже 95,4%, но и диапазон увеличивается и теперь составляет 31,6 ± 10 минут.

Даже математические формулы не дадут тебе точную оценку срока, к которому ты гарантировано закончишь работу.

3) Сравнительная оценка 

Разберем на примере. Допустим, ты находишься на последней станции красной ветки киевского метро  “Академгородок”. Тебе звонит друг и спрашивает: “Через сколько ты будешь на Крещатике?” Но ты не частый гость в Киеве, поэтому твоя экспертная оценка будет размытой: “Через 1 час”. Но проехав одну станцию, ты узнаешь, что отрезок из пункта "А" в пункт "Б" поезд преодолевает за 4-5 минут. Соответственно, если перед тобой еще 9 таких отрезков, с учетом своего прошлого опыта ты сможешь дать более точную оценку: дорога займет 45 минут, а не час.


4) Параметрическая оценка

Распространена в строительстве. Допустим, ты делаешь ремонт на кухне и хочешь постелить линолеум. Ты знаешь площадь пола и размер линолеума, который нужно купить, стоимость услуг мастера и т.д. Соответственно, заложив определенные риски (кусок линолеума, например, может порваться), можешь рассчитать точную оценку стоимости укладки линолеума на кухне. Формула простая —  разделить объем работы на производительность.


Однако в IT объем работ постоянно меняется, потому что нельзя предвидеть все нюансы. Производительность разработчика определить также практически невозможно из-за меняющейся эффективности работы (час работы в понедельник утром не равен часу работы в пятницу вечером) и внешних факторов (не выспался, перепил, заболела кошка и т.п.). Получается, что мы одно неизвестное делим на другое, добавляем к результату 20% рисков и продаем заказчику. Так оценивать задачи крайне не рекомендуется.

5) Оценка “снизу-вверх”

Самый точный и ресурсозатратный метод. Смысл в том, чтобы разбить крупные задачи на мелкие. К нам зашел проект, структурно в нем должен быть frontend, backend, веб-админка для администрации проекта. Дальше разбиваем front на главную страницу, регистрацию, back office. Разбиваем регистрацию: по e-mail, по телефону, по соцсетям. В задачах есть front, back, тестирование. Прорабатываем эту цепочку и оцениваем задачи, начиная от самой мелкой, постепенно двигаясь вверх. В конце все суммируем и получаем определенный эстимейт.



Почему оценка в часах не работает?

Оценивать задачи можно в следующих единицах:

  • время (часы, деньги, недели, месяцы);
  • деньги (доллары, евро, гривны, рубли и т.д.);
  • Story Points.

Оценка в часах, как правило, необъективна и не учитывает эффективные часы работы. В такую оценку не закладывают: 

  • социальные сети;
  • звонки по телефону;
  • перекуры, кофе;
  • общение с коллегами;
  • походы в туалет;
  • прокрастинацию.
Реально из 8-часового рабочего дня эффективно человек работает 4-5 часов. Таким образом, из 720 доступных в спринте часов, реальное capacity (количество идеальных часов, доступное в следующем спринте) составляет 504 часа, при этом 216 часов являются неэффективными. Исходя из среднего рейта 10 долларов в час, 216 часов — это 2160 потерянных долларов за спринт, либо 4320 потерянных долларов в месяц.


Таким образом, становится ясно, что оценка в часах — лживая. 


Как оценивать в Story Points?

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

Большинство из озвученных проблем решает сравнительная оценка Story Points, которая показывает “размер” задач относительно друг друга и помогает команде планировать на долгосрочную перспективу. Такой метод позволяет достаточно точно оценить задачу.

Story Points — эфемерная оценка (оценка в “попугаях”), которая не имеет физических единиц измерения. 1 SP — это оценка потраченных усилий всей команды (разработчики, верстальщики, QA) на реализацию самой простой задачи (выход на live). Оценивается не длительность задачи, а ее размер относительно другой.


Оценка в Story Points будет эффективной, если будут выполнены следующие условия:

  • состав команды не меняется;
  • один и тот же продукт; 
  • velocity (средняя скорость команды, количество закрытых SP за спринт);
  • задачи выполняются только в спринте;
  • крупные задачи декомпозируются на мелкие;
  • оценивает вся команда и все задачи;
  • задачи сравниваются между собой.


Что используют для оценки в SP?

Чаще всего для оценки в Story Points используют шкалу Фибоначчи (правда, с некоторой корректировкой), в которой значение числа равняется сумме двух предыдущих.


Вторая по популярности — оценка задач в трех осях (объем, риски, сложность). Объем задачи —  время, которое уйдет на ее реализацию. Иногда бывает что задача достаточно объемная, но по сложности очень легкая и тривиальная. Бывает наоборот — задача небольшая, но сложная, требующая анализа и несущая определенные риски.

Соответственно, по этим критериям формируется табличка по задачи для каждого отдела (разработчики, дизайнеры, QA). Оценивать объем, сложность и риски можно от 1 до 3, либо от 1 до 5. Команды голосуют по этим критерии, суммируют и определяют “вес” задачи в Story Points.


Некоторые команды используют другой подход — оценку задач в футболках. Самая простая и маленькая задача команды обозначается размером XS. Относительно этой задачи сравниваются все последующие (S, M, L, XL, XXL). Соответственно, так команда может планировать, сколько больших, средних и крупных задач может сделать за спринт.


Аналогичная оценка — оценка в буквах (A, B, C, D, E), где A — самая мелкая задача, E — самая крупная.


Как определить скорость своей команды?

Velocityсредняя скорость команды — определяется постфактум. Этот показатель демонстрирует среднюю динамику, которая помогает бизнесу планировать долгосрочные перспективы, делать квартальные и годовые планирования. 

Зная динамику своей команды, ты можешь рассчитать, сколько SP она выполняет за спринт (например, 100 SP) с учетом прокрастинации и других внешних факторов. Корректно брать усредненное значение по последним пяти спринтам. 

На графике ниже мы можем увидеть, что гарантированная динамика команды на протяжении девяти спринтов составляла 9-10 SP. Не гарантированная при благоприятных обстоятельствах — 12-15 SP. Если повезет — 20-30 SP. Эти метрики нужно снимать и анализировать.


Стоит учитывать, что Velocity одной команды не равно Velocity другой. Если одна команда закрывает 100 SP, а другая — 1000 SP, это не значит, что первая работает хуже. Каждая команда берет за эталон свою конкретную задачу, поэтому сравнивать эти значения между собой некорректно.


Как переходят на SP?

С точки зрения японской философии Кайдзен, переходить на SP нужно плавно. Вначале давать оценку задачам в часах, потом начать дополнительно оценивать в SP Через три спринта, собрав статистику и рассчитав velocity, начать отказывать от часов в пользу SP. 


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

Хочешь узнать больше? Регистрируйся на онлайн-курс "Управление проектами в IT (PM)"

Подпишись на еженедельный дайджест и получай на почту:

лучшие статьи, видео вебинаров, предстоящие события, интервью с лидерами индустрии

Наши каналы в социальных медиа: