フロントエンドインフラストラクチャの有効性の値を測定する方法は?

フロントエンドインフラストラクチャの有効性の値を測定する方法は?
「フロントエンドとバックワード」のWeChat公式アカウントに注意してください。フロントエンド、Node.js、サーバー側テクノロジーなどのトピックを含む、一連の「意図的にオリジナル」の高品質な技術記事が表示されます。

EDITORIAL
、市販の製品とは異なる、内部ツール/プラットフォームは、一般的に明確で直接的なビジネス価値を持っていない、それは定量化指標を介して自分の価値の効果を測定する必要がある、指標データの枠組みを確立するために、本論文の試みは直接適用することができるので、内部ツールその/プラットフォームの価値も見て説明することができます

1.生産活動のコア要素を分析
するオブジェクト指向の観点から、フロントエンドエンジニアリングは、オブジェクトとオブジェクト間の関係と相互作用です。

(オブジェクト指向の観点からのフロントエンドエンジニアリングシステムから)

その中で、オブジェクトは、サブジェクトオブジェクトとオブジェクトオブジェクトの2つのタイプに分けられます。

オブジェクトは、フロントエンドアプリケーションの制作アクティビティにおけるさまざまなエンティティの抽象化です。オブジェクトの一部はサブジェクト(さまざまな役割の人など)であり、その他はオブジェクト(ツール、プラットフォーム、その他の特定のものなど)です。フロントエンドアプリケーションの開発と配信を完了するためのインタラクティブな動作

人とツールは、生産性に直接関係するコア要素です。

フロントエンドインフラストラクチャの有効性の値を測定する方法は?

ツールが強力でインテリジェントであればあるほど、人間の操作の効率が高くなり、精神的な負担が少なくなります。

PSマインドとは、人々が物事を認識する方法と習慣を指します。これは、ユーザーが周囲の世界をどのように認識し、行動を起こすかに影響します。これは、対応する役割、記憶、チャネル、および能動的および受動的な教育の方法の認知状況に依存し、競合製品等の役割の使用習慣については、工具製品の経験測定の4軸モデル(1)を参照してください。

2.
ツールの主要な目標特定します。ツールの場合、効率と経験を考慮することは常に目標ですが、ツールが異なれば、次のように焦点が異なる場合があります。

  • モジュールの構築、モジュールの公開など、ユーザーと直接向き合わない低レベルのツールは、効率が比較的重要であり、経験が2番目です。

  • ユーザーが直接操作する上位レベルのツール(デバッガー、リリースプラットフォームなど)は、効率も重要ですが、エクスペリエンスにさらに注意を払います。

  • 一方、ツールは常に問題を解決するために生まれ、ツールの選択は4つの状況にすぎません。

  • かけがえのない:目標の問題を解決できる唯一のツールであり、選択の余地がないため、経験や効率がどれほどであっても、それを使用する必要があります

  • 最高のエクスペリエンス:同様のツールの中で最高のエクスペリエンスであり、ニーズを正確に満たし、他のツールとの効率に明らかな違いはありません。

  • 最も効率的:同じツールの中で最も効率的なもので、問題をすばやく解決し、明らかに他のツールよりもはるかに高速です

  • 経験は悪くなく、効率はまともです。経験と効率のバランスが取れており、明らかな欠点がなく、問題をほとんど解決できず、使用するのもそれほど面倒ではない同じ種類のツールです。

  • 選択の余地がない場合を除いて、効率に明らかなギャップがない場合は経験の豊富なツールが人気であり、欠陥がない場合は効率の明らかなギャップを開くことができるツールが非常に人気があります。

  • ただし、経験と効率の点で最良のオプションに明らかな欠点がある場合、ユーザーは、その欠点に長期間耐えるよりも、十分ではない代替ツールを選択する傾向があることに注意してください。

何。はい。xxxは使いたくない

3.有効性値の測定モデルの確立
主要な目的を決定した後、次の質問は、効率と経験を定量化して測定できるようにする方法です。

効率と
アナログ作業効率を測定するための計算式:

作業効率=合計作業/作業時間
ツール効率は次のように定義できます。

ツールの効率=問題のスケール/操作時間
問題のスケールはまだ定量化できるものではなく、さらに時間コストとして特徴付けられます。

ツールの効率=時間コスト(ツールなしで必要)/時間コスト(ツールで解決)
次に、3つの状況があります。

  • 比率は1に等しい:ツールはツールの有無にかかわらず同じであり、ツールは効率の改善をもたらさない

  • 比率は1未満です。ツールの使用に時間がかかるため、使用しない方がよいでしょう。

  • 1より大きい比率:ツールはより効率的であり、値が大きいほど、ツールによってもたらされる効率の向上がより明白になります。

経験の測定は
、正確な値を取得するために統一されたルールを通じて計算できる効率とは異なりますが、測定モデルを確立することもできます。

フロントエンドインフラストラクチャの有効性の値を測定する方法は?

経験とは、製品とユーザーの心(上の図の心の線)の重なりの程度を指します。ツールの機能とパフォーマンスがユーザーの心理的期待に近いほど、経験の評価が高くなります。これは次のように反映されます。

  • 使いやすさ:ユーザーの心から製品の機能へのマッピング、究極の使いやすさは直感的ですぐに使用できます

  • 安定性:ユーザーの心から製品のパフォーマンスへのマッピング、究極の安定性は完全な信頼であり、ツールがうまくいかないことを疑うことはありません

これは:


工具体验 = 易用程度 * 稳定程度

つまり、ツールエクスペリエンスは使いやすさと安定性の産物であり、使いにくい、または不安定な欠点がある限り、エクスペリエンスは急激に低下します。

パフォーマンス値の
要約を測定します。効率値をもたらすツールは、次の2つの側面に反映されます。


效能价值 = 效率价值 * 体验因子

その中で:

  • 効率値:ユーザーが問題を解決するための時間コストを削減し、ユーザーが問題をより迅速に解決できるようにします

  • 経験要因:ユーザーの精神的負担を軽減し、ユーザーが問題をより簡単かつ楽しく解決できるようにします

この2つは互いに補完し合い、エクスペリエンスのアップグレードにより効率が向上する可能性があり、効率の向上によってエクスペリエンスが向上する可能性もあります。

したがって、経験が保証されているという前提の下で、効率はパフォーマンス値の尺度として簡単に使用でき、正確な比率を使用してパフォーマンス値を定量化できます。

4.適切なデータインジケーターの選択
測定モデルが確立されると、特定のデータインジケーターがボックスで囲まれます。


上記の分析に基づくと、時間コスト(エクスペリエンスが保証されている場合)は、ツールによって節約された時間コストを直接反映します。これは、ユーザー数、使用頻度、および使用期間に密接に関連しています。

  • ユーザー数:累積ユーザー数、日次/週次/月次UV、日次新規ユーザー、日次/週次/月次アクティブユーザー(期間中にコア機能を操作したユーザー数)

  • 使用頻度:日次/週次/月次PV、機能使用率、コア稼働時間、日次平均使用時間

  • 使用時間:コア稼働時間

PS関数の使用率=特定の関数を使用しているユーザーの数/ユーザーの総数。これは、全体に対するさまざまな関数の寄与を測定するためにも使用できます。

例えば:

每天节省的时间成本 = 日用户量 * 日功能使用率 * (不用该工具解决所需的时间 - 操作时间)
  = 100 * 35% * (1.5人日 - 0.8人日)
  = 24.5人日

さらに、他のいくつかのサイドデータも有効性の値を反映できます。

  • ユーザー分布:ターゲットユーザー数、ユーザー***率、各属性のユーザーの割合、各属性のユーザー***率

  • 出力結果の分布:量、重要度、平均時間、各属性の出力結果の割合

PSユーザー***レートは、ユーザー***レート=既存のユーザー数/ターゲットユーザー数として簡単に理解できます。

例えば:


覆盖2/3的目标用户,包括60%以上的一线开发人员、10%的测试人员
覆盖8大产品线,半年支持40多个项目,包括效果极好的xx重点项目


使いやすさは、いくつかの数値で測定することもできます。

  • ユーザー満足度:ユーザーの苦情や問い合わせの数/率、サンプル調査の満足度

  • 操作の難しさ:誤操作の数

  • 精神的負担:ヘルプドキュメントの単語数とメモの数

さらに、製品マネージャーが使用する一般的な要件収集方法は、実際のユーザーの実際の操作を観察し、ユーザーが遭遇したフラストレーションを記録することです。プロセスを中断したり、急いで支援を提供したりしないでください。多くの場合、使用上の問題を正確に見つけることができます。


安定性の程度安定性の程度、次のような異常な指標から反映される可能性があります。

  • クラッシュ率

  • バグの数

  • 操作の失敗時間

その中で、操作の失敗は、ランタイムエラー、サービスインターフェイスエラー、検索結果なしなどのあいまいな定義です。安定性の問題は、ユーザーエクスペリエンスを簡単に破壊し、パフォーマンスを大幅に低下させる可能性があります。たとえば、ツールは常にクラッシュし、ほとんど役に立たなくなります。 、有効性の価値について話す方法はありません

5.データがある場合は、データを使用して話します。
定量化可能なデータインジケーターを確立する理由は、データを使用して以前の仮定のいくつかを検証し、ツールの反復と最適化のガイダンスを提供するためです。

  • 新機能はユーザーによってサポートされていますか?機能使用率はいくらですか?プロモーションチャネルは効果的ですか?

  • ユーザーの操作はスムーズで、実際に費やした時間と予想した時間の間に大きなギャップがありますか?

  • 結果はどうなりますか、ROIは十分に高いですか、継続する必要がありますか?

PMの成熟した方法論で物事を行う

おすすめ

転載: blog.51cto.com/15080030/2589243