Utbenat: Fail Fast

Inledning

Sebastian:
‍Varmt välkomna till Syntra Utbenat. Det här är podden där vi under 10 minuter reder ut orden och begreppen som cirkulerar i data- och AI-världen, och benar ut vad de faktiskt betyder – tillsammans med Sebastian Mildgrim.

Den dyra middagsbjudningen

Sebastian:
‍Föreställ dig att du ska ha en stor, viktig middagsbjudning på lördag. Tolv personer kommer över. Du bestämmer dig för att slå på stort och laga en avancerad, fransk skaldjursgryta från en fin kokbok du fått i julklapp. Du går upp tidigt. Du köper färsk fisk, saffran och ett vin för lite mer än du brukar spendera. Du hackar, du kokar fond, du silar och du reducerar. I sex timmar står du vid spisen och sliter med det här massiva projektet.

När gästerna sätter sig häller du stolt upp grytan i vackra tallrikar. Du sätter dig ner, tar din allra första sked och smakar. Och... det smakar katastrof. Du råkade ta fel på tsk och msk för saltet, och vinet du hällde i hade fått korkröta. Det är helt oätligt. Där sitter du. Du har slösat en hel lördag, bränt massa pengar och gästerna är hungriga. Om du bara hade tagit en liten sked och smakat på fonden efter femton minuter... då hade du kunnat slänga den, skratta åt misstaget och hittat en lösning. Men du väntade i sex timmar och nu är det bara pizzabudet som kan rädda kvällen.

Vad "Fail Fast" egentligen betyder

Sebastian:
‍IIdag ska vi prata om vad som egentligen gick fel med skaldjursgrytan, vi ska prata om begreppet Fail-fast. Det är en term som ofta slängs in i presentationer av ivriga konsulter, och som ofta missförstås av ledningsgrupper som tror att det betyder "vi ska misslyckas". Men i själva verket handlar det om överlevnad, prestige och konsten att inte laga mat i sex timmar utan att smaka.

Fail-fast är en filosofi som handlar om riskminimering. När vi bygger nya system, lanserar en AI-modell eller skapar en ny dataplattform, så bygger vi det nästan alltid på antaganden. Vi antar att användarna vill ha den här funktionen. Vi antar att datakvaliteten är tillräckligt bra. Fail-fast betyder att vi måste bygga den allra minsta, billigaste versionen av vår idé för att testa om det antagandet stämmer. Och om det inte stämmer, så avbryter vi snabbt. Innan vi har bränt budgeten.

Det traditionella IT-projektet

Sebastian:
Låt oss titta på hur verkligheten ofta ser ut i våra företag. Vi är otroligt duktiga på att starta projekt. Vi sätter ihop en styrgrupp, vi skriver en kravspecifikation på flera sidor och vi ber om en budget på en miljon. Sen låser vi in projektteamet i en källare i sex månader för att bygga en ny AI-assistent för kundtjänst eller kanske en pristjänst för våra avtalskunder på e-handeln.

När vi sen står inför att rulla ut systemet med pukor och trumpeter... så upptäcker vi att verkligheten inte riktigt är som vi trodde. AI-assistenten vi byggde kanske ger blixtsnabba svar, men det visar sig att kunderna blir frustrerade för att de egentligen bara ville prata med en människa när deras faktura blivit fel. Eller så räknar den nya pristjänsten ut exakt rätt rabatter, men e-handelskunderna loggar ändå inte in, för de föredrar att ringa sin stamsäljare för att förhandla. Vi har byggt en tekniskt perfekt lösning på ett beteendeproblem som vi helt missförstod från början. Det är ett otroligt dyrt sätt att upptäcka att man har fel.

Varför vi inte vågar misslyckas tidigt

Sebastian:
Varför gör vi så här då? Det handlar om mänsklig psykologi och något som kallas "Sunk Cost Fallacy" – fällan att kasta goda pengar efter dåliga. Men framförallt handlar det om prestige. Säg att ni är ett par månader in i det där projektet. Projektledaren börjar inse att den tekniska plattformen ni valde inte klarar av belastningen. Det kommer inte att fungera.

I en Fail-fast-kultur hade projektledaren dragit i handbromsen direkt, gått till ledningsgruppen och sagt: "Vi hade fel i ett av våra antaganden. Tekniken vi valt håller inte. Vi avbryter och måste omvärdera om det är värt att försöka igen med en annan teknik eller om vi ska omallokera budgeten till något annat" Men i en traditionell företagskultur är det ofta livsfarligt att misslyckas. Den som drar i handbromsen riskerar att pekas ut som syndabock, istället för att hyllas som hjälten som just sparade företaget en massa pengar. Man vill inte vara den som spräcker bubblan. Så istället för att dra i handbromsen, så börjar man lappa och laga. Man anlitar fler konsulter. Man tvingar fram en halvdan lösning bara för att kunna visa upp något, för man har ju redan bränt ett par hundratusen. Man driver ett så kallat "vattenmelonprojekt": Det är grönt och fint på utsidan i alla statusrapporter, men det är blödande rött på insidan. Allt för att man inte vågar misslyckas tidigt.

"Learn Fast" – det vi egentligen menar

Sebastian:
Egentligen är "Fail-fast" ett ganska olyckligt namn, för ingen gillar ordet fail. Det skapar rädsla. Det vi egentligen pratar om är Learn-fast. Hur snabbt kan vi få ny kunskap? Inom data och AI är detta extra viktigt, för vi har sällan alla svar när vi börjar. Vi vet inte hur AI:n kommer svara förrän vi ger den vår data. Om vi bygger allt färdigt innan vi testar datan, tar vi en enorm risk. Att applicera den här filosofin innebär att vi byter fokus från "Hur snabbt kan vi bygga klart allt?" till "Vilken är vår största och farligaste gissning just nu, och hur kan vi bevisa eller motbevisa den redan nästa vecka?". Helt enkelt, att fail-fast är egentligen bara att köpa sig information. Vad är billigast: Att betala tio tusen kronor nu för att veta att idén är dålig, eller en miljon om sex månader för att lära sig exakt samma sak?

Lösningen: Bryt ner riskerna

Sebastian:
‍Så, hur kommer vi ur det här beteendet? Hur slutar vi bygga månader i blindo? Det handlar om att sluta se projekt som enorma block, och istället börja isolera det vi faktiskt är osäkra på. Vi måste sänka tröskeln för att testa och pröva. Det gör vi enklast genom att sluta prata om 'krav' och börja prata om 'hypoteser'. Istället för att säga: 'Vi ska bygga ett nytt system', säger vi: 'Vi tror att våra kunder vill lösa det här själva på webben.' När vi formulerar det som ett antagande blir det plötsligt självklart att vi först måste försöka bevisa att vi har rätt, med minsta möjliga ansträngning, innan vi börjar bygga.

Tänk er att ni går in på en riktigt bra, italiensk glassbar. Ni tittar ner i disken och ser en ny, ganska konstig smak. Låt oss säga "Mango och Chili". Det ser lite spännande ut. Men köper ni omedelbart en gigantisk trelitersbytta med Mango-Chili, tar hem den, bjuder hela släkten och hoppas att det är gott?

Nej. Ni ber killen bakom disken om ett smakprov. Han tar en pytteliten, rosa plastsked, skopar upp ett halvt gram glass och räcker över disken. Du smakar. Om det är vidrigt, så slänger du den lilla skeden i papperskorgen och säger: "Nej tack, jag tar vanilj". Det kostade dig noll kronor, det tog fem sekunder, och du undvek en stor besvikelse.

IT-projekt idag saknar rosa plastskedar. Ni sätter er allt för ofta och handlar trelitersbyttor direkt. Fail-fast handlar om att dela ut plastskedar. Innan ni bygger ett massivt dashboard som ska visa försäljning i realtid, kan ni ta ett utdrag till Excel, rita upp en graf manuellt och visa den för säljchefen på ett möte. Om säljchefen säger "Det där mätetalet bryr jag mig inte ett dugg om", ja, då kastar ni skeden och har sparat den utvecklingstiden.

Det här gör du på måndag

Sebastian:
‍Så här gör ni på måndag. Titta på ert största pågående, eller kommande, projekt. Fråga er själva: Vad är det största antagandet vi gör just nu för att det här ska lyckas? Är det att kundtjänst faktiskt kommer använda det nya verktyget? Är det att datan i gamla systemet är tillräckligt ren?

När ni har identifierat det farligaste antagandet, hitta ett sätt att testa just den saken med bara ett par arbetstimmar. Skissa verktyget på en whiteboard. Skicka ett testmejl. Ta ut en manuell lista. Ge er ut och be folk smaka på glassen innan ni köper glassfabriken. Vågar ni slänga de dåliga smakerna tidigt, så kommer fler av era projekt leverera riktigt värde på budget och i tid.

För att sammanfatta: Fail-fast handlar inte om att vara slarvig och misslyckas. Det handlar om att lära sig snabbt, döda prestigefyllda projekt innan de dränerar kassan, och att alltid testa de farligaste antagandena först. Sluta koka soppa sex timmar i blindo, och börja dela ut rosa plastskedar.

Tack för att du lyssnade på dagens avsnitt av Utbenat! Vill du prata mer om dagens ämne eller bara prata data, hör av dig till oss, vi finns på Linkedin. Eller kontakta oss via vår hemsida. Vi hörs, och ta hand om er där ute!

Du har lyssnat på Syntra – en podd från Fiwe.