あなたはこれを完全に間違った視点から見ています。これは、テクノロジーについて何も知らないクライアントからの愚かな要求ではありません。これは、プロジェクトにリスクをもたらすと思われる設計上の制約です。
したがって、プロジェクトでリスクに遭遇した場合は、何をしても構いません。つまり、リスクを定義し、評価し、緩和戦略を推奨します。
- リスクを定義します。 「パフォーマンスの問題」を引き起こし、「簡単に拡張できない」と言うのは、リスクを定義するものではありません。何を意味するのかを正確に指定する必要があります。実行されないのは何ですか?その理由は何ですか? これらの問題に直面するのは、どのような規模の変化でしょうか?
- リスクを評価します。 さて、あなたは問題があると思います。どれくらい悪い？これらのパフォーマンスの問題が実際に発生することをどの程度確信できますか? そうした場合、ユーザーにどのような影響がありますか? あなたは、プログラムはスケーリングできないと言っています。規模が拡大すると、カードの設計上の欠陥が露呈するのでしょうか? 最も重要なことは、これをどのように知るかです。 ここでは、時間をかけてプロトタイプを構築してベンチマークすることで、無意味な議論を大幅に省くことができます。
- 軽減戦略を推奨します。これを実装する正しい方法 は何ですか? なぜそれが正しい方法なのですか？繰り返しますが、どうやってこれを知っていますか？ 繰り返しますが、プロトタイピングはあなたの友達です。
この演習を行うことで、いくつかのことが得られます。
最初に、すべての詳細について自分が正しいとしても、それらをすべてまとめると問題にならないことに気付くかもしれません。はい、このプログラムはうまく機能したり、うまくスケーリングしたりすることはありませんが、予測されたユースケースのいずれもこれらの問題に遭遇しない場合、それらを解決する価値はありません.
第二に、誰かに「これはうまくいかないだろう、私はそれを知っているだけだ」と言うのと、「私たちが期待するユースケースをベンチマークしました。このアプローチは4つの結果になるようです.または、ユーザー トランザクションあたり 5 秒の応答時間です。」
第三に、ソフトウェアが失敗する条件を知っていて、その懸念をクライアントに明確に伝え、クライアントが「私たちは本当にこのように動作することを望んでいるだけです」と言った場合、あなたは責任を放棄したことになります。あなたが特定したリスクをクライアントが軽減しないことを選択したためにこれが失敗した場合、誰もあなたを指摘して、それがプログラマーのせいだと言うことはできません。
何よりも、証拠は意見に勝ります。この質問全体を、クライアントの意見に対するあなたの意見のケースとして組み立てました。それは負ける命題です。あなたがしなければならないことは、「ここに私たちが解決しなければならない問題がある」という枠組みを作ることです。質問をそのように構成するには、問題の存在を実証する必要があり、そのためには証拠が必要です。
最終的に、リスクを軽減するかどうかを決定するのはクライアントであり、あなたではありません。彼の決定を裏付けるために、あなたができる最善の情報を彼に提供するのはあなた次第です. そして、それが彼の決定であることを、気にせずに明確にする必要があります。
私は、単純な電子メールが注意を完全に集中させることを何度も発見しました。
私は設計を見直してきましたが、議論する必要があるリスクがここにあると思います. [アプローチ A] は、トランザクションの量に非常に敏感であり、問題が発生するほど多くのユーザーがいることが心配です。
[アプローチ B] を使用して少しテストを実行しましたが、感度ははるかに低くなります。私の単純なプロトタイプでは、1 秒あたり X 件のトランザクションを取得できました。[2 つのアプローチが物事を処理する方法の技術的な比較] であるため、これは理にかなっています。
[パフォーマンスが悪い場合にプログラムがどのように失敗するかを説明する]ので、私はこれについて特に心配しています。
これは私にとって重大な問題のように思えます。私だったら、[アプローチ B] を使用します。なぜなら [このアプローチがどのようにリスクを軽減するかを説明する] ためです。
しかし、あなたは私よりも [アプローチ A] に精通しており、この件に関するあなたのガイダンスに喜んで従います. 私たちは何をすべきだと思いますか？
このメッセージは、「私の言うことを無視すれば、プロジェクトは失敗するだろう。あなたがそうするように私に言ったことを証明する文書を手に入れるつもりだ」とはっきりと言っています。また、実際にはそうも言っていません。