主にプログラミング会社ではない会社のためにプロジェクトを開始するとき、期待の1つは、すべてのバグのない完成した製品があり、必要なすべてをすぐに行うことです。ただし、そうなることはめったにありません。
期待を管理し、非プログラマーにソフトウェア開発が他のタイプの製品開発とどのように異なるかを説明するいくつかの方法は何ですか？
回答:
最近、コンピューターを持っている人のほとんどが「バグ」の概念に遭遇しているので、そこから始めてください。「アプリケーションがこれまでに失敗した最も厄介な方法は何ですか？それに10を掛けると、テストとメンテナンスに十分なリソースを割り当てなければユーザーの経験が得られます。」
また、非プログラマーと良好な関係を築くことの価値を過小評価しないでください。あなたの判断が信頼できるかもしれないと立証できれば、彼らがあなたの推論を完全に理解していなくても、あなたがYプロントをしなければ、Xが劇的に失敗するというアラームを鳴らすとき、彼らはあなたを真剣に受け止めます。
私が成功した1つのアプローチはこれです：
私たちは皆、コンピューターが指示されたことだけを正確に行うことを知っています。
プログラミングは、私たちがコンピュータを伝える方法です、今我々はそれが何をすべきか何を後に。
これは、あなたの振る舞いが今どのように振る舞うかは、あなたのマシン上で実行されているコードのいずれかを書いたすべての人の意図の組み合わせによるものであることを意味します。オペレーティングシステム、ドライバー、プログラミング環境、ライブラリなどの複雑さを考慮すると、ほとんどのシステムでは2万人以上の人が関与している必要があり、10万人を超える可能性があることがわかります。
各人が書いたコードは、自分の理解、動機、意図、能力を反映しています。システムの完璧な操作がいることを必要とすることを考えると、すべてのこと-これらの20Kの人々によって書かれたコードのエラーなしで対話するすべてのコードのは、必要な行動の意味や解釈に同意しなければならない、驚くべき事実は、我々がバグを持っていることはありませんが、それらの数が非常に少ないこと。
IMOは、アジャイルプロセス（スクラム、クリスタルなど）によって提供される透明性が、平均的な利害関係者に開発がどのように機能するかを示すことに大いに役立つことを発見しました。
比phorによる説明は漏れやすい抽象化ですが、ここで私のためにしばしば働くいくつかのアイデアがあります：
これらの説明のどれもがずさんな仕事を許さないことに注意してください。
すべての変数が可動部分であるコンピューターとしてのコンピュータープログラムを考えてください。これにより、些細なプログラムでさえ、数百の可動部品で構成されるマシンになります。
それが失敗すると、プログラムにエラーがないことを数学的に証明することはできますが、膨大な時間がかかり、努力する価値がないという事実に頼ります。
最後に、IntelとMicrosoftがバグを回避できないかどうかを尋ねますが、どのように期待していますか？
同様の質問にさらに詳しく答えましたが、要点は「プログラミングは工場や組立ラインを建設するようなものです」。
これを示す従来の方法は、プロジェクト管理トライアングルです。スコープ、コスト、スケジュールの3つの競合する基準。通常、「安く、速く、良い-2つを選ぶ」と表現されます。
設計、開発、および展開プロセスの最後に、製品に設計上の欠陥が比較的なく、指定された機能で動作するという期待は完全に合理的です。同じ期待は、プロジェクト、プロセス、または職業に関して完全に不合理です。
科学に基づいた専門家は、ハードまたはソフトを問わず、探索、不正確で不正確な概念化の形成、最適とは言えない（または単なる間違った）戦術を経て、試行錯誤を通して何が機能するかを発見し、リソースがなくなるか、十分なレベルのパフォーマンスが達成されるまで、何度も繰り返し処理しますか？
欠陥がないプロセスはありませんが、より高い品質レベルに漸近的に近づくことができます。
それは、戦術がしばしば推測とプロトコルを必要とする医療専門家に当てはまり、活動の多くは基本的にほとんどがウェットウェアのマシンをデバッグしています。土木工学と建築では、新しい工学材料のアプリケーションを現場で検証する必要があり、標準に厳密に準拠しているにもかかわらず、長年の使用後に突然失敗する可能性があります。自動車分野では、適用されるエンジニアリングまたは修理サービスの欠陥がなく、一般に、経年および動作条件の変化が、故障点までの性能に影響を与えることがあります。ソフトウェア開発は、こうした点でこれらの職業と根本的に違いはありません。新しい、目的のある機械を考案することに焦点を当てているのは、その大部分です。
あなたはそれを彼らが見ることができるものと比較し、可能であれば毎日使用するかもしれません。
たとえば、自動車。車は今日よりも洗練された信頼性の低いデバイスとしてスタートしました。自動車は100年以上も製造されてきましたが、ソフトウェアはおそらくその半分の長さです。車は大幅にカスタマイズされており、価格に含まれているもの（色の選択など）、エンジンのサイズ、トランスミッションの種類、ホイール/タイヤ、トリムレベルなどが大幅なコスト要因となります。
車やソフトウェアには、多くの機能、品質、コストの要因があります。次に、ソフトウェアテクノロジー、専門知識の利用可能性、それが構築された場所でさえ大きな違いを生む方法について議論できます。適切な開発サイクル（たとえば、わずかな変更を伴う年次モデル、約3年ごとの車体/エンジン/プラットフォームの変更）は、顧客のニーズと複雑な設計プロセスの組み合わせによって推進されます。一部の製品は、小さくてだらしない外観から始まりますが（ホンダアコードを考えてみてください）、トップレートになるまで毎年改善されます。
車にはリコール（多くの場合、ソフトウェアアップグレードよりもコストがかかります）と、パーツリストへの実行変更の形での漸進的な改善（バグ修正を考えてください）があり、多くの場合、長期的なサポートが必要です（後方/前方互換性を考えてください）。車の費用の多くは、家に帰ってからです。ソフトウェアのコストの多くは、顧客を更新およびアップグレードする際の最初の製品リリース後に発生します。
場合によっては、ソフトウェアまたは他のソフトウェア製品を含むよく知られている製品を参照できます。たとえば、電話にはリリースサイクルがあり、最初の販売後に機能を追加して更新し、収益を増やす方法があります。電話は、前方/後方互換性の優れた例です。多すぎて、古いものを捨てて新しいものを買うことはありません。顧客が少なすぎると、顧客は契約が切れる前に嫌いな電話を切望します。
Windows、Microsoft Office、Webブラウザー、Webページなどの製品はすべて、ディスカッションで使用できるソフトウェアです。これらは1年または3年のサイクルで更新されていますが、より頻繁に自動更新される場合があります。バグやセキュリティホールがあり、それらはさまざまな程度で顧客に影響を及ぼしますが、最善の努力にもかかわらず風景の一部となっています。顧客は修正プログラムを無料で入手できますが、通常は拡張機能に対して、多くの場合バンドルとして、場合によっては個別のモジュールとして、またはライセンスキーを介して支払います。
マイクロソフト、アップル、グーグル、アマゾンなどの業界リーダーはすべて、比較的安価な顧客をユーザーに提供しています。しかし、彼らはそれらの製品を可能にする莫大な費用を抱えています。彼らの経験によれば、ソフトウェアは高価ですが、価値があり、有益です。多くの場合、品質と、必要な機能をすべて備え、タイミングが合ったときに市場に参入することの間で妥協します。彼らが作るすべての製品が成功するとは限りません。名前を変えたり、マーケティングと販売を改善したり、損失を減らしたり、後の製品で学んだことを使って犬を勝者に変えることもあります。
おそらく、1対1で、または理想的には小グループで、開発する必要があるソフトウェアのユースケースを試してみてください。ユースケースを説明する際に、さまざまなことが発生する可能性がある場合のポイントを特定します（予期しないが不合理なケースではありません）。それらを列挙し始め、いくつかの明確化を求め、実行または解決する必要があるすべての決定と方向、およびその際に行われるトレードオフを示します。彼らが困惑し、あなたに答えを与えることができないまで続けてください。数百または数千のコースを決定し、コードを書くことの両方で、おそらくあなた自身で、おそらくあなた自身で、おそらくはるかに明確でない方向で、あなたが彼らと一緒に何をしているのかを正確にあなたに伝えてください誰でもレイアウトできる場合とできない場合があります。そしてそこにいるとき 自分のことを考えていなかった場合、プログラムが何をするかを保証することはできません。たぶん、それは「正しい」ことをしているかもしれません。それがバグです。それが、ソフトウェアの作成に時間がかかる理由です。時間が短いほど、考慮して対応する機会が少なくなり、プログラムが未知の状況で「正しい」ことをしない可能性が高くなります。
コストと時間。
時間
XでYの時間を提供するという期待を設定します。それ以上でもそれ以下でもありません。それから、次のバージョンが何時に来るかを伝えます。最初は、Xの構築にY時間かかると信じて驚くかもしれません。ここで、ソフトウェアの構築にかかる時間と複雑さを説明します。彼らが驚かない場合は、あなたが見積もる時間が非常に短いか、ソフトウェアの構築について考えるよりもよく知っているかのどちらかです。
コスト
これは、Steve McConnelのCode Competeの本（記憶から引用していますので、同じ効果で伝えられなかった場合はご容赦ください）-お客様が新しい機能を要求するのは簡単です。プロダクトマネージャーとして、顧客が何を求めているかを言うべきではありません。その新しい機能を構築するのにどれだけの労力と費用がかかるかを見積もる必要があります。彼らは、新しい機能が実際にお金/時間の価値がないか、おそらくそれを必要としないことをゆっくりと理解します。私はあなたが彼らを怖がらせるためにこれを武器に使用することを提案していませんが、正直にそれを使用してください。