project-management - 変化する要件に関して、顧客をどのように管理していますか?

Question

Steve Yegge の知恵にもかかわらず、ほとんどの開発者は、技術に詳しくない顧客から集められた要件に直面しています。顧客に対応し、要件を翻訳するプロジェクト マネージャーがいる場合もあれば、そうでない場合もあります。いずれにせよ、要件が変わることは避けられないことです。

「優れたプログラミング手法」を構成するもののほとんどは、変化する要件に耐えられるように適応可能なシステムを開発することに関係しています。YAGNI、DRY、疎結合などの原則がこれに貢献しています。アジャイルなどの反復的な開発プロセスも、動くターゲットを攻撃しようとする懸念に対処しようとします。もちろん、システムをテストすることで、変更を加える可能性が無限に高くなります。

それにもかかわらず、私たちの多くにとって、要件を変更すると、ソフトウェアの品質が損なわれるだけでなく、モチベーションが低下し、誰かを刺したくなるようです。

この質問は、恣意的または軽微な変更を思いとどまらせながら、必要な方法で要件を変更できるように顧客を管理する方法に関するものです。どのようにしますか？

• 開発者を顧客から隔離するプロジェクト マネージャーはいますか?
• 正式な変更管理プロセスはありますか? マネージャーを変更しますか？
• 顧客が本当に必要なときに釣り銭を手に入れるのはどれほど難しいですか?
• 逆に言えば、「軽薄」な場合、顧客はどの程度おつりを手に入れやすいのでしょうか?
• 変更のコストを説明する際、顧客にどの程度詳細に説明しますか?
• 変更のリクエストを受け取った後、顧客にこの情報をどのくらい迅速に提供できますか?
• プロセスを台無しにする要因は何ですか (例:顧客にノーと言えない PM は? )
• あなたにとって何が効果的ですか？

Answer 1

あなたが顧客が決して彼の考えを変えない理想的な世界を探しているか、あなたが理想的なスペックを手に入れているなら-あなたは間違ったビジネスにいます。そうは言っても、顧客の期待と変更要求を管理するために私が見つけた最も効果的なメカニズムは、正確な測定システムを確立することです。

これが私のチームの運営方法です。

1）ユーザーストーリーから始めます。顧客はそれらの作成に関与し、開発チームは各ユーザーストーリーに相対的な方法でかかる時間を見積もります。

2）以前の経験を使用して、これらの相対的な見積もり（ストーリーポイント）を取得し、プロジェクトの主要なマイルストーンが完了する時期の大まかなスケジュールを作成します。

3）これらのマイルストーン内で、2週間の反復を実行します。顧客は、承認基準の設定と、ストーリーが承認されたかどうかに関与します。単純なバーンダウンチャートは、打ち上げ目標の達成にどれだけ近づいているかを顧客に示します。

4）多くの場合、承認セッション中に、機能が（元の承認基準を満たしていても）期待どおりに機能しなかったため、顧客は変更を要求します。この時点で、新しい見積もりで新しいストーリーを生成します。マイルストーンの日付を適切に調整することもできます。これにより、ボールがカスタマーコートに戻されます。

• 多くの場合、彼らは変更要求が価値がないことに気づき（彼らは上司から承認を得る必要があります）、私たちは新しい機能を殺します
• 重要な場合もあるので、機能を取得する期限を延期します
• そして最後に、同等の時間がかかる別のそれほど重要ではない機能を強制終了するオプションが常にあります。

重要なのは、変更要求から逃げ出すことではなく、すべての変更要求が製品に影響を与えることを確立することです。フリーランチのようなものはありません。

Answer 2

私は独立した開発者として働いているので、顧客と直接接触します。ほとんどの場合、彼らが実際に何を望んでいるのかわからないのは普通のことです。ですから、私たちはゆっくりと始めて、早い段階でプロトタイプを提供して遊んでから、徐々に変更を加えていきます。顧客が「軽薄な」変更を望んでいると思われる場合は、この変更は機能しない、または必要ないと伝えます。5 分の作業であれば、とにかく実行することもできます。

後で発生する小さな変更に対してお金を稼ぐために、後で契約にいくつかのメンテナンス条項を追加すると役立ちます. より大きな変更の場合は、時間単位で請求するだけです。

Answer 3

顧客管理は難しく、非常に簡単に失敗する可能性があります。

いち早くお客様の信頼を得る必要があると思います。私にとっては、次の方法でこれを行うことができると思います：

• プロダクト マネージャーを任命するよう顧客に依頼します。プロダクト マネージャーは、顧客が望む要件を十分に説明できる明確な思考を持ち、顧客との強力な協力関係の構築を目指します。
• 彼らのビジネスを本当に理解するように努めてください。ドメインの専門家である必要はありませんが、顧客がどこから来たのかを知る必要があります。
• 彼らが何を望んでいるのかについて、適切な質問をしてください。
• まず、すべての変更を歓迎します。これは、顧客が気まぐれで気まぐれであるということではなく、顧客が本当に望んでいるものをよりよく理解するための機会です。これにより時間や費用がかかる場合は、損失リーダーとして受け入れる必要があるかもしれません。
• プロトタイプを早期に提供し、実行可能な限り多くの顧客からのフィードバックを取り入れます。
• 顧客に素晴らしい製品を提供します。

これが完了し、顧客があなたを信頼すると、不当な変更を拒否したり、以前は範囲外と見なされていたものに対して追加の支払いや時間を要求したりできるようになります。

もちろん、すべての顧客とこの種の関係を築くことはできません。馬鹿な人もいます (この場合、別のプロダクト マネージャーを任命できるかどうかを確認してください) 。効果的な仕事上の関係。

Answer 4

「要件の変化」よりも、進化する要件という用語を使用したいと思います。MMLehman 教授 ( http://www.doc.ic.ac.uk/~mml/およびhttp://en.wikipedia.org/wiki/Meir_Manny_Lehman ) は、ソフトウェアの進化に関する研究に多大な貢献をしました。彼の研究は、すべてのタイプの要件が進化するわけではないことも示唆しています。要件が同じままであるこれらのシステム (つまり、数学ライブラリなど) のいずれかで作業することができれば、自分は幸運だと考えるかもしれません。

私たちの経験上、開発者は要件に関する情報をできるだけ前もって好むのに対し、顧客やエンドユーザーは開発プロセスのできるだけ遅い段階で要件を指定または調整できることを重視しています。前者は、ソリューションの計画と設計に役立つ詳細な情報を必要とします。後者は、変化する環境や結果として得られる情報に対応するための操作の余地を顧客に与えるため、要件を後から変更することで戦略的優位性を得ることができます。プロジェクトの初期段階/反復。詳細な計画を持つ能力と物事を変更する能力との間のトレードオフは、開発プロセス自体 (ウォーターフォール、アジャイル、スパイラルなど) を大きく決定します。

要件の進化を管理するための実用的なアドバイス:

• 進化する要件、複数のチェックポイント、または反復を考慮して、初期計画に余裕を持たせます。

• ある種のプロトタイピングまたは実現可能性調査によって明確になる可能性が高いように、プロジェクトの最初に不安定な要件を入れるか、プロジェクトの後半に変更を計画します。

• 要件がまだ関連していることを監視します。

• 現在の要件の優先順位を付けた最新のリストを手元に用意してください。相対的な優先度とコストを含め、現在の「必須」をすべての利害関係者に適切に可視化することとして、進化を制御し続けるのに役立つものは他にありません。

• どれくらいの時間がかかるかについての顧客の期待を管理し続けます。これは、集中力を維持するのにも役立ちます。

• 必要に応じて、要件を変更または追加するための正式なプロセスを導入します。プロセスの説明では、関与するこれらの役割、レビューの頻度などを指定する必要があります。これは、政治的および最も日和見的であるが必須ではない要件に対する優れた保護手段として機能する可能性があります。

• 最初のバージョンであっても、リファクタリングのためにしばらくビルドします。開発中に追加の知識を得た結果として、ソリューションの全部または一部を破棄する可能性が非常に高くなります。

Answer 5

顧客が最初から何を求めているかを知っているとは期待できないため、順応性が必要です。しかし、変化のために変化を止める必要もあります。

これは「内部」のお客様向けです。

顧客との交渉が効果的な方法であることがわかりました。彼らはそれを待つか、他の (まだ実装されていない) 機能を犠牲にすれば、どんな機能でも手に入れることができます。これにより、システム全体に関連して求めている変更の価値について考えるようになります。

場合によっては、これがうまく機能し、適切な妥協点に達することもあります。また、顧客が乳母車からおもちゃを放り出し、機能を実装する必要があり、品質が低下することがあります。

顧客が支払う場合、それは別の球技です。コストの変更、および製品が完成に近づくにつれてコストが増加することを認識させる必要があります。これは、何を提供するかについて事前に多くの分析を行い、仕様が合意されていることを確認する必要があることを意味します。そうすれば、何が変わったのかを測定できます。これはどちらの当事者にとっても最も効果的な解決策ではないかもしれませんが、物事をカットアンドドライに保ちます. そのため、彼らは不満を抱いておらず、無料で大量の仕事をすることにはなりません。

Answer 6

ソフトウェア エンジニアリングでは、変化は単なる事実です。それは起こります。私たちにとって、すべてには代償が伴います。クライアントが望む変更はほぼすべて行いますが、時間の見積もりとそれに伴う費用が常に発生します。クライアントにノーと言ったことはありますか? 通常はそうではありませんが、変更要求が非常に高額になることがあります。潜在的なセキュリティ上の脅威などについては一線を画しますが、その場合は、ご要望に応じることができないことを冷静に説明します。

顧客にどこまで説明するか、どこに資金を配分するか、これを開発に、これを分析に、などを説明します。なぜそのようなコストがかかるのかを明確に伝えません。認めますが、これは一部のクライアントによって少し異なります。それらのいくつかは、正確に何時間どこで費やされたかについて、非常に詳細な請求書を受け取ります. 契約を結ぶには、同意する必要がありましたが、これは私たちにとって非常にまれなことです。

時々、ノーと言えない営業担当者がいて、それが問題を引き起こす可能性があります。私たちはこれに多くの時間を費やしてきましたが、残念ながらまだ問題が発生しています。何がかかるかを調べずに何かを引用することで、彼らがどれだけのお金を費やしたかを説明することで、私たちはそれに対抗します。透明性はすべてのレベルで重要です。誰もが自分の決定が収益にどのように影響するかを知る必要があります。

軽薄な変更を行いますか？うん。覚えておかなければならないことは、ほとんどの場合、時間単位で請求する場合、5 分の変更は 1 時間ごとに請求されるため、非常に有利です。変更要求の場合と同じように、事前にこれらすべてを説明して、彼らがそれを認識できるようにしますが、本当に重要でない限り、そのような行動を思いとどまらせるのに役立つ傾向があります. 実際には、すべての変更を同じように扱います。どんなにばかげていると思っても、彼らにとって軽薄と見なされるものを知っているとは思いません。私たちは正式な変更プロセスを用意しており、顧客がそれを書き留めてサインオフすることを要求し、それを評価して作業コストの見積もりを提示します。彼らは同意する場合、開始してもよいことを知らせる文書に正式に署名するか、要求を取り消します。私たちは勤勉に努めますが、

私の同僚は、顧客関係船の管理について聞いた中で最高のアドバイスをくれました. それはギブアンドテイクです。顧客を満足させるには、顧客が何かを必要としているときに喜んで手を差し伸べる必要がありますが、同時に、ノーと言うことができなければなりません。人々と接するとき、彼らはあなたに彼らを助けてほしいと思っていますが、彼らはあなたが背骨を持って自分自身のために立ち上がることも望んでいます. そうすればお互いに有利な状況になります。

Answer 7

顧客は、それを行う時間がないか、何をすべきかわからない(そして、そのためにお金を払ってもらいたい)ために、何かをするためにあなたのところに来ます。要件が変化している場合、それは後者が原因です。言い換えれば、彼らは詳細を理解するためにあなたにお金を払っています! そして、彼らは好きなものと嫌いなものを知っていますが、それがどのように機能するかはわかりません.

これを認識し、ソリューションが必要なものは何でも適切な場所に収まるようにします。