måndag 8 april 2013

Komplexa problem och komplicerade problemlösningsmetoder matchar inte

För ett år sedan hörde jag om Cynefin-ramverket och tyckte att det verkade akademiskt och smart. Det handlar om olika problemtyper baserat på relationen mellan orsak och verkan.

Bild från wikipedia
I den enkla delen är det enkelt att se samband mellan orsak och verkan. Där kan man skriva recept på lösningar.

I den komplicerade delen behöver man analysera för att förstå bästa lösningen, man kan använda tidigare kunskap för att navigera bättre.

I den komplexa delen behöver man experimentera för att förstå systemet bättre, man kan bygga upp kunskap runt systemet efter hand.

I den kaotiska delen kan man bara förstå i efterhand vad som hände, man kanske kan dra några slutsatser därur.

Utan att gå djupare i ramverket så är det intressant att dela upp problemområden i enkla, komplicerade, komplexa och kaotiska och erkänna att man måste ha olika tillvägagångssätt. När det handlar om enkla och komplicerade problem kan vi fråga om råd och förvänta oss bra tankar givet vår problembeskrivning. Men är problemet komplext eller kaotiskt så räcker inte en problembeskrivning eller goda råd. Då behöver man experimentera och reagera på experimentens utkomst för att hitta bästa lösningen.

Människokroppen är till exempel ofta komplex med vi vill gärna ha problemlösningar som om den vore enkel. Jag frågar doktorn vad jag ska göra när jag har ont i magen och jag vill ha ett svar direkt eftersom hen har skolat sig ca 12 år för att bli doktor. Nu är det så att hen har skolat sig länge för att problemet är komplext och ibland kaotiskt och det är därför som doktorn ibland säger: Prova att göra så här i två veckor och kom tillbaka. Doktorn försöker att samla in ny information för att bygga upp mer kompetens om problemobjektet.

Det samma gäller vid produktutveckling. Om vi vet exakt vad som ska byggas och vilka funktioner som ska finnas så har vi ett enkelt eller komplicerat problem. Om vi däremot inte vet det utan behöver experimentera och prova marknadsbehoven lite så går det inte längre att navigera i förväg med kravspecar och kontrakt. Vi måste navigera tillsammans för att träffa rätt. Annars använder vi komplicerade verktyg för att lösa komplexa problem.

Hela detta inlägget är inspirerat av Liz Keogh korta tal som börjar 1 minut in i filmen från LEAN BOSTON 2012. Där förklarar hon att de agila verktygen scrum och kanban bygger mycket på att man ska bryta ner arbetet i mindre delar som kan planeras för sig. Problemet är att detta räcker bara för enkla och komplicerade problem. Men scrum i sig är ju byggt för att hantera de komplexa problemen.

En tanke som slår mig nu är att tillvägagångssätten för att jobba med komplexa problem på sin höjd är komplicerade. Den beskrivs mycket i Lean Startup av Eric Ries.

Innebär det här att om en person på ett företag blir expert på ett tekniskt område så kommer denne att använda sin kompetens för att lösa problemen istället för att experimentera fram en lösning? Det skulle då betyda att personen försöker lösa ett komplext problem med sina komplicerade tankeverktyg. Det är kanske detta som innebär att inte ha rena ögon på problemet längre.

Det här tål att tänkas vidare på.

Inga kommentarer: