Januari 2012
Ett inlägg om krav av Micael Åkesson, kravkonsultpartner till Nohau
Efter ett antal år i branschen som kravhanterare och teknisk projektledare har jag fått den stora äran att leverera ett antal tankenötter och reflektioner.
Jag surfar runt på ett antal siter för att hämta inspiration och läser av tidens strömningar, när det gäller kravhantering och mjukvaruutveckling. Modeorden haglar Lean, Scrum, Agile, Kanban, effektstyrning och testdriven utveckling. Brist på kunskaper och erfarenheter saknas knappast. Men varför havererar ändå många projekt? Frågan är inte retorisk. Är det ont om smarta människor med kompetens och engagemang? Nej, jag brukar istället hävda att som man bäddar får man ligga.
Kravens status i projektet
Låt oss fokusera på flödet. Ja, vad är fundamentalt i början av detta? Svaret är krav. Men varför glöms krav ofta bort? I effektstyrning har man döpt om krav till Action eller åtgärd. I Agile och Scrum fokuserar man på krav i utvecklingsfasen. Tongångarna brukar vara i olika utvecklingsprojekt: Usch… måste vi skriva en massa krav som ingen ändå kommer att läsa. Det är lika bra att sätta igång och koda på direkten, sedan kan vi fixa fram kraven… Kanske beror detta förhållningssätt på att krav är ett komplicerat område som hanterar stora och komplexa mängder information. Samtidigt ökar pressen på projekten att snabba upp utvecklingstiden. Dessutom har komplexiteten i produkternas funktionaliteter vuxit lavinartat. Utvecklingen av mobiltelefoner är ett bra exempel, där telefonboken snabbt fick sällskap av olika mediafunktioner, såsom video-/musikspelare. Lägg därtill en mördande konkurrenssituation.
Var realistisk och förbättra i små steg
Om man funderar på vad som är basalt i kravhantering, brukar jag framhålla ett antal punkter; Scope, Acceptanskriterier, kravdatabas och att koppla krav till Test Case. Men detta känner vi ju redan till. Vad är det egentligen som ger den bästa affärsnyttan? Handlar det helt enkelt om att återkoppla, så att rätt saker levereras? Hur skapar vi ett klimat som verkligen gynnar produktivitet, effektivitet och flexibilitet? Finns det ett mantra eller ett trollspö som löser upp alla problem? Här är svaret nej, det finns inga enkla lösningar. Utgå från dina egna erfarenheter och förbättra i små steg. Ständiga förbättringar skapar nya möjligheter. Nu är vi tillbaka i ruta ett. Vem är ansvarig för Scopet i projektet? Det är projektledaren. Men kära projektledare, lös inte alla världens problem. Ta inte in kravet att åka till mars. Var i stället realistisk, försök att balansera alla intressenter och deras krav. Börja med positiv Scope-strategi, inte de-Scoping. I flera telefonprojekt som jag har erfarenhet av, har detta varit ett stort problem. Därför är det viktigt att försöka anpassa Scopet till tillgängliga resurser.
En stötesten är resursallokering, som kan bestå i att organisationen saknar ett enhetligt system för hur resurserna till de olika projekten ska fördelas. Istället är resursallokeringen utspridd till ett antal linjechefer, som brukar använda excelblad. Om organisationen väljer Featureutveckling enligt en Agile metodik, finns resursallokeringen i ett verktyg som är gemensamt för hela utvecklingsorganisationen. Detta är helt verksamhetskritiskt för att få snurr på Featureutvecklingen.
Ta kommandot över Scope och ändringshantering
En annan stötesten när det gäller Scope hantering, är det som kallas för ”Scope creeping”, d.v.s. när Scopet växer okontrollerat. Jag har även erfarenhet att leda Change Control Board (CCB) i flera telefonprojekt. I CCB:et kom det smygvägen in en massa ”nya” krav, som inte var med i Scopet för början. Mitt råd är att vara strikt när det gäller ändringshanteringen. Definiera en budget i mantimmar/kostnad för hur många ändringar som är budgeterade för projektet. Var samtidigt strikt med att ta in ändringar, i annat fall riskerar projektet att inte leverera i tid.
Om du har en leverantör, stäm av med hjälp av Compliance statement, om vad som kommer att levereras i Scopet. Gör en realistisk releaseplanering, så att rätt saker levereras enligt tidplan. Följ upp med Acceptanskriterier. Var noga med kraven, försök hantera samtliga krav i en databas. Genomlys projektet med jämna tidpunkter utifrån kravperspektivet.
Genomlys projektet i tid
Finns samtliga funktionella och icke funktionella krav med i kravmassan? Är alla krav i Scopet omhändertagna i design fasen? Har samtliga krav Test Case? Hur ser Acceptanskriterierna ut? Om projektet jobbar utifrån effektstyrning och sätter användaren i fokus, glöm inte bort Acceptanskriterierna. Försök att kontinuerligt och aktivt jobba med frågeställningarna ovan. Kommunicera det ni gör till alla i projektet. Detta genererar en struktur och ryggrad i varje projekt. Det handlar om enkla basala steg i utvecklingsmetodiken, vilka skapar värden för slutkunden och ger förbättrad precision i projektet.
Hör gärna av dig om du vill fortsätta dialogen!
//Micael