FAQ: Audits, Architektur und Delivery – konkret beantwortet

Audit Kompakt liefert eine schnelle, priorisierte Diagnose: Hotspots, Risiken, Quick Wins und Empfehlungen, was als Nächstes sinnvoll ist. Audit Plus geht einen Schritt weiter und übersetzt Befunde in eine Roadmap mit Sprint-Zuschnitt: Epics, Tickets, Qualitäts-Gates und klare Entscheidungspunkte. Praktisch bedeutet das: Bei Audit Plus ist die Anschlussfähigkeit in Ihr Backlog Teil des Deliverables, nicht nur ein guter Vorsatz.

Der Fokus liegt auf dem, was sich unabhängig vom Stack bewährt: klare Modulgrenzen, testbare Schnittstellen, stabile CI/CD und sinnvolle Observability. In der Praxis sehen wir häufig TypeScript/Node, Java/Kotlin, Python, .NET sowie gängige Cloud-Setups. Wenn ein exotischer Teil dabei ist, klären wir im Erstgespräch, ob er im Audit „in scope“ sein muss oder ob ein Schnittstellen-Review reicht. Entscheidend ist, wo das Risiko und der Engpass sitzen.

Ja, und das ist oft sinnvoll. Ein Audit muss nicht „alles“ abdecken, um nützlich zu sein. Wir definieren gemeinsam einen engen Scope – zum Beispiel ein kritisches Modul, eine Integrationsschicht, die CI/CD-Pipeline oder einen End-to-End-Flow mit P99-Latenzspitzen. Wichtig ist, dass der Teilbereich klar an ein Ergebnis gebunden ist: weniger Rollbacks, schnellere Builds, stabilere Deployments oder bessere Änderbarkeit in einem Domänenbereich.

Ja. Häufig passt ein Retainer mit festem Rhythmus: zum Beispiel ein bis zwei Tage pro Woche für Pull-Request-Reviews, Architekturentscheidungen, Delivery-Verbesserungen und Enablement-Formate. Wir empfehlen Retainer vor allem dann, wenn viele kleine Maßnahmen parallel laufen und ein Team eine unabhängige zweite Meinung für Entscheidungen braucht. Inhalt und Takt werden so definiert, dass Sie nicht in einer Dauer-Workshop-Schleife landen.

Die Paketpreise sind Festpreise für klar definierte Deliverables; die Abrechnung erfolgt netto in Euro. Inklusive sind die vereinbarten Sessions, die Analysearbeit und die Dokumentation (Befundkatalog, Roadmap, Tickets/Empfehlungen). Nicht inklusive sind dauerhafte Betriebsaufgaben oder die Übernahme von On-Call. Wenn sich im Verlauf zeigt, dass ein Scope nicht passt, stoppen wir und schlagen eine saubere Anpassung vor – bevor sich Aufwand in die falsche Richtung bewegt.

Ja. Wir strukturieren Ergebnisse so, dass sie für Engineering und für nicht-technische Stakeholder verständlich sind: Risiken in Geschäftsauswirkung übersetzt, Maßnahmen als Roadmap mit Entscheidungspunkten, und Messpunkte, die Fortschritt zeigen (z. B. Build-Zeit, Deployment-Frequenz, Change Failure Rate). In der Praxis hilft das, Budget und Kapazität für unglamouröse, aber notwendige Arbeit zu sichern – ohne Drama und ohne Übertreibungen.