Qognis Studio · Auditoplevering
Voorbeeld
De gestelde vraag
De checkout herbouwen op de huidige stack, of eerst van platform veranderen?
- Bestemd voor
- Een klant (geanonimiseerd)
- Format
- Audit · € 3.000 vast
- Duur
- 9 werkdagen
- Oordeel
- Nog niet
Dit is een voorbeeld. De structuur, de diepgang en de vorm van het oordeel zijn wat een klant krijgt. De bevindingen zelf zijn verzonnen ter illustratie, want echte audits zijn vertrouwelijk en wij publiceren de problemen van anderen niet — en ook geen verzonnen cases.
01 — Eén vraag, schriftelijk vastgelegd
Een audit beantwoordt één vraag, vastgelegd bij de intake nog vóór het werk begint. Alles wat wij vinden en wat niet helpt om ze te beantwoorden, blijft buiten het rapport. Daardoor blijft een rapport op leeslengte in plaats van zestig pagina’s.
02 — Wat er onderzocht is
Het rapport opent met een lijst van wat wij gelezen en uitgevoerd hebben. In dit voorbeeld: de repository, de productielogs voor het defect bij herhaalde pogingen, drie maanden analytics van de checkout, het aankooptraject van begin tot eind doorlopen, en twee sessies met de ingenieurs die de code beheren. Elke bevinding vermeldt haar bron. Niets berust op een indruk.
03 — Bevindingen, naar impact
Elke bevinding krijgt een ernstgraad, het bewijs dat eronder ligt en wat ze u kost. Ze zijn geordend naar impact, niet naar de plek waar wij ze gevonden hebben.
De staat van de checkout wordt gedupliceerd tussen de winkelwagendienst en de storefrontsessie; na een herhaalde betaalpoging lopen de twee uiteen.
Evidence — Twee keer gereproduceerd in staging. Komt overeen met vier supporttickets uit mei.
Consequence — Dubbele afschrijvingen zijn mogelijk bij een herhaalde poging. Dit defect ligt aan de basis van de tickets die tot de audit hebben geleid.
Rendering en businessregels delen één modulegrens, waardoor elke prijswijziging een volledige regressieronde afdwingt.
Evidence — CI-historiek: drie van de laatste vijf opleveringen vertonen hetzelfde regressiepatroon.
Consequence — De doorlooptijd gaat naar hertesten, niet naar bouwen. De grens opsplitsen verdient zichzelf terug binnen twee opleveringscycli.
Laad- en foutstatussen zijn onderling inconsistent over de zes drukst bezochte views.
Evidence — Opgenomen en geannoteerde doorloop van alle zes de views.
Consequence — De waargenomen kwaliteit blijft achter op de werkelijke betrouwbaarheid. Opportunistisch te verhelpen; rechtvaardigt geen apart project.
04 — Het oordeel
Nog niet. Los eerst het defect bij herhaalde pogingen op: dat is goedkoop, dringend en blijft overeind bij elke beslissing over de stack. Nu van platform veranderen zou het defect meenemen. Kom terug op de vraag zodra het volume van de tweede markt reëel is in plaats van geprojecteerd. Wanneer het eerlijke oordeel een lichter format is, of helemaal geen opdracht, zegt het rapport dat ook — de audit wordt betaald voor het oordeel, niet voor de uitkomst.
05 — Het uitgeschreven pad
Eén pagina, drie acties, elk geprijsd volgens het publieke register: het defect bij herhaalde pogingen oplossen (een Gerichte build), de modulegrens opsplitsen (een Buildsprint), de platformwissel in Q3 opnieuw bekijken met reële volumes. Wij lopen het samen door tijdens de beslissingsvergadering, en het plan wordt de scope van wat de klant daarna kiest.