onsdag 15. juli 2009

Bedre nå slår best senere

En veldig sann blogpost, som samtidig kanskje får ting til å høres enklere ut enn de er: Bedre nå slår best senere.

Jeg har vel knapt vært på ett prosjekt hvor vi ikke har utsatt å gjøre en liten forbedring vi kunne gjort i dag, fordi vi ser at vi kan gjøre en større forbdedring i morgen som inkluderer eller overflødiggjør den lille forbedringen vi kunne gjort i dag. Og da er det jo bortkastet tid å gjøre dagens forbedring. Eller?

Eksempel:

- Ja, variabelnavnene i denne klassen er helt på bærtur, men vi må gjøre en opprydning i flere variabelnavn og bør se alt under ett.

- Ja, dette brukergrensesnittet er helt ubrukelig, men vi skal gjøre en større endring i funksjonaliteten uansett, så da vil vi lage et nytt grensesnitt.

- Ja, denne koden er helt spaghetti, men i stedet for å forsøke å forbedre den litt nå, bør vi kaste den og skrive den på nytt.

- Ja, vi kan løse problemet for kundene nå med denne lille justeringen, men skal vi først implementere noe slikt må vi gjøre det 100% og da må vi også ta med ... (fyll inn det som passer)

Et viktig kontrollspørsmål når slike innvendinger kommer og vil stoppe en forbedring, er: Når er det planlagt å gjøre denne store forbedringen? Hvis det ikke finnes et konkret svar på dette spørsmålet, bør man virkelig vurdere å gjøre forbedringen nå, og så heller leve med at Den Store Forbedringen en gang i framtiden kanskje overflødiggjør jobben.

Veldig ofte er det ikke snakk om mange timene uansett. I hvert fall ikke for å få til en viss forbedring. Og hvor mye taper vi på å ikke gjøre forbedringen her og nå? Altså bør vi gjøre en kost/nytte-analyse som delvis ser bort i fra at Den Store Forbedringen kommer, og ser på nytten ved å løse problemet med én gang uavhengig av hva vi tror vil skje om noen uker eller måneder.

I realiteten er det selvfølgelig ikke så enkelt. Man vil jo gjerne ofte tro på at den store forbedringen er rett rundt hjørnet og snart, snart vil bli inkludert i en iterasjonsplan. Og dessuten har man kanskje så mange forbedringer man ønsker å gjøre at man uansett må prioritere - og da virker det selvfølgelig fornuftig å nedprioritere de tingene som uansett vil bli håndtert på et senere tidspunkt.

Som en tommelfingerregel tror jeg likevel at bedre nå må slå best senere mye oftere enn det som skjer i praksis.