"Det tager kun et øjeblik"
Alle, som arbejder med opbygning eller vedligehold af en hjemmeside, app eller system, kender den besked.
"Kan I bare ændre den knap?"
"Det er virkelig bare en lille rettelse."
"Flyt lige dette element."
"Kan det gøres hurtigt?"
"Det er vel 5 minutters arbejde?"
Og nogle gange er det faktisk sådan.
Nogle gange tager en farveændring af en knap få minutter. Nogle gange kræver rettelse af en stavefejl ét klik. Nogle gange åbner udvikleren koden, ændrer en linje og så er det klaret.
Problemet er, at ikke alle ændringer, som ser små ud for brugeren, er små set fra systemets perspektiv.
Og et endnu større problem opstår, når der er dusinvis, snesevis eller hundreder af sådanne "små ændringer" om måneden. Så begynder der at ske noget interessant.
Virksomheden kan få indtryk af, at der i realiteten ikke bestilles noget stort. Samtidig bruger IT-teamet en betydelig del af tiden på netop disse små opgaver.
Og her kommer spørgsmålet: Hvad koster én knap "Ret det hurtigt" egentlig?
Lad os starte med et simpelt eksempel
Forestil dig, at marketingafdelingen sender en besked til softwarehuset:
"Hej, vi skal bare ændre teksten på knappen. I stedet for 'Se tilbud' skal det være 'Lær tilbuddet at kende'. Det er en lille ting, så lav det venligst hurtigt."
Det lyder banalt. Men fra teknisk teams side kan det se helt anderledes ud.
Udvikleren skal:
1. Analysere anmodningen
Hvor findes knappen?
Er den kun ét sted?
Findes den i flere versioner af siden?
Er teksten indtastet direkte i koden?
Styres den af et CMS?
Gælder ændringen både desktop- og mobilversionen?
Er knappen en del af en komponent, der bruges andre steder?
2. Foretage ændringen
Ændre teksten.
Ombygge komponenten.
Opdatere indhold i CMS.
Eller modificere koden.
3. Kontrollere resultatet
Ser knappen stadig korrekt ud?
Går teksten uden for området?
Virker det på mobil?
Har ændringen påvirket andre steder?
4. Teste
Kan man klikke på den?
Fører linket til det rigtige sted?
Er der opstået fejl?
5. Udrulle ændringen
Hvis ændringen kræver deployment, skal den sættes i produktion.
Og pludselig viser det sig, at: "Bare en tekstændring"
ikke nødvendigvis betyder: "Kun 5 minutters arbejde".
Hvad kan en lille ændring koste?
Lad os antage et meget konservativt scenarie.
Udvikleren bruger:
- 15 minutter på analyse,
- 20 minutter på implementering,
- 15 minutter på test,
- 10 minutter på forberedelse og udrulning.
I alt: 60 minutters arbejde.
Og her kommer et vigtigt punkt. Hvis teamets timeløn for eksempel er 200 kr. netto, koster en tilsyneladende lille ændring omkring: 200 kr. netto.
Men det er ikke alt. I den reelle proces kan der opstå:
- overdragelse af opgaven,
- afklaring af omfanget,
- spørgsmål til kunden,
- ventetid på svar,
- kontrol af resultatet af den, der indberetter,
- rettelse efter feedback,
- ny udrulning.
En time kan derfor meget nemt blive til to. Og en lille ændring til flere timers arbejde for hele holdet.
Det dyreste er ikke udførelsen
Det kan lyde paradoksalt. Nogle gange tager selve opgaven 10 minutter. Men forberedelsen tager 20 minutter mere. Og så kommer test, udrulning, kommunikation og kontekstskift.
Og netop det sidste element er ofte mest undervurderet.
Context switching - den skjulte omkostning ved små opgaver
Udvikleren arbejder på en stor funktion. Koden er åben. Vedkommende er fokuseret.
Pludselig dukker der en besked op: "Hej, bare en lille ting. Kan du rette knappen?"
Udvikleren afbryder arbejdet. Åbner ticketen. Tjekker siden. Finder stedet i koden. Laver ændringen. Tester. Udruller. Går tilbage til den oprindelige opgave...
Og så skal vedkommende huske: "Hvad var det nu, jeg lavede?"
Det er netop context switching, det vil sige skift af kontekst. Og det kan være meget dyrt. Ikke fordi hver enkelt ændring kræver meget arbejde, men fordi hver ændring afbryder tankegangen.
Jo mere komplekst arbejdet er, desto større er omkostningen ved at vende tilbage. Derfor betyder 10 mikroopgaver ikke altid 10 × 10 minutter. I praksis kan det være langt mere.
Én knap er ingenting. Hundrede knapper er en proces.
Antag, at virksomheden sender til teknisk team:
- 20 små ændringer om måneden,
- hver tager i gennemsnit 45 minutter.
Det giver: 15 timers arbejde om måneden.
Ved en sats på 200 kr. netto: 3.000 kr. netto om måneden.
Årligt: 36.000 kr. netto.
Og vi taler kun om 20 små opgaver om måneden. Uden nye funktioner. Uden produktudvikling. Uden nye moduler. Uden integrationer. Uden design.
Bare: "ændr", "ret", "flyt", "tilføj", "fjern".
Forestil dig nu en organisation, hvor der er 50 sådanne opgaver om måneden. Eller 100.
Skalaen ser helt anderledes ud...
Mikroopgaver har en anden omkostning - de blokerer for udvikling
Det er en af de vigtigste brikker i puslespillet.
Hvis udviklingsteamet bruger 20% af tiden på små rettelser, kan det ikke bruge de 20% på produktudvikling. Det lyder indlysende. Men i praksis ses det ofte ikke direkte.
Virksomheden siger: "Hvorfor er den nye funktion ikke færdig endnu?"
Udvikleren svarer: "Vi havde mange løbende emner."
"Hvilke?"
"Rettelser, små ændringer, opdateringer, små opgaver."
Hver enkelt var lille. Men sammen skabte de en stor blok af arbejde. Det er lidt som notifikationer på telefonen. Én notifikation går an. Ti er lidt forstyrrende. Hundrede?... Pludselig har vi brugt hele dagen på at reagere.
Det er det samme med mikroopgaver.
"Lille opgave" er ikke altid en lille opgave
Det er også vigtigt at forstå, at ikke alle ændringer er ens. En tekstændring i CMS kan virkelig tage få minutter.
Men en tekstændring i en applikation kan kræve:
- at finde komponenten,
- ændring af kode,
- opdatering af oversættelser,
- tests,
- rebygning af applikationen,
- udrulning.
Ændring af ét felt kan kræve modifikationer i:
- frontend,
- backend,
- databasen,
- API.
Ændring af et element i systemet kan påvirke andre elementer.
Derfor giver spørgsmålet: "Hvor lang tid tager det at ændre denne knap?" ofte ingen meningsfuld svar uden kendskab til systemarkitekturen.
Først skal man tjekke. Først derefter kan man estimere.
Hvorfor siger udvikleren nogle gange: "Jeg skal lige tjekke"?
Det er ikke en undvigende bemærkning. Det er ofte et tegn på professionalisme.
En god udvikler bør ikke love: "Ja, selvfølgelig, fem minutter." hvis vedkommende ikke ved, hvad der ligger under overfladen.
Vedkommende bør sige: "Jeg undersøger, hvor elementet bruges, og giver besked."
Det kan tage 10 minutter. Men de 10 minutter kan spare flere timers problemer. For den dyreste ændring er ofte ikke den, der tager en time.
Den dyreste er den, som:
- ødelægger en anden funktion,
- skaber fejl i produktionen,
- kræver akut rollback,
- genererer nye tickets,
- kræver indsats fra flere personer.
Derfor er analyse før ændringen en del af arbejdet, ikke spild af tid.
Hvordan kan kunden reducere omkostningerne ved mikroopgaver?
Det handler ikke om at stoppe med at anmode om små ændringer. Små ændringer er en normal del af produktudvikling. Det handler om at styre dem godt.
1. Gruppér små opgaver
I stedet for at sende:
"Skift knappen."
"Ret lige overskriften."
"Og tilføj linket."
"Og flyt dette element."
er det bedre at samle dem i en pakke.
Teamet kan så lave flere ændringer i én arbejdscyklus.
Mindre kontekstskift.
Mindre kommunikation.
Færre udrulninger.
Lavere omkostninger.
2. Prioritér
Ikke alt er akut.
Hvis alt får status:
AKUT
er intet reelt akut.
Det er godt at opdele opgaver i:
- kritiske,
- vigtige,
- planlagte,
- kosmetiske.
Så kan teamet arbejde mere effektivt.
3. Overvej, om ændringen kræver kode
Hvis virksomheden ofte ændrer:
- tekster,
- billeder,
- bannere,
- links,
- meddelelser,
er problemet måske ikke langsommeligheden hos udvikleren.
Måske er problemet arkitekturen.
Hvis hver indholdsændring kræver en programmør, bør man overveje et CMS eller et administrationspanel.
Et godt designet system bør lade forretningsbrugere styre det, som reelt ikke kræver udviklerindgriben.
Et godt system bør svare på spørgsmålet: hvem bør lave denne ændring?
Det er en vigtig designregel. Ikke alle ændringer bør gå til udvikleren.
Hvis marketing kan selv:
- ændre tekst,
- erstatte et billede,
- tilføje en artikel,
- ændre rækkefølgen af sektioner,
giver det ingen mening at involvere en programmør.
Udvikleren bør fokusere på det, som kræver deres kompetencer.
Altså blandt andet:
- bygge nye funktioner,
- systemudvikling,
- integrationer,
- optimering,
- sikkerhed,
- arkitektur,
- løse tekniske problemer.
Ellers begynder virksomheden at betale udviklere for arbejde, som systembrugere kunne udføre selv.
Det svarer lidt til at hyre en mekaniker til at tanke bilen. Jo, vedkommende kan gøre det. Men er det nødvendigt?
Hvornår er det værd at sige: "Lad os gøre det anderledes"?
Hvis den samme forespørgsel dukker op regelmæssigt, bør man stoppe op og stille spørgsmålet:
Hvorfor gør vi det manuelt hver gang?
Hvis vi hver uge beder om den samme ændring, bør vi måske lave:
- en indstilling i CMS,
- en konfiguration,
- et administrationspanel,
- automatisering,
- et self-service værktøj.
Den engangsomkostning ved at bygge sådan en løsning kan være højere. Men bagefter kan hver ændring tage få sekunder i stedet for timer.
Det er forskellen mellem at betale for hver ændring og at investere i et system, der tillader selvbetjening.
Mikroopgaver og samarbejdsmodellen med softwarehuset
Det er også vigtigt for kunder.
Hvis samarbejdet med softwarehuset kun er baseret på modellen: "I sender - I får et tilbud - Vi accepterer - I udfører", kan hver lille ændring skabe ekstra organisatorisk overhead.
Derfor fungerer ofte bedre ved løbende samarbejde:
- timepakker,
- vedligeholdelsesabonnement,
- dedikeret team,
- backlog af opgaver,
- regelmæssige sprints,
- fastlagte udrulningsvinduer.
Det betyder ikke, at alle kunder skal vælge samme model. Det handler om at matche samarbejdsformen med projektets karakter.
Hvis virksomheden kun har én ændring om måneden, kan en kompleks proces være overkill. Hvis virksomheden har 50 opgaver om måneden, kan manglende proces blive meget dyrt.
Bør man opgøre hver ændring?
Det afhænger.
I nogle projekter giver en detaljeret opdeling af tid mening. I andre skaber det mere administration end besparelse.
Derfor er det værd at se samarbejdet i et bredere perspektiv.
Det vigtigste spørgsmål er ikke: "Hvad kostede den ene ændring?"
Et bedre spørgsmål er: "Hvad koster måden, vi styrer alle ændringer på?"
Hvis virksomheden betaler 200 kr. for én ændring, men dermed undgår fejl og har sikkerhed for, at alt fungerer, kan det være en fornuftig udgift.
Hvis virksomheden derimod hver måned betaler flere tusinde kroner for dusinvis af lignende mikroopgaver, er det værd at overveje, om problemet kan løses systemisk.
De dyreste ord i IT?
Måske er det: "Det er bare en lille ændring."
Ikke fordi små ændringer er dårlige. De er nødvendige.
Et digitalt produkt lever. Kundernes behov ændrer sig. Markedet ændrer sig. Marketing ændrer sig. Teknologien ændrer sig. Forandringer er naturlige.
Problemet opstår, når organisationen ikke ser de akkumulerede omkostninger.
Én lille ændring? - Ikke noget stort.
Ti? - Stadig ikke så meget.
Hundrede? - Det er allerede en proces.
Og hvis der er dusinvis af sådanne processer? Pludselig bruger virksomheden ikke penge på produktudvikling; den bruger dem på konstant at rette småting.
I stedet for at tælle knapper, så tæl tid
Godt styret digital produktudvikling handler ikke om at forhindre kunder i at anmode om små ændringer.
Det handler om at vide:
- hvilke ændringer virkelig kræver en udvikler,
- hvilke der kan udføres af andre,
- hvilke der bør automatiseres,
- hvilke der bør grupperes,
- hvilke der er reelt presserende,
- hvilke der kan planlægges,
- hvilke der bør løses systemisk.
For nogle gange er det bedste svar på: "Ret det hurtigt."
ikke: "Okay, vi gør det."
men: "Lad os tænke over, hvorfor vi igen om en måned skal rette det."
Det er her, softwarehuset ophører med kun at være en leverandør af opgaver og begynder at være en teknologisk partner. For en god partner udfører ikke kun de næste tickets.
Den hjælper også med at se, at nogle gange er den billigste ændring ikke den, vi gør hurtigst. Den billigste er den, vi ikke behøver at lave for hundrede gange.
Og derfor kan én knap "Ret det hurtigt" koste en time.
Men et veludformet system kan gøre, at de næste hundrede lignende ændringer klares af dig selv på få minutter.
Det er ikke en besparelse på udviklere. Det er en investering i bedre processer, bedre arkitektur og klogere udnyttelse af hele teamets tid.
