I förvånansvärt många projekt finns dom där. Systemutvecklarna och arkitekterna som hävdar att lösningen på leverans- och kvalitetsproblem både kan och bör lösas genom en detaljerad och fryst funktionsspecifikation. “Om de bara hade specificerat vad som verkligen önskades hade ju vi kunnat göra vårt jobb”, brukar det heta. Du känner säkert igen tongångarna. Eller känner du dig möjligen träffad? I så fall har Tobias Hill något att berätta för dig.
Jag vill börja med att vrida tillbaka klockan ett antal år och projekt och villigt erkänna att även jag på den tiden i varje projektutvärdering ropade efter mer detaljer, mer planering och en fryst specifikation. Hur skulle vi utvecklare annars veta vad som skulle göras? Och hur skulle vi kunna göra ett bra jobb med ett rörligt mål? Som relativt nybakad civilingenjör var ju det den mest rimliga reaktionen – vad visste jag om verklighetens nyckfullhet?
Tyvärr ledde de mer detaljerade specifikationerna sällan till bättre resultat. Mycket tid och möda tillbringades på att göra själva specifikationen och att till slut nå en “sign-off” från beställaren. När väl detta hade skett var det svårt eller omöjligt att bli klar i tid. Till varje detaljerad funktionsspecifikation hör ju som bekant ett lika orimligt detaljerat tidsestimat, och resultatet blev aldrig riktigt så som kunden hade tänkt sig – inte sällan hade behoven ändrats under utvecklingstiden. Med denna verklighet stirrande mig i vitögat blev jag tvungen att överge mitt behov av upplevd förutsägbarhet till fördel för en ny strategi, en strategi för anpassningsbarhet.
Funktionsspecifikationen är en modell av verkligheten. Den är ord, och ibland bilder, på papper som försöker beskriva den applikation som skall byggas. Den färdiga programkoden är även den en modell och beskrivning. Den senare kräver att detaljer uttrycks med hög detaljrikedom och precision. Om vi använder samma detaljrikedom i en tillhörande funktionsspecifikation har vi skapat oss ett onödigt och kostsamt dubbelarbete. Detta dubbelarbete adderar en stelhet som motverkar viljan att hantera sena och i vissa fall stora förändringar. I sämsta fall leder detta till att förändring enbart tas om hand i den ena modellen (läs: programkoden) vilket ger oss det enda som är sämre än en detaljerad fryst funktionsspecifikation, nämligen en missvisande sådan.
En detaljerad och fryst funktionsspecifikation tvingar oss dessutom att ta de viktigaste besluten då vi har minst information. Vi skaffar oss mer kunskap ju mer vi bygger vår applikation och ju mer den används. Det är då vi kan ta de bra besluten och det är då vi kan förfina vår kravbild och därtill hörande specifikation. Att omvänt ta viktiga beslut tidigt leder ofta till att onödiga eller olämpliga funktioner byggs. I detta tidiga skede finns det ingen naturlig vetskap om den kostnad och tid en funktion tar att bygga, eller om den kommer passa i sitt sammanhang. Verkligheten och applikationen har inte fått säga sitt ännu.
Slutligen. Det största problemet med en detaljerad och fryst funktionsspecifikation är att den ger intryck av att vara en heltäckande överenskommelse mellan beställare och utförare. Den ligger där och säger “Hej, psst, du! Alla beslut är tagna redan. Det enda du behöver göra är att till punkt och pricka implementera det som står i mig så kan ingen komma och säga att du inte gjort ditt jobb”. Som sådan blir den en friskrivning, ett sätt att slippa involvera beställaren för att löpande diskutera alternativa och bättre angreppssätt. Den blir ett sätt att slippa ta ansvar för slutprodukten och i värsta fall ett sätt att i ett olyckligt sent skede kunna säga “We were only following orders”.Den samvetsfråga du måste ställa dig som systemutvecklare är om det känns mer rätt att till punkt och pricka implementera en detaljerad och fryst specifikation av en ofullständig idé, eller om det känns mer professionellt att tillsammans med beställaren ta ansvar för att leta fram den lösning som bäst löser dennes problem.
