実装可能かどうかわからない機能を提供することを約束する必要がありますか？

HNの記事で、次のアドバイスに出会いました。

不明な場合でも、常に顧客/ユーザーに「はい」と伝えます。90％の時間、あなたはそれを行う方法を見つけるでしょう。10％の時間、戻って謝罪します。大幅な個人的成長のための低価格

しかし、顧客/ユーザーに何らかの約束をする前に、実行可能性分析を行うべきだと常に考えていました。それでは、どのような状況で上記のアドバイスを適用すべきでしょうか？

これは、その記事によって引き起こされた短い連続の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。作業、または作業を提案するプロジェクトのコスト、スケジューリング、人員、品質、および成果の現実的な定量的推定を確保し、これらの推定の不確実性評価を提供します。

提供できないものを約束することには、ビジネス上および法律上の意味があります。通常、これらは顧客が他の場所に行ったり、支払いを拒否したり、会社を訴えたりすることで発生します。あなたが他の人とパートナーシップを結んでいる場合、あなたの部品が配達されなかった場合、彼らは損害賠償を求める可能性があります。訴訟は競合他社からも発生します。

Seymour Crayと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％だったかもしれません。これらの状況に陥ると、顧客を失ったばかりであり、市場全体で非常に口頭の悪い参照を獲得する可能性が高くなります。

悪魔の擁護者を演じる

分析的な考え方であるため、技術者は主に、完了したリクエストとコミットされたリクエストのスコアカードに基づいてパフォーマンスが判断されると想定する傾向がありますが、実際には、カットされて乾燥しているわけではありません。

開発が始まる前に、顧客は自信のレベルとコミットする意欲に基づいてチームのパフォーマンスに関する意見を形成し始めます。

この理由の一部は、顧客が請負業者のコミットするためのrequestが、要求のまったくの難しさまたは請負業者の能力の欠如によるものかどうかを評価するのに苦労する可能性があることです。

リクエストの難易度を測定するための絶対的な基準はないため、顧客にとってより重要なのは、リクエストの90％または100％が満たされるかどうかではなく、請負業者が100％の努力を払うことです。

顧客が2つのシナリオから選択する必要があるとします。

請負業者A：

• すべてのリクエストを確実に配信できる
• 結果：リクエストの90％が配信されました
• 顧客は請負業者が100％の努力をしたことを喜んでいます
• 顧客は、未完了のリクエストが予期せぬ問題によるものであり、おそらく請負業者の管理外であることを認識している

請負業者B：

• リクエストの90％を配信することを約束します。残りの10％で提供できるかどうか自信がない
• 結果：リクエストの90％が配信されました
• 顧客は、請負業者が要求の残りの10％を完了しようとしていないことに失望しています
• お客様は、要求の未完了の10％が請負業者の労力または能力の不足によるものであると想定しています

両方のシナリオで、同じ数のリクエストが配信されました。しかし、顧客は「オーバーコミット」している請負業者Aが100％の努力を払っていると感じ、これを使用して、請負業者Aの信用に対する残りの要求が本当に難しいことを検証しました。

反対に、顧客は請負業者Bが100％の努力を払っていないと感じ、すべての要求を完了することができないのは、請負業者Bの努力または能力の不足によるものでした。

免責事項：私は戦略としてオーバーコミットメントを支持していません。これは、オーバーコミットメントが肯定的な結果をもたらす可能性のある現実世界の状況の単なる観察です。

「スパイクソリューション」を作成する時間を与えるように伝える必要があります。

スパイクソリューションとは、コーディングする際に、プロジェクトで不確実性を生じさせる方法を実行できる、またはそれが可能かどうかを把握できる小さなプログラムです。

たとえば、プログラムでSMSを送信したことがないが、どういうわけかSMSが可能であることを知っているとします。急な解決策は、SMSを送信する小さなプログラムを作成することです。そうすれば、それはもはや不確実性ではなく、実現可能性についてさらに見積もることができます。

ここでは何エクストリームプログラミングのドキュメントは、それを言います：

スパイクソリューションを作成して、技術的または設計上の困難な問題に対する答えを見つけます。スパイクソリューションは、潜在的なソリューションを探索するための非常にシンプルなプログラムです。調査対象の問題のみに対処するスパイクを作成し、他のすべての懸念を無視します。ほとんどのスパイクは維持するのに十分ではないので、捨てることを期待してください。目標は、技術的な問題のリスクを軽減するか、ユーザーストーリーの推定の信頼性を高めることです。技術的な困難がシステムの開発を遅らせると脅した場合、1対2の開発者を1週間か2週間問題にさらし、潜在的なリスクを減らします。

私の経験によれば、ユーザーが何かを要求するとき、ユーザーが本当に望んでいるか、必要としているものの詳細な仕様を彼らに尋ねるべきです。多くの場合、リクエストについて二度と聞くことはありません。