1. Stöd lärande

Mjukvaruutveckling är en läroprocess. Vi vet inte från början hur slutresultatet kommer se ut. Därför rekommenderar vi åtgärder som stödjer lärande och hjälper alla som arbetar i ett öppna data- projekt att ta till sig och förstå det som byggs. Till exempel är det bra att dela upp arbetet i små delar, så kallad agil systemutveckling, för att underlätta inlärning av svåröverskådliga frågor.

Omfattande och komplexa satsningar bär alltid med sig ett visst mått av osäkerhet, och planering är en förutsättning för att hantera problem. I den fysiska världen gynnas projekt ofta av detaljerade specifikationer och utförliga tidslinjer som gör projektarbetet så förutsägbart som möjligt. It-projekt rymmer dock en annan dynamik och vid skapandet av ny it- infrastruktur kan den klassiska, detaljerade planeringen skapa fler problem än den löser.

Agil systemutveckling

IT-branschen använder olika metoder för att kunna leverera kvalitet i tid. Den kanske mest kända och beprövade metoden kallas agil systemutveckling och bygger på idén att projekt delas upp i små, testvänliga delar där framstegen granskas och justeras kontinuerligt. Våra rekommendationer utgår ifrån dessa idéer och applicerar dem på arbetet med öppna data.

Att dela upp stora projekt och arbeta med små, avgränsade delar är kontraintuitivt för många människor. Vi har växt upp i en värld där noggrann planering och förutbestämda processer tagit oss ända till månen. Men månlandningarna var inte resultatet av den traditionella arbetsmodellen. NASAs personal arbetade i en mängd små iterationer, diskreta steg med tester i varje skede och väldigt många misslyckanden som formade den fortsatta processen. I mjukvarusammanhang pratar man om test-driven utveckling och det har blivit en sorts branschstandard.

Varför ska vi bry oss om detta?

Formulera nyttan med varje delmoment. Svara på frågan "Varför ska vi bry sig om detta scenario?" Lärande är mer effektivt när du som lär dig vet varför du ska bry dig om frågan. Fördelen/ nyttan ska presenteras före det som ska läras. Annars ägnar vi mindre uppmärksamhet åt att förstå och minnas. För att hitta en bra "varför" kan ni använda Varför-Och-VemBryrSig- metoden. Den funkar så här. Beskriv det som ska förklaras och låt en annan person fråga "Varför ska jag bry mig?". Svara och låt den andra personen fråga "Och?". Nu börjar du bli irriterad och svarar på ett nytt sätt. Då säger den andre personen "Vem bryr sig?". När du svarat på den frågan borde du ha en bra anledning till varför just det här är viktigt att förstå.

Använd grafik

Människor är visuella varelser. Våra hjärnor har mycket lättare att ta in och bearbeta diagram, grafer, teckningar och foton än bara text.

Beskriv saker ur flera perspektiv

Upprepa det du sagt men på olika sätt till exempel med ett citat, en bild eller en fråga.

Flexibilitet eller avslut

Den svåraste utmaningen i it-projekt är inte att ta bort osäkerhet i förväg utan att anpassa till osäkerheten i takt med att den blottläggs. För att förstå varför det är så kan det hjälpa att se på it-projekt som två korsande linjer, en för flexibilitet och den andra för färdigställande/ avslut. Vid projektstart har vi hundra procent flexbilitet och noll procent avslut. Vid projektets slut är förhållandet omvänt. För varje beslut som genomförs minskar flexibiliteten och färdigställandet ökar.

Planen kan till och med göra det svårare att upptäcka och åtgärda fel. Överdrivet detaljerad planering minskar flexibiliteten innan det är nödvändigt vilket gör det svårare, inte lättare, att hantera oförutsedda problem som alltid uppkommer. Ju större ett it-projekt är desto mer sannolikt är det att oväntade problem uppstår. För att undvika sådana situationer krävs helt andra metoder än i traditionella projektarbeten.

Okunskap är den största flaskhalsen

Varför ska du bry dig om detta? Varför kan inte IT- konsulter ta hand om det tekniska och ta emot beslut från myndighetspersonal?

Problemet är att det saknas förståelse för mjukvaruutveckling i myndigheters och kommuners ledningsrum. När ett öppna data- projekt diskuteras behöver både utvecklare och ledning förstå tekniken tillräckligt väl för att kunna bedöma om projektet rör sig i rätt riktning. Först då blir kritiken konstruktiv och arbetet produktivt.

Den verkligt stora utmaningen är alltså att införa regelbundet lärande om IT på ledningsnivåer i offentliga organisationer.