Мы взяли интервью у Иракли Агладзе — продакт менеджера 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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