レガシーシステムを推進する管理を処理する方法
私は現在有償インターンシップに参加しており、過去5年間に複数の開発者が（異なる時期に）開発した時代遅れのシステムを維持することを任されています。経営陣は「システムは生命維持にある」に同意し、現在システムを使用しているエンドユーザーからバグレポートをかなり定期的に受け取ります。
現在、経営陣はプロジェクトをさらに1年間延長したいと考えており、その過程でユーザーベースはほぼ3倍になります。
インターン（またはエントリレベルのポジション）として「プッシュバック」するにはどうすればよいですか？オープンエンドのドキュメントではありますが、私の懸念を述べたレポートはすでに書いています。変更を提案するためのプロトコルまたはドキュメントタイプはありますか？私は提案をする立場にありますか、それとも単に古いシステムをサポートし続けるべきですか？
- 明確に言うと、ソフトウェア開発は私の会社の主要なビジネスではありません。そのため、内部プロトコルはありません。さらに、プロジェクトには正式なドキュメントも要件ドキュメントもありません。開発は非常にアドホックです。
私は現在有償インターンシップに参加しており、過去5年間に複数の開発者が（異なる時期に）開発した時代遅れのシステムを維持することを任されています。経営陣は「システムは生命維持にある」に同意し、現在システムを使用しているエンドユーザーからバグレポートをかなり定期的に受け取ります。
このシステムは、人々がまだシステムを使用していて、ビジネス活動をサポートしていれば、古くなっているわけではありません。それはまだ使用されているので、ビジネスはそれを単に捨てることはできません-システムの必要がなくなるまでサポートされる必要があります。これは、ビジネス目標の変更であるか、新しいシステムが開発、テストされ、エンドユーザーに正常に展開された可能性があります。
本当に、5年はそれほど長くはありません。私は10年前のコードを使用したことがあります。それでもユーザーのニーズに応えているのなら、なぜ捨てるのですか？それはそれを開発するために費やされた多くのお金を捨てています。コストの増加や要件の大幅な変更により維持が不可能になるまで、それを破棄するビジネス上の理由はありません。
現在、経営陣はプロジェクトをさらに1年間延長したいと考えており、その過程でユーザーベースはほぼ3倍になります。
このシステムが「生命維持」されていると経営陣が言った場合、なぜ彼らはそれをさらに展開しようとしているのですか？レガシーシステムでは、交換されるまでメンテナンスアクティビティが継続するのが一般的ですが、システムが寿命に達した場合、通常はより多くの人に展開されません。メンテナンスの延長は1つのことですが、システムに依存するユーザーを追加することは、全体として異なる状況です。
私には、それは実際には寿命ではなく、むしろメンテナンス段階にあるように聞こえ、システムがユーザーのニーズに対応しなくなるまで存在し続けます。
インターン（またはエントリレベルのポジション）として「プッシュバック」するにはどうすればよいですか？オープンエンドのドキュメントではありますが、私の懸念を述べたレポートはすでに書いています。変更を提案するためのプロトコルまたはドキュメントタイプはありますか？私は提案をする立場にありますか、それとも単に古いシステムをサポートし続けるべきですか？
古いシステムを引き続きサポートする必要があります。後で、ソフトウェアは会社の主要なビジネスではないと述べました。このような環境では、ソフトウェアチームの仕事は会社の主要なビジネスをサポートすることです。ただし、ソフトウェアチームはビジネス目標も念頭に置く必要があります。
それまでの間、大胆にならない方法で提案をキャプチャしてください。システムに統合できる、または新しいシステムが作成された場合に使用される可能性のある他のテクノロジーやテクニックとその長所/短所を指摘します。これをどのように行うかは会社によって異なりますが、後のいくつかの点を考慮すると、おそらくWikiまたは他の共同サイトを確立することは有用でしょう。
ソフトウェア以外のビジネスでは、ソフトウェアはコストであり、ソフトウェアチーム（特にソフトウェアプロジェクト/プログラムマネージャー）は、エンドユーザーのニーズをサポートしながら、ソフトウェアシステムの構築と保守のコストをできるだけ最小限に抑えるように努める必要があります。 。 （とにかく、あなたの投稿から、とにかく）ユーザーのニーズを満たすソフトウェアを捨てることは、ソフトウェアチームの最善の利益に反します。
*明確に言うと、ソフトウェア開発は私の会社の主要なビジネスではありません。そのため、内部プロトコルはありません。さらに、プロジェクトには正式なドキュメントや要件ドキュメントはありません。開発は非常にアドホックです。
私には、これが問題です。ドキュメントを作成しない、仕様に合わせて開発しない、一貫性の欠如は、ソフトウェア開発のコストを増加させる傾向があります。これを修正することに取り組むことが私の最優先事項であり、コーディング標準、バージョン管理、自己文書化コードと設計文書の作成、欠陥追跡、および要件仕様のようなものに取り組むことでそれを行います。
私は自分の懸念を述べたレポートをすでに書いています
良い。それがインターンとしてできることの程度です。そのようなレポートを書くときの将来の参考のために、感情的な偏見のない公平で専門的な方法で難しい事実を提示することを強調します。レポートを誰が読むか、おそらく、あなたが説明している問題の一部を引き起こしたかどうか、またはこれらの問題につながった決定を下した人かもしれません。冷酷な事実以外の何かは、侮辱や犯罪などの人々によってとられる可能性があり、あなたを好きではなく、おそらくそれを真剣に受け取らないようにするでしょう。
経営陣は現在、プロジェクトをさらに1年間延長したいと考えており、その過程でユーザーベースはほぼ3倍
このようなビジネス上の決定は、彼らが利用できるリソースを使って期限を定めようとしているために行われることを覚えておいてください。経営陣はおそらくレガシーソフトウェアの問題を認識しており、ユーザーの不満も認識していると思いますが、リファクタリングや書き換えに対応できるソフトウェア開発リソースはありますか？
ほとんどの場合、そうではありません。特に、ソフトウェアが会社の主役ではなく、ソフトウェアの品質とユーザー満足度が収益に直接影響しない場合は特にそうです。このような決定を下すことは、あなたが何をしようとも負け負けの状況に陥ることが多いため、マネージャーであることが嫌な理由です。
過去5年間に複数の開発者によって（異なる時点で）開発された古いシステムを維持する
プロジェクト全体で間違いがあり、この点に至りました。確かなユーザー入力または要件の欠如、変化する要件とニーズを管理するための適切な製品管理と変更管理の欠如、および実装するための適切な技術リソースの欠如が、現在存在する問題を引き起こしました。時代遅れが正しい言葉かどうかはわかりませんが。基盤となるテクノロジーは、サポートされていないフレームワークとテクノロジーに基づいて構築されていますか、それとも最先端のテクノロジーや理想的なテクノロジーではありませんか？
インターン（またはエントリレベルのポジション）として「プッシュバック」するにはどうすればよいですか？
あなたは最も権力の少ない立場にあり、あなたはそれに対して一時的です。あなたが正しいかどうかは関係ありません、私はインターンが私にこれまで「プッシュバック」することを期待しません。私は彼らが学び、彼らが彼らを見たときに問題を話し合い、そして命令に従うことを彼らに期待します。それだけです。注文が与えられたら、彼らの能力を最大限に発揮することを期待しています。それは、その時点で話し合いの時間が終わったからです。
あなたはインターンです。全体として、日々のビジネス上の必須事項に遠く離れていることさえ疑わしく、他の人々が気づいているように、5年前のコードベースはそれほど古いものではありません。
レガシーシステムの交換に関する決定は、常に技術的に推進されるとは限りません。それらは変化するビジネス要件によって推進されます。それらへの入力は、維持に関連する困難になる可能性があります。しかし、結局のところ、自分の立場が必ずしもすべての利用可能な必要な知識を持っているという意味ではないことを認識する必要があります。現時点では、あなたが実際に最善策を提案するために必要な知識はごくわずかしかないと言っておきます。
あなたへの私のアドバイスはこれです：経験から学び、あなたの知識が日常的にビジネスを運営しなければならない人々のそれよりも優先されると仮定するのをやめてください。
あなたの仕事は、システムを稼働させ続けることであり、光沢のある新しい代替品を提案することではありません。
多くの若いプログラマーは、古いシステムのメンテナンスが、光沢のある新しいシステムの設計よりもプログラミング作業の重要な部分であることを認識していないようです/
押し戻さないでください。あなたがすべき唯一のことは、あなたの懸念を明確で簡潔な方法で表明することです。問題の事実は、あなたが将来働くであろうほとんどの企業がレガシーシステムを持っているということです。多くの場合、交換するには高すぎるため、これらのレガシーシステムを維持する必要があります。
多くの場合、現在のシステムをより良いシステムに置き換えるという最善の意図さえ持っているかもしれませんが、新しい異なるバグを導入するだけかもしれません...システムを離れると、システムはすぐにレガシーシステムに変わり、会社は以前と同じ場所にいる。その目的を果たさなくなるか、最新のシステムと完全に互換性がなくなるまで、時代遅れになるものはありません。私の会社には20年以上前のシステムがあり、現在ASP.NETに変換しています。システムはまだ稼働していますが、古いテクノロジーのサポートは減少しており、最新のWebブラウザーで機能させることはますます時間がかかるようになっています。
あなたができること：
物をきれいに残す
何かを維持するときは、開始したときよりもきれいにしてください。修正を行うだけでなく、クリーンアップを行うことで、次回誰かが変更を加える必要があるときに理解しやすくなります。
ドキュメントの作成
ドキュメントが不足していることが問題である場合は、ドキュメントを作成します。システムの特定の部分で作業しているときは、それを文書化します。
痛みを少なくする
私が述べたように、あなたはあなたの懸念を表明することができますが、あなたの最善はあなたがシステムに熱心に取り組むこととあなたの後のそれらのために取り組むことをより良くすることです。バグを適切に修正します。資料。コードのにおいを分散させます。改善する。そして、あなたがこれらのことをするとき、あなたの上司に知らせてください。開発プロセスを改善するためにX、Y、Zを行っていることを伝えます。それは信頼性を構築し、長期的にはあなたとあなたの会社を何よりも助けるでしょう。
私は、非常に理論的な意味でレガシーシステムと呼ばれるものはないと思います。私は非常に古い電話（レガシーシステム）を持っていますが、最近は良いAndroid電話（最新のプラットフォーム））ですが、私の電話は機能し、必要なことを行います。 ？
今日「レガシー」と呼んでいるすべてのシステムは、ある日最先端のものでした。必要なときだけです。また、相当な量の作業が行われている場合、最新のプラットフォームですべての作業をやり直すことはありません。つまり、自動的にバグがなくなる（または痛みがなくなる）ことになります。
ここに私があなたがすべきことをお勧めします：
まずは「レガシーシステム」への嫌悪感を忘れてください。これにより、生産性が大幅に低下します。
今何をしていて、何を考えているかを文書化し始めます。少しずつですが。ドキュメントを作成するのに必要な時間は、ドキュメントが必要だと気づいたときよりも優れています。
「レガシーシステム」の推進をプッシュバックする代わりに、スムーズに終了するためのパスを定義してください。分離できる新しい開発は、古いシステムとの相互運用性を損なうことなく、新しいプラットフォーム形式で段階的に実行できることを管理者に納得させることができるかどうかを確認してください。物事が進化するにつれてゆっくりと（そしてこれは本当にゆっくりとなるでしょう）、レガシーシステムを維持する必要性はなくなります。これが、古いシステムに別れを告げる唯一の方法です。
ディパン。
YOU DO N'T !!!これは素晴らしい機会です！
あなたは学ぶインターンシップです！このプロジェクトは、現実の世界です。
あなたはそれを持っていることはとても幸運です。あなたが無資格であるという事実はあなたの懸念ではありません。 （管理者がこれに気付いた場合、あなたはかなりの利益を得ます）
このインターンシップを終えると、資格が与えられます。これは素晴らしいニュースです。
PS：バックアップは慎重に行ってください。実行するものはすべてロールバックできるようにしてください。 「簡単な修正」という問題から始めますが、ユーザーにとって大きな問題です。赤ちゃんのステップを踏みます。
真実は、インターンがやりたいことをインターンに与えることではありません。あなたが最も若い人であるとき、あなたは最も刺激的でない仕事を得ます。あなたが個人的にどれだけうまく処理するかは、よりエキサイティングな仕事をするために彼らがあなたを信頼できるかどうかに関して、組織に多くを言います。
したがって、ここでは、バグ修正を行うことで提供できること、コードの各部分を少し変更することでリファクタリングできること、ユニットテストを作成できること、このシステム用にそれらを作成し始めることで、リファクタリングできることを示す貴重な機会があります。そして、あなたはこのシステムで立ち往生している次の貧しい魂のための文書を作成することによって文書化できるということです。また、ユーザーに効果的に対処し（報告されたバグの詳細を取得するため）、ユーザーのニーズを満たすことができることを示す機会にもなります。プロジェクトがソース管理下にない場合は、そこに配置し、バグがバグトラッカーで追跡されない場合は、開始します。これらのタイプのアクションは、プロとして働く方法を知っていることを示します。このすべては、あなたが去った後に捨てられるプロジェクトを行ういくつかの楽しいテクノロジーで働くよりもはるかに価値のある経験です（他の一部のインターンは行うために割り当てられます）。
または、反対の道をたどって、プロジェクトがどれほどひどく、それを置き換えるのがどれほどクールであるかについて単に気にしないかもしれません。その場合、あなたはインターンシップ後にその会社で仕事を提供されることはほぼ確実でしょう。
別の年に行っても費用対効果が高いかどうかを判断するのに十分な情報がない可能性があります。会社を理解し、なぜユーザーを追加するのかを理解するのは興味深いことです。一部の成長が進んでいるようで、別のアプリを構築するために経済的または一定の時間的制約の下で一歩下がる余裕はないようです。とにかく、新しいアプリを作成することはめったに最善の選択ではありません。彼らがそもそも古いテクノロジーに基づいて構築しない限り、5年はそれほど古いものではありません。