Как сделать сторипоинт универсальной мерой всех вещей

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

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

Вторая важная цель введения универсального сторипоинта — сделать управление разработкой по-настоящему data-driven. Если у вас есть общая единица, то вы сможете посчитать:

• как со временем меняется производительность всей команды в сумме и в среднем на одного разработчика
• как конкретный разработчик прогресирует со временем
• задетектить провалы в производительности людей и команд
• посчитать стоимость производства одного сторипоинта (от ФОТа команды), и, как следствие, сколько будет стоит в производстве фича или целый проект

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

Представьте, что вам повезло и вы можете отмасштабировать команду и нанять дополнительных разрабов. На старте у вас 45 человек, можно дорастить команду до 65. В команде есть бэки, фронты, мобильные разработчики, датасайнтисты, тестировщики, аналитики. Они работают в разных продуктовых командах. Цель масштабирования — быстрее деливерить фичи, то есть увеличить time to market.

Вот три разных исхода ситуации:

Вариант 1. Хороший.
Вы наняли дополнительных 20 разработчиков (+44% к размеру команды), а производительность всей команды выросла даже сильнее (+75%), потому что выросла и средняя производительность на человека (+21%). Это могло произойти, если вы наняли бодрых, работоспособных миддлов и как-то потюнили процессы.

Вариант 2. Плохой.
Вы наняли тех же 20 человек (+44% к команде), производительность выросла чуть меньше (+42%), но начиная где-то с 10 нового разраба она расти перестала вообще. Следующие 10 новых сотрудников уже не принесли роста производительности, зато затормозили всех остальных, и средняя велосити на одного в результате вообще немного упала (-1,36%).
Это могло произойти, например, если вы наняли много джунов и они потребовали к себе больше внимания и времени, чем фактически принесли пользы. Либо вы набрали много QA, которые не производят SP сами, или синьоров, которые больше ревьювят и менторят, но не производят. И то, и другое влияет на качество продукта позитивно, и оно действительно могло вырасти, но если цель была в ускорении — то надо понять, устраивает ли вас такой результат за потраченные деньги.

Вариант 3. Хакерский.
Вы вообще решили не нанимать людей, а как-то хитро потюнили процессы и на свободный бюджет пообещали всем хорошие премии за высокие результаты. Итог: команда не поменялась (+0%), общая производительность выросла на 42%, потому что каждый разработчик стал работать в среднем гораздо эффективнее. Вы сделали свою разработку гораздо быстрее, time to market (вероятно) сократился, все счастливы.

Это интересная и классная аналитика.

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

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

• сложности
• трудозатрат
• неопределенности
• объема коммуникаций

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

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

Шаг 1. Начинаем с определения базовой сложности задачи.

Она может быть 1, 0,5 или 2.

0,5 — однострочник или супер-простая задача, гораздо меньше 1
1 — типичная простая задача, которую понятно как делать, и точно можно закончить в пределах одного рабочего дня
2 — задача, в которой чувствуются потенциальные подводные камни

Обычно это первая оценка, которую интуитивно дают разрботчики.

Шаг 2. Добавляем отягчающие обстоятельства.

После определения базовой сложности к ней можно добавить 1 или 2 дополнительных очка за каждый из четырех факторов риска.

Пример.
Базовая сложность задачи 1, простая задача.
Но она не слишком хорошо описана, точно в процессе потребуются уточнения, добавляем 1 очко за коммуникации.
Плюс, придется залезть в легаси код, с которым никто давно не работал, добавляем 2 за неопределенность.
Итого задача тянет на 1+1+2 = 4.

Шаг 3. Приводим к шкале Фибоначчи.

Сторипоинты принято оценивать по шкале Фибоначчи: 0, 1, 2, 3, 5, 8, 13
Мы тоже это сделаем, причем округление всегда будет идти в большую сторону. Если суммарная оценка задачи вышла на 4, то мы ставим финальную оценку в 5. Если бы оценка вышла 6 — мы бы поставили 8, если на 9 — мы бы поставили 13.
Это делается специально, поскольку чаще всего разработчики склонны недооценивать риски и трудозатраты, и округление в большую сторону дает более реалистичный результат.

Шаг 4. Декомпозируем крупные задачи.

Если финальная оценка задачи оказалась 8 или 13 — задача требует разбиения на составляющие. Её нужно разделить на несколько подзадач и каждую подзадачу оценить отдельно. 8 или 13 в оценке говорит о том, что в задаче очень много подводных камней, а ее оценка нереалистична.

Над «восьмеркой» разработчик точно будет сидеть дольше, чем над четырьми задачами по 2. Чаще всего декомпозиция «восьмерки» дает не менее 4-5 задач с разной стоимостью, а их сумма оценок может потянуть на 10, 15 или 20 сторипоинтов вместо 8. И это уже реалистично.

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

Оценивают задачи разработчики одной компетенции.

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

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

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

Оценивают задачи разработчики одной продуктовой команды.

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

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

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

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

• в группе может появиться сильный лидер, оценке которого все автоматически будут доверять, перестанут ставить ее под сомнение и вообще напрягаться и оценивать самостоятельно.
• со временем оценка делается менее внимательно и возрастает недооценка всех рисков, то есть задачи оцениваются дешевле, чем они есть на самом деле. В результате кажется, что производительность команды по цифрам снизилась, а на деле все стали просто хуже попадать в свои собственные оценки.
• Бывает, наоборот, что риски переоцениваются просто по привычке. Может возникнуть «инфляция оценок». Это когда та задача, которую полгода назад оценили бы на 1 спусти полгода тянет уже на 2 или даже 3.

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

Мы, в итоге, остановились на варианте оценок внутри продуктовых команд. Но чтобы поддерживать оценки универсальными и нивелировать негативные эффекты, мы придумали два процесса:

1. Супервизия оценок.
   Это значит, что на каждую оценку каждый раз приходит гость из другой команды. Причем гость всегда разный.
   У нас это были тимлиды, которые не привязывались к одной команде на оценках, а курсировали между разными командами. Они, во-первых, следили за соблюдением общей методики оценки, а, во-вторых, не давали проводить оценку «спустя рукава», задавали каверзные вопросы и не мирились с неформальными лидерами.
   
2. Наблюдение за балансом.
   Мы ввели метрики баланса оценок в командах и коэффициент разбаланировки, и наблюдали за ними после каждого спринта. В случае существенных отклонений от баланса мы видели, в какой части команды происходят проблемы, и присылали на их оценки дополнительных супервизоров, которые помогали прикалиброваться к системе снова.

Балансировка — это процесс анализа результатов оценок. Для анализа баланса оценок берется сумма сторипоинтов, которую команда или отдельный разработчик довел до продакшна за последние два-три спринта. Дальше считается баланс, это делается так:

1. по компетенциям (бэк, фронт, аналитика, датасайнс и т. д.).
Берем среднюю производительность на разработчика в компетенции и делим на среднюю производительность разработчика во всей разработке. Вычитаем единицу.
2. по продуктовым командам
Берем среднюю производительность на разработчика в продуктовой команде и делим на среднюю производительность разработчика во всей разработке. Вычитаем единицу.

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

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

Если на графиках баланса мы видим, что какая-то команда сильно ускорилась, это может означать разные вещи:

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

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

Что считать сильным отклонением от нормы? Мы считали отклонение в любую сторону менее чем на 20% — нормальным, более чем на 20% — аномальным и требующим внимания.

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

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

Если коэффициент разбалансировки поднимается выше 20% — требуется большое внимание к процессу оценки, сроки выполнения малопрогнозируемы, состав команды неоптимален, выводы о производительности команд и отдельных разработчиков недостоверны.

Мы считали эти показатели в полностью автоматическом режиме на базе API Jira и визуализации в Redash, поэтому быстро и без головной боли получали данные о том, насколько здоров наш процесс оценки задач.

#projectmanagement #управлениепроектами #оптимизация #storypoints #оценказадач #scrum #productmanagement