Häromdagen hörde jag en presentation av en person som jobbar på ett spelföretag. Han sa att de inte arbetar med krav alls. Vad jag hörde var att de inte har den gamla formen av kravanalytiker som sitter och samlar och specificerar allt de kommit fram till, för att sen föda utvecklare med dessa specifikationer. I stället låter de spelutvecklarna testa och experimentera fram olika varianter tills något känns bra. De har också en relativt stor grupp hängivna spelare (användare) som får pröva spelen tills de identifierar vilka som faktiskt är bra och roliga och då eventuellt släpper de spelen. Han sa att endast en bråkdel av spelen faktiskt når ut i produktion.
De arbetar också mycket med test, förutom användningstesten så automatiserar de test av sådant som bara måste fungera gång på gång, typ login och annat. Dessutom har de fasta regler att förhålla sig till, t.ex från API:er (gränssnitt) med tjänster som de använder, t.ex Facebook, Google mfl. Och det är ju bara att följa de gränssnittsspecarna.
I mitt huvud tänkte jag, men! Ni jobbar ju visst med krav! I alla fall enligt min personliga tolkning av vad krav faktiskt är. Det är bara så att ni jobbar mycket mer modernt och snabbt med kravarbete än vad många andra gör.
Det ni gör när ni experimenterar och släpper lös den kreativa sidan hos utvecklarna, testar med spelare och automatiserar gränssnitt och studerar och programmerar utifrån API-specar är ju också krav!
Fast ”Krav” är ett olyckligt ord. Just här använder jag ”krav” som ett samlingsord för alla tekniker, metoder och arbetsuppgifter som leder till förståelse av vad användarna faktiskt behöver och beslut om vad som ska ut i drift eller inte.
”Krav” för mig kan uttryckas muntligt, skriftligt, som en teckning, en modell, en skiss, en dialog, som ett test, som programkod, en första version av mjukvara. Någon sa att den enda sanna kravspecen är programkoden, och det håller jag med om, även om den kanske inte är så läsbar för alla. Programkoden talar faktiskt om för maskinen vad den ska utföra. Det mesta som inte är programkod är tankar och idéer som uttrycks på mer eller mindre luddiga sätt.
”Krav” är analysarbete. Att göra en prototyp av ett spel, eller en tjänst och att låta testa den samt studera och dra slutsatser av resultatet och förbättra eller förkasta är också analysarbete.
Problemet är att ”Krav” är ett så dåligt ord eftersom det associerar direkt till långa kravspecar.
”Krav” kan i min värld vara t.ex:
– En backlog
– Ett experiment eller en prototyp
– En skiss på en näsduk eller whiteboard
– En begrepps/informationsmodell eller domänmodell (vilket ord man nu föredrar..)
– En användarberättelse (user story eller en hel text om kundens resa genom systemen)
– Ett testscenario
– Feedback från någon
– En vision förmedlad av någon (användare, utvecklare, vd, medarbetare, marknadschef, säljare, kundtjänst…)
– Ett kommunicerat mål
– Regler definierade av någon
Jag vill dumpa ordet ”krav” och det är antagligen det vi måste göra för att komma loss från de långa kravspecarnas och användningsfallens bojor. Fenomenet i sig: att analysera, förstå, testa, undersöka, följa upp, visionera & designa försvinner dock inte för att vi dumpar ordet ”Krav”. Det är fortfarande en nödvändighet för att få något värdefullt ut av den mjukvara vi producerar.
Att hej vilt koda utan mål, mening, vision eller feedback vore hrm.. intressant.. att se resultatet av. Jag tror att den här killen från spelföretaget ville säga att de kodade hej vilt och ”kravlöst”, men faktum var att de verkar väldigt strukturerade i sin metod att experimentera och samla in feedback, förstå spelarna och jobba med visioner.
Kravspecifikationen då? Har den spelat ut sin roll?
Ordet i sig, ”kravspecifikation”, måste vi nog också göra oss av med för att bli av med dokument som ingen varken läser eller förstår, förutom den som skrev den.
Specifikationer och dokumentation av olika slag däremot kommer vi fortsätta behöva. I olika grad beroende på hur många beroenden vi har och hur stor vår affär eller verksamhet är. Att publicera ett API/webservice för någon internt eller externt att använda utan någon form av dokumentation blir… svårt för de som ska använda den. Att förvänta sig att mjukvara hos myndigheter, banker eller andra regulerade verksamheter ska anpassa sig till lagstiftning utan någon dokumentation av lagarna blir också.. svårt. Det är också specar.
Att gång på gång undersöka och muntligt sprida affärs- och verksamhetsregler i en stor organisation blir också… svårt. Lyckas man dokumentera dessa regler på ett läsbart och hållbart sätt så kanske man inte behöver så många fler specifikationer.
Problemet med specifikationer är inte att de finns, utan att de är för omfattande, att de snabbt blir inaktuella och beskriver design och andra delar som konstant förändras och att de är svårtillgängliga.
Utmaningen är att specificera tillräckligt lite.
I spelföretagets fall så höll de sina specifikationer i form av automatiserade testfall. Genom att titta i de specarna så förstår man hur spelen fungerar.
Jag har sett verksamheter där man faktiskt har en lätt tillgänglig källa över domänmodellen (informationsmodellen) som uppdateras med exakt vilka koder som betyder vad och vilka regler som gäller.
Det går.
Men kanske går det inte att prata om ”krav” och ”specifikationer” längre. Det för med sig en ryggsäck som vi inte vill ha.
Min ambition är att jobba med både krav och specifikationer utan att prata om dem.
Senaste kommentarer