Чем проект банковского мобильного приложения отличается от других? Та же работа с заказчиком, уточнение и описание требований, проектирование функциональностей, согласования ТЗ… Но так кажется только на первый взгляд. 

Меня зовут Алиса Ковыршина, я — аналитик в компании Surf, работаю с e-com и банковскими проектами. В статье обсудим основные моменты в разработке мобильного банкинга, с которыми сложнее и дольше всего справляться.

Я буду рассказывать о том, с чем столкнулась при работе с крупным системообразующим банком. Когда я подключилась к этому проекту, в Surf над ним работали уже около трёх лет: приходилось «по ходу» вникать в процессы и стараться улучшить их. 

Старт работы

Когда я впервые столкнулась с банковским проектом, оказалось, что всё не так очевидно и скоуп работ отличается от привычного. Пришлось проделать много подготовительной работы:

• Проанализировать разные банковские приложения, чтобы понять их структуру.

• Изучить стандарты, по которым формируются экраны и юзер-флоу: от НСПК, Центробанка.

• Поэкспериментировать с моделями разработки ПО.

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

• Изучить специфичный формат банковских требований.

Многоуровневая система согласования ТЗ и количество ЛПР

Одна из основных особенностей банковских проектов — многоуровневая система согласования технических заданий (ТЗ) и количество ответственных лиц со стороны банка, принимающих решение (ЛПР).

Если в e-com проектах чаще всего достаточно согласовать ТЗ с представителем или, как максимум, несколькими представителями со стороны заказчика, то в банке, как правило, согласование происходит через несколько подразделений. Хотя такой долгий процесс согласований бывает не только в банках. 

У меня на проекте со стороны банка была отдельная команда по каждой фиче. С каждой командой по фиче — своя переписка и регулярные созвоны.

Получать согласование нужно было от:

1. бизнеса,

2. технического отдела,

3. проджект-менеджера  со стороны банка,

4. продакт оунера со стороны банка,

5. внешнего регулятора, если задача регуляторная. Например, у НСПК — Национальной системы платёжных карт — для функциональностей типа СБП (Системы быстрых платежей).

Иногда один представитель банка выполнял сразу несколько ролей: это, конечно, облегчало задачу.

Большое количество ЛПР влечёт дополнительные трудности:

1. Эффект «сломанного телефона».

2. Долгие согласования.

3. Замечания, поступающие с разных слоев и противоречащие друг другу.

Как с этим работать

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

Нам помогли:

• Еженедельные статус-встречи с представителями банка: обычно в них участвуют PM со стороны банка, продакт оунер по фиче или аналитик, представитель отдела тестирования, бэкенда и системный аналитик от банка.

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

• Письменные итоги встреч. Обязательно получить подтверждение корректности со всех сторон. Такие правила подстегивают и регулируют погружение в задачу со стороны всех лиц.

• Обозначение чётких сроков согласования фичи: ТЗ согласовано X числа, сборки будут готовы Y числа, иначе сроки сдвигаются. Очень действенный способ, когда заказчик на реальном примере понимает, что влечет за собой затягивание согласования с их стороны.

• После согласования ТЗ все остальные работы брать доработками. Доработки — это задачи с дополнительной логикой, которые рассматриваются и оцениваются отдельно, поверх согласованных фич, если в процессе разработки или тестирования выясняется, что заказчик хочет добавить что-то новое. 

Если накидывать требования «по ходу», время выполнения задачи может увеличиться. Это вызывает стресс у разработчиков, появляется ощущение, что «мы не попали в оценку». Хотя на самом деле дополнительные требования — это отдельные мини-задачи, которые не входили в изначальную оценку. 

Правило «остальные работы брать доработками» помогает всем ответственным лицам глубже погрузиться в контекст задачи и внимательнее отнестись к согласованию изначального ТЗ. 

Сложный формат поступающих требований

Обычно в банковских проектах требования поступают в виде внушительного документа: в нём сформулированы ожидания стейкхолдеров от системы в терминах требований к бизнес-процессам.

Банковские бизнес-требования (БТ) — довольно специфичный вид требований. К некоторым особенностям сложно привыкнуть. 

Требования описаны ко всем системам, принимающим участие в разработке мобильного приложения: фронту, бэку, внутреним системам, безопасности. Из-за большого числа перемешанных требований появляются проблемы:

1. На изучение и анализ БТ уходит много времени.

2. Аналитику нужно найти и определить все требования, которые относятся именно к его системе. 

3. Редко можно встретить подробное описание требований для каждой из систем: оно, скорее, поверхностное, так что иногда приходится выяснять требования почти с нуля.

Много обновлений: нужно следить за версиями документа. Обычно оригиналы БТ хранятся и редактируются во внутренних системах банка. Нам их отправляют на финальном этапе проработки.

Иногда требования присылаются в готовом виде, но конечно, так бывает не всегда: есть большие фичи со сложной логикой, которая дописывается «на ходу». В таком случае банк может что-то поменять, но нам об этом не сообщить.

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

Большое количество нефункциональных требований. В БТ стандартно содержатся общие положения, миссии, задачи, критерии оценки достижения целей, ожидаемые изменения в бизнес-процессах. Все это создает «информационный шум», может запутать аналитика и увести в сторону от необходимой логики.

Как с этим работать

1. Самый важный этап после изучения БТ — собрать всех заинтересованных лиц и подрядчиков со сторонних систем на общем созвоне и «пробежаться» по логике. Обычно всплывает много нюансов. Заказчику и подрядчикам становятся более понятны зоны ответственности каждого. Это помогает и на будущем этапе отладки: если возникнет проблема, все понимают, к какой системе она относится. Значит, решить её значительно проще и быстрее, чем обращаться ко всем заинтересованным лицам в поиске решения.

2. Удобное правило: на этапе инициации фичи выписать все требования, которые, на ваш взгляд, относятся к вашей части приложения. Попросить банк подтвердить, что вы правильно поняли требуемую функциональность.

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

   

4. Если в БТ есть моменты, которые описаны неоднозначно, лучше расписать их максимально простым языком и уточнить, такая ли логика подразумевалась.

Регуляторные задачи

Регуляторные задачи — задачи, которые поступают в банк от регулятора: обычно им выступает Центробанк или федеральные органы. Выполнять их обязательно: за невыполнение в нужный срок у банка могут отозвать лицензию. К таким задачам можно отнести УФЭБС (Унифицированные форматы электронных банковских сообщений), СБП (Систему быстрых платежей), Биометрию.

Обычно о «регуляторках» сообщает сам банк, причём именно перед дедлайном. Чтобы не допустить срочных задач, которые нужно добавить в спринт любыми способами, можно при инициации спринта уточнять у банка наличие регуляторных задач: возможно, о части из них будет известно заранее.

Основные проблемы, которая появляются из-за регуляторок:

1. Поздняя инициация регуляторных задач.

2. Строгий дедлайн, который никак нельзя просрочить.

3. Сложность фич и жёсткие правила, от которых нельзя отступать, даже если они не вписываются в концепцию приложения. Под жесткостью требований понимается соответствие определенным стандартам банковских приложений, общим правилам при проектировании фичи, которых нужно придерживаться, чтобы пройти проверку федеральными органами.

Примеры

Расскажу, как мы в Surf справлялись с биометрией — это была регуляторная задача. Мы работали одновременно над несколькими банковскими проектами, у в каждом использовались разные подходы к реализации фичи: на одном — встраиваемая библиотека CryptoSDK, на другом — приложение МП ЕБС. 

Собраться командами и вместе обсудить логику на старте у нас не получилось: сроки реализации были разные. Зато команды, которые приступали к фиче позже, могли уточнить сложные и спорные моменты у тех, кто фичу уже реализовал.

Например, после общения с другой командой мы решили попробовать МП ЕБС. Это помогло продвинуться с реализацией, потому что наш подход был сложно реализуемым, а команда, приступившая к фиче позже всех, начала проектирование с уже имеющейся базы. Поэтому обмен опытом круто сокращает время реализации и даёт возможность продумать кейсы, которые не лежат на поверхности.

Давайте помогать друг другу решать сложные задачи. Подписывайтесь на наш телеграм-канал Surf on data waves: там мы делимся своими кейсами и опытом.

Кидайте в комменты к статье, какие полезные телеграм-каналы по аналитике читаете вы. 

Ещё один яркий пример — фичи по СБП: они регулируются НСПК. 

Чтобы функциональность была реализована верно и прошла все этапы тестирования корректно, необходимо придерживаться строгих правил:

• расположение элементов на экране, 

• отступы, 

• наименования, 

• количество полей. 

Конечно, все эти моменты учитывает и прорабатывает дизайнер. Но аналитик, как лицо, которое видит общую картину функциональности, тоже должен их контролировать.

Мы на проекте столкнулись с проблемой: паттерны дизайна в некоторых фичах расходились с требованиями регулятора, а ещё нужно было добавлять логику в уже перегруженный экран. Это были именно требования НСПК, которые финально согласуют функциональность. Поэтому нам пришлось принять утвержденное решение и постараться структурировать элементы, чтобы немного улучшить визуал.

Как с этим работать

Хочется обозначить, что от регуляторных задач «страдает» не только команда разработки, но и сам банк. Они могут возникать по ходу изменения внешней и внутренней политики, изменений в экономике. Например, добавление или удаление новой валюты, изменение ставки по кредитам, поддержка различных видов платежных ссылок. Иногда часть разрабатываемых фич может стать неактуальной в процессе разработки, если регулятор поменял требования.

Избежать выполнения регуляторных задач нельзя, но можно предпринять меры:  регуляторки уже не будут казаться чем-то страшным :)

Что делаем:

• В начале спринта САМИ уточняем у банка, планируются ли регуляторные задачи. Если чувствуем, что нужен рисёрч со стороны банка, ставим себе «на заметку» и пингуем по этому вопросу.

• Строго фиксируем оговоренные требования на первоначальном этапе и создаем скоуп задач. Если прилетают новые задачи, выносим новой итерацией.

• Для подстраховки планируем в спринте дополнительное время на возможные регуляторные задачи. 

• Следим за общими паттернами в приложении. Обозначаем, если новые требования «ломают» общую логику или от регулятора приходят специфичные требования. Задача — минимизировать «ущерб», если невозможно сделать иначе.

• Фиксируем API с командой бэкенда. После добавления запросов стараемся проверить их, например, через Postman, чтобы на этапе разработки минимизировать неожиданные ответы с сервера и разобраться с такими кейсами заранее.

• Если компания разрабатывает несколько банковских проектов, полезно будет объединиться командами, разобраться с логикой, выстроить общие паттерны по работе с регуляторками. Время на проработку задач это точно сократит.

Проблема с доступами и тестовыми данными

Для тестирования приложения желательно предусмотреть все потенциально необходимые доступы, которые нужно запросить у банка. Обычно это делает менеджер проекта, но аналитик, как человек, максимально погруженный в задачу, может сразу продумать этот этап и подсветить сложности в тестировании. Тогда не придётся тратить на это время на этапе тестирования: сразу будет понятно, как проверять фичу.

Примеры

1. Тестирование переводов по QR-коду на разных средах. Полезно будет разобраться, как генерируются коды, сформировать список QR-кодов для будущих проверок. Мы, например, сразу не поняли, что тестовые QR-коды на тестовом и продовом серверах формируются по-разному. Вопрос появился на позднем этапе, но у нас получилось быстро его решить.

2. Тестирование биометрии. Здесь процесс более сложный: нужно разобраться с тестовым приложением для сдачи биометрических данных, с работой приложения МП ЕБС, которое идентифицирует потенциального пользователя. Для сдачи тестовых биометрических данных используются специальные сервера, работающие по инструкции. При этом они работают нестабильно и повлиять на этот процесс глобально ни мы, ни банк не можем. Нам, например, понадобилось около месяца, чтобы окончательно сдать тестовые данные для биометрии.

Проблема с доступами встречается часто и не дает синхронизировать обновления по фиче со стороны бэка и фронта: например, в ситуации, когда обновления бэка поставлены на тестовую среду, но она недоступна. Конечно, в таком случае спасают моковые сервисы, но только если бэк будет реализован по согласованным договоренностям.

Как с этим работать

• Сообщать тестировщикам о возможных сложностях тестирования заранее, чтобы облегчить задачу на последующих этапах.

• Найти всех ответственных лиц, которые как-то могут повлиять на работу тестовых сред. Желательно сразу информировать их о проблемах.

6 советов аналитику для работы над банковским приложением

Как вы уже поняли, на банковских проектах работать непросто. Они имеют специфические особенности, к которым нужно привыкать. Я надеюсь, эта статья поможет вам с ними разобраться и быть готовыми.

Напоследок ловите топ советов от меня, которые важно держать в голове. Возможно, это поможет не только в мобильном банкинге :)

1. При старте работы над фичей важно понять всех ЛПР и их роли. Это поможет уточнять требования и согласовывать ТЗ быстрее.

2. Старайтесь максимально понять и разобрать поступающие требования, декомпозировать их. Не пренебрегайте совместными созвонами с командой банка для проработки логики.

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

4. Не забывайте о регуляторных задачах. Планируйте в спринте время для таких задач, закладывайте риски. Совместно с другими командами, разрабатывающими банковские приложения у вас в компании, выделяйте общие паттерны для работы с регуляторками.

5. Следите за версионностью требований. Фиксируйте оговоренные требования на первоначальном этапе. Новые задачи лучше выносить новой итерацией.

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

   Например, когда задач очень много, важно спланировать время на проектирование всех фич. Бывает наоборот: задачи становятся на стоп и непонятно, что делать. Нужно заранее создать бэклог из задач по улучшению функциональностей, рефакторингу ТЗ, проработке новых процессов для такого случая — в зависимости от того, что в конкретный момент требуется проекту.