愚かなクライアントのリクエストをどうするか?
-
04-07-2019 - |
質問
プロジェクトの入札に勝ちましたが、今ではクライアント(IT部門のクライアント)が非常に特殊な方法でソリューションを設計/実装することを望んでいます。パフォーマンスの問題のために、アプリケーションはそのように失敗します。また、簡単に拡張することはできません。
この特定のクライアント/ユーザーは、使用するプラットフォームと言語(ASP.NET / SQL Server)について何も知りません。彼の唯一の知識はCobolにあり、私のPOVを理解させるために彼を怒らせることは彼を怒らせるだけです。
彼は私に連絡しました。彼は私を入札の勝者として選んだ人でした。彼は私の小切手を承認する人です。彼はこの会社との唯一の連絡先です。
私は失敗することがわかっている解決策を提供することに不安を感じており、失敗させる愚かなプログラマとして知られたくありません。私は過去に彼らのためにプロジェクトを行ってきたので、このアプリケーションに対する彼らの本当のニーズと使用パターンを知っています。
一方、彼のやり方でこれを行うと、コードを修正することで問題を解決するために、私の契約をより長く延長します(したがって、より多くの金銭的利益が得られます)。
このクライアントを永遠に失う可能性が高いことを知って、プロジェクトを辞任すべきですか?
または…
ピルを服用し、拡張プロジェクトから金銭的利益を得て、コストとして悪い名声を引き受ける必要がありますか?
解決
これはまったく間違った観点から見ています。これは、テクノロジーについて何も知らないクライアントからの愚かなリクエストではありません。これは、プロジェクトにリスクをもたらすと思われる設計上の制約です。
したがって、プロジェクトでリスクに遭遇したときに何でもします。それを定義し、評価し、緩和戦略を推奨します。
- リスクを定義する。それを言うと、「パフォーマンスの問題」が発生する。および「簡単にスケーラブルにならない」リスクを定義していません。正確な意味を指定する必要があります。実行されないものとその理由規模のどのような変更がこれらの問題に遭遇しますか?
- リスクを評価します。さて、問題があると思います。どれくらい悪い?これらのパフォーマンスの問題が実際に発生することをどの程度確信できますか?その場合、ユーザーにどのような影響がありますか?あなたは、プログラムはスケーリングできないと言います:スケールの成長は、カードでさえデザインの欠陥をさらすでしょうか?最も重要なことは、どのようにこれを知っているのですか?ここでは、プロトタイプを構築してベンチマークするために時間をかけることで、多くの無意味な議論を節約できます。
- 軽減戦略をお勧めします。これを実装する正しい方法は何ですか?なぜ正しい方法ですか?繰り返しますが、どのようにこれを知っていますか?繰り返しますが、プロトタイピングはあなたの友人です。
この演習を行うと、いくつかのことが起こります。
最初に、あなたはあなたがすべての特定について正しい間、それらをすべてまとめるときそれが問題ではないことを発見するかもしれません。はい、このプログラムはうまく機能しないか、拡張性がありませんが、予測されるユースケースがこれらの問題にぶつからない場合、簡単に解決する価値はありません。
第二に、誰かに「これは実行されません。ただそれを知っています」と伝えることには違いがあります。そして、「私たちが期待するユースケースのベンチマークを行ったところ、このアプローチでは、ユーザートランザクションごとに4〜5秒の応答時間が得られるようです。」
第三に、どの条件がソフトウェアを失敗させるかを知っていて、これらの懸念をクライアントに明確に伝えれば、クライアントは「本当にこのように動作することを望んでいる」と言います。あなたは自分の責任を果たしました。クライアントがあなたが特定したリスクを軽減しないことを選択したためにこれが失敗した場合、誰もあなたを指し示すことができず、それがプログラマーのせいだと言うことはできません。
何より、証拠は意見に勝ります。この質問全体を、あなたの意見とクライアントの意見の対比として組み立てました。それは負けの命題です。あなたがする必要があるのは、「これは私たちが解決する必要がある問題だ」としてフレーム化することです。そして、そのように質問を組み立てるには、問題の存在を実証する必要があり、そのためには証拠が必要です。
最終的に、リスクを軽減するかどうかを決めるのはクライアントではなく、あなたです。彼の決定を裏付けるためにできる限り最高の情報を彼に提供するのはあなた次第です。そして、あなたはそれについてペニスではなく、それが彼の決定であることを明確にする必要があります。
複数の機会に、単純なメールが完全に注意を集中させることがわかりました:
私はデザインを見直してきましたが、ここで議論する必要があるリスクがあると思います。 [Approach A]はトランザクションの量に非常に敏感であり、これで問題が発生するほど十分なユーザーがいるのではないかと心配しています。
[Approach B]を使用して少しテストを実行しましたが、感度はずっと低くなりました。私の簡単なプロトタイプでは、1秒あたりXトランザクションを取得できました。これは理にかなっています[2つのアプローチが物事を処理する方法の技術的比較]。
[プログラムのパフォーマンスが低い場合にプログラムがどのように失敗するかを説明してください]
これは私にとって重大な問題のようです。もし私が
他のヒント
彼と一緒に座って、明確な質問をする必要があると思います。
その特定の方法で実装したい理由を理解する必要があります。ビジネスニーズを満たす実用的なソリューションを提供したいことを示す必要があります。
提案された技術に精通していない可能性があり、ある程度の安心が必要であると述べたように、根本的な懸念、対処する必要がある問題がある可能性があります。
物事が完全に文書化され、サインオフされていることを確認しない場合。
オプション1:立ち去れ、あなたはすでに悪い関係を持っているので、改善する可能性は低いです。
ただし、契約を延長したいので、それをしないでください。それはせいぜいずるく、最悪の不正行為ですが、契約が必要な場合は...
オプション2:アーキテクチャの選択と理由を文書化し、仕様として承認するよう依頼します。彼が作成した仕様を使用してパフォーマンスやスケーラビリティを保証しないという条項を契約に追加し、それを自分の方法で実装します。あなたの好むアプローチと推論のプレゼンテーションを彼に送ってください。
プロジェクトが失敗した場合(彼が正しいかもしれません)、いつでも彼にそう言って代替案を提示したことを指摘できます。
彼のアーキテクチャを誠実に実装するようにしてください。つまり、意図的に失敗させないでください。あなたの主張を証明する初期のテストを行い、失敗したことを彼が知っていることを確認してください。プロジェクトのライフサイクルを通じて、プロジェクトが軌道に乗っていないことを明確に書面で警告します。
幸運を祈ります。オプション1を真剣に検討する
アプリケーションのような小さなプロトタイプを作成して、彼が間違っていてあなたが正しいことを証明することは可能ですか?しっかりした証拠があれば、話はずっと簡単です。
カスタマーサービスポリスになるのは嫌いですが、これを「愚かなクライアントリクエスト」と言っています。本当にそうでない限り、おそらく悪い考えです(その場合、疑いなく立ち去るべきです)。より良い用語は、「情報に基づいていない顧客の要求」だと思います。
それを考慮に入れて、クライアントはおそらく本物のニーズを持っていることを覚えておいてください。解決策に対する彼らの(十分な情報に乏しい)アイデアに偽装されているだけです。少し調べて、彼らが本当に探しているものを見つけて、あなたがより良いと思う解決策を提案し、それがなぜより良いだろうと説明します。そして、あなたがクライアントの能力を疑問視していないような方法でそうしてください。誰も彼らを愚かに感じる人と一緒に働きたいとは思わない。
ここでは詳細がわからないため、具体的な手順を提案するのは難しいですが、私の考えは次のとおりです。
彼が欲しいものではなく(彼が必要なもの)彼を構築し、解決策が間違っていることを知っているなら、あなたは失敗に加担するプロジェクト。動作せず、スケーリングもしないことを知っている場合は、とにかくビルドしても、「フォールガイ」になったとしても驚かないでください。プロジェクトが失敗したため、次回にそれを行うためにこれ以上お金を稼ぐ必要はありません。
男が怒っている場合、多くの理由が考えられます。その理由の1つは、彼がテクノロジーを理解しておらず、彼を悩ますことです。しかし、私は状況を知りません、だから誰が知っていますか?私は個人的に男を怒らせて、感情をボートに駆り立てるよりも、正しい解決策を提案し、正しい解決策を主張することを望んでいます。
彼は顧客であるかもしれず、小切手を保持するかもしれませんが、それは彼を賢くも正しくもしません。古い格言にもかかわらず、顧客は常に間違っています。今、あなたは彼に間違った方法または正しい方法で近づくことができ、彼は両方に同じ反応をするかもしれません。しかし、あなたは関係なく、彼に正しい方法でアプローチしたい。
最終的に、彼はあなたが自分のやり方でそれを行い、主張と感情以外で彼の方法をサポートできないと主張するなら、私は仕事から丁寧に立ち去ります。正直なところ、お金には価値がありません。彼はあなたに怒っているかもしれませんが、問題の悪い解決策のためにあなたの会社のお金を無駄にしたわけではないことを知って、あなたはよく眠れます。
- 正直に言ってください。
- 彼の発言を聞いてください。
- 彼の感情があなたの判断を曇らせないようにしてください。
- 最後に、正しいことをしてください。
少なくとも、そうすることです。
幸運を祈ります!
聞くと学ぶ。クライアントのアプローチの長所と短所に真剣に興味を持つ。
問題に対する独自のアプローチを宣言する顧客が理解できる方法で、アプローチの長所と短所も必ず記録してください。
次に、両方の方法について話し合い、顧客とのやり取りを行いますが、「あなたのアプローチは愚かで、私は正しい」方法ではありませんが、彼のアプローチがもたらすメリット。
彼のアプローチに問題がある場合は、彼に尋ねてください。しかし、「これは機能しません」という方法ではなく、「このスケールはどうなるのか」ということに興味があります。 単に推測するだけではなく、彼の考えを理解し、代わりに「この方法で行った事実や数値を知ってください。これらのケースやこれらのケースでトラフィックが多すぎるという問題はないでしょうか?」
あなたは何かを学ぶかもしれません。頑張って!最終的には、彼のやり方でコーディングする必要があるかもしれません。本当に落とし穴を理解するならもっと良いでしょう!
この質問に答えられるのは基本的にあなただけです。あなたはクライアントとあなたの状況を最もよく知っています。この仕事をする方法を見つけることができれば、それはあなたの電話です。
個人的に、私はプロジェクトを辞退します。彼らがあなたを維持したい場合は、定められた要件の下でプロジェクトを取ることができない理由を説明してください。
プロジェクトをあなたに実装させたい場合は、 IT部門のスタッフの専門知識ではなく、あなたの専門知識を雇ったことを伝えます em>。
気分が悪い場合は、立ち去ってください。 最善の願いと最善の推奨にもかかわらず、私たちは以前からクライアントに特定のソリューションを提供することに専念してきました。
財務上の問題で、「必要」な場合ビジネス、それから私は間違いなくタイムボクシングの観点からプロジェクトにアプローチします。
どのようなタイムラインで達成可能なものを教えてください。さまざまなマイルストーンを達成したときに、モジュール方式で支払いを受けるようにしてください。少なくともそのように、それがあなたにとって勝者にならないならば、それはあなたに将来去る機会を与えます。
別の選択肢は、あなたよりも自分のやり方で行う方がどれだけ費用がかかるかを示すことです。
クライアントが必要な場合、彼もあなたを必要とします(おそらくそれ以上)。結局のところ、彼はあなたを選択した人です。彼は問題を解決する必要がある人です。
「どのように」仕事をするかについての彼の指示に左右されないという立場を取りなさい。氷が溶けているのが見える可能性があります。
私は彼と一緒にいくつかの誤った方向の戦術を試すことをお勧めします。彼の方法に懸念があることを彼に知らせ、あなたのニーズと彼の両方に適した他のソリューションを彼に提供してください。アグレッシブになることは避けてください(彼が間違っているとは言わないでください)が、両方のオプションを統合するより良いソリューションがあると思うと言います。
「動詞柔道」を練習してみてください。対決的であることは、彼とあなたのポイントをネットにするつもりはなく、あなたがただ難しいだけであることを彼にもっと確信させるだけです。彼に同意し、一般的なアイデアについて親密な関係を築き、それからあなたのソリューションへの道を穏やかに導きます。
あなたの懸念を含み、クライアントの悪い決断による失敗の場合でも彼らがお金を払う契約を描く。次に、署名させます。
ただし、その契約を経験豊富な弁護士が必ず実行するようにしてください。それは、悪意がさらに悪化し、金銭を求めて訴訟を起こす必要がある場合、裁判所があなたをすり抜けるので、少し間違えやすいためです。
署名する前に、契約のその部分をクライアントに知らせてください。おそらく彼らは再考するでしょう。
または、他の人が示唆しているように、このすべてのトラブルを経験する代わりに、保釈、立ち去り、またはより良い:実行します。できるだけ早く。本当に多額のお金でない限り、売り切れる価値はありません。
(編集:くそー、サイモンは数秒で私を打ちました。)
ソリューションを提案し、(プレゼンテーション / ドキュメントを使用して)なぜそれが優れているのかを説明してください。または、それからプロトタイプを作成することもできます。
あなたのクライアントは、あなたがそれを証明するなら、あなたがその分野で技術的なリーダーシップを持っていることを理解し、あなたを信頼するべきです。
飢えていない限り、私はプロジェクトを救済します。私自身はコンサルタントとして、私が顧客にもたらす唯一の価値は、私が持っている知識であると感じています(そして、彼らが持っていない、または彼らが私を雇わない)。私が「知っている」何かに取り組むには失敗すると、コンサルタントの倫理規定(ある場合)に違反します。
クライアントの方法が失敗する可能性が高いことをクライアントに納得させるように一生懸命努力し、その後、彼のために仕事をするために他の誰かを見つけるために一生懸命努力します。