Technisches Audit
Wir prüfen Architektur, Codequalität, Sicherheit, Infrastruktur, Deployment und Dokumentation. Der schriftliche Bericht ordnet die Risiken nach geschäftlicher Auswirkung, damit Sie wissen, was zuerst behoben werden muss.
Software-Sanierung & Projektübernahme
Software-Sanierung für Produkte, die sich kaum noch ändern lassen
Der bisherige Dienstleister ist weg, Releases verzögern sich ständig, oder jede kleine Änderung macht etwas anderes kaputt. Wir prüfen den Code, beheben, was Ihre Kunden gefährdet, und planen die Modernisierung in Phasen, die Sie budgetieren können.
- Technisches Audit vor jeder Entscheidung über eine Neuentwicklung
- Zuerst kritische Korrekturen, dann Modernisierung in Phasen
- Dasselbe Team kann für die Roadmap bleiben
- 01 Technische Bewertung
- 02 Kritische Risiken
- 03 Stabilisierung
- 04 Modernisierungs-Roadmap
- 05 Weiterentwicklung des Produkts
Die meisten Übernahmen scheitern im ersten Monat
Ein neues Team übernimmt den Code, liest ein paar Dateien und liefert die ersten Korrekturen aus. Einige Wochen später läuft ein geplanter Job nicht mehr oder eine Kundenintegration fällt aus, weil niemand wusste, dass es sie gibt.
Wir gehen in umgekehrter Reihenfolge vor. Zuerst erfassen wir, was das Produkt im Produktivbetrieb tut: Services, Daten, Hintergrundjobs und die Integrationen, auf die Ihre Kunden angewiesen sind. Dann beheben wir die Fehler, die Sie Geld oder Vertrauen kosten. Eine größere Modernisierung folgt danach, in Teilen, die Sie einzeln freigeben.
Was eine Software-Sanierung umfasst
Die Bausteine laufen meist in dieser Reihenfolge ab, und jeder ist auch für sich allein nützlich.
Stabilisierung
Abstürze, Datenprobleme und defekte Integrationen werden zuerst behoben. Dann ergänzen wir Monitoring und einen sicheren Release-Prozess, damit dieselben Fehler nicht wiederkehren.
Modernisierung
Wir ersetzen veraltete Frameworks, entflechten Module, die niemand gefahrlos ändern kann, und überführen die Infrastruktur in eine Umgebung, die Sie betreiben und planbar bezahlen können. Das Produkt bleibt die ganze Zeit live.
Langfristige Verantwortung
Sobald das Produkt stabil ist, können dieselben Entwickler die Roadmap übernehmen. Sie behalten das im Audit aufgebaute Wissen, statt ein neues Team für die erneute Einarbeitung zu bezahlen.
So läuft eine Sanierung ab, Phase für Phase
Jede Phase endet mit einem Ergebnis, das Sie prüfen können, bevor Sie die nächste freigeben.
- 01
Zugang und Bestandsaufnahme
Lesezugriff auf Code, Hosting und Tickets, dazu Gespräche mit den Personen, die das Produkt nutzen und betreuen.
Ergebnis Eine Karte des Systems und seiner Abhängigkeiten
- 02
Technisches Audit
Architektur, Sicherheit, Performance, Tests und Deployment, geprüft daran, wie das Produkt heute genutzt wird.
Ergebnis Ein Risikobericht, geordnet nach geschäftlicher Auswirkung
- 03
Stabilisierung
Kritische Fehler, Sicherheitslücken und fragile Releases werden zuerst behoben. Monitoring wird ergänzt, wo es fehlte.
Ergebnis Releases ohne Überraschungen
- 04
Modernisierungs-Roadmap
Behalten, refaktorieren oder ersetzen, entschieden Modul für Modul, mit einer Aufwandsschätzung für jedes.
Ergebnis Ein Plan in Phasen, den Sie budgetieren können
- 05
Laufende Entwicklung
Neue Features auf einer Codebasis, die sie tragen kann, entwickelt von einem Team, das sie bereits kennt.
Ergebnis Ein planbarer Release-Rhythmus
Sanierung in Phasen oder kompletter Rewrite?
Manchmal ist ein Rewrite die richtige Entscheidung. Häufiger ist er der teuerste Weg, wiederzuentdecken, was das alte System eigentlich getan hat.
| Frage | Kompletter Rewrite | Sanierung in Phasen |
|---|---|---|
| Wann Kunden einen Nutzen sehen | Wenn das neue System den vollen Funktionsumfang erreicht hat | Ab dem ersten Stabilisierungs-Release |
| Risiko für aktive Kunden | Hoch während der Umstellung | Auf jeweils ein Modul begrenzt |
| Sonderfälle | Gehen oft verloren und werden im Produktivbetrieb wiederentdeckt | Bleiben erhalten, weil das aktuelle Verhalten zuerst erfasst wird |
| Budget | Große Vorabverpflichtung | Phase für Phase freigegeben |
| Wann es sinnvoll ist | Die zugrunde liegende Plattform hat ihr Lebensende erreicht | Das Produkt funktioniert, lässt sich aber nur schwer und teuer ändern |
Häufige Fragen
Können Sie ein Produkt übernehmen, das ein anderes Team gebaut hat?
Ja, so beginnen diese Projekte am häufigsten. Wir starten mit Lesezugriff und einem technischen Audit von Architektur, Code, Infrastruktur, Dokumentation und Lieferprozess, bevor wir etwas ändern.
Was, wenn der bisherige Dienstleister das Projekt unfertig hinterlassen hat?
Wir klären, was sicher bleiben kann, was den Launch blockiert und welche Abfolge von Arbeiten das Produkt am schnellsten zu den Kunden bringt.
Müssen wir das Produkt neu schreiben?
In der Regel nicht. Das Audit zeigt, welche Teile bleiben können, welche Refactoring brauchen und welche ersetzt werden müssen. Die meisten Produkte werden Modul für Modul modernisiert, während sie live bleiben.
Können wir nur mit einem technischen Audit beginnen?
Ja. Bei übernommener oder instabiler Software ist das Audit meist der richtige erste Schritt. Sie erhalten eine nach Priorität geordnete Risikoliste und einen Plan, egal wer die Arbeit am Ende umsetzt.
Was brauchen Sie von uns für den Start?
Lesezugriff auf Repositories und Hosting, die vorhandene Dokumentation und Zeit mit den Personen, die wissen, wo es im Produkt hakt.
Join.To.IT hat die Qualität der Website deutlich verbessert und viele Probleme der vorherigen Version gelöst, die ein anderer Dienstleister gebaut hatte. Das Team reagiert sehr schnell und nutzt Projektmanagement-Tools wie Trello, Bitbucket, Slack und Skype proaktiv. Außerdem halten wir tägliche Stand-up-Meetings ab, sodass nichts untergeht.