プロジェクトの複雑さをプログラマー以外の人に説明するための良い比喩はありますか？
私は「システィーナ礼拝堂を正確に建てているわけではない」とだけ言われました。これは真実ですが、私は貨物管理アプリケーションを構築しています。これは、フォームにコントロールを描画するほど単純ではありません（ベンダーはあなたにそう信じさせますが）。
私はそれを言った人に対してこれを保持しませんが、私がしていることの複雑さは少し誤解されていると感じます、さもなければその声明は出されなかったでしょう。
プログラマー以外の人にプロジェクトの複雑さを説明するかもしれない良い比喩はありますか？
いくつかの比喩...
複雑さに関しては、それは一種の車を作るような、またはボートを最初から自分で作ります。 必要なエンジニアのチームのようなソフトウェアプロジェクトスペースシャトルの構築。唯一の違いは、あなたが物事を汚しても、人々は通常死ぬことはないということです。人々の命が危機に瀕しているとすれば、それはスペースシャトルのようなものです。 （ただし、ソフトウェアはロケット船ほどクールではありません。）
あなたのソフトウェアプロジェクトがシスティーナ礼拝堂ではないのは事実ですが（それは何ですか？）、それ自体が非常に複雑な貨物管理システムを構築するようなものです。ホワイトボードにいくつかの図を描いたり、システム設計やデータフロー図を持ち歩いたりすることができます。 彼らが見るのを手伝ってください。
「あなたは今までにコンピューターを作った？」と尋ねます。すべてのコンポーネントの選択と注文、コンピューターの構築、オペレーティングソフトウェア、デバイスドライバーの選択とインストール、最終結果の構成はすべて、この貨物管理プロジェクトよりも時間がかからず、はるかに簡単です。
それを彼らがしていることに関連付けることについてのアドバイスは良いですが、彼らが何をしているのかを十分に理解していることを確認してください適切なアナロジーを作ってください。彼らが訓練を受けた整備士であり、それが（たとえばオートマチックトランスミッションの代わりに）キャブレターの再構築に匹敵するとあなたが言った場合、彼らは「大丈夫、それはそれほど複雑ではない」と思うかもしれません。
ニール・アーンストはソフトウェアの比喩について少し話します 、住宅契約の比喩の適用可能性、そしてまた指摘しますソフトウェア工学は本質的に説明するのが難しいそれは抽象で作業する。
ニールはジム・ウォルドのエッセイにリンクしています ソフトウェア工学とデザインの芸術 、彼はそこで指摘しています
このように、私たちがソフトウェアエンジニアリングと呼んでいるものは、他の種類のエンジニアリングよりも、実際には建築（建物を生産する実際の建築）に似ています。科学の要素がありますが（建物は物理法則に従わなければなりません）、芸術の大きな要素もあります。作成するソフトウェアの種類によっては、2つの組み合わせが異なる場合がありますが、常に組み合わせがあります。
したがって、おそらく壮大な建築と建築の偉業は適切な比喩です。 （私たちがしていることがシスティーナ礼拝堂に近づいているわけではありませんが、それを念頭に置いて私たちがしていることに取り組む必要があります。）
残念ながら、あなたのプロジェクトを些細なこととして却下した人は、これを理解する可能性は低いです。彼らはそれをするのに十分抽象的に考えることができないかもしれません。あなたが望むことができる最善のことは、彼らが車やボートや家の例えを理解するか、あるいは図でそれを見るするのを助けることです。
編集：プロジェクトと「フォームへのコントロールの描画」との間の相対的な複雑さについて指摘しました。システィーナ礼拝堂の発言に「それは本当です。しかし、3か月のWebプロジェクトが家の裏にある小さな小屋である場合、この貨物管理システムはRogers -」と答えることができます。 センター。
スピーカーはほぼ間違いなく「絵画システィーナ礼拝堂[天井]」を意味していました。意味のある類似点はありますか？
ミケランジェロは、元の建築家によって提案された足場にいくつかの問題を抱えていました。彼は最終的に独自のフレームワークを構築しました。
ミケランジェロは彫刻家であり、任務を完了するためにフレスコ画を学ぶ必要がありました。
教皇ユリウス2世はもともと、使徒たちの12人の人物を描いて欲しかったのです。ミケランジェロは主題の選択についてフリーハンドで交渉し、300人以上の人物を描いた旧約聖書のシーンを提供しました。彼はすべての絵を自分でやった。
プロジェクトは継続的に資金を使い果たしました（教皇が周囲の州と戦争を続けていたため）。
では、見てみましょう。技術的なプリマドンナへの大きな依存、キャッシュフローの問題、クライアントの仕様に達していない...そうです、私が聞いたことのあるソフトウェアプロジェクトはないようです。
私はかつて聞いた古い逸話を思い出します：
自動車整備士は外科医にこう尋ねます。「なぜそんなに稼ぐのですか。どうしてそんなに複雑なことをしているのでしょうか。エンジンを使った私の仕事はとても複雑でやりがいがあります。私はそれが本当に得意です。それなら何でも直せます。エンジンがおかしい！」
その後、外科医は行き、イグニッションを回して車を始動します。それから彼はメカニックを見ます：「まあ、今それを直してください。」
ロケット手術ではありません。
システィーナ礼拝堂を建てるようなものではない場合は、家を建てるようなものかもしれません。家を建てるにはさまざまなことが行われ、さまざまな専門分野にさまざまな人々が関わっています。それほど複雑なことはありませんが、多くの作業が必要です。
問題は本当にではない家を建てるようなものです。それは常に変化する家を建てるようなものです。ただし、複雑にするために、これはあなたのポイントをより効果的に説明するかもしれません。
人がそれを理解していなければ、比喩はあなたに何の役にも立たないでしょう。あなたは彼らが理解できる言葉で個人に複雑さを説明するように努めるべきです。可能であれば、彼らが経験するかもしれない複雑な作業状況にそれを関連付けるようにしてください。
会計士の場合、次のように言うことができます。「これは、電卓を持って米国連邦準備制度を自分で監査するようなものです」
プログラミングはbabyを教えるようなものです。これについて私と一緒に耐えてください：あなたがニンジンの買い物に行く方法を赤ちゃんに説明したいと想像してください。ロボットを教えるのと同じことをします。
最初に彼は歩くことを学ぶ必要があります。ウォーキングサブルーチン。詳細については説明しませんが、彼は他の人の前に足を置き、体重のバランスをとる必要があります。彼が倒れたり、障害物に直面したりする場合の例外を管理する必要があります。
次に、スーパーマーケットの場所に関する地理的な仕様が必要です。
彼は市場を見つけるまでウォーキングサブルーチンを使用するように言われなければなりません。彼が合理的な時間内に市場を見つけられない場合（定義する必要があります）、彼は帰国ルーチンを開始する必要があります。
彼がスーパーマーケットを見つけた場合、彼はニンジン偵察アルゴリズムを使用してニンジンを見つけなければなりません。彼はすべてのオブジェクトをデータバンクのニンジン3Dモデルと比較する必要があります。再び合理的な時間（またはタイムアウト）。
それから彼はニンジンへの永久的なアクセスを得るためにそれらのニンジンをお金と交換する場所を評価しなければなりません。この部分は本当にトリッキーかもしれません。
次に、現在のニンジンの国際価格と、別の場所でより低価格のニンジンを入手するために必要なリソースに基づいて価格を評価する必要があります。
私はプロセスの途中で、あなたは私のドリフトを捕まえます。そして、私はたくさんのチェックと例外、評価、認識などをスキップしました。開発者の完全なチームがこれをプログラムするのに数ヶ月、おそらく数年かかるでしょう。そして、それはニンジンを買うだけです。
私が言おうとしているのは、アプリケーションを開発するときは、すべて、文字通りすべてを「伝える」必要があるということです。明確に指定されていないすべての詳細について、驚きがあります。「ランダムな」動作です。 、エラーまたは単純なシャットダウン。一般的な状況で何をすべきか、状況が変化したときにどのように適応するかをプログラムに指示する必要があります。プログラミングは、赤ちゃんに非常に複雑なタスクを教えるようなものです。
次に、最悪の部分があります。プロセス全体を通して赤ちゃんの手を握ることはできません。あなたは彼がすべてを持っていることを確認し、彼を手放します。 2つの考えられる結果：すべてが期待どおりに最初から最後まで正常に機能する（決して起こらない）か、赤ちゃんが仕事の途中で座って泣いていて、何が悪かったのか尋ねることができません。彼はただ泣いていて止まらない。そして、デバッグが始まります。
これで、証券取引所を管理するソフトウェア、自動芝刈り機、または飛行機を構築するためにどれだけの労力が必要かをよりよく想像できます。飛行機を操縦する方法を赤ちゃんに教えるのにどれくらいの時間が必要ですか？
番号。
正直なところ、ありません。
あなたができる最善のことは、エンドユーザーにコンピューターのロールプレイをさせることです。そうすれば、プロセスがいかに複雑であるかを理解するまで、各ユースケースを検討する必要があります。
何千行ものコードをすばやくスクロールしてください。 「1つの文字が間違っていると、このすべてが機能しません」と言います。
もう1つ：
小説を書くのと同じですが、タイプミスや文法の誤りが1つしかない場合を除いて、すべてが意味をなしません。
私が一般の人々によく使用する比喩は、ソフトウェアの構築は橋の構築とは異なるということです。
橋を建設する場合は、Iビームとリベットを購入でき、標準のコンクリートを注ぐことができます。ソフトウェアを構築している場合は、独自のIビームとリベットを作成する必要があり、非標準のコンクリートを発明する必要がある場合があります。
橋が半分完成したとき、夜にドライブイン映画館として機能するべきだと誰もあなたに言いません。しかし、ソフトウェアでは、最新の変更要求が一般的です。
橋が半分完成したら伝えるできます。ソフトウェアが半分完成したときはわかりません。
X線、超音波、およびその他のツールを使用することにより、橋を使用する前に、橋に構造上の欠陥がないことを確認できます。ただし、テストのベストプラクティスがあっても、ソフトウェアを使用するまで、ソフトウェアの多くの障害を発見することはできません。また、特定の障害を修正するのにかかる時間や、最後の重要な障害がいつ発見されたかを知ることは非常に困難です。
これらすべての要因は、ソフトウェアプロジェクトにかかる時間を予測することが難しい理由、およびソフトウェアプロジェクトがしばしば遅れる理由を説明するのに役立ちます。
以前のソフトウェアプロジェクトと比較できます。
古いプロジェクトXを覚えていますか、それは約6か月かかりましたか？さて、新しいプロジェクトYはおおよそその複雑さです。
それができない場合は、プロジェクトを実際の物理工学を必要とする他のプロジェクトと比較してください。家を設計して建てるようなプロジェクトもあれば、橋のようなプロジェクトもあります。
あなたの会社が比較の基礎として行ったエンジニアリングプロジェクトを見つけることができればさらに良いです、もちろんこれは彼らの業界に依存します。
技術的なバックグラウンドがない人は、私たち（プログラマーを意味する）が行うことを単純化しすぎるのが一般的だと思います。とは言うものの、多くのプログラマーは私たちの仕事を複雑にしすぎているか、少なくとも実際よりも多くのことをしていると思います。
私たちのほとんどが書いているソフトウェアは、それほど複雑なことは何もしていないと思います（騒ぎに入る前に、これには多くの例外があることを自由に認めます）。私たちは、クライアントが絶えず要件を変更している、またはそれが私たちの分野に固有であるかのように完全に対立している要件を持っている家やオフィスを建てるという比喩を投げかけるのが大好きです。さて、あなたがほとんどの請負業者にその話をしたならば、私は彼らがあなたの顔で笑うだろうと思う。彼らは、私たちよりも、矛盾する要件、無意味な要求、変化する要求の影響を受けません。純粋な「ウォーターフォール」アプローチは、私たちと同じように問題があります。
ですから、それは、プログラマー以外の人が特定のタスクやプロジェクトが難しい理由を理解するのに役立つ最善の方法は、メタファーを思いつくことではないと思います。それは彼らを巻き込むことです。些細なことの例を示し、その「些細な」変更に実際にどれだけの作業が必要かについての洞察を与えます。
単体テストがある場合は、1行のテストを行ってから、テストの結果を前に（はずすべて合格）、後に赤いバーの後に赤いバーで表示します。 「そこに、あなたは指摘することができます。1行のコードが壊れたすべてを見てください。私はそこですべてを修正しなければなりません」。もちろん、それは作成された例です。
類推によって、プログラマー以外の人が私たちの仕事の複雑さを真に理解できるとは思いません（ただし、実際にはそれほど複雑ではありません）。あなたは本当にあなたがしている実際の仕事への洞察を彼らに与えなければなりません、それは実際には単純で巧妙なアナロジーよりもはるかに批判的な考えを取ります。
ビジネスアプリケーションの主な目標は、多くの場合、組織内のコミュニケーションを支援することです。そのため、ビジネスアプリケーションの複雑さを説明しようとすると、XとYの間の日常のビジネスコミュニケーションが途絶えることがよくあります。そして、それを粉砕します。
これにより、プログラミングの経験がない人でも、複雑さを簡単に伝えることができます。 XとYを話さなければならないだけでなく、彼らの言語も構成しなければならないからです。などなど。
これがお役に立てば幸いです=）
これは、ソフトウェアエンジニアリングを説明するための私のお気に入りの比喩の1つです。
あなたが家を建てていると想像してみてください。あなたは家の計画を立て、どのような材料を建てるか、そしてどのように建てるプロセスを組織するかを決める必要があります。 （ほとんどの人は家で仕事をしたことがあるので、これに関係することについて大まかな概念を持っています。）
今、あなたが家を建てているのではなく、100階建てのオフィスを備えた超高層ビルを建てていると想像してみてください。計画は家の計画とどのように異なりますか？材料はどのように異なる必要がありますか？どのような要素を慎重に検討する必要がありますか？
ここで、自分で超高層ビルを構築しているのではなく、月に飛んでそこに超高層ビルを構築するロボットを構築していると想像してください。では、計画はどのように異なっている必要がありますか？材料はどのように異なる必要がありますか？すべての決定の影響を慎重に検討する必要がある理由がわかりますか？
必要に応じて「超高層ビル」を「貨物管理システム」に置き換えることもできますが、それでも比喩は役立つと思います。
他の人に話させて、難しい質問をさせます。有効な戦略かもしれません。彼の意見はどの数字に基づいていますか？
図はより理解しやすいです。
たくさんありますか
- リストアイテム
- ユースケース
- 要件
- 同様のプロジェクトに開発者を巻き込んだ
- 会社または必要なサードパーティ製品
- ユーザー
- サイト
- .。
同期が必要ですか？メタファーを見つけるのにも良い点です。
リスク管理はありますか？失敗の影響は何ですか。標準のPCプログラムは重要ではありませんが、プログラムが間違った値を計算したり、機能しなくなったりした場合はどうなりますか？
OSをプログラムすることの難しさは何ですか-私はそれを使用する方法を知っています:)有効な答えではありませんよね？
幸運を
プロジェクト管理が不十分で非現実的な見積もりが出されたためにプロジェクトを遅れて納品した場合...
「プロジェクトにさらに数人のプログラマーを追加すれば、時間内に完了すると思いますか？」
あなたはで返信することができます
「私の妻は赤ちゃんを産んでいます。医者は9か月かかると言いました。私は、3人でそれを成し遂げることができる別の2人の女性を使うかどうか尋ねました。」
リッチ
私はプログラミングプロジェクトを飛行機と比較するのが好きです。航空機にはさまざまな複雑さがあります。低レベルでシンプルだが機能的なアプリは、第二次世界大戦の複葉機かもしれません。使用は制限されていますが、適切なコンテキストでは適切なツールです。一方、商用ジェット旅客機とそれを構築するために必要な詳細/複雑さのレベルを見始めると、まったく異なるストーリーがあります。それはそれを使用している人々を飛ばすことができなければならないだけでなく、それを使用している間安全で快適である必要があります。飛行機（アプリ）がクラッシュしたり、過度の遅延が発生したりすると、乗客（ユーザー）はイライラしたり不満を感じたりします。それが十分に起こった場合、彼らは新しい航空会社を見つけるでしょう。あなたはあなたが必要とするどんな道に沿っても飛行機の複雑さで走ることができます。
飛行機のその他の大きな違いは、航空機を飛行/維持するために必要なスキルレベルと人数です。一人の男性が複葉機を飛ばす/維持することができますが、民間旅客機に対処するには、より多くの訓練/工数を持つより大きな乗組員が必要です。
ソフトウェアシステムを書くことは、物語を書くことに似ています。それは、一貫性が作家に直接依存している創造的な努力です。ストーリーが進むにつれて、プロットポイント（要件）が変化し、必要に応じてキャラクターが導入され、形作られ、カットされます（リファクタリング）。ストーリー（ドメイン）の理解は常に進化しており、ストーリーの関連部分が実際に書かれるまで、特定の詳細を知ることはできません。
コードはアイデアの表現です。したがって、開発者は、エンジニアであるよりも作者であることに共通点があります。他の回答で言及されているように、家（または車や橋）を建てるというアナロジーは、その仕事に任されていません。私たち国民は何世紀にもわたってこれらのパターンを打ち出してきました。私たちはソフトウェアを開発してから60年しか経っていません（業界として25年ほど）。機械工学がソフトウェア開発の確かなアナロジーである場合、見積もりで行う問題はありません。
皮を厚くするだけです。それが上司でない限り、あなたは何も説明しない持っている。そして、ところで、あなたはあなたが一日中インターネットで過ごしていると思う人々にそれを決して通すことはありません（どのように、皮肉なことです）。これは、プログラマー、サーバー担当者などに当てはまります。
あなたは生計を立てるために何もしなかったことを知りませんでしたか？
編集：私は理由もなく反対票を獲得しました...
エッジケースのシナリオでプログラムする必要のあるすべてのロジックについて説明します。
たとえば、出荷された内容の数に関するレポートは、日付範囲を選択するだけで数値が表示されるため、非常に単純であると考えています。目的地にまだ到着していないコンテナをコードがどのように検索する必要があるかを説明します。コンテナが送信者に返送されていないことを確認する必要があります。コンテナが疑わしいと思われたために税関に保管されていた場合は、税関のWebサービスに接続してコンテナのステータスを確認します。キャンセルされたコンテナ、沈没したために海上で失われたコンテナは出荷済みとしてカウントされますが、のみの場合は無視する必要があります。船は、米国、英国、フランス、日本、中国の沖合で120海里以上、またはその他の国の沖合で30海里以上沈没しました。トラックの運転手が過失ではありませんが、単純に紛失したコンテナは、少なくとも6か月間紛失するまでカウントされません。
これにより、明らかに単純なプログラムであっても、プログラマーが説明しなければならない圧倒的な数の「細部」のアイデアが人々に与えられます。
1982年に、私はIntel用の新しいテストマシンコアエレクトロニクスを設計していました。これは、マイクロコントローラーチップ（8X4Xファミリーのマイクロコントローラー）のテスト用でした。製品エンジニアリング（私はテストエンジニアリング）の人から、なぜそんなに時間がかかるのかと尋ねられました。しかし、質問にはその背後にある態度がありました。当時、私は大学を1年しか卒業していませんでした。
私は彼に「試験機を設計したことはありますか？」と尋ねました。
彼は自分の質問ですぐに問題に気づきました。
お役に立てれば。
JR
誰もがマクドナルドを理解しています。あなたがたくさんの現金を持っているなら、あなたはフランチャイズを手に入れ、誰かがやって来てあなたのためにすべてを準備します。ソフトウェアは、フランチャイズを取得してから、すべて自分でやらなければならないようなものです...
- プロパティを検索
- プロパティに入札
- プロパティを購入する
- 他のマクドナルドのように見えるシェルの建物を建設するために建設クルーを取得します
- 必要な機器を見つけて購入する
- 機器を設置する
- コンピューターを入手する
- POSソフトウェアを作成する
- コンピューターをドライブアップウィンドウに置き、ハンバーガーフリッパーに注文を送信するコードを記述します
- タイムカードソフトウェアを書く
- 給与計算ソフトウェアを書く
- セキュリティシステムをインストールしてコンピュータ化する
- 有能な乗組員を雇う
- 列車乗務員
- 株を買う
- 在庫を追跡するソフトウェアを作成する
- 在庫の注文を予測するソフトウェアを作成する
- 等。
あなたはその考えを理解します。平均的なジョーが気付いていない開発に入るものがたくさんあります。マクドナルドは魔法のように見えます。しかし、1つを実行する（そして維持する）には多くのことが関係しています。
私は住宅建設の比喩をもう少し進めたいと思います。それぞれのプロジェクトは、材料が異なる特性を持ち、異なる方法で相互作用するわずかに異なるコンポーネントを使用して、ゼロから家を建てるようなものです。多くの場合、各家はわずかに異なる物理法則の下で異なる惑星に建てられています。
そしてもちろん、あなたが家を建てている間、家のデザインを変え続ける顧客が常に存在します。
そうです、あなたはすべての家が同じであると言うことができます。屋根、壁、ドア、窓、配管、配線-しかし、悪魔は常に細部にあります。
反比喩はどうですか？ソフトウェア開発プロジェクトは組立ラインではありません。
私は家の比喩を避けるかもしれません。 3年前に家を建てたとき、エンジニアリングプロジェクトとはまったく違うことに驚きました。私は配管工を誓います、そしてトリム大工の1人は酔っていたに違いありません。
この男にあなたの機能仕様を見せてください。彼は、アプリケーションの構築にどの程度の詳細が関係しているかについてのアイデアを得るようになります。
私は人々に、それは稼働し続ける必要があり、毎週異なることをするエンジンを維持するようなものだと言います。また、それは目に見えないので、間接的に何が起こっているのかを理解する必要があります。
この説明は、技術者以外の人を本当に満足させるものではありませんが、気分が良くなるのに役立ちます。
エンジニアリングの複雑さの大部分は、人々の間の相互作用（および彼らが表す部門、彼らの目標、およびこれらの相互作用から生じる進化する設計上の決定）を含みます。これをエンジニア以外の人に説明することはできませんでした。エンジニア以外の人は、「必要に応じて、いつでも自宅で仕事をすることができます」と言っています。
それは庭です。私の母は熱心な庭師であり、私のコードベースについて話すのと同じように彼女は自分の庭について話します。
- それはまだ終わっていない-除去される雑草が常にあり（バグ/リファクタリング）、新しい草本の境界線または野菜のプロットの計画（新機能/要件）
- 予期せぬ-ある日、彼女が雑草に行って花壇を再編成したとき、彼女はカエルのコロニーが住んでいたことを発見し、冬（サードパーティの図書館で奇妙さを見つけたり、外部の請負業者を待ったりするようなものです）
- あなたはその中であなたの人生全体を無駄にすることができます、そしてあなたがやりたいことの半分を達成したように感じることは決してありません
プログラミングには、相互に重ねられた多数の条件とアクションが含まれます。 1つの条件が100％正しくない場合、プログラムは間違ったアクションを実行する可能性があります。そして、コンピューターは寛容ではありません。
対戦相手の動きを予測するマスターチェスプレーヤーのように、すべてのシナリオを予測し、コードでそれを説明するのはプログラマーの仕事です。
プロジェクトが成長するにつれて、チェス盤も成長し、完璧さの必要性は、1人のプログラマーが処理するのが指数関数的に難しくなります。
なぜそれが複雑なのかわからないかもしれませんが、複雑さについての労働を参照するかもしれません。
10人がこのプロジェクトに2年間取り組む必要があるほど複雑であることがわかりますか？
私のアプローチは完全に異なる：
私は彼らに別の開発者であるかのように説明し、専門用語の意味を尋ねると、それも説明します。これは通常、さらに詳細になります。ユーザーは実際にその問題がどれほど複雑であるかを実感します。です。
私の見解では、類推は、開発に関連する方法がないため、機能しません。
ダークナイト
インタビューで、私はモービーが何かを言ったことを覚えています...
「すべてが間違っている」を「すべてが複雑」に言い換えるべきだと思うことがあります。
それはソフトウェアです。
または、実際にread、それらに与えます：
I Sing the Body Electronic：A Year with Microsoft on the Multimedia Frontier これは、ソフトウェア開発について一般の人に洞察を与えることができる、おそらく私が読んだ中で最高の本です。 （実際、CS以外の専攻として、それは私がソフトウェアにとどまるように導いた本の1つでした）。
いくつかのプロジェクトでは、タコを小さな箱に入れようとしているような気がします。また、一部のプロジェクトでは、実行中の映画で作られたジグソーパズルを組み立てているような気がします。おそらく、クライアントに何かを説明するための比喩ではありませんが:)
私が持っている最初の質問はあなたの聴衆は誰ですか？これは管理ですか？この人が複雑さを理解していることが重要なのはなぜですか？
この人がシステムの複雑さを適度に把握していることがビジネス上重要であると仮定すると、システムの概要を示し、1つの側面の詳細を調べてから、システムの場所について意見を求めることができます。簡略化できます。この人があなたの複雑なシステムを理解するための独特の適性を本当に持っている可能性もあります、それで彼らにとってそれは本当にそうではありません複雑です。とにかく、彼らをシステムの開発に関与させて投資させると、彼らはあなたの最も厳しい批評家からあなたのチャンピオンに変わるかもしれません。
私が見つけた問題は、単純なものが想像よりもはるかに複雑な場合があるということです。たとえば、「これが発生するたびに、これを実行させる」と単純に言うことができます。そして、それは単純な変更ですが、多くのコードまたは複雑でバグのある動作を必要とすることになります。
それを説明するために、それは少し複雑です。あなたのプロジェクトマネージャーが彼にとって単純であるためにあなたに厳しい時間を与えているなら、何が起こる必要があるかはそれに時間を与えます。準備ができていないと言って、持っているものを見せてください。最終的には、X時間かかると言うと、実際にはX時間かかることを意味することを学習します。
私はそれが船を造ってそれを維持するようなものだと言いたいです：エンジンをきちんと整えて、掃除して、フジツボをこすり落とすなど。もちろん、ソフトウェアは古く、要件が変化し、環境が変化するため、壊れることはありません。
スティーブマコネルズのコードコンプリートを見てください。そこにはいくつかの優れた比喩があります。