Кейс ANNA.MONEY — как планирует релизы и ведет разработку британский IT-cтартап в сфере финансов

Планирование релизов с помощью User Story Mapping, техника в действии!

Иракли Агладзе, Anna Money, Open Banking, кейс Кайтен, Kaiten, кейс Anna Money, кейс User story map, пользовательские истории
Иракли Агладзе — продакт менеджер Anna Money

Мы взяли интервью у Иракли Агладзе — продакт менеджера Anna Money. Иракли занимается Open Banking — партнерством с другими банками и платежными системами.

Иракли, расскажи немного про Anna Money, что вы делаете, что у вас за продукт?

ANNA — автоматизированный банковский помощник. Это значит, что Anna может сама выставить счет клиенту, мониторить баланс в других банках, заплатить налоги и подать декларацию. По сути, — это платежная система с клиентским сервисом, которая работает по технологии машинного обучения. На данный момент у нас около 80 сотрудников, распределенных по всему миру. Есть три основных офиса в Великобритании и России, А еще с нами работает много удаленных сотрудников.

Иракли, что ты в целом думаешь о планировании в его классическом исполнении (гантт, сетевые графики, ресурсное планирование)?

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

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

А как ты планируешь релизы, какие инструменты для этого используешь?

У нас есть определенные цели, которые нам нужно достичь. Эти цели в формате OKR записываются в инструмент, который называется Weekdone, хотя табличка в Excel тоже может успешно с этим справиться, лишь бы не лень было ее заполнять (мне всегда лень). Пользовательские истории, отвечающие этим целям, выводятся на общий сторимап (User Story Map) — там мы вместе с командой расставляем приоритеты, обсуждаем, что лучше сделать в первую очередь и что и как повлияет на достижение целей.

Подробнее о сторимапах (Карты пользовательских историй, в оригинале «User Story Map»)

Если вы знакомы с термином и сутью, можете смело переходить к следующему вопросу. Здесь мы расскажем что такое USM.

User Story Map – инструмент, который позволяет структурировать техническое задание в определенном визуальном формате, чтобы:

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

Например, у вас есть такое ТЗ, описанное в виде древовидного списка:

  1. [Раздел] Настройка приложения
    1. [Страница] Профиль
      1. [Функция] Редактирование имени
      2. [Функция] Редактирование email
      3. [Функция] Настройка почтовых уведомлений
    2. [Страница] Оплата
      1. [Функция] Оплата банковской карточкой
      2. [Функция] Оплата с помощью PayPal
  2. [Раздел] Работа с транзакциями
    1. [Страница] Список транзакций
      1. [Функция] Просмотр списка
      2. [Функция] Фильтрация по типу транзакций
    2. [Страница] Страница транзакции
      1. [Функция] Просмотр детализации
      2. [Функция] Возврат средств
      3. [Функция] Частичный возврат средств

Оформляем ТЗ в виде User Story Map:

Иракли Агладзе, Anna Money, Open Banking, кейс Кайтен, Kaiten, кейс Anna Money, кейс User story map, пользовательские истории
ТЗ в виде User Story Map

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

  1. первый уровень называется Активности, туда вошли разделы из ТЗ;
  2. второй уровень — пользовательские истории, туда вошли страницы;
  3. третий уровень — задачи, это уже функции которые мы должны реализовать в рамках страниц из ТЗ.

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

Можешь поподробнее рассказать про ваш сторимап (User Story Map), что это такое?

У нас много карт, и моя выглядит вот так, за мной закреплено направление open banking.

Иракли Агладзе, Anna Money, Open Banking, кейс Кайтен, Kaiten, кейс Anna Money, кейс User story map, пользовательские истории
User Story Map направления open banking

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

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

Иракли Агладзе, Anna Money, Open Banking, кейс Кайтен, Kaiten, кейс Anna Money, кейс User story map, пользовательские истории
В User Story Map Anna.Money релизы привязаны к датам

А что происходит дальше со сторимэпом, как он обновляется, разработчики тоже его используют?

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

Иракли Агладзе, Anna Money, Open Banking, кейс Кайтен, Kaiten, кейс Anna Money, кейс User story map, пользовательские истории
Карточка в User Story Map связана с карточкой на канбан-доске в Кайтен

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

Иракли Агладзе, Anna Money, Open Banking, кейс Кайтен, Kaiten, кейс Anna Money, кейс User story map, пользовательские истории
Карточка на доске, связанная с карточкой User Story Map
Иракли Агладзе, Anna Money, Open Banking, кейс Кайтен, Kaiten, кейс Anna Money, кейс User story map, пользовательские истории
В карточке в Кайтене видны связи, поэтому понятно, ради какой цели выполняется задача

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

С инструментами понятно, а можешь рассказать как вы придумываете фичи, про процесс генерации идей?

Есть стратегическая часть, которая заключается в том, что акционеры с нами обсуждают глобальную идею «мы хотим сделать A и B, стать C и D через Х недель, потому что Y». Далее, мы в своих командах принимаем решение, что конкретно мы в рамках своей компетенции можем сделать, чтобы этих целей достигнуть. Смотрим, что происходит на рынке, чем занимаются конкуренты, с чем приходят наши партнеры. Иногда, наоборот, думаем: «А вот было бы круто, если бы …» — и уже потом идем к нашим партнерам, и предлагаем им что-то новое.

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

Дай нам совет, как продакт и проджект менеджерам делать свою работу хорошо?

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

Попробуйте Kaiten и улучшите работу своей компании

Зарегистрироваться

Интересные статьи

Кейс применения Kaiten международной IT-компанией
Рассказываем, как Kaiten помог трём отделам слаженно работать, а руководителям компании — следить за процессом в реальном времени
Kaiten вместо связки Trello и Jira: кейс «Додо Пиццы»
Сочетание Jira и Trello внутри одной компании создавало больше проблем, чем преимуществ. Мы выбрали третий вариант — Kaiten
Как несколько человек развивает множество проектов: кейс Rossko
Что находится под капотом у ведущего поставщика автозапчастей