Как в Skyeng работают
с бэклогом?
Наполнение и приоритизация

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

1. Стратегия компании

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

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

2. Job Story

Второй пункт — job story. Приведем такой пример: все видели недавний запуск Яндекс.Go, который теперь стал закрывать job story не только такси, но и заказа продуктов, еды и так далее. Это тоже часть стратегии компании, новая глобальная функция, которую компания закрывает. Это не маленькая фича, а глобальное изменение рынка, и если у вас верхнеуровнево сформулирована job story, то бэклог наполняется соответствующими задачами, которые помогают ее реализовать.

3. Инсайты от фаундера или руководителя компании

Третьим инструментом являются инсайты от фаундера или руководителя компании.

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

4. Инсайты с рынка

Четвертый инструмент — инсайты с рынка. Если вы находитесь на позиции мидл- или сеньор-продакта или туда метите, очень важно следить за рынком:

1. Узнавать, что нового появилось в сфере технологий, близких к вашему продукту;
2. Следить, что запускают ваши конкуренты в России, в США, в Китае или где-то еще.

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

5. Инсайты от отдела продаж или техподдержки

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

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

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

6. Аналитика

Шестой способ наполнения бэклога — разумеется, аналитика. Здесь все просто: вы изучаете вашу систему аналитики, просите вашего аналитика искать «выбросы» — неожиданные изменения метрик.

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

7. Результаты кастдевов

Седьмой инструмент, который неоднократно упоминался выше — результаты кастдевов. Это очень важный пункт, но нужно помнить несколько аспектов:

• Во-первых, кастдев дает не только какие-то конкретные инсайты и конкретные гипотезы.

Когда вы занимаетесь кастдевом, в вас пробуждается эмпатия. Вы начинаете чувствовать то, что чувствует ваш пользователь, и понимаете, как он мыслит. Очень часто люди, работающие в сфере IT, что называется, «далеки от народа». Как правило, это люди с доходом сильно выше среднего и у них совершенно другие жизненные проблемы. Кастдевы и разговоры с пользователями помогают сформировать ощущение «живого человека», для которого продукт и делается. Это также очень важно.

• Во-вторых, кастдевы — хороший инструмент для проверки стратегии или job story.

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

8. Результаты исследований

Восьмое и последнее — результаты исследований. Под исследованиями здесь подразумеваются скорее не кастдевы, а несколько иной момент.

В Skyeng есть отдел исследования рынка, и главный результат его деятельности — инсайты о том, как себя ведет не один или несколько пользователей, а пользователи вкупе, потому что сто пользователей могут начать вести себя иначе, чем один конкретный пользователь, выбранный для конкретного исследования. Есть эффект толпы, эффект массовости и многие другие вещи, и, соответственно, статистика рынка и покупательской способности это все объединяет.

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

Зачем вообще приоритизировать бэклог? Почему нельзя все делать планомерно? Все очень просто.

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

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

Приоритизация позволяет делать такие изменения — какими бы они ни были интересными и важными — позже, чем воплощать сильные гипотезы, которые могут ощутимо сдвинуть метрику или продукт.
Здесь стоит порекомендовать вам книгу «Эссенциализм». Эта книга — о том, что очень важно выбирать то, что вы делаете, и каждый раз, когда вы чему-то говорите «да» — например, вытащили из бэклога одну фичу и начали ее реализовывать — это автоматически означает, что десяти другим фичам вы сказали «нет». Или, наоборот, когда вы какой-то фиче говорите «нет», решаете, что ее вы точно не возьмете в продукт, это означает, что вместо траты сил на нее вы будете делать что-то другое, и это «другое» может быть лучше.

У вас мог возникнуть вопрос: «А почему нельзя просто взять и использовать любой фреймворк? Их же довольно много». Здесь будут упомянуты несколько из них, но на самом деле их несколько десятков и в Интернете можно почитать о них подробнее. Почему все же нельзя пользоваться исключительно ими?

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

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

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

В двух словах — способов приоритизации много.

Начнем с простого. Если вы смотрели выступления сотрудников Skyeng, то вы, наверное, слышали про ROI. До сих пор некоторые команды используют ROI как систему приоритизации. Работает она очень просто: берем то, сколько мы заработаем с фичи, делим на то, сколько она нам будет стоить, и получаем конкретный коэффициент ROI, то есть окупаемость инвестиций.

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

Существует часто используемый фреймворк ICE, в котором мы оцениваем impact, confidence и effort.

По сути, это такой же ROI, только посчитанный немного иначе и с учетом confidence. Что это такое?

«Confidence» — это вера в конкретную фичу. Обычно ICE используют с четырехбалльной, пятибалльной или десятибалльной шкалой. Что происходит при его использовании? Берется какая-то идея и рассматриваются следующие показатели:

— сколько на ней можно заработать,
— насколько мы в нее верим,
— насколько сложно будет ее реализовать (причем в последнем пункте оценка идет наоборот: чем больше усилий будет вложено, тем меньше балл).

Потом это все перемножается и на выходе мы получаем скоринг ICE, по которому можно оценивать фичи.

Чтобы его немного улучшить, можно попробовать не просто высчитывать коэффициенты по баллам, а самостоятельно выработать шкалу оценки.
Приведем пример: допустим, вы делаете какую-то фичу, и если вы планируете заработать с нее от нуля до миллиона рублей, то ее impact — единица, если от одного миллиона до десяти — то значение impact будет равно двум, и так далее.

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

Подобная шкала будет полезна не только для ICE, но и для RICE-приоритизации. RICE, по сути, использует примерно те же самые расчеты, но, во-первых, формула немного отличается, а во-вторых, здесь добавляется reach — охват, число пользователей, которые этой фичей смогут воспользоваться. Именно поэтому RICE гораздо больше подходит компаниям, которые уделяют большое внимание масштабированию.

Также есть модель KANO, которая используется довольно часто. Что она из себя представляет?

Прежде всего, это график с двумя осями: первая — насколько глубоко проработана функция. То есть если, например, взять функцию заказа такси, то в приложении Яндекс.Go она проработана отлично, соответственно, мы ставим точку на этой оси ближе к правой части, потому что функция полностью закрыта. Если же функция не закрыта или закрыта плохо, то мы поставим точку ближе к левой части оси.

Вторая ось — степень удовлетворенности пользователя. В случае с моделью KANO фичи можно условно разделить на три вида. Первый вид — это функции, являющиеся для пользователя основными.

Условно, если вы пользуетесь Google Docs, то основной функцией для вас будет написание текста и вряд ли она вызовет у вас какое-то восхищение, вы ожидаете ее по умолчанию. При этом не делать этот функционал нельзя, потому что он представляет собой базовые ожидания пользователя от продукта.

Есть второй вид фичей: это функции, являющиеся основным инструментом выбора для пользователя. Если мы говорим о тех же самых Google Docs, то к этим функциям можно отнести объем хранимых документов на Диске, работа функции автосохранения, разделение доступа к документу с другими людьми — словом, это те признаки, на основании которых пользователь и выбирает продукт. Это не базовые функции, они дополнительные, но именно они могут являться вашим конкурентным преимуществом, хотя и не вызывают у пользователя трепета.

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

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

Проходимся по столбцам таблицы:

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

Допустим, в какой-то момент ваша компания настолько отмасштабировалась, что все процессы внутри нее стали невероятно сложными. Это значит, что, прежде всего, нужно делать фичи, решающие какие-то блокирующие проблемы. В таком случае можно, например, поднять приоритет столбца «Блокер» до 40 процентов (разумеется, в сумме все приоритеты не должны давать больше 100 процентов). Или, например, вы знаете, что у вашей компании проведение экспериментов и реализация почти не занимают ресурсов — допустим, у вас все сделано на Tilda и собрать решение вы можете за несколько минут. Это значит, что вы можете «скрутить» приоритеты у правой части, отвечающей за соответствующие процессы, и не обращать на нее внимания, а вес ценности, наоборот, увеличить.

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

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

Суммируя вышесказанное, какие можно отметить правила развесовки приоритетов?

1. Еще на старте нужно договориться с руководителем о весах приоритетов и о самих приоритетах или составить их самому, исходя из особенностей компании.

2. Очень важно договориться о распределении баллов: все фичи нужно оценивать по одинаковым критериям.

3. Необходимо оставлять буфер для внезапных, незапланированных задач, и не планировать время команды вплотную.

При этом при развесовке нужно учитывать:

1. Приоритеты и стратегию компании, если они сформулированы;

2. Ситуацию с экономикой, деньгами и рынком;

3. Ресурсы компании.

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