Snygg lösning på fel problem

2005-04-18 09:18 sista ordet

Många anser att om utvecklade program leveras i tid så är projektet lyckat. Om programmet dessutom inte kostar mer än beräknat så har projektet lyckats ännu bättre. 

Jag har dock varit inblandad i projekt som varit både försenade och kostat för mycket, men som ändå blev lyckade därför att kunden fick ett system betalade sig snabbt, vilket gjorde kunden väldigt nöjd (till slut). 

Så hur man än vänder och vrider på det så måste man nog säga att det ultimata testet om projektet är lyckat ofta beror på om kunden är nöjd eller ej. 

Så hur gör man för att utveckla program som gör kunden nöjd? 

Nyckeln är att förstå vad som är viktigt för kunden. Som utvecklare är vi ofta kreativa och är bra på att komma fram med lösningar. Saken är dock att vi tenderar att ta fram snygga lösningar på fel problem.

Det kan ställa till med svårigheter. 

Ett exempel: 

Vi startade ett projekt för att utveckla ett verktyg för att analysera källkod. Vi anställde en smart programmerare för att göra jobbet. Kunden förklarade för programmeraren hur det var tänkt att verktyget skulle fungera och vilka funktioner som var viktigast. Programmeraren var kreativ och föreslog snart en rad tilltalande funktioner. Kunden tackade för förslagen, funderade en stund och meddelade att detta var funktioner som inte var nödvändiga. Funktionerna skulle därför inte införas. 

Programmeraren blev mycket upprörd och förklarade att kunden skulle få funktionerna i stort sett gratis eftersom grovjobbet redan var gjort. 

Kunden blev nu också upprörd och ansåg att programmeraren skulle fokusera på de funktioner som var viktigast, inte de som var enklast att implementera. 

 Diskussionen slutade med att vi enades om att programmeraren kunde föreslå funktioner, men att kunden är den som bestämmer vilka funktioner som ska införas och i vilken ordning. 

Faktum är att vi har tillämpat denna princip mer och mer därför att den gör alla inblandade nöjda. Vi anordnar arbetsmöten där varje kundrepresentant (inklusive slutanvändare) får berätta vad som är viktigast för dem. 

Vi skriver ner alla önskemål så att inget önskemål glöms bort. Om ett önskemål är oklart så diskuterar gruppen tills alla förstår vad det innebär. 

När alla önskemål är nedskrivna så är det utvecklarnas tur att bedöma hur mycket arbete varje önskemål medför. 

När kundrepresentanterna vet hur mycket varje önskemål kostar så är kan de prioriterera och välja vilka önskemål som ska genomföras inom den utsatta tidsramen. Mötet avslutas när kundrepresentanterna har enats om en lista med krav som ryms inom tidsramen. 

När kraven är genomförda så träffas gruppen igen för ett nytt möte då implementeringen utvärderas och nästa omgång önskemål och krav planeras på samma sätt igen. 

Det första mötet kan vara trevande, men efter ett antal möten formas en gruppkänsla som gör att de flesta känner att projektet är på rätt väg. Förklaringen är att kundrepresentanterna känner att utvecklarna lyssnar och förstår vad som ska prioriteras. Utvecklarna får dessutom en känsla för vad som är viktigt och behöver inte ägna dyrbar tid åt att införa funktioner som inte behövs. 

Det som kanske är mest slående är att principen är enkel. Den är inte ny eller revolutionerande heller. 

Jag har varit med i projekt på Ericsson där man tillämpade detta med stor framgång. Kent Beck förespråkar något liknande för kravhantering i Extreme programming. 

Den enda haken är att man måste ha tillgång till kundrepresentanter, vilket kan vara ett nog så svårt problem och får bli ämnet för en annan krönika.

Mikael Lindvall