[Перевод] Почему приоритизация по трудозатратам и ценности не работает
И почему всё же стоит использовать её
Статья рассказывает, почему наиболее популярный способ приоритизации бэклога не так хорош, как принято думать, и что можно сделать, чтобы улучшить его.
Оценка трудозатрат на разработку и ценности (отдачи от трудозатрат) — главный элемент приоритизации в продуктового бэклога: это простой понятный подход, а потому очень популярный. У вас наверняка есть 2 такие колонки в продуктовом бэклоге (и даже если нет, то стоит их добавить):
Столбцы: Фича/Проект, Трудозатраты, Ценность.
Содержимое в ячейках первого столбца:
Вкладка сообществ
Обновить потока отправки
Добавить биллинг PayPal
Исправить ошибку в квитанции
Контакт с менеджером
Обновить условия обслуживания
Трудозатраты могут указываться в человеко-неделях или просто определяться по уровню сложности задачи (простая/лёгкая/сложная). Как только у вас появляются числа, становится важным выбор тех фичей, которые обеспечат наибольшую финансовую отдачу. Но тут всё становится несколько сложнее. Для того чтобы понять, почему, давайте расположим наши задачи в прямоугольной системе координат:
По оси X располагаются трудозатраты, по Y — ценность
Достаточно очевидно, что верхние левые проекты лучше всех остальных, а правые нижние — самые плохие. Но как сравнивать всё остальное? К счастью, решение существует. Вам уже может быть знакома матрица трудозатрат и ценности. Если погуглить, можно найти тысячи разнообразных вариаций матрицы — она уже давно является best practice в индустрии.
По оси X: малые трудозатраты — инкрементальные улучшения, большие трудозатраты — «денежная яма» (прим. пер.: в других источниках «пожиратели времени»).
По оси Y: малые трудозатраты — лёгкие победы, большие трудозатраты — большие победы.
Идея очень проста — разделение на квадранты помогает увидеть, как располагаются проекты.
Квадрант «Мало / мало» в левом нижнем углу содержит мелкие незначительные улучшения продукта. Каждый продуктовый бэклог включает много задач такого типа и все они играют важную роль для заполнения простоев, но при этом обладают низким приоритетом.
С другой стороны, квадрант «Много / много» охватывает большие проекты, которые обещают большой доход. Многие амбициозные команды любят делать ставки именно на такие проекты.
Наиболее желанны проекты, комбинирующие малые трудозатраты и большую отдачу в левом верхнем углу — никто не откажется от лёгкого выигрыша (и кто знает, может быть, один из таких проектов станет очередной кнопкой, позволившей заработать $300 млн…).
И, наконец, правый нижний квадрант — большие усилия и малая отдача — так называемая денежная яма, неблагодарные задачи, чемодан без ручки. Определённо никто не хочет тратить и без того ограниченные ресурсы на создание вещей, которые требуют много работы и имеют очень небольшую ценность.
Наложение наших планов на данную матрицу позволяет быстро получить понятную картину:
… и теперь приоритизация довольно проста:
- Сначала избавляемся от всего, что находится в квадранте денежной ямы (это хорошее избавление).
- Затем задаём лёгкому выигрышу высокий приоритет.
- И в конце мы формируем микс из инкрементальных улучшений и больших ставок, основанный на доступных ресурсах и наших аппетитах.
Довольно просто?
Не так быстро…
Такая же очевидная, как всё вышеописанное, проблема заключается в том, что приоритизация по методу оценки трудозатрат и ценность вынуждает нас выбирать неправильных «победителей». В первую очередь потому, что этот метод предполагает необходимость дать оценку на основе предсказания будущих событий — усилий, которые потребуются для реализации задачи, и пользы, которая будет принесена пользователям в результате этих усилий. Как уже известно, люди очень плохи в деле прогнозирования.
Склонность недооценивать трудозатраты
В 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 (больше информации о подсчёте уровня доверия здесь).
Формула расчёта приоритетности теперь такая:
A/B-тесты
A/B-тесты уничтожают почти все догадки и избавляют от большинства рисков. Если вы тестируете фичу перед запуском, вам не нужно опираться на предчувствия и интуицию — вы увидите достаточно — успешна идея или нет. A/B-тестирование позволяет делать ставки с относительно низким риском. По этой п/ичине такие компании, как Netflix, тестируют всё — и маленькие, и большие изменения.
