アウトソーシングされたソフトウェア開発プロジェクトを社内に移管するためのベストプラクティスと戦略は何ですか？
知識移転の最良の方法は何ですか？
どのような種類のドキュメントが期待されるべきですか？
外部関係者と私たちの両方によって、引き渡しの前後にどのような活動を行う必要がありますか？
これに対する答えは、多くの異なるものに依存します。
- あなたのチームはすでに開発を管理するスキルを持っていますか？
- このプロジェクトを引き受けるためのリソースはありますか？
- プロジェクトは機能的に完了していますか、それとも進行中ですか？
- 製品はサードパーティが所有する技術に基づいていますか、それとも専門知識が必要ですか？
- この移行を行うには、どのような時間枠が必要ですか？
- サードパーティはこの移行を簡単にしますか、それとも困難にしますか？ （彼らはビジネスを失っています、それは専門的でなく、近視眼的かもしれません、しかしいくつかの会社はそれを難しくしようとします）
- 製品はサーバー上で実行されますか？実行されているサーバーを現在所有していますか？
- 外部企業はユーザーサポートを行っていますか？
- コンプライアンスや法的な問題はありますか？
（注：これは正式なリストではなく、網羅的でもありません-私の提案ですが、これまでのところ、これらの種類の移行の1つを管理していましたが、移行は開発が始まる前に計画されていました-DaveNayが指摘するように、プロセスを作成しますはるかに簡単）
リソース評価
最初の4つの質問は、プロジェクトをリソース化し、維持し続ける能力を扱っています。明らかに、プロジェクトを遂行するためのスキルと利用可能なリソースが必要なので、プロジェクトのサイズを見積もり、スキルのギャップを理解する必要があります。このプロジェクトを維持し、合意された機能を提供するために必要な作業量を把握する必要があります。トレーニングとスキルアップのための十分な時間を含める必要があります。移行の終わりが近づくと、ベンダーはあなたを助ける動機が少なくなるので、スケジュールには十分な余裕があります。
ジョブのサイズを評価できるようにするには、ジョブに取り組む人にできるだけ早くコードベースを見てもらう必要があります。コードの品質に応じて、オンボーディングの労力は大幅に異なります。開発者の意見を取り入れ、慎重に検討してください。一部の企業は、意図的にコードを理解しにくくしているため、コードから移行するのが困難です。
プロジェクトによっては、専門的なスキルが必要な場合があります。場合によっては、サードパーティで働く人だけが持っているスキルも必要です。これが事実である場合（そしてベンダーとの関係に応じて）、ベンダーからのコンサルタントを6か月から1年の間社内で働くように手配することをお勧めします。そうでない場合でも、それはおそらく良い戦略であり、ベンダーはあなたの会社からの収益を完全に失うことはなく、あなたはより効果的にあなたのチームを訓練することができます。
テクノロジーとアーキテクチャの評価
プロジェクトのタイプとアーキテクチャに応じて、技術要件が何であるかを理解する必要があります。独自のサーバーを購入する必要がありますか？他のハードウェアまたはソフトウェア要件はありますか？ソフトウェアライセンス、追加のミドルウェアのインストールが必要ですか。ここには、考慮する必要のある項目の長いリストが存在する可能性があります。細かい櫛でプロジェクトを実行し、すべてのハードウェアとソフトウェアの依存関係を見つけて、それぞれのチェックリストを作成します。次のようなことを考慮する必要があるかもしれないことを覚えておいてください：
- 開発ソフトウェアライセンス
- データベースまたはOSライセンス
- ミドルウェアライセンスまたはハードウェア
- サーバーハードウェア
- ネットワークインフラストラクチャ
- ライブラリおよびその他のツール
- 外部サービスへのアカウント（例：Googleマップ、支払いゲートウェイなど）
- 開発/ステージング/ UAT環境
プロジェクト評価
次の段階は、プロジェクト自体を評価することです。ベンダーによって実装されていると思われるすべての機能のリストを取得し、バグ/問題または不完全な機能の記録があることを確認してください。これをベンダーに提出し、ベンダーが行うことの最終リストに同意します。これはお金の価値の観点からです-あなたがそれらにお金を払ったならば、あなたはそれらが行われたことを確認したいです。ベンダーとの関係が悪い場合、またはベンダーの能力に自信がない場合は、自分で作業を行うことをお勧めしますが、それでもリストを編集して、必要な機能を完了するために必要な作業を管理者が認識していることを確認する必要があります。すべての問題を修正します。
移行の管理
理想的には、移行期間中に並行して作業する必要があります。適切なオーバーラップ時間を必要としますが、長すぎないため、緊急性を失わないでください。プロジェクトのサイズによって異なります。1か月の短いもので十分であり、6か月の長いもので十分です。
ベンダーがほとんどの作業を行うことから移行を開始し、徐々に人々に問題を引き受けさせる必要があります。最終的には、すべての問題はチームが行う必要があり、ベンダーはサポートのみを提供します。チームの各開発者には、ベンダーの会社に誰かがいて、問題を解決するために電話をかけることができます。作業中の問題がシステムのできるだけ多くの部分に触れていることを確認してください。開発者がコードベースを理解するために数週間を費やす内部ハンドオーバーを見たことがありますが、期間の終わりには、システムがどのように組み合わされているかについて漠然とした理解以上のものは得られません。開発者は、システムの内外を実際に理解するために、コードを記述または変更する必要があります。
関係管理
3つの異なる種類の関係を管理する必要があります。
- 提供事業者
- あなたのユーザー/顧客
- あなたの管理
ベンダーを管理するという点では、あなたはすべての上に非常にいる必要があります。彼らが繰り返しビジネスや紹介のチャンスがない限り、彼らはあなたのためにプロセスを簡単にするインセンティブをほとんど持っていないことを覚えておいてください。一部の企業は、プロセスを非常に困難にします。
決定を下す権限を持ち、問題や問題について誰に連絡できるかをベンダー内に1つ連絡します。スムーズな移行を保証するのは、この担当者が責任を負うことに全員が同意する必要があります。ベンダーが何をするか、何をしないかについて事前にベンダーから合意を得ていることを確認し、同意するものが固定料金であることを確認してください。不特定の期間、特定の料金を支払うことに同意しないでください。そうしないと、ベンダーはかかとを引きずってしまいます。彼らにとっての最優先事項は、知識をチームに伝達することであることを明確にします。チームの開発者が助けを求めて来ない場合、またはあなたの人にそれをするように訓練する代わりに彼ら自身で物事をすることを主張する場合は、あなたの連絡先にすぐにそれを持ち出してください。
両社の開発チームとの最初の会議/電話をスケジュールして、全員が何を期待しているのかを正確に明確にします。毎週の通話をスケジュールし（ハンドオーバーの終わりが近づくと毎日）、すべての問題、バグ、機能、およびステータスを確認し、スケジュールどおりであることを確認します。
必要なユーザー/顧客とのコミュニケーションの量は、ベンダーが彼らと接触している量によって異なります。直接の連絡がない場合でも、何が起こっているのかを顧客/ユーザーに知らせ、移行中に遅延やその他の問題が発生する可能性があることを警告する必要があります。直接の連絡がある場合は、それを管理するための別のプロセスが必要になります。ユーザーサポートを提供している場合は、これを行うためのリソースやトレーニングなども確保する必要があります。
また、管理チームが起こっていることすべてを認識し続ける必要があります。そうしないと、遅延や混乱につながる問題が発生した場合、責任はあなたとあなたのチームにあります。常に上向きに管理し、可能な限り透明性を保ちます。マネージャーに定期的にレポートを送信し、可能な限り上に配布します。レポートが簡潔で明確であり、全体的なステータスが上部にあり、問題が赤で強調表示されていることを確認してください（ほとんどの上級管理職は詳細をあまり読みません）。ベンダーに問題がある場合は、それがレポートに記載されていることを確認してください。問題がやがてなくなることを期待して、問題を隠蔽しようとしないでください。問題がなくなる可能性があり、それはあなたにひどく反映されます。
その他
必要な法的またはコンプライアンスの問題を認識していることを確認してください。データ保護およびプライバシー法、規制報告、監査、サーベンスオクスリー法など。引き継ぐプロジェクトにそのような要件があり、それを遵守しない場合、罰則が厳しくなる可能性があります。