Idag förklarar vi vad vattenfallsmodellen för utveckling av datorprogram är, och varför den är en sådan katastrof inom offentlig sektor.
Vem är med under utvecklingsfasen?
>Alla som utvecklat större mjukvaruprojekt vet att de tar form över tid, genom testning mot användares faktiska beteende. Att utveckla agilt innebär att sjösätta funktioner efterhand som de blir klara, att användare är delaktiga genom att prova produkten och att man kontinuerligt reviderar projektets struktur utifrån användandets natur. Motsatsen kallas för vattenfallsmetoden. Den innebär att systemet designas, sedan konstrueras, sedan testas och sedan lanseras.
För större projekt där utvecklarna ska producera något som ska användas i en specifik verksamhet de själva inte har kunskap om så är vattenfallsmetoden en katastrof. Trots detta används den för nästan all svensk offentlig IT. Rikspolisstyrelsens katastrofsystem PUST Siebel är ett annat exempel på när vattenfallsmetoden varit destruktiv. Där valde man efter insålda drömmar från konsulter att byta ut ett väl fungerande system mot ett nytt system. Detta skulle utvecklas färdigt innan det släpptes, vilket ledde till att det var oanvändbart när det väl lanserades. Vissa menar att PUST Siebel totalt kostade Polisen 10 miljarder kronor i försämrad effektivitet. Även om den siffran är långt ifrån sanningen är det uppseendeväckande produktivitetsförluster vi pratar om.
I upphandlingen ställer den offentliga aktören sina krav (kravspecifikationen). Sedan arbetar utvecklarna med att designa och konstruera ett system. Verklig testning – alltså att de som i framtiden faktiskt ska använda systemet försöker använda sig av det – sker egentligen först i samband med lansering, när vattenfallsmetoden används.
”De senaste 15 åren har mycket gjorts för att åstadkomma användbarhets- och tillgänglighetsintegrering i traditionell systemutvecklingsmetodik och på senare år i form av agil (lättrörlig) utveckling och agila utvecklingsprocesser.”
Arbetsmiljöverkets rapport Digital Arbetsmiljö
För sent att åtgärda brister
>Detta gör att systemen lanseras med fundamentala brister som det är alldeles för sent att åtgärda på ett rimligt sätt. Hade användare fått testa systemen tidigt i processen hade man kunna fånga upp bristerna i tid. Hade utvecklare och användare fört dialog så hade design och konstruktion av systemen kunnat anpassas efter hur användarna faktiskt använder dem. När användarna väl kommer in i bilden är dock ofta det enda man kan göra att plåstra över systemens problem, lappa och laga ytan men inte förändra på djupet.
”Redan 2009 lyfte Paulsson fram att antalet skolor som nyttjar lärplattformar ökar men att detta för med sig ramar och begränsningar. Vidare anser Paulsson att det är viktigt att se över orsakerna till begränsningarna och på vilka sätt de kan minimeras. Den vanligtvis redan färdiga utformningen av lärplattformarna har förvisso många funktioner men de motsvarar inte alltid användarnas faktiska behov. I Sveriges Kommuner och Landstings (SKL) nationella handlingsplan för digitalisering av skolväsendet (2019) framgår att när digitala tjänster inte är förankrade och anpassade till användarnas behov utgör det ett hinder vilket hämmar ett ökat användande. Paulsson (2009) menar att även om det är möjligt att lägga till funktioner i lärplattformar, så kallade plug-in eller add-on, så kvarstår systemets svagheter ändå.”
Kyle Howard & Pernilla Söderströms lärarexamensarbete SchoolSoft – ålagd men inte användarvänlig?
Användarnas önskemål hörs inte i tid
>Användarna och deras önskemål kommer tyvärr ofta in i bilden i slutfasen av utvecklingen. 2018 införde Malmö stad lärplattformen Infomentor på samtliga 80 grundskolor i kommunen, utan att någonsin ha frågat vad lärarna ville ha ut av en sådan plattform. När Växjö kommun köpte in frånvarosystemet SAITS deltog en referensgrupp med 60 personer, där bara två var lärare. Ingen frågade på förhand personalen på den kommunala skolan Katedralskolan vad som faktiskt behövdes i personalens vardag.
Några som till skillnad från lärarna ofta är med från början är juristerna, som definierar vilka lagkrav som finns på systemet. Det är såklart bra att man från början är tydliga med att offentlig IT måste följa lagen (även om det ibland verkar som att man ignorerar behovet av personuppgiftsskydd), men när det blir de enda ”hårda” kraven från upphandlaren så vänds utvecklarnas uppmärksamhet från användarnas behov till lagbokens bokstav.
”All utveckling och införande av tekniska stödsystem i en verksamhet påverkar arbetet på en rad olika vis, ofta mycket genomgripande. Arbetsorganisation, arbetsprocesser, kompetenser, kommunikation och samverkan förändras och arbetet ska utföras under nya förutsättningar. Det går helt enkelt inte att undvika. Därför kan man egentligen aldrig prata om renodlad teknik- eller systemutveckling eller införande. Det handlar alltid snarare om verksamhetsutveckling och införande av ett nytt arbete. Slutsatsen blir att de processer enligt vilka de nya digitala stödsystemen utvecklas måste hantera även andra aspekter på arbetet, dess organisation och arbetsmiljön, annars kan inte den potentiella nytta uppnås, man riskerar att införa nya problem och att cementera ineffektiva arbetssätt.
Detta har visat sig vara ett problem och svårare i praktiken än man kan föreställa sig. De traditionella modellerna för systemutveckling innehåller oftast inte alls något stöd för att behandla annat än de mer tekniska aspekterna på systemutvecklingen. Kompetenser om annat än det tekniska, t.ex. arbetsmiljökunskap, saknas i projekten och man har ofta inget mandat att hantera frågor om arbetsorganisation och förändrade arbetsprocesser med mera i förändringsprojekten.”
Arbetsmiljöverketes rapport Digital arbetsmiljö
Digitaliseringen behöver vara öppen och transparent
>För Piratpartiet är det självklart att utveckling av mjukvara för det offentliga borde börja med verksamheten som ska stödjas. När det kommer till lärplattformarna måste man börja hos lärarna och deras behov och sedan involvera dem under hela utvecklingsprocessen. Låt utvecklingen ske öppet och transparent, så att tekniskt kunniga kan bidra direkt till kodbasen och andra kan testa systemet och ge feedback under utvecklingen. Digitaliseringen av Sverige ska vara en öppen och transparent process. I denna fråga står vi nära lärarfacken.
”Vårt grundkrav är att denna typ av hjälpmedel måste utformas i nära samarbete med lärarna och att deras kunskaper ska tas tillvara. Huvudmännen måste lita på lärares kompetens och på deras åsikter om hur systemen fungerar i praktiken. De måste också vara beredda och vidta åtgärder i de delar det inte fungerar.
Johanna Jaara Åstrand, Lärarförbundets ordförande
[…]
Ansvariga måste följa upp och utvärdera hur de digitala lärplattformarna verkligen fungerar. Om lärarna säger att de inte fungerar som tänkt utan bara tar bara tid så borde man pausa användandet av lärplattformarna. Det är inte bara slöseri med tid, de är oerhört dyra också. Därför är det märkligt att lärarna inte har mer inflytande och att man inte lyssnar på dem.”
Som vi tidigare konstaterat präglade vattenfallets värsta sidor utvecklingen och upphandlingen av Skolplattformen. Kravspecifikationen gjordes sex år innan lansering. Man involverade knappt användarna i utvecklingen förrän som testkaniner vid lanseringen 2018-2019. Projektledningen som formulerade kravspecifikation och arbetade med utvecklingen saknade kompetens om verksamhetens natur. Tystnadskulturen gjorde att man inte kunde ta tag i brister som medarbetare identifierade.
Nästa text tittar närmare på idén om lärplattformar som verktyg för kontroll istället för pedagogik.
Du kan ta del av hela serien här: https://piratpartiet.se/skolplattformen/.