COCO slår til igjen

Vi bør nok slutte å gi COCO ideer.
Det forrige eksperimentet skulle være nok.
En ekte applikasjon.
Ekte navigasjon.
Brukere.
Roller.
Databaser.
Språk.
Bevis.

En respektabel casestudie.
En ren konklusjon.
Så viste noen det: Logistics in Motion.
Det var nok feilen.

Det begynte med tre lagre
Ingenting spesielt spennende.
Tre DEMO-lagre.

• Kalsdorf bei Graz.
• Wiener Neustadt.
• Klagenfurt.

Syntetisk data.
Ingen kundeinformasjon.
Ingen produksjonsbeholdning.

Nettopp den typen miljø der ingenting viktig skal skje.
Så ble det første lageret valgt.
Og applikasjonen fikk kontekst.
Fra det øyeblikket hadde hver skjerm et spørsmål til knyttet til seg.

Tilhører dette fortsatt det samme lageret?
Endrer språket bare grensesnittet?
Forblir prosessen på samme steg?
Stemmer beholdningen fortsatt?
Peker dokumentreferansen fortsatt på riktig hendelse?
Ser operatøren nøyaktig det som trengs for neste handling?

Plutselig var den interessante delen ikke lenger skjermen.
Det var kontinuiteten mellom skjermene.

COCO har en tendens til å gjøre det.

Logistikk er ikke en samling skjermer
Utenfra kan lagerprogramvare se villedende enkelt ut.
Varer ankommer.
De lagres.
Noen bestiller dem.
De plukkes.
De sendes.
Ferdig.
Bortsett fra at det finnes en hel operativ verden gjemt mellom ankommet og sendt.
Forventet.
Mottatt.
Kontrollert.
Tilgjengelig.
Reservert.
Flyttet.
Plukket.
Blokkert.
Korrigert.
Sendt.
Revidert.

Den fysiske bevegelsen betyr noe.
Men det er tilstandsovergangen som gjør den bevegelsen forståelig for programvaren.
Og når de to virkelighetene slutter å stemme overens, får noen til slutt en dårlig dag.



Et lager er lettere å forstå når bevegelse er synlig, ikke bare registrert.
Det er derfor vårt logistikkarbeid aldri egentlig har startet med menyer, dashbord, eller teknologi.
Det starter med den materielle Flow.

Hvor kommer informasjon inn?
Hvor endres den?
Hvor kan den gå tapt?

Hvor blir noen tvunget til å spørre en annen person om hva som skjedde?
Hvor blir et manuelt steg stille den svakeste delen av en ellers automatisert prosess?
Noen ganger er svaret et nytt grensesnitt.
Noen ganger en integrasjon.
Noen ganger en skanner.
Noen ganger rett og slett en bedre tilstandsmodell.

Mer programvare er ikke automatisk bedre programvare.
Målet er ikke automatisering for sin egen skyld.
Målet er en prosess som forblir forståelig.

Control. Clarity. Flow.

Prosessen begynner før den første bookingen.
Før varemottak.
Før plukking.
Før lagerbevegelse.
Før den første transaksjonen.
Flow stiller et veldig grunnleggende spørsmål:
Hvilket lager jobber vi i?
Det høres nesten trivielt ut.
Det er det ikke.
Lagerkontekst hører til alt som følger.
Beholdning.
Dokumenter.
Lokasjoner.
Plukking.
Omplasseringer.
Revisjonshistorikk.
Unntak.

Prosessen kan se helt sunn ut mens den opererer i feil kontekst.
Det er nøyaktig den typen problem et skjermbilde sjelden avslører.
Og nøyaktig den typen grense COCO liker å stille spørsmål ved.

Språk er enkelt til det ikke er det
Tysk.
Engelsk.
Kroatisk.
Norsk.
Og andre.

En brukerprofil definerer de tilgjengelige språkene.
Operatøren bytter språk mens applikasjonen kjører.
Grensesnittet endres umiddelbart.
Forretningsprosessen skal ikke det.
Det skillet er viktig.
Lageret flytter seg ikke fordi ordet for lager endret seg.
Plukkordren starter ikke på nytt fordi brukeren valgte et annet språk.
En reservasjon forsvinner ikke.
Et unntak tilhører ikke plutselig en annen transaksjon.
Prosessen forblir der den er.
Bare representasjonen endres.
Det høres opplagt ut.

Helt til man innser hvor mange applikasjoner behandler et språkbytte nesten som en ny økt.

En flerspråklig forretningsapplikasjon bør ikke gjøre det.
Presentasjonstilstanden kan endres.
Forretningstilstanden må forbli stabil.
Det gjør språkbytte til en overraskende nyttig regresjonstest.
En liten funksjon.
En veldig god bruddlinje.
COCO liker bruddlinjer.

Steg for steg begynner applikasjonen å samle historikk
Varer ankommer.
Prosessen går fremover.
Varemottak bookes.
Beholdningen endres.
Lagerstatusen gjenspeiler den nye virkeligheten.
Plukking begynner.
Lagerbeholdning blir reservert.
Operatøren mottar en oppgave.

En mobilvisning reduserer hele prosessen til det som betyr noe i akkurat det øyeblikket:
Posisjon.
Lagerplass.
Antall.
SSCC.
Operatør.
Ikke mer.
Ikke mindre.
Det er viktig.
Det mobile grensesnittet er ikke en andre forretningsprosess.
Det er en annen visning av samme prosess.
Lagerapplikasjonen kan vite alt.
Plukkeren skal ikke måtte det.
Clarity betyr ikke alltid å vise mer informasjon.
Noen ganger betyr clarity å ha disiplinen til å skjule nesten alt.

Så skanner noen feil lokasjon
Her blir en logistikk-arbeidsflyt mer interessant enn en funksjonsliste.
Den forventede lokasjonen er én ting.
Den skannede lokasjonen er en annen.
Flow stopper.
Krasjer ikke.
Stopper.
Det er en forskjell.
Prosesstatusen forblir synlig.
Den berørte beholdningen forblir forståelig.
Unntaket blir eksplisitt.

Kontekstuell hjelp forklarer hva som er relevant for den nåværende situasjonen.
Brukeren løser avviket.
Prosessen fortsetter.
Dette øyeblikket sier mer om operativ programvare enn flere sider med happy-path-skjermbilder.
Ekte logistikk er ikke vanskelig når alt er korrekt.
Ekte logistikk blir vanskelig når noe er nesten korrekt.
Et nyttig system skjuler ikke det bak et grønt dashbord.
Det gir unntaket en status.

En grunn.
En historikk.
Og en vei videre.

Dokumenter husker det folk glemmer

Etter hvert som arbeidsflyten skrider frem, begynner referanser å samle seg opp.
ASN.
Varemottak.
Lagerbevegelse.
Plukking.
Utsendelse.
Flow.
Den interessante delen er ikke at dokumenter finnes.
Den interessante delen er at de forteller den samme historien som prosessen.
Hvorfor er denne beholdningen her?
Hvilket mottak introduserte den?
Hvilken operasjon reserverte den?
Hvilken plukking forbrukte den?
Hvilken forsendelse flyttet den ut?
Ble et unntak løst før neste steg?
Hva var det aktive lageret?
Hva skjedde før den nåværende tilstanden?
Når tilstand og dokumentasjon produseres av samme prosess, blir sporbarheten lettere å stole på.
Når de ikke er det, begynner folk til slutt å rekonstruere historikken.
Vanligvis i Excel.
Vanligvis under press.
Vanligvis etter at noe allerede har gått galt.
COCO foretrekker bevis før det øyeblikket.
Tydeligvis reiser COCO også
Det var enda en liten endring mellom kjøringene.
Ubuntu hadde sin kjøring.
Red Hat Enterprise Linux 10 tok den neste.
COCO fortsatte.
Ingen seremoni.
Ingen spesiell "Red Hat-modus".
Ingen omskrevet arbeidsflyt.
Ingen bekvemt forenklet test.
Samme Flow.
Annen grunn under den.
En tidligere COCO-kjøring hadde allerede testet applikasjonen på Ubuntu Linux.
Den nåværende flyttet til Red Hat Enterprise Linux 10.
Annet skrivebordsmiljø.
Andre systembiblioteker.
Annen pakking.
Annet driftsmiljø.
Samme lager.
Samme forretningstilstander.
Samme beholdningsoverganger.
Samme språkendringer.
Samme unntakslogikk.
Samme bevis.
Det er en ganske fin måte å teste plattformuavhengig programvare på.

Ikke annonser at det er plattformuavhengig. Flytt det. Se så hva som går i stykker.

Språktilstand.
Lagerkontekst.
Dialogoppførsel.
Timing.
Temaer.
Prosessoverganger.
Unntakshåndtering.
Bevis.
Operativsystemer har overraskende kreative måter å avsløre antakelser på.

Ubuntu avslørte noen.
Red Hat avslører andre.
Det er nyttig.

Fordi multiplattform-utvikling ikke er evnen til å starte den kjørbare filen to ganger.

Det er evnen til å endre miljøet uten å endre betydningen av prosessen.
En lageroperatør bør ikke bry seg om applikasjonen kjører på Ubuntu eller Red Hat.
En plukkordre bør heller ikke bry seg.
Det bør heller ikke et revisjonsspor.
Hvis plattformforskjeller begynner å endre forretningsatferd, er programvaren ikke virkelig plattformuavhengig.
Den er bare portabel.
COCO virker betydelig mer interessert i den første definisjonen.
Det er vi også.

COCO bestemmer ikke hva korrekt logistikk betyr
Denne delen er viktig.
COCO blir ikke en lagerekspert bare fordi det kan følge en lager-arbeidsflyt.
Mennesker definerer fortsatt korrekthet.
Mennesker bestemmer når beholdning blir tilgjengelig.
Mennesker definerer hva en blokkert levering betyr.
Mennesker bestemmer hvem som kan korrigere en mengde.
Mennesker definerer hvilken bevegelse som krever et revisjonsspor.
Mennesker bestemmer hvordan en gyldig unntaksløsning ser ut.
Mennesker bestemmer når en forsendelse er virkelig komplett.
COCOs jobb er annerledes.

Gjenta.
Observere.
Sammenligne.
Huske.
Etterlate bevis.

Gjør det så igjen etter at programvaren endres.
Og igjen.
Og igjen.
Uten å bli lei.
Uten å bestemme at forrige ukes resultat sannsynligvis fortsatt er gyldig.
Uten å hoppe over det irriterende unntaket fordi lunsjen er om tolv minutter.
Den glamorøse fremtiden for AI-testing inneholder en overraskende mengde repetisjon.
Vi anser det som en funksjon.

Bevis endrer samtalen
Tradisjonell testing ender ofte med en helt fornuftig setning:
"Det fungerte da jeg testet det."

COCO er interessert i den neste setningen.

Hva fungerte nøyaktig?
Hvilket lager?
Hvilken bruker?
Hvilket språk?
Hvilken prosesstilstand?
Hvilken sekvens?
Hvilket dokument?
Hvilken beholdningsverdi?
Hva skjedde umiddelbart før teststeget?
Hva endret seg umiddelbart etterpå?
Kan en annen ingeniør forstå resultatet uten å spørre personen som utførte testen?
Det er der regresjonstesting blir mer enn gjentatt klikking.
En skjerm kan være korrekt mens prosessen er feil.
Et plukkevindu kan se perfekt ut mens beholdningen allerede har drevet av sted.
Et dokument kan eksistere mens tilstanden som skulle ha skapt det aldri inntraff.
En applikasjon kan vise 100 % mens et revisjonsspor stille er uenig.
COCO følger Flow fordi det er i Flow disse motsigelsene blir synlige.

Et sted mellom Control og Flow
Det er en interessant symmetri her.
God logistikkprogramvare prøver å redusere usikkerhet innenfor en operasjon.
God testing prøver å redusere usikkerhet om programvaren som kjører den.
Den ene spør:
Hvor er varen?
Den andre spør:
Hvordan vet vi at programvaren fortsatt vet det?
Den ene spør:
Ble denne bevegelsen fullført?
Den andre spør:
Hvilket bevis viser at tilstanden endret seg riktig?
Den ene spør:
Kan neste skift fortsette?
Den andre spør:
Kan neste ingeniør forstå hva som skjedde?
Ulike spørsmål.
Samme instinkt.
Gjør tilstanden synlig.
Bevar resonnementet.
Reduser mengden kunnskap som bare finnes i noens hode.
Kanskje er det koblingen vi ikke opprinnelig planla.

Ingeniørmessig fortreffelighet uten banneret
Ingen klikker på en Engineering Excellence-knapp.
Det finnes ingen.
Og det bør sannsynligvis ikke finnes en.
Ingeniørmessig fortreffelighet viser seg indirekte.
Lagerkonteksten overlever et språkbytte.
Samme prosess overlever en annen Linux-plattform.
En lagerbevegelse forblir sporbar.
En mobil plukker ser nøyaktig det som trengs og ingenting annet.
Et unntak avbryter prosessen uten å ødelegge dens tilstand.
Hjelpevinduet forklarer den nåværende konteksten i stedet for å vise generisk dokumentasjon.
Dokumentkjeden stemmer overens med den operative sekvensen.
Neste ingeniør kan forstå hva som skjedde uten å spørre personen som tilfeldigvis var der.
Det er nok av teater tilgjengelig i moderne programvare.
AI kan generere imponerende demonstrasjoner.
Dashbord kan animeres.
Tall kan bevege seg.
Videoer kan se veldig overbevisende ut.
Ingenting av dette beviser at to beholdningsoperasjoner ikke stille kan produsere et feil resultat.
Ingenting av dette beviser at et unntak fortsatt kan rekonstrueres uker senere.
Ingenting av dette beviser at lagerarbeideren, spedisjonøren, og utvikleren ser på den samme operative sannheten.

Ingeniørmessig fortreffelighet starter et mindre fotogent sted.

Med konsistens.
Med bevis.
Med grenser.

Med viljen til å holde de kjedelige delene kjedelige.
Usynlig pålitelighet produserer sjelden det mest dramatiske skjermbildet.
Helt til man bevisst begynner å lete etter det.

Control. Clarity. Flow.
Control er å vite hvilket lager, hvilken prosess, og hvilken tilstand som er aktiv.
Clarity er å forstå hva som endret seg, når det endret seg, og hvorfor.
Flow er å la operasjonen fortsette uten å miste historien bak den.
Det fungerer for logistikk.
Det fungerer for programvaretesting.
Det fungerer overraskende bra for ingeniørfaget selv.
Det første Flow-eksperimentet ga COCO Administration.
Brukere.
Roller.
Databaser.
Språk.
Så ga noen det et lager.
Så flere språk.
Så mobil plukking.
Så beholdning.
Så omplasseringer.
Så unntak.
Så dokumenter.
Så et annet operativsystem.
På dette tidspunktet bør vi sannsynligvis slutte å legge til ting.
Vi kommer sannsynligvis ikke til å gjøre det.

Control. Clarity. Flow.

Ubuntu hadde sin tur.

Red Hat har den nåværende.

Flow fortsetter å bevege seg.

COCO fortsetter å se på.
Og et sted midt i den siste kjøringen ble det tydelig at det er et annet spørsmål som venter bak dette.

Vi vet hva det er.
COCO vet hva det er.
Du vet det ikke.
Ennå.

Vi kunne fortalt deg det.

Men da vil du kanskje slutte å sjekke om en ny Insiders-artikkel har dukket opp.
Og det ville ødelagt eksperimentet.