Привет! Меня зовут Елена, я недавно перешла работать в SM Lab руководителем продукта Портал поставщика. Портал – это рабочее место поставщиков товарной продукции в Спортмастер и Остин. Решение представляет собой трехслойную систему со множеством интеграций и витиеватым функционалом. Локализация интерфейсов, инструкций и обучающих курсов на трех языках, в миссии – простота и удобство пользования.
В SM Lab продуктовый подход, поэтому я зашла в готовую команду. Её особенность в том, что она достаточно большая – 17 человек. В этой статье я хочу рассказать о том, как мы внедрили относительные оценки работ и что получили в результате.
Оценка в лоб
Наш продукт востребованный, важный и ценный для бизнеса, поэтому передо мной прямо с порога возникла задача оценки сроков реализации очередной доработки.
Что делать? Собрала команду, мы вместе спроектировали решение, декомпозировали его на задачи, оценили каждую, просуммировали трудозатраты, округлили в большую сторону, еще раз посмотрели на итоговую цифру, подтвердили, я передала прогноз бизнесу и выдохнула. А потом подсчитала, сколько стоила подготовка прогноза, и ужаснулась.
Во-первых, 17 человек – это немало, и 1.5 часа командной встречи — это почти чел/неделя.
Во-вторых, команда работает по Kanban, и у нас нет выделенного времени на подобные мероприятия.
В-третьих, product lead до меня 3 года работал в продукте, поэтому мог дать верхнеуровневую оценку без привлечения команды, т.е. без лишних трудозатрат.
Взвесив все это, я поняла, что, если резко не научусь ускорять и удешевлять подготовку оценки, у меня просто разовьется комплекс вины перед заказчиком.
Так как продукт живой, времени до следующего запроса от бизнеса было немного, а тут еще и конец финансового года замаячил с дорожной картой на следующий год…
Как быть? Я вспомнила про относительные оценки. На самом деле, я никогда ранее сама с ними не работала, но, как и многие, читала, слышала, могла поддержать разговор.
Относительные vs Абсолютные
Что я знала об относительных оценках? Относительные оценки противопоставляют абсолютным оценкам.
Абсолютная оценка – это оценка в человеко-часах.
Абсолютная оценка – родная дочка «водопадного» подхода. Получили проект, разбили на задачки, подсчитали затраты в часах для каждого участника, согласовали с заказчиком, пошли копать. При этом абсолютная оценка не такая точная, как хотелось бы. Причин много: и специалисты – большие оптимисты при оценке своих работ, и работы по проекту не всегда предсказуемы, и по 8 часов непрерывно никто не сидит над задачами, и прочее.
Вместе с гибким подходом к разработке появляются относительные оценки.
Относительные оценки – это оценки через сравнение. Например, эта задача такая же простая, как та задача, или эта задача такая же непонятная и геморройная сложная, как вот та.
Единицы измерения относительных оценок самые разные:
• Сторипойнты (1SP, 2SP, 3SP, 5SP, 8SP)
• Размеры маек (S, M, L, XL)
• Животные (хомяк, котик, барбос)
и многие другие.
Как применять?
Если требуется оценить выполнение задач одним специалистом, проще применить алгоритм абсолютной оценки: спросить, сколько времени он потратит на решение каждой задачи, и подсчитать сумму.
Если необходимо оценить выполнение множества задач кросс-функциональной командой, лучше использовать относительные оценки. Например, если над каждой задачей работает аналитик, разработчики front, rest, бд, тестировщик, собирать оценки с каждого - тот еще квест.
Было бы здорово придумать свои оригинальные единицы измерения, но времени для творчества не было, а размеры маек в общем-то тоже
относились к нашей тематике.
Как мы внедрили относительные оценки?
Буквально по щелчку пальцев?
1. На ретроспективе посмотрели закрытые задачи за прошедший месяц.
2. Выделили командой самые простые и быстрые – проставили им размер S.
3. Выделили следующие по сложности задачи – проставили им размер M.
4. Аналогично выделили размеры для задач и L и XL.
5. Занесли описание размеров с примерами в базу знаний Confluence.
На ближайшей встрече по декомпозиции сразу указали в Jira размеры в майках для задач. По мере работ провели небольшое повторное обсуждение и внесли уточняющие примеры в базу знаний.
Больше мы описание размеров в Confluence не правили – двух встреч по 15 минут нам было достаточно, чтобы зафиксировать правила оценки задач в майках для нашего продукта.
Внедрить относительные оценки - легко, потому что, на самом деле, в жизни мы их все уже внедрили. Когда мы обсуждаем новые задачи между собой, мы говорим: «Это легкотня» или «Это ппц», или «Тут надо подумать». Это и есть относительные оценки: мы интуитивно даем оценку через сравнение с задачей из своего прошлого опыта.
Как в теории перейти от оценок задач к прогнозам реализации user-stories?
Чтобы от прошлого перейти к будущему, нужно выполнить следующие шаги:
1. Перевести майки в сторипойнты: XS (1SP), S(3SP), M(5SP), L(8SP), XL(13SP).
Стандартно для ориентировочного шага между относительными оценками применяют коэффициенты из ряда Фибоначчи (1, 2, 3, 5, 8..). Почему не 1, 2, 4, 8, 16? Чтобы не усложнять. Если решить, что задача M в 2 раза больше, чем задача S, невольно при оценке будешь задумываться – а точно ли в 2 раза? Шаг у ряда Фибоначчи позволяет больше абстрагироваться от оценки в часах.
2. Подсчитать среднюю скорость команды:
где SP1...SPN – количество в сторипойнтах, а n – количество спринтов или релизных циклов.
Чем большее количество спринтов участвует в подсчете, тем более усредненной и точной будет рассчитанная скорость. Из формулы важно исключить дефекты и другие непредвиденные вбросы, таким образом мы заложим ресурс на работу с задачами такого рода в будущем.
3. Скорректировать скорость с учетом мощности команды:
где P-количество участников команды, D-количество дней, T-рабочее время.
Если впереди сезон отпусков, мощность команды уменьшится, а значит, уменьшится и скорость.
Как мы в команде перешли к прогнозам на практике?
1. Закрыли 3 релизных цикла по 1,5 недели.
2. Я посмотрела статистику закрытия задач без учета проблем с приоритетом critical, сформулировала прогнозы реализации 7-ми user stories (у нас – эпиков) ближайшей бизнес-инициативы (3 месяца).
3. В конце ежедневной летучки за 10 минут согласовала прогнозы с командой.
4. Представила бизнесу наш прогноз и показала, как он был рассчитан.
На подготовку прогноза я потратила примерно 2 часа. Представляю, сколько времени мы с командой из 17 человек потратили бы на абсолютную оценку реализации 100+ задач.
Относительные оценки хороши тем, что снимают вопросы типа: «А кто так оценил? Я тогда болел?» или «А почему заложили так мало времени? Надо было побольше». Точнее, не снимают вопросы, а дают ответ – всегда можно объяснить и показать на закрытых задачах, как на пальцах, почему сформирован именно такой прогноз.
При этом, прогнозы в относительных оценках легко объяснимы бизнесу, и это еще один плюс в копилку.
Безусловно, за следующие 3 месяца работы над бизнес-инициативой мы то немного опаздывали по срокам, то слегка опережали их. Тем не менее, прогнозы, полученные таким нехитрым и дешевым (ура!) способом, позволили нам с командой реализовать большую бизнес-инициативу из семи эпиков вовремя.
Помимо прочего, тот факт, что команда сама утвердила подход к расчету сроков, и, фактически, сами дедлайны для ближайшей доработки, очень мотивировало каждого участника вложиться в достижение нашей общей командной цели.
И немало важным бонусом стало то, что, привнеся этот новый подход к оценке задач, я смогла повысить доверие команды ко мне и моим начинаниям.
В следующий раз расскажу об одном любопытном кейсе, с которым мы столкнулись при внедрении относительных оценок.
Надеюсь, мой опыт покажется кому-нибудь из вас интересным и полезным.
Спасибо, что дочитали до конца!