"Det tar bara en stund"
Alla som arbetar med att bygga eller underhålla en webbplats, app eller system känner igen det här meddelandet.
"Kan ni bara ändra den här knappen?"
"Det är verkligen bara en liten ändring."
"Flytta bara det här elementet, tack."
"Kan det göras snabbt?"
"Det är nog fem minuter jobb, eller hur?"
Och ibland är det faktiskt så.
Ibland tar det bara några minuter att byta knappfärg. Ibland krävs ett klick för att rätta ett stavfel. Ibland öppnar utvecklaren koden, ändrar en rad och är klar.
Problemet är att inte varje ändring som ser liten ut för användaren är liten ur systemets perspektiv.
Och ett ännu större problem uppstår när sådana "små ändringar" blir ett dussin, flera dussin eller hundratals per månad. Då händer något intressant.
Företaget kan uppfatta att man i princip inte beställer något stort. Samtidigt lägger IT-teamet en betydande del av sin tid på just dessa små uppgifter.
Och här dyker frågan upp: Vad kostar egentligen en knapp "Åtgärda det snabbt"?
Låt oss börja med ett enkelt exempel
Föreställ dig att marknadsavdelningen skickar detta meddelande till ett software house:
"Hej, vi behöver bara ändra texten på knappen. Istället för 'Se erbjudandet' ska det vara 'Upptäck erbjudandet'. Det är en liten grej, snälla gör det snabbt."
Det låter banalt. Men ur teknisk synvinkel kan det se helt annorlunda ut.
Utvecklaren måste:
1. Analysera ärendet
Var finns knappen?
Finns den bara på ett ställe?
Förekommer den i flera versioner av sidan?
Är texten inskriven direkt i koden?
Hanteras den via ett CMS?
Gäller ändringen desktop- och mobilversionen?
Är knappen en del av en komponent som används på andra ställen?
2. Genomföra ändringen
Ändra texten.
Bygga om komponenten.
Uppdatera innehåll i CMS.
Eller modifiera koden.
3. Kontrollera resultatet
Ser knappen fortfarande korrekt ut?
Går texten utanför knappen?
Fungerar allt på mobilen?
Har ändringen påverkat andra ställen?
4. Testa
Går den att klicka på?
Går länken till rätt mål?
Har något fel uppstått?
5. Rulla ut ändringen
Om ändringen kräver en deploy måste den placeras i produktionsmiljön.
Och plötsligt visar det sig att: "bara en textändring"
inte nödvändigtvis betyder: "bara fem minuter jobb".
Vad kan en liten ändring kosta?
Låt oss anta ett mycket konservativt scenario.
Utvecklaren lägger ner:
- 15 minuter på analys,
- 20 minuter på implementering,
- 15 minuter på tester,
- 10 minuter på förberedelse och rullning ut.
Totalt: 60 minuters arbete.
Här kommer en viktig punkt. Om teamets timtaxa är till exempel 200 kr exkl. moms så kostar en till synes liten ändring ungefär: 200 kr exkl. moms.
Men det är inte allt. I den verkliga processen kan även uppstå:
- överlämning av uppgiften,
- förtydligande av omfattning,
- frågor till kunden,
- väntan på svar,
- granskning av resultatet av den som begärde ändringen,
- ändring efter feedback,
- ny rullning ut.
En timme kan alltså mycket lätt bli två. Och en liten ändring kan bli flera timmars arbete för hela teamet.
Det dyraste är inte att utföra ändringen
Det kan låta paradoxalt. Ibland tar själva utförandet 10 minuter. Men förberedelsen tar 20 till. Sedan kommer tester, utrullning, kommunikation och kontextbyte.
Och just det sistnämnda elementet är ofta mest underskattat.
Context switching – den dolda kostnaden för små uppgifter
Utvecklaren jobbar på en stor funktion. Koden är öppen. Hen analyserar problem och är fokuserad.
Plötsligt kommer ett meddelande: "Hej, bara en liten grej. Kan du fixa knappen?"
Utvecklaren avbryter arbetet. Öppnar ärendet. Går in på sidan. Letar i koden. Gör ändringen. Testar. Driftsätter. Går tillbaka till det tidigare arbetet...
Och då måste hen minnas: "Vad höll jag egentligen på med?"
Detta är context switching – att byta kontext – och det kan bli mycket kostsamt. Inte för att varje enskild ändring kräver mycket arbete, utan för att varje ändring bryter det kognitiva flödet.
Ju mer komplext uppdraget är, desto högre blir kostnaden att återgå till det. Därför innebär 10 mikro-uppgifter inte alltid 10 × 10 minuter; i praktiken kan det bli betydligt mer.
En knapp är inget. Hundra knappar är en process.
Anta att företaget skickar till teknikteamet:
- 20 små ändringar per månad,
- var och en tar i genomsnitt 45 minuter.
Det ger: 15 timmars arbete per månad.
Vid 200 kr/timme exkl. moms: 3000 kr exkl. moms per månad.
Årligen: 36 000 kr exkl. moms.
Och här pratar vi bara om 20 små uppgifter per månad. Utan stora funktioner, utan produktutveckling, utan nya moduler, utan integrationer, utan design.
Bara: "ändra", "fixa", "flytta", "lägg till", "ta bort".
Föreställ dig nu en organisation där sådana uppgifter är 50 per månad. Eller 100.
Skalan ser plötsligt helt annorlunda ut...
Mikro-uppgifter har ytterligare en kostnad – de blockerar utveckling
Det här är en av de viktigaste delarna i hela bilden.
Om utvecklingsteamet lägger 20 % av sin tid på små korrigeringar kan de inte använda den tiden för produktutveckling. Det låter självklart, men i praktiken syns det ofta inte.
Företaget frågar: "Varför är inte den nya funktionen klar än?"
Utvecklaren svarar: "Vi hade mycket löpande ärenden."
"Vilka då?"
"Fixar, små ändringar, uppdateringar, små uppgifter."
Var och en var liten. Men tillsammans skapade de ett stort arbete. Det är lite som aviseringar på telefonen: en avisering stör inte, tio är irriterande, hundra...? Plötsligt har vi spenderat hela dagen på att reagera.
Med mikro-uppgifter är det likadant.
"Liten uppgift" är inte alltid en liten uppgift
Det är viktigt att förstå att inte alla ändringar är lika. Att ändra text i ett CMS kan verkligen ta några minuter.
Men att ändra text i en applikation kan kräva:
- att hitta komponenten,
- ändra koden,
- uppdatera översättningar,
- tester,
- ombyggnad av applikationen,
- utdrullning.
Att ändra ett fält kan kräva modifieringar i:
- frontend,
- backend,
- databas,
- API.
En förändring av ett element i systemet kan påverka andra element.
Därför är frågan: "Hur lång tid tar det att ändra den här knappen?" ofta meningslös utan kännedom om systemets arkitektur.
Först måste man kolla. Sedan kan man estimera.
Varför säger utvecklaren ibland: "Jag måste kolla"?
Det är inte att undvika ett svar. Det är ofta ett tecken på professionalism.
En bra utvecklare bör inte lova: "Ja, självklart, fem minuter" om hen inte vet vad som ligger under ytan.
Hen bör säga: "Jag kollar var elementet används och återkommer."
Det kan ta 10 minuter. Men de 10 minuterna kan spara flera timmars problem. För den dyraste ändringen är ofta inte den som tar en timme.
Den dyraste är den som:
- förstör en annan funktion,
- orsakar ett fel i produktionen,
- kräver brådskande rollback,
- genererar fler ärenden,
- kräver insats från flera personer.
Därför är analys före ändring en del av arbetet, inte bortkastad tid.
Hur kan kunden minska kostnaderna för mikro-uppgifter?
Det handlar inte om att sluta begära små ändringar. Små ändringar är en normal del av produktutveckling. Det handlar om att hantera dem väl.
1. Gruppera små uppgifter
Istället för att skicka:
"Byt knappen."
"Ändra rubriken också."
"Lägg till den här länken på köpet."
"Flytta elementet också."
Samla dem hellre i ett paket.
Teamet kan då göra flera ändringar under en arbetscykel.
Mindre kontextbyte.
Mindre kommunikation.
Färre utrullningar.
Lägre kostnad.
2. Prioritera
Allt är inte brådskande.
Om varje sak har status:
URGENT
är ingen av dem verkligen brådskande.
Dela upp uppgifterna i:
- kritiska,
- viktiga,
- planerade,
- kosmetiska.
På så sätt kan teamet arbeta mer effektivt.
3. Fundera på om du behöver ändring i koden
Om företaget regelbundet ändrar:
- texter,
- bilder,
- banners,
- länkar,
- meddelanden,
kan problemet vara arkitekturen snarare än utvecklarnas hastighet.
Om varje innehållsändring kräver en utvecklare kan det vara värt att överväga ett bättre CMS eller administrationspanel.
Ett väl designat system borde låta affärsanvändare själva hantera det som faktiskt inte kräver en utvecklares ingripande.
Ett bra system bör svara på frågan: vem bör göra ändringen?
Det är en viktig designprincip. Inte varje ändring ska gå till en utvecklare.
Om marknadsföring själv kan:
- ändra text,
- byta bild,
- lägga till en artikel,
- ändra ordningen på sektioner,
är det meningslöst att involvera en utvecklare.
Utvecklaren bör ägna sig åt det som kräver deras kompetens.
Det innebär bland annat:
- skapa nya funktioner,
- utveckla systemet,
- integrationer,
- optimering,
- säkerhet,
- arkitektur,
- lösa tekniska problem.
Annars börjar företaget betala utvecklare för arbete som systemets användare skulle kunna utföra själva.
Det är lite som att anlita en bilmekaniker för att tanka bilen. Visst kan de göra det. Men behöver vi verkligen det?
När är det dags att säga: "Låt oss göra det annorlunda"?
Om samma förfrågan återkommer regelbundet är det värt att stanna upp och ställa frågan:
Varför måste vi göra detta manuellt varje gång?
Om vi varje vecka ber om ändring av samma element kanske vi borde skapa:
- en inställning i CMS,
- en konfiguration,
- en adminpanel,
- automation,
- en self-service-mekanism.
En engångskostnad för att bygga en sådan lösning kan vara högre. Men därefter kan varje ny ändring kosta några sekunder istället för en timme.
Det är skillnaden mellan att betala för varje ändring och investera i ett system som tillåter självbetjäning.
Mikro-uppgifter och samarbetsmodell med software house
Det här är också viktigt för kunder.
Om samarbetet med software house endast bygger på modellen: "vi rapporterar – ni prisberäknar – vi godkänner – ni utför", kan varje liten ändring skapa ytterligare organisatorisk overhead.
Därför fungerar ofta bättre vid kontinuerligt samarbete:
- timpaket,
- underhållsabonnemang,
- dedikerat team,
- backlog med uppgifter,
- regelbundna sprintar,
- avtalade utrullningsfönster.
Det betyder inte att alla kunder ska välja samma modell. Det handlar om att anpassa samarbetsformen till projektets karaktär.
Om företaget behöver en ändring per månad kan en omfattande process vara överdriven. Om företaget skickar 50 uppgifter per månad kan avsaknad av process bli mycket kostsamt.
Bör varje ändring faktureras?
Det beror.
I vissa projekt är noggrann minutredovisning meningsfull. I andra skapar det mer administration än besparingar.
Därför är det värt att se samarbetet i ett större perspektiv.
Den viktigaste frågan är inte: "Hur mycket kostade den här ändringen?"
En bättre fråga är: "Vad kostar sättet vi hanterar alla ändringar på?"
Om företaget betalar 200 kr för en ändring men tack vare det undviker fel och har tryggheten att allt fungerar kan det vara en rimlig kostnad.
Men om företaget varje månad betalar flera tusen för tiotals liknande mikro-uppgifter bör man överväga om problemet kan lösas systematiskt.
De dyraste orden i IT?
Kanske är det: "Det är bara en liten ändring."
Inte för att små ändringar är dåliga. De är nödvändiga.
En digital produkt lever. Kundernas behov förändras. Marknaden och marknadsföringen förändras. Tekniken förändras. Ändringar är naturliga.
Problemet börjar när organisationen inte ser deras kumulativa kostnad.
En liten ändring? – Inget stort.
Tio? – Fortfarande inte mycket.
Hundra? – Det är redan en process.
Och om det finns flera sådana processer? Plötsligt visar det sig att företaget inte spenderar pengar på produktutveckling utan på att ständigt justera småsaker.
I stället för att räkna knappar, räkna tid
Välhanterad digital produktutveckling handlar inte om att förbjuda kunder att begära små ändringar.
Det handlar om att veta:
- vilka ändringar som verkligen kräver en utvecklare,
- vilka som kan utföras av användarna själva,
- vilka som är värda att automatisera,
- vilka som bör grupperas,
- vilka som verkligen är brådskande,
- vilka som kan planeras,
- vilka som är värda att lösa systematiskt.
För ibland är det bästa svaret på: "Fixar ni det snabbt?"
inte: "Okej, vi gör det."
utan: "Låt oss fundera på varför vi behöver göra den här ändringen igen om en månad."
Det är här ett software house slutar vara bara en leverantör och blir en teknisk partner. En bra partner utför inte bara ärenden.
Den hjälper också att se att ibland är den billigaste ändringen inte den vi gör snabbast. Den billigaste är den vi inte behöver göra för hundrade gången.
Och därför kan en knapp "Åtgärda det snabbt" kosta en timme.
Men ett väl designat system kan göra så att de nästa hundra ändringarna kan göras själv på några minuter.
Det handlar inte om att spara på utvecklare. Det är en investering i bättre processer, bättre arkitektur och ett smartare utnyttjande av hela teamets tid.
