Wie ich Tech-DDs mache: Das Scorecard-Framework

Warum ein Framework

Vor meinem ersten Tech-DD habe ich 3 Tage damit verbracht zu entscheiden was ich überhaupt prüfen soll. Jetzt habe ich eine Scorecard mit 12 Dimensionen. Jede Dimension bekommt 1-10 Punkte. Es ist nicht perfekt — aber es ist reproduzierbar.

Die 12 Dimensionen

Code-Qualität (Gewichtung: 15%)

Top 50 Files nach Churn-Rate analysiert. Test-Coverage gemessen (nicht die CI-Zahl — die echte Coverage mit Branch-Coverage auf den kritischen Paths).

Architektur (Gewichtung: 15%)

Ist die Architektur dokumentiert? Gibt es ADRs? Ist die Service-Grenze logisch oder historisch gewachsen?

Skalierbarkeit (Gewichtung: 12%)

Lasttests mit k6. Basis: die Traffic-Annahmen aus dem Pitch-Deck. Wenn das Deck "10x in 2 Jahren" sagt, teste ich das.

Security (Gewichtung: 12%)

Dependency-Scan (Trivy), Secret-Scan (Gitleaks), manuelle Review der Auth-Flows. Häufigster Fund: hardcoded Secrets in Config-Files.

Team (Gewichtung: 10%)

Bus-Faktor, Seniority-Verteilung, Onboarding-Doku. Wichtigster Indikator: kann ein neuer Entwickler in unter 2 Wochen produktiv werden?

CI/CD (Gewichtung: 8%)

Pipeline-Dauer, Deployment-Frequenz, Rollback-Strategie.

Observability (Gewichtung: 6%)

Logging, Metrics, Tracing. Gibt es Alerts die jemanden aufwecken?

Data Management (Gewichtung: 6%)

Backup-Strategie, Recovery getestet, Migration-Workflow.

Dependencies (Gewichtung: 4%)

Outdated Dependencies, transitive Dependencies, bekannte CVEs.

Documentation (Gewichtung: 4%)

README, API-Docs, Runbooks für Incidents.

Tech Debt (Gewichtung: 4%)

TODO/FIXME-Count, bekannte Workarounds, geplante Refactorings.

Infrastructure (Gewichtung: 4%)

Cloud-Kosten, Resource-Utilization, IaC (Terraform/Pulumi).

Das Report-Format

84 Seiten. Warum so lang? Weil VCs Entscheidungen treffen die auf 45M Euro basieren. Die wollen Details, nicht eine Executive Summary.

Aufbau:

Was ich gelernt habe