営業スタッフはアプリケーションの分析と設計に干渉する必要がありますか？
私たちは一種のCMSに取り組んでいます。これは、 Weebly のような高速でホストされた一元化されたWebサイトビルダーです。スクラム開発モデルも使用しています。しかし、ここにはいくつかの問題があるようです。私たちのセールスマネージャーはいつも私たちのところに来て、アプリケーションのデザインやUI要素などについて不平を言い、何度も何度もやり直して開発プロセスを妨げます。例は次のとおりです。
- グリッドアイテムの削除や編集などのアイテムアクションがあるのはなぜですか？グリッドの上にツールバーとしてリストアクションを設定するだけです。アイテムアクションはありません。
- なぜ赤い色？緑を使用してください。それは人々が好きなものです。
- グリッドではなく、コンテンツにツリーを使用します。
私の質問は本当に簡単です。営業スタッフがアプリケーションの分析と設計に干渉することは生産的であると考えられますか、それとも正常であると考えられますか？
あなたが干渉として見ているのは、単に彼らが新しい要件や変更された要件を乗り越えようとしていることかもしれません。あなたの色の問題の例は、この典型的な例です。
ただし、他の例は干渉と見なされる可能性があります。特に、それらを表現した方法です。
あなたがする必要があるのは、製品の方向性と設計について話し合うための定期的な会議を手配することですが、エンドユーザーの要件（「ユーザーはすべてのウィジェットを選択できる必要があります」）または販売要件のいずれかとして要件を述べるように依頼する必要があります（「このデータを円グラフとして表示できる必要があります」）実装の詳細としてではなく。一般に、目的を果たす限り、どのように実装するかは問題ではありません。
要件が特定の実装の詳細に一致する場合があります-例：階層をツリーとして表示します。
絶対に。
スクラムの要点は、すべてのスプリントの最後に製品所有者のフィードバックを取得して、正しいものを構築していることを確認することです。
セールスマネージャーはnotスプリントの途中であなたを邪魔しているはずです。しかし、最後にプレゼンテーションを行うときは、彼がそこにいて、あなたがいるはずです彼の苦情のすべてに欠陥を書く（彼はユーザーの声として行動しています）。
次に、スプリント計画会議を開催するときに、これらの欠陥を残りの製品バックログで優先し、適切と見なされるようにスプリントバックログに取り込む必要があります。セールスマネージャーは、（製品所有者の裁量で）製品バックログの優先順位付けの一部でもある必要があることに注意してください。 しかしそうではありませんスプリント計画の一部。
エンジニアは、ユーザーのインターフェイスの実装が苦手なことで有名です（ユーザーとは考え方が異なります）。営業チームは製品を販売する必要があり、おそらく彼は何が売れるかを知っています。チームに専任のUIエキスパートがいる場合、またはよく知られていて使用されている他の一般的なインターフェイスをコピーしている場合を除いて、UIレイアウトに関する彼のアドバイス（実装方法ではないように見える）はおそらくあなたよりも優れていると考えるべきです使用中のことをよりよく示すことができます）。
注：これは、同じものを繰り返し更新するのをやめるための便利な方法でもあります。そのためのバックログアイテムを作成します。セールスマネージャーが間違っていると思われる場合は、製品の所有者がそれを確認していることを確認してください。これは、バックログアイテムとクローズされたアイテムに記載する必要があります。セールスマネージャーが再びそれを持ち出した場合、この主題はすでに議論され、決定されていると言って、バックログ項目を彼に示すことができます。
理想的には、要件は顧客からのものである必要がありますが、営業スタッフも貴重なフィードバックのソースであり、営業スタッフがセールスマネージャーを介したリクエスト（個々のリクエストが殺到するだけでなく）は、単に干渉するのではなく、プロセスを支援しようとしていることを示唆しています。
営業スタッフは、顧客と開発チームの間の連絡役を務めていますか？もしそうなら、営業スタッフはその仕事をしています。営業スタッフもソフトウェアの消費者ですか？その後、彼らは設計に関するフィードバックを提供できるはずです。あなたが正しいことをしているなら、あなたは あなた自身の犬の食べ物を食べる とにかくあるべきです。
とはいえ、設計上の決定自体は営業スタッフが行うべきではありません。営業スタッフは単なる利害関係者の1人です。それらは、設計プロセスに影響を与えることができるはずですが、指示することはできません。
営業担当者の話を聞く必要があります。彼らは常に顧客と話しているので、顧客があなたのソフトウェアが良いか悪いか、そしてそれをどのように変更すべきかを彼らに話すのを聞く必要があるので、彼らは理論的に建設的な提案を提供するのに最適な立場にあります。
営業担当者に、適切で実用的なフィードバックを提供するように促します。ラベルの色をfuschiaに変更することは、誰にとっても最善の方法ではないかもしれませんが、全体的なスキームが読みにくいという顧客からのフィードバックに基づいて、全体的なカラースキームを再評価することは可能です。
スクラムでは、 Product Owner のみが、何をどの順序で構築するかを決定できます。したがって、変更要求をPOにポイントするだけで、POは通常どおりバックログで優先順位を付けることができます。
そうは言っても、営業部や他の人からの意見に問題はありません。彼らはおそらくユーザーとたくさん会い、あなたが恩恵を受けるかもしれない貴重な洞察を持っています。結局のところ、顧客、チーム、または営業からの機能要求を管理（および調整）するのはPO次第です。
売上高が開発プロセスで適切に表現/統合されていないように思われます。彼らは利害関係者ですか？そうでない場合、彼らの意見/懸念はおそらく利害関係者を通して集められるべきです。しかし、彼らは本格的な利害関係者である可能性があります。
最終的に、開発者としての私たちの責任は、製品の技術設計（およびその実装）です。デザインの残りの部分は私たちの責任範囲ではありません。デザイン（必ずしもグラフィックだけではない）がない場合は、必要があるため、空白を埋めます。しかし、それはそれが製品に最適なデザインであるという意味ではありません。
この設計の変更が問題になる場合は、調査して対処する必要があります。たぶん、開発は、作業を開始する前に埋めなければならない空白を指摘する必要があります。たぶん、開発はある程度の変動性を提供する必要があります。たぶん、問題はもっと早く対処する必要があります。 （問題が適切に対処されていない可能性があります。）営業担当は、変更要求の影響を理解する必要があるかもしれません。
私が懸念していることの1つは、あなたがこの質問を敵対的に表現したことです。この開発努力のために支払うお金をもたらすのは販売です。考え方は大きく異なるかもしれませんが、協力する方法を見つける必要があります。そうしないと、何も売ることができません。
干渉/干渉と提案の違いがあります。貴重な提案と役に立たない提案にも違いがあります。
コードの作業中にアクティブに中断されている場合、それは干渉または干渉としてカウントされます。そのような場合、あなたには営業担当者をあなたの顔から追い出す権利があります。さらに、会議での絶え間ない二次的な推測によって意思決定が損なわれている場合、営業担当者があなたの権限を損なう、またはあなたの能力に疑問を呈する努力をしている場合、それは確かに受け入れられません。
しかし、何かを提示するときに単にたくさんの意見を聞いているのであれば、これは干渉ではありません。家をペイントしている間、はしごでぐらついているのを見ながら、デッキの家具に座ってビールを飲んでいる友人から聞くような、それは歓迎されないアドバイスです。
提案がばかげているか気まぐれに聞こえても、営業担当者が善意を持っていて、顧客にとって最善だと思うものを望んでいる可能性は十分にあります。
提案を行うことで、営業担当者はデザインやインタラクションモデルの弱点を示唆している可能性があります。または、彼らはただ斧を斧で斧を持っているかもしれません。
変更の正当な理由がある場合は、実際の実装が文字通り提案の詳細を組み込んでいない場合でも、フィードバックに対応する方法を見つけることを試みる価値があります。聞くと何かを学ぶ可能性は十分にあります。これらの提案で使用されている単語は、実際の問題を指していない可能性があることに注意してください。それらは、まだ十分に理解されていない根本的な問題の単なる代理です。
私は、ある幹部が、そこに必要なビジネスロジックについて話し合うのではなく、左側のピクセル数をいじりたいと思っていた会議に参加しました。これは、彼の時間や私たちの時間の有効活用ではないことは確かです。しかし、私はまた、何かの外観や使用されたコントロールの種類について人々が不満を言うのを聞いたことがあり、それは本当にどのように何かが機能したかについての回り道の不満でした、それがどのように見えたかではありません。ユーザーは通常、それを取得するまで何が欲しいかわからないことに注意してください。営業担当者をユーザーの代理人と考えると、同じ問題に苦しむ可能性が高くなります。
したがって、すべての提案を受け入れる義務を感じないでください。ただし、営業担当者の口から出てくるすべての単語をすぐに却下しないでください。