ЭФФЕКТИВНОСТЬ

Формирование бэклога
и его приоритизация

Иво Димитров
Директор по продуктам Модульбанка
Сегодня я бы хотел поделиться тем, как создается бэклог у нас в Модульбанке и как происходит приоритизация.
В качестве инструмента мы используем Jira в связи с его гибкостью и возможностями интеграции с кучей всего. Здесь стоит сказать, что в нашей компании около 900 сотрудников, и вся компания работает через Телеграм. У нас написано много внутренних ботов с аналитикой, показателями, рабочими штуками и даже бот, который делает релиз. Быть онлайн в телеграмме и отвечать оперативно (в рамках разумного) у нас прописано в трудовом договоре. Боты очень нам помогают в каждодневной работе, и если с теми ботами, что присылают цифры, все понятно, то есть, например, бот, через который ты оформляешь отпуск, просишь доступ куда-то или находишь нужного человека или задачу. Одним словом это удобно, быстро, круто и бесплатно. Но вернемся к основной теме …

Внутри Jira мы управляемся сущностью «Идея». То есть любая фича это идея, которую стоит рассмотреть и, по необходимости, сделать. Любой человек в компании может предложить идею. Важно понимать, что мы просим всех описывать именно проблему, которая есть, а не как ее решить, так как для нахождения решения есть другие процессы. А еще мы недавно запустили сбор идей внутри личного кабинета (чуть ниже скриншот). Клиентские идеи видят все пользователи и могут за них голосовать, что очень помогает нам с приоритизацией.
Сбор идей в личном кабинете
Когда идея попадает на доску, то она ставится в статус «Входящие», где ожидает первичной оценки. Создатель идеи (да и другие) должны оценить идею по определенным принципам — экономика (сколько это нам сэкономит или сколько мы заработаем), крутость для клиента (по степени ожидания, например must have или супер круто феерично) и сложность (по сути некий аналог сторипойнтов). Все это считается по формуле и выводится «показатель приоритета» — цифра, которая показывает, насколько важна идея и как скоро с ней надо начинать работать. Если идея клиентская, то добавляется еще один параметр — голоса клиентов банка, которые имеют существенный вес в формуле. Далее, раз в неделю, разбираются задачи из «Входящих», и мы либо от них отказываемся (примерно 70% задач, и да, это очень круто, так как мы реально научились говорить нет фичам, а это очень и очень сложно, но полезно), либо переводим на исследование (15%), т.к. нет уверенности, надо это делать или нет. Оставшиеся идеи (15%) сразу идут в статус «Запланировано», так как по ним все понятно и логично.
Так как у нас есть показатель приоритетности, то все карточки на доске сортируются по убыванию на основе данной цифры. То, что приоритетнее, то и выше, быстрее пойдет по процессу и быстрее будет сделано. То есть идея могла прийти только сейчас, но зато пойдет в работу сразу же, так как имеет высокий приоритет. И наоборот, если идея с маленьким приоритетом, то она может очень долгое время пролежать внизу. Правда иногда мы делаем чистку и выкидываем в «Не делаем» такие задачи, если они лежат слишком долго. По сути, таким образом происходит естественный отбор идей на разработку, это позволяет нам фокусироваться только на том, что действительно важно.
А что дальше?
Теперь обсудим, кто такой аналитик у нас. Да-да, над всеми идеями у нас работает «креативная пара» в лице аналитика и дизайнера. Так как мы банк, то мы не можем себе позволить роскошь с неописыванием задачи полностью, не предусмотрев все возможные кейсы, поэтому для каждой идеи мы делаем технические задания. По факту это не такой унылый документ, как может показаться на первый взгляд. Это больше похоже на user story с очень подробным описанием, но при этом на простом языке и с кучей картинок. Задача аналитика не просто описать реализацию идеи, а именно совместно с дизайнером придумать эту реализацию, найти ключевые метрики, понять, что будет служить показателем успеха данной фичи, и уже потом все это описать. По сути аналитик у нас — это продукт-менеджер во всех остальных компаниях, и именно поэтому мы с недавних пор переименовали ребят в менеджеров по продукту, чтобы соответствовать действительности. Четкого правила нет, кто начинает первый, дизайнер или аналитик, так как это зависит от задачи: может быть так, что визуально пользователь увидит одну кнопку, но на самом деле по нажатию будет запущен целый конвейер процессов и задействована уйма людей. А может быть и наоборот, когда идет вопрос редизайна чего-либо, то здесь главенствует дизайнер, а продукт-менеджер просто описывает принцип.

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

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

Я уверен, что мы продолжим оптимизировать процесс, поэтому, если что-то интересное придумаем, то обязательно поделюсь с вами.


Иво Димитров
Директор по продуктам
10+ лет в сфере управления продуктами и продуктового дизайна. До работы в Модульбанке был соучредителем стартап-инкубатора, в котором выпустил вместе с командой много отличных продуктов на рынок России.

Facebook | Twitter
Читайте также