Привет! Меня зовут Артём Коньков, я тимлид команды продуктовой разработки в Купере. У меня в команде шесть разработчиков, по два на каждый стек: мобилка, фронтенд, бекенд и два QA. В статье расскажу о том, как, став тимлидом в уже почти сложившейся команде, менял систему оценки задач и переводил абстрактные сторипоинты в конкретные.

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

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

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

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

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

Предыстория

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

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

Казалось бы, не так важно, что у тебя кривой burndown график, если работа сделана. Но из-за разницы в оценках между стеками получалось, что на задачи коллег очень сильно подвергались «инфляции», и их выполненная работа вообще ничего не меняла на графике, а метрики нам важны, потому что только так мы можем оценивать реальный объём работы сотрудника, ставить точные сроки, а потом их соблюдать. 

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

Что такое конкретная и абстрактная оценка в сторипоинтах

Конкретная оценка подразумевает использование сторипоинтов, чтобы определить точные временные затраты на выполнение задачи с учётом опыта и навыков команды. Например, если команда знает, что задача требует 3 дня работы, она может оценить её в 3 сторипоинтов, приравняв 1 сторипоинт к 1 дню.

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

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

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

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

2. Различия в производительности: Разные члены команды могут иметь разную производительность, что делает оценки в сторипоинтах менее точными. Опытный разработчик может выполнить задачу, оцененную в 5 сторипоинтов, за 3 дня, в то время как новичок может потратить на неё 5 дней.

3. Сложность масштабирования: Когда команда растет или меняется состав, сложно сохранять единообразие в оценках в сторипоинтах. Это может привести к несогласованности и неточности в планировании.

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

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

Сначала мнения разделились

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

Как я победил абстрактные оценки и какие результаты это дало

Мы выбрали систему, где 1 сторипоинт = 1 день.

Точнее «примерно 1 день», потому что:

• мы никого не ругаем, когда не попадаем в диапазон оценки;

• учитываем, что не можем на 100% оценить влияние других команд на сроки.

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

При оценке задач мы учитываем не только дни, но и коэффициент производительности (он же фокус-фактор) каждого сотрудника. Например, у меня в отделе есть middle-разработчик, который за 10 рабочих дней в спринте делает 13 сторипоинтов. То есть за десять дней он выполняет работу, рассчитанную на две недели.

А есть middle, который за 10 дней выполняет 9 сторипоинтов.

Коэффициент производительности одного миддла будет 1,3, а для второго — 0,9. Умножая 10 рабочих дней на их коэффициенты производительности, мы понимаем, что нам нужно запланироваться для сеньора на 13 сторипоинтов в спринт, а для миддл-разработчика — на 9.

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

Burndown-график до перехода на конкретные сторипоинты и после:

Очень интересно послушать, были ли у вас похожие сложности в принятии системы сторипоинтов и как вы их разрешили. Тема горячая, готов к диалогу :)

Tech-команда Купера (ex СберМаркет) ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.