クライアントがプロジェクトに貢献できるようにする最良の方法は何ですか？

クライアント用のCRMを構築しています。最初の主要なフェーズが終了し、2番目のフェーズが合意されたので、クライアントは作業の一部をピックアップし、2番目のフェーズを構築する間にデータベーススキーマとビジネスプロセスを若干修正します。

これが実用的かどうかは定かではありませんが、そうであると仮定すると、これを実行可能にするための対策を講じることができる指針が欲しいのです。ここに私がこれまでに得たものがあります：

• これまで、クライアントは主にユーザーの視点からプロジェクトを見てきました。明らかに、2部構成のセミナーを開催し、内部の仕組みを紹介します。

  • 最初に、既存のデータベーススキーマを表示し、例としてそれを拡張します。
  • 次に、サンプルコードをいくつか表示し、スキーマ拡張のための新しいビジネスプロセスを記述します。
• コードは現在、内部Subversionリポジトリにあります。私たちは彼のネットワーク（VPNに接続できる）にパブリックなものをセットアップできましたが、分散システムの方がうまくいくと思います。しかし、そのように感じるのは私だけだと思われるので、説得力のあるいくつかの議論を使用できます。

• 本番環境で実行されるコードがコミットされることを義務付け/保証する方法がわかりません。「xは休暇に入る直前に重大な、文書化されていない変更を加えたようだ。今ではyはそれ以来ずっと発生しているこのバグを見つけようとしている」災害は避けられない。理想的には、すべての変更は、展開前に次のことを行います。

  • 問題追跡システムに文書化される、
  • 最初に別のテスト環境で発生し、
  • 自動テストに合格する必要があります。

  悲しいかな、私はそれらのいずれかの規律が勝つことを疑います。

1）前者は存在せず、2）後者はクライアントが既存のコードを見て、場合によっては変更することを禁止するため、プラグインアーキテクチャまたは個別のプロジェクトは実行可能なオプションではないと想定します。主張する。

これは最も好きな答えではありませんが、それでもここにあります！

それは危険です（初心者が新しい車を運転できるようにするのと同じくらい）-しかし、それは悪い考えではありません。

なぜ彼らがこれをしたいのかを理解してください。それは彼らが予備のリソースを持っているということではなく、自分自身をコントロールしていると感じさせることです。

あなたがする必要があるのは以下です：

1. クライアントの教育-ソフトウェアは単なるコードではありません。参加したい場合は、まずアーキテクチャの側面、設計などを確認します。彼らに質問を投げかけ、彼らが前に行った選択の意味を示します。

2. アプローチの賛否両論については常にオプションに戻って（およびこれらの会議を適切に文書化して）決定を行うことを許可する必要があります。少なくとも彼らは、彼らがあまり知らないことを認め始めます-または、彼ら自身に所有権を取ります。

3. ブランチなどの別のスペースを作成して、必要なコードを作成できるようにすることができます。コミットまたはマージの前に、物事を適切にテストする必要があります。

合併症が起こる可能性があることは知っていますが、すべての問題はチャンスです。すべてがうまくいけば、クライアントは実際に内部の問題についてより多くの評価を得るようになり、あなたが良い仕事をしたことを（どのように）知っているので、より良い信頼を築きます！

PS：あなたに洞察を与えるために-私はインド出身です。そして、私は管理があまり多くの手がかりを持っていない非常に多くのITショップを知っています。彼らは通常、プロジェクトがゴミ箱に入らないようにするためにクライアントが追加のリソースを置くことを気にしません（幸せにさえ感じます！これは彼らにとって素晴らしいことです。それらはすべて、「あなたが言ったことは何でも！」という1つの考え方で行きます。これは私の同胞を軽deするためではなく、共同開発がそれほど悪い考えではないことを示すためです。結局のところ、多くの経営陣が描いているのは、ビジネス上の問題に対する「プロシューマーアプローチ」です。

痛い...あなたは正しい考えを持っていますが、私はこれがどれほど厄介であるかを見てきました、そして、両方の党はかなり苦しみます。現在、このようなアプリケーションをメンテナンスしています。

見つける本当の理由クライアントは、プロジェクトに直接貢献する必要があると認める理由を。彼らは今、あなたが現実的にそれを明らかにするよりも速くプロジェクトを完了したいと思っているのですか？彼らはすでに変更を望んでいますが、仕様の変更や追加機能のリクエストに追加費用が発生することを恐れていますか？社内の開発リソースがプロジェクトでより多くの制御と入力を必要とする組織や、社内の開発者のために忙しい仕事を探している組織で政治的闘争はありますか？（この最後の1つは私にとって家の近くでヒットします）

彼らの本当の動機を見つけて、可能な限りそれらに対処します。彼らがそれを示唆しているという事実は、トラブルが近づいていることを示す大きな警告サインです。そのようなことに同意する前に、彼らの本当の懸念を軽減するようにしてください。プロジェクトを強力にコントロールして段階的に廃止するか、大混乱とプロジェクトの失敗を引き起こす可能性が高いからです。

編集：残念ながら、その船はあなたのために航海しましたが、まだ絶望しないでください。来る痛みを大幅に最小化するためにできることはまだあります。何であれ、彼らが唯一無二のプロジェクトマネージャーおよび製品所有者であり、この人物があなたの組織/会社に関連していることを絶対に確認してください。この人は、スプリントを計画し、ユーザーストーリーを追加または削除し、社内およびクライアントの会社のリソースにタスクを割り当てる能力を持っている必要があります。起こるものは何でも、あなたの会社の開発リソースがさらに重要なあなたの顧客のリソースから別々に動作していないことを確認してくださいしないでください会社の開発者がプロ​​ジェクトマネージャーまたはプロダクトオーナーに報告できるようにします。彼らは、契約でカバーされていない無料の仕事を完全に利用するか、あなた自身のプロジェクトからあなたを奪います。それは確実です。

法的観点からは、基本的に「地雷原に目隠しされたロバに乗る最良の方法は何ですか？」

プログラミングの観点から、より多くの情報を求めます-クライアントが要求しているものは、何らかのユーザー定義のEAVシステムを使用して、またはシステムに追加できるフックを使用して実装できますか？理想的には、さまざまな理由から、クライアントのコードを可能な限りお客様のコードから分離しておく必要があります。

通常、ここでクライアントの役割を担っている人。正直に言うと、この問題は発生しません。これまでのところ、ソース管理になり、CIセットアップとQAセットアップを使用して物事をテストするからです。この配置はセットアップが非常に難しい場合があります。コンサルタントから、特に物事を進める際に多くの反論を受けます。請求可能な時間でプロセスの相互参照を行っているようです。

あなたの見方は、正直言って少し歪んでいると思います。まず、それはあなたのコードベースではなく、むしろ私たちのコードベースであることに留意してください。2つ目は、ほとんどの場合、クライアント側のITショップは、この製品が設計どおりに機能し、維持、管理、および今後のサポートが容易であることを確認する意欲が非常に高いことです。バグを修正するために戻ってくることは、ほとんどのコンサルタントとは異なり、請求できる時間ではありません。さらに、コインの運用面も所有している場合、簡単に構成可能で予測可能な方法で失敗するように物事を構築することは非常に重要です。開発スタッフの一部は請求可能な時間に制約されていないため、プロジェクトの品質が向上する可能性があります。

動作させる方法に関しては、DCVSが実現可能であれば、間違いなくその方法です。ニュートラルなもの（bitbucket、github）を選択すると役立ちます。CIを適切に配置することは、ここでの天の恵みでもあります。最後のコミットでCIが正常に動作しなくなったことを誰もが知っているときに、正常に動作するのが難しくなります。CIを介して物事を強制的に展開できる場合（通常はベンダーに強制する必要があります）、すべての変更が確実にコミットされるようにすることができます。トレーニングに関しては、数日間クライアントとペアリングすることを検討しましたか？それはあなたが必要とする横方向の結びつきを確立する良い方法かもしれません。全体としては、全員が同じチームに属していることを納得させることが最善策です。彼らは同じチームにいるからです。

これは技術的な問題であり、管理上の問題であるようです。コンサルティング会社とソフトウェア会社の両方で、このような状況に対処しました。全体的な「顧客はソフトウェアからどれだけの価値を得ることができますか？」および「ポストプロダクションを維持するためにどれだけの労力が必要ですか？」これは実際にはあなたにとって良い状況です。多くのクライアントは、人々が関与していると主張します。ただし、多くの作業が必要になります。

念頭に置いて、最初に必要なのは、優れた作業指示書です。これにより、フックの対象と、フックの対象が一覧表示されます。役割と責任行列が関与している各項目を、所有している、と誰がちょうど通知する必要があります誰が説明以下律法主義の文書です。これらは両方とも、各タスクが何であるかを低レベル（推定に十分な低さ）でリストする明確に定義されたWork Breakdown Structureがあることを前提としています。

作成に関しては、通常は逆の順序です。スコープ（明らかに既に持っている）-> WBS（持っているかもしれない）->役割と責任マトリックス-> SOW。

所有権を明確に定義したら、次はコードと環境を管理します。私はコード管理ツールについてはかなり不可知論者です。私が言うことは、コアチームの外部の誰かによって行われたすべてのことについてコードレビューを行うことが重要だということです。使用しているツールがこれにフラグを立てている場合、それでもなお良いでしょう。以前に行われた重要なアーキテクチャ上の決定に反する何かを締めつける人を避けたいと思います。4目コンセプト（2つの目ですべてを確認する）は、あなたができる最も重要な戦術的決定です。

環境も管理するのが苦痛です。通常、「私たちは自分の環境で仕事をし、終わったらあなたの仕事になります」という状況を経験し、ベンダーとクライアントの両方が苦労しています。あなたの状況はより複雑に聞こえます。プロジェクトが終了するまで、彼らがあなたの環境で働く方法を試してみることをお勧めします。クライアントの環境管理を訓練する方法を見つけることができれば（これが得意であるとは思わないでください）、さらに良いでしょう。

その他の注意事項...

1. クライアントがあなたのチームと同じ生産性を持っていると思い込まないでください。（ドメインの知識には上向きの驚き、ソフトウェアに固有の速度には下向きの驚きがあります。）

2. クライアントがあなたの方法論を知っていると思い込まないでください。

3. クライアントがチームのワーク倫理を共有していると思い込まないでください。（私は上向きと下向きの両方の驚きを見てきました。）

4. 多くの時間のトレーニングとコロケーションをお過ごしください。

5. トラブルシューティングをクライアントに教えるのに1時間費やすことで、将来何日も節約できます。

6. クライアントを活用して社内組織を介して作業し、コンテンツとドメインの質問の専門家を見つけてください。

7. クライアントを活用して組織のトレーニングを販売してください。

8. デフォルトでは、開発プロセスにクライアントを含めると、プロフェッショナルサービス会社のように考えるようになります。 デビッドマイスターは、このトピックに関する最高の本を執筆しました。20％しか関係ない場合でも、読む価値はあります。

これらすべての警告にもかかわらず、あなたのチームのクライアントを含むことは、あなたをあなたのバイヤーに近づけることに驚異をもたらすことができます。これらのクライアントは、将来参照される可能性が最も高いクライアントです。この状況を最大限に活用してください！

クライアントには、すべてがどのように設定されているかのウォークスルーを必ず提供する必要があります。これは、最初のフェーズでサインオフするための要件である必要があります。クライアントが何かを直接編集できるようにすることを後押しする必要があります。クライアントは問題追跡システムに入力され、残りの作業を優先する変更要求に記入する必要があります。どのリクエストが契約の範囲外であるかを決定するのは、あなたとあなたのクライアント次第です。これがどのように発生するかは、何らかの変更管理ワークフロー/ドキュメントで設計する必要があります。存在しない場合は、作成して、クライアントがこれを変更するプロセスであることをクライアントに同意してもらうことを強くお勧めします書き込み。そうでなければ、何もうまくいかないことを祈る以外にできることはあまりありません。