非技術スタッフは開発チームに代わって要件を収集できますか?


8

大規模な組織で作業する場合、開発チームのメンバーがクライアントに直接アクセスして要件を収集できないことがよくあります。アカウントマネージャーに質問のリストを提供して、あなたに代わって要件を収集できるようにすることは可能ですか?

回答:


5
  • 可能:はい:-)

  • 推奨:本当に他に方法がない場合のみ。これは、非常に壊れやすく、十分に理解されていない要件を簡単にもたらします。そして、問題は、実装または受け入れテスト中の後の段階でのみ現れる可能性があります。

理想的に収集する要件は、クライアントと開発者の間の一連の詳細なディスカッションである必要があります。クライアントは通常、本当に欲しいものについて非常にかすかな考えを持っているため、最初のあいまいな説明をそのまま実装すると、ほぼ必然的に問題が発生します。したがって、開発者は、各アイデア/ストーリー/要件の価格を伝えることができるはずです。これは、クライアントがニーズを優先するのに役立ち、何が可能で何が可能であるかについて技術的なフィードバックを与えることができます。また、クライアントの問題に対する最良の技術的解決策を提供するために、必要に応じて問題ドメインを深く理解する必要があります。そして、すべての過程で、クライアントを適切に理解していることを確認する必要があります。つまり、説明を求めたり、コミュニケーションセッション中に自分の言葉で理解したことを繰り返したりします(そして、クライアントのアイデアのUIプロトタイプ/モックアップを頻繁に提供します)。これに最適な媒体は口頭でのコミュニケーションです。面と向かって話すことができない場合は、ビデオ会議または電話会議が次善の選択肢です。

クライアントと開発者の間の通信チャネルとして技術者以外の人がいると、通信の効率が大幅に制限されます。少なくとも仲介者がいない場合は、電子メールでドキュメントをやり取りすることもできます。そのため、誤解の可能性が1つ少なくなります。


私はあなたに同意しますが、なぜ開発者とビジネスの間にプロキシがあり得ないのですか?大企業のプロジェクトでの私の経験は、複数のシステム(異なる場所に異なる開発チームがいる可能性があります)、データウェアハウジングとレポート、インフラストラクチャ、さらにはビジネスプロセス自体の変更にさえ触れています。このすべてを世話する誰かが必要です。
softveda

3
@Pratik、それはいくつかの店ではビジネスアナリスト(BA)と呼ばれています。BAは確かに便利な場合があります(現在のプロジェクトにもBAがあります)。ただし、優れたBAは(IMHO)アカウントマネージャーとはかけ離れています。彼女は問題ドメインについてよく知っており、アプリケーションについても(必ずしも深い技術レベルである必要はありません)。
ペーテルTörök

開発者とビジネス間のプロキシは機能しますが、プロキシがトレーニングされ、何を尋ねればよいかを知るのに十分な知識がある場合のみです。顧客のニーズを単に知っている人に依存することは、それらのニーズを、開発に必要な詳細レベルに到達する技術仕様に変換する方法がわからない場合の失敗のレシピです。
Beofett、2011年

ビジネスアナリストとして、通信チャネルとして機能する非技術者が効率を大幅に制限することについては、完全にあなたに同意する必要があります。私のIT産業の特定の部分(政府請負)では、顧客がどのように機能し、どのように機能できるようにしたいのか、そして顧客が何を重要視しているのかを正確に理解するために膨大な時間を費やしました。私たちのソフトウェアエンジニアは、お客様のビジネスプロセスのビザンチン的な側面を解明するために必要な時間や傾向(通常は社会的スキル)を持っていません。ユーザーとアプリケーションについて多くのことを知っています
JBiggs

5

仲介者が効率を制限する可能性があることをPéterTörökと同意しますが、開発者以外のユーザーとエンドユーザーと話し合うことで、コミュニケーションの効率を高めることができます。

私は、開発者とエンドユーザーが一緒に話をすることがよくありますが、それらは「異なる世界」から来ているため、お互いを誤解している場合があることがわかりました。同じ言葉を話している間、彼らは完全に異なることを意味するためにそれらを理解するかもしれません...エンドユーザーと開発者の考え方/言語の両方を理解する仲介者は、必要なものの相互理解を改善する金の重みに値することができます/開発されるもの。

そうは言っても、アカウントマネージャーやその他の種類のマネージャーであっても、マネージャーに尋ねるのは適切ではありません。開発者とエンドユーザーの世界のギャップを埋めるのはスキルであり、「余談」として行うことではありません。


あなたはあなた:-)書いていた間、私は完全に開発者が真の解決策を提供するために、問題領域を理解する必要があることに同意し、この線に沿って私の答えを拡張
ペーテルTörök

@Péter:はい、StackOverflowでの回答は、人々が同時に話すようなものです。他の人が言った後に聞いたことだけを聞いて、自分で話す(答える)のをやめた(または新しい答えをロードした)チャットセッションで行うように、誰かが入力していることを示すのは良いことですが、StackOverflowサーバーに要求しすぎると思います... :-)
Marjan Venema

同意する。私はビジネスアナリストとして、顧客の考え方や機能についてほとんど知らないソフトウェアエンジニアと、ソフトウェアの開発方法についてほとんど知らない顧客との間の橋渡しをしなければなりません。私は、私がしていることをする人はコミュニケーションに非常に貴重であると双方から聞いています。クールなテクノロジー中心の道をたどっていた計画セッション中に、「素晴らしい」と言って何かを言うことができましたが、それは彼らが使いたい方法ではありませんでした。これは、彼らが見ることができる必要がある...」
JBiggs

2

つまり、この作業方法には危険が伴い、アジャイルマニフェストが誕生した理由の1つでした。

{ユーモアの悪い試み}乞う、借りる、戦う、チートする、盗む、魅力する、パブに連れて行く、実際にエンドユーザーと関わるためにできることは何でもする{/ユーモアの悪い試み}

ただし、真剣にアクセスできない場合は、少なくともフィードバックサイクルが速いことを確認してください。ですから、アカウントマネージャーを通じて質問をすることができます(リモートアクセスの方が優れているメールからでも、クライアントに直接アクセスできる場合)が、毎日尋ねて、クライアントが試せるようにできる限り頻繁にプロトタイプを提供します。

そうでなければ、エンドクライアントが実際に望まないものを提供するという大きなリスクがあります。


2

私は中規模の組織で働いており、多くのビジネスアナリストを抱えるビジネスソリューションチームがあります。彼らはビジネスプロセスを非常によく理解し、ビジネスが望むものを開発者が理解するものに翻訳するので、彼らは重要な仕事をします。他の方法でも機能します。設計や建築の問題を検出した場合、または問題を解決する別の方法を提案した場合、私は彼らと話し合い、彼らはビジネスに向かいます。

大企業では、要件を作成するときに技術的なこと以外に考慮すべきことがたくさんあります。スタッフのトレーニングの問題のように、顧客に変更を与えない、質問を問題のないものにするために存在する補償プロセスのように、または「ジョン」はマーケティングがこの機能を使用していて、これを変更することはできないなど。

構造がある場合は、質問に答えるためにそれを使用してください。ビジネスアカウントマネージャーにフォローアップする質問のリストを提供します。


1

あなたは電話ゲームの要件収集バージョンをプレイしています。せいぜい、これは多くのコミュニケーションの非効率性を引き起こします。最悪の場合、要件が正しく収集されなくなります。このフィードバックループとその効率の重要性は、顧客担当者がアジャイルチームで最も価値のある(そしてスケーリングが最も難しい)役割の1つである主な理由の1つです。


0

番号

あなたの質問を文字通りに捉えると、その答えは、「NO!NO!千と二十四回NO!「アカウントマネージャー」が訓練を受けたコンサルタント、アナリスト、開発者でもない限り

プロセスに訓練を受けていない仲介者が必要な場合は、ユーザーアンケートをメールで送信し、アカウントマネージャーにCCを送信することをお勧めします。彼/彼女はおそらくプロセスに付加価値を与えることはできませんが、コミュニケーションを確実に乱すことができます。

このプロセスにおけるアカウントマネージャーの適切な役割は、ミドルウェアやアマチュアアナリストではなく、利害関係者として会話参加することです。


+1、同意する必要があります。それはたくさん起こります、しかし私はそれがうまくいくのを見たことがありません。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.