大規模なシステム変更の実施 [終了]

Question

「捨てるために建てる」というフレーズをご存じの方は、そう、私たちはそれを実行したようです。オンライン アプリのバージョン 1 の制限に達しつつあります。次の方法で物事をクリーンアップしましょう。

• コードとUIの再構成
• UIプロセスの統合
• さらに機能を追加する
• 未来に向けた構築
• 上記のすべてを処理できるようにデータベース構造を変更する

この移行を実現する最善の方法は何でしょうか?

私たちは、(終了後に) すべてのユーザーを新しいシステムに引き渡すことを避けたいと考えています...彼らはパニックになり、私たちは通話負荷に対処できなくなりました。当社のユーザーは、技術的に熟練したソフトウェアの作成に慣れているタイプから、HTML が何なのかを知らないユーザーまで、幅広いユーザーに対応しています。

システムの新しい「インストール」を開始し、この新しい設計がバージョン 1 の問題を十分に解決していることを確認した後、ユーザーを徐々にそのシステムに移行する必要がありますか?

システムの各モジュールを（何らかの方法で）段階的に変更する必要があるでしょうか?データベースのレイアウトが変更され、その結果「コア コード」と周囲のいくつかのモジュールのコードを調整する必要が生じるため、これは難しい場合があります。

最先端のバージョンのアプリを使用する、信頼できる忍耐強い「ベータ テスター」クライアントを一組持つのは一般的ですか?(ここでの目標は、フィードバックを取得し、新しいシステムでバグをテストすることです)

他にアドバイスはありますか？初体験？

Answer 1

残念ですが、答えは状況によるです。それはアプリケーションの種類とユーザーの種類によって異なります。どのようなシステムなのか、バージョンの変更範囲が分からないと、お答えすることが困難です。

そうは言っても、いくつかの経験則があります。

まずビッグバン打ち上げを避けること。システムを立ち上げると必ず問題が発生します。業界には、人々がバンバン打ち上げが素晴らしいアイデアだと考えていたにもかかわらず、問題が発生して打ち上げが頓挫したプロジェクトがたくさんあります。 クイル ビッグバン打ち上げの因果関係として最近注目を集めた。

歯が生える問題を対処しやすくするには、最初は少数のユーザーで作業し、その後ゆっくりとユーザーの数を増やしていく必要があります。

次に、絶対に積極的にしなければならないことは、 ユーザーを第一に考えます. 。システムの V2 を使用するには、ユーザーは最小限の作業を行う必要があります。理想的な仕事量はゼロです。

これは、あるシステムから別のシステムにユーザーをゆっくりと移行することを選択した場合、 あなた すべてのデータと設定が確実に移行されるようにする責任があります。たとえば、2008 年 12 月 9 日より前のすべてのレコードには V1 を使用し、それ以降のすべてのレコードには V2 を使用する必要があるとユーザーに指示するような愚かな行為は行わないでください。

V2 をリリースするポイントは、ユーザーの生活を楽にすることであり、不必要に難しくすることではありません。

第三に、ベータ版プログラムを用意します。これはイントラネット アプリケーションにも当てはまります。アプリケーションの開発は、多項式の根を求めるニュートン・ラフソンの方法によく似ています。ユーザーが望んでいることを推測し、それをユーザーに提供し、ユーザーがフィードバックを提供するという繰り返しで、ゆっくりと、しかし確実に問題の解決策に近づいていきます。

ベータ プログラムは、変更についてコメントする時間を与えずに新しいバージョンを人々に押しつけるよりも、はるかに早くルートを見つけるのに役立ちます。ベータ版は、ユーザーを早期に参加させ、プロセスに参加していると感じさせるのに役立ちます。その重要性はいくら強調してもしきれないほどです。

Answer 2

私たちはユーザーにまったく新しい CRM システムを導入し終えたところですが、そのようなやり方でそれを行うのはひどいアイデアだったと言わせてください。私のチームにとっても、お客様にとっても、非常に苦痛でした。

たとえそれがより多くの作業を行うことを意味するとしても、私は段階的なリリースを行うためにあらゆる手段を講じるつもりです。すべてを移行するために英雄的な努力をする必要がないため、顧客は製品を少しずつ紹介できることに感謝するでしょう。

お役に立てば幸いです!

Answer 3

同意する エステバン 段階的なリリースが最適であるということです。家を改築するようなものです。最初はそれを終わらせるのが良い考えのように思えます。ただし、事前にすべてを計画し、多くの請負業者を雇って引っ越しする必要があることを意味します。その後、計画に何か変更が生じたり、請負業者がいなくなったりして、節約できると期待していた時間がすべて失われます。一方、段階的な変化により、ステップの合間に誰もが立ち止まって考える機会が得られます。以前の変更が計画よりもうまくいった場合、後の変更を回避できる場合があります。

私はスケーリングに大きな問題を抱えたシステムに取り組んでいます。私たちは必要と思われるすべての変更のリストを作成し、予想される影響に基づいて優先順位を付けました。それから、一度に 1 つずつ変更を加え始めました。リストの半分ほどで、スケーリングの問題が解決されたことがわかりました。リストはまだありますが、完成させる必要はないかもしれません。自由に機能を追加したり、他の問題を解決したりできます。

もちろん、場合によっては、思い切って全部壊すのが最善の場合もあります。しかし、それは人々が信じがちなほど一般的ではありません。また、重要な運用システムにとって、「破棄」の決定は致命的となる可能性があります。現代のコンピューティング時代に導入する必要があると誰もが同意している大規模な政府プロジェクトを見てください。ただし、重要なサービスの一部が失われるため、それはできません。もし哲学が段階的に変化していれば、おそらく一度に一つずつ近代化されていたでしょう。

Answer 4

まるで インクリメンタルな再アーキテクチャ アジャイルの流行語として選択する必要があります。

Web アプリケーションでそれを行ったことはありませんが、段階的に行われるかなり根本的なクライアント アプリケーションの変更を経験したことがあります。事前に少し時間を投資して、作業が適切な方法で順序付けされていることを確認すると、うまく機能する可能性があります。優れたリファクタリング支援ツールをまだ持っていない場合は、それに少額の投資をすると非常に役立ちます。個人的にお勧めできます ジェットブレインズ リシャーパー .NET を使用していて、Java ベースの場合は、IntelliJ IDEA に同様の機能が含まれていると思います。