Майки, деньги, два торта: как мы разучились оценивать задачи

Привет! Меня зовут Артём и я тимлид в Skyeng. У моей команды разработки есть заказчик, он же продуктовый менеджер, он же просто Ваня. Ваня считает, что наша схема с оценкой задач не идеальна. Например, оценка в 2 дня ничего ему не даёт. Свою задачу на проде он увидит через неделю или дней 10. Или больше. Или меньше.

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

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

Как научиться отвечать на вопрос «Когда?», если о предсказуемости речи не идёт?

Как мы усомнились в Estimate

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

Так как мы всегда на удаленке, всё происходит в JIRA: есть доска, на которой визуализированы этапы работ. Карточка покидает статус «Техревью» и перебирается в «Готово к разработке» после того, как мы все описали и оценили. Именно в этот момент мы берем на себя обязательства выполнить работу.

У «Готово к разработке» стоит WIP-лимит — больше 8 задач одновременно быть не может. Есть и обратное правило: как только задач в колонке становится мало, мы инициируем новое техническое ревью.

Факт: мы тратим заметное время на оценку. Техревью обычно проходит два раза в неделю, на 4 задачи с детальной проработкой и оценкой может уйти 1,5-3 часа. Но! Затем мы еще можем потратить время, чтобы разобраться, почему Estimate таки был превышен.

При этом ни оценка, ни разбор полетов не добавляют ценности нашему продукту. Скорее, на них мы теряем время. И деньги. Я долго сомневался в необходимости этих процедур, а в один момент дозрел до серьезного разговора с продактом. И мы оба признали проблему.

«Футболка сухая и совсем...» не XS

Решили: давайте экспериментировать с подходами к оценке. Я предложил остановиться на T-Shirt Size — в качестве единицы измерения в этой технике используются размеры футболок. Нужно найти самую маленькую задачу, которую приходилось делать, и принять ее за XS. После этого остальные задачи оцениваются по принципу «насколько они больше XS» — и в зависимости от этого им присваивается размер S, M, L или XL.

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

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

Работаем так несколько месяцев, собираем статистику. И только Иван на нас косо смотрит.

Выяснилось, что XS, как и S, мы делаем то за 1 день, то за 10. А на L тратим то 5, а то 15 дней. Потому что по факту какую-то работу мы берем в первую очередь, какую-то во вторую, а какую-то в пятую — и задачи одинаковой размерности проводят в статусах ожидания разное время. Упс, вот тебе и средние.

Короче говоря, тут разброс не в пару дней — и для Вани мало что поменялось. Мы признали эксперимент неудачным, но всё-таки идея о том, что задачи можно как-то категоризировать, засела в голове. И я стал думать в эту сторону дальше.

«Все любят тортики. Слоёные!» Осел из Шрека

И я люблю. К тому же, день рождения ребенка это отличный повод! Захожу на свой любимый сайтик и начинаю выбирать:

• можно такой, а можно и не такой,
• можно украсить, а можно не украшать,
• можно на 2кг, а можно и на 5кг.

Не буду раскрывать свои вкусовые предпочтения, а тортик я выбрал. И привезли его к назначенной дате. Далее пойдет философия объевшегося торта тимлида.

Я, разумеется, не Ньютон, а тортик не яблоко, но озарение пришло.

Я мог выбрать из множества вариантов, но что бы я ни выбрал, дата доставки не менялась. Мне нужен был торт через неделю. И мне были готовы оказать эту услугу. А размер торта, вес и всякие прибамбасы не сильно влияли на конечный результат — точнее, в данном случае, вообще не влияли. Дело не в размере, как говорится. А в чем? В цене.

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

Идея с SLA триггернула, потому что я читал про это в Канбан-гайде

С точки зрения Канбан-метода всё есть сервис. И несмотря на то, что мы поставляем не тортики, а наш продукт нельзя пощупать или съесть – разработка тоже сервис. И мы также по-разному относимся к задачам.

Вспомним нашу доску:

Сервис состоит из нескольких этапов (разработка, код-ревью, тестирование), а колонка «Готово к разработке» — это наша точка коммита перед заказчиком.

Какие-то вещи мы делаем в своем обычном ритме, но когда прилетают горящие задачи, мы бросаем всё. Остается понять, какие у нас SLA, — и можно будет заключить соглашение с Ваней.

Как оценить SLA своей команды: строим спектральную диаграмму (это просто)

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

• По оси Х фиксируем Lead Time (LT) — время производства задачи. В нашем случае это время от «Готово к разработке» до «Готово».
• По оси Y откладывается частота — сколько задач мы сделали за LT1, LT2, LT3 и т.д.

Мы взяли закрытые за последние несколько месяцев задачи и получили следующее:

Мы закрыли 3 задачи за день, 6 — за два, больше всего — за 5, а где-то бились над таской больше двух недель…

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

Вот что получилось раскопать нам. Это наша регулярная работа.

Разброс довольно большой, но он поддается анализу.

В целом, основная масса задач распределилась в промежутке 7-14 дней, а парочка улетела совсем далеко — в этом хвосте было несколько задач (не все) с PR в другие сервисы. Те задачи, что завершились за 3-4 дня, скорее исключение, чем правило.

Итак, я уже могу сказать заказчику, что если задача проходит как регулярная работа, с вероятностью 75% она доедет до прода за 10 дней.

А с вероятностью 90% это займет 14 дней. Ну а если разработка затрагивает другие сервисы компании, ждать придется немного дольше, — нам нужен код-ревью от другой команды и потом еще деплой.

Поехали дальше. Мы назвали этот класс «Важный».

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

И тут мы также можем озвучить SLA: с 75% вероятностью задача попадет на прод за 5 дней, с 90% вероятностью за 7. Продолжим?

Те самые задачи, ради которых мы бросаем всё и пилим, пилим, пилим — блокеры.

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

Несмотря на то, что все подобные ситуации нам удалось разрешить за 2 дня, всё равно озвучим 90’ый процентиль. Во-первых, не стоит обещать 100% — никому и никогда :) Во-вторых, нужно закладывать вариабельность: вспомним случай с регулярной работой, когда несколько задач улетело за 20+ дней, потому что появилась зависимость от других команд.

Готово! Можем согласовать с Ваней SLA по всем классам обслуживания:

Мы выбрали именно 90% по срокам — это, по сути, толерантность заказчика к их несоблюдению. То есть, если 1 из 10 задач не уложится в SLA, нам готовы это простить.

Если ваш заказчик не такой добрый, лучше озвучивать 95’ый процентиль, например.

Вместо заключения

— А что мешает Ване набирать только важные задачи или блокеры?
— Горизонтальные WIP-лимиты.

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

Спасибо за внимание и успешного вам планирования!

Автор: Артем Расскосов

Источник