Implementieren von großen Systemänderungen

Question

Wenn Sie mit dem Ausdruck "bauen einen Weg zum Wegwerfen" vertraut sind, nun, wir scheinen das getan zu haben; Wir erreichen die Grenzen der Version 1 unserer Online-App. Es ist Zeit, die Dinge zu bereinigen von:

• Re-Organisation von Code und UI
• Unifying UI verarbeitet
• mehr Funktionalität
• Bauen für die Zukunft
• ändern unsere Datenbankstruktur alle zu handhaben Hinzufügen die obigen

Was ist der beste Weg, um diesen Übergang passieren?

Wir wollen vermeiden, dass alle unsere Benutzer auf ein neues System (sobald es fertig ist) geworfen werden ... sie würden ausflippen und wir könnten die Anruflast nicht verarbeiten. Unsere Benutzer führen die Skala von technisch kompetenten Use-to-Write-Software-Typen zu denen, die nicht wissen, was HTML ist.

Sollten wir eine neue "Installation" unseres Systems starten und die Benutzer schrittweise darauf umstellen, nachdem wir sichergestellt haben, dass dieses neue Design die Probleme der Version 1 ausreichend löst?

Sollten wir (irgendwie) jedes Modul unseres Systems schrittweise und Phase ändern? Dies kann schwierig sein, da sich das Layout der Datenbank ändert, was dazu führt, dass der "Hauptcode" und der Code für mehrere umgebende Module angepasst werden müssen.

Ist es üblich, eine Reihe von vertrauenswürdigen, Patienten, "Beta-Tester" -Kunden mit einer hochmodernen Version einer App? (Das Ziel hier wäre, Feedback zu erhalten und auf Fehler in einem neuen System zu testen)

Irgendwelche anderen Ratschläge? Erfahrungen aus erster Hand?

Answer 1

Die Antwort, fürchte ich, hängt davon ab. Es hängt von der Art der Anwendung und der Art der Benutzer ab, die Sie haben. Ohne zu wissen, was das System ist und den Umfang der Änderungen in der Version, ist es schwierig, eine Antwort anzubieten.

Das gesagt, es gibt einige Faustregeln.

Erstens, vermeiden Sie den Big Bang Start. Jeder Start eines Systems wird Probleme haben. Die Industrie ist übersät mit Projekten, in denen die Leute den Start des Bang-Bang für eine großartige Idee hielten, nur für Kinderkrankheiten, um den Start in die Knie zu zwingen. Cuil war eine kürzliche hochkarätige Kausalität der Big-Bang-Start.

Um die Kinderkrankheiten beherrschbar zu machen, müssen Sie zunächst mit einer kleinen Anzahl von Benutzern arbeiten und dann langsam die Anzahl der Benutzer erhöhen.

Zweitens, die Sache, die Sie unbedingt tun müssen, ist setzen Sie den Benutzer zuerst. Der Benutzer sollte die geringstmögliche Arbeit leisten müssen, um V2 des Systems zu verwenden. Die ideale Menge an Arbeit wäre Null.

Das bedeutet, dass, wenn Sie langsam holen, um Benutzer auf die anderen von einem System zu migrieren, Sie für die Herstellung verantwortlich sind sicher, dass alle Daten und Einstellungen migriert werden. Machen Sie zum Beispiel nichts Dummes, indem Sie dem Benutzer sagen, dass er V1 für alle Datensätze vor dem 12.09.2008 und V2 für alle Datensätze danach verwenden muss.

Der Zeitpunkt der Veröffentlichung von V2 sollte das Leben der Benutzer erleichtern und es nicht unnötig schwieriger machen.

Drittens, haben Sie ein Beta-Programm. Dies gilt auch für Intranet-Anwendungen. Die Entwicklung einer Anwendung ähnelt der Methode von Newton-Raphson, um die Wurzel eines Polynoms zu finden. Sie machen eine Vermutung, was der Benutzer wünscht, Sie liefern ihn an den Benutzer, der Benutzer gibt Feedback und langsam, aber sicher bringt Sie jede Iteration näher zur Lösung des Problems.

Ein Beta-Programm hilft Ihnen, die Wurzel viel schneller zu finden, als nur neue Versionen an Leute zu senden, ohne dass sie Zeit haben, die Änderungen zu kommentieren. Betas helfen, Ihre Benutzer früher an Bord zu bringen und sie in das Verfahren einbezogen zu fühlen. Die Wichtigkeit, von der ich nicht genug betonen kann.

Answer 2

Wir haben gerade ein brandneues CRM-System auf unsere Benutzer eingestellt und lassen Sie mich Ihnen sagen, dass es eine SCHRECKLICHE Idee war, es so zu machen: Es war extrem schmerzhaft für mein Team und für unsere Kunden.

Ich würde alle möglichen Mittel durchgehen, um schrittweise Freigaben zu machen, auch wenn es bedeutet, mehr Arbeit zu erledigen. Sie werden dankbar sein, weil Sie keine heldenhaften Anstrengungen unternehmen müssen, um alles in Bewegung zu setzen, und Ihre Kunden werden die Fähigkeit schätzen, sich ein wenig in das Produkt einführen zu lassen.

Hoffe, dass hilft!

Answer 3

Es klingt wie inkrementelle Re-Architektur sollte Ihre agile Buzz-Phrase der Wahl sein.

Ich habe es noch nie in einer Webanwendung gemacht, aber ich habe einige ziemlich radikale Clientanwendungsänderungen durchgemacht, die inkrementell durchgeführt wurden. Wenn Sie ein wenig Zeit investieren, um sicherzustellen, dass die Arbeitsteile auf eine vernünftige Art und Weise sequenziert werden, kann es gut funktionieren. Eine kleine Investition in gute Refactoring-Hilfsmittel wird sehr hilfreich sein, wenn Sie sie nicht bereits haben. Ich kann persönlich jetBrains Resharper empfehlen, wenn Sie .NET verwenden, und wenn Sie Java-basiert sind, glaube ich, dass IntelliJ IDEA ähnliche Funktionen enthält.

Answer 4

Ich stimme mit Esteban überein, dass graduelle Veröffentlichungen am besten sind. Es ist, als würde man ein Haus umbauen: Es ist zunächst eine gute Idee, es hinter sich zu bringen. Aber bedeutet, dass Sie alles im Voraus planen müssen, eine Reihe von Auftragnehmern einstellen und ausziehen müssen. Dann ändert sich etwas im Plan oder ein Bauunternehmer verschwindet, und die ganze Zeit, die Sie sparen wollten, ist weg. Zwischenzeitliche Veränderungen geben jedem die Chance, innezuhalten und zwischen den einzelnen Schritten zu denken. Manchmal können Sie spätere Änderungen vermeiden, wenn frühere Änderungen besser als geplant verlaufen.

Ich arbeite an einem System, das ein großes Skalierungsproblem hatte. Wir haben eine Liste aller Änderungen erstellt, die wir für notwendig hielten, und sie nach möglichen Auswirkungen priorisiert. Dann fingen wir an, eine Änderung nach der anderen vorzunehmen. Nach ungefähr der Hälfte der Liste hatten wir das Skalierungsproblem gelöst. Ich habe immer noch die Liste, aber ich muss sie vielleicht nie beenden. Ich bin frei, Funktionen hinzuzufügen und andere Probleme zu lösen.

Natürlich gibt es Zeiten, in denen es am besten ist, die Kugel zu zerbeißen und das Ganze zu zerreißen. Aber das ist viel weniger üblich als Menschen glauben. Und bei kritischen Betriebssystemen kann die "Zerreiß" -Entscheidung fatal sein. Schauen Sie sich die großen Regierungsprojekte an, von denen alle zustimmen, dass sie in die Ära der modernen Computertechnik gebracht werden müssen, aber das kann nicht, weil einige wichtige Dienste verloren gehen. Wenn sich die Philosophie allmählich geändert hätte, wären sie vielleicht Stück für Stück modernisiert worden.