開発の最初の段階では、顧客は常に満足しています。顧客の期待が開発されたものと一致しない場合、顧客は不満になります。 顧客と開発マネージャーは一つのことについて話し、彼らは「計画」や「リスク」のようなスマートな言葉を使っているようで、クライアントは完成品に熱心ではなかったようです。 どうして？
クライアントは、ビジネス上の問題を解決するためのツールを考えて、原則として、このツールに関するいくつかのアイデアを、時には非常に一般的で、時には非常に詳細かつ具体的に既に与えられています。 多くの場合、表現には、このクライアントと競合他社の両方の経験だけでなく、消費者とその行動に関する知識も含まれます。 クライアントは、ビジネスタスクとそのコンテキストを使用して、ツールからの期待を形成し、このツール自体を開発するために専門家に依頼します。 来て、彼はツールが欲しいと言います。
開発マネージャーは、独自のコンテキストと経験を持ち、使いやすさ、開発会社のメリット、プロジェクト予算のステレオタイプを通してこの欲求を見ています。 そして、それはツールに関する最初のアイデアを形成し、それらを修正して顧客に提示します。
顧客は、一般的な表現ではプレゼンテーションが彼を満足させていると見ますが、彼は知識の文脈でこれをチェックします。 矛盾を見つけた場合、彼は質問をしますが、さらに悪いことに、要件が一般的なリストによって修正され、コンテキストにうまく収まる場合。 その後、顧客は開発の開始に満足し、タスクが設定され、作業が本格化します。
開発の過程で、マネージャーは顧客のツールのさまざまなコンポーネントの最終的な詳細を確定し、顧客は細部と期限に注意を払い、マネージャーの仕事に満足し、ツールを迅速に運用することを楽しみにしており、その結果、マネージャーはビジネスタスクに対する迅速かつ高品質のソリューションを手間いらずに提供することを楽しみにしていますそのような忠実な顧客へのプロジェクト、実行会社の利益とボーナス。
しかし、顧客の結果の最初のプレゼンテーションでは、失望が待っています-このツールは問題を解決するだけでなく、顧客企業の既存のビジネスプロセスにも適合しません。 「しかし、あなたはそのような制限について話さなかった、それについて言葉がない仕事の声明書に署名した！」-マネージャーのフラストレーションは増大している、彼はすでにクライアントが不注意な素人だと考えている。 「そして、あなたはこれらの微妙さとニュアンスについて尋ねませんでした」-クライアントは開発と開発者にもはや満足していません。
そして、ツールの最初の議論で問題が発生し、マネージャーと顧客の両方が同意せず、同意しませんでした。 顧客が保存したコンテキストは、ツール開発プロジェクトのコンテキストになっていません。 マネージャーはツールの機能について説明しましたが、クライアントのビジネス上の問題を解決する段階についての彼のアイデアが、クライアントによって概説されたものと一致するかどうかを確認しませんでした。 だから、私の例からはまさに誰もが理解できるが、味、嗜癖、ステレオタイプの一致を保証するものではないことが判明した。
私の経験から、これは話すことによってのみ避けることができます。 クライアントと彼のビジネスについて詳しく話し、声を出して書き留め、スケッチや図を描きます。
特定のシステム機能ではなく、タスクとユーザーについて話します。
-オンラインストアが欲しい。
-はい、10万ルーブルを行います。
このダイアログは、残念ながら、クライアントとのコミュニケーションの典型的な例です。 はい。最初の顧客との会談で、店が何を売るのか、顧客は誰なのか、商品をどのように選択して購入するのかを知るのは高価です。 さらに、販売は行われない可能性があり、このお金は単にパイプに飛び込みます。 しかし、楽器の作り直しはより費用がかかり、契約上の義務が既にあり、クライアントは開発会社に満足しなくなり、このイメージの損失はサービスを提供する会社にとって重大です。
用語を避けてください。
-請求システムと統合された名刺サイトを持っています。
-これは名刺ではなく、企業サイトです。
タスクを明確にし、ユーザーの行動をシミュレートし、システムの基本機能を明確にした後、開発マネージャーは自分がどのように、そして何を開発するかを想像します。 クライアントが理解できない用語を避けて、これを日常の言語でクライアントに伝え、提示されたシステムが彼の期待に合うかどうかを確認し、時間内に放置されたポイントを指摘するようにします。 そして、これらの用語についての彼自身のアイデアの点で彼が動けなくなった場合、合意は機能しません。 結局のところ、誰もが独自の方法で「リンゴ」さえも理解しており、ここに「ストレステスト」と「アジャイル」、純粋な推測と期待があります。
ビジネス目標を追求します。
-便器の販売方法を教えないでください。ここに購入ボタンを引いて、ここにバナーを配置します。
クライアントが特定のフィールドや要素についてシステムについて話す準備ができていても、ツールの各部分のビジネスのコンテキストにおける目標や目的から逸脱しないでください。 コンテキストが表示されるのは、ビジネスの観点からのツールのタスクのリストと、クライアントの期待です。 また、クライアントがフィールドとボタンについて議論することを主張する場合は、それらも議論しますが、ツールのこの部分の特定のタスクを修正した後です。
調べてもう一度質問してください。
明白で、ファイナライズして、ダブルチェックするほど、クライアントの期待について学ぶことが多くなります。 開発マネージャーとしてのソリューションが明らかであるように見えても、クライアントにこのソリューションについて伝え、一般的なモデルで記述し、このアクションが時間または予算によってブラックホールを作成しないことを確認してください。 クライアントは、そのような対話にうんざりしているが、装飾的に使われたお金ではなく、問題を解決する彼のビジネスで働くツールを受け取ることに感謝するだろう。
もちろん、これは原始的です。 間違いなく、それはすべての不正確さから救いません。 はい。ビジネスアナリストは要件を指定でき、システムアナリストはそれらをソフトウェア製品の要件に適用します。これは、顧客に必要なツールの基礎となります。 しかし、プロジェクトの条件、予算、コミッショニングに関する責任をマネージャーから解放する人はいません。 また、会社に対する顧客満足の責任もマネージャーの肩に残ります。 だからこそ、これらの見た目は平凡なことを忘れてはなりません。
「350〜450グラムの青酸っぱいリンゴ（おばあさんのスミスや種の品種）」と私は買い物リストに書いた。 それから彼女は考えて、そして付け加えました：「葉なしで、しかし尾で。 尾の色は重要ではありません。」
