開発者はクライアントとどの程度対話する必要がありますか？
私の学部で哲学的な議論がありました。私はp.seの意見を聞きたいと思います。私たちは60人のITショップ内の6人の開発部門です。他のすべての部門はFASTで成長しており、私たちの部門は数年間同じサイズです（そのサイズで完全に予約されていません）。
私のマネージャーと昔ながらのメインフレーム担当者は、開発者は決してクライアントと連絡を取り合うべきではないと主張しています。クライアントとのすべてのやり取りは、プロジェクト管理レイヤーによって軽減する必要があります。これにより、コーダーはコーディングを行うために必要なフォーカスをコーダーに提供でき、ジョーアベレージコードモンキーの自閉症スペクトラム傾向からクライアントとのビジネス関係を保護できると彼は主張します。 （私の言葉ではなく、彼の言葉です。）
会社のオーナーである彼の上司は今朝、会社の一人一人が自分を販売部門の延長として考える必要があり、アップセルの機会のために常に耳を傾ける必要があると彼に話しました。この目的のために、開発者が販売の機会を聞く機会を得るために、クライアントが開発者に直接または完全に直接アクセスできるようにするべきだと彼は考えています。
私は真ん中のどこかにいます。開発者をクライアントからある程度保護するのはいいことだと思いますが、実際にはそれは決して完全ではありません。そして、はい、会社のすべての仕事には売上が含まれますが、それは必ずしも誰もが同じ機会を持っていることを意味するわけではありません。
編集：私たちはアジャイルショップではありません。私たちの一部（咳）はその方向に進みたいと思っていますが、今のところ、これは従来の固定入札契約ショップであると想定しています。
EDIT2：自閉症の冗談は面白くなかった。とった。自閉症のジョークが決してあり得ないことは完全に可能です。とはいえ、自分自身とその雇用主をうまく代表する能力を持つ開発者と、（現在）その能力を持っていない開発者がいます。私のマネージャーは、すべての開発者が構造的に会社の代表者になる権限を与えられた場合、会社がどのように代表されるかについて真の懸念を持っています。
また、ここでの実際のプッシュアンドプルはウォーターフォールとアジャイルの中間にあることが、応答を読むことからますます明らかになっています。
個人的には、直接クライアントと連絡をとる機会がなかった場所で働くことはありませんでした。 PMとBAのレイヤーを通過する必要があるときに要件の問題を解決しようとするのは面倒で、メッセージが明確に伝わることはありません。このアクセスにより製品を改善し、実際にクライアントのニーズを反映させ、適切な質問を知らない誰かによるそれらのニーズの解釈を反映させないようにします。
私がデータベースのETL作業を行っていることと、クライアントのIT担当者との5〜10分の会話でインポートまたはエクスポートに関する長年の問題を解決できることがよくあります。 IT担当者がIT担当者と話し合う必要がある場合があります。これは、これが差分インポートまたは2つの方法で行われるインポートの場合に特に当てはまります。データベースの構造とニーズ、およびデータベースのニーズを理解する必要があります。この情報を入手するには、直接話すことが唯一の方法です。
ただし、メールや電話を定期的に受けないようにしたいのですが、必要のないときに直接電話をかける人もいます。他の方法では解決できない問題が発生した場合にのみ、話をする必要があります。そして、あなたが彼らがお金を払っていないあなたから仕事を得るためにアクセスを利用しようとしないように、あなたは境界を設定することができなければなりません。私は常に、私たちが議論することになっている問題の範囲外の新しい要求を営業側に紹介します。
クライアントと直接話をしても、販売機会が増えることはめったにありませんが、頭の中でうまく機能しません。
お客様との接点がいくつかあるはずだと思います。従来のプロジェクト管理では、この人物がプロジェクトマネージャーです。スクラムでは、この人をプロダクトオーナーと呼びます。エクストリームプログラミングでは、それは顧客の代表です。スクラムとXPでは、この人物が顧客の組織の出身である必要はなく、決定を下すときに顧客の声が与えられるだけであることに注意してください。
私にとって最大の懸念は 通信パスの数 です。プロジェクトチームのコミュニケーションパスの数は、（N×（N-1））/ 2として定義されます。ここで、Nはプロジェクトチームの人数です。チームの全員が顧客またはクライアントに通信アクセスできる場合、Nは顧客の組織内の連絡先の数だけ増加し、通信パスが大幅に増加します。だれがどんな情報を知っているか、だれがいつ何を言ったかを知り、すべてのコミュニケーションを組織化しておくことはほとんど不可能になります。
開発チームとクライアント間の自由なコミュニケーションに関する2番目の最大の懸念は、プロジェクトの現在の状態とステータスに関して誰が何を言っているかを追跡すること、スケジュールと予算の見積もりを満たすことなどです。主要な連絡窓口を設けることで、開発組織の外部の誰もが適切な粒度で何が起こっているかを正確に把握し、チームの各メンバーが割り当てられたタスクを実行するために必要なすべてを確実に持つことができます。
私のマネージャーと昔ながらのメインフレーム担当者は、開発者は決してクライアントと連絡を取り合うべきではないと主張しています。クライアントとのすべてのやり取りは、プロジェクト管理レイヤーによって軽減する必要があります。これにより、コーダーはコーディングを行うために必要なフォーカスをコーダーに提供でき、ジョーアベレージコードモンキーの自閉症スペクトラム傾向からクライアントとのビジネス関係を保護できると彼は主張します。
大部分はあなたの上司に同意します。開発者は開発のために、テスターはテストのためにそこにいます。それは、開発者の1人が顧客の連絡先、製品の所有者、または顧客の担当者になれないということですか？絶対違う。実際、特に要件エンジニアリング、実現可能性のディスカッション、およびスケジューリングに関しては、顧客とのやり取りに関与することで、技術的なバックグラウンドを持つ誰かがいると役立つ場合があります（結局、エンジニアはエンジニアリングタスクのスケジューリングが得意です）。
クライアントを開発者から保護する必要があると主張することは間違っており、おそらく攻撃的です。エンジニアには、クライアント（およびプロジェクトのすべての利害関係者）と対話するために必要な知識とスキルが必要です。それは彼らがそれをするためにすべてに呼ばれるべきではないということだけです。
会社の所有者である彼の上司は今朝、会社の一人一人が自分を販売部門の延長として考える必要があり、アップセルの機会について常に耳を傾ける必要があると彼に話しました。この目的のために、開発者が販売の機会を聞く機会を得るために、クライアントが開発者に多かれ少なかれ直接アクセスする必要があると彼は考えています。
所有者は絶対に間違っています。販売やマーケティングの教育やトレーニングを受けていない人は、それらの部門の仕事をしてはいけません。エンジニアは販売やマーケティングとやり取りする必要がありますか？はいぜったいに。しかし、ソフトウェアを販売するのは彼らの仕事ではなく、利害関係者の要件を満たすソフトウェアを構築するのが彼らの仕事です。すべての開発者がソフトウェアの販売とマーケティングで忙しい場合、誰がそれを設計、構築、テストしていますか？
私はクライアントから完全に保護されていなくてもある程度同意できますが、開発者は気の利いた営業スタッフとして月光を浴びるべきではありません。
開発者はまさにそれであり、誰かが最終製品をどのように開発するかです。クライアントと数回会うことは、2つの当事者が特定のアイテムの開発から生じる可能性のある潜在的な問題をすべて明らかにできるため、良いことです。クライアントは自分が望むものを直接表現でき、開発者は可能なことを時間枠で表現できます。
これがうまくいかない場所は、絶え間ない接触です。あなたのクライアントが一日おきに心を変えるタイプの人であると想像してください。次に、クライアントが計画の変更を1日おきにdev-teamにメールで送信し、それが製品の開発に大混乱をもたらすと想像してください。クライアントが製品の変更について話し合うために「適切なチャネル」を通過するように強制することで、開発者は製品の仕上げに集中し、本当に必要が生じた場合にのみ変更を加えることができます。
開発者はクライアントと直接やり取りするのではなく、仕事やフィードバックを取得するときの管理や、サポートの問題を取得するときのクライアントサポート部門を通じてやり取りするべきだと私は感じています。開発者は実用的なタスクを取得する必要があり、クライアントが直接連絡（たとえば、電子メールのやり取り）を通じて何を望んでいるか、何が必要かを理解しようとすべきではありません。管理部門または営業部門などの他の部門に任せて、ソフトウェアの方向性を管理し、クライアントの要望/ニーズがどこに適合するかを把握できるようにする必要があります。
「アジャイル」開発キャンプにいる間、あなたのPMはウォーターフォールプロセスのファンであるかのように聞こえます。
ここに正しい面と間違った面があるかどうかはわかりませんが、私は間違いなく「アジャイル」側のほうが好きです。私は少なくとも週に1回はユーザーと話し、ユーザーが何をしているかを見て、問題を聞きます。それがサービス部門が処理できるものであれば、私は彼らに話しますが、十分な頻度で、サービス/販売/プロジェクト管理の複数のフィルターを介して通信が行われた場合、おそらく私には到達しなかった実際のユーザビリティの問題または欠けている機能を目にします。
私は、開発者がクライアントから保護されている会社で働いていました。その結果、開発者は契約書に適合したソフトウェアを提供しましたが、必ずしも有用であるとは限りませんでした。さらに悪いことに、開発者はビジネス価値のないものに誇りを持っていました。 （タッチスクリーンとキーボードのないシステムで優れたキーボードナビゲーションが必要なのは誰ですか？ソフトウェアのユーザーがバックグラウンドを持っていない場合、スクリプト機能が必要なのは誰ですかor時間or =スクリプトを使用する必要はありますか？）開発チームの暗黙的で記述されていない目標は、ユーザーが実際に必要とするものと「同期」することはありませんでした。そして、「開発者」が決定を下すことを許可されていない単なるコードモンキーでない限り、これは開発者の多くの時間を無駄にします。
私のマネージャーと昔ながらのメインフレーム担当者は、開発者は決してクライアントと連絡を取り合うべきではないと主張しています。クライアントとのすべてのやり取りは、プロジェクト管理レイヤーによって軽減する必要があります。これにより、コーダーはコーディングを行うために必要なフォーカスをコーダーに提供でき、ジョーアベレージコードモンキーの自閉症スペクトラム傾向からクライアントとのビジネス関係を保護できると彼は主張します。 （私の言葉ではなく、彼の言葉です。）
彼がこの見解を保持しているのは、彼が古い学校のメインフレームであり、仲間のコーダーについてのあなたのコメントが私の見解を尊重していないからではありません。
とは言っても、ユーザー/ビジネスレイヤーを誰が扱うべきかについてのサービス管理に関してはさまざまな考え方がありますが、それらは必ずしも管理の文化に依存しているわけではなく、最後にビジネスを行ったときのファッションに依存しています。コンサルタント。
開発者が何らかの優先順位付けプロセスを経由せずに機能をユーザーに販売できるようになればなるほど、所有者の立場は受け入れられません。私はあまり賛成しません。おそらく必要なのは、一部の層です。必ずしもプロジェクトマネージャーではありませんが、ビジネスアカウントマネージャーのように、ユーザーや顧客に実用的であれば販売できる機能を提案したり、他の人に行ってもらったりできます。ユーザーからの入力が必要な場合。
あなたのPMは正しいです。クライアントがDev's Direct＃を取得すると、Devにはサポートコールが殺到します。
PMは、彼が邪魔になることなくミドルパーソンとして振る舞うことができるように、十分に技術的である必要があります。
以下は屋上から叫ばれる必要があります。だからここに行きます]
それがPMの仕事です!!!開発者がすべての仕事をする必要があることを保証し、彼らが一定の中断なしで機能できることを保証するために！PMは、DEVSのために機能します!!! PMSは、DEVSが彼ISの仕事を間違っていると思い、プロジェクトを誤解している！
PMをバッファとして使用する方が一般的には良いと思います。存在しない場合、次のことに気づきました：
開発者は、要件がクライアントから直接入力されたときに発生する、体系化されていない、あまり考えられていない形式に圧倒されます。優れたPMは、クライアントの生のアイデアを開発に引き渡す前に洗練するという驚くべき量の作業を行います。これを実行して実際に製品を構築する時間のある開発者はほとんどいません。
一部のコンポーネントに不満があるため、開発者はクライアントに腹を立てています。開発者が自分のニーズを無視しているように見えるため、クライアントは開発者に腹を立てています。 PMは、圧力下で加熱される可能性が低い2つのパーティ間の客観的な通信チャネルを提供します。
ただし、機能するためには、次の要素が必要です。
プロジェクトマネージャーは良い人でなければなりません。彼らは誰にとってもパンチバッグになる能力を持っている必要があります。クライアントは開発者に不満を抱き、テスターはビジネスアナリストに不満を抱き、開発者はほぼすべての人に不満を抱きます:) PMは、すべての側面に耳を傾け、全員を幸せで生産的にするために存在する必要があります。
開発者は、厳しいテストの繰り返しを進んで行う必要があります。クライアントとの直接的なやり取りはそれほど多くなく、PMは要件を伝えるのに最適ではないため、クライアントとテスターはプロセス全体で可能な限り多くの反復を確認し、継続的に検証する必要があります。開発者が仕様を正しく解釈していることを確認します。プロジェクトの終わりまでコードに座って要件について質問するだけで、実際には成果物を頻繁にリリースしない開発者は、この種の構造ではうまくいきません。彼らの欠点ではありませんが、このようなスタイルの開発者は、より良いフィードバックループを作成するために、クライアントともっと直接対話する必要があると思います。
PM=バッファ構造を嫌う開発者もいますが、私はそれが好きになりました。要件の責任を負うプロジェクトの真ん中に誰かがいることは完全な命の恩人です。他に誰が責任を負うのでしょうか？クライアントは何が必要であるかを必要な詳細で説明することを期待できず、とにかく小切手を持つ人に多くの責任を負うことはできません。開発者は説明責任を負うことができますが、通常、彼らはすでに解釈する必要なく十分な能力を持っていますBAの不可解なとりとめ良いPMクライアントからのすべての熱を遮断する人は、開発者の仕事をはるかにストレスの少ない私見にします。
リードエンジニアは通常、高度に技術的な会議（または会議の中で高度に技術的な部分）の間だけ顧客と対話する必要があります。または、技術ロードマップのディスカッション。リードエンジニアとは、特定のプロジェクトのリードエンジニアではなく、チームの最高のエンジニアを意味します。
PMは、すべての最新の頭字語とアーキテクチャーの決定を知ることに対して必ずしも責任があるわけではありません。PM（および上司）は、これは、リードエンジニアがギャップを埋める必要がある場所です。
ITには、活用して尊重すべき役割があります。各役割には、顧客との連絡理由が0、1、またはそれ以上あります。
連絡理由は、PMによって定義される必要があります。
システムアナリスト、要件アナリスト、ビジネスアナリストなどの正しい役割は、PM監督の下で、有能なチームメンバーに割り当てる必要があります。
顧客とのやり取りは簡単なスキルではありません。スキルとプロジェクトポリシーの両方が、首相によって提示されるべきです。
奨励したいプラスは次のとおりです。
- ITとビジネスの良好な関係
- 単一または非常に限られた要件のソース
- 正確な要件収集
起こりたくないこと：
- プロジェクト計画/ポリシー以外の顧客への約束
- 提供できる顧客の要求を否定する
- 誰が何を約束したかを失う道
- 要件を不適切に文書化する
- 彼らが互いに話をしていないように見えるようにする
- お客様にITに対する自信を失わせる
- 統合なしで行き来するメールが多すぎる
したがって、あなたの質問に答えるために、「指定された」開発者は、PMで定義されたロールで、PMで指定されたインスタンスでのみ、 （プロトタイピングや共同テストなど）。
私は私のポイントを明確にしたいと思います...