Eksperimenthastighet

Eksperimenthastighet er hastigheten en organisasjon fullfører gyldige eksperimenter med, vanligvis uttrykt som tester avsluttet per måned eller per kvartal. Det er en av de sterkeste prediktorene for hvor mye verdi et testprogram genererer, av en enkel grunn: hvis bare et mindretall av eksperimentene produserer en meningsfull forbedring, er antallet forbedringer som finnes i stor grad en funksjon av hvor mange eksperimenter som kjøres. En dobling av læringshastigheten, alt annet likt, dobler omtrent den sammensatte effekten på de beregningene som er viktige.

Hastighet er begrenset av tre separate begrensninger, og det å identifisere hvilken som binder er det første trinnet i å forbedre den. Trafikk setter et hardt statistisk tak: et nettsted kan ikke kjøre flere samtidige, tilstrekkelig kraftige tester enn volumet støtter. Produksjonskapasiteten dekker idégenerering, design, bygging og kvalitetssikring, og er vanligvis den bindende begrensningen i organisasjoner der hver test krever ingeniørarbeid. Prosessen dekker godkjenningssykluser, interessentgjennomgang, juridisk eller merkevaregodkjenning og analysebehandlingstid, og er ofte den største skjulte kostnaden, med tester som står inaktive i køer lenger enn de bruker på å samle inn data.

Å øke hastigheten ved å senke standarder er selvdestruktivt og dessverre vanlig. Å forkorte kjøretider til under en full konjunktursyklus, hoppe over beregning av utvalgsstørrelse, forlate kvalitetssikring, teste det som er enkelt i stedet for det som er viktig, og stoppe tester ved første tegn på betydning øker antallet fullførte eksperimenter samtidig som det reduserer antallet reelle funn. Et program som rapporterer førti tester i kvartalet med upålitelig metodikk produserer mindre verdi enn et som rapporterer tolv tester utført riktig, og det skaper mer organisatorisk forvirring fordi resultatene motsier hverandre.

De produktive virkemidlene handler hovedsakelig om å fjerne ventetid i stedet for å komprimere selve testene. Opprettholde en prioritert etterslep av byggeklare ideer, slik at kapasiteten aldri er inaktiv. Etablere et gjenbrukbart komponentbibliotek og testmaler, slik at byggetiden reduseres. Avtale stående godkjenning for en definert klasse av lavrisikoeksperimenter, slik at hver enkelt ikke krever en ny godkjenning. Kjøre ikke-overlappende tester samtidig på forskjellige områder av nettstedet. Automatisere analyse og rapportering, slik at resultatene er tilgjengelige den dagen testen avsluttes, i stedet for to uker senere. Ingen av disse går på bekostning av nøyaktighet; alle reduserer kalendertiden mellom ett eksperiment og det neste.

Hastighet bør også leses sammen med kvalitetsmål snarere enn isolert. Nyttige følgesvenner inkluderer andelen tester som når en gyldig konklusjon i stedet for å bli forlatt, andelen som produserer dokumentert læring uavhengig av utfall, andelen eksperimenter som adresserer sider eller flyter med høy verdi, og den målte kumulative effekten av programmet via en holdout. Et dashbord som bare viser hastighet vil, forutsigbart, bli optimalisert ved å kjøre mer trivielle tester.

Samtidighet fortjener spesiell oppmerksomhet, fordi det er den spaken som oftest brukes uforsiktig. Å kjøre flere eksperimenter samtidig multipliserer gjennomstrømningen når testene påvirker urelaterte deler av opplevelsen, og skaper utolkelige resultater når de overlapper hverandre. De praktiske reglene er å kartlegge hver test til trakttrinnene og målgruppene den berører, å unngå å kjøre to tester som endrer samme trinn samtidig, og å sjekke for interaksjonseffekter når tester er tilstøtende i stedet for å anta uavhengighet. Noen organisasjoner løser dette ved å opprettholde en delt kalender med aktive eksperimenter med de berørte områdene registrert, noe som er lite glamorøst, men forhindrer den vanlige situasjonen der to team ubevisst tester motstridende endringer på samme side og begge rapporterer ufullstendige resultater uten å forstå hvorfor.

For de fleste organisasjoner er den raskeste veien til høyere hastighet ikke et nytt verktøy, men en tydeligere driftsmodell: hvem genererer ideer, hvem prioriterer, hvem bygger, hvem godkjenner, og hvor lang tid hvert trinn får ta. Å etablere denne modellen er en normal del av en vekststyring engasjement, og den resulterende kadensen avhenger vanligvis av å ha nok forberedte, veldokumenterte hypoteser til å holde pipelinen full, som er der kontinuerlig brukerforskning fortjener sin plass som et innspill til testveikartet snarere enn et sporadisk separat prosjekt.