06.08.2018 04:26
KarinaTsar 17 3200 Источник

И почему всё же стоит использовать её


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


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




Столбцы: Фича/Проект, Трудозатраты, Ценность.
Содержимое в ячейках первого столбца:
Вкладка сообществ
Обновить потока отправки
Добавить биллинг PayPal
Исправить ошибку в квитанции
Контакт с менеджером
Обновить условия обслуживания


Трудозатраты могут указываться в человеко-неделях или просто определяться по уровню сложности задачи (простая/лёгкая/сложная). Как только у вас появляются числа, становится важным выбор тех фичей, которые обеспечат наибольшую финансовую отдачу. Но тут всё становится несколько сложнее. Для того чтобы понять, почему, давайте расположим наши задачи в прямоугольной системе координат:



По оси X располагаются трудозатраты, по Y — ценность


Достаточно очевидно, что верхние левые проекты лучше всех остальных, а правые нижние — самые плохие. Но как сравнивать всё остальное? К счастью, решение существует. Вам уже может быть знакома матрица трудозатрат и ценности. Если погуглить, можно найти тысячи разнообразных вариаций матрицы — она уже давно является best practice в индустрии.



По оси X: малые трудозатраты — инкрементальные улучшения, большие трудозатраты — “денежная яма” (прим. пер.: в других источниках “пожиратели времени”).
По оси Y: малые трудозатраты — лёгкие победы, большие трудозатраты — большие победы.


Идея очень проста — разделение на квадранты помогает увидеть, как располагаются проекты.


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


С другой стороны, квадрант “Много / много” охватывает большие проекты, которые обещают большой доход. Многие амбициозные команды любят делать ставки именно на такие проекты.

Наиболее желанны проекты, комбинирующие малые трудозатраты и большую отдачу в левом верхнем углу — никто не откажется от лёгкого выигрыша (и кто знает, может быть, один из таких проектов станет очередной кнопкой, позволившей заработать $300 млн…).


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


Наложение наших планов на данную матрицу позволяет быстро получить понятную картину:



… и теперь приоритизация довольно проста:


  1. Сначала избавляемся от всего, что находится в квадранте денежной ямы (это хорошее избавление).
  2. Затем задаём лёгкому выигрышу высокий приоритет.
  3. И в конце мы формируем микс из инкрементальных улучшений и больших ставок, основанный на доступных ресурсах и наших аппетитах.


Довольно просто?


Не так быстро…


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


Склонность недооценивать трудозатраты


В 1979 году бихевиористские психологи Дэниэл Канеман и Амос Тверски описали феномен, который они назвали ошибкой планирования. Они показали, что люди и команды регулярно излишне оптимистичны в оценке времени, которое потребуется для завершения задачи, чем в итоге занижают оценку. Этот феномен также был подтверждён в множестве других исследований.


Если вы работаете в сфере IT, то эта новость не является для вас шокирующим открытием. Задачи и проекты постоянно задерживаются и отличие от изначального плана может доходить до 2-3 раз (а иногда гораздо больше). Опытные тимлиды и проектные менеджеры являются предпочитают планировать время с запасом, они добавляют буфферы или просто умножают оценку на 2, но даже с учётом этого проекты всё равно не завершаются вовремя и тем более не завершаются раньше времени (пример).


Причинами этого являются некоторые особенности, большинство из которых — различные когнитивные искажения:


  • Оптимизм и мысли о желаемом.
  • Неточные воспоминания о том, сколько времени требовалось для похожей задачи в прошлом.
  • Чрезмерная фокусировка на завершении задачи.
  • Недооценка влияния случая.
  • Масштаб задач — чем больше проект, тем ниже точность оценки длительности.

Склонность переоценивать отдачу


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


В технической сфере мы особенно наивно не знаем об этом. Раз за разом я вижу менеджеров и команды, которые верят своим оценкам будущих выгод, основанным на “чутье печёнкой”, независимо от того, насколько хорошими оказались предыдущие предсказания. Два основных фактора, способствующие этому, заключаются в следующем:


  • Нет чётких метрик — часто ответ на вопрос о том, является ли проект успешным, формируется из интерпретации результатов, потому что критерии успешности не были определены заранее.
  • Мы склонны помнить наши удачные предсказания и забывать неудачные (или приписывать их другим).

Как только начинаешь систематически измерять удачи и неудачи, появляется ясная картина того, как плохо мы умеем предсказывать выхлоп. Анализ A/B-экспериментов, проведённый независимо Microsoft, Netflix и Booking продемонстрировал, что в лучшем случае только 1 из 3 протестированных идей показывает положительный измеримый результат. Остальные исследовавшиеся идеи либо не дали результата вообще, либо он был отрицательным. Но эти цифры не отражают ситуацию всей индустрии. Одна выигравшая идея из трёх — это очень хороший результат, возможный только у зрелых продуктов и компаний, которые провели большое количество времени, исследуя своих пользователей и покупателей. Стартап будет ближе к соотношению 1:10 (или ещё хуже), а немного более зрелые компании могут рассчитывать на более хорошие показатели.


“Унизительно наблюдать, насколько плохо эксперты (включая нас) оценивают ценность фичей. Каждая фича, созданная командой разработки, создана потому, что кто-то верит, что у неё будет ценность, однако многие преимущества рушатся при столкновении с реальностью.”


Из исследования Microsoft, 2009


Джон Т. Гурвиль из Бизнес-школы Гарварда в своей исследовательской статье 2006 года описал сильное несоответствие между тем, какую ценность компании ожидают предоставить потребителям в результате внедрения инноваций и тем, как эту ценность видят сами потребители. Согласно исследованию Гурвиля, компании склонны переоценивать выгоды от продукта, тогда как пользователи видят гораздо больше ценности в уже используемом решении и переоценивают затраты на переключение на новое решение. По Гурвилю, компании завышают значение в 9 раз.


Вернёмся к матрице “Трудозатраты / ценность”


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


Оглянувшись назад на матрицу, нам становится понятно, что на самом деле ситуация обстоит следующим образом:

Да, с наибольшей вероятностью, вы попадёте в зону денежной ямы.


Но всё ещё хуже. Как показывает результат анализа A/B-тестов, некоторые проекты имеют отрицательный результат — это то, что не учитывает почти ни одна команда разработки. Таким образом, появляется элемент риска, который никак не раскрыт в этой матрице.


Настоящая матрица “Трудозатраты / ценность” выглядит как-то так:



По оси Y ниже нуля — негатив, генератор потерь.


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



Я думаю, это хороший момент, чтобы распрощаться с матрицей “Трудозатраты / ценность”. Эта модель слишком упрощена и предполагает, что с некоторой долей уверенности можно заранее сказать, сколько будет стоить разработка и насколько позитивное влияние окажет новая фича. Если бы существовала матрица реальной ситуации (а я думаю, её не существует), то, вероятно, она бы выглядела так:



Зелёный — проекты, которые вы хотите рассмотреть.
Оранжевый — проекты, которые вы не хотите делать.
Красный — проекты, которые вы на самом деле не хотите делать.


5 шагов для того, чтобы сделать матрицу “Трудозатраты / ценность” жизнеспособной


Во-первых, вам нужно осознать, что 60-90% проектов в вашем бэклоге бесполезны — они просто не дадут хотя бы сколько-нибудь значимый результат или будут стоить гораздо больше, чем вы готовы за них заплатить. Приоритизация и эксперименты нужны для того, чтобы находить те бриллианты, которые пользу всё-таки принесут (они тоже будут реализованы с задержкой сроков, но это нормально).


Во-вторых, я до сих пор являюсь сторонником матрицы “Трудозатраты / ценность” и считаю её очень удобной. Де-факто, я очень часто рекомендую её компаниям, с которыми работаю. Однако также я поощряю усилия немного улучшить этот подход к приоритизации.


Посчитайте отдачу на салфетке


Обычно можно значительно увеличить точность вычислений, если разбить задачу на части и оценивать эти части по отдельности. Мой любимый пример — это маркетинговые кампании, которые строятся на рассылке пушей или промо внутри продукта. Они почти всегда обещают улучшение конверсии или увеличение выручки на “10%”, но если вы посчитаете как воронки будут работать в реальности — как много людей увидит промо, какой процент кликнет, сколько из этих кликнувших сконвертируется — вполне вероятно, что полученное число будет не “10%”, а сократится до долей процентов. Да, ошибка в два порядка может быть замечена менее, чем за две минуты.


Используйте доступные данные или новые данные


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


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


Думайте о дешёвых способах проверить ваши гипотезы


Для больших проектов часто полезно провести предварительные исследования:


  • Опросы
  • Смок-тесты — например, рекламная кампания на Facebook «фальшивая дверь»
  • Пользовательские интервью
  • MVP

Все эти исследования не обязательно проводить для каждой фичи, т.к. их сложно масштабировать.


Доверительный интервал


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


Очень низкий уровень доверия может быть 0.1, очень высокий 0.8 (больше информации о подсчёте уровня доверия здесь).


Формула расчёта приоритетности теперь такая:


$Приоритет = \frac{Выхлоп }{Усилия } Уровень Доверия$


A/B-тесты


A/B-тесты уничтожают почти все догадки и избавляют от большинства рисков. Если вы тестируете фичу перед запуском, вам не нужно опираться на предчувствия и интуицию — вы увидите достаточно — успешна идея или нет. A/B-тестирование позволяет делать ставки с относительно низким риском. По этой п/ичине такие компании, как Netflix, тестируют всё — и маленькие, и большие изменения.

Комментарии (17)


  1. Vlad5
    06.08.2018 10:52
    #18961289
    +1

    Если абстрагироваться от конкретной проблемы с недооценкой/переоценкой и рассмотреть проблему глобальней, то получим следующее: хвост виляет собакой. Надеюсь, что ни для кого не открою секрета, что IT отрасль является прикладной. То есть должна прикладываться к чему-либо ещё, и помогать решать проблемы той области. И раз у нас всё перевернули с ног на голову, то получаются такие сферические кони в вакууме. Вроде выпускают прекрасную программу/фичу/плагин, а она никому не нужна…


    1. KarinaTsar Автор
      06.08.2018 12:31
      #18961765

      Согласна с вами, очень часто ситуация обстоит именно так, однако на данный момент довольно популярны подходы по исследованию потребностей — как качественные (CustDev, Design Thinking), так и количественные (Lean Startup) методы, которые в комбинации показывают хорошие результаты


  1. xedas
    06.08.2018 13:50
    #18962171

    Мне одному кажется, что в координатах «усилия — эффект» должны быть не прямоугольники, а что-то вроде этого?

    И последняя формула

    на это намекает.


    1. KarinaTsar Автор
      06.08.2018 14:05
      #18962279

      Оригинальная матрица предполагает использование именно квадрантов (более подробно, например, тут: habr.com/company/hygger/blog/359208)
      Последняя формула выведена автором именно с учётом критики оригинальной матрицы.

      Предложенная картинка выглядит интересно :)
      Раскройте, пожалуйста, как на вашем графике учитывается уровень доверия? Плюс у вас не учтён вариант с «отрицательной ценностью», когда в результате релиза фичи компания деньги не зарабатывает, а теряет.
      Плюс не очень понятно по самому графику — по Y ценность, по X трудозатраты? Выглядит так, как будто у вас это именно вектора, но я не уверена, что понимаю правильно


  1. xedas
    06.08.2018 15:22
    #18962695

    Y ценность, по X трудозатраты
    Да, это оси.
    Отрицательная ценность — ну продолжим график вниз. Вот дорисовал:

    Уровень доверия — можно вот так:
    результат = (ожидаемый результат) * (уровень доверия).


  1. S_A
    06.08.2018 15:56
    #18962827

    В экономике есть гораздо интереснее методы, например риск-эффективность-стоимость. Там формируется наилучший портфель с точки зрения эффективности и риска. Эффективность = эффект / затраты.


    1. KarinaTsar Автор
      08.08.2018 09:57
      #18970321

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


      1. S_A
        08.08.2018 13:31
        #18971689

        Ну нет. Когнитивные искажения — это личное (субъективное) изобретение автора. Все что не очень известно — в экономике моделируется как риск (и если более глубоко, чувствительности к риску, но сперва — риск). Короче, тот метод о котором я — покрывает все когнитивные субъективные искажения оригинального автора.

        Смотрите здесь.

        В целом РЭСТ-диаграммы вместе с описанным методом построения
        гистограмм эффекта дают достаточный набор средств для принятия
        решений о выборе пакета мероприятий, обеспечивающих достижение
        поставленной цели.


        1. KarinaTsar Автор
          08.08.2018 14:01
          #18971873

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

          У Канемана есть книга «Thinking, fast and slow», которая как раз излагает суть исследований и на примерах раскрывает ущербность теории о том, что люди рациональны


          1. S_A
            08.08.2018 14:14
            #18971947

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

            Только вот не надо натягивать сову на глобус, теории Канемана в статье ноль повдоль и поперек. И еще, я нигде не утверждал что люди рациональны. Рациональны их теории, особенно те, которые обоснованы выводами — и способны дать применимый результат (в отличие от психологии Канемана).

            Вобщем, за деревьями лес где-то есть, я вас обрадую (начинается он с того, что люди Канемана и риски проектов немного разные вещи). «Риски как матмодель» — привет из августа 2008 — основа экономики. Те кто ими пренебрегает, перестает быть экономическим субъектом (и становится предметом изучения Канемана).


          1. S_A
            08.08.2018 14:22
            #18972003

            Справедливости же ради отмечу. Сам пользуюсь примитивным ранжированием по эффективности с отсечением по затратам.

            Это математически оптимальный способ формирования портфеля (если риск не учитывается, или учтен в эффективности — для этого тоже есть способы).

            Если по шагам надо — есть однорукие бандиты. Вобщем много всего хорошего есть.


  1. c0f04
    08.08.2018 09:57
    #18970323

    Из статьи непонятно, как дела обстоят с зависимостями в такой матрице?

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


    «Быстрые деньги», как и «инкрементальные» решения могут повлечь за собой как плохое качество кода и архитектуры, так и создать для компании постоянные затраты в виде вынужденной бесплатной технической поддержки. Зачастую такие решения предполагают невозможность рефакторинга в будущем.

    Часто бывает так, что одно и то же решение задачи может быть как в «быстрых деньгах», так и в «больших ставках». Думаю, менеджеры чаще будут выбирать «быстрые деньги» и расплачиваться в долгосрочной перспективе.

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


    1. KarinaTsar Автор
      08.08.2018 10:11
      #18970379

      Отвечу по пунктам:

      • Если использовать матрицу для приоритизации продуктового бэклога (приоритизация проектов), а не проектного (приоритизация задач), то внутри проекта задачи из «денежной ямы», требующиеся для реализации задач из «больших ставок» относятся к одному проекту и оцениваются совокупно.
      • Не очень понятно, что вы имеете ввиду под «могут сместить» — приведите пример.
      • В рамках именно приоритизации с помощью матрицы инкрементальные задачи должны «заполнять пустоты», а не быть самодостаточным проектом. Для решения проблемы смещения по графику как раз и предлагается более трезво оценивать сроки
      • При оценке сроков подразумевается оценка реализации в целом, при этом низкое качество кода не навязывается матрицей, если разработчик оценил сроки с плохой реализацией, то матрица в этом точно не виновата :)

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


      1. c0f04
        08.08.2018 18:33
        #18973625

        Не очень понятно, что вы имеете ввиду под «могут сместить» — приведите пример.

        Тут на хабре была очень интересная статья на эту тему "Чёрные треугольники". В реальном мире далеко не всегда решают создавать фреймворки или движки. А без них большая часть возможностей будет попадать в «денежную яму» или в «убыточность».

        К примеру, есть задача открыть какой-либо файл (что-то сложное, например, 3D-сцена) и отобразить его содержимое на экране. Клиент уже готов платить. Можно взять за основу библиотеку для работы с этим форматом и завязать на неё отрисовку. Но другой клиент хотел более сложный формат файла, для которого нет библиотеки. Её будут писать и скорее всего завяжутся на уже реализованный функционал. Форматы могут сильно отличаться. И скорее всего реализация будет упираться в неудобства завязки на первую библиотеку. Неудобства в данном случае будут выражаться будущей поддержкой кода. Получается две задачи, одна в «быстрых деньгах», другая — в «денежной яме». Но если сделать абстракцию над библиотекой и свой движок вывода («денежная яма»), то на момент окончания реализации обе задачи перемещаются в категорию «быстрых денег». То есть все задачи в совокупности окажутся в категории «большие ставки». И тут дело уже за менеджерами, нужны ли им «быстрые деньги», либо быстро развивающийся продукт.

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


        1. KarinaTsar Автор
          09.08.2018 06:30
          #18975143

          Приведённый вами пример как раз к оценке сроков и относится. Матрица обычно используется не для принятия технических решений, а для выбора, какую из идей брать в работу / не брать в работу.
          Для простоты — ваш пример Идея1:
          Реализация X — N дней, A отдачи
          Реализация Y — M дней, B отдачи
          При этом в бэклоге есть и другие идеи:
          Идея2 — O дней, C отдачи
          Идея3 — P дней, D отдачи.
          И в данном случае, если для Идеи1 варианты реализации оценены некорректно (прогнозируемая отдача не учитывала риски техдолга или «подготовительных работ», которые относятся к проекту по реализации Идеи1), то и матрица отобразит это некорректно.

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


          1. c0f04
            09.08.2018 07:26
            #18975253

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

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


            1. KarinaTsar Автор
              09.08.2018 12:42
              #18976575

              Если на матрице не размещать альтернативные решения, то она не будет их учитывать, конечно :)

              По поводу необходимости технического бэкграунда у менеджеров уже сотни копий сломано, в том числе на Хабре. По своему опыту могу сказать, что мне лично навыки программирования помогают только в проектной части, а для продуктовой части менеджмента программерские навыки или фиолетовы, или оказывают негативный эффект.
              Если рассматривать только одну сторону управления, то, конечно, понимание важности хорошей кодовой базы (~минимизированный техдолг) и опыт оценки сроков по собственному опыту программирования сильно помогает в организации процесса разработки.
              Однако как показывает мировой опыт — одной только правильно выстроенной и успешно завершённой разработки недостаточно для успеха на рынке и статья как раз о том, чтобы оглядываться в первую очередь на бизнес-показатели продукта, а не на своё представление о нём и счастье пользователей