実装可能かどうかわからない機能を提供することを約束する必要がありますか？
HNの記事 で、私は次のアドバイスに出くわしました：
確信が持てない場合でも、常に顧客/ユーザーに「はい」と伝えてください。 90％の確率で、その方法を見つけることができます。時間の10％、戻って謝罪します。個人の大きな成長に対して支払う低価格
しかし、私は常に実現可能性分析を行うべきだと思っていましたbefore顧客/ユーザーにあらゆる種類の約束をして、彼らがどの時点でも誤解されないようにします。では、どのような状況で、上記のアドバイスを適用すべきでしょうか？
これは、その記事によって引き起こされた短い連続の2番目の質問です。
優れたプログラマー：コードを最適化します。優れたプログラマー：データを構造化します。最高のプログラマー：違いは何ですか？
これには別の名前があります：早期最適化です。早期終了を使用しないでください。
これが「単一の入口点/単一の出口点」ルールです。これは本当の問題に対するパッチです。つまり、早期に終了すると混乱が生じる可能性があります。正しいルールは、「ごちゃごちゃを片付ける」ことです。さらに良いルールは、自分自身をクリーンアップするデータ構造を使用することです。これにより、プログラマーは混乱をクリーンアップする必要がなくなります。そして今、わからない場合でも、常に顧客/ユーザーに「はい」と伝えてください。90％の確率で、それを行う方法が見つかります。
これも非常に悪いアドバイスです。
場合によっては、お客様に「いいえ」、または「どのミレニアムでこれを希望するか」を伝える必要があります。アーキテクチャを破壊するもの、顧客が費やすよりもはるかにコストがかかるもの、またはそれを達成する方法についての手掛かりがないものを約束しないでください。あなたはテクノロジーではなく、顧客を知っています。それを行う方法がわからない場合は、それを行うことができるとは言わないでください。よくわからない場合は、それが可能かどうかを調査する時間が必要だと言ってください。それは正直である方がいいです、そしてそれはあなたをトラブルから守ります。
約束を果たせなければ、顧客はすぐに元顧客になります。 10％の故障率は小さいように聞こえるかもしれませんが、顧客が10％に集中するということです。あなたが約束したことを成し遂げることができないとき、時々彼らは訴訟を起こす。あなたは本当にそれを望んでいません。また、約束を順守することを確認すると、18時間勤務しているため、破産したり、正気を失ったり、配偶者を失ったりする可能性があります。あなたもそれを望まない。
このように考えてください。飛行機の着陸の90％が成功した場合、航空業界はどうなると思いますか？戻って、クラッシュした10％について謝罪すると、何かが修正されると思いますか？
「できると思う」と言ったほうがいいです。または「確認してご連絡いたします」。ノーと言ったり、カウンターが何かを提案したりしたことがあります。お客様が「インターネットに接続しなくても動作し、触覚フィードバックを使用するブラウザーベースのアプリケーション」を希望する場合は、おそらくそれが可能です。しかし、それは高価であり、実際のニーズが何であるかを議論することはより有用でしょう。
あなたが正直なら顧客はあなたを尊敬します。質問のアドバイスでは、その人は10％の確率で間違っています。 10回に1回、いつも間違っている人と一緒に仕事をするなら、私はその人をまったく信用しません。それは恐ろしい実績です。
月を約束し、岩を届けることは、容認されるべきではない一種のセールスマンのアプローチです。それが可能かどうかわからない場合は、調査してください。または、調査にかかる時間を見積もります。この方法では、提供できないものを約束することはありませんが、それを調査するのにかかる時間は支払われます。
この質問は正式に調査されており、共同で作成された IEEE Computer Society/ACM Code of Ethics によって対処されています。
2.01。彼らの能力と能力の分野でサービスを提供し、彼らの経験と教育の限界について正直かつ率直に。
3.04。教育とトレーニング、および経験を適切に組み合わせて、彼らが取り組んでいるプロジェクト、または働くことを提案しているプロジェクトの資格があることを確認します。
3.09。コスト、スケジュール、人員、品質、およびプロジェクトの作業結果の実際的な定量的見積もりを確保し、これらの見積もりの不確実性評価を提供します。
5.05。コスト、スケジュール、人員、品質、およびプロジェクトの作業結果の実際的な定量的見積もりを確保し、これらの見積もりの不確実性評価を提供します。
提供できないものを約束することについては、ビジネス上および法律上の影響があります。通常、これらは他の場所に行ったり、支払いを拒否したり、会社を訴えたりする顧客から来ます。あなたが他の人とパートナーシップを結んでいる場合、あなたのパーツが配達されない場合、彼らは損害賠償を請求する可能性があります。訴訟は競争相手から来ることさえあり得る。
スーパーコンピュータの黎明期から、シーモアクレイとControl Data Corporationのチームが製品の発売を間近に控え、別の非常に大規模なコンピュータ会社が顧客にもその発売を間近に迫っていたという話があります。嘘はCDCに多くのビジネスを犠牲にして、大企業が彼らの主張の信頼できる証拠を示すことができなかった訴訟に変わりました。その結果、当時は1970年に8000万ドル相当の大きな和解がありました（2012年にはインフレ調整済みで約2億2,300万ドル）。あなたはそれについてここで読むことができます：
http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing
十分な時間、リソース、および成功の定義に関する柔軟性があれば、何でも可能です。白いx-massの例は、50％を超える精度のみが必要で、ユーザーの地理的位置と少しの統計データがある場合は簡単です。
ほとんどのプロジェクトの真の最初の質問は、何かが可能であるかどうかではなく、特定の一連の状況を考慮してそれが合理的であるかどうかです。
この機能は、試行の費用を正当化するのに十分な価値を追加しますか？
アイデアがかなり素晴らしいものであったとしても、長い開発期間またはよりエキゾチックなハードウェアの取得が必要な場合は、クライアントが前もってそれを知ってから、ほとんどの場合、会話をより合理的な目標に戻す方がよいでしょう。
誰かがあなたに空白のチェックをし、締め切りがないのに夢中なら、どうしてもすべてが可能であることを伝えてください。その過程で目標を達成するために必要ないくつかのテクノロジーを発明して配布する必要があることを知らせてください。
一方、妥当なリソースを使用して妥当なクライアントを扱う場合、クライアントがすでに実行され、時間/お金/リソースのプロモーションに費やしている可能性があるため、同意した後に一部の機能をカットする必要があるとクライアントに伝えるよりも悪いことはありません。それを文書化し、その10％がプロジェクトを最初から環境に優しくしたものだったのかもしれません。それらの状況に陥ると、顧客を失い、市場全体で非常に口頭で悪い参照を獲得した可能性が高くなります。
悪魔の支持者を演じる
分析的な考え方なので、技術者は、自分のパフォーマンスは主に、完了した要求とコミットされた要求のスコアカードに基づいて判断されると考える傾向がありますが、実際にはそれほど単純なものではありません。
開発が始まる前に、顧客は、自信とコミットメントのレベルに基づいて、チームのパフォーマンスについて意見を出し始めます。
この理由の1つは、請負業者がコミットすることをためらうことが、要求の純粋な困難によるものか、請負業者の能力の欠如によるものかを顧客が評価するのに苦労する可能性があるためです。
リクエストの難易度を測定する絶対的な基準はないため、多くの場合、顧客にとってより重要なことは、リクエストの90％または100％が満たされているかどうかではなく、請負業者が100％の努力をしているという信頼です。
顧客が2つのシナリオから選択する必要があるとします。
契約者A：
- すべてのリクエストに対応できると確信している
- 結果：リクエストの90％が配信されました
- 顧客はpleased請負業者が100％努力した
- 未完了のリクエストは予期せぬ問題が原因であるとお客様が認識している。おそらく請負業者の管理外
契約者B：
- リクエストの90％を提供することを約束します。残りの10％で配信できると確信していない
- 結果：リクエストの90％が配信されました
- 顧客は請負業者が要求の残りの10％を完了しようとしないとがっかりした
- お客様は、未完了の要求の10％が努力の不足または請負業者の能力の欠如によるものであると想定しています
どちらのシナリオでも、同数のリクエストが配信されました。ただし、顧客は、「オーバーコミット」の請負業者Aが100％の労力を費やしていると感じ、これを使用して、残りの要求が本当に請負業者Aの信用に難しかったことを検証しました。
反対に、顧客は請負業者Bが100％の努力を払っていないと感じ、すべての要求を完了できないのは請負業者Bの努力または能力の不足が原因であると考えました。
免責事項：コミットメントを戦略として主張していません。これは、オーバーコミットメントが肯定的な結果をもたらす可能性のある現実の状況の観察にすぎません。
「スパイクソリューション」を作成する時間を与えるように彼らに指示する必要があります。
スパイクソリューションは小さなプログラムであり、それをコーディングすることで、プロジェクトの不確実性を生み出していることを行う方法、またはそれが可能かどうかさえも把握することができます。
たとえば、SMSをプログラムで送信したことがないが、どういうわけかそれが可能であることがわかっているとします。スパイクの解決策は、SMSを送信する小さなプログラムを作成することです。これにより、もはや不確実性がなくなります。実現可能性についてさらに見積もることができます。
これが eXtremeプログラミングのドキュメント が言っていることです。
スパイクソリューションを作成して、困難な技術的または設計上の問題に対する答えを見つけます。スパイクソリューションは、潜在的なソリューションを探索するための非常にシンプルなプログラムです。スパイクを作成して、調査中の問題のみに対処し、他のすべての懸念を無視します。ほとんどのスパイクは保持するのに十分ではないので、それを捨てることを期待してください。目標は、技術的な問題のリスクを減らすか、ユーザーストーリーの推定の信頼性を高めることです。技術的な困難がシステムの開発を停滞させる恐れがある場合、開発者のペアを1〜2週間問題にさらし、潜在的なリスクを減らします。
私の経験によれば、ユーザーが何かを要求するとき、ユーザーが本当に何を望んでいるか、何が必要かについての詳細な仕様を尋ねる必要があります。多くの場合、リクエストについて二度と聞くことはありません。