Problemet

1870 fick arkitekten Gustav Dahl uppdraget att rita en ny byggnad till den kungliga boksamlingen på slottet. Biblioteket, som invigdes 1878, utformades efter internationella förebilder. Det blev en av landets första byggnader med stomme i gjutjärnskonstruktion. Bibliotekets exteriör hade ett drag av nyrenässans.

När jag kliver in i den gamla historiska byggnaden så kan jag inte låta bli att förundras av det gamla och traditionella. Men nu var jag där för att utforska framtiden. Jag visste inte exakt vilket problem vi skulle lösa. Vi skulle utveckla en typ av  tjänst som kunde leverera data till kunder på ett nytt och modernt sätt. Och vi hade bara några veckor på oss. Hur ska vi egentligen hinna göra något på sådan kort tid tänker jag?

Jag märker snabbt att vi i teamet hamnar i diskussion kring lösning. Det blir mycket prat om teknik. Vi vet egentligen inte vilket problem vi ska lösa. Så vanligt, eller hur? Jag ber om att vi gör detta på ett annat sätt. Jag pratar med några användare, ber dem förklara vad de behöver och hur de jobbar med den data de behöver. Jag återkommer till teamet. Ber om att vi sätter upp en webbplats, en så kallad ”hello world”. Vi lägger till en knapp där det står ”Ladda ner data”. Vi testar med kunden, de blir väldigt glada. Vi lägger till en logotyp och en kort text hur man arbetar med materialet. Vi är klar. Vi kan stänga projektet någon vecka innan tiden är slut. Allt prat om att vi skulle ha massor av lösningar, filtrera data, olika målgrupper, massor av hjälptexter. Inget behövdes.

Vad vill jag säga med denna berättelse? Vi fastnar ofta i analysfasen. Vi vågar inte definiera vilket problem vi ska lösa. Vi är inte överens om varken problem eller lösning. Vi lyckas inte flytta komplexa, och komplicera problem till att bli enkla.

Skapa ett gratis konto för att fortsätta läsa