特にオペレーティングシステムが毎年更新され、2〜3か月ごとに新しいデバイスが登場するモバイルテクノロジーの分野では、長い生産サイクル（市場投入までの時間）は悪です。 したがって、最小限の機能を備えたシンプルな製品を使用することを恐れる必要はありません。 アプリケーションの作業は、短い反復（更新の場合は1か月以内）と十分に確立されたフィードバックを伴う継続的な改善の形で行う必要があります。 言い換えれば、アプリケーションは徐々にだまされるはずです。
Redmadrobotモバイルアプリケーションサポートおよび開発部門のディレクターであるAlexander Alekhin（@alekhinsasha）は、プロセスの整理における経験を共有しています。
サポートが必要
当社の主な専門分野は、金融、保険、通信会社の顧客セルフサービス向けのサービスアプリケーションです。 そして、いくつかの特異性があります。 一方では、これらの企業には独自の顧客サービス部門があり、最初の質問とユーザーの苦情に対応しています。 一方、このようなアプリケーションのサポートには、顧客企業のサービスレベルに関連する、より高いレベルのサービス提供が必要です。
アプリケーションの公開後に解決する主なタスクは次のとおりです。
- 健康モニタリング;
- 製品のエンドユーザーからフィードバックを受け取り、問題の解決を支援します。
- 安定性の向上と新しい機能の追加。
- 新しいデバイスおよびOSバージョンへのアプリケーションの適合。
- 顧客企業のビジネスニーズの満足度を追跡します。
- 製品開発計画の調整。
そして、Redmadrobotでこれらの問題を解決する方法を次に示します。
ワークフローとサポートおよび開発プロセス
6つの主要プロセス内でITIL方法論に従って製品をサポートおよび開発するためのすべての活動を実施します。
- インシデントおよび問題管理
- 変更管理
- リリース管理
- サービス提供管理
- オーディエンス管理
- ビジネス価値管理
リリース管理
正式には、作業の結果は新しいリリースのリリースであるため、リリース管理プロセスはスキーム全体の中心と考えることができます。 次の連続した手順で構成されます。
- リリース計画
- リリースビルド
- リリースリリース
将来のリリースの構成は、次のものから形成されます。
- 動作中に特定された欠陥
- 以前のアップデートに含まれていない、または新しい要件の策定プロセスに含まれていない新機能
したがって、図に示すように、リリースに取り組むための「燃料」は、インシデントおよび問題管理プロセスと変更管理プロセスによって提供されます。
リリースのビルド作業はアジャイル手法に従っており、その構成は1つ以上のスプリントにパッケージ化されています。 Jiraは、タスクトラッカーとして使用されます。タスクトラッカーでは、個別のワークフローとアジャイルボードのセットをセットアップします。
Jiraでアジャイルボードを操作するトピックについては、Yandexのメンバーから詳細な記事をお勧めします。 Yandex.Picturesでどのように計画し、どのようにこれに到達しましたか。」
リリースの品質は、ユーザーレビュー、およびバックグラウンドレベルからのクラッシュレポートの数の偏差によって評価されます。
: — Jira : — — (Request for Change RFC) : — (Release Candidate) — : , , — : — QA- : — - — —
インシデントおよび問題管理
このプロセスの目的は、アプリケーションの操作中に検出された問題をタイムリーに解決することです。
定義によると：
インシデントとは、標準（通常）の使用シナリオの一部ではないイベントであり、アプリケーションを部分的または完全に使用できなくなったものです。
問題は、1つ以上のインシデントの原因不明です。
このプロセスでの作業は、古典的な3レベルのスキームに従って構築されます。
最初のレベル
オンラインサービスは、通話の単一のエントリポイントです。 アプリケーションの登録と分類を実行し、それらの優先順位と実行の責任者を決定し、典型的なインシデントを解決する責任があります。
最初に述べたように、このレベルのサポートはカスタマーサービス部門に提供されます。 運用サービスのスペシャリストに必要な文書と指示のみを提供し、第2レベルとの対話プロセスの構築を支援します。
第二レベル
サポートエンジニア-技術的な専門知識を実施し、非典型的なインシデントを解決し、アプリケーションナレッジベースを更新し、欠陥を特定して第3レベルのサポートに転送します。 同じレベルで、ミドルウェアが使用されている場合は管理されます。
理由が製品のアーキテクチャまたはソフトウェアの実装に関連している場合、問題解決は第3レベルに渡されます。
第三レベル
開発者とテスター-第2レベルで解決されない複雑なインシデントを分析し、欠陥を修正し、提供されたソリューションをテストします。
インシデントと問題に関する情報は、次の3つのチャネルを介して受け取ります。
- ヘルプデスクシステムはZendeskであり、アプリケーションの実行の登録、分類、監視が行われます
- 特に更新の公開後の最初の数日間、重大な欠陥を特定できるレビューを毎日監視するアプリケーションストア
- クラッシュ統計を収集し、自動的にタスクをバグトラッカーに記録するアプリケーションヘルスモニタリングシステム
: — Zendesk — Crashlytics Google Analytics — Jira : — — : — : — — — — -
変更管理
このプロセスの目的は、変更のコストと製品への影響を評価することです。
プロセスの一環として、RFCを受け取り、要件を詳細に説明し、実装に関連する変更、コスト、およびリスクの影響度を評価します。
すべての要求はトラッカーに分類され、ビジネスの重要度に応じて実装を分析した後、製品のバックログになるか、すぐに次のリリースのスプリントになります。
: — Jira : — RFC : — (Road Map) — : — — — -
オーディエンス管理
このプロセスの一環として、アプリケーションのエンドユーザーと直接やり取りします。
- 不足している欠陥を検出し、製品開発計画を調整するために、ユーザーのレビューを監視します
- 製品の機能に関する質問に答えてください（残念ながら、この機能は現在のところGoogle Playでのみ利用可能です）
- リリース計画について通知する
- 不適切なコメントをフィルタリングし、プラスの場合
つまり、ユーザーとの対話を行っており、製品に対するユーザーの意見が重要であることを明確にしています。
明らかに、アプリケーションストアで否定的なレビューを処理することはほとんど不可能です。 彼らは感情的で、情報価値がなく、フィードバックはありません。 したがって、フィードバックフォームを通じてサポートチームに問題を報告するようユーザーを動機付けます。 プロジェクトの標準である「アプリケーションについて」画面に表示されるか、ユーザーがデュースまたはデュースを挿入する場合は、評価時に開くことができます。
評価の維持に加えて、フィードバックフォームでは、分析に必要な情報（デバイスタイプ、OSバージョン、アカウント情報、コンテキスト）を収集できます。
評価ダイアログを表示する適切なタイミングの選択、およびネガティブな感情をリダイレクトするトリックについては、記事「アプリのレビューを促す」 （Maciloveからの翻訳）で詳しく説明されています。
: — Google Play Developer Console — iTunes Connect — Windows Phone Dev Center — AppAnnie — : — — , : — — : —
ビジネス価値管理
製品開発の観点から最も重要なプロセス。 その目標は、製品の変更を計画して、ビジネスによって設定された主要業績評価指標を達成することです。
すべてのモバイルビジネスアプリケーションの半分以上が、メトリックをまったく追跡していないと思います。 せいぜい、Googleアナリティクスのユーザー数を監視するだけです。 このような状況で製品の設計と機能を変更する決定は、本能によって行われ、実証されていません。 一方、製品の品質を継続的に改善するには、ビジネス目標と同期した主要な指標を数え、分析することが重要です。
このプロセスは、コンバージョンファンネルの各段階での指標の収集と分析に基づいています。 プロセスの一環として、次の活動を実施します。
- 追跡および分析システムの調整
- 特定のビジネス目標の達成を評価するためのアプリケーション内のファンネル設計
- メトリックの変化のダイナミクスの視覚化
- 分析の分野でのコンサルティング（占いではなく、メトリックスの観点からビジネスにとって良いことと悪いこと）
- メトリックス改善活動
- 直接的な競合分析
: — AppsFlyer — Flurry — Google Analytics — AppAnnie — AppInTop : — : — Road Map : — - —
サービス提供管理
このプロセスの目的は、署名されたSLAへの準拠を監視し、サポートサービスの品質を向上させることです。
サービスレベルアグリーメントまたはSLA（サービスレベルアグリーメント）は、サポートの一部として提供されるサービス、これらのサービスを提供する手順、および次のような測定可能な品質指標を説明する文書です。
- アプリケーション応答時間
- 重大度とビジネスプロセスへの影響の程度に応じて、インシデントと欠陥を解決する時間
SLAの詳細については、 「初心者向けのSLA」をご覧ください。
現在、契約には2つのオプションを選択できます。基本と拡張、アプリケーションと問題解決への応答時間の違い、アプリケーションの状態を評価するために監視するチャネルの数です。
出力では、プロセスは、サポートの品質および製品の一般的な状態に関するアイデアをすべての関係者に提供するレポートを生成します。 レポート作成の実験中に、次の形式に決めました。
発生した重大な問題、またはSLAの範囲を超える期限切れのタスクについてリリースマネージャーに通知する毎日のレポートは、何か重大な問題が発生したときにオンになる一種のサイレンです。 日次レポートでは、アプリケーションストアでの否定的なレビューのバーストが考慮されます。これは、更新後の最初の数日間は特に重要です。
週次レポートは、追跡するすべてのチャネルで受信したフィードバックモニターです。 レポートは3つの部分で構成されます。
- チケットの種類ごとのZendeskチケット統計：
- 変更リクエスト
- 事件
- 欠陥
- Crashlyticsクラッシュ統計。これは、リリースの安定性に関するアイデアを提供します。 障害が発生するたびに、発生したエラーに関するメッセージが生成され、特定の重大度レベルを超えると、バグトラッカーに自動的に到達します。
- 毎週のレーティングの変更、レビューの総数、および行われた欠陥の数を考慮した、アプリストアのレビューに関する統計。 定量的な指標に加えて、サポートエンジニアは自由形式でレビューの定性的な説明を行い、明らかな問題と頻繁なユーザーリクエストに焦点を当てます。
月次レポートには、サポートコストの予算編成とアカウンティングに各スペシャリストが費やした時間数に関する情報と、体系的な違反を特定して管理上の決定を下すことを可能にするSLAの準拠率が含まれています。 このレポートは、プロジェクトオフィスとサポートおよび開発部門のマネージャーを対象としています。
: — Zendesk — Jira : — — (, ) : — , : —
結論
- 必ず、短い反復で作業の正確さを顧客に納得させてください。 彼に本を手に入れて、やり直してください。 継続的な改善モデルに基づいて成功した製品を引用します。 このアプローチのみが、ビジネスニーズと顧客のニーズに最大限の満足をもたらすことを証明します。
- 製品のサポートシステムを構築します。 それなしでは、多かれ少なかれ大規模な顧客と仕事をすることはできません。 SLAがない場合は、入札への参加も許可されない可能性があります。