開発者とクライアントの関係
私は現在、多くのシステムの実装を担当している小さな会社で働いています。そのほとんどは政府機関向けです。一般的には、20年前に開発されたソフトウェアを使用して、最新のニーズに合わせてシステムを改修することを意味します。クライアントは一般的に彼らに非常に慣れており、変化を思いとどまらせる傾向があります（彼らは50代から60代のギブまたはテイクであるため、一般的に技術に優しいものではありません）。
ご想像のとおり、ほとんどの場合、開発チームはクライアントとの関係の処理を開始し、この場合に必要なドキュメント（通常はCU）を生成し、クライアントとの改善を確認するための毎週の会議を支援します。
経験としては、これは私にとって金鉱です。ソフトウェア開発のすべての側面について素晴らしい視点を提供しますが、開発者が火星から来た場合、クライアントは金星から来たため、いくつかの問題も発生します。語彙/経験/解釈能力に微妙なギャップがあり、コミュニケーションにノイズが発生し、場合によっては最終製品に影響を及ぼします。
開発者はクライアントと直接連絡を取る必要がありますか、それともクライアントのニーズを私たちが理解できる疑似形式の要件に変換する「アダプター」の人が必要ですか？
常にクライアントと直接連絡を取り合ってください。常に。常に。
以前に直面した例を説明します。すでに存在していた製品は、独自のCSSを作成できるバージョン2.0でした（大変な作業です！）。 V2.0の実装中（何十年も前）、彼らは内部ブランドを反映するために緑色でCSSを作成しました。 （理由-デフォルトのスキームはマゼンタでした！）
2年前、バージョン6.0へのアップグレードに着手したとき、製品自体がデフォルトのスキームとしてMicrosoft（！）ブルーを選択しました。
予想通り、クライアントは緑色を手放すことをいとわなかった。内部的にも、対立がありました。 BAは、内部ブランディングは不要であり、デフォルトのMicrosoft（！）ブルーを使用できることに同意しました。しかし、いいえ、最終的な利害関係者は緑色を維持することを主張し続けました。そうしないと、アップグレードはまったく行われません。
私たち開発者は何をしましたか？
最終的な利害関係者との会議を開催しました。以下の方針で会議を開始-
あなたは何を知っていますか、私は私たちが内部のブランドの色を失うことになっていることに腹を立てています。あなたが長年にわたって築き上げてきた社内ブランドを失いかけていることに、どれほど腹を立てているのかわかりません。しかし、残念ながら、私たちは今、いくつかの難しい決定を下す必要がある段階にあり、あなたが私たち（開発者）を助けてくれることを願っています。
次に、アップグレードを実行するための優れた機能をすべてリストアップしました。
- アンカータブ（ああ、とても素敵です！）
- Webブラウザで列をドラッグして並べ替えます（ああ、それは素晴らしいです！）
- .。
- .。
- .。
- .。
そして、私たちは何が欠けているのかをリストアップしましたか？
- 内部のブランドカラーが失われます
として素敵な引用を投げました
あなたは戦争に勝つために戦いに負けることができます！
そして、私たちは彼らに決断を任せました。言うまでもなく、彼らはマイクロソフトの色を受け入れ、すべてが順調でした。
私たちが直接接触していなければ、これは不可能だったでしょう。なぜなら、BAではなくあなたが新技術の優れた機能を販売できる開発者だからです。
PS： Wanted がリリースされたので、引用を「1つ殺し、おそらく1000を節約する」に置き換えることができます。
開発者は絶対にクライアントと連絡を取る必要があります！ビジネスアナリストが正式な仕様を作成した場合でも、クライアントにアクセスして特定の質問をしたり、作業中の機能に関するフィードバックを即座に得たりすることは常に有益です。ビジネスアナリストは非常に役に立ちますが、私は要件のために彼らだけで仕事をしたくはありません。また、クライアントに機能を披露するのに1、2週間以上待ちたくありません。彼らが変更を加えたとしても、プロジェクトの最後にすべての変更を積み上げるよりも、開発の時期に近いところで小さな変更を加える方が常に簡単です。
新しいソフトウェア手法も、クライアントとソフトウェア開発チームを近づけることを目的としています。アジャイル/スクラムの主な原則の1つは、クライアントがチームに参加し、常に質問に対応できることです。アジャイルチームはまた、スプリントまたは反復のたびにソフトウェアのデモを行います。アジャイルは、ソフトウェアが変更され、チームが「アジャイル」であり、変化するビジネス要件に適応する必要があるという前提の下で形成されました。
常にクライアントの視点から始めます。例：質問：機能するものを変更する理由回答：テクノロジーはサポートされなくなる危険性があり、近い将来、テクノロジーに精通している開発者を見つけることができない可能性があるためです。
あなたは新しいテクノロジーに夢中になっているので、何かを変えたいという衝動を避けてください。彼らが1967年のVBカブトムシを運転し、あなたがプリウスに恋をしているからといって、彼らが変化の必要性を認識しているわけではありません。あなたの欲求ではなく、彼らのニーズに焦点を合わせてください。
それには2つの側面があります。
クライアントと直接連絡を取ることは素晴らしい考えです。実生活でのユーザーの行動、問題点、ソフトウェアに必要なこと、繰り返しビジネスを行うためにできることについて、貴重な経験を積むことができます。
このすべてにアダプターの人がいることも非常に重要です。あなたがいくつかの政府の会計ソフトウェアをやっているとしましょう。政府機関は、このソフトウェアの一部または全部を別の政府に再利用したくないと考えています。代理店も、おそらく別の州にあるものですか？もちろん、そうするでしょう、そしてそれがアダプターの人の出番です。このソフトウェアを別の関連エンティティの要件と問題点にマッピングし、開発者にカスタマイズを行うように依頼するのが彼/彼女の仕事です。
両方のアプローチが必要であり、補完的だと思います。
それは重要だと思いますが、それより少ない場合がいくつかあります。
- 開発者は、一般的なユーザーであるか、特定のドメインでの作業経験が豊富です。
- クライアントがほとんどまたはまったく対話しないアプリの部分を構築しています。
- 開発者は、現時点では強力なソーシャル/コミュニケーションスキルを持っていません。クライアントで練習するのではなく、それに取り組んでください。
- たるみを拾う他のチームメンバーがいます。
「プログラマーは、実際にプログラムを書くよりも、プログラムを書くのに役立つプログラムを書くほうがいい」という引用を思い出します。私はこのように感じたことがありません。私は、たまにマウスを玄関先に置いて、今までの様子を見せてくれる猫のようなものなので、注目を集めます。