Har vi fel fokus när bygger IT-system?

Man tjänar inga pengar på att bygga ett IT-system. Det kostar att beskriva vad man vill ha, det kostar att bygga och testa och det kostar en massa att förvalta. Vinsten ligger i att IT-systemet används efter att det har byggts. För att maximera vinsten så minskar man kostnader alternativt ökar försäljningen. Det kan i ljuset av detta verka lite märkligt att de flesta IT-system byggs med stöd av systemutvecklingsmodeller och projektmodeller som är helt fokuserade på arbetet under projektets fortlevnad och handlar mycket lite på vad som händer när projektet är slut. Under de femton år jag arbetat med IT i olika branscher och i olika roller har jag sett en del sorgliga misstag upprepas gång på gång utan någon verklig reflektion på varför det gick så fel igen.

1995 då jag började med systemutveckling arbetade vi enligt en klassisk sekventiell modell av vattenfallstyp. De projektledare som var lite mer framåt körde kortare cykler på 2-3 månader som de kallade etapper eller något annat fyndigt. Ju kortare cykler och ju mindre projekt desto bättre resultat. På mitt första jobb arbetade vi hårt med att införa test som en självklar del och lyckades i de projekt jag deltog riktigt bra. Trots våra mycket lyckade projekt fanns det ändå en viss missnöjdhet hos den som hade beställt. Orsaken var att vi saknade kunskap om helheten. Vad hände innan och efter att vårt fantastiska system gjort sitt? En mer aktiv beställare med fokus på vad systemet ska användas till i drift och dagliga möten, gärna korta, hade gjort underverk. De senaste fem åren har jag istället sett de verkliga användarna och verksamhetsspecialisterna bli färre och ägna mindre tid åt projekten. Med argumentet att organisationen ska slimmas sitter ansvaret för vad som ska byggas nästan helt hos IT-människor som aldrig arbetat med just den verksamhet som systemet ska stödja.

Det jag sysslat med mest är test. Här spretar mognaden rejält mellan olika företag och olika orter. Många förstår fortfarande inte nyttan med test utan ser det som en stor kostnad som ska hållas nere till varje pris medan andra arbetar seriöst på att bygga upp kompetensen inom företaget då man förstått att det lönar sig på sikt. Så ofta som vi läser om IT-haverier i tidningen borde testare vara ett framtidyrke med gott om jobberbjudanden. Visst kostar det att testa men vad är alternativet? I värsta fall att aldrig leverera något system alls, eller att orsaka katastrofala händelser. Oftast är resultatet missnöjda användare, ökade supportkostnader, kaos i förvaltningen och i slutändan minskar det enda vi bryr oss om nuförtiden, nämligen vinsten. Så med argumentet att vi måste spara så förlorar vi istället pengar! Test är viktigt men jag tycker att en del som skriver om test får lite hybris och tror att test ensamt ska lösa alla problem som finns. Tiden är knapp som den är så testarna har knappast tid över för att även styra projektet, skriva kraven, ansvara för CM-rutiner, skriva användarhandledningar – åtminstone inte allt av de nämnda. Bidra positivt – javisst, men ta ansvaret för – nej!

Vad gäller kravspecifikationer har jag sett allt från funktionslistor till användningsfall. Vissa riktigt bra men andra oanvändbara eller direkt hindrande. För mycket detaljer där de inte hör hemma kan vara katastrof. Lika illa som för lite detaljer där de verkligen behövs. Regelverk, formler, filgränssnitt och fältinnehåll kräver ofta en hög detaljeringsgrad. Andra typer av krav på lite högre nivå kan vara användningssituationer och användargränssnitt där mycket detaljer, förutom att det tar en massa tid att skriva ner, kan hindra effektiv utveckling. Om vi nu misslyckas gång efter annan med att skriva användningsfall på rätt nivå ska vi kanske tänka om och byta mot ett annat format. Det är ju samma problem med testfall – detaljerade stegvisa beskrivningar av funktioner som gör anspråk på att täcka allt. En ljuspunkt i tillvaron just nu är de User Stories som ofta används i agil utveckling.

Detsamma gäller för testfall där mängden text och detaljerade instruktioner ofta dominerar över kritiskt tänkande och realistiska användningssituationer. Här finns en olycklig utveckling där certifiering på inpluggade faktakunskaper med tveksam validitet blivit det främsta kravet för vissa företags anställningskriterier. Ljuspunkten är den växande skaran riktigt duktiga testare som är öppna för förändring och för helheten.

Finns det botemedel? Några idéer som jag har snappat upp och försöker tillämpa så gott det går är:

1)      Test: testdriven utveckling, tidiga tester, verktygsstöd, testdesign för smartare testfall. Sparar stora pengar om det görs bra

2)      Effektstyrning: INNAN vi bygger systemet, fundera på vad det är vi ska åstadkomma, styr sen mott effekterna. Ta kontroll och bli nöjd

3)      Kommunikation: prata med beställarna, prata med utvecklarna, prata med användarna, fråga om det är något du inte förstår. Det är inte säkert att du får veta allt trots detta men du kommer en bit på väg

4)      Användbarhet: lätt att lära, svårt att göra fel, bra dokumentation och mycket annat. En av grundstenarna till nöjd användare är interaktionsdesign och användbarhet – så mycket mer än bara test i slutet av projektet.

5)      All övriga kvalitetsfaktorer: säkerhet, prestanda, förvaltningsbarhet. Tänk på dessa innan produktionssättningen

6)      Sluta göra det som inte fungerar!

Den viktigaste slutsatsen jag drar är att det inte borde finnas IT-projekt alls. Allt är verksamhetsprojekt där IT kan vara en viktig del. Som det fungerar idag så verkar de faktorer som är viktiga för billig förvaltning – robusthet, användbarhet, prestanda etc. – för det mesta ignoreras. Botemedlet tror jag är att börja studera de kostnader som finns i förvaltning och försöka uppskatta vad bristande förarbete, kravhantering och test kostar.

En sammanfattande bild. Sänk kostnaderna och höj intäkterna under förvaltningsfasen – inte direkt raketvetenskap – men det verkar vara svårt att få till på ett bra sätt. Ja, projektstyrning är viktig men i den ingår att ha som mål att systemet ska vara billigt i drift. Att som idag bara fokusera på tid, resurser, funktioner och test av dessa leder in oss på fel spår.

trfocusstor

About Torbjörn Ryber

Torbjörn Ryber
Grundare Fearless Consulting

Problemlösare, testare, egen företagare. Arbetat inom IT sedan 1995 efter fem års studier till civilingenjör i datateknik. Numera konsult, föreläsare, kursarrangör och åsiktsmaskin. Gillar the Context-driven school of testing.