社内で開発されていないアプリケーションを保守するための一般的な配置は何ですか?
注:メンテナンスとは、バグ修正、最適化、小さな変更、および将来の拡張を意味します。
これは、口に出さない(まあ、管理レベルでは口に出さない)問題の1つです。
シナリオ1は、保守、サポート、および拡張がオフサイトの会社によって行われることです。これは、それらが5年後にまだ存在していることを前提としています(そこでのビジネスにはリスクがあります)。この継続的なケアに伴う費用は、最初に考慮に入れる必要があります。
シナリオ2は、作業がオンサイトのIT部門に「ダンプ」されることです。経験から、特にオフショアに行くという決定に基づいて冗長性が行われた場合、それはしばしば評判が良くありません。たとえそれが好評であったとしても、あなたは他人のコードを理解しようとする学習曲線を持っています。稼働前にコードを確認する時間があれば、とても幸運です。それは通常、すべて消火活動です。また、時間の90%が理解に費やされていたという理由だけで、マネージャーが何かをするのにX倍の時間がかかる理由を理解できない場合もイライラします。
これがオフショアリングに賛成または反対として過度に出くわした場合はお詫びします。私は厳密にトピックから外れていると信じて、それに応じて私の応答を和らげようとしました! ;)
それはプロジェクトの開始時に考慮する必要がありますが、決まった答えはありません。会社ごと、プロジェクトごとに異なります。
社内チームがある場合は、継続的にサポートおよび強化するためにチームに引き渡すことができます。明らかに、これに関する問題は、最初から関与していなかった人々への引き継ぎに関する問題です。
このルートを進む場合は、プロジェクトの早い段階から内部チームのメンバーに参加して、仕様やコードのレビューなどを実施することをお勧めします。そうすれば、引き継ぎが来たときに、彼らは自分が見ているものを理解できます。 UATは、サポートがまだ利用可能である間に簡単な方法としてバグ修正の一部に関与する可能性があるため、実践的な能力でそれらをオンボードにする良い機会です。
引き渡しが契約に含まれ、双方で正しくリソースが提供されていること、およびアウトソーシング会社への最終的な支払いが満足のいくように完了することに依存していることを確認する必要があります。
あるいは、プロジェクトを完了した会社は、継続的に(有料で)プロジェクトを喜んでサポートするでしょう。ここでの問題は、コスト以外に、通常はスタッフの継続性が得られないことです。確かに長期的ではありません。また、引き継ぎは制御できないため、適切に管理されているかどうかさえ確認できません。
私はこれが(フェンスの両側から)発生するのを見てきましたが、元の開発者からサポート担当者への引き継ぎが不十分であることがよくあります。これは、コードや製品の品質の低下だけでなく、強化のコストはあなたに返されます(新しい開発者からの見積もりは、彼がシステムを本当に理解しておらず、実際には、その会社にそれを書くためにお金を払ったにもかかわらず、あなたが彼に学ぶためにお金を払っているので、より高くなります)。
個人的には、サポートのために常に内部ルートを使用します(サードパーティがソースコードを失うのを見て、これらは信頼するには重要すぎると思います)が、それは戦略的な決定であり、チームが存在しない場合は、押し売り。
通常、ある程度のメンテナンスが契約に含まれ(専用価格で、またはプロジェクトの一部として)、結果として生じる更新にはコストがかかります。
一般的に、メンテナンスのために次の2つの形式で新しい取引を行うことができます。
新機能/最適化/拡張機能の場合:
個人的にも開発者としても、すべてをプロジェクトとして扱い、バグを無料で修正するのが好きです。小さな最適化/変更。30分もかからない場合は無料で提供し(顧客を満足させます)、そうでない場合は時間単位で請求します。
理想的な状況は、クライアントにIT部門がある場合、新しい機能を追加し続けている間、クライアントがメンテナンスを担当できるように、必要な技術文書をクライアントに提供できることです。