Boktips: The Principles of Product Development Flow

Jag har ibland svårt att ta mig tid att läsa böcker.  Speciellt långa och svåra böcker. Men den här våren har jag läst en av de jobbigaste böckerna om produktutveckling, helt tack vare Hemnets bokklubb (och tack vare Marcus Kempe som startade den).

51pdvcfcp3l._sx338_bo1204203200_

Den här jobbiga men briljanta boken heter The Principles of Product Development Flow och är skriven av Donald Reinertsen. Jobbig eftersom den är skriven av en ingenjör på ett ingenjörsmässigt sätt, innehåller formler och referenser till tunga saker som köteori. Briljant eftersom den känns helt komplett. Att följa principerna i boken, även om man bara följer några, kommer göra ens bolag eller team effektivt. Principer som att mäta rätt saker, inte ha för mycket igång samtidigt eller prioritera på ett rationellt sätt.

Min minst lika briljanta kollega Kristofer jämförde boken med en komplett referens till allt man behöver tänka på för att laga god mat. Om man ska baka en lax perfekt ska ugnen till exempel vara på 180 grader eftersom [lång förklaring]. Men den är rätt värdelös när barnen skriker av hunger och man snabbt behöver sno ihop något hyggligt krubb.

Jag har svårt för sådana här böcker, vill gärna ha inspirerande och konkreta exempel snarare än formler. Men kanske just därför har jag lärt mig en massa av att läsa boken. Just att den saknar det konkreta gör att man själv behöver fylla i en massa luckor, exemplifiera och konkretisera gör den till en perfekt bokklubbsbok. Sen skadar det inte alls att ha fantastiska kollegor att diskutera med.

Prioritera utifrån ekonomiskt värde över tid

Jag gillar att sätta mål, mäta och följa upp vad tjänster levererar. Man försöker alltid hitta mål och metrics som man känner är bra mått på att vi levererar nytta för användare och affär. Det blir lite gissningsarbete.

Reinertsen menar att vi oftast använder fel metrics och har alldeles för dålig koll på vad vi faktiskt tjänar. Vi behöver koppla allt vi gör till ett enda mått; Life-cycle profit impact. Alltså hur mycket pengar en förbättring kommer inbringa under en produkts hela livscykel. Det här gäller allt från att ta fram nya produkter till hur vi till exempel jobbar med teknisk skuld eller hur vi sätter samman team.

Jag är tveksam till att mäta allt, och det tror jag inte Reinertsen menar heller. Men jag tror absolut vi alldeles för ofta prioriterar baserat på känsla snarare än på vad som är rationellt. Några exempel:

  • Produktledare lutar ibland åt att prioritera nya produkter för högt. Snabba intäkter värderas högre än långsiktiga förbättringar även om de kan ge bättre ekonomi.
  • Utvecklare lutar ibland åt att prioritera teknisk kvalitet för högt. Snygg och förvaltningsbar kod är ofta bra långsiktigt men mindre viktigt för ett experiment eller en tjänst som bara ska leva några månader.
  • Designers lutar ibland åt att prioritera snygga detaljer för högt. Detaljer som transitioner och animeringar kan göra en del för helhetsupplevelsen. Men om de är dyra att implementera är värdet ibland tveksamt jämfört med annat som att förbättra texter, informationsstruktur eller tillgänglighet.

Ett steg i rätt riktning är att alltid fundera på hur saker kan mätas på ett rättvist sätt där vi kan lägga vår känsla åt sidan och fokusera på vad som ger effekt för affär och användare. På Hemnet jobbar vi med målstyrning enligt OKR vilket lett till en massa bra diskussioner kring mätning och mål.

Optimeringar är ofta u-formade

En annan grej jag tar med mig är att i valet mellan två extremer är det oftast optimalt att lägga sig någon stans mitt emellan.

Batch size, till exempel. Att minska scopet för en uppgift gör att man kan få feedback snabbare, minskar kötid (vi kan gå vidare till nästa uppgift snabbare), minskar risk, minskar overhead och minskar behovet av planering och synkning.

u_curve

Att dela upp eller minska storleken på uppgiften leder ofta till minskade kostnader. Men vi kan inte göra uppgiften för liten, eftersom det också finns en ”transaktionskostnad” i att starta igång och avsluta uppgifter. Som att fördela uppgifter mellan personer eller deploya kod.

Det finns en massa andra exempel på U-formade optimeringar i boken. Hur många uppgifter ska man ha igång samtidigt om man vill maximera genomflöde? Inte en, inte oändligt många.

utilization-4

Hur ”belagda” bör teammedlemmar vara för att jobba så effektivt som möjligt? Jobbar alla 100% finns ingen tid att hjälpa andra med sina uppgifter eller styra om när förutsättningar ändras vilket leder till fördröjningar. Lite slack är bra. Men det är inte heller mest effektivt att alla jobbar 50%. Den optimala beläggningen ligger någonstans däremellan, runt 80%.

Man kan aldrig kan vara dogmatisk kring något. Sanningen finns alltid mitt emellan två extremer. Det tycker jag är en väldigt bra sak att ha med sig när det gäller typ allt.

Tack!

Jag skulle aldrig läst klart den här boken utan bokklubben (som minskade i storlek i takt med att folk tröttnade). Men jag rekommenderar den absolut. Dels till den som är processnörd, gillar ingenjörsmässiga beskrivningar, vill förstå varför agile/lean är bra och kunna tänka ut egna lösningar på processproblem. Dels till den som har en snäll kollega att diskutera med och få moraliskt stöd av.

Annons

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com-logga

Du kommenterar med ditt WordPress.com-konto. Logga ut /  Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut /  Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut /  Ändra )

Ansluter till %s