Перестаньте оценивать задачи

Всем привет! Меня зовут Алексей, я руковожу командой разработки в Xello. Немного о себе и нашей компании я рассказал в предыдущей статье. Продолжая тему процессов и инструментов, сегодня хочу затронуть еще один аспект — оценку задач в командах разработки.

Я более десяти лет активно участвую в разработке большого количества продуктов в самых разных компаниях. И ни разу не встречал команды, которая бы сделала свою фичу в срок (за исключением текущего места работы:)). Также я не видел диаграмм сгорания задач (Burndown Chart), которые бы вышли в ноль. И в этой связи возникает вопрос: насколько эффективно оценивать задачи в разных величинах?

На мой взгляд, оценка может решить две ключевые задачи:

Как правило, задачи приоритизируют через скоринговую таблицу (часто даже бессознательно). В самом простом варианте это выглядит следующим образом: есть сложность (effort) и значимость (impact). Чем меньше сложность и больше значимость, тем выше приоритет задачи. Effort и Impact оценивается от 1 до 5 абстрактными величинами. Это хороший способ формализовать приоритизацию, если она зависит от большого количества факторов, в том числе, например, от степени неопределённости и рисков. Абстрактная сложность в такой матрице – один из элементов, влияющих на итоговый приоритет.

Мы строим такие модели в Product Discovery от Atlassian. По матрице Effort-Impact можно измерять эффективность приоритизации.

Пример распределения задач по матрице Effort-Impact:

Матрица готовых задач:

Матрица задач, которые мы взяли в работе:

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

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

Оценка по времени нам необходима, чтобы понять, к какому сроку и какую задачу мы реализуем (построить диаграмму Ганта, разбить на квартальные цели, построить дорожную карту (Roadmap) со сроками реализации, запланировать другие смежные активности компании).

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

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

В таком же формате это работает при недельном/двухнедельном планирований на уровне каждого отдельного разработчика.

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

Важно только количество задач, которые мы сделаем за неделю/квартал.

Теперь перейдём к абстрактным величинам (а-ля Story Points).

По заверению популяризаторов Story Point-ов в рамках Agile, на длительной дистанции сложность задач начнёт соотноситься со временем. В идеальном же мире, если задачи декомпозировать атомарно, то каждая из них должна быть размером в 1 Story Point. Команда, которая научилась так декомпозировать задачи, будет брать стабильно определенное число задач в спринт, не задумываясь про их оценку.

Чтобы дойти до этого этапа, необходимо определить количество story point-ов, которое будет закрываться командой за спринт для вычисления среднего значения на длинных дистанциях. Почему это не работает на практике:

SP можно переводить в часы.

Задача SP в рамках процесса планирования на длинной дистанции — научиться планировать реализацию задач с учётом неопределенности. Планирование — функция от времени.

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

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

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

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

Как это работает у нас сейчас:

5. Обсуждаем, что помешало выполнить задачи и учитываем это при следующем планировании по итогам спринта.

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