Рсхб

_{Соавтор:Кузнецова Юлия Андреевна - UX-писатель Экосистемы РСХБ}

Каким должен быть дизайнер в банке, чтобы и продукт хороший создавал, и коллеги не жаловались. Смотрим через призму софт-навыков вместе с UX-дизайнерами РСХБ.

#1 Коммуникабельность: не просто коллега человек

Дизайнер отличная профессия для интровертов. Рисуешь интерфейсы, слушаешь музыку, ни с кем не общаешься На самом деле, нет!

Работая в банке, ты участвуешь в большом количестве созвонов, слушаешь коллег, предлагаешь свои идеи. Споришь. Много споришь. Убеждаешь. Идешь на компромисс. Вместе с тобой над продуктом работают много других сотрудников продакт-менеджеры, аналитики, разрабы, редакторы, юристы ты должен уметь услышать каждого и найти общий язык.

Общаясь с разными специалистами, ты лучше понимаешь, как устроена работа на проекте и начинаешь понимать, что из твоих решений сработает и поможет банковским клиентам, а что вряд ли будет реализовано и сделано разве что покрасоваться на Dribbble.

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

#2 Презентация: готов объяснить свою работу

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

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

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

#3 Аналитика: думает не только о красоте

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

Хороший дизайнер постоянно анализирует, как пользователи будут взаимодействовать с интерфейсом, удобно ли ему переводить деньги другу, перечислять зарплату сотрудникам или подавать заявку на кредит.

С одной стороны, ты должен на интуитивном уровне понимать психологию взаимодействия с интерфейсом. А с другой всегда остаешься скептиком и тестировать свои гипотезы. Порой пользователи воспринимают ту или иную функцию абсолютно непредсказуемо и не понимают твоей задумки. Одна только фраза Мне нравится. Думаю пользователям понравится тоже не поможет. Нужна аналитика. Много аналитики.

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

#4 Понимание бизнес-процесса: переводит с банковского языка на человеческий

Юный дизайнер: мастерски работает в Фигме, любит компоненты, боготворит филигранную верстку.

Продвинутый дизайнер: понимает, как устроен бизнес и финансы.

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

Дизайнер понимает интересы обеих сторон и знает, одна маленькая ошибка может привести как к финансовым потерям, так и к потери доверия пользователей. Зная это, он скрупулезно изучает сферу, в которой крутится. Работая над банком для бизнеса, дизайнер сам попробует зарегистрировать ИП, а разрабатывая приложение для инвестиций собирает свой инвестиционный портфель.

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

#5 Любознательность: постоянно учится новому

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

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

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

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

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

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

Итак, в далёком уже 2015 году мы получили задание собрать команду для полного цикла разработки, начиная с аналитики и заканчивая тестированием и внедрением. До этого большую часть работ развития выполняли внешние вендоры, а сил собственных разработчиков хватало только на небольшие доработки напильником.

Готовим аэродром

Первое, о чём начинают задумываться при открытии регионального центра, А где, собственно?.

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

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

В первый раз, когда мы столкнулись с проблемой выбора места для регионального центра разработки, нам повезло: нам дали на выбор аж три города Хабаровск, Уфа и Владимир. Местные филиалы РСХБ были готовы разместить наших сотрудников, избавляя нас от многих хозяйственных проблем. Справедливо полагая, что Хабаровск слишком далеко и в него не налетаешься, да и разница во времени не позволит работать единой командой, а Владимир, наоборот, настолько близок, что большинство грамотных специалистов наверняка уже переехали в Москву, мы выбрали золотую середину. Как впоследствии показало время середина и в самом деле была золотой. Этот центр не просто взлетел сейчас он самый крупный из наших самолётиков: если в начале в нём было всего три сотрудника, сейчас их более 300.

Запуск самолётика отчасти позволяет нам ускорить процесс создания и других региональных центров, когда на размещенные вакансии откликаются люди из других городов. Например, на запуск самолётика в Рыбинске откликнулись кандидаты из Пензы. Получается своеобразная цепная реакция: люди увидели, что РХСБ открывает региональные центры разработки, и стали предлагать свои услуги на опережение. Не только у нас был запрос на сотрудников, но и они сами искали возможность присоединиться к нам, даже создавали её там, где мы и не планировали. А когда в городе есть готовый работать костяк команды, нарастить её на месте уже проще.

Что же с офисами?

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

Всё же не в каждом региональном филиале банка есть свободное место для разработчиков, да и командам по мере роста становится тесно. Так, кстати, случилось и с первым самолётиком в Уфе этой большой команде довольно быстро пришлось подыскивать себе более просторное место.

Прошло пять лет, и самолётиков набралась уже целая эскадрилья они работают в 11 городах, и останавливаться на этом мы не собираемся.

Самолёт не взлетит без Капитана

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

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

Как выявить лидера? Обычно его видно сразу и не только по деятельности на местах, опыту или скилам. В нашей практике часто бывало так, что это не мы искали лидеров, а они сами нас находили. Собирали часть команды и предлагали создать на её основе новый самолётик. Именно так появились некоторые наши региональные центры. Конечно, в этом практически идеальном варианте есть и минус насколько легко капитан привёл команду, настолько же легко он сможет её увести, если что-то вдруг пойдёт не так. Но нам пока везло: потерь среди наших лидеров ещё не случалось, мы стараемся работать так, чтобы люди оставались с нами. Хотя бывали и непредвиденные ситуации.

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

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

Полёт нормальный?

Самолётик полетел а дальше что? Лидер лидером, но присмотр хорошего диспетчера и технических служб тоже важны.

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

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

Процесс работы с центрами непрерывен. И дело не только в наборе новых кадров, но и в развитии уже имеющихся. Рост сотрудника важная задача как для самих центров, так и для нас, потому что в выигрыше в итоге окажутся все. Чтобы помочь им в этом, мы постоянно обучаем людей, причём не только в регионах, но и, бывает, даже приглашаем сотрудников на обучение в Москву.

Что ещё нужно самолётикам для успешного полёта (ну и чтобы не свалиться в пике по ошибке)? Толковое управление. Когда команд так много и задач они решают ещё больше, важно понимать, кто чем занят, насколько загружен, с кем сейчас взаимодействует. В нашей практике бывает, что над одной задачей работают люди не только из разных команд, но и из разных городов. Так что в нашем случае Agile и ещё раз Agile.

Зачем это всё, или Человек существо социальное

А почему именно офисы? Не лучше ли нанимать сотрудников удалённо и не тратить ресурсы на аренду помещений? Сейчас, когда ковид заставил большинство айтишников поработать на удалёнке, я всё чаще слышу мнения, что региональные центры как структуры и не нужны вовсе.

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

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

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

В качестве послесловия

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

Мы снова начнём запускать самолётики.

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

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

Одной из главных сложностей стала проверка документов заявителя. Действительно ли они направлены от имени того юридического лица, которое указано в заявке? Как можно доверять скан-копиям или электронным выпискам без юридического подтверждения? Если с уже имеющимися в базе данных клиентами банка в период пандемии проблем не возникло (для них уже есть система дистанционного обслуживания), то для новых заявителей пришлось изобретать отдельный, полностью бесконтактный механизм работы с документами.

Начало работы: концепт

Разработку нового процесса мы запустили ещё в начале пандемии. Наш департамент информационных технологий предложил решение на базе механизма, которым уже пользуются 90 % юридических лиц и индивидуальных предпринимателей, юридически значимый электронный документооборот на базе операторов ЭДО. Это тот самый документооборот и те самые операторы, через которых большая часть организаций и предприятий направляет в ФНС отчётность и взаимодействует с энергосбытовыми компаниями по хозяйственным операциям. Это работает так: при подключении к оператору ЮЗД юридическое лицо или индивидуальный предприниматель получает усиленную квалифицированную электронную подпись (УКЭП) и по ней удостоверяющий центр идентифицирует представителя компании. После этого для банка отправитель документов становится связан с компанией, которую он представляет. Операторы ЭДО связаны роумингом, что позволяет получать заявки и документы от всех абонентов ЮЗД.

Реализация и подводные камни

Работу разбили на два этапа. На первом нужно было реализовать процесс получения от людей, ещё не являющихся клиентами банка, заявки на кредит и дать им возможность предоставить необходимые ЮЗД. На втором реализовать полностью дистанционное подписание кредитного договора с обеих сторон и приём на обслуживание нового клиента.

Этап 1. Создание процессов, нормативных документов, закупка лицензий и работ

В первую очередь нам пришлось пересмотреть всю нормативную документацию по дистанционной работе с ЮЗД.

Для взаимодействия с ФНС и другими контрагентами мы уже использовали ряд технических решений ЮЗД, представленных на рынке. Но процессы, использующие ЮЗД, не были централизованными и каждый региональный филиал банка проводил локальные конкурсы на закупку этих решений.

Для нового процесса мы подготовили техзадание на закупку новых лицензий, но главное на доработку системы под требования банка. Для реализации была выбрана компания Тензор. Вместе с её экспертами мы решили следующие задачи:

• согласовали новый бизнес-процесс;

• подключили работников банка к системе электронного документооборота;

• организовали удалённые рабочие места и настроили доступы к личным кабинетам;

• настроили и запустили бизнес-процесс согласно требованиям банка.

Всё это заняло у нас меньше двух месяцев в июне мы уже могли получать заявки и подтверждающие документы от клиентов дистанционно.

Этап 2. Подписание кредитного договора

Со сложностями мы столкнулись на втором этапе, когда организовывали возможность подписания кредитного договора. Процесс выглядит просто: получить договор, загрузить в ИС ЮЗДО, подписать УКЭП со стороны банка и со стороны клиента, направить на регистрацию в Росреестр (для договоров ипотеки) и положить в архив. Но на деле за каждым шагом есть своё но.

Получить договор

С бумагой всё понятно: распечатали, подписали, сдали на хранение, вывезли в архив. В архиве при должных условиях бумага хранится 2030 лет, и если пришёл запрос от контролирующих органов, то документ просто достают из архива, делают копию, заверяют и отправляют ответ. Не нужны никакие преобразования, распечатки и подборы шрифтов.

Кредитный же договор, подписанный только в электронном виде, это единственный документ, подтверждающий факт сделки. Он должен храниться в IT-инфраструктуре банка, причём в исходном электронном виде, включая все подписи (любое преобразование сделает его недействительным), при этом быть доступным для просмотра, проверки подписей и формирования печатных форм на протяжении всего срока кредитования плюс ещё условные 10 лет (для разных договоров срок хранения может отличаться).

Эти 10 лет для электронного документа значат многое. Из-за развития технологий спустя столько лет могут возникнуть проблемы с открытием файла и проверкой подписей. Даже шрифты в файле договора могут устареть и исчезнуть из операционных систем.

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

Подписать УКЭП

У РСХБ 62 филиала и более 2 000 сотрудников, участвующих в процессах. Каждый из них должен получить доступ к системе, обучиться и получить УКЭП. В масштабах одного человека это несложная задача, но, когда нужно провести работу со всем штатом, её решение становится очень трудоёмким.

И действительно, это заняло немало времени. Наибольшие сложности возникли с составлением списков сотрудников, уполномоченных работать с УКЭП и документами. Необходимо было собрать фамилии, адреса e-mail, отсеять уволившихся и т. д. Но, когда это было сделано, мы смогли внести их данные и обеспечить доступ не вручную, по одному, а централизованно, всем списком.

Положить в архив

Во-первых, раньше в банке не хранили оригиналы кредитных договоров, подписанные только в электронном виде. Снова может показаться, что проблема не такая и сложная: достаточно воспользоваться инфраструктурой операторов ЮЗД. Но по действующему законодательству оператор ЭДО должен гарантированно хранить только первичку и только в течение 5 лет. Конечно, оператор подтверждает, что он будет хранить и дольше, но либо это влечёт дополнительные непрофильные затраты для оператора, которые он перекладывает на банк, либо документы при оптимизации могут быть удалены. Банк такие условия не устраивают, потому что файл и подписи к нему это единственный подтверждающий сделку документ. А сделки бывают разные и по объёмам, и по длительности.

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

Во-вторых, для хранения подобных документов нужно надёжное электронное хранилище. В РСХБ с 2017 года внедрена и успешно функционирует АСОА автоматизированная система управления хранением документов на бумажном носителе и хранения электронных образов документов. В ней хранятся скан-образы документов клиентов, копии договоров и иные документы по сделкам с клиентами. Но новый процесс требует хранения в системе оригиналов договоров. Поэтому, когда оригинал останется только во внутренней системе банка, потери должны быть исключены. Нужно было вывести всю систему хранения или её часть, в которой размещаются документы, на запредельный уровень SLA.

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

В-третьих, каждая копия кредитного договора, подписанного в электронном виде, эквивалентна оригиналу. Доступ к копии договора и подписи равносилен тому, как если бы злоумышленник получил доступ к его оригиналу. Кредитный договор, подписанный в электронном виде, не должен быть доступен никому, кроме ограниченного круга пользователей. В рамках существующих процессов сотрудникам банка нужно работать с копиями кредитных договоров. И важно, чтобы на копии (печатной форме) были понятные для человека штампы с информацией из УКЭП и датами подписания. Чтобы всё это обеспечить, нужен высоконагруженный сервис, который проверяет соответствие документа подписям, валидность УКЭП на дату подписания и генерирует печатную форму.

На выходе пришлось решать сразу две проблемы. Первая касалась ограничения доступа. Силами IT и Департамента безопасности банка была разработана и внедрена матрица доступов и ограничений доступов к информации и её пересылке. Доступ к оригиналу КОД получили только определённые сотрудники подразделений, которым это необходимо для работы. Остальные же сотрудники могут только загружать договоры в периметр банка (в архив), после чего они утрачивают доступ к этим документам, как и возможность куда-либо пересылать их со своих компьютеров или извлечь на любых носителях. Всё это решается настройкой ролей.

Вторая проблема касалась работы с печатными формами документов. КОД в банке используются не только в рамках самой выдачи кредита или оспаривания, но также в печатной форме и в процессах по мониторингу, контролю за исполнением условий договора, контролю ковенант (объёмов денежных средств, которые клиент должен сопроводить через банк в зависимости от оборота) и т. д. Поэтому сотрудникам и системам, которые осуществляют этот контроль, нужна печатная форма, на которой было бы видно, кто, когда и чем подписал этот договор.

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

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

Такой документ сотрудники банка смогут использовать в необходимых им бизнес-процессах. Помимо этого, сервис, возможно, позволит и заёмщику, ставшему клиентом банка, получать по запросу печатную форму документов, которыми он обменялся с банком через ЮЗДО. Сделать это можно будет по каналам дистанционного банковского обслуживания в личном кабинете клиента.

Результаты работы

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

• обеспечить бесперебойность кредитного процесса даже в условиях новых пандемий (но мы очень надеемся, что их больше не будет);

• выстроить полноценные и безопасные взаимоотношения с клиентами;

• гарантировать юридическую силу документов и правомочность операций;

• наладить простой и прозрачный диалог с надзорными организациями и госслужбами;

• найти оптимальные способы использования электронных подписей;

• отказаться от ручного ввода и хранения бумажной документации;

• снизить число ошибок и погрешностей при работе с бумагами.

Кроме того, эти наработки смогут в будущем послужить хорошей основой для построения более функционального целевого решения.

Что мы будем делать дальше

У электронного ЮЗД много перспектив и преимуществ. Не только с точки зрения экологии (все мы знаем: меньше бумаги больше деревьев), но и практичности. Ведь чем быстрее обрабатываются документы, тем быстрее можно получить кредит. Процесс, безусловно, будет совершенствоваться, возможно, будет расширена и продуктовая линейка для потенциальных клиентов банка.

Сейчас перед ДИТ стоят более понятные, но не менее важные задачи:

• обеспечить безотказность процесса;

• доработать используемые банком системы и интеграции между ними;

• реализовать новые механизмы по интеллектуальной автоматической обработке, распознаванию и верификации поступающих в банк документов, чтобы снизить нагрузку на операционистов и повысить скорость обработки документов;

• обеспечить работу с использованием ЮЗД и объединить процессы банка, клиента и контрагента в мире электронных документов;

• реализовать то, что ещё не придумано, ведь эта область пока только развивается.

Обратная связь

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

В заключение добавим, что, если у вас есть экспертиза в ЮЗД или просто желание научиться работе с электронными документами, мы будем рады видеть вас в нашей команде. Мы ищем специалистов любого уровня. Если вас интересует это направление, вы можете написать нам сюда.

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

Задачи: почему мы вообще в это ввязались

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

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

• покупателям для формирования корзины из фермерских продуктов и оформления заказов

Поиск решения: почему выбрали Flutter

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

По большому счёту, выбирали между нативом и Flutter. React Native и Xamarin отбросили почти сразу, с ними уже имелся опыт не очень удачный. Также рассматривали PWA, но этот вариант тоже пришлось забраковать: на момент выбора там было не всё хорошо с поддержкой нативных функций системы, особенно в iOS. К тому же для хорошей поддержки требовались свежие версии OS, что тоже могло стать проблемой. В общем, изучив вопрос поглубже, решили не собирать грабли.

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

• достаточно быстрый, за счет компиляции, сравним с нативом

• виджетный (компонентный) подход, сродни React

• кроссплатформенный меньше кода, потенциально упрощает тестирование

• богатый инструментарий разработчика IDE и прочее

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

• продукт, который развивает и продвигает Google и большое Open-source community

• крупные компании Google, Groupon, Alibaba разрабатывают на нём свои приложения

Были и минусы:

• мало разработчиков всего 121 резюме, 11 лидов/сеньоров в Москве

• дорогие лиды/сеньоры

• относительно мало технической информации stackoverflow и т.п.

• пока мало готовых (сложных) компонентов стандартные/системные тут не используются

• язык новичкам придётся учить Dart (но легко переходить, если есть опыт разработки на Java или JavaScript)

• сложно найти подрядчиков с опытом

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

Пришлось фантазировать: формирование команды

После выбора решения одним из главных вызовов стало формирование команды под новый проект. О поиске Flutter-разработчиков можно написать отдельную статью. На момент старта проекта весной 2020 года подходящих специалистов на рынке было, мягко выражаясь, не густо. HH по запросу Flutter выдавал несколько десятков резюме, в которых значился некоммерческий опыт: Мне было интересно, и я начал разрабатывать своё приложение или Уговорил попробовать сделать какой-то простенький внутренний проект в компании.

И всё же через HH мы нашли нашего первого разработчика, Михаила. Ему так понравился Flutter, что он по собственной инициативе сделал на этом фреймворке приложение для своей компании но развития оно, к сожалению, не получило. Михаил хотел работать с Flutter дальше, поэтому он вышел на рынок, где мы и нашли друг друга. Вместе с ним формировать команду мобильной разработки стало немного проще: появилась своя компетенция.

Основная масса специалистов по Flutter это младшие разработчики, которые только начинают свой путь, а также старшие или ведущие, у которых есть время изучать современные технологии и пробовать их в виде proof of concept. Проще всего адаптироваться к Flutter тем, кто имеет опыт Android-разработки. На втором месте web-разработчики: react, vue.js здесь близкий по духу компонентный подход.

И всё же людей на рынке было крайне мало, а в активном поиске ещё меньше. С начинающими разработчиками мы решали и решаем вопрос в т.ч. за счёт нашей стажёрской программы для студентов старших курсов вузов, где под руководством опытных наставников ребята становятся полноценными джунами. Так было с Евгением, который пришёл к нам на стажировку по мобильной разработке. Обучался под руководством Михаила почти со старта проекта и достаточно быстро дошёл до продуктовых задач.

Однако с синьорами и мидлами дело было совсем плохо, обычные каналы поиска не работали. Пришлось фантазировать: искали людей в тематических telegram-каналах и через Хабр, среди авторов статей по Flutter. С подходящими кандидатами списывались, общались, давали тестовые задания. Это вынудило нас расширить географию на всю Россию, что стало новым опытом: до этого мы рассматривали только кандидатов из городов, в которых есть наши офисы но с Flutter это не работало.

На сегодняшний день география команды довольно обширна: кроме москвичей, у нас работают жители Петрозаводска, Елабуги, Барнаула. Есть кандидаты технических и физико-математических наук. Таким образом, команда формировалась постепенно, параллельно с активной разработкой приложения. Сейчас у нас уже 7 разработчиков, появляются новые проекты на Flutter мы растём.

Изначально работу выстраивали по принципу feature-driven development (FDD, разработка, управляемая функциональностью). Но впоследствии решили перейти на унифицированный процесс разработки на основе OpenUP: такой способ лучше подходит для управления разработкой всего продукта и координации нескольких команд архитекторов, аналитиков, разработчиков, тестировщиков. Внутри команд разработки используем Scrum.

Особенности разработки на Flutter

Когда говорят о кроссплатформенной мобильной разработке, часто сравнивают React Native и Flutter. Однако нужно понимать, что React Native это не история про один код на все платформы. Недаром официальный слоган проекта Learn once, write anywhere. Дело в том, что в React Native пишут код на JavaScript, который использует нативные для каждой платформы компоненты и они довольно сильно отличаются. Да, есть общие компоненты, вроде Text и View: под обе платформы, хотя и с нюансами. Но много и таких, что работают только на одной ОС. Поэтому в React Native нередко можно встретить выражения:

if (Platform.OS == 'ios') ...`

При использовании Flutter разработка ведётся на языке Dart, который компилируется в нативный для платформы код. При этом вместо нативных компонентов используется собственная библиотека виджетов, которые выглядят как нативные Material и Cupertino для Android и iOS соответственно. Вы можете использовать виджеты из обеих библиотек в одном приложении, кроме того, их очень легко кастомизировать.

В результате код действительно выходит кроссплатформенным. Целевую платформу необходимо учитывать лишь изредка. Например, у нас была ситуация с отображением маркеров на google-карте. У этих изображений должен быть разный исходный размер, а значит механика отрисовки должна учитывать устройство, на котором запущено приложение.

Бывает и так, что есть уникальная для платформы функциональность. Подстановка СМС-кодов верификации на iOS работает по умолчанию, от программиста не требуется никаких действий. А на Android нужно использовать системные методы, чтобы получить этот код программно и подставить в нужное поле. Хотя даже для этой задачи уже существуют Flutter-библиотеки, например, sms_user_consent. Весь платформенный код в ней уже создан, остаётся только добавить свой listener для получения сообщений.

if (Platform.isAndroid) {  listenForCode();}void listenForCode() {  smsUserConsent = SmsUserConsent(      phoneNumberListener: () {},      // Действия при получении смс-сообщения      smsListener: () {        Log('code is updated to ${smsUserConsent.receivedSms}');        final sms = smsUserConsent.receivedSms;        _smsCodeController.text = sms.substring(sms.lastIndexOf(' ') + 1);      });  smsUserConsent.requestSms();}

Одна из не очень удобных особенностей Flutter достаточно динамичный релизный цикл. Как и во всех подобных активно развивающихся фреймворках, почти каждое крупное обновление приводит к необходимости внесения изменений в уже написанный код. Например, при переходе с версии 1.20 на 1.22 пришлось потратить несколько часов из-за конфликтов имён классов проекта и встроенных классов Flutter. Тем не менее такие серьезные изменения скорее редкость, они происходят не чаще трёх раз в год.

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

Разработка на Flutter значительно быстрее, нежели нативная. Если говорить о кодовой базе, то нативный мобильный код по объёму для каждой платформы по отдельности был бы примерно аналогичен Dart-коду, но за счет того, что платформ две, получаем существенное увеличение трудозатрат.

Результаты и выводы: стоит ли разрабатывать на Flutter

Новый фреймворк не подвёл: после полугода разработки MVP доступно в магазинах приложений для Android и iOS. Проект по-прежнему развивается, и в этом очень помогает фидбэк пользователей: мы активно взаимодействуем с фермерами, которые делятся своими впечатлениями от использования платформы. В ближайшем будущем хотим подключить к нашему маркетплейсу сторонние сервисы доставки, внедрить онлайн-платежи, организовать процесс совместных покупок. Для реализации этого нам понадобятся не только мидлы и сеньоры, специализирующиеся на Flutter, но и PHP-разработчики (Senior и Team Lead с опытом Magento 2), а также опытные специалисты по Vue.js. Если видите себя членом нашей новой команды обязательно пишите!

Нам очень понравилось работать с Flutter. Тем не менее это решение пока нельзя считать универсальным: для нашего проекта оно подошло на 100%, но при разработке какой-нибудь игры или продукта, использующего более сложные и передовые технологии VR, AR, ML и т.п., всё могло бы сложиться не так гладко. Впрочем, со временем эта функциональность наверняка подтянется.

Единственный реальный риск корпоративные войны между Apple и Google. Если политика Apple в отношении приложений на Flutter изменится, это может негативно сказаться на его перспективах. Речь не только о процессе размещения в магазине приложений, но об инструментальных средствах, таких как совместимость SDK.

Мобильным разработчикам однозначно стоит попробовать Flutter, особенно тем, кто делает первые шаги в мире программирования. На сайте проекта есть отличная документация, у фреймворка имеется активное сообщество, а также большая база сторонних плагинов и библиотек. И мы со своей стороны собираемся продолжать делиться своим опытом решения реальных задач на Flutter и готовы ответить на ваши вопросы, задавайте их в комментариях.