Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Hvis du, som jeg, har prøvet at eje en gammel bil på et stramt budget, så har du måske også prøvet at få en værkstedsregning af den slags, hvor indholdet giver dig mulighed for at booste din personlige udvikling.
Dels fordi, din horisont udvides, når fakturaen lærer dig om dele i en bil, som du ikke anede eksisterede, og dels fordi et opkog i dit indre følelsesliv skal håndteres, når reparation af delene viser sig at koste mere end bilens samlede værdi - plus moms.
I det øjeblik går det op for dig, at du måske egentlig godt kunne have klaret dig med tre og ikke fem døre i bilen, når nu dørhåndtagene bag åbenbart har det med at sætte sig fast (og her hjælper det ikke, at din velmenende mekaniker mener, at årsagen nok er, at de bruges for lidt …)
Den ekstra motorkraft fra turboen, som bidrog til underholdningen under prøveturen - og ikke mindst bilens pris - er strengt taget heller ikke nødvendig for at dække dit beskedne transportbehov på tilproppede veje i byen. I hvert fald ikke nu, hvor du har lært, hvad det koster dig, hvis turboen brænder af.
Med andre ord: Dine oprindelige krav var ikke alle reelle ifht. dit egentlige behov. Og det kostede dig, da du indkøbte løsningen, og det koster dig nu under den løbende vedligeholdelse.
Og når vi taler it ...
Overført til it-udvikling er pointen, at de suverænt billigste krav at understøtte nu og i fremtiden er de krav, der ikke er der.
Det universelle vidundermiddel som altid giver dig en bedre og billigere løsning er derfor: at holde dine krav i kort snor og i bedste fald fjerne nogle af dem.
Det vil spare dig både under udviklingen og i den efterfølgende drift og vedligeholdelse.
Nu tænker du måske, at det ikke ligefrem er raketvidenskab, og at det på ingen måde giver mening at fjerne krav, da kravene jo netop udtrykker det, som løsningen skal kunne.
Så hvis nogle af kravene fjernes, så vil løsningen ikke komme til at leve op til kundens forventninger og mål med løsningen?
Og det kan du have ret i. Men kun, hvis du lever i en perfekt verden, hvor alle krav er stillet af de rigtige folk med fuld indsigt, komplet overblik og en dyb forståelse af både forretningsbehov og it.
Dette 360-graders overblik skal i øvrigt holdes opdateret til enhver tid i takt med, at den system- og forretningsmæssige virkelighed udvikler sig.
Det er med andre ord en yderst sjælden situation i praksis.
I den verden, de fleste af os i it-branchen lever i, er der derimod andre vilkår, der gør sig gældende.
Krav kan opstå på mange måder, og de har svingende kvalitet. Som gule sedler fra workshops lavet af dem, der lige kunne være til stede på dagen. Som ukritisk overførsel af funktionalitet fra de gamle løsninger.
Som idéer, alle synes er gode, men som aldrig vurderes ifht. reel cost/benefit. Som personlige kæpheste fra interessenter med stort engagement, men kun for en snæver del af løsningen.
Som konkrete løsningsforslag, der ikke er funderet i de reelle behov osv. osv.
Her er det på sin plads at understrege, at jeg ikke ønsker at bebrejde de både dygtige og velmenende mennesker, som hver dag bidrager til den komplekse opgave, det er at få etableret krav til en løsning.
Ovenstående er blot eksempler på, hvordan virkeligheden ofte ser ud rundt omkring, og forklaring på, hvorfor krav sjældent er perfekte.
Krav må derfor aldrig opfattes som hellige - heller ikke når de kommer i hænderne af os arkitekter og udviklere, som skal designe og bygge løsningerne.
Et eksempel
Et eksempel fra den virkelige teknologiverden - og endda den mere kompetente del vil nogen sige - er fra dengang, Tesla skulle starte produktionslinien for deres Model 3.
De havde problemer med monteringen af en fiberdug mellem batteriet og bilens bund.
Efter adskillige forsøg med justering af den milliondyre robot, der skal gøre det, rejser spørgsmålet sig: Hvorfor skal dugen overhovedet være der? Hvorfra kommer kravet?
Der bliver peget på brandsikkerhed som årsag, men det vil de sikkerhedsansvarlige ikke kendes ved.
De peger i stedet på, at formålet må være at mindske støj og vibrationer, hvilket dog afvises af de komfortansvarlige.
De ender derfor med at teste to biler imod hinanden - en med og en uden dug. Da de ikke oplever nogen forskel, fjernes dugen fra designet, og produktionslinien kan forenkles og effektiviseres markant.
Så de er derude, de irrelevante krav. Men hvad kan du gøre for at undgå dem?
Du er først og fremmest bevidst om, at krav sjældent er perfekte og derfor gerne må udfordres og genbesøges undervejs i udviklingsprocessen.
Ja, det bør de faktisk altid blive. Det gælder både, hvis du er kravstiller, men i ligeså høj grad hvis du er udvikler eller arkitekt, da du med din indsigt i teknikken bag ofte kan se muligheder for at skabe en bedre og billigere løsning.
Du er også eksperten på evt. nye tekniske muligheder, som måske ikke har været overvejet, da kravene blev stillet.
Og er du en af de erfarne med et dybt kendskab til funktionaliteten i de eksisterende systemer, vil du på indirekte vis også have en stor viden om den forretning, der skal understøttes, og dermed er du både særligt egnet og særligt forpligtet til at udfordre de krav, der serveres for dig.
Et andet aspekt er den løbende vurdering af cost/benefit for det enkelte krav. Oftest er der opmærksomhed på cost/benefit, når et krav stilles.
Men den vurdering kræver løbende opmærksomhed i takt med, at forståelsen af løsningen udvikler sig gennem udviklingsprocessen - både teknisk og forretningsmæssigt.
For eksempel kan den nødvendige udvikling bag et krav vise sig at blive markant dyrere eller billigere end forventet, når der graves i detaljerne.
Og tilsvarende kan en udvikling i den forretningsmæssige forståelse betyde, at en feature eksempelvis ændrer prioritet, indhold eller bliver helt overflødig.
En sidste pointe er at sikre en tilstrækkelig sporbarhed af de opstillede krav, så det altid er let at finde frem til, hvorfra det kommer.
Dermed kan de rette folk altid hurtigt bringes i spil, når et krav bliver udfordret og skal genovervejes senere i processen. På den måde mindskes også risikoen for, at 'herreløse' krav uden relevans får deres eget liv som i eksemplet fra Tesla.
De gode råd
Så få bedre og billigere løsninger med følgende råd:
- Betragt ikke krav som hellige, men tillad, at de udfordres løbende.
- Hold øje med udviklingen i cost/benefit for de enkelte krav i takt med, at forståelsen af både løsning og behov modnes.
- Sørg for tilstrækkelig sporbarhed omkring kravene, så de rette folk hurtigt kan bringes i spil, når et krav skal udfordres eller revurderes.
Og så vil du endda ofte også sidde med en bedre forståelse af, hvorfor kravet faktisk er vigtigt for løsningen.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.