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



    Привет, Хабр! Меня зовут Артём и я тимлид в 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 больше, чем в другие, что там? Копать можно вплоть до заказчиков и исполнителей, а также изучать комментарии к таске.

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

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

    В целом, основная масса задач распределилась в промежутке 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 без плагинов такие лимиты не поставишь, так что устная договоренность точно нужна. Инструменты инструментами, но без взаимодействия с людьми никуда.

    Спасибо за внимание и успешного вам планирования!
    Skyeng
    Крупнейшая онлайн-школа Европы. Удаленная работа

    Комментарии 35

      +1

      Хм, интересный подход… Но изменилось ли что-нибудь при таком подходе в конечном счёте?

        0
        Сервис стал более предсказуемым, ну и до этого момента, Ваня вообще не знал сколько времени и на что уйдет :)
          +1
          Сервис стал более предсказуемым

          Он правда таковым стал?


          Каков процент тасок того или иного типа реально попадает в новые договорённости (интересны именно таски, которые были выполнены уже после новых договорённостей), и на каком объёме задач этот анализ построен?


          И устраивает ли "заказчика" такой процесс?

            0
            Если посмотреть данные за последние 3 месяца (~90 тасок) будет около 75% попадания в SLA. Важно анализировать почему мы не попадаем в SLA. Это может быть проблема в сервисе, которую мы не учли и тогда мы можем придумать какое-то решение, внедрить его, посмотреть на метрики. А может быть осознанный выбор согласованный с заказчиком.

            Еще момент. SLA стоит пересматривать с какой-то периодичностью. На него могут влиять различные факторы: от расширения команды до «лето это особенное время».
        0

        И кстати, а почему "время производства задачи" идёт именно от "готово к разработке", а не от старта технического ревью? Это же ведь обязанность тех. команды? Или в новом процессе нет никакого технического ревью? А как тогда определяется тип задачи (блокер/важная/регулярная)?

          +1
          А как тогда определяется тип задачи

          Это определяется не на тех. ревью. Есть квоты: может быть всего 2 важные задачи. А мы добираем 4. Соответственно, две из четырех идут как регулярная работа. А какая задача важнее определяет заказчик (Ваня). Мы лишь ограничиваем его.

          а не от старта технического ревью?

          Можно и от старта технического ревью считать. Нужно просто договориться где точка коммита. И согласны ли вы на такой риск — давать коммит по задаче, до того как обсудили тех. решение. Мы решили, что для нас «готово к разработке» это отличный вариант.
          +1
          Не торта, а торта!
            +2
            Как так получилось, что сложность задачи перестала коррелировать с временем её производства?
              +1
              Реальный размер задачи — это время в системе. Вас могут попросить перекрасить кнопку в другой цвет. Это легко, но на проде окажется через неделю просто потому что «не до этого». Сложность/Размерность задачи выравнивается за счет времени в статусах ожидания (в Канбан это называется эффективность потока).

              Ну и у нас, все-таки, вероятностное распределение. Мы действительно что-то выпускаем раньше потому что делаем/тестируем быстрее, но это только какой-то % от всех задач конкретного класса обслуживания. И это тоже можно проанализировать, вы можете добавить к своим классам обслуживания еще тип работ. Например, можно дать отдельный SLA по багам в классе обслуживания «Важный».
                +1
                это потому что производством в данном случае считается только разработка. «А ведь есть еще тестирование и код-ревью». но они в данной системе оценки воспринимаются не как часть производства, а как издержки на транспортировку или хранение.
                +2
                довольно очевидный вывод, что оценка времени реализации задачи не говорит о том когда за нее возьмутся
                оценка задачи определяет сколько ресурсов на нее требуется
                и нужно для планирования спринтов
                а время появления в проде определяет то, в какой спринт попадет эта задача
                  0
                  Т.е. у вас никогда не переносились задачи из одного спринта в другой? Просто «появления в проде определяет то, в какой спринт попадет эта задача» звучит как решение всех проблем.
                    0
                    Перенос в другой спринт означает неправильную оценку трудоемкости
                    В статье же предлагается объединить оценку трудоемкости и планирование спринтов(не связанные в общем вещи) в одной оценке.
                    Довольное странное решение, если учесть что то когда брать задачу зависит от бизнес приоритетов, и слабо завязано на трудоемкость выполнения.
                    Скорее всего это местная специфика, когда все поступающие задачи обязательно делаются в порядке поступления. Бывает и другая организация, когда по итогам оценки трудоемкости приоритет задач может меняться, вплоть до отказа от задачи.
                      +1
                      Я с вами согласен, но я не предлагал объединять планирование спринтов и оценку трудоемкости. У нас нет спринтов. Приоритет так же влияет на то, в какую очередь задача пойдет в работу. У нас заканчиваются задачи -> мы набираем еще -> я могу дать SLA по каждой и озвучить его заказчику.
                  +1
                  Я правильно понял, что парни познали разницу между efforts и duration, но своим путем через торты и майки?
                    0
                    Вот я тоже решительно не понял, как оценка трудозатрат плавно превращается в календарные сроки
                      +1
                      Многие, почему-то, заострили внимание на этом. Мы пытались ответить заказчику на вопрос «Когда?» и один из вариантов был заложить в Estimate всё, что только можно. Разумеется, это не работает. Я бы мог просто описать метод, которым мы в итоге пользуемся, но решил, что лучше расскажу всё как было. Вдруг это кому-то поможет не наступать на наши грабли.
                        0
                        или между estimate и due date
                        +1
                        Ваня считает, что наша схема с оценкой задач не идеальна. Например, оценка в 2 дня ничего ему не даёт. Свою задачу на проде он увидит через неделю или дней 10. Или больше. Или меньше.

                        Вероятно, потому, что оценка отвечает на вопрос "сколько" и не отвечает на вопрос "когда".
                        Помогает понять, сколько задач можно запихнуть в спринт. А в чем их измерять — в story points, человеко-часах, футболках или тортиках — не суть важно.

                          +1
                          Мы работаем без спринтов. «Готово к разработке» пополняем по необходимости, когда там остается 1 -2 задачи.
                          0
                          Когда спрашивают «Какой эстимейт на задачу?», на самом деле интересно, не сколько времени ты на неё потратишь, а когда уже можно будет воспользоваться её результатами. В планировании, к сожалению, это не удобно, но при оперативном контроле гораздо эффективней спрашивать «Когда ты планируешь закончить эту задачу?»(В какой день и в какое время), вместо «Сколько часов тебе надо на её выполнение?». Вопросы принципиально разные и вносят для каждой из стророн гораздо больше опредлённости, что в вопросе, что в ответе.

                          Я же вам сказал — «приходите завтра». А вы всё время сегодня приходите...

                            0
                            спасибо за статью
                            А с вероятностью 90% это займет 14 дней.


                            По-моему, формулировка не верна. Такой вывод можно было бы сделать, если бы 90% задач были в сегменте «14» на оси LT
                            Кажется, вы имели в виду: с вероятностью 90% задача доедет до прода в течение 14 дней. Т.е., 90% задач уезжали на прод раньше чем за 14 дней.
                              0
                              Я бы, наверное, сформулировал так: с вероятностью 90% это не должно занять больше 14 дней. Интересное замечание, если честно. Озвучивая срок в 14 дней, мы оставляем пространство для маневра и не создаем ложных ожиданий. Т.е., мне кажется, если изменить формулировку, то может и измениться поведение человека. Но, возможно, я перегибаю :)
                              0
                              А зачем Ване знать когда выкатится таска? Т.е. вы набрали таски на спринт и они должны быть выполнены к концу спринта. Чтобы оценить объем спринта и ставится эстимейт каждой.

                              Если спринт недельный, то и таски должны быть выкачены через неделю. А то, что у вас таска кочует из спринта в спринт — неправильная декомпозиция и оценка.
                                +1
                                У нас нет спринтов. Мы пополняем «Готово к разработке» когда там остается 1 — 2 задачи.
                                  +3
                                  Артём, обрати внимание, насколько людям непривычно смотреть на эту идею из мира скрама и спринтов. Вероятно, в будущем стоит больше акцентировать внимание на том, что вся эта штука не то что не монтируется со спринтами, а чуть ли не прямо противоречит им.

                                  Тут очень сильно зависит от того, какой запрос (и майндсет) у продакта. Если он приходит с вопросами «через сколько времени такая-то задача будет на проде», то твоя идея (и канбан) работает хорошо. Если он приходит с вопросами «какие фичи будут через неделю на проде», то хорошо работает скрам. Если продакт мыслит потоком отдельных плюс-минус изолированных задач — канбан. Если еженедельными инкрементами — скрам.
                                    0
                                    Если он приходит с вопросами «какие фичи будут через неделю на проде», то хорошо работает скрам.

                                    Если заказчик не пытается в спринт вбросить что-то, что важнее того, что уже в спринте и если за спринт закрываются все взятые в него задачи — ваш скрам, действительно, работает хорошо)
                                0
                                В итоге получается Ваня сам мог провести такую классификацию задач и без всяких SLA примерно представлять, в какой срок какой тип задач выкатывается на прод?
                                  0
                                  Анализ провести мог кто угодно, главное знать что и как анализировать.
                                    0
                                    А собственно классическую оценку задач вы не проводите и Ване она не интересна? На мой взгляд у Вас вышла скорее система классификации задач по срочности деплоя, чем собственно оценки трудоёмкости задач. А ведь обычно под оценкой задач всё-таки понимают долю ресурса разрабоки, которую она займёт из какого-то отрезка времени. И используется она не для того чтобы решить, что выкатить первее, а что лучше сделать за условный ближайший месяц, вот эту большую фичу в 13 сторипоинтов или вот эти 4 фичи в 3 + 5 + 2 + 3 = 13 сторипоинтов.
                                      +1
                                      Тут не решается проблема «что выкатить первее». Вы запланировали на месяц 4 фичи в 3 + 5 + 2 + 3 = 13 сторипоинтов. И тут в середине месяце заказчик приносит что-то новое и хочет это дать вне плана. Я могу ответить ему через сколько это «вне плана» появится на проде и как это скажется на остальных фичах в плане срока.

                                      Если вы можете запланировать себе на месяц работы и гарантировать, что ничего нового не прилетит за этот месяц — это круто! А если вы еще и выполните всё, что на месяц напланировали — значит у вас нет проблем! У нас так не получается, поэтому мы используем такой подход.
                                  0
                                  Мы договорились на ограничение по количеству задач в классе обслуживания: нельзя взять больше двух блокеров, нельзя взять больше двух важных задач.

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

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

                                    Например это разные заказчики, и каждый их них аргументирует почему эти задачи важны именно сейчас.

                                    В Канбан есть роль SRM (Service Request Manager) — менеджер сервиса запросов. Он отвечает за управление потоком запросов (в том числе от разных заказчиков) на выполнение для сервиса поставки (в нашем случае разработка). Один из вариантов как менеджерить запросы от разных заказчиков — предоставить квоты. Т.е. ввести лимит на заказчика. Например, только 2 элемента одного и того же заказчика может находиться в системе одновременно.
                                      0
                                      В Канбан есть роль SRM (Service Request Manager) — менеджер сервиса запросов. Он отвечает за управление потоком запросов (в том числе от разных заказчиков) на выполнение для сервиса поставки (в нашем случае разработка). Один из вариантов как менеджерить запросы от разных заказчиков — предоставить квоты. Т.е. ввести лимит на заказчика. Например, только 2 элемента одного и того же заказчика может находиться в системе одновременно.


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

                                        Когда в «Готово к разработке» остается 1 — 2 элемента, то инициируется встреча по пополнению. У каждого заказчика есть квота и он может отдать только определенное кол-во своих задач.

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

                                        В подходе описанном выше возможен еще и дополнительный эффект. Например, заказчики могут начать договариваться между собой и предоставлять друг другу эти самые квоты: «Петя мне очень надо, дай мне свой слот, а я тебе в следующий раз дам вообще 2 своих!». У нас примерно так и происходит (только у нас нет квот). Задачу в разработку может поставить только менеджер продукта (по сути, он SRM). И он договаривается с заказчиками.

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

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое