RosEvroBankのモバイルアプリケーション開発：ケース

2017年の春に、新しいRosEuroBankモバイルアプリケーションをリリースしました。 モバイル製品の開発、テスト、実装の過程で2つのチームが直面した課題-RedmadrobotとRosEvroBankは、次のケースで説明します。 したがって、「モバイルRosEuroBank：舞台裏」。


RosEvroBankが私たちに連絡する頃には、すでにOtkritie BankやLife Financial Groupなどのモバイルバンキング製品をいくつか作成していました。そして、「キッチン」全体（プロセス、ルール、金融サービスオペレーターのニーズ）についてよく考えていました。そのため、非常に迅速に開発を開始できました。

Artem Grebnev、RosEvroBankプロダクトオーナー
「2016年の初めに、プロジェクトに取り組む内部銀行チームを編成し、実験を開始しました。 年の半ばには、既存のソリューションに基づいてモバイルバージョンを作成するのは非合理的であり、最初からすべてをやり直す必要があり、これは有能で訓練を受けた経験豊富な銀行ソフトウェアの開発者が行う必要があります。 市場を調査し、いくつかのチームを招待しました-誰でも参加できるオープンなオファーがありましたが、明確な選択基準がありました。第一に、専用の開発チーム、そして第二に、銀行のオフィスで直接開発チームの「着陸」までの密接なやり取りがありましたスピードアップに役立つ場合。 すべての提案を確認した後、私たちはRedmadrobotが私たちの期待に最も合っていることを認識しました。

2016年8月、銀行は64ページで最も詳細なTKを提供しました。これには、クライアントが将来のアプリケーションで見たいものがすべて含まれていました。 製品からのこれらの期待を一緒に調整する必要がありました。 TK「RosEvroBank」は、本質的に3つの機能ブロックで構成されていました。既存の顧客向けの高品質サービス、非顧客向けの電子財布などの追加サービス、あらゆる業務の支払いアグリゲーターです。 すべてのブロックは正しいものですが、その実装には膨大な作業と非常に長い市場投入期間が必要です。少なくとも1年または2年の開発期間があり、その間に視聴者の損失と業界リーダーからの大きな遅れがあります。 そのため、モバイルアプリケーションとFinTech製品の市場でよく使用されるアプローチを銀行に提供しました。最小限の機能を備えたアプリケーションの最初のバージョンを6〜8か月間起動し、その後製品を体系的に開発しました。

最初のリリースの最小機能を決定するために、銀行と私は彼のビジネスにとって最も重大な問題を特定しました。他の銀行またはキャッシュにお金を引き出すことを好む給与プロジェクトを持つ多くの企業クライアントです。 この痛みを最初に解決する必要があり、ここで努力を集中しました。



銀行のアプリケーションとミドルウェアのロジックに、今後6か月間の開発の機会を組み込むことは、最初から重要でした。

アプリケーションでできること

最新の銀行業務アプリケーションに必要な標準の機能セットに加えて、必ずしも見つからない追加機能を実装することにしました。 つまり、ウォレットのように、自動支払いと他の銀行のカードでの作業です。

Alisa Morozova、プロジェクトマネージャー、Redmadrobot
「銀行商品に関連するものはすべて、口座、ローン、RosEuroBankのカード、その他の銀行など、1つの画面で収集されています。 お金の持ち物をすぐに理解でき、前後に簡単に投げることができます。」



外部リンクカードを使用すると、支払いを行い、RosEuroBankカードの残高を無料で補充し、そこから他のカードに送金できます。 他の銀行のカード間では、わずか1％の手数料で送金できます。 外部リンクカードでの操作の場合、CVV / CVCコードのみを入力する必要があります。



支払いの場合、個別のタブが選択され、いくつかのタイプのスマート自動支払いが実装されます。 最初のものは定期的です：転送の量と頻度が示され、制限を設定できます-特定の日付または指定された数の転送まで実行されます。



車の支払いの2番目のタイプは、イベント発生時の不規則な転送です：税金、罰金、住宅および共同サービスの支払い。 ここで、各取引の制限と月ごとの合計制限で支払いを設定できます（たとえば、最大500ルーブルまでの罰金を月に5回まで支払う）。



最も興味深いのは、テンプレートに従った自動サブスクリプションです。車両の登録証明書の番号を入力し、罰金を見つけて支払ったとしましょう。 これは、システムが将来罰金を監視し、通知して支払いを申し出るのに十分です。 税金や手数料を支払う場合も同様です。たとえば、子供の学校グループなど、親relativeの請求書の自動支払いをオンにすることもできます。

ところで、スキームの下での支払いの開発は、ビジネスロジックの観点から最も困難なタスクでした。 任意の形式で提供できますが、美しく表示し、ユーザーが混乱しないようにする必要があります。 多くの銀行業務は、ユーザーの観点から非常によく似ています（支払い、自動支払い、請求書、テンプレートに従った支払い）。そして、銀行システムの観点から見ると、これらはまったく異なるエンティティです。

システム構成

銀行のアーキテクチャはどうですか？ ビジネスプロセスエンタープライズレイヤー（BPEL）があり、WSDL形式の既存および開発されたサービスに基づいてすべてのプロセスを処理するビジネスロジックをすばやく実装できます。 モバイルアプリケーションは中間層を見て、BPELを見て、BPELはバス経由でWSDLを介してすべての銀行システムと通信します。

中間層はCMSとして機能し、同時にJSONをWSDLに変換します。これは、すべての内部サービスがWSDLで動作し、モバイルアプリケーションがJSONで動作するように適合されているためです。

さらに、アプリケーションコンテンツのすべてのデータ（支払いアイコン、ロゴ、配色など）も保存されます。 たとえば、Sberbankカードの追加を開始し、数字の最初の桁を入力すると、カードの背景が緑色に変わります。 また、MTSを支払うと、背景が赤で強調表示されます。 これらの配色、ロゴ、その他のコンテンツはすべて、レイヤーにのみ保存されます。



中間層-銀行のウェブサイトと「仮想オフィス」（インターネットバンキング）を含む外部DMZの一部。 DMZの背後には、銀行のメインネットワークがあり、他のすべてのシステムが動作しています。 これは、モバイルアプリケーションのビジネスロジックレイヤーが配置されている場所であり、レイヤーからの要求のみを受信して​​処理します。

銀行内のすべての通信は、すべてのシステムにWebサービスを提供するデータバスを介して行われます。 その結果、最適化機能の優れたアプリケーションが得られました。 たとえば、サービスプロバイダーのリストの最初のバージョンは非常に高速ではありませんでした。すべてのプロバイダーに完全なスキームをダウンロードしたため、15〜20秒かかりました。 ここで、定義のリストのみをアップロードし、すべてのクライアントが必要とするわけではない個別のリクエストで詳細を非表示にします。



Alexey Shcherbakov、RosEvroBankデジタルバンクITヘッド
「現在、コンテンツレイヤーを使用して同じスキームのWebアプリケーションを再設計しています。 以前は、独自のコンテンツシステムを使用し、WSDLを介してBPELと通信していました。 しかし、モバイルアプリケーションでは、アーキテクチャアプローチの変更のテストに成功しており、Webアプリケーションとモバイルアプリケーションは機能的にもアーキテクチャの観点からも同期されます。 統一により、銀行のさらなる発展が簡素化されます。利用可能なすべてのデジタルチャネル（web、mob、sms、ussdなど）に新しい製品を迅速に投入できます。」

Dmitry Korchmarek、RosEvroBankチームリーダー
「銀行向けのWebアプリケーションを作成したときは、さらに時間がかかりました。多くの要件を持つ巨大なプロジェクトであり、多くの新しいシステムが作成されました。 すべてのシステムのAPIの実装と統合の開始のためのいくつかの準備プロセスには、数か月、さらに数か月、統合自体がかかりました。 しかし一方で、銀行のロジックではなく、ユーザーの観点からこれらすべてのシステムを組み合わせることができました。 その結果、モバイルバージョンでは、新しいAPIと新しい機能の開発プロセスが非常に積極的なペースで進みました。 モバイルバージョンに必要なのは最上位のビジネス要件のみで、Redmadrobotの助けを借りて、わずか数か月でAPIを準備しました。 私たちが望むほど完璧で、きれいで、透明ではないことがわかりました（117ページの仕様があり、そのうち17ページが変更の履歴です）。しかし、アーキテクチャ自体により、「バトル」サーバーでの現在の実装に影響を与えない新しい機能を開発および実装できます外出先で。」

iOSバージョンのアプリケーションはSwiftで作成されました。 Redmadrobotには多くの独自のライブラリがあります-トランスポート層、データベースなどのために、多くの時間を節約します。

Olga Vorona、iOS開発者Redmadrobot
「私たちはすべての会社のプロジェクトの中で1つのパラダイムで作業するよう努めており、チーフアーキテクトは階層化アーキテクチャを推進しています。 大きな層-サービスレベルとUI。 サービスレベルには、データベースを操作するトランスポートが含まれ、これらはすべて個別のサービスに分割されます。 ビジネスロジックのレベルの詳細については、 こちらをご覧ください 。 MVVM（Model、View、ViewModel）、MVPM（Model、View、PresentationModel）を使用したら、ナビゲーションにルーターを使用します。 ViewControllerにはできるだけ残さないようにし、PresentationModelではさらに多くを作成します。 プレゼンテーションは、サービスレベルからモデルを取得し、それらからViewModelを作成します。 View ControllerはこれらのViewModelを使用して、ユーザーが画面に表示するViewを構成します。 ViewControllersでルーターを使用して、スクリプト間またはスクリプト内で切り替えます。

銀行のニュアンス

モバイルバンクを開発するには、ユーザーアカウント、テストアカウント、カードをテストする必要があります。 「戦闘」と交差しない銀行のテストゾーンでは、任意のパラメーターでクライアントを作成できます。 しかし、同時に、事前に必要になる可能性のある口座、カード、ローンのすべての組み合わせを検討する必要があります。 これを行うには、すべての銀行商品とそれらの可能な条件を理解する必要があり、これは膨大な数のバリエーションです。

中間層の開発とテストのプロセスの最初の段階では、これに関連して多くの点が生じました。 銀行APIの性質により、銀行による特定のアクションの正しい実行は、モバイル開発者の観点からはエラーのように見える場合があります。 たとえば、10個の製品の識別子がアプリケーションに送信され、その中にはカードとアカウントがあります。 そして、カードの助けを借りて、銀行の規則に従って口座からしか実行できない多くの操作を実行することは禁止されています。 開発者がカード識別子を置き換え、アカウントのメソッドを呼び出すと、APIがエラーをスローします。

設計

銀行は簡潔で軽量なデザインに設定されていたため、最小限のグラフィックス、大きなフォント、シンプルな配色を使用しました。



Tatyana Gushchina、デザイナー、Redmadrobot
「開発をスピードアップするために、興味深いアニメーションで希釈された標準設計要素が最大限に使用されました。 彼らの仕事は、大量のデータの読み込みなど、遅い操作を実行するときにユーザーにフィードバックを与えることです。 最初は、画面全体をブロックする更新とアクティビティインジケータのみがありました。 しかし、リクエストの詳細のために-1つの画面に複数のリクエストがある場合があり、スクロールするとこれが表示されるはずです-Loaderもレンダリングしました。 別のトピックがメイン画面を思い付きました。セキュリティ上の理由でアプリケーションに何もキャッシュされていないため、ロード中に画面が空白のままでした。 これはユーザーの期待に反するものであり、ダウンロードプロセスが進行する主な画面を模倣する特別な中間画面を追加しました。

2つのチームでのコミュニケーション

RosEvroBankプロダクトマネージャーVitaliy Palchikov
「銀行内には、社内チャット、社内ファイル共有、プロジェクト管理システムなど、部門間の相互作用の快適なエコシステムがあります。 このプロジェクトの複雑さは、第一に、一方では銀行側の管理者、マネージャー、開発者、テスターで構成され、他方では銀行のチームのエコシステムの「外部」で構成される分散チームとして働くことでした。 第二に、私たちにとっての課題は、プロジェクトの短期間の立ち上げでした。 私たちは車輪を再発明しませんでした-15-20人からのWhatsAppチャットは極端でしたが、実用的なソリューションです:)

困難でした。プロジェクトの前に「コンピテンスセンター」がオンザフライで開発され、QAの必要性は深刻でありませんでした。最初は、仕様への準拠について開発者のAPIを個人的に確認する必要がありました モバイルアプリケーションのテストの一環として、「盗聴」トラフィック。 バックラッシュ応答とアプリケーションの動作を比較します。 また、アプリケーションのリリース後、顧客からの電話の着信を個別に処理し、機能を最初の行に戻すための事前に準備されたスクリプトを使用してFAQデータベースを形成することができます。 両チームのプロジェクトマネージャーの負荷は大幅に増加しましたが、誰もが困難に対処しました」。

チームチャットにより、プロジェクトに関する効果的なコミュニケーションを24時間年中無休で構築できました。 その結果、2つのチームの開発者間のコミュニケーションはプロジェクト管理者に限定されず、チーム間で完全かつ緊密な相互作用が構築されました。



夕方の10時にメソッド呼び出しが失敗したことを知らせ、銀行は即座に当直の管理者に連絡し、緊急の更新が予定外にロールアップされていることがわかり、すぐに「10分待ってすべてが機能する」と答えました。 メソッドが受け入れられないということではなく、バグがJiraで開始され、銀行は翌営業日に対応します。 これにより、開発が大幅に加速され、プログラマーは都合の良い時間に作業できるようになりました。



必要に応じて、RosEvroBankは銀行バックエンドの特定の部分を担当する専門家をチャットに接続し、テスターを追加しました。すべての問題は迅速に解決されました。 チームメンバーでさえ、プロジェクトの開始についてチャットから学びました:)

結果は何ですか

Redmadrobotの私たちにとって最も重要なことは、銀行と適切に連携することでした。 どんなに高度なものであっても、それはまだ大規模な構造であり、別のデジタルバンクであっても、多数の承認とチェックが必要です。 大きな成果は、そのような顧客と協力する方法を学び、同時に、アーキテクチャ、設計、記述、テスト、およびテストシステムを行う方法で協力する方法を彼らに教えたことです。

これまでに、バックエンドバンクで利用可能な機能の約90％を閉鎖しました。モバイルアプリケーションは、機能面ですでに銀行のWebキャビネットよりも優れています。 記事を書いている間、アカウントの開設、非居住者の登録、カードでの資金の使用に関するグラフィカルなレポート、カードの制限の管理の可能性をすでに認識していました。 近い将来の計画-電話番号による銀行顧客への転送、接続オプション-キャッシュバック、累積利息およびSMS通知、変換、オペレーターとのチャットなど。