30 декабря
150 молодых специалистов и 40 социальных проектов, меняющих наше общество: как прошел ночной Social Impact Hackathon&Accelerator
| 1 | 1 | 3 |
Если вы планируете запуск какого-либо продукта, вам нужно не только правильно определить цели (об этом мы писали здесь), но и расставить их в определенном порядке. Для этого подойдет скоринг (scoring) задач. Какие методы расстановки задач существуют и как они помогают сделать выбор в сложных ситуациях, нам рассказал Юрий Бранковский, продакт-менеджер с 7-летним опытом работы в ИТ, ментор и член жюри хакатонов Emerge и Epam engineering jam.
— Скоринг задач (приоритизация списка задач) — один из инструментов, который регулярно используют при разработке и запуске продукта. Скоринг нужен для очистки бэклога от ненужных, бесполезных или утративших актуальность задач или для определения состава роадмэпа продукта, продуктового портфеля компании. Сам по себе скоринг ничего не дает и как любой инструмент может принести компании и пользу, и вред. Поэтому важно понимать, как, где и когда его применение актуально.
Бэклог — это журнал оставшейся работы, которую необходимо выполнить команде.
Если просто применять ту или иную модель скоринга, без глубокого анализа данных, существует риск начать оценивать экспертно, то есть — основываясь на собственном опыте, интуиции и выводах. Например, менеджер говорит фразу: «Компания N произвела такие-то действия и получила такие-то результаты, поэтому считаю, что нам необходимо сделать так же». Это — экспертная оценка, которая не учитывает специфику текущей ситуации, продукта и факта, что компания N уже вышла на рынок. В данной ситуации менеджер пытается перенести чужой опыт на свою компанию без каких-либо оснований. Или, например, менеджеру просто так нравится его идея, что он пытается «подогнать» итоговый балл скоринга, чтобы «фича» (идея с неким рыночным преимуществом) пошла в разработку.
Поэтому даже те формулы скоринга, которые используют множество параметров, могут дать нерелевантный итоговый балл.Не стоит оценивать что-то «в лоб», необходимо понимать, относительно чего выставляется оценка: относительно цели, влияния на фокус компании, метрики, выручки и пр. Выбор ключевого параметра зависит от специфики продукта и команды.
Например, продуктовые команды концентрируются на LTV (lifetime value) и Retention (коэффициент удержания пользователя/клиента). А «команды роста» (отвечают за разработку проектов, потенциально сулящих компании кратный рост) оценивают проекты и «фичи» относительно выручки или количества пользователей.
Если проект оценивать относительно влияния на фокус компании, глобальную цель, то все равно стоит любому фокусу и цели сопоставлять цифры. Поэтому лучше всего для скоринга использовать понятную метрику, которую просто посчитать и проще спрогнозировать степень ее изменения.
Например, фокус компании на международную экспансию можно оцифровать количеством активных зарубежных пользователей, количеством стран, количеством заключенных контрактов с компаниями и т.д. Чтобы команды понимали, как их работа и отдельные «фичи» влияют на движение компании относительно фокуса, лучше всего использовать дерево метрик. Этот метод позволяет декомпозировать глобальные цели до фундаментальных показателей, с которыми проще работать продакт-менеджерам.
Важно, чтобы метрики сопоставлялись с P&L компании (profit & loss report, отчет о прибыли и убытках). Таким образом продакт-менеджеры и команды будут чувствовать большую ответственность, так как влияют не на абстрактный параметр, а на деньги. То есть буквально дерево метрик должно быть математическим «скелетом» компании.
Например, на рисунке 1 показано верхнеуровневое дерево метрик маркетплейса образовательных курсов, в котором количество оплаченных курсов определяется более низкоуровневыми метриками:
Количество оплаченных курсов = трафик х конверсию в заявку х конверсию в оплату.
При этом объем трафика зависит от количества партнеров. И если декомпозировать дерево дальше, можно составить ветвь метрик для отдела продаж, где партнеры будут разбиты на категории (например, по объему трафика), а менеджеры будут обзванивать те сегменты, которые приводят больше потенциальных покупателей.
Таким образом, команды получат четкую метрику, которая:
1) позволяет производить скоринг, опираясь на четкие, понятные данные (количество оплаченных курсов, конверсия в заявку и оплату)
2) дает понимание, как именно команды своей работой влияют на глобальную цель компании (что повышает и эффективность работы, и мотивацию).
Существует много моделей скоринга, начиная от подсчета «по здравому смыслу» и заканчивая формулами, позволяющими рассчитать конкретный балл для каждого проекта или «фичи». Одни компании используют стандартные модели, другие кастомизируют их «под себя». Единого подхода нет, главное, чтобы модель решала основную задачу — делать то, что приводит компанию или продукт к поставленной цели (о правильной расстановке целей мы писали вот здесь).
Скоринг проектов относительно показателя Return On Investment (коэффициент окупаемости инвестиций). Чем выше ROI проекта, тем раньше этот проект необходимо сделать, закончить. При этом можно устанавливать минимальный порог проекта: например, проекты с ROI меньше 300% — вообще не брать в работу. Хорошим ROI считается показатель от 300%, в остальных случаях получается, что проект сработал практически «в ноль». Больше 1000% — это уже подозрительный показатель. Но рост до 10 раз вполне возможен, если, например, очень дешевая в реализации идея принесла много новых пользователей.
((Доход от вложений — размер вложений) / Размер вложений)*100% = ROI (коэффициент окупаемости вложений)
Это хороший метод для расчета маркетинговых проектов и «фичей», профит которых достаточно просто посчитать. Если оценить профит от проекта сложно, то показатель может быть сильно завышен. Однако, с другой стороны, необходимость максимально точного расчета дохода от проекта позволяет лучше проанализировать сам проект (продукт, «фичу») и понять, как она («фича») влияет на финансовые показатели.
Для SaaS-сервисов можно использовать другую формулу:
((Жизненная ценность клиента — стоимость приобретения клиента) / стоимость приобретения клиента)*100% = ROI, где жизненная ценность клиента = CLV = (средняя стоимость покупки х среднее количество повторных покупок).
Например, у вас есть две кампании. Одна стоит 100 тыс. руб. РФ, вторая — 200 тыс. руб. РФ. Потенциально первая может принести 1000 новых пользователей, вторая — 4000 пользователей. Сперва вторая кажется более выгодной, так как стоимость привлечения клиента в два раза меньше. Но разработка первой кампании будет стоить 60 тыс. руб., а второй — 150 тыс. руб. Например, за счет необходимости партнерских интеграций и дополнительной разработки. При этом в первом случае вы ведете пользователя на свой лендинг, где он покупает услугу за 200 рублей, а во втором случае вы даете скидку 50% (100 руб.) в рамках акции с партнером.
Таким образом, считая все данные и полагая CLV одинаковыми для обоих случаев, получаем:
Получается, что обе компании невыгодны при подобной экономике (ROI < 100%), при этом у первой кампании ROI почти в два раза выше, хотя изначально казалось, что вторая лучше.
Также при расчете дохода от проекта или «фичи» можно использовать данные по предполагаемому изменению таких метрик, как LTV и Retention.
Если вы опасаетесь, что при таком методе оценки проектов вы будете фокусироваться на тех, что приносят больший доход за меньшее время, то можно определять портфель проектов на год таким образом, чтобы доход от краткосрочных проектов можно было реинвестировать в более стратегические проекты.
Также портфель проектов можно оценивать относительно стоимости команды за год: если команда не окупает себя, то стоит подумать о том, чтобы помочь ей сфокусироваться или переключиться на другие проекты, где она сможет показать себя.
RICE — еще один метод приоритизации идей и «фич» продукта. Аббревиатура включает 4 фактора, которые продакт-менеджер может использовать для оценки и приоритизации продуктовых «фич»:
Уровень охвата (Reach) измеряют количеством людей/событий за определенный период времени. Например, «фича» для онбординга будет касаться всех новых пользователей, но не будет важна для старых пользователей. При этом надо учитывать, что если онбординг пользователи проходят один раз, то при уменьшении трафика охват также будет меняться. В отличие, например, от основных (старых) пользователей, количество которых не сильно меняется, если Retention вышел на плато.
Онбординг (onboarding) — это процесс, через который проходят пользователи от начала своего пути до становления клиентом и далее.
Если в продукте речь идет о миллионах пользователей, то лучше разбить их на сегменты, например, где 1 — «меньше миллиона пользователей», а 10 — «10 миллионов», и в расчете указывать цифры от 1 до 10, чтобы не считать «фичи» в миллионах.
Влияние (Impact) показывает, какой вклад приносит эта «фича» продукту. Измеряться может в баллах (1 — слабое влияние, 3 — сильное влияние). Ценность показателя понимается по-разному в каждом продукте. Лучше всего делать этот показатель минимально субъективным. Например, оценить, насколько новая «фича» может потенциально увеличить в онбординге конверсию в первую оплату. Таким образом, можно будет сравнивать разные «фичи» относительно единого показателя — денег.
Показатель Confidence призван снизить влияние экспертности в оценке предыдущих показателей, однако опыт показывает, что и уверенность часто завышают. Чаще всего 100%-ный показатель ставят для «фичи», у которой есть оценка трудозатрат, данные аналитики или АБ-теста либо исследования, которые могут подтвердить необходимость релиза. Однако даже наличие всего этого не гарантирует 100%-ного результата.
Вдобавок, одно дело — оценка гипотезы (9 из 10 гипотез проваливаются, получается, что confidence вообще не поднимется выше 10%), другое — «фичи», которые разрабатывают уже после экспериментов. Однако бывают ситуации, когда после раскатки эксперимента он показывает результаты хуже, хотя во время теста все было ок. Например, такое может быть в сложных операционных продуктах. Также этот показатель может быть рассчитан более субъективно, в баллах, где 1 — «слабо верим», 2 — «верим», 3 — «сильно верим». Но я бы советовал все-таки прописывать критерии оценок «сильно, слабо», чтобы снижать субъективность и экспертность скоринга.
Трудозатраты (Effort) оценивают как количество «человеко-месяцев», недель, дней или часов, в зависимости от специфики разработки и ее уровня. Главное, чтобы оценка всех проектов была в одних единицах.
Например, у вас две «фичи»: одна — в онбординге, вторая — в основном продукте. Охват первой составляет 1000 пользователей, второй — 500. Влияние «фичи» оцениваем по шкале 1–3: «не сильно», «сильно», «кардинально». И для первой она составляет 3, для второй 2. То есть «фича» в онбордниге может кардинально повлиять на конверсию в оплату, а та, что в продукте — сильно повлиять на retention. Сложность первой 4 (недели разработки), второй — 2. Для альтернативного примера посчитаем уверенность не в процентах, а также по трехбалльной шкале («слабо верим», «верим», «сильно верим»): 1 для первой и 2 для второй. Таким образом, получаем:
То есть берем в работу вторую «фичу», для продукта.
Этот метод определения приоритетов был придуман Шоном Эллисом, который известен авторством термина Growth Hacker.
В ICE используется шкала от 1 до 10, чтобы все факторы сбалансировано повлияли на итоговый балл (все составляющие оцениваются в баллах, а не в реальных показателях). Оценивать можно то, что вам нужно, лишь бы все значения были согласованы между собой (руководствуясь логикой). Оценка получается достаточно субъективной, потому что перевод в баллы не имеет четкого критерия. Но этот метод можно кастомизировать «под себя», чтобы он стал точным. Также можно использовать комбинированные модели, которые сочетают в себе несколько моделей оценки (например, как в весовой модели).
Такая модель даже может содержать в себе вышеупомянутые системы, чтобы сделать оценку более сбалансированной и учитывающей специфику команды. Также это позволяет не забывать про стратегические и блокирующие проекты, у которых другие показатели могут быть относительно невысокими.
В любом случае важно описывать принцип проставления баллов, чтобы оценка была максимально прозрачной для всей компании.
Также важно проверять, что все показатели оцениваются в одинаковых единицах. То есть некорректно сравнивать проекты, где Impact в одном случае оценивается в деньгах, а в другом — в степени влияния на метрику, тогда лучше все пересчитать в деньги. Также комбинированный метод позволяет оценивать стоимость всех проектов и сравнивать со стоимостью команды. Продуктовый портфель нужно составлять таким образом, что даже если из 10 проектов «выстрелит» 1, то он должен окупить команду с положительным показателем.
Как оценить уверенность (confidence)
По своему опыту могу сказать, что уверенность вызывает всегда больше вопросов и у менеджеров, и у разработки. Если остальные показатели можно оценить достаточно точно, то как оценить уверенность? И как снизить влияние «желания запилить эту красивую «фичу», чтобы не получилось так, что подсознание подгоняет результаты скоринга под желаемую «фичу»? Лучше всего договориться внутри команды или компании о том, какие могут быть уровни уверенности при использовании в скоринговых моделях. Например, можно использовать инструмент, предложенный Итамаром Гиладом, продакт-менеджером Google и Microsoft с более чем 20-летним стажем работы.
Рассмотрим уровни подробнее:
Так как не все «фичи» доходят до запуска, то при скоринге проектов на этапе планирования можно умножать уровень уверенности на 0,1 (исходя из того, что «выстреливает» лишь 1 гипотеза из 10). Таким образом, можно начать с проектов, у которых много подтверждений, и параллельно дополнить данными другие проекты — для повышения уровня уверенности, который в итоге повлияет на место проекта или «фичи» в общем бэклоге.
Вне зависимости от инструмента, который вы выберете для скоринга, важно помнить про три ключевых момента:
Также важно презентовать вашу систему скоринга стейкхолдерам и команде, чтобы оценка была максимально прозрачной. Во время презентации вы еще и дополнительно проверите ваш метод «на прочность».
30 декабря
150 молодых специалистов и 40 социальных проектов, меняющих наше общество: как прошел ночной Social Impact Hackathon&Accelerator
27 декабря
Плоская кровля: как ПВХ-мембраны решают проблемы проектировщика, монтажника и заказчика
26 декабря
Разреши себе вести бизнес по-королевски с Белинвестбанком!
26 декабря
Максимальное вдохновение и мотивация: Беларусбанк выпустил очень добрый корпоративный календарь
26 декабря
Как избежать протечек и износа кровли: почему важна жесткость основания под гидроизоляцию
24 декабря
МТБанк предлагает поделиться частичкой тепла, отправив родным и близким уникальную новогоднюю открытку
23 декабря
Белагропромбанк поможет развивать ваш бизнес
20 декабря
А1 улучшил мобильную связь в 33 районах Беларуси
