アプリケーションに対する主な質問の1つ：アカウントからどこでどのようにお金を使うか？
アプリケーションを操作する最も可能性の高いシナリオを選択し、ユーザビリティ研究所で「通りから」生きている人々に提供しました。 それぞれがいくつかのタスクを受け取りました。たとえば、「テレビ広告では、「ようこそ」関税について学びました。 アプリケーションを使用して切り替える価値があるかどうかを理解する必要があります。」 または-「あなたはウズベキスタンへの出張に行きます。接続が最も有益になるように、どのように、そして何を接続するのですか？」
以下-テスト中に出会ったユーザーからの驚き、およびバックエンドのさまざまなサブシステムからの大量のデータを扱うことの難しさについて少し。
そのため、ある時点で、次のようなスケッチの形で完全なアプリケーションを構築することができました。
部門ごとにタスクを設定します。合計13の最優先ユーザーシナリオを取得し、可能な限り高速で便利なものにすることを試みました。 次に、「実際の」設計でアプリケーションを現実に近づけ、通常のユーザーでテストを開始しました。
テスト中
- 入り口には、電話のベータ版アプリケーションとカードのタスクがあります。 特別な機関が基準（年齢、性別、インターネットスキルなど）に従って人を募集します-私たちの意見では、アプリケーションの対象者に対応するプロファイルを提供します-そして、私たちがこのアプリケーションに対処する人（新しい人から） 。 これらは、モバイルインターネットを使用する18〜30歳の男女であり、過去6か月に少なくとも1回は関税の変更、サービスの接続、またはインターネットを介した残高の補充を行っています。
- 代理店は、スクリーナー （潜在的な回答者が尋ねた質問の束を含むアンケート）を準備し 、選択を開始します。 回答者が基準を満たし、研究に参加する準備ができている場合、彼は私たちの研究室であるMobiolabに来る時間を割り当てられます。
- ユーザーがその場所に来ます。 実験室には、カフェ、オフィスエリア、リビングルームなど、さまざまな場所の雰囲気を再現する部屋があります。 具体的には、このアプリケーションは、コーヒーとおいしいクッキーのすぐ後ろにある「ホーム」ゾーンでテストされました。
研究所ホームゾーン
- テスト自体は次のようになります。ユーザーがタスクを読み取り、タスクの完了を開始します。 モデレーターは近くに座って、調査プロトコルの回答者のすべてのアクションとコメントを書き留めます。 どこでどのような間違いが行われたか、問題の解決にかかった時間を修正します。 あなたの個人アカウントのウェブ版にITトラッカーやその他の機器を使用した場合、すべては必要に応じてHD撮影でモデレーターの行動によって決定されます-十分なデータが来ます。 はい、携帯電話の画像もプラズマスクリーンに表示して、群衆全体で肩越しにユーザーを見ないようにしました。
- 次に、すべてのプロトコルを接続し、効率と生産性を考慮し、エラーを説明し、問題の修正方法を確認します。 すべてのタスクが完了したら、製品について質問します。 すべてのコメントを書き留めます。
主なタスクは、ユーザーがタスクに対処しなかった、またはゆっくりした、または初めてではなかった状況を見つけることです。 例は次のとおりです。ユーザーは「サービス」タブに移動しましたが、すべてのユーザーが「すべてのサービス」ボタンを見つけたわけではありません。 ポインタがないため、ユーザーには見えないという結論に達しました。 このボタンに矢印を追加しました。
生地カードの例
状況 ：アプリケーションの最初の起動時の回答者の半数は、画面中央に膨大な数に気づきましたが、これがバランスだとは理解していませんでした。 残高を確認するために、「サービス」タブに移動しました。 「あなたはどう思いますか、メインページに示されている数字は何ですか？」という質問の後、彼らはそれが不可解なものであると答えました。
理由 ：
•ユーザーが最初に目にするのは膨大な数です。 しかし、彼らはそれが何であるかを理解することができません。なぜなら、説明は合計の下に小さな活字で書かれているからです。
•天びんの文字表記はありません（「p」、「rub」など）。
これらの推奨事項：
•「dd.mm.yyのバランス」というフレーズを天びんの上に表示する必要があります。
•バランス「p」または「rub」のアルファベット表記を追加します。
状況 ：一部の回答者は、接続されたサービスに関する情報を検索するときにミスを犯しました。 アプリケーションのメインページでクリックできないブロック「You are connected」をクリックしました。
推奨事項 ：メインページの[接続済み]要素をクリック可能にし、クリックするとアクティブなサービスのリストを表示します。
変更のその他の例
最初のバージョンでは、アクションボタンは上部のナビゲーションバー（右上隅のチェックマーク）にありましたが、人々は失われ、ほとんど見えませんでした。 右側には最もユーザーフレンドリーなバージョンがあります。
最初は、地図にプラスまたはマイナスのボタンはありませんでした。 ソファに横たわっているユーザーにとっては非常に不便でした（そのため、実際のインテリアを再作成しています！）手の位置を変えてマルチタッチを行うこと。 同じ問題が原因でした。片手でスケールを制御することは不可能だったため、ボタンを追加しました。
ここでは、サービスのプレゼンテーションの構造を大幅に分類しました。
テストを何度か繰り返した結果、ユーザーは自信を持って問題を解決した最終バージョンを取得できました。 それでは、バックエンドに移りましょう。
バックエンド開発の主な難しさ
この部分での作業は、デザインの開発と並行して行われましたが、実際には、ボリュームが大きかったため、はるかに早く始まりました。 高負荷下でのシステムの動作を保証するITインフラストラクチャの構築を完了する必要がありました。 ソフトウェアを作成し、VimpelComインフラストラクチャのモバイルコンポーネントとITコンポーネントの複雑な統合を実行しました。
主なスレッドは次のとおりです。
- セルフサービスシステムとの通信。 そこで承認とサービス管理が実行されます。
- 課金システムは、財務情報を提供します。
- CRMはサブスクライバーにサービスを提供します
- コンテンツ管理システムには、アプリケーションとの双方向通信もあります。
- そして最後に、統合された支払いシステム。
これらはすべて異なるサブシステムであり、ほとんどの部分で完全に異なるアーキテクチャ、インフラストラクチャ、さらには送信プロトコルと情報ストレージの原理があります。 ユーザーはこれをあまり気にしないので、個人アカウントを開発するときは、すべてのやり取りのためのある種の共通プラットフォームを構築するために一生懸命働き、モバイルアプリケーションを実装するときは、それを完了することが不可欠です。
通信の損失を最小限に抑えるために、AT ConsultingとRedmadrobotのプロジェクトチームは1つのオフィスサイトに移動し、長い間並んで働いていました。
覚えているなら、古い個人アカウントには、システムの最大加入者数に問題がありました。 新しい環境は、仮想環境の負荷に応じて拡張し始めました。 新しいモバイルソリューションは、スケーラビリティの点でも汎用性があります。
簡単に聞こえますが、個人アカウントの初期バージョン（2年以上前）では、統合システムとAPIサブシステムがボトルネックでした。 約1年半の間、上位層のアーキテクチャ全体を調べ、柔軟に作業することを妨げるすべてのものを取り除くことができました。 開発の方向が正しく選択されたことにより、アーキテクチャが大幅に変更され、簡素化されました。 これで、アプリケーションはセルフサービスシステム「My Beeline」と非常に緊密に統合されました。
認証の問題
アプリケーションは、多くの場合、電話のバランスとタブレットのSIMカードのバランス、およびホームインターネットのバランスが1つのアカウントのアカウントと見なされるユーザーを承認します。
セルフサービスチャネルへのアクセスの主な詳細は、個人アカウントからのログインとパスワードです。 パスワードは、短いUSSDコマンド（* 110 * 9＃）または他の方法を使用して、アプリケーションから取得できます。
将来的には、SSO（シングルログイン）に基づいてモバイルアプリケーションサービスを単一の承認ゾーンに統合する予定です。 さらに、キャビネット（たとえば、「Hi」サービスブロードバンド、ブロードバンドアクセス）と個人アカウントをマージする予定です。アプリケーションは、他の人を1つのキャビネットアカウントに「バインド」する機会があり、ログインなどですべての番号（家族など）を管理できます番号のみを使用します。 現在、Facebook、Vkontakteのソーシャルネットワークアカウントを使用した認証に取り組んでいます。
データセンター
データセンターは2つの異なる領域にあります。 これらは、Vimpelcomのメインおよびリザーブコンピューティングセンター（GVCおよびRVC）です。
各サイト（MCCおよびRVC）には、ソリューション用に複数のサーバーがインストールされています。 それぞれにアプリケーションのインスタンスがいくつかあります。 アプリケーションインスタンスがクラッシュしたり、サーバーに障害が発生したり、データセンターで事故が発生したりしても、トラフィックは自動的にバックアップ機器にリダイレクトされます。
リアルタイムの仕組み
さまざまなサービスを備えたAPIが、モバイルアプリケーションとのすべての統合が行われるフレームワーク内で、個人アカウントで作成されています。 サービスは、RESTful Webサービスの原則に基づいて構築されています。 より正確には、JAX-RS仕様に従って。 データはJSON形式で送信されるため、モバイルトラフィックの量を節約できます。 また、トラフィックを節約するために、送信データのアーカイブを実装しました。 すべてのサービスはステートレスの原則に従って実装されているため、問題なくスケーリングできます。
発売日
ユーザーがアプリケーションの問題を自信を持って解決し始めた後（ユーザビリティインデックス-86％、主観的な満足度-98％）、技術的な部分により、大まかに言って一般的なAPIの類似物によって必要な機能をすべて管理できるようになった後、レビューのためにアプリケーションを送信しました。 今ではすでに出ています。 もちろん、便利な機能で随時更新します。