Hvad der er bedst og hvad der er godt nok <
En klassisk matematisk opgave går ud på at finde den bedste rute for en sælger imellem en række byer. Det gælder om at planlægge den, så der er mindst afstand at rejse, kortest rejsetid eller andre kriterier, der skal opfyldes.
Det viser sig at være en hårrejsende opgave, der kan tage meget lang tid at løse. Den kræver utallige, gentagne gennemregninger af de samme beregninger, og vil til sidst føre til den ultimativt optimale løsning - den bedste med andre ord.
Det åbenbares dog, at man ved at acceptere det næstbedste - eller noget der er meget tæt på det optimale - kan man forkorte beregningstiden betragteligt. Ikke bare skære lidt af den eller endog halvere den. Næh, det kan tage en brøkdel af den fulde tid, at beregne et resultat er er indenfor få procent af det optimale. Man kan med andre ord finde en rejsetid, der er meget tæt på den korteste, men med et langt mindre ressourceforbrug.
Godt nok er godt nok <
For at systemet skal kunne afgøre, hvornår det er tid til at stoppe beregningerne, skal det vide hvad vi forventer. En typisk beskrivelse af forventningerne kunne være "Når 10 på hinanden følgende beregninger ikke forbedrer resultatet mere end 1 procent, er det på tide at stoppe".
Samme filosofi kunne med stort held benyttes i webprojekter. Ved nøje at beskrive forventningerne til det færdige system - faciliteter, ydelse, skalerbarhed eller andre forhold - kan vi sætte et veldefineret mål for hvornår projektet er tilfredsstillende. Ikke hvornår det er så godt som det kan blive, ikke færdigt, og slet ikke det bedste... men bare godt nok! For godt nok, det må jo være... ja, godt nok.
Se fidusen <
Fidusen er at dette resultat ofte opnås langt tidligere end det bedste. Hvis man stræber efter perfektion, når man meget sjældent sit mål. Og vejen fra et resultat, der er godt nok, til et, der er perfekt, er meget lang.
Den kan passende beskrives med den berømte 80/20 regel. 80 procent af resultatet kan opnås med 20 procent af ressourceforbruget. Med andre ord skal der bruges fem gange så lang tid på, at nå et resultat der er perfekt, i forhold til et resultat der er godt nok. Det er alt for meget!
Man opnår altså store resultater i starten af projektfasen, og kan ganske snart have noget klar. Men så flader resultatkurven ud, og det kræver en stadigt stigende indsats at gøre produktet bedre. Det handler om at standse, når forholdet mellem indsats og resultat er optimalt. Enkelt, ikke?
Beskriv forventningerne <
Som en det af et veldefineret mål for projektet bør man derfor beskrive sine forventninger. Og man skal ikke bare beskrive forventningerne til resultatet, men også til forløbet.
Hvis kunden forventer en daglig telefonopringning, løbende orientering eller indflydelse på bestemte forhold, så skal kunden have det - eller have at vide, hvis det ikke er kan lade sig gøre. Hvis leverandøren forventer, at kunden leverer grafikken, er klar med indhold til prototypen eller står til rådighed til test, så skal kunden have det at vide. Forventningerne skal udtrykkes helt klart, og der skal være enighed. Man skal heller ikke tage ting for givet. Intet er givet med mindre man kender hinanden meget godt. Giv klart udtryk for, hvad der forekommer selvfølgeligt. Det øger sandsynligheden for at forventningerne indfries.
Det lyder måske besværligt og som et ekstra stykke arbejde, men det sparer faktisk mange ærgrelser og tilmed ressourcer. Det viser sig nemlig, at forventningerne ofte er lavere på mange områder, hvor man antog et vist niveau. Det betyder sparet arbejde. Samtidig sikrer man sig at alle ønsker opfyldes - også de små, der ellers nemt kan skabe frustration.
Med andre ord <
- Stræb ikke efter perfektion med mindre det er målet i sig selv
- Styr kvaliteten og mængden efter forventningerne
- Giv udtryk for selvfølgeligheder
- Beskriv forventninger til både mål og forløb
- Begræns indsatsen til det optimale i forhold til et veldefineret mål
- Bedøm resultatet ud fra forventninger - ikke potentielle muligheder