ときどき立ち止まって、あなたがしていることを改めて見直すときがあります。 古いソリューションがかつて正しいように見えたが、今は問題が発生した場合はどうなりますか？ 勇気を出して、白紙の状態から始めてください。 それまでの間、8年前にQIWIが製品の発売時にどのように正しい選択をしたかを説明しますが、2015年には何度もやり直す必要がありました。

どのようにすべてが始まりましたか？

遠い昔、遠い、遠い銀河では、2008年でした。 QIWIは、オンラインストアにQIWI e-ウォレットからの支払い方法を提供することを考えました。 すでに使用されているプロトコルは、プロバイダー側​​のアカウントを持つクライアント向けでした。 たとえば、クライアントがモバイルの残高を100ドル請求する場合、765ドルも問題ではありません。 端末または個人アカウントでは、プロバイダーとの契約番号を示して支払うだけで十分です。 このプロトコルは、歴史的にプッシュと呼ばれていました。

顧客が22 999 forでiPhone 3Gオンラインストアを購入した場合、20000 25または25 000 payを支払うことはできません。正確に22 999 storeに転送する必要があるため、新しいプロトコルを開発する必要がありました。

市場の会社の主要な切り札は支払い端末であり、それらを最大限に使用するためには、遅延支払いをサポートする必要がありました。 明らかに、現実世界から最も近い類推は請求です。 しかし、通知する方法と、アカウントをユーザーに関連付ける方法は？ もちろん、電話番号を使用することにしました。 会社は既に識別子としてこれを使用しています。

これは、顧客がストアで製品を選択し、QIWIを使用して代金を支払うことをアナウンスするときに、アカウントを操作するためのプロトコル（プル）が表示される方法です。 次に、彼は電話番号を入力し、ストアサーバーがAPIによって請求書を発行し、幸せなユーザーが端末、qiwi.com、またはパートナーに支払いに行きます。 その結果、ストアは支払いの成功またはアカウントのキャンセルの通知を受け取ります。

APIを開発した後、彼らはそれを積極的に販売し始めました。 請求書が発行され、提案された顧客は、ターミナルまたはqiwi.comにアクセスします。 しばらくして、請求書の支払い方法をユーザーに美しく説明するページが必要であることが明らかになりました。 彼らはそれを行い、恐ろしい言葉を「チェックアウト」と呼びました。 同時に、プロトコルを接続および構成するためのアプリケーションのファイリングシステムishop.qiwi.comが作成されました 。

進化的劣化

支払いページの初期ロジックは単純で、ログインしてQIWI残高で支払います。 電話番号の入力は、ストアの横に残りました。 これは、課金プロトコルによって暗示されていました。

プロトコルがシンプルで明確であると判断したため、すでに合理性への期待のすくいを踏んでいます。

何かがうまくいかない場合、それはそこに行くことが判明しましたが、それについては後で詳しく説明します。 その後、タイクレジットカード、モバイルコマース、タイマネー、マイクロクレジットのトライアルローンチが来ました。 これらすべての革新により、一般的なユーザーエクスペリエンスに関係なく、請求書の支払いページが徐々に変更されました。 たとえば、モバイルコマースではパスワードが不要なため、支払い方法を事前に選択するためのページが追加され、残高からの支払いが複雑になりました。 さまざまな支払い方法の実装に加えて、たとえばパスワード変更ルールの厳格化など、内部要件による変更もありました。

すべてはビジネスの観点から論理的かつ正しく行われましたが、2014年までにユーザーの支払いシナリオを見てみましょう。 あなたがかつてQIWIを使用したが、6か月が経過した顧客であるとします。 この間、携帯電話会社は番号を他の人に渡すことができたため、ウォレットは非アクティブとしてマークされました。 端末からお金を入金し、店舗に来て、QIWIで支払いを選択し、電話番号を入力して、請求書支払いページに移動します。

最初のページが開き、支払い方法が事前に選択された後、登録、支払い方法の選択による支払いの確認、および操作のSMS確認のページが続きます。

その結果、新しいユーザーまたはパスワードを忘れたユーザーに対して、最大8ステップが地獄のようなロジックとともに実行されました。 チェリーは、財布に拘束された後にのみクレジットカードによる支払いでした。

創業以来、QIWIは銀行よりもスタートアップに似ているため、Megaphoneとの統合などのビジネスプロジェクトの実装中に開発された製品は、実装の速度が優先されました。 このアプローチは非常に効果的ですが、時には一般的なクリーニングが必要です。

松葉杖MVP

支払いプロセスをより便利にするために、支払いページ全体を完全に変更する計画を立てました。 しかし、これは長いプロセスであることが明らかになりました。 したがって、UX / UIの作業と並行して、現在の製品の最も重要な変更を選択しました。

まず、パスワードの代わりに1つのSMS、つまりOTP-ワンタイムパスワードで認証することにしました。

詐欺師は、目的のテキストメッセージを釣ってユーザーを欺くことをすぐに学んだため、OTPは、売上高が大きく、資金を引き出すオプションのない信頼できるパートナーにのみ含まれていました。 また、OTPシナリオでは、新規ユーザーの登録が大幅に簡素化され、SMS入力とオファーの承認のみが必要になりました。

また、余分なページを減らし、少し気を付けました。 請求書の金額に基づいて、サービスはユーザーにとって便利な支払い方法を決定し始めました。ユーザーがウォレットの残高を持っている場合、支払いの前に1回のクリックのみが残っていました。 同時に、カードによる支払いを担当するチームと一緒に、事前に拘束することなく、ページに入力されたカードの詳細で支払いを行いました。

3か月間、すべての変更が実装され、コンバージョンとともに売上高が増加しました。 ただし、支払いページは依然としてサイトと同じアプリケーションの一部であったため、統計を正しく計算することは不可能であり、技術的負債は屋根を突き抜けました。 また、パートナーとのアクションの瞬間に安定性を保証し、製品の変更を同期することも困難でした。 サービスのアップグレードを開始する時が来ました。

勇敢な新世界、またはSPAゾーン

2015年、QIWIはマイクロサービスアーキテクチャへの切り替えを開始しました。 再編の最適な候補は、支払いページでした。 REST APIとWebアプリケーションを実装する別個のJavaサービスを作成することが決定されました。 検索エンジンのインデックス作成が不要なのは良いことです。

同社は当時、React JSでWebアプリケーション（SPA-シングルページアプリケーション）を作成した経験がありませんでした。 フロントエンド開発者を雇い、新しいアプローチを習得するのに時間がかかりました：ツールの学習、開発スタックの選択、TeamCityと内部npmリポジトリでの連続ビルドの設定、テスト方法の選択。

開発が始まるまでに、UXプロトタイプの準備が整い、テストに合格したため、APIの設計を簡素化できました。 もちろん、チームは松葉杖に代わる大きな遺産をかき集めなければなりませんでした。 古いアーキテクチャはそのような野barさを示唆していませんでした。

React JSを理解している人向け

開発時には、reduxのようなソリューションは現在ほど人気が​​ありませんでした。 したがって、オブザーバブルステートアプローチが使用されました。 当初はバオバブを使用していましたが、当時は計算状態の開発が不十分であったため、次のような独自のソリューションに切り替えました。 コンポーネントの接着剤として、依存性注入が必要でした。 この図は、アプリケーションコンポーネントのレイヤーへの分離を示しています。 これは、効果によってコンポーネントの初期化（componentDidMount）の間に実行されるデータと状態の変更をロードするためのアクションによって、フラックスまたはリデュース操作の通常のスキームとは異なります。 計算された状態とキャッシュされたデータローダー（ローダー）もあります。

分析する

6か月間、私たちは会社で最初のマイクロサービスの開始を準備しました。 しかし、すべてが順調に進んだわけではありません。 12月は、支払いに影響する新しいソリューションを実行するのに最適な時期ではありません。 売り上げが少ないパートナーが新製品を最初に受け取ったのは面白いことです。 製品を発売し、売上高、コンバージョン、エラーの変動を徐々に制御しました。

12月に、アクティブなパートナー、ユーザー、全体的な変換、修正された主要な問題に関する基本的な統計情報を受信するデバッグを行いましたが、1月の休日にはほとんど全員が古いアプリケーションに戻りました。

1月に、3か月間、大規模な打ち上げが開始されました。 予期しないエラーが常に発生しました。 たとえば、一部のパートナーはページへのPOSTリダイレクトを行いましたが、プロトコルにはGETのみが記載されていました。 Adobe Airブラウザーでページを開いた主要なパートナーがいました。そこではすべてが標準に対して非常に悪いです。

そしてもちろん、古いプロトコルを使用したか、単にすべてのドキュメントを無視し、ログインページではなく、それらに適切と思われるものを開いたパートナー。 そのため、新バージョンの製品では、分析、つまり問題のある指標の検索に焦点を当てました。 彼らは私たちが多くの予期しない発見をするのを助けました。 製品が分離されたとき、彼らはプロバイダーのタイプとそれが機能する通貨と組み合わせて、各支払い方法のファネルを構築し始めました。 一般的な売り上げとコンバージョンのグラフで失われた問題が表面化しました。

また、多くの大規模なパートナーであっても、クライアントを支払いページに送らず、請求書が発行され、QIWIのどこかで支払うことができると言っていることに驚きました。 Pullプロトコルを使用する場合は、bill.qiwi.comにリダイレクトしてください。そうしないと、顧客の生活が複雑になり、コンバージョンの最大30％が失われます。

私たちは、新製品の非標準的な動作によるこれらの問題やその他の問題のサポートを学びました。

発売の大部分はAliExpressで歓迎されました。 支払いページでモバイルの組版を長い間待っていました。 興味深いことに、モバイルバージョンのユーザー数は、便利なUIの登場後に大幅に増加し、40％以上に達しました。 AliExpressのプロモーションの時代には、モバイルインターフェースを持つユーザーの割合は80％に達しました。

一般にカードの売上高は、一連の仮説検定の2倍以上を上げることができました！ これの多くが可能になりました、なぜなら プロジェクトの立ち上げに最大限の重点を置いたプロジェクトアプローチは、1つのチームによる1つの製品の段階的な開発に置き換えられました。 ローンチ後も積極的な開発が続けられており、すぐに良いニュースを共有できることを嬉しく思います。

個人、プログラマー

私はQIWIで5年間働いており、Flex-AS3のプログラマーとして来ました。 チームはソーシャルネットワーク用のアプリケーションを開発しました。 その後、node.jsとAngular JS、レストランのスタートアップがありました。 eBay-QIWIの統合と立ち上げ、古いishopnew.qiwi.ruの閉鎖、ishop.qiwi.comへの移行、および新しい請求書支払いページの立ち上げにより、アナリスト/プロジェクトマネージャーとしてプロジェクト管理に移行します。 現在、私はeコマース向けのb2b製品の開発を担当しています。請求書支払いページ、ishop.qiwi.com、およびプロバイダーの内部監視システムです。 開発、プロジェクト管理、製品開発ビジネスなど、中小企業と大企業の両方で興味深い経験を収集することが判明しました。

アジャイル製品チームと小規模製品チームへの移行が好きです。 確かに、誰もがこのスタイルに合うわけではないことに注意できます。 各チームメンバーはより大きな責任を負います。たとえば、チームリーダーは、それどころか、チーム間で分散されている開発者の独立性を高めることに貢献する必要があります。 ただし、これにより、大企業は多くの点で小規模なスタートアップと同じくらい柔軟になり、チーム全体が独自の経験を積むことができます。

製品自体を作成および開発し、同時にユーザーの生活を本当に簡素化する企業は多くありません。 QIWIはその1つです。 独自の製品を発売することで世界の見方が変わるため、同社はこれを奨励していますが、ご存知のように、いくつかのスタートアップは実際のビジネスに成長しています。 QIWIは、数千、数万または数十万のユーザーが使用する製品の開発を提案しています。これは成長の機会であり、刺激的な体験です。

現在、QIWIパートナー接続サイトishop.qiwi.comの重要な更新を準備しています。 これまでのところ、控えめに言っても理想的ではありませんが、パートナーとの連携のアプローチを大幅に変更する予定です。このためには、オープンAPIを備えた新しいアーキテクチャが非常に重要です。

したがって、REST APIを書いた経験のあるシニアJavaをチームに参加させ、今年何千人ものパートナーの質を向上させるために招待します。

一般に、QIWIの私たちは常にJavaおよびJS（React JS）開発者に満足しています。 開発には多くの興味深い方向性があります。 また、静かな時間と定期的なハッカソンもあります。 参加しよう！