Чем проект банковского мобильного приложения отличается от других? Та же работа с заказчиком, уточнение и описание требований, проектирование функциональностей, согласования ТЗ… Но так кажется только на первый взгляд.
Меня зовут Алиса Ковыршина, я — аналитик в компании Surf, работаю с e-com и банковскими проектами. В статье обсудим основные моменты в разработке мобильного банкинга, с которыми сложнее и дольше всего справляться.
Я буду рассказывать о том, с чем столкнулась при работе с крупным системообразующим банком. Когда я подключилась к этому проекту, в Surf над ним работали уже около трёх лет: приходилось «по ходу» вникать в процессы и стараться улучшить их.
Старт работы
Когда я впервые столкнулась с банковским проектом, оказалось, что всё не так очевидно и скоуп работ отличается от привычного. Пришлось проделать много подготовительной работы:
Проанализировать разные банковские приложения, чтобы понять их структуру.
Изучить стандарты, по которым формируются экраны и юзер-флоу: от НСПК, Центробанка.
Поэкспериментировать с моделями разработки ПО.
Разобраться с регуляторными задачами, которые нужно выполнять точно в срок.
Изучить специфичный формат банковских требований.
Многоуровневая система согласования ТЗ и количество ЛПР
Одна из основных особенностей банковских проектов — многоуровневая система согласования технических заданий (ТЗ) и количество ответственных лиц со стороны банка, принимающих решение (ЛПР).
Если в e-com проектах чаще всего достаточно согласовать ТЗ с представителем или, как максимум, несколькими представителями со стороны заказчика, то в банке, как правило, согласование происходит через несколько подразделений. Хотя такой долгий процесс согласований бывает не только в банках.
У меня на проекте со стороны банка была отдельная команда по каждой фиче. С каждой командой по фиче — своя переписка и регулярные созвоны.
Получать согласование нужно было от:
бизнеса,
технического отдела,
проджект-менеджера со стороны банка,
продакт оунера со стороны банка,
внешнего регулятора, если задача регуляторная. Например, у НСПК — Национальной системы платёжных карт — для функциональностей типа СБП (Системы быстрых платежей).
Иногда один представитель банка выполнял сразу несколько ролей: это, конечно, облегчало задачу.
Большое количество ЛПР влечёт дополнительные трудности:
Эффект «сломанного телефона».
Долгие согласования.
Замечания, поступающие с разных слоев и противоречащие друг другу.
Как с этим работать
Задача компании-разработчика — отвечать за целостность продукта: именно мы видим общую картину приложения и можем подсветить расхождения с паттернами приложения и переиспользуемыми элементами, рассинхрон в логике.
Нам помогли:
Еженедельные статус-встречи с представителями банка: обычно в них участвуют PM со стороны банка, продакт оунер по фиче или аналитик, представитель отдела тестирования, бэкенда и системный аналитик от банка.
Переписка может затеряться, её проще игнорировать. Созвоны — особенно еженедельные — помогают намного быстрее отследить отсутствие согласующего лица, обозначить существующие проблемы, увидеть, что решение вопроса «застряло» на каком-то этапе.
Письменные итоги встреч. Обязательно получить подтверждение корректности со всех сторон. Такие правила подстегивают и регулируют погружение в задачу со стороны всех лиц.
Обозначение чётких сроков согласования фичи: ТЗ согласовано X числа, сборки будут готовы Y числа, иначе сроки сдвигаются. Очень действенный способ, когда заказчик на реальном примере понимает, что влечет за собой затягивание согласования с их стороны.
После согласования ТЗ все остальные работы брать доработками. Доработки — это задачи с дополнительной логикой, которые рассматриваются и оцениваются отдельно, поверх согласованных фич, если в процессе разработки или тестирования выясняется, что заказчик хочет добавить что-то новое.
Если накидывать требования «по ходу», время выполнения задачи может увеличиться. Это вызывает стресс у разработчиков, появляется ощущение, что «мы не попали в оценку». Хотя на самом деле дополнительные требования — это отдельные мини-задачи, которые не входили в изначальную оценку.
Правило «остальные работы брать доработками» помогает всем ответственным лицам глубже погрузиться в контекст задачи и внимательнее отнестись к согласованию изначального ТЗ.
Сложный формат поступающих требований
Обычно в банковских проектах требования поступают в виде внушительного документа: в нём сформулированы ожидания стейкхолдеров от системы в терминах требований к бизнес-процессам.
Банковские бизнес-требования (БТ) — довольно специфичный вид требований. К некоторым особенностям сложно привыкнуть.
Требования описаны ко всем системам, принимающим участие в разработке мобильного приложения: фронту, бэку, внутреним системам, безопасности. Из-за большого числа перемешанных требований появляются проблемы:
На изучение и анализ БТ уходит много времени.
Аналитику нужно найти и определить все требования, которые относятся именно к его системе.
Редко можно встретить подробное описание требований для каждой из систем: оно, скорее, поверхностное, так что иногда приходится выяснять требования почти с нуля.
Много обновлений: нужно следить за версиями документа. Обычно оригиналы БТ хранятся и редактируются во внутренних системах банка. Нам их отправляют на финальном этапе проработки.
Иногда требования присылаются в готовом виде, но конечно, так бывает не всегда: есть большие фичи со сложной логикой, которая дописывается «на ходу». В таком случае банк может что-то поменять, но нам об этом не сообщить.
Полезно попросить выделить со стороны банка ответственного сотрудника по фиче или в целом по всему приложению, который сможет сообщать о выпуске новой версии БТ. У меня на проекте за это отвечал PM от банка, который всегда находится в контексте происходящего.
Большое количество нефункциональных требований. В БТ стандартно содержатся общие положения, миссии, задачи, критерии оценки достижения целей, ожидаемые изменения в бизнес-процессах. Все это создает «информационный шум», может запутать аналитика и увести в сторону от необходимой логики.
Как с этим работать
Самый важный этап после изучения БТ — собрать всех заинтересованных лиц и подрядчиков со сторонних систем на общем созвоне и «пробежаться» по логике. Обычно всплывает много нюансов. Заказчику и подрядчикам становятся более понятны зоны ответственности каждого. Это помогает и на будущем этапе отладки: если возникнет проблема, все понимают, к какой системе она относится. Значит, решить её значительно проще и быстрее, чем обращаться ко всем заинтересованным лицам в поиске решения.
Удобное правило: на этапе инициации фичи выписать все требования, которые, на ваш взгляд, относятся к вашей части приложения. Попросить банк подтвердить, что вы правильно поняли требуемую функциональность.
Полезные штуки, которые спасают не только в банковских приложениях, но и в любых крупных проектах и фичах, — это схемы. Можно использовать любой удобный инструмент, который поможет упростить и сделать очевидной для понимания логику. Мы пользуемся BPMN-схемами.
Пример BPMN-схемы Если в БТ есть моменты, которые описаны неоднозначно, лучше расписать их максимально простым языком и уточнить, такая ли логика подразумевалась.
Регуляторные задачи
Регуляторные задачи — задачи, которые поступают в банк от регулятора: обычно им выступает Центробанк или федеральные органы. Выполнять их обязательно: за невыполнение в нужный срок у банка могут отозвать лицензию. К таким задачам можно отнести УФЭБС (Унифицированные форматы электронных банковских сообщений), СБП (Систему быстрых платежей), Биометрию.
Обычно о «регуляторках» сообщает сам банк, причём именно перед дедлайном. Чтобы не допустить срочных задач, которые нужно добавить в спринт любыми способами, можно при инициации спринта уточнять у банка наличие регуляторных задач: возможно, о части из них будет известно заранее.
Основные проблемы, которая появляются из-за регуляторок:
Поздняя инициация регуляторных задач.
Строгий дедлайн, который никак нельзя просрочить.
Сложность фич и жёсткие правила, от которых нельзя отступать, даже если они не вписываются в концепцию приложения. Под жесткостью требований понимается соответствие определенным стандартам банковских приложений, общим правилам при проектировании фичи, которых нужно придерживаться, чтобы пройти проверку федеральными органами.
Примеры
Расскажу, как мы в Surf справлялись с биометрией — это была регуляторная задача. Мы работали одновременно над несколькими банковскими проектами, у в каждом использовались разные подходы к реализации фичи: на одном — встраиваемая библиотека CryptoSDK, на другом — приложение МП ЕБС.
Собраться командами и вместе обсудить логику на старте у нас не получилось: сроки реализации были разные. Зато команды, которые приступали к фиче позже, могли уточнить сложные и спорные моменты у тех, кто фичу уже реализовал.
Например, после общения с другой командой мы решили попробовать МП ЕБС. Это помогло продвинуться с реализацией, потому что наш подход был сложно реализуемым, а команда, приступившая к фиче позже всех, начала проектирование с уже имеющейся базы. Поэтому обмен опытом круто сокращает время реализации и даёт возможность продумать кейсы, которые не лежат на поверхности.
Давайте помогать друг другу решать сложные задачи. Подписывайтесь на наш телеграм-канал Surf on data waves: там мы делимся своими кейсами и опытом.
Кидайте в комменты к статье, какие полезные телеграм-каналы по аналитике читаете вы.
Ещё один яркий пример — фичи по СБП: они регулируются НСПК.
Чтобы функциональность была реализована верно и прошла все этапы тестирования корректно, необходимо придерживаться строгих правил:
расположение элементов на экране,
отступы,
наименования,
количество полей.
Конечно, все эти моменты учитывает и прорабатывает дизайнер. Но аналитик, как лицо, которое видит общую картину функциональности, тоже должен их контролировать.
Мы на проекте столкнулись с проблемой: паттерны дизайна в некоторых фичах расходились с требованиями регулятора, а ещё нужно было добавлять логику в уже перегруженный экран. Это были именно требования НСПК, которые финально согласуют функциональность. Поэтому нам пришлось принять утвержденное решение и постараться структурировать элементы, чтобы немного улучшить визуал.
Как с этим работать
Хочется обозначить, что от регуляторных задач «страдает» не только команда разработки, но и сам банк. Они могут возникать по ходу изменения внешней и внутренней политики, изменений в экономике. Например, добавление или удаление новой валюты, изменение ставки по кредитам, поддержка различных видов платежных ссылок. Иногда часть разрабатываемых фич может стать неактуальной в процессе разработки, если регулятор поменял требования.
Избежать выполнения регуляторных задач нельзя, но можно предпринять меры: регуляторки уже не будут казаться чем-то страшным :)
Что делаем:
В начале спринта САМИ уточняем у банка, планируются ли регуляторные задачи. Если чувствуем, что нужен рисёрч со стороны банка, ставим себе «на заметку» и пингуем по этому вопросу.
Строго фиксируем оговоренные требования на первоначальном этапе и создаем скоуп задач. Если прилетают новые задачи, выносим новой итерацией.
Для подстраховки планируем в спринте дополнительное время на возможные регуляторные задачи.
Следим за общими паттернами в приложении. Обозначаем, если новые требования «ломают» общую логику или от регулятора приходят специфичные требования. Задача — минимизировать «ущерб», если невозможно сделать иначе.
Фиксируем API с командой бэкенда. После добавления запросов стараемся проверить их, например, через Postman, чтобы на этапе разработки минимизировать неожиданные ответы с сервера и разобраться с такими кейсами заранее.
Если компания разрабатывает несколько банковских проектов, полезно будет объединиться командами, разобраться с логикой, выстроить общие паттерны по работе с регуляторками. Время на проработку задач это точно сократит.
Проблема с доступами и тестовыми данными
Для тестирования приложения желательно предусмотреть все потенциально необходимые доступы, которые нужно запросить у банка. Обычно это делает менеджер проекта, но аналитик, как человек, максимально погруженный в задачу, может сразу продумать этот этап и подсветить сложности в тестировании. Тогда не придётся тратить на это время на этапе тестирования: сразу будет понятно, как проверять фичу.
Примеры
Тестирование переводов по QR-коду на разных средах. Полезно будет разобраться, как генерируются коды, сформировать список QR-кодов для будущих проверок. Мы, например, сразу не поняли, что тестовые QR-коды на тестовом и продовом серверах формируются по-разному. Вопрос появился на позднем этапе, но у нас получилось быстро его решить.
Тестирование биометрии. Здесь процесс более сложный: нужно разобраться с тестовым приложением для сдачи биометрических данных, с работой приложения МП ЕБС, которое идентифицирует потенциального пользователя. Для сдачи тестовых биометрических данных используются специальные сервера, работающие по инструкции. При этом они работают нестабильно и повлиять на этот процесс глобально ни мы, ни банк не можем. Нам, например, понадобилось около месяца, чтобы окончательно сдать тестовые данные для биометрии.
Проблема с доступами встречается часто и не дает синхронизировать обновления по фиче со стороны бэка и фронта: например, в ситуации, когда обновления бэка поставлены на тестовую среду, но она недоступна. Конечно, в таком случае спасают моковые сервисы, но только если бэк будет реализован по согласованным договоренностям.
Как с этим работать
Сообщать тестировщикам о возможных сложностях тестирования заранее, чтобы облегчить задачу на последующих этапах.
Найти всех ответственных лиц, которые как-то могут повлиять на работу тестовых сред. Желательно сразу информировать их о проблемах.
6 советов аналитику для работы над банковским приложением
Как вы уже поняли, на банковских проектах работать непросто. Они имеют специфические особенности, к которым нужно привыкать. Я надеюсь, эта статья поможет вам с ними разобраться и быть готовыми.
Напоследок ловите топ советов от меня, которые важно держать в голове. Возможно, это поможет не только в мобильном банкинге :)
При старте работы над фичей важно понять всех ЛПР и их роли. Это поможет уточнять требования и согласовывать ТЗ быстрее.
Старайтесь максимально понять и разобрать поступающие требования, декомпозировать их. Не пренебрегайте совместными созвонами с командой банка для проработки логики.
Старайтесь заранее понять, как можно пощупать реализацию и какие сложности могут возникнуть на этапе тестирования, чтобы подсветить их тестировщикам: в банковских приложениях реализация часто сложнее, чем в e-com.
Не забывайте о регуляторных задачах. Планируйте в спринте время для таких задач, закладывайте риски. Совместно с другими командами, разрабатывающими банковские приложения у вас в компании, выделяйте общие паттерны для работы с регуляторками.
Следите за версионностью требований. Фиксируйте оговоренные требования на первоначальном этапе. Новые задачи лучше выносить новой итерацией.
Будьте готовы к тому, что даже если вы будете придерживаться этих правил и стараться предусмотреть все сложности, это не гарантирует вам того, что сроки не будут сорваны и состав релиза не поменяется в процессе разработки. Темп работы в банковских проектах бывает довольно рваный: под это нужно подстраиваться и по процессам и морально :)
Например, когда задач очень много, важно спланировать время на проектирование всех фич. Бывает наоборот: задачи становятся на стоп и непонятно, что делать. Нужно заранее создать бэклог из задач по улучшению функциональностей, рефакторингу ТЗ, проработке новых процессов для такого случая — в зависимости от того, что в конкретный момент требуется проекту.
Кейсы и лучшие практики в области системной и бизнес-аналитики, новости, вакансии и стажировки Surf — в телеграм-канале Surf BA Team. Присоединяйтесь!
Больше кейсов команды Surf ищите на сайте >>
