Krav är som miljön och IREB är som miljöskyddslagen

Visst kan man till viss mån värna om miljön utan att det ska behöva finnas lagar, förordningar och regler. Alla människor tycker ju om ren luft och rent vatten och vill hellre se grönska än grå betong utanför sina fönster. Inte heller finns det några miljöpsykopater, som blir glada när det förorenar och skräpas ned med flit. Utan dessa besvärliga och ganska tråkiga lagar (försök exempelvis lusläsa ”Svensk författningssamling 1969:387”!) blir det dock lätt helt fel och miljön förstörs utan att någon egentligen vill det.

Samma sak gäller krav, både affärskrav och systemkrav. Man kan till viss mån lyckas att fatta bra affärsbeslut och bygga bra IT-system utan att det måste finnas utpräglade projektaktiviteter som heter kravinsamling, kravanalys och kravvalidering. Alla tycker bättre om smidiga arbetsflöden och lyckade satsningar, och vill hellre se fina IT-tjänster än https://javlaskitsystem.se/. Det finns inte heller så många projektpsykopater som trivs bra förrän det råder riktigt kaos och system sjösätts under dramatiska former i sista minuten. Utan dessa besvärliga och ganska tråkiga normer (försök till exempel lusläsa ISO/IEC/IEEE 29148:2011 ”Requirements Engineering Standard”!) blir det lätt helt fel i projekt trots att alla gör sitt bästa för att det ska bli bra.

Vi människor är duktiga på att dölja sanningen bakom fasader – alla kulturer baseras på denna kunskap. Samma sak händer ofta med kravhantering. Ju mer man tror sig veta att man minsann inte behöver någon specialaktivitet för att ta hand om sådana självklarheter som projektmål, systemfunktionalitet eller produktbacklogg desto mer säker blir jag på att mycket kravarbete faktiskt pågår, fast under ett annat namn.. En gång fick jag höra att kraven var ”arkaiska” när man kör med kontinuerlig integration och leverans, och motsatsen är ett faktum: för att uppnå hög leveranstakt och en värdedriven releaseplanering krävs mycket smidigt kravfotarbete.

Kravarbete går under många olika öknamn som ”förfining av produktbackloggen”, ”specification by example” eller BDD i den agila världen. Det försvinner i projektledningens avgrund inne i PMBOK, eller ges kraftig mindervärdeskomplex i BABOK som en lillebror av det stora och prestigefyllda verksamhetsanalysen; sist men icke desto minst, uteblivna eller bortglömda krav tar man hand om som sista åtgärd av testare, speciellt inom ramar för utforskande testning.

Det är inget självändamål att lyfta fram kravarbete och systemkrav till en mera prominent plats, det är inte fråga om prestige utan det handlar främst om effektivitet och lönsamhet. Det helt enkelt lönar sig att ta hand om krav på ett ordentligt sätt och att använda de rätta begreppen som främjar raka budskap.

För drygt tjugo år sedan insåg man samma princip vad gällde testning. ISEB, och sedan ISTQB testcertifieringar startades. De har blivit så populära att idag har fler än en halv miljon människor skaffat sig sådana. Man har lärt sig att visst går det bra ibland att uppnå bra kvalitet med testning inbyggt i andra aktiviteter, men det går mycket bättre när testningen betraktas som delvis separat, självständig disciplin och kunskap. Det är dags att uppnå samma mognadsnivå vad gäller krav och kravarbete.

IREB certifieringsschema kan hjälpa oss ordentligt på vägen dit. Personligen, har jag ingen överdriven entusiasm för certifieringar som sådana, men vissa självklara fördelar har de: de skapar ordning och reda, alstrar referensramar, gör ordning på terminologin, och framför allt, skapar en solid, heltäckande bas för alla. Först när du behärskat den, blir det fritt fram att kritiskt granska och komma med bättre idéer.

IREB schema är dessutom riktigt bra skapat av både industrispecialister och akademiker, erfarna människor som vet vilka kunskaper deras och andras projekt behöver.


I mitt nästa blogginlägg tänker jag beskriva IREB huvudpelare i detalj: idag får en ritning räcka till 😊. Hej då!




Bogdan Bereza
Programmerare, testare, psykolog, kvalitolog, verksamhetsanalytiker, traditionsälskare, agil-entusiast och utforskare. Pragmatisk, drömmare och visionär, allt i en och samma person. Han blandar gärna testning med kravarbete, mixar agila och utforskande metoder med försiktig förebyggande planering och kopplar ihop praktiskt projektarbete med bokskrivandet och undervisning. Hans elever tycker om honom för hans förmåga att göra svåra ämnen lättbegripliga. 



Skicka en kommentar

Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.