9.3 Tjeklister

Brugsklare hurtigreference-tjeklister. Kopiér en ind i jeres egen proces og tilpas den; pointen er dækning, ikke den præcise ordlyd.

Tjekliste til gennemgang af ny metrik (før en metrik tilføjes til et dashboard)

Metrikken har en navngiven beslutning, den informerer (emne 1.1)
Metrikken er klassificeret som diagnostisk eller evaluerende, skriftligt (emne 1.1)
Hvis den er incitamentsudsat, er der defineret et værn samtidig (emne 1.2)
Manipulationsvektoren er navngivet: hvordan ville et rationelt team få dette tal til at se godt ud uden at forbedre det reelle resultat (emne 1.2)
Metrikken er klassificeret som input, output eller resultat (emne 1.3)
Metrikken har en navngiven ejer og et dokumenteret kildesystem og en dokumenteret indsamlingsmetode (emne 1.4, 1.5)
Metrikken bruger en median eller percentil, ikke et gennemsnit, hvis de underliggende data er skæve (emne 1.6)
Metrikken bruges aldrig til individuel vurdering, eller også er denne brug separat og eksplicit oplyst (emne 1.1)

Dashboardet har én navngiven, specifik målgruppe og beslutning (emne 8.1)
Hver incitamentsudsat metrik vises i den samme visning som sit værn (emne 1.2, 8.1)
Akserne starter ved nul, medmindre en angivet, synlig undtagelse er dokumenteret (emne 1.6)
Tendens over tid vises, ikke et enkelt øjebliksbillede (emne 1.6)
Dashboardet har en navngiven ejer og en gennemgangsrytme (emne 1.4)
En synlig erklæring angiver, hvad dashboardet ikke er til, hvis det er relevant (emne 1.1)
Datakilder har grundlæggende sundhedstjek, så en ødelagt pipeline ikke stille fremstår som aktuel (emne 1.5)

Formål og eksplicitte ikke-mål kommunikeres før lancering, ikke reaktivt (emne 8.3)
De mennesker, der måles, var inddraget i valget af metrikker (emne 8.3)
Programmet starter i rent diagnostisk tilstand, med en forpligtet minimal bevisperiode (emne 8.3)
Der findes en hurtig, synlig reaktionsprotokol for enhver fremtidig hændelse med misbrug (emne 8.3)
Der er valgt et pilotteam, som reelt meldte sig frivilligt, ikke et pålagt (emne 8.5)
Det grundlæggende styringsarbejde (charter, ejerskab, diagnostisk politik) er på plads, før instrumenteringen begynder (emne 1.4, 8.5)

Postmortem undersøger systemet, ikke enkeltpersonen (emne 6.2)
Alvorlighed blev klassificeret efter dokumenterede, standardiserede kriterier (emne 6.2)
Tider for opdagelse, bekræftelse og løsning registreres hver for sig (emne 6.2)
Handlingspunkter er specifikke, tildelt og følges til afslutning (emne 6.2)
Postmortem deles uden frygt for individuelle konsekvenser (emne 6.2, 8.3)

Hver dashboardmetrik er testet mod: “ville et team, der bruger kraftig AI-assistance, men ikke producerer mere reel værdi, vise en forbedret aflæsning her” (emne 7.1)
Ændringsfejlrate og fejlrate gennemgås ved siden af enhver stigning i AI-assisteret udrulningsfrekvens eller commit-volumen (emne 7.1)
Gennemgangskapacitet og -dybde overvåges, efterhånden som mængden af AI-genereret kode ændrer sig (emne 7.1)
Undslupne fejl mærkes efter niveau af AI-assistance for at afprøve, ikke antage, om den historiske sammenhæng mellem fejlrater stadig holder (emne 7.1, 7.3)
Opdagelsesmetoder, der modstår “ser korrekt ud”-fejl (mutationstest, egenskabsbaseret testning), er på plads for AI-tunge kodestier (emne 7.3)
Metrikchartret er eksplicit genbesøgt og opdateret for dette skifte, ikke ladt til at drive ugransket (emne 1.4, 7.1)

Hver metrik har stadig en navngiven ejer (emne 1.4)
Mindst én metrik er udfaset i den seneste cyklus, hvis den holdt op med at fortjene sin plads (emne 1.1)
Vurderingen af modenhed på fem dimensioner er gennemført ærligt, scoret efter minimum, ikke gennemsnit (emne 8.4)
Ingen metrik er gledet fra diagnostisk til evaluerende brug uden en eksplicit, oplyst beslutning (emne 1.1)
Definitioner er stikprøvekontrolleret mod den faktiske instrumentering for afdrift (emne 1.2, 2.4, 5.1, 6.2, 6.4)
Forholdet mellem resultat og output på de primære dashboards er beregnet og gennemgået (emne 7.4)