Qognis Studio · Audit-Liefergegenstand
Beispiel
Die gestellte Frage
Den Checkout auf dem aktuellen Stack neu bauen oder zuerst die Plattform wechseln?
- Erstellt für
- Ein Kunde (anonymisiert)
- Format
- Audit · 3.000 € pauschal
- Dauer
- 9 Arbeitstage
- Urteil
- Noch nicht
Dies ist ein Beispiel. Struktur, Tiefe und Aufbau des Urteils entsprechen dem, was ein Kunde erhält. Die Befunde selbst sind zur Illustration erfunden, denn echte Audits sind vertraulich, und wir veröffentlichen weder die Probleme anderer noch erfundene Fallstudien.
01 — Eine Frage, schriftlich vereinbart
Ein Audit beantwortet eine Frage, die beim Auftakt vor jeder Arbeit festgelegt wird. Alles, was wir finden und was nicht zur Antwort beiträgt, bleibt aus dem Bericht. Das hält einen Bericht auf Leselänge statt auf sechzig Seiten.
02 — Was untersucht wurde
Der Bericht beginnt mit einer Liste dessen, was wir gelesen und ausgeführt haben. In diesem Beispiel: das Repository, Produktions-Logs zum Retry-Defekt, drei Monate Checkout-Analytics, der Kaufweg von Anfang bis Ende durchlaufen und zwei Sitzungen mit den Ingenieuren, denen der Code gehört. Jeder Befund nennt seine Quelle. Nichts beruht auf einem Eindruck.
03 — Befunde, nach Konsequenz
Jeder Befund trägt einen Schweregrad, die Belege dahinter und das, was er Sie kostet. Sie sind nach Konsequenz geordnet, nicht danach, wo wir sie gefunden haben.
Der Checkout-Status wird zwischen dem Warenkorb-Service und der Storefront-Session doppelt geführt; nach einem Zahlungs-Retry weichen beide voneinander ab.
Evidence — Zweimal in der Staging-Umgebung reproduziert. Deckt sich mit vier Support-Tickets aus Mai.
Consequence — Bei einem Retry sind Doppelbelastungen möglich. Dieser Defekt steht hinter den Tickets, die das Audit ausgelöst haben.
Rendering und Geschäftsregeln teilen sich eine Modulgrenze, sodass jede Preisänderung einen vollständigen Regressionsdurchlauf erzwingt.
Evidence — CI-Historie: Drei der letzten fünf Releases zeigen dasselbe Regressionsmuster.
Consequence — Die Durchlaufzeit fließt ins Nachtesten, nicht ins Bauen. Die Grenze zu trennen, rechnet sich innerhalb von zwei Release-Zyklen.
Lade- und Fehlerzustände sind über die sechs meistbesuchten Ansichten hinweg uneinheitlich.
Evidence — Aufgezeichneter, kommentierter Durchgang durch alle sechs Ansichten.
Consequence — Die wahrgenommene Qualität liegt hinter der tatsächlichen Zuverlässigkeit. Nebenbei beheben; rechtfertigt kein eigenes Projekt.
04 — Das Urteil
Noch nicht. Beheben Sie zuerst den Retry-Defekt: Er ist günstig, dringend und überlebt jede Stack-Entscheidung. Ein Plattformwechsel jetzt würde den Defekt mitnehmen. Kommen Sie auf die Frage zurück, sobald das Volumen des zweiten Marktes real und nicht nur prognostiziert ist. Wenn das ehrliche Urteil ein kleineres Format oder gar kein Auftrag ist, sagt der Bericht auch das — das Audit wird für das Urteil bezahlt, nicht für das Ergebnis.
05 — Der schriftliche Weg
Eine Seite, drei Schritte, jeder anhand des öffentlichen Leistungsverzeichnisses bepreist: den Retry-Defekt beheben (ein Gezielter Build), die Modulgrenze auftrennen (ein Build-Sprint), den Plattformwechsel im Q3 mit echten Volumina erneut prüfen. Wir gehen das gemeinsam in der Entscheidungsbesprechung durch, und der Plan wird zum Scope dessen, was der Kunde als Nächstes wählt.