Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.

Как я люблю эти оценки разработчиков: «нууу…эта задача на полчаса». Через два дня: 

— Ну че, когда будет готово? 

— Да тут уперлись в интеграцию и еще нужно кое-что согласовать с аналитиком, думаю за сегодня закрою...

Еще через день:

— Еще делаю, вчера не успел, думаю завтра будет готово. 

Занавес. И проблема здесь не в разработчиках. Просто абсолютные оценки НЕ работают.

Если большую задачу оценивать по сумме мелких подзадач и не закладывать время на уточнения, передачу задачи из отдела в отдел, «ждем, когда починят», «жду ответа» и прочие неопределенности, сроки реализации задачи ВСЕГДА будут слетать. Почему они будут слетать? Потому что учесть на старте все невозможно. Существует много неопределенностей по ходу разработки, включающие объем работы, техническую сложность, простои, задержки, согласования, ожидания. И какие бы мы инструменты планирования ни старались использовать, сроки разработки все равно слетят.

Как же тогда планировать время выполнения?

1. Я рекомендую собирать статистику времени выполнения целиковой ценности. Например, пользователь хочет добавить способ оплаты в один клик с Apple Pay. Задача распадается на разработку, тестирование и так далее. Нам важно знать, когда будет готова фича, а не когда разработчик и тестировщик сделают свои задачи. Поэтому мы начинаем собирать статистику времени выполнения для каждой целиковой задачи.

Часто время ожидания между передачей задачи из рук в руки не учитывается. Поэтому важно настроить трекер так, чтобы фиксировать время на целиковую задачу. Для этого нужно настроить сбор статистики задачи от статуса «выбрано в работу» до «готово». В итоге получите распределение времени выполнения по завершению задач. И тогда вы будете при планировании опираться не на предиктивные данные в попытке все учесть, а на данные статистики. Статистика же покажет реальную картинку и отразит, через какое время задачи проходили через систему. Такое распределение можно собирать для каждой из категорий задач. Чтобы упростить, я рекомендую выделить в вашем бэклоге несколько типов задач по объему (например, S — самая маленькая, M — средняя, L — большая, XL — очень большая) и для каждого типа строить свое распределение. 

2. Чтобы планировать время выполнения новой задачи, стоит ориентироваться не на экспертную оценку разработчика, а на статистические данные! Берем график выполнения задач и смотрим, за какое количество времени закрывались похожие задачи.  

Например, три задачи выполнены за 10 дней, а девять рабочих элементов — за девять дней. С 89% вероятностью следующая задача будет выполнена в срок до 10 дней, так как задач всего было 28, а 25 из них сделаны до 10 дней.

Почему можно доверять статистике?

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

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

Пользуясь статистикой, в одной компании мы улучшили прогнозируемость выполнения задач до 90%, и когда заказчики приходили с новыми задачами, после их выбора мы давали объективные сроки. Была счастлива и команда, и заказчики. Команда — потому что на них не давили, а заказчики были спокойны.

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

Почему?

Для руководства мерой прогресса является законченный функциональный элемент, так как он потенциально может принести новую прибыль компании. Число потраченных часов разработчиков никакой информации о прогрессе не дает, кроме того, что разработчик усиленно трудился. Сумма относительных единиц равна производительности команды. То есть она определяет, какое количество целиковых задач несущих ценность может сделать команда за спринт.

Здесь также фокус на статистике — вы собираете статистику завершенных относительных единиц в спринте и на основе этого можете планировать будущие спринты. 

Оценка в относительных единицах — это оценка задач относительно друг друга путем сравнения, поэтому такая оценка не зависит от опыта разработчиков, и вариабельность оценок будет ниже. Также с помощью такой оценки оценивать задачи намного быстрее. По оценке одной компании оценка в относительных единицах экономит 80% времени на оценку.

Как оценивать в относительных оценках?

1. Возьмите ваш бэклог продукта (список задач).

2. Найдите в нем самые маленькие и схожие элементы между собой.

3. Договоритесь, что эти элементы вы примите за самые маленькие элементы и тогда их можно будет оценить в 1 SP (стори поинт), если вы оцениваете по Фибоначчи или в XS, если оцениваете по майкам. Особой разницы нет, какой метод использовать. Но на практике майки могут восприниматься командой на старте проще.

4. Далее найдите элементы в бэклоге, которые в 2 раза больше тех, которые 1 SP и договоритесь, что они 2 SP и так далее.

5. После запланируйте спринт. Пока нет статистики, первый спринт планируйте на основе ощущений и можете оценить задачи в часах.

6. После того как спринт завершен — посмотрите, сколько SP вы сделали.

7. У вас появились первые данные, продолжайте собирать дальше.

8. Через 3-5 спринтов у вас будет статистика, на которую можно опираться.

Важно понимать, что это не оценка, а прогноз, основанный на статистике. 

Какие могут быть плюсы от таких подходов к оцениванию:

• Сильно улучшается прогнозируемость и предсказуемость поставок. 

• Вы видите реальную картину по задачам в компании или департаменте.

• Улучшается качество планирования. Сдали фичу в срок — клиент доволен. Больше никаких извинений из-за переноса сроков.

• Скорость планирования и оценки задач возрастает в два, а то и в три раза.

• Даете объективные прогнозы заказчику на основе статистики.

Приглашаем всех желающих на бесплатный вебинар «Как правильно увольнять человека». Увольнения — сложная тема, поэтому научимся работать с увольнениями, как с нормальной частью менеджерской деятельности. Обсудим:
— Кого и почему надо увольнять?
— Причины увольнения; законодательная основа; сроки увольнения;
— Увольнение по инициативе сотрудника — как предотвратить.
Регистрация на занятие.

А если вам понравилась статья, жду в своем телеграмм канале и на сайте.