Меня зовут Александр Глухов, я в финтехе с 2013 года.
Сейчас работаю в Ак Барс Банке и оптимизирую процессы в мидл-офисе и бэк-офисе.
Мы делаем для банка разные продукты, один из них — универсальное рабочее место сотрудника.
Это внутренний сервис для сотрудников банка, который рассматривает заявки на кредит и после всех проверок принимает решение, выдавать кредит или нет. Моя история про работу с бэклогом и внутренними заказчиками.
В его основе лежат наши разработки для мидл и бэк-офисов, но выводы применимы и в других сферах, даже не связанных с банками и финтехом.
Эта статья представляет собой стенограмму отчета о встрече Three Amigos Talk.
Что это за рекламный стенд?
«В 1990 году журналисты молодёжной редакции Центрального телевидения Иван Кононов и Алексей Гиганов вывели в эфир программу «Голос народа», которую в народе прозвали «Будка гласности».На улице была установлена будка с видеокамерой, и каждый мог говорить все, что хотел».
РТ Посмотрите этот пример: Эти персонажи явно очень хотят сказать что-то важное, но не понимают, с кем и зачем разговаривают. Этот очень утрированный пример похож на то, как разработчики иногда общаются с пользователями — они не понимают, с кем разговаривают и какова цель другого человека.
И все теряют время.
Поэтому важно построить систему, в которой вы и пользователь — большая дружная команда.
Вы работаете над одним и тем же продуктом, поэтому важно общаться честно и открыто.
Хотя и здесь можно переборщить.
Кому от вас что-то может понадобиться?
Заинтересованные стороны — это название компании для людей, которые хотят что-то от вас получить.Мы будем использовать это слово на протяжении всей статьи, но имейте в виду, что оно на самом деле означает.
Существует четыре группы заинтересованных сторон:- Клиенты банка,
- Пользователи (они же сотрудники банка) — наши основные собеседники,
- Владельцы процессов
- Владельцы бизнеса.
Давайте разберемся, что именно.
Клиент
Это человек, который подал заявку на кредит. Он хочет быстро получить кредит без пятнадцати телефонных звонков и переподписывания документов, чтобы не пришлось ходить в офис.Такого обычного клиента легко представить.
Клиенты не любят долго ждать ответа и не понимать, что происходит с их заявкой.
Пользователь (сотрудник банка)
Это сотрудники банка, которые принимают решения по кредитам.Они хотят хорошо выполнять свою работу и быстро обрабатывать заявки.
Им мешают несовершенные инструменты, сбои в системе и устаревшие методологии.
Из-за этого возникают страдания.
Но сотрудники банка — это кладезь знаний о том, как сделать процессы лучше.
Важно общаться с пользователями, чтобы они не считали разработку надзорным органом, а, наоборот, доверяли вам.
Владельцы процессов (PO)
Это подразделения и участки в банке, которые хотят обеспечить выполнение показателей своего подразделения.То есть у них, например, есть метрика — принимать решения по 10 заявкам в день, и они озабочены соблюдением этой метрики.
Их боль — ошибки пользователей, из-за которых все ломается.
Программное обеспечение несовершенно и не предотвращает ошибок пользователей, но ОО хотят, чтобы их специалисты совершали ошибки реже.
То есть нужно дать им инструмент, который облегчит жизнь.
Владельцы бизнеса
Очевидно, они владеют бизнесом и борются за лучшее обслуживание клиентов.Их проблема в сложных бизнес-процессах — сложно за всем уследить (особенно в банке) и быстро перестроить процессы, чтобы решения принимались быстрее.
Как правильно слушать пользователей
Наши команды разработчиков активно работают с пользователями (помните, что пользователи — это другие сотрудники банка, а не клиенты).У нас есть общие чаты и периодические созвоны, где мы обсуждаем, что нужно друг другу.
Регулярно синхронизируйте
Sync — это место, где вы можете быстро получить отзывы и предложения по новым функциям.
Потому что сотрудники банка большую часть времени используют продукт, который вы производите, и знают, чего им не хватает.
Запишите проблемы
Проблемы будут всегда, особенно в продуктах на стадии MVP. Это приводит к недовольству пользователей, ошибкам и неучтенным случаям.Все это необходимо своевременно фиксировать, чтобы у пользователей не возникало ощущения, что их не слушают и игнорируют. Конечно, это не значит, что после каждого найденного вами бага нужно бросать все и заниматься только этим.
Но все должно быть открыто — пользователи должны знать, что они могут прийти к вам и озвучить проблему, а потом что-то с этим сделают. Также хорошо иметь цифры.
Пример.
Вы работаете над распознаванием документов.
Раньше данные вводились вручную, а теперь вы их узнаете, и это сократило время обработки на минуту.
В этот момент важно подойти к пользователям с цифрами и показать статистику — мол, мы сделали классную систему, и теперь вы экономите кучу времени и не делаете того, что должна делать машина.
Обсудить приоритеты
Нет необходимости защищать себя от пользователей какими-то замками или заборами, то есть они тоже должны в той или иной форме участвовать в расстановке приоритетов и влиять на то, какие из их болей и предложений следует решать в первую очередь.Пример На АРМ имеется очередь заявок, по которым специалистам необходимо принять решение.
У нас было такое пожелание от исполнителей, чтобы им было важно видеть название продукта в списке задач.
То есть сразу видно, где ипотека, где потребительский кредит и все.
После долгих бесед мы выяснили, что сотрудникам важно обрабатывать заявки на ипотеку раньше, чем на потребительские кредиты.
То есть у них есть какой-то встроенный приоритет, и когда они видят весь список, то могут спокойно выбирать.
Теперь список приложений выглядит так: 
Сначала вы видите пустой список.
Когда пользователь освобождается от предыдущей задачи, он нажимает кнопку «Взять новую задачу».
После этого система анализирует, какие товары сейчас находятся в очереди, на какие товары и что важнее.
И такая приоритетная задача возлагается на сотрудника.
Важно общаться с пользователями не на языке желаний, а на языке потребностей.
То есть они должны прийти к вам с тем, что у них болит, а не с тем, что им просто хочется иметь.
А иногда даже важно выйти в поля.
Давай поговорим об этом.
Что такое гемба
Гемба — японский подход к работе с пользователями.Звучит это примерно так: чтобы понять, как на самом деле используется услуга, зайдите туда, где услуга предоставляется, и во всем разберитесь.
Цель гемба — понять, как ваш продукт или услуга работают без прикрас в реальных условиях.
Я считаю, что гемба должна состоять из двух этапов.
Первое — подготовить пользователей к тому, что вы к ним придете.
Во-вторых, объясните, что это не тест, экзамен или аудит. Никого не уволят и не накажут – нужно просто работать в обычном режиме.
Выход из гемба также является трудным моментом, с которым обычно плохо справляются.
В конце концов, хорошей практикой считается выявление проблем и, в идеале, план их решения.
Пример Вы использовали компонент, в котором сотрудник заполняет адрес клиента вплоть до номера квартиры.
По идее это должно было ускорить процесс ввода, но по метрикам видно, что скорость не изменилась.
Гемба показывает, что все заполняется медленно — возможно, проблема на бэкенде, и проще все заполнить вручную, не дожидаясь подсказки.
Затем вы устраняете проблему и примерно сообщаете пользователю, когда ожидать исправления.
Важно, чтобы пользователь понимал, что его не бросили и что решение обязательно найдется.
Как слушать владельцев бизнеса
Владельцы бизнеса — это крупные менеджеры, которые отвечают за показатели ресурсов, процессов и продуктов.Поймите свою стратегию развития.
Важно понимать долгосрочную стратегию разработки продукта.
Ключевым заинтересованным сторонам должно быть очевидно, когда и каких результатов вы планируете достичь, с указанием примерных дат и этапов.
Если вы держите задачу по функции X в бэклоге, то важно, чтобы все заинтересованные стороны знали, что она у вас в планах, и вы планируете сделать ее в ближайшем будущем, а задача Y с более низким приоритетом будет выполнена через шесть месяцев.
.
Опять же — синхронизировать.
Это нужно делать регулярно и со всеми заинтересованными сторонами, чтобы не оказаться в ситуации, когда фичи для кого-то делаются сразу, а кто-то постоянно приходит с вопросами: «Когда это будет готово? А что я? Допустим, вместо вендорной системы мы делаем свой инструмент для сотрудников мидл-офиса.
Это снизит барьер входа для сотрудников, а также поможет и подскажет пользователю.
Понятно, что мы не сделаем этот продукт даже за квартал, это долгосрочная перспектива.
И очень важно, чтобы ключевая заинтересованная сторона знала, что мы все еще этим занимаемся, и видела декомпозицию проекта.
Как мы планируем в Ак Барс Банке.
Пример В финтехе все не очень гибко в плане работы.
Есть нормативные требования, есть клиенты из юристов, внутренняя и информационная безопасность и т. д. Поэтому даже внутри банковских подразделений необходимо собирать потребности и балансировать между банковским менталитетом и гибкими методологиями развития.
Вот почему мы используем квартальное планирование.
Это значит, что перед началом квартала мы собираем потребности, расставляем их по приоритетности, а затем планируем по согласованному со всеми заинтересованными сторонами списку приоритетов — детализируем их, разбиваем на задачи и проверяем зависимости.
А потом все снова.
Конечно, бывают неожиданные изменения на рынке или внутри процессов, поэтому иногда приходится все перестраивать.
Но в целом у нас есть письменный процесс планирования, которым пользуются все.
Поэтому заинтересованные стороны понимают, куда обращаться, если вам больно, как выбираются задачи, какие сроки и как бороться, чтобы вашу задачу взяли на себя за квартал.
Как сформулировать потребности
Грамотно сформулированная потребность должна содержать несколько пунктов.Гипотеза ценности .
Это описание того, почему мы выполняем задачу, какую ценность для бизнеса мы хотим получить.
Годовая метрика.
Стандартный индикатор, позволяющий ранжировать задачи между собой.
То есть, условно говоря, Малик предложил идею 1, которая поможет заработать 10 миллионов за год, а у меня есть идея 2, которая позволит заработать 20 миллионов за год. Моя идея, вероятно, победит по умолчанию.
Ведущие показатели.
Они нужны, чтобы понимать, что потребность позволит достичь результата.
Например, если мы выполняем задачи по привлечению партнера, который даст нам 1000 новых выпущенных карт, то ведущей метрикой являются потенциальные заявки на карты.
То есть, если мы понимаем, что у нас нет 1000 потенциальных заявок на карты в качестве входных данных, то 1000 проблем может никогда не произойти.
Поэтому мы тоже стараемся фиксировать опережающие метрики, чтобы в течение года понять, идем ли мы вообще туда.
Значение показателя .
Мы измеряем финансовый эффект, чтобы по конкретной фиче понять, сколько денег она заработала.
Критерии приемки.
Чтобы все понимали, что должно получиться в итоге.
То есть если это MVP, то мы сразу обсудим, в каком формате будет проходить запуск.
Если заказчик хочет полноценный процесс «под ключ», здесь тоже все должно быть сформулировано.
Чтобы результат оказался не таким, каким вроде бы они его сделали, но это не то и так далее.
Как работать со всеми, чтобы не было больно
Это то, что необходимо для продуктивной работы со всеми заинтересованными сторонами.Зафиксируйте правила создания и ведения бэклога.
Задел – это не какие-то тайные знания за семью печатями; он должен быть доступен всем, от пользователей до основных заинтересованных сторон.
Обновите свой бэклог.
Нет смысла собирать задачи на год вперед, уходить в глубокую защиту и целый год делать что-то непонятное, не обращаясь к пользователю и не запуская новые функции.
Шаблон бэклога можно вести в разных инструментах — мы используем общедоступную доску, а для визуализации бэклога за квартал для команды и заинтересованных сторон — доску в Miro. Это может выглядеть примерно так: 
Рассмотрите приоритеты задач.
Создавая бэклог, не нужно стараться сделать одну деталь идеальной, чтобы от нее летели искры.
Лучше определитесь, какова ваша цель.
А если у вас два процесса, один из которых отлично работает, а второй барахлит, то, наверное, нет смысла вылизывать первый — лучше починить второй.
Дополнительным моментом является то, что система расстановки приоритетов должна быть максимально ориентирована на приоритеты компании.
В конце я хочу вернуться к рекламному стенду и поделиться интересным видео, которое мне попалось.
Не становитесь рекламным стендом и постройте систему так, чтобы пользователи могли легко с вами взаимодействовать, а другие заинтересованные стороны могли вам доверять и понимать, кто, что и почему делает в компании.
И тогда все будет хорошо.
Теги: #Управление разработкой #Управление проектами #разработка #Управление продуктом #никто не читает теги #бэклог #финтех #хаос
-
Видеообзор Фройо
19 Oct, 24 -
Инкапсулируйте Это
19 Oct, 24 -
Как Продавать В 12 Раз Выгоднее Конкурентов?
19 Oct, 24
