はじめに
アナリストとして働く過程で、プロジェクトの失敗の原因を繰り返し分析しなければなりませんでした。 経験を積むにつれて、私は顧客と協力するための特定の方法論を開発しました。それを共有したいと思います。
製品、プロジェクト、またはサービスのあいまいな要件に対処しなければならなかっただけではないと思います。 多くの場合、顧客は「非常に忙しい」、「詳細な議論にアクセスできない」などです。 時間が経つにつれて、私は顧客を「適格」と「未熟練」に分けるための基準を開発しました。以下に説明する方法のおかげで、それぞれが既存のタスク（受け取った人と設定した人の両方）をすばやく監査できるようになります
この文脈での「未熟」は否定的な意味合いを持ちません。 この用語の意味は、顧客の機能を実行する経験の不足を説明するために使用されます。 もちろん、パフォーマーも未熟です。 しかし、この記事では、パフォーマーの問題は考慮されません。
以下に、顧客が適格な注文を作成できるようにする方法を説明します。 「デモ」で「私が望んでいたものとはまったく違う」が展開されたときに、この方法がこうした状況を軽減することを願っています。
理論のビット
原則として、問題解決の過程で協力はどのように組織されますか？
- 彼の活動に困難を経験している顧客がいます-彼は所望の結果を独立して得ることができません。
- この顧客は問題を定式化し、問題を解決できるアーティストを探しています。
- 請負業者が正しい結果を提供するために、両当事者は、顧客による結果の受け入れ基準に同意します。
- 同時に、顧客と請負業者の両方に資格が必要です。 1つ目は結果を受け入れるための基準を策定することができ、2つ目は基準を満たす結果を提供することです。
少なくとも1つの条件が満たされない場合、問題は解決されません。
理論を実践する
原則として、このモデルは機能しますが、家庭レベル（現在のタップを修理したり、エンジンオイルを交換したりする）や、実際の製品やサービスが生産される専門分野（エンジニアやアナリストの仕事の結果）で問題を引き起こすことはありません。
ケースを想像してください-1人の開発者がデータベースを作成し、視覚化のためのフロントエンドを必要とします。 彼自身は方法を知らず、自分の問題を解決する実行者（サービス）を探しています。 サービスのタスクを設定するとき、顧客（ベースホルダー）は問題を説明し（データベースに保存された情報を視覚化できません）、インターフェイスを公開し、受け入れ基準（機能、コスト、技術）を定義します。
これらの3つのポイントのうち少なくとも1つが注文に含まれていない場合、顧客自身が請負業者から何を受け取りたいかを完全に理解していないと考えられます。 そのような注文は資格がなく、請負業者はそのようなタスクを引き受けてはなりません。 「推測しない」リスクは大きい。
同様のアプローチがアナリストに適用されます。 サービスとして機能するアナリストは、顧客と会い、問題を特定し、設計されたソリューションが「フック」する必要のあるインターフェースを受け取り、受け入れ基準を修正します。 顧客が「賢く考えて、何かを考えて」と言った場合、アナリストは通常、このタスクを引き受けない方が良いと考えます。 顧客は「未熟」であり、結果を受け入れて配信するときに問題が発生します。
理論を実践する-2
開発者とアナリストは、TK、仕様を使用して注文要件を修正する方法を長い間学びましたが、管理レベルに移行すると、すべてが変化することがわかります。 別のエンジニアの注文を明確に策定した昨日のエンジニアは、マネージャーのカテゴリーに移ったときに非常に漠然とタスクを策定し始めます。
私はほぼ毎日、100人のマネージャーからの資格のない注文の例に会わなければなりません。 典型的なサンプルは次のとおりです。
- 「リリースのバグの数に問題があります。 より徹底的にテストし、ユーザーに可能なすべてのオプションを作成する必要があります。」
- 「プロセスの透明性を高めるために、KPIを使用します。 各グループのリーダーは、グループの作業の結果を評価する指標を示すアプリケーションを作成する必要があります。
- 「2つの競合製品のどちらをさらに開発するかを選択するには、市場を分析し、それに基づいて選択を行うことができる提案書を作成する製品担当者を任命する必要があります。」
それはおなじみですか？
読者、これらの各タスクはどれほど成功すると思いますか？ 私がアナリストとして働いていたとき、私は一度も二度もそのような命令を実行することができませんでした。
時間が経つにつれて、私自身が頭の中で成長し、自分の実践では、順序（またはタスク）の正しい修飾された文言が、最初の反復で問題を解決する可能性を大幅に高めると繰り返し確信していました。
資格のある顧客マネージャーを取得するにはどうすればよいですか？ 彼は何を学び、彼が望むものを正確に得るために従うべき方法論を学ぶ必要がありますか？ エンジニアの方法と類似して、マネージャーは、注文を作成するときに、3つのポイントを決定する必要があります。
- 問題の言葉遣い。 難易度の本質を判断し、1〜2文で説明します（初心者向け）。
- 受け入れ基準。 各基準は、「この問題を解決したことをどのように理解できますか？」という質問に対する答えを表しています。 この質問に対する回答は、顧客と請負業者の両方に、結果が最終的にどのように評価されるかについて明確なアイデアを提供します。これらの回答の文言により、リストに優先順位を付けた場合、ソリューションのMVPを決定することもできます。
- エンジニアが議論するインターフェースとの類推により、依存領域を定義する必要があります。 問題の解決策と相互に関連するすべての領域に変更について通知する必要があり、変更自体を行うことができます。
少なくとも1つの質問に明確な回答がない場合、請負業者への注文は不適格となり、引き受ける価値はありません。
上記の例の1つを例にとり、提案されたスキームに従ってそれを分解し始めます。 一般的なマネージャーの問題は次のとおりです。会社には2つの競合する開発があります。 決定を下す必要があります-どちらを選択しますか？
資格のないお客様-マネージャー：
競合する開発を選択するために、彼は製品所有者を招待し、「製品戦略を開発し、製品を選択するための情報を提供する」タスクを設定します。 そして、期限は-最初の測定-1か月後です。
通常、1か月後に見るのに最適なのは、一般的なフレーズを含むPPのスライドです。 通常、これは「私が望んでいたものではありません」。 そして、オプションを列挙するサイクルは、定式化されていない注文の解を求めて始まります。 請負業者は忙しく、仕事の質について苦情はありません。 しかし、結果からも満足のいくものはありません。 徐々に、アイデアは終わりのない議論に退化します。
資格のある顧客はどのように働いていますか？
マネージャーは、「エンジニアリング」形式で注文を発行します。
問題の定式化：開発する製品を決定することはできません（または両方とも可能ですか？）
受け入れ基準：問題を解決したことをどのように理解しますか？ 決定を下すには何が必要ですか？ （例として）：
- 工業操業の準備状況の評価が表示されます（優先度が高い）。
- ソリューションは、顧客の基本的な機能要件を満たす必要があります。
- 使用されるテクノロジーのスタックの展望と現代性。 等 そのようなリストは長くなる場合がありますが、基準をより正確に定式化するほど、決定が容易になります。 最も重要なことは、決定が正当化されることです。
決定の結果として変化する依存タスクを策定します
- 製品コンセプト：どのように変化しますか？
- 経済モデル：決定は収益化モデルにどのように影響しますか？
- 生産コンポーネント：決定が下された後、技術スタックはどのように変化しますか？
- スタッフィング-現在のスタッフの資格で製品を開発できますか？
まとめ
資格のある顧客であるマネージャーは、請負業者の注文（タスク）を次のように策定します。
- 問題を定義します（解決策がまだわかっていない問題を定式化します）
- 結果の受け入れ基準を定義します（問題が解決される条件を説明します）
- 請負業者が問題を解決するときに考慮する必要がある依存タスクを定義します。
このトピックが興味深いと判明した場合、次の記事は「未熟な」パフォーマーに捧げられます。