レガシーシステムを推進する管理を処理する方法

現在、私は有料のインターンシップに参加しており、過去5年間にわたって（異なる時期に）複数の開発者によって開発された古いシステムを維持する任務を負っています。経営陣は「システムは生命維持中」に同意しており、現在システムを使用しているエンドユーザーからかなり定期的にバグ報告を受け取っています。

現在、経営陣はプロジェクトをさらに1年間延長したいと考えており、その過程でユーザーベースのほぼ3倍になります。

インターン（または任意のエントリーレベルのポジション）として、「プッシュバック」する方法を教えてください。オープンエンドの文書ではありますが、私は懸念を述べた報告書をすでに書いています。変更を提案するためのプロトコルまたはドキュメントタイプはありますか？私は提案をする立場にありますか、それとも単に古いシステムをサポートし続けるべきですか？

• 明確にするために、ソフトウェア開発は私の会社の主要なビジネスではありません。そのため、内部プロトコルは存在しません。さらに、プロジェクトには正式な文書もまったくなく、要件文書もありません。開発は非常にアドホックです。

現在、私は有料のインターンシップに参加しており、過去5年間にわたって（異なる時期に）複数の開発者によって開発された古いシステムを維持する任務を負っています。経営陣は「システムは生命維持中」に同意しており、現在システムを使用しているエンドユーザーからかなり定期的にバグ報告を受け取っています。

このシステムは、人々がまだ使用していて、ビジネスアクティビティをサポートしている場合、時代遅れではありません。まだ使用されているので、ビジネスはそれを捨てることができません-システムの必要性がなくなるまでサポートする必要があります。それは、ビジネス目標の変更、または新しいシステムの開発、テスト、およびエンドユーザーへの展開が成功した可能性があります。

本当に、5年はそれほど長くありません。私は10年前のコードを使用したことがあります。それでもユーザーのニーズに応えている場合、なぜそれを捨てるのですか？それはそれを開発するために費やされた多くのお金を捨てています。コストの増加のために維持できなくなるか、要件が大幅に変わるまで、それを捨てるビジネス上の理由はありません。

現在、経営陣はプロジェクトをさらに1年間延長したいと考えており、その過程でユーザーベースのほぼ3倍になります。

このシステムは「生命維持装置」であると経営者が言う場合、なぜ彼らはそれをさらに展開しようとしているのですか？保守作業は、交換されるまでレガシーシステムで継続するのが一般的ですが、システムが寿命に達した場合、通常はより多くの人に展開されません。メンテナンスの延長は1つのことですが、システムに依存するユーザーを追加することは、すべて異なる状況です。

私には、それは実際には寿命ではなく、むしろメンテナンス段階にあり、システムがユーザーのニーズを満たさなくなるまでそこにあり続けるようです。

インターン（または任意のエントリーレベルのポジション）として、「プッシュバック」する方法を教えてください。オープンエンドの文書ではありますが、私は懸念を述べた報告書をすでに書いています。変更を提案するためのプロトコルまたはドキュメントタイプはありますか？私は提案をする立場にありますか、それとも単に古いシステムをサポートし続けるべきですか？

古いシステムを引き続きサポートする必要があります。後で、あなたはソフトウェアがあなたの会社の主要なビジネスではないことに言及します。このような環境では、ソフトウェアチームの仕事は会社の主要なビジネスをサポートすることです。ただし、ソフトウェアチームはビジネス目標を念頭に置く必要もあります。

それまでの間、あなたの提案を誇張しない方法で記録してください。システムと統合できる、または新しいシステムが作成された場合/使用された場合に使用される可能性のある他の技術または技術とそれらの長所/短所を指摘します。これをどのように行うかは会社によって異なりますが、後のいくつかの点を考慮すると、おそらくwikiまたは他の共同サイトを確立することが役立つでしょう。

ソフトウェア以外のビジネスでは、ソフトウェアはコストであり、ソフトウェアチーム（特にソフトウェアプロジェクト/プログラムマネージャー）は、エンドユーザーのニーズをサポートしながら、ソフトウェアシステムの構築と保守のコストを可能な限り最小化するように努力する必要があります。（私が知る限り、投稿からとにかく）ユーザーのニーズを満たすソフトウェアを捨てることは、ソフトウェアチームの最大の利益に反します。

*明確にするために、ソフトウェア開発は私の会社の主要なビジネスではありません。そのため、内部プロトコルは存在しません。さらに、プロジェクトには正式なドキュメントは一切なく、要件ドキュメントもありません。開発は非常にアドホックです。

私には、これが問題です。文書を作成せず、仕様に合わせて開発することも、一貫性を欠くと、ソフトウェア開発のコストが増加する傾向があります。これを修正することは私の最優先事項であり、コーディング標準、バージョン管理、自己文書化コードと設計文書の作成、欠陥追跡、要件仕様などに取り組むことでそれを行います。

懸念事項を記載したレポートをすでに作成しました

良い。それはインターンとしてできることの範囲です。そのようなレポートを書くときの将来の参照のために、私は感情的な偏見のない公平で専門的な方法で難しい事実を提示することを強調します。誰がレポートを読むのか、おそらくあなたが説明している問題のいくつかを引き起こした、あるいは引き起こしていないかもしれない、あるいはこれらの問題につながった決定をした誰かを知りません。冷酷な事実以外のものは、f辱や犯罪などの人々によって受け取られる可能性があり、あなたを好きにならず、おそらくそれを真剣に受け取らないようにします。

経営陣は現在、プロジェクトをさらに1年延長したいと考えており、その過程でユーザーベースはほぼ3倍になりました

このようなビジネス上の意思決定は、利用可能なリソースを使用して正当なものにしようとしているため行われます。管理者はおそらくレガシーソフトウェアの問題を認識しており、おそらくユーザーの苦情を認識していると確信していますが、リファクタリングまたはリライトに対処するためのソフトウェア開発リソースはありますか？

ほとんどの場合、そうではありません。特に、ソフトウェアが会社の基本でなく、ソフトウェアに対する品質とユーザーの満足度が収益に直接影響しない場合は特にそうです。このような決定を下すことが、何をするにしても負けやすい状況に陥ることが多いために、マネージャーになるのが嫌になることがあります。

過去5年間に複数の開発者によって（異なる時期に）開発された古いシステムを維持する

この点に至るまで、プロジェクト全体で間違いが発生しました。堅実なユーザー入力または要件の不足、変化する要件とニーズを管理するための適切な製品管理と変更管理の欠如、および実装するための適切な技術リソースの不足が、今日存在する問題を引き起こしました。しかし、時代遅れが正しい言葉かどうかはわかりません。サポートされていないフレームワークとテクノロジーの上に基礎となるテクノロジーが構築されていますか、それとも最先端のテクノロジーや理想的なテクノロジーではありませんか？

インターン（または任意のエントリーレベルのポジション）として、「プッシュバック」する方法を教えてください。

あなたは最もパワーの低い立場にあり、あなたはそれで一時的です。あなたが正しいかどうかは関係ありません。インターンが私を「押し戻す」ことは期待していません。私は彼らに学び、彼らが見ている問題を議論し、命令に従うことを期待しています。それについてです。注文が与えられたら、彼らの能力を最大限に発揮することを期待しています。その時点で議論の時間が終わっているからです。

あなたはインターンです。他の人が気づいているように、5年前のコードベースは実際にはそれほど古くはありません。

レガシーシステムの交換に関する決定は、必ずしも技術的に決定されるわけではありません。それらは、ビジネス要件の変化によって推進されています。それらへの入力は、メンテナンスに関連する困難になる可能性があります。しかし、一日の終わりには、自分の立場が必ずしもすべての利用可能な必要な知識を持っていることを意味するわけではないことを認識する必要があります。私は、あなたが現時点で最高の動きであるものを呼び出すために必要な知識を実際にはほとんど持っていないとまで言います。

あなたへの私のアドバイスはこれです。経験から学び、あなたの知識が日々ビジネスを運営しなければならない人々の知識に勝ると仮定するのを止めてください。

あなたの仕事は、システムを機能させ続けることであり、光沢のある新しい交換品を提案することではありません。

多くの若いプログラマーは、古いシステムのメンテナンスが、光沢のある新しいシステムの設計よりもプログラミング作業の大きな部分であることを認識していないようです。

押し戻さないでください。あなたがすべき唯一のことは、明確で簡潔な方法で懸念を表明することです。問題の事実は、将来あなたが働くほとんどの企業がレガシーシステムを持つことです。多くの場合、交換するには高価すぎるため、これらのレガシーシステムを維持する必要があります。

多くの場合、現在のシステムをより優れたシステムに置き換えることをお勧めしますが、新しいバグを導入するだけで済みます...システムを離れるとすぐにレガシーシステムに戻り、会社は以前と同じ場所にいる。その目的を果たすか、最新のシステムと完全に互換性がなくなるまで、時代遅れのものはありません。私の会社には20年以上前のシステムがあり、現在ASP.NETに移行しています。システムは引き続き動作しますが、古いテクノロジーのサポートは減少しており、最新のWebブラウザーで動作させるにはますます時間がかかります。

できること：

物事をきれいにする

何かを維持するときは、開始したときよりもきれいにしておきます。修正を行うだけでなく、物事をクリーンアップして、次に誰かが修正を行う必要があるときに理解しやすくします。

ドキュメントを作成する

ドキュメントの不足が問題である場合は、ドキュメントを作成します。システムの特定の部分で作業しているときは、それを文書化します。

痛みを軽減する

私が述べたように、あなたは懸念を表明することができますが、あなたの最善はシステム上で熱心に働き、あなたの後の人々のために取り組むことをより良くすることです。バグを適切に修正します。資料。分散コードの匂い。改善する。そして、これらのことをするときは、上司に知らせてください。X、Y、Zを実行して開発プロセスを改善することを伝えます。それは信頼性を構築し、長期的にはあなたとあなたの会社を何よりも助けるでしょう。

いけない!!! これは素晴らしい機会です！

あなたは学ぶためのインターンシップです！このプロジェクトは現実のものです。

あなたはそれを持ってとても幸運です。あなたが資格がないという事実はあなたの懸念ではありません。（もし管理者がこれに気づいたら、あなたは多くを得たでしょう）

このインターンシップを終了すると、資格が得られます。それは素晴らしいニュースです。

PS：宗教的にバックアップを作成します。あなたがすることは何でもロールバックできることを確認してください。「簡単な修正」である問題から始めますが、ユーザーにとって大きな苦痛です。赤ちゃんの手順を実行します。

非常に理論的な意味では、Legacy systemと呼ばれるものはありません。私は非常に古い携帯電話（レガシーシステム）を使用しており、最近では優れたAndroid携帯電話（近代的なプラットフォーム）がありますが、私の携帯電話は機能し、必要なことを行います。なぜそれを捨てなければならないのですか？

今日「レガシー」と呼ぶすべてのシステムは、かつて最先端のものでした。必要なのは時間だけです。また、かなりの作業が行われている場合、最新のプラットフォームですべてをやり直すということではありません。つまり、自動的にバグがなくなる（または痛みがなくなる）ことを意味します。

ここにあなたがすべきことをお勧めします：

1. 最初に「レガシーシステム」に対する嫌悪感を捨ててください。これにより、非常に非生産的になります。

2. あなたが今やっていることとあなたが考えていることを文書化してください。段階的な方法ではありますが。ドキュメンテーションを行うには、必要なことに気づくよりも良い時間はありません。

3. 「レガシーシステム」の推進を押し戻すのではなく、出口のパスをスムーズに定義してください。分離できる新しい開発は、古いシステムとの相互運用性を損なうことなく、新しいプラットフォームで段階的に実行できることを管理者に納得させることができることを確認してください。物事が進化するにつれてゆっくり（そしてこれは本当にゆっくりとなるでしょう）、レガシーシステムを維持する必要性はなくなります。古いシステムに別れを告げる唯一の方法です。

ディパン。

真実は、誰もインターンに彼らがやりたい仕事を与えないことです。あなたが最も若い人であるとき、あなたは最も刺激的な仕事を得ます。あなたが個人的にどれだけうまく対処しているかは、彼らがあなたにもっとエキサイティングな仕事をすることを信頼できるかどうかについて、組織に多くを語っています。

バグ修正を実行することで提供できること、コードの各部分に少し手を加えてリファクタリングできること、ユニットテストを作成できること、このシステム用に作成を開始できることを示す貴重な機会です。そして、このシステムにこだわっている次の貧しい魂のための文書を作成することで文書化できること。また、ユーザーに効果的に対処して（報告されたバグの詳細を取得する）、ユーザーのニーズを満たすことができることを示す機会も提供します。プロジェクトが現在ソース管理されていない場合はそこに配置し、バグがバグトラッカーで追跡されていない場合は開始します。これらのタイプのアクションは、専門的に働く方法を知っていることを示します。

または、反対の道をたどって、プロジェクトがどれほど悪いのか、それを置き換えるのがどれほどクールなのかについてただの雌犬にすることもできます。その場合、インターンシップ後にその会社での仕事はほとんど確実に提供されません。

おそらく、もう1年行くのが費用対効果が高いかどうかを判断するのに十分な情報を持っていません。会社を理解し、なぜ彼らがユーザーを追加しているのかを理解することは興味深いでしょう。ある程度の成長が見られるようで、経済的にも一定の時間的制約の下で別のアプリを構築することもできません。とにかく、新しいアプリを構築することはめったに最良の選択ではありません。そもそも5年というのは、古い技術で構築しない限り、それほど古いものではありません。