顧客が要求に対して何を意味したのかを理解することは、ソフトウェア開発者の責任ですか？

はい/いいえの質問の種類とその理由は？

顧客が要求で何を意味したのかを理解するのはソフトウェア開発者の責任ですか、それとも開発者に要求を適切に説明するのは顧客の責任ですか？

現在、職場での状況は、「顧客が既に説明していること、顧客が望んでいることです。それ以上の質問をするのではなく、リクエストを理解することはあなたの責任です」。

英語は私の強力なスイートではありませんが、すべてのリクエストは曖昧な英語で書かれており、単語を間違え、文章を理解するのが困難です。

私はシステムの3番目または4番目の開発者です（最後の開発者は仕事を辞めました）。それが、顧客が開発者側である程度の理解を期待している理由かもしれません。

システム自体は、UIレベルでもソースコードレベルでも非常に複雑です。これは私には猿のコーディングのように見えます-実際にリクエストを理解していない間、リクエストを正しく取得してください。

私は実際に仕事を辞めることを考えていますが、誰が正しいのか、誰が間違っているのかわからないので、まだやっていません。

理解することがあなたの仕事なら、あなたが理解するまで質問するのはあなたの仕事です

あなたが尋ねる人は顧客ではない人（私はしばしば顧客と接触していた仲介者と話しました）であるかもしれないので、あなたが顧客と話すことを禁止している人は代わりに質問に答えるか、あなたを紹介するべきですできる人。

しかし、最終的には何らかのコミュニケーションが必要です。彼らがそれを拒否する場合（そして理解できない文書を提供することは事実上コミュニケーションを拒否します）、前任者がしたように、あなたはすべきです：すぐに逃げなさい。

クライアントと上司が面倒なペーパートレイルを残した場合、あなたができることはあなたが持っているものからできるだけ多くの感覚を集めて、どのように知識があるかを構造化するために平易な英語でシナリオを書き始めることですシステムは動作することになっています。

Given / When / Thenシナリオを使用すると、何が起こる必要があるかを詳細に把握できます。また、それらは単純な英語で記述され、構造化されているため、上司やクライアントとのコミュニケーションに使用できます。私はこの点に着きました、そして、システムがここで何をすることになっているのかわかりません。」

あなたが理解していないことをすべて文書化する努力をしたにもかかわらず、追加の説明を求めるときにあなたが単に避けた場合、以前の開発者は仕様を伝える方法を知らなかったためではなく、そうすることは不可能です。

私の意見では、両方（顧客と開発者）が問題とその解決策について同じ理解を得る必要があります。

リクエストを理解していないと、ソリューションを作成できません。

そのため、仕様を読む必要があります。仕様が十分に明確でない場合（または仕様が書かれていない場合）、回答を提供できる人がいるはずです。

私は、ビジネスの質問に答えることができる人が一人いるチームで働いています。このビジネスオーナーは、顧客のビジネスを知っている私が働いている開発会社のメンバーか、顧客チームのメンバーのいずれかです。

あなたの特定の状況では、プロジェクトマネージャーは、同じ質問を何度も聞かれると（開発者の離職のために必要な）顧客がイライラすることを恐れており、これは彼と彼の会社にあまり反映されていません。

もちろん、これらの質問をしないと、システムの完了/変更に時間がかかり、顧客が望んだ結果にならない可能性があります。これにより、遅延が増加し、プロジェクトマネージャーとそのマネージャーにあまり反映されません。会社、少なくとも顧客の目には。

プロジェクトマネージャーが質問を許可しないことを選択する理由はいくつかあります。

1. 彼はネガティブな結果を本当に理解していないか、否定しています。
2. 彼は代替案を知っていますが、迷惑な質問よりも遅れや品質の低下を受け入れる可能性が高いことを顧客は知っています。
3. 彼は政治的なゲームをプレイしています。多分、彼はすぐにプロジェクトを離れることを知っていて、それまで問題を隠したいと思っているかもしれません。

IMOの理由2は考えられません。理由1を排除するために、彼に代わる選択肢を説明してみて、それらの間で明確な選択をするように頼んでください。理由3を排除するために、書面でこれを行い、潜在的な問題を早い段階で認識し、修正しようとしたことを証明できるようにします。しかし、正直に言うと、これが必要だと思われる場合は、できるだけ早くそこに行くべきでしょう。

サービスプロバイダーがクライアントの意図を理解していることを確認することは、常にサービスプロバイダーの責任だと思います。

私たちの分野の専門家として、ブリーフを完了するのは私たちの仕事ではなく、私たちのサービスを利用するプロセスを通してお客様を導く手助けをすることです。

顧客重視のアプローチは、絶対に物事を行う方法であり、実証済みのテスト済みビジネスモデルだと思います。

顧客と開発者は協力して、システムの理解を深める必要があります。

ソフトウェア会社は、各当事者に求められること、つまり契約の基本的な側面についてクライアントと合意する必要があります。「心の出会い」がなければ、非常に現実的な意味で、契約はありません。

あなたが有能なプログラマーであると仮定して、仕様が明確でない場合、単に「リクエストを理解し、それ以上の質問をするのはあなたの責任です」と言われるのはかなりばかげています。

これは、元の質問に対するコメントの新しい情報に基づいています。

声明

顧客はすでに彼が望んでいることを説明してくれました。それ以上の質問をするのではなく、リクエストを理解するのはあなたの責任です

プロジェクトリーダーから提供されます。述べられた根拠は

私はシステムの最初の開発者ではないので、より多くの質問でクライアントの代表者を煩わせるべきではありませんが、質問を解釈するために余分な時間を費やそうとします

それで、あなたが特に避けるように言われていることは、質問で顧客を悩ましています。

「質問の解釈に余分な時間を費やす」ように頼むことは、必ずしも不合理ではありません。顧客が実際に言ったことに基づいて要件が何であるかを理解するために、合理的な努力、またはおそらく少し不合理な努力をする必要があります。それ以外の場合は、それは貴重なスキルです。

それが失敗する場合（そして、さまざまな理由で既に持っているように聞こえます）、プロジェクトリーダーに助けを求めてください。質問ではできるだけ具体的になるようにして、宿題が終わったことを示します。たとえば、

これらの人々は何が欲しい？」

次のような質問をします

要件文書のパラグラフ17では、foobarはfrozzleを縮める必要があると述べています。これらの3つのfrozzlesのどれがそれを指しますか？

または、要件が本当にひどく書かれていて、解読できない場合は、それを彼に伝えてください。

要件が正しく理解されていることを確認することは、最終的にはプロジェクトリーダーの責任であると思います（プロジェクトが成功するためには、彼の最大の利益になることは確かです）。しかし、チームの一員として、あなたはその責任の一部を共有します。自分で何らかの努力をしたことを示し、プロジェクトリーダーがあなたを助けることを拒否した場合、彼はそれを完全にあなたの責任にしました。それがそのポイントに達したら、彼がそれを知っていることを確認してください。

完璧な世界では、機能と仕様のリストがどこかにあるはずです。これは、会社と顧客を結び付ける契約に書かれたものです。

あなたの質問に答えるために、開発者は顧客が何を望んでいるかを実際に理解し、両方の当事者が同じビジョンに同意するように文書を作成する必要があります。

もちろん、これは完璧な世界ではなく、多くの場合仕様がありません。仕様が書かれていない場合、これは難しくなります。あなたの会社には、顧客との関係委任者として働いて、顧客が何を望んでいるかを理解するのを助けることができる人が残っていますか？

そうでない場合、あなたの立場で、私は以前の開発者から情報を取得しようとします。

誰が要件を理解するかを指定する実際の役割は、これらの変数のいくつかによって異なると思います

• チームサイズ
• 会社の基準
• 上司が働くために使用される方法
• チームメンバー間のさまざまな専門知識

あなたがただ一人のチームであるならば、あなたは要求の一番下に到達するためにあらゆる努力をするべきです。進行中のプロジェクトに慣れていない場合は、顧客と再度リクエストをやり直すよう努力する必要があります。

編集： 最も重要なことは、顧客がそのような貧弱な要件を行ったことを知らない可能性があり、要件を収集するプロセスは多くの場合長くて退屈なものですが、それは重要なプロセスです。彼らと一緒にやってください。