client - 配達時にクライアントの反応が否定的だった場合、どのように対応すればよいですか?

Question

私はジュニアプログラマーです。上司にクライアントと同席するように言われたので、参加しました。(私のプログラマーの観点から) プロジェクトの提供は成功したにもかかわらず、クライアントの不満そうな顔を見ました!

クライアント:これを含めることもできたはずです!
当方：仕様にありませんでした！
依頼人：常識！

プログラマーとして、この状況にどのように対応しますか?

score 21 · Accepted Answer

この状況を回避するためにすべきこと:

含まれるものと含まれないものを明示的に指定します。

問題はおそらく仕様の未指定部分に帰着します:

クライアントは、不特定のものがあるべきだと考えています。つまり、暗示されていました。
開発者は、不特定のものを入れるべきではないと考えています。

あなたが持っている将来の仕様については、このドキュメントで何かが指定されていない場合、元の仕様が追加費用で行われた後に行うことができることを明示的に述べるキャッチオールステートメントが必要です.

現在の状況であなたがすべきこと：

自分の経験から学ぶ以外に、クライアントとある程度妥協する必要があります。

例: 私はあなたが常識だと思うこの機能を実行しますが、将来のすべての追加/変更については、明示的に仕様化する必要があります。

つまり、もう少し作業を行う必要がありますが、クライアントが締結するすべての明示的に指定された契約をキャッチする見返りとして、それは価値があります。

スペックが悪い？

必然的にスペックが悪かったのでしょうか？いいえ。

クライアントが期待するすべてのことを言及することは不可能であるため、上記のすべてのステートメントを明確かつ明示的に仕様書/契約書に記載することが重要です。

問題を軽減するその他の方法:

早い段階でクライアントを巻き込み、初期のプロトタイプを見せます。彼らがそれを要求しなくても。
クライアントに最終製品を販売するのではなく、クライアントの製品に取り組むためのサービスを販売するようにしてください。
アジャイル開発モデルなどを検討して、タスクが明確に定義され、小規模で、対価が支払われ、議論の余地がないようにします。

score 14 · Accepted Answer

これは、私がアジャイル開発哲学に切り替えた多くの理由の 1 つです。私の意見では、このシナリオをうまく回避する唯一の方法は、全知全能であるか、顧客を深く巻き込み、できるだけ早くフィードバックを得るために早期リリース/頻繁にリリースすることです。そうすれば、顧客が欲しいと言ったソフトウェアではなく、顧客が本当に欲しがっているソフトウェアを開発することができます。

score 14 · Accepted Answer

クライアント:これを含めることもできたはずです!

当方：仕様にありませんでした！

クライアント:常識!!

私たち:私たちはクライアントが指定した以上のことをしようとはしません - 私たちは仕様に従います. 指定された機能を実装することと同様に、指定されていない機能を実装しないことが重要です。お客様は、時間内に予算内で仕様を正確かつ完全に実装するために完全に信頼できるという事実を高く評価しています。

他の人が非常に正しく指摘しているように、状況はほとんどの場合、私が上で説明した単純な交換よりも複雑です。

ただし、実装者が、「ソフトウェアが仕様のすべての機能を証明できるように実装すると、完全であると見なされる」という合意を本質的に実装する顧客の署名を含む仕様を持っている場合、上記は有効です。仕様であるため、契約外です。

契約自体にもここでいくつかの入力がある場合があります-署名された契約がない場合は、仕様に何があるかは問題ではありません-これまでのすべては握手で行われ、取引全体(支払いを含む)はどちらかの不満に基づいてトイレに行きます。

しかし、契約書と仕様書があり、顧客がその両方を見て署名した場合、顧客はさらに先に進むように頼む余地はありません。

さて、それを実装する必要があるかどうかの問題について：

驚くばかり！ あなたは製品を配達しましたが、彼らは1 つの苦情しか受けませんでした。機能を実装し、それを「景品」と呼び (仕様と契約の範囲外で作業していることを彼らが理解していることを確認し、ドルで示されている割引で作業の請求書を明示的に送信してください)、プロジェクト全体を承認してもらいます。 .

プロジェクトが終了したこと、義務の範囲を超えたこと、さらに「サプライズ」が契約/仕様の範囲外であることを明示的に示します。持ってる。

UI の問題である場合は、より暗い状況に陥っています。

仕様は UI を適切に説明していますか? モックアップはありますか？仕様がレイアウト、使用法、およびモックアップを含むことを非常に厳密に記述していない場合、UI に関するこの苦情について顧客を責めることはありません。

いずれにせよ、顧客の立場は理解できると思います - UI モックアップで遊んでいない場合でも、顧客は結果に失望するでしょう - 心理的に言えば、あなたとあなたの顧客があり得た方法はありません。同じ考えを念頭に置いていました（常識がそうではないという事実を気にしないでください！）。

率直に言って、作業が完了する前に顧客が UI を確認することを考えたのがこれが初めてである場合、少なくとも部分的には、優れた UI 設計プロセスを顧客に説明しなかったあなたの責任です。これは彼らのアプリにとって重要な機能であり、彼らが想像していたものと非常に密接に結びついています。現実と一致するように時間をかけて内部表現を「成長」させない限り、このような状況に満足することはできません.

この断絶は、ユーザーと顧客による頻繁なテストによってのみ解決されますが、これは明らかに欠落しています。これは、仕様が満たされているかどうかではなく、クライアントの教育とコミュニケーションに関する問題です。

-アダム

score 10 · Accepted Answer

スコープの土壇場での変更を予期してください。常に発生するため、準備を整えておいてください。
クライアントと頻繁に進捗状況を確認して、驚きを最小限に抑えます。
契約: 機能仕様に加えて、初期上限のある時間と材料 (クライアントがコントロールしていると感じるように)。その後、変更が加えられたら、必要に応じてキャップを再交渉します。
彼らが欲しいものを手に入れることができないとは決して言わないでください。彼らは無料でその答えを得ることができます!
彼らが求めているよりも常に少し多めに与えてください。
クライアントと同じチームにいるように関連付けます。合法的に敵対者として描かれることを受け入れないでください。
彼らは、従業員と比較して、請負業者を忠実ではないと考えるかもしれません。彼らの従業員と同じように、あなたが彼らの成功に専念していることを彼らに示してください。

score 4 · Accepted Answer

これは、固定入札方式の多くの欠点の 1 つです。ビジネスのニーズや優先事項が変化したり、単純な誤解があったりすると、このような厄介な状況から弁護士の呼び出しまで、あらゆる結果が生じます。変更し、その変更にかかる時間に対して報酬を受け取ります。また、時間単位の取り決めがあるからといって、計画を立てることや見積もりを行うことを妨げるものではありません。

ただし、固定入札のピックルになったら、オプションは次のとおりです。1）追加費用でそれを行います。2) 無料で行います。3) しないでください。

オプション 3 が最悪で、オプション 1 が最適です。クライアントとの良好な信頼関係と適切なコミュニケーションがあれば、通常は簡単にオプション 1 にたどり着きます。関係が悪い場合は、より大きな問題を抱えていることになります。その時点で、レイヤーを避けるようにしてください。

最後のポイント - 「The Delivery Date」として知られるものがあるプロジェクトは、必然的に前述の問題に遭遇します。この日付のプロジェクトは通常、洞窟に数か月間隠れて開発し、その後、利害関係者の前で製品を一斉に解き放つことを含みます。これは突然であり、クライアントの期待と実際の製品がバラバラになるまでの時間が十分に残されています。代わりに、製品の中間バージョンを表示し、数週間ごとにフィードバックを収集すると、2 つのことが起こります。まず、より良いフィードバックを得て、誤解を最小限に抑え、より良い製品を作ります。第二に、大量の期待が置かれる単一の時点はありません。クライアントが想像しているものと実際に存在するものとの潜在的な違いははるかに小さい. 驚く様な事じゃない。

幸運を。

score 4 · Accepted Answer

クラシックケース...

これに対する明確な答えはありませんが、すべてはコミュニケーションを中心にしています。予防措置が講じられているはずです（毎週のレビューなど）。

確かに、すべてを無料でやり直すことはできません。

2 つの方法: または、オフにするように伝えるか、対処するか。

取引を選択した場合:

まず、共感し、クライアントを尊重します。
簡単に変更できるものをご覧ください。
契約書をご覧ください。
たぶん、新しい契約を作成します。
やりすぎないでください。
進捗状況と必要な作業を彼らに見せてください。
不足している機能の回避策を見つけます (おそらく、他の優れた機能や利用可能なツールを使用します)。

あなたの常識を使ってください、それはとても一般的で、面白くさえありません.

score 2 · Accepted Answer

うーん、うまく配信できませんでした。どこかで誤解が生じていました。詳細を知らなくても、これは開発者が注入した問題ではなく、おそらく顧客のせいではないことを示唆しています-要件収集タスクが不十分でした. これは、ソフトウェア側にドメインの専門家がいない場合や、要件発見プロセスができることをすべて行っていない場合に起こることの典型的な例です...

それが私だったら、問題を修正し、将来同様の問題を回避する方法を見つけます。

これをどのように処理するかによって、クライアントとのこの契約/ビジネスの将来が決まります。責任を持って問題を修正することは、会社にとって大きなチャンスです。

編集:これは、これがどのように発生したかを評価して修正するのに役立つ良い機会です。一部の企業は、行うことすべてを完全に刷新することを選択しますが、これは間違いだと思います。無視も同様です。問題を人のせいにするのも間違いです。

これがどのように発生したか、プロセスが何であるか、そしておそらくどのように発見されたのかを説明する良い機会です. 大幅なルールの変更やプロセスの変更は行いませんが、将来の作業のガイドラインを作成することは素晴らしいことです。あなたの会社には、欠点について明確な教訓がありました。この問題を修正し、プロセスを修正する機会を失うことは、チャンスを無駄にすることになります。

score 2 · Accepted Answer

OPの件名と質問について言えば：

あなたが雇用されているプログラマーである場合は、他のリソースがあなたと会うことを願っています. 組織の「上層部」の可能性があります。

この場合、あなたの仕事は直接的な質問に答え、感情を抑えることです。はい、彼らはあなたのコードを愛していないので、あなたは傷ついたと感じるかもしれませんが、上司がいるときに感情を示すことは良いことではありません. むしろ、ニュートラルに見えるようにして、他の人にセッションを任せてください。

さて、彼らが「あなたを乾かすためにぶらぶらしている」なら、私は次の質問をお勧めします：

a) 「わかりました。なぜこの機能を含めるのが常識だと思いますか?なぜそれを含めなかったのかを知りたいです。」（思考プロセスを説明するよう強制する。ある人にとっての常識が、他の人にとっての常識であることはめったにない。）

b) 「まあ、次のリリースでそれを含めることができると確信しています。相互に合意できるアプローチに到達するために、XXX (上司) に任せます」 (つまり、上司がいる場合は、コストや景品について話さないでください)。。これまで。）

繰り返しますが、これは、あなたが製品を提供した会社で働いているプログラマーであることを前提としています。それ以上の場合、つまりあなたが上層部の 1 人である場合、ここでの提案の多くは優れています。

ただし、あなたが上層部またはコンサルタントプログラマーである場合は、何よりもまず

a) この要件を満たさなかったプロセスについて謝罪します。これが再発しないようにクライアントと協力することを約束します。

次に、他の戦略に進みます。修理に料金を請求するかどうかは問題ではありません。謝罪はクライアントにとって最も重要なアクションです。繰り返しになりますが、見逃した機能について謝罪しているわけではありません。あなたはそれを逃してしまった欠陥のある設計プロセスをお詫びしています. このように始めてから解決策を探すと、通常、クライアントは非常に順応します。

乾杯、

-リチャード

score 2 · Accepted Answer

「あなたはどう反応しますか？」

質問 1 - この顧客との関係を継続しますか? 真剣に。不特定の機能が「常識」であると主張する場合、これは維持または強化するのに適した関係ではない可能性があります。

縁を切りたいなら、それは簡単です。準拠できなかった仕様の各部分を強調して、そのゲームをプレイするように依頼してください。欠落している機能ごとに特定のテスト基準を取得します。歯を引っ張る。何が欠けているかを判断する際に、対立的になりましょう。理由を聞かないでください。事前にすべての詳細を尋ねてください。遅くて不快です。しかし、とにかくそれらは必要ありません。

関与したい場合は、関係を変更する必要があります。現在、あなたにはパッシブアグレッシブな顧客がいます。言いたいことは言わないが、言いたくないことは言う。

これは彼らの習慣かもしれません。これが彼らが譲歩を勝ち取る方法かもしれません。または、これは彼らのずさんな仕様かもしれません。

関係が必要な場合、あなたの反応には 2 つの部分があります。

短期。彼らが満足するものを手に入れましょう。特定の変更を特定する必要があります。「実行するコスト」と「仕様への適合性」を使用して、各変更をスコアリングする必要があります。
- 安くて体にフィットするものもあります。それらを行います。
- 安価に実行できるものもありますが、仕様には適合しません。不適切な仕様が手直しにつながる可能性があることをよく考えてください。ある意味では、彼らから仕様を購入したことになります。また、基準を上げる必要があるかもしれません。
- （悲しいことに）仕様に適合する高価なものが問題です。あなたはこれらに問題を抱えており、ほとんどそれらをしなければなりません.
- 仕様に合わない高価なものは誰にとっても教訓です。仕様の書き直しや承認など、これらの計画を詳しく説明します。
長期。彼らがあなたが再びPAされていないことを確認してください. 早い段階で頻繁にレビューし、アジャイル手法を使用します。もっとコミュニケーションして、もっとプロトタイプを作って、もっとリリースしてください。

score 2 · Accepted Answer

ZiG、私は現在の職場で何度かこの問題に対処しなければなりませんでした。私のグループ (3 人の開発者) は、アジャイルな方法で物事にアプローチしようとしています。私たちは、ストリームの途中や最後の 2 番目のリクエストを取得することに慣れています (その後、ケースバイケースで処理します)。

ただし、リソース (特に時間) には限りがあり、仕様にない場合は約束できないことを明確にしています。重要であると判断され、現在のリリースに収まらない場合は、通常、フォローアップリリースを計画しています。重要でない場合は、リストに追加します。

私が発見したことの 1 つは、時間 T でユーザーに仕様 S に同意してもらうことができるということです。ただし、時間 T + N では、ユーザーに仕様 S に同意したことを思い出させるか、同意したことを認めてもらいます (あなたが保管してきた文書を、私は願っています!) 必要以上にトリッキーにすることができます.

score 1 · Accepted Answer

この致命的な罠を回避するには、SCRUM のようなアプローチを使用します。クライアントを開発プロセスに早期に、頻繁に、非公式の限定された委員会に参加させます -> リスクの軽減とアジリティの向上。

score 1 · Accepted Answer

あなたの文字通りの質問、どのように反応するかという点では、最善の方法はあなたの自我を無視することです (「何?! これに一生懸命取り組んで仕様を満たした後?!」) 代わりに、積極的に耳を傾け、コンセンサスに取り組むことに集中します。 .

クライアント: これを含めることもできたはずです!

当方：仕様にありませんでした！

クライアント: 常識!!

Us: 仕様の範囲を超えなかったことに不満を感じていることは理解しています。これについてあなたがどのように感じているかを見て、どうすればあなたを幸せにすることができますか? すべての人を助けるプロセスを一緒に作成できるかどうか見てみましょう。

基本的に、これを「あなたが言った/私が言った」デスマッチに変えたくありません。それらを解決する唯一の方法は弁護士であり、誰も勝てません。仕様またはプロセスに問題があることに同意できる場合は、協力してそれらを修正してください。

score 1 · Accepted Answer

このアプローチは実際に私にとって はうまくいきました.あなたのソフトウェアが好きではない人が去り、好きな人に取って代わられるのを待ちます.

明らかに、これに本当に頼ることはできませんが、あなたが良い仕事をしたこと、そしてあなたのソフトウェアがあなたを雇った人々のビジネスニーズを本当に満たすことを確信しているなら、それを待つことは価値があります. クライアントの最初の反応が最終的な反応ではない場合があります。特に、クライアントの懸念をすぐに取り入れることができる場合はなおさらです。

score 1 · Accepted Answer

クライアントに自分のせいだと思わせようとしないでください。それは彼らのせいかもしれませんが、彼らにそのように感じさせることは建設的な結果をもたらさず、彼らを苛立たせるだけです.

代わりに、クライアントは自分が使用しているソフトウェアについて不満を言うだけであることを理解する必要があります。ほとんどの場合、それは気に入っているからです。誰も使っていないソフトウェアについて文句を言う人はいません。クライアントが求めているものを正確に提供したとしても、提供するソフトウェアについてクライアントが不満を言うことは避けられません。だから、汗をかかないでください。ソフトウェアは決して完成しません。

score 0 · Accepted Answer

あなたは学びます-すべてが学び、個人的なものは何もありません。
私たちは私たちの分野の専門家であり、顧客よりも彼が必要としていることをよく知っています。そして次回は、次の顧客のために、すべての便利な機能を事前に提案し、彼を幸せにし、私たちが専門家であり、私たちがよく知っているので、彼にもっとお金を払わせるでしょう。

score 0 · Accepted Answer

要件収集担当者の完全な失敗、間違いありません。プロジェクト管理者が成果物を反復せず、クライアントとのチェックインミーティングを行わないという追加の失敗。

ただし、承認済みの仕様があり、提供したものは仕様と一致しています。したがって、あなたの会社には 2 つの選択肢があります。ビジネス開発の名目でコストを帳消しにして無料で変更を行うか、または変更要求に対して料金を請求するかです。

score 0 · Accepted Answer

仕様に含まれていない場合は、仕様に含まれていません。特定の分野の知識を持たない開発者にとって、「常識」は無関係な概念です。さまざまな業界がさまざまな方法で機能しており、あるアプローチは特定の分野には非常に適しているかもしれませんが、他の分野では完全に受け入れられない場合があります.

良い仕様書を書くことは芸術です。IMO、小さな反復を行うアジャイルな「アナリスト/プログラマー」アプローチを採用するか、詳細で明確な仕様を作成して維持することができます。どちらも非常に熟練したタスクであり、依然として反復的です。仕様を進化させる必要があります。

どちらの方法も思ったほど簡単ではなく、クライアントと良好な関係を築く能力が必要です。

score 0 · Accepted Answer

顧客が頭の中で何を考えているかを知ることはできません。この状況は、プログラミングプロジェクトの経験がないクライアントでよく発生します。私があなたに提案するのは、「常識」はエンジニアリング (または、必要に応じてプログラミング) の答えとしてはあまり正確ではないことを彼に示すことです。

書かれていないものを作ることはできないことを彼に示す、人生の他の例を彼に示してください。例: 新しい家を建てる場合、家を建てる人はすべての詳細を含む計画が必要です... 彼はオプションの電気プラグを入れません。

score 0 · Accepted Answer

私はこれを一度持っていました。幸いなことに、デザインを作成したのは私ではありませんでした。それが問題であることが判明したからです。

あなたの会社とクライアントの間のコミュニケーションが可能な限り完璧であることが極めて重要です。お互いに理解していることを確認してください。質問をして、彼らに質問させてください。デザイン内で何も開かないようにしてください。これが納車時の問題点となります。また、プロジェクト期間中 (できればプレリリースで) 定期的なミーティングを行います。

残念ながら、多くの開発者はコミュニケーションが苦手で、多くのクライアントは自分のニーズを認識していません。しかし、ギャップを最小限に抑えることができれば、満足した (そして戻ってきた) 顧客であることがわかります。

score 0 · Accepted Answer

これが、私/私が一緒に働いたチームが常にプロトタイプスタイルのアプローチを使用した理由です。つまり、次のことを意味します。

要件を収集した後、クライアントにソフトウェアの初期および基本リリースを示します。
クライアントは、「これを含めることもできた」/「それは常識だ」と言います。
クライアントの希望を反映するようにデザインを変更する
ポイント1から公式リリースまで繰り返す

score 0 · Accepted Answer

早い段階で開始する必要があります。仕様/ユースケース/ユーザーストーリーは、何が提供されるかを定義する契約であることを、早い段階で頻繁に顧客に伝えます。アジャイル環境では、顧客が必要とする「常識」機能を観察し、それを求める機会がたくさんあります。これは、アジャイルアプローチの利点の 1 つですが、「常識」の追加をすぐに受け入れ始めると、最後に、おそらくあなたの費用で、無限の拡張に備えています。

一部の顧客はこれを期待しています。できないことを伝えれば伝えるほど、最終的な議論はより簡単になります。

後輩として、これはまだできないことだと思いますが、難しいが必要な教訓の 1 つは、顧客を解雇しなければならない場合があるということです。

client - 配達時にクライアントの反応が否定的だった場合、どのように対応すればよいですか?

21 に答える 21

Related

Reference