Интуиция против статистики: как расставить приоритеты по внедрению новых функций

Руководитель по мобильным продуктам «Сбербанка» для юридических лиц Кирилл Гурбанов рассказал о том, как приоритезировать доработки продукта при помощи оценки по взвешенным факторам.

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

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

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

Если вы работаете в большой организации, где продуктом занимается не один человек, а несколько, то наверняка регулярно будете получать вопросы относительно приоритетов в бэклоге. «А когда будет вот это?», «А почему это решили не делать?», «Вот эту штуку нужно 100% реализовать, она очень нужна» и далее в таком духе. Вопросы будут приходить от коллег, от начальства, от смежных отделов, от команды.

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

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

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

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

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

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

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

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

Здесь можно привести аналогию с предпринимательской средой. Мое общение с многочисленными бизнесами, ИТ-компаниями, стартапами подтверждает, что в России мало предпринимателей, опирающихся на цифры.

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

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

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

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

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

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

Я рекомендую выбрать от четырех до семи наиболее важных продуктовых метрик и сделать их критериями скоринга. Вот несколько примеров:

• влияние на выручку;
• влияние на лояльность пользователей;
• наличие аналогичных функций у большинства конкурентов;
• может привлечь новых пользователей;
• охват аналогичными функциями среди пользователей веб-версии (для мобильных продуктов);
• влияние на Retention или Churn и так далее;
• влияние на стоимость привлечения.

Обязательно оставьте среди критериев хотя бы один, который будет учитывать субъективные вещи. В конце концов, никто не отменял чутье, так пусть оно станет одним из критериев.

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

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

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

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

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

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

Не стоит забывать, что скоринг заставляет внимательнее относиться ко времени разработки, что влечет к прямой экономии средств.

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

Этого можно избежать. Достаточно при постановке каждого балла (особенно тех, что являются экспертными, то есть субъективными) несколько раз спрашивать себя или команду: «Является ли этот балл реальным отражением вещей, или мы завышаем его?». Такая простая вещь работает на удивление хорошо.

Давайте подведем итог: что нужно сделать, чтобы внедрить скоринг в свою работу.

• Выберите критерии, по которым будете оценивать все доработки. Пусть это будут 4-7 наиболее важных продуктовых метрик.
• Расставьте веса. Не делайте ни один критерий блокирующим». Не занижайте вес технической сложности
• Определите порог скоринга — как правило, техническую сложность, ниже которой задачи попадают сразу в разработку.
• Проскорьте весь имеющийся бэклог, чтобы актуализировать приоритеты.
• Подвергайте процедуре скоринга каждую значимую доработку продукта.
• Создавайте продукт, который пользователи будут любить.

#Кейсы