“Kan I ikke bare bygge en knap der…”. Knappen skal automatisk fordele en indbetaling ud på de rigtige åbne poster, så bogholderen slipper for at sidde og gætte om mandagen. Alle nikker. Det lyder rigtigt, det lyder simpelt, og hvis vi var uansvarlige, kunne vi gå hjem og begynde at kode samme aften.
Det er bare ikke en god idé, og jeg vil gerne fortælle hvorfor. Der ligger en hel arbejdsproces bag et “lad os lige vente lidt”, og der ligger noget vigtigt for systemer og sammenhænge. Jo mere af den her proces du forstår, og jo mere du kan bidrage undervejs, jo bedre en løsning får du ud af det. Så det her er både en beskrivelse af hvordan vi arbejder, fase for fase, og af hvad du selv kan, og bør, gøre langs vejen.
Idéen er sjældent det den lyder som
Det første vi gør med en idé er at være lidt uhøflige ved den. Ikke over for kunden, men over for idéen. For “kan I ikke bare bygge en knap” er ikke en opgave, det er en overskrift, og under den overskrift gemmer der sig som regel en hel række antagelser. Så vi graver. Hvem sidder egentlig med opgaven i dag, hvor tit går det galt, hvad sker der når det går galt, og hvordan ville “godt nok” se ud?
De kunder der gerne vil have mere styr på det der bliver bygget, tager det her meget alvorligt og laver den første del selv. Det svære er ikke at få idéen, det er at beskrive det bagvedliggende problem i stedet for at springe direkte til løsningen. Skriv nogle sætninger: hvad sker der i dag, hvor ofte sker det, hvad går galt, hvad bruger vi af tid på det, og hvordan ville en god dag se ud. Du kan eventuelt bruge en AI som sparringspartner til lige det. Helt konkret kan du skrive sådan her til den:
“Jeg har det her problem: [indsæt beskrivelse af dit problem]. Jeg tror løsningen er: [indsæt beskrivelse af din løsning]. Interview mig om både problemet og løsningen, stil alle de dumme opklarende spørgsmål, og saml det til sidst i en kort, konkret beskrivelse.”
Den kender ikke din BC-opsætning, så den kan ikke fortælle dig hvad der kan lade sig gøre, men den er god til at presse dig til at være konkret.
En kunde der møder op med den slags beskrivelse, sparer os begge for de første timers gætteri. Og nogle gange, når vi graver sammen, opdager vi at det virkelige problem lå et helt andet sted, og at knappen slet ikke var svaret.
Design: at blive uenige på papir
Når vi er blevet enige om hvad problemet faktisk er, går vi i gang med at designe løsningen. Og her vil jeg gerne aflive en myte, for design lyder som noget med farver og skærmbilleder, og det er det næsten aldrig. Design er der hvor vi bliver uenige i teorien, på papir, i stedet for i koden, fordi uenighed på papir koster stort set ingenting, mens uenighed i koden koster den tid det tog at udvikle den. Vi tegner flowet, vi kigger på hvad Business Central allerede kan (der er intet så dyrt som at bygge noget standard-systemet leverer gratis), og vi bliver konkrete om edge cases. Altså alle de situationer hvor virkeligheden ikke opfører sig pænt: den halve indbetaling, den forkerte valuta, brugeren som fortryder midt i det hele.
Her kan du også komme os i forkøbet, og du kan hjælpe på en anden måde end vi kan. Du kender din egen hverdag bedre end nogen konsulent nogensinde kommer til. Så tegn gerne et groft udkast, lav en simpel mockup, om det så bare er på et stykke papir eller noget du har fået en AI til at skitsere, og skriv især de edge cases ned som du kender. Undtagelsen der altid dukker op ved månedsafslutning. Kunden der aldrig betaler det fulde beløb. Det er den slags viden vi ikke kan gætte os til.
Vil du have en AI til at hjælpe dig med at grave edge cases frem, så prøv noget i denne stil:
“Her er en arbejdsgang jeg gerne vil have understøttet i Business Central: [beskriv den skridt for skridt]. Spørg mig systematisk ud om alle de situationer hvor det kan gå galt eller afvige fra normalen, og saml til sidst de undtagelser jeg skal huske at fortælle min konsulent om.”
Én ting skal du vide om dit eget udkast: du ved sjældent hvad BC allerede løser eller hvad der er dyrt kontra billigt at bygge. Så dit design er et startpunkt vi kvalificerer sammen, ikke en færdig plan vi bare eksekverer. Du skal heller ikke blive skuffet hvis vi ender med at have smidt en stor del af det ud, det er hele pointen med at vi gør det teoretisk inden vi bare koder. Alt det andet vi eller du har fundet ud af, var vi aldrig kommet på uden den del vi smed ud.
POC: kan det overhovedet bære
Nu bliver det håndgribeligt. En proof of concept, en POC, er den mindst mulige mængde kode eller opsætning der kan svare på det ene spørgsmål: kan den her tilgang overhovedet bære? Det er ikke et produkt, og det er ikke pænt. Formålet er at aflive urealistiske løsninger så tidligt som muligt, så hvis løsningen afhænger af at vi kan trække data ud af et andet system uden at ødelægge noget, så er det præcis dét vi bygger først, og kun det. Vi vil hellere opdage om tre dage end om tre uger at fundamentet ikke holder.
I mange tilfælde kan man faktisk selv lave en mini-POC ved manuelt at gå igennem de skridt og knapper man vil have automatiseret. Det beviser ikke at vi kan bygge det pænt og stabilt, men det beviser noget mindst lige så vigtigt, nemlig om idéen overhovedet er værd at bygge. Et Excel-mock der viser den ønskede fordeling af indbetalingen, fortæller os på fem minutter mere end en time ved et mødebord. Så hvis du har lysten og tiden: leg med det. Det værste der kan ske er at du opdager at idéen ikke holdt, og det er billig læring. Skal man skridtet videre derfra, skal man nok have fat på en udvikler.
En AI kan også hjælpe dig med at gøre den øvelse struktureret:
“Jeg vil teste om det giver mening at automatisere en opgave. Hjælp mig med at skrive de manuelle skridt jeg tager i dag ned som en tjekliste, og stil spørgsmål til hvert skridt, så jeg kan vurdere hvilke der reelt kan automatiseres, og hvilke der kræver en menneskelig beslutning.”
Udvikling og udviklertests: byg huset
Når vores POC har vist at idéen kan bære, begynder det egentlige udviklingsarbejde, altså der hvor skitsen bliver til rigtig, stabil kode. Her skal vi for alvor oversætte alle de små, glemte detaljer til noget der kan fungere i virkeligheden. Især når der opstår småting der ikke lige passer ind, er det vigtigt at forstå hvorfor du gør som du gør.
En specifikation kan aldrig rumme det hele. Der dukker hele tiden små valg op undervejs som ingen tænkte på ved mødebordet, og en udvikler der forstår din forretning, træffer de valg rigtigt uden at skulle spørge om hver eneste lille ting. En der ikke gør, gætter, og gætter forkert oftere end man skulle tro. Så jo mere af den forståelse vi har fået med fra de tidligere faser, jo færre af de her spørgsmål ender med at blive gættet i stedet for besvaret.
Samtidig med at der bygges, laver udvikleren enten testscenarier der kan udføres manuelt eller automatiske tests. Altså dokumenterer hvordan løsningen kan testes. Det er ikke det samme som testen med rigtige brugere der kommer senere, det er udviklerens eget sikkerhedsnet mens der bygges. Det lyder som dobbeltarbejde, og det tager også tid, men det er den slags tid der betaler sig mange gange, fordi det gør det trygt at ændre og udvide løsningen bagefter uden at noget gammelt går i stykker i det skjulte.
Mantraet er: jo tidligere vi kan påpege en fejl, jo nemmere er den at løse eller rette op på.
Din rolle i denne fase er enklere end i de andre, men den er til gengæld nem at forsømme: vær til at få fat på. De spørgsmål der dukker op under udviklingen, er ofte små, men svarene flytter resultatet. Så forsvind ikke helt efter designet er aftalt. De bedste forløb er dem hvor vi kan sende et kort spørgsmål og få et kort svar inden for samme time.
Trial og test: virkeligheden banker på
Bagefter, eller sideløbende, skifter vi bevidst rolle og prøver at ødelægge vores eget arbejde. Vi tester det oplagte, men vi bruger mindst lige så meget krudt på de skæve indtastninger, de tomme felter, de to brugere som rører ved den samme post samtidig. Vi skriver automatiske tests der kan køre igen og igen, så vi ved at næste gang vi ændrer noget, går det gamle ikke i stykker uden at vi opdager det. Det bliver hurtigt lidt teknisk. Men princippet er simpelt nok: vi vil hellere selv finde fejlen end at du finder den en travl fredag eftermiddag.
Så giver vi løsningen til et lille antal rigtige brugere med rigtige opgaver, og vi holder mund og ser på. Det er næsten altid ydmygende. Ikke fordi løsningen er dårlig, men fordi folk bruger systemer på måder vi ikke havde forudset. Bogholderen klikker et andet sted end vi troede. Den knap vi var mest stolte af, bliver aldrig brugt, mens en lille detalje vi næsten sprang over, viser sig at afgøre om folk gider tage værktøjet til sig. Man kan ikke tænke eller gætte sig til den slags, man kan kun se det.
Vi vil gerne så tæt på brugerne som muligt, for ofte er det nemmere at se når en bruger trykker et uventet sted, end at vente på at brugeren fortæller det. Det du kan gøre som kunde, er at udpege de rigtige testbrugere. Du kan sige på forhånd hvad “det virker” egentlig betyder for jer, så vi tester mod jeres virkelighed og ikke vores forestilling om den. Har du brug for hjælp til at få de kriterier ned på papir, kan du spørge en AI:
“Jeg skal snart afprøve en ny løsning i Business Central. Hjælp mig med at formulere hvad der konkret skal være opfyldt, før jeg vil sige at løsningen virker, både i tal og i hvordan den opleves at bruge.”
Og du kan give os den ærlige feedback, også den lidt pinlige af slagsen: “jaee, den regner rigtigt, men jeg stoler ikke helt på den endnu.” For et værktøj folk ikke stoler på, bliver ikke brugt, uanset hvor korrekt det regner.
Drift: der hvor det egentlig begynder
Og så går løsningen live, og de fleste tror at det er slutningen. Men vi er ikke helt færdige endnu. For nu møder løsningen den rigtige virkelighed, hver dag, med alle slags brugere og de datamængder og edge cases som ingen kunne forudse eller teste. De første uger holder vi ekstra godt øje, det vi kalder hyper-care, hvor der er kort vej fra en bruger som undrer sig, til en som kan svare.
Her bør du være opmærksom på når noget har ændret sig i forretningen, i stedet for at vente til det brænder på. Meld tilbage når en ny idé dukker op, for de bedste videreudviklinger starter ofte som en lille undren i driften. Og hold øje med om løsningen stadig bruges som tænkt, eller om folk har fundet en genvej udenom, for det sidste er næsten altid et tegn på at der er noget vi skal se på sammen.
Og lige dér er vi tilbage ved mødebordet klokken lidt i tre. Forskellen er bare, at du nu kender vejen fra “kan I ikke bare bygge en knap” til noget der kører stabilt om torsdagen, og at du ved hvor du selv kan skubbe på undervejs. Beskriv problemet skarpt, tegn dit udkast, leg med et mock hvis du har mod på det, og sig sandheden i trial. Så laver vi det tekniske løft, og knappen bliver måske aldrig helt som den lød ved det første møde. Den bliver som regel bedre, og som regel fordi vi byggede den sammen.
