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