Der Dienstleister ist gescheitert, und du hast dich blamiert.
Das System ist im schlimmsten Moment stehen geblieben. Seine Erbauer sagten, es sei nicht vorhersehbar gewesen.
Das Legacy-System, das niemand anfassen will.
Das Produkt ist in Produktion und bedient Kunden. Es hat Probleme, die niemand lösen kann, und jeder Eingriff riskiert neue.
Woher sie kommen
Meistens eine von diesen drei.
Die Person, die es geschrieben hat, ist weg.
Eine einzige Person wusste, wie es funktioniert. Der Code ist geblieben, aber niemand kann ihn lesen.
Du hast beim großen Anbieter unterschrieben, und das Projekt kommt nicht voran.
Viele Menschen, viele Meetings, wenige Zeilen Code. Jede Änderung muss über den Anbieter laufen, weil sonst niemand daran arbeiten kann.
In allen drei Fällen ist nicht das Problem, dass die Software nicht funktioniert. Sie funktioniert, bis man sie anfasst.
Mit KI gebaut
Es funktioniert. Aber du weißt nicht, was drinsteckt.
Immer öfter entsteht ein Produkt so: eine Idee, ein paar Wochen mit KI, und etwas, das wirklich funktioniert. Um eine Hypothese zu testen, ist das der richtige Weg. Das Problem kommt später, wenn aus diesem Prototyp das Produkt wird, auf dem das Unternehmen steht.
Die KI tut, worum du sie bittest. Worum du sie nicht bittest, entscheidet sie selbst. Sie hat vielleicht angenommen, es sei ein kleines Projekt, und die Sicherheit offen gelassen, ohne es dir zu sagen. Die Software ist vielleicht gut gemacht. Aber ihre Schwachstellen kennst du nicht, und deshalb kannst du nicht entscheiden, ob du sie akzeptierst oder behebst. Meistens entdeckst du sie, wenn etwas kaputtgeht.
Für uns ist es dieselbe Situation wie bei Code, den man von einem anderen Dienstleister übernimmt, und wir gehen sie genauso an: Wir analysieren das Produkt, entscheiden gemeinsam, was bleibt und was neu gebaut wird, und isolieren den kritischen Teil, den, auf dem das Geschäft steht. Was du wissen musst, ist, wo das Produkt nachgeben kann. Ein Review Zeile für Zeile, über Tausende von Zeilen, sagt dir das nicht.
Wer es schon gemacht hat
Estremamente flessibili, hanno dimostrato enorme capacità nella gestione di un codice sorgente non scritto da loro (sono subentrati dopo due anni dalla nostra nascita), arrivando a padroneggiarlo completamente dopo pochissime settimane.
Was wir tun
Zuerst stoppen wir den Schaden. Dann entscheiden wir über Rettung oder Neubau.
Wir schreiben nicht aus Prinzip neu. Ein Produkt, das bereits Kunden bedient, hat Wert: Wir betrachten die Kosten des Behaltens, des Neubaus und was ohne Abschalten möglich ist.
Es gibt drei Wege, und die Wahl hängt von Zahlen ab, nicht von technischem Geschmack. Manchmal ist Neubau richtig, manchmal laufen Alt und Neu nebeneinander, manchmal retten wir Stück für Stück.
Belastung
Ein Prototyp in Produktion gezwungen. Entstanden, um die Idee zu beweisen, dann ohne Neubau vor echte Nutzer gestellt.
Infrastruktur
Cloud, die nicht skaliert. Server fester Größe, die nur die Last von gestern tragen.
Prozesse
Schwere, unzuverlässige Verarbeitung. Langsamkeit, Ausfälle und Daten, die gelegentlich verschwinden.
Zeit
Angehäufte Obsoleszenz und Schulden. Technologien auf Versionen ohne Updates, bei denen jede Änderung drei weitere braucht.
Menschen
Der einzige Techniker ist gegangen. Keine Dokumentation, keine Übergabe. Der Code existiert, das Wissen nicht.
Vorher
Nachher
- Belastung
- Infrastruktur
- Prozesse
- Zeit
- Menschen
- Derselbe Punkt, gelöst
Die eigentliche Frage
„Das haben mir die anderen auch versprochen.“
Wenn du hier bist, wurdest du wahrscheinlich schon einmal enttäuscht. Die Frage ist nicht, ob wir gut sind, sondern warum es diesmal anders sein sollte.
Eine Antwort in Worten gibt es nicht, denn Worte hast du schon gehört. Wir können dir zeigen, wo unser Prozess seine Sicherungen setzt.
Zuerst
Du entscheidest, wofür Kapazität eingesetzt wird
Jede Aktivität wird beschrieben und geschätzt und bleibt stehen, bis du sie freigibst.
Jeden Tag
Sieh die Pipeline in Bewegung
Du siehst Status, Zwei-Wochen-Zyklus und ob Arbeit vor oder hinter dem Plan liegt.
Währenddessen
Niemand veröffentlicht den eigenen Code
Jede Änderung wird von einem zweiten Techniker geprüft und getestet.
Vor dem Release
Eine Umgebung zum Testen
Die Arbeit kommt vor der Produktion in eine für dich zugängliche Umgebung.
Immer
Code und Server bleiben deine
Kein Lock-in. Du kannst alles mitnehmen — deshalb bleiben Kunden aus freien Stücken.
Die Rechnung
Drei Köpfe kosten weniger als zehn Hände.
- Wie sie arbeitet
Die große Struktur
Viele Menschen, meist am Anfang ihrer Erfahrung: Das Projekt kommt durch Versuche voran
Das kleine Team
Verantwortungsvolle Fachleute: Wer am System arbeitet, verantwortet seine Funktion
- Was es kostet
Die große Struktur
Hunderte Tage zum vollen Satz
Das kleine Team
Ein Bruchteil der Tage. Dort gewinnt man die Rechnung — nicht beim Satz
- Was bleibt
Die große Struktur
Ein funktionierendes Produkt mit technischen Schulden
Das kleine Team
Sauberer, portabler Code. Deiner.
| Die große Struktur | Das kleine Team | |
|---|---|---|
| Wie sie arbeitet | Viele Menschen, meist am Anfang ihrer Erfahrung: Das Projekt kommt durch Versuche voran | Verantwortungsvolle Fachleute: Wer am System arbeitet, verantwortet seine Funktion |
| Was es kostet | Hunderte Tage zum vollen Satz | Ein Bruchteil der Tage. Dort gewinnt man die Rechnung — nicht beim Satz |
| Was bleibt | Ein funktionierendes Produkt mit technischen Schulden | Sauberer, portabler Code. Deiner. |
Die Elite kostet weniger, als du denkst. Und ist früher da.
Wie man beginnt
Modernization Audit
Bevor du dich bindest: wissen, was du hast.
Wir analysieren den Zustand des Produkts, identifizieren Ursachen und liefern einen Plan: was gerettet, was neu geschrieben wird, in welcher Reihenfolge und mit welchem Zeitplan. Dann entscheidest du, ob es weitergeht — auch mit jemand anderem.
Wenn du schon weißt, was zu tun ist und nur sehen willst, wie wir arbeiten, gibt es einen kürzeren Weg: den Dry Run.