How I Met Your Product

#modulbank

В прошлый раз я начал рассказывать, как происходит приоритизация задач у нас в Модульбанке и как на них влияют пользователи. Если вдруг пропустили, то это тут https://t.me/growthup/256

Ранее мы обсудили, что идея (задача) появляется и проходит первые этапы и когда мы решаем, что ее точно делаем (сами уверены или большое кол-во голосов у пользователей), то она попадает в столбик план и именно из этого столбца/статуса Аналитик берет задачу.

А теперь обсудим кто такой аналитик у нас. Да да, над всеми идеями у нас работает “креативная пара” в лице аналитика и дизайнера. Так как мы банк, то мы не можем себе позволить себе роскошь с неописыванием задачи полностью не предусмотрев все возможные кейсы, поэтому для каждой идее мы делаем технические задания. По факту это не такой унылый документ, как может показаться на первый взгляд. Это больше похоже на user story с очень подробным описанием, но при этом простым языком и кучей картинок. Задача аналитика не просто описать реализацию идеи, а именно совместно с дизайнером придумать эту реализацию, найти ключевые метрики, понять, что будет служить показателем успеха данной фичи и уже потом все это описать. Четкого правила нет, кто начинает первый, дизайнер или аналитик, так как это зависит от задачи, так как может быть так, что визуально пользователь увидит одну кнопку, но на самом деле по нажатию будет запущен целый конвейер процессов и задействовано уйма людей. А может быть и наоборот, когда идет вопрос редизайна чего-либо, то здесь главенствует дизайнер, а аналитик просто описывает принцип.

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

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

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