Мы взяли интервью у Иракли Агладзе — продакт менеджера Anna Money. Иракли занимается Open Banking — партнерством с другими банками и платежными системами.
Иракли, расскажи немного про Anna Money, что вы делаете, что у вас за продукт?
ANNA — автоматизированный банковский помощник. Это значит, что Anna может сама выставить счет клиенту, мониторить баланс в других банках, заплатить налоги и подать декларацию. По сути, — это платежная система с клиентским сервисом, которая работает по технологии машинного обучения. На данный момент у нас около 80 сотрудников, распределенных по всему миру. Есть три основных офиса в Великобритании и России, А еще с нами работает много удаленных сотрудников.
Иракли, что ты в целом думаешь о планировании в его классическом исполнении (гантт, сетевые графики, ресурсное планирование)?
Для меня планирование — это, в первую очередь, прозрачность. Это значит, команда понимает, что она будет делать завтра, акционеры знали, чем мы занимаемся сейчас и когда собираемся это поставить. Сам инструмент всегда зависит от конкретных целей — иногда мне хочется собрать для самого себя диаграмму Гантта. В основном, правда, я так прикидываю, когда в отпуск пойти можно мне или кому-то из ребят в команде
Наверное, это связано с тем, что у нас команды полностью укомплектованные внутри себя — у нас есть и backend, и frontend, которые закрывают процесс продуктовой разработки, так что нам практически не приходится планировать ресурсы в привычном понимании и траффик-менеджер нам не особо нужен.
А как ты планируешь релизы, какие инструменты для этого используешь?
У нас есть определенные цели, которые нам нужно достичь. Эти цели в формате OKR записываются в инструмент, который называется Weekdone, хотя табличка в Excel тоже может успешно с этим справиться, лишь бы не лень было ее заполнять (мне всегда лень). Пользовательские истории, отвечающие этим целям, выводятся на общий сторимап (User Story Map) — там мы вместе с командой расставляем приоритеты, обсуждаем, что лучше сделать в первую очередь и что и как повлияет на достижение целей.
Подробнее о сторимапах (Карты пользовательских историй, в оригинале «User Story Map»)
Если вы знакомы с термином и сутью, можете смело переходить к следующему вопросу. Здесь мы расскажем что такое USM.
User Story Map – инструмент, который позволяет структурировать техническое задание в определенном визуальном формате, чтобы:
- была видна связь между большими задачами и их декомпозицией;
- была разбивка: какие задачи в какой релиз (дату) выйдут.
Например, у вас есть такое ТЗ, описанное в виде древовидного списка:
- [Раздел] Настройка приложения
- [Страница] Профиль
- [Функция] Редактирование имени
- [Функция] Редактирование email
- [Функция] Настройка почтовых уведомлений
- [Страница] Оплата
- [Функция] Оплата банковской карточкой
- [Раздел] Работа с транзакциями
- [Страница] Список транзакций
- [Функция] Просмотр списка
- [Функция] Фильтрация по типу транзакций
- [Страница] Детализация по транзакции
- [Функция] Просмотр детализации
- [Функция] Возврат средств
- [Функция] Частичный возврат средств
Оформляем ТЗ в виде User Story Map:
Вы можете проследить, как структура задач здесь представлена на 3-х уровнях:
- первый уровень называется Активности, туда вошли разделы из ТЗ;
- второй уровень — пользовательские истории, туда вошли страницы;
- третий уровень — задачи, это уже функции которые мы должны реализовать в рамках страниц из ТЗ.
Обратите внимание, что уровень задач разбит на релизы. Таким образом, менеджер может быстро увидеть — что ожидается в первом релизе, что во втором и быстро перекидывая карточки между релизами планировать работу команды.
Можешь поподробнее рассказать про ваш сторимап (User Story Map), что это такое?
У нас много карт, и моя выглядит вот так, за мной закреплено направление open banking.
Цветные карточки сверху — основные направления. Далее белые карточки — большие задачи. И затем у нас идет планирование релизов — что мы хотим к началу каждого месяца иметь.
В качестве релизов мы используем даты, поэтому это получается отличный инструмент для планирования.
А что происходит дальше со сторимэпом, как он обновляется, разработчики тоже его используют?
Да, использовать сторимэп удобно для планирования, но он верхнеуровневый, сами задачи живут в канбан досках. Для примера возьмем задачу Overview assistance.
Она имеет связанную задачу с доской, где идет разработка — там уже документы и более детальная декомпозиция на подзадачи, если требуется:
Таким образом, карта служит как план, а тактические действия происходят на канбан-досках. Это все связано внутри одного инструмента, поэтому быстро находятся причинно-следственные связи и видно, ради какой цели выполняется каждая задача.
С инструментами понятно, а можешь рассказать как вы придумываете фичи, про процесс генерации идей?
Есть стратегическая часть, которая заключается в том, что акционеры с нами обсуждают глобальную идею «мы хотим сделать A и B, стать C и D через Х недель, потому что Y». Далее, мы в своих командах принимаем решение, что конкретно мы в рамках своей компетенции можем сделать, чтобы этих целей достигнуть. Смотрим, что происходит на рынке, чем занимаются конкуренты, с чем приходят наши партнеры. Иногда, наоборот, думаем: «А вот было бы круто, если бы …» — и уже потом идем к нашим партнерам, и предлагаем им что-то новое.
У нас есть какие-то гипотезы, которые мы сразу можем проверить метриками и продолжить развитие, а можем вначале пойти и спросить у пользователей. У нас есть группа ранних последователей, которые охотно с нами общаются, хотя они и не имеют никакого отношения к продуктовой разработке сами по себе — это такие же владельцы бизнесов, как хозяин вашего любимого бара на районе — им просто интересно в этом участвовать и помогать делать продукт лучше для себя.
Дай нам совет, как продакт и проджект менеджерам делать свою работу хорошо?
Всегда спрашивать себя «Зачем?». Это касается и работы с инструментами в том числе — они все очень разные и всегда проще подумать, зачем именно тебе нужно что-то, что ты собираешься использовать. Это позволит и подобрать конкретно удобное решение, и не даст увязнуть в собственно работе с инструментом как игрушкой. Например, сторимап в Кайтене я использую в качестве самого базового планирования, чтобы держать в курсе акционеров о том, что мы (я) в команде понимаем вообще, что мы делаем. В то же время для собственного понимания, что я ничего не пропустил. Мне очень помогает связь задач на доске разработчиков с пользовательскими историями. Это позволяет не задумываться о том, к чему конкретно относится та или иная задача и быстро избавляться от ненужного при необходимости.