Wanneer is klaar ook echt klaar?

 
06 mei 2009

Vaak zeggen developers dat ze klaar zijn als ze geen nieuwe features meer hoeven toe te voegen en de applicatie niet meer bij het eerste de beste zuchtje omvalt, maar in praktijk zijn we dan soms nog langer bezig met de applicatie opleveren dan we nodig hadden om op dat punt aan te komen.

Hoe bepalen we dan wanneer we echt klaar zijn? En hoe zorgen we dat we opleveren wat de klant wil, zonder er 3 keer langer over te doen dan oorspronkelijk begroot?

De oude manier van vaste features, budget en planning lijkt me niet meer van deze tijd. Als je al een van de drie haalt, is het resultaat vaak niet wat de klant uiteindelijk had gewild. Met de gemiddelde agile ontwikkelmethodiek leveren we in ieder geval iets op wat de klant nodig heeft, maar of we dat binnen tijd en budget kunnen doen is vaak afhankelijk van de wil van de klant om met minder features genoegen te nemen. De eerste klant die daar blij van wordt, moet ik echter nog tegenkomen.

Wat kunnen we dan doen? Leggen we budget en tijd vast in het contract met de klant en laten we features variabel? Als ontwikkelaar weet je dan zeker wat je krijgt voor je tijd, maar je klant zal misschien met een bekocht gevoel vertrekken (als hij of zij al een dergelijk contract aan durft te gaan). Commiteren we ons in de afspraak met de klant aan een vast omlijnde set van features? Geheid dat daar op dag 2 al aan getornd moet worden, omdat de lijst niet meer strookt met de werkelijke wens van de klant.  Spreken we een fixed budget af en laten we de bom barsten als de bodem daarvan in zicht is? Niet iets waarmee je je klant uitnodigt om vaker terug te komen.

Zijn er nog andere ideeen over hoe je met je klant kan afspreken wanneer je klaar bent, zodanig dat beide partijen daar mee kunnen leven? Is dat wel af te spreken op het moment van contract onderhandeling? Wil je liever een korte discovery fase waarin je een beter beeld kunt vormen van het totale project? En hoe doe je dat dan met klanten die niet willen betalen voor die 1 a 2 weken die je daarvoor nodig hebt?

Of laat je de criteria om vast te stellen dat je klaar bent met je project juist expres wat vaag aan het begin en werk je die, samen met het eindresultaat van het project, steeds verder uit? Met alle risico’s van overschreiden van budget en deadlines van dien?

Op veel van bovenstaande vragen en overwegingen kan ik geen eenduidig antwoord bedenken en heb ik dat ook nog niet van anderen te horen gekregen. Tot die tijd blijf ik dan maar hopen dat ik niet al te ver na de deadline iets kan opleveren waar de klant iets aan heeft en blij mee is en ik als developer er nog iets aan over hou en niet al te veel onbetaalde nazorg aan heb.


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Project- & procesmanagement, Development


Reactie

  • Thomas,

    Correct gesteld en volgens mij zijn er geen eenduidige antwoorden. Een lijstje met zaken die (in mijn optiek) kunnen helpen het doel te bereiken kan ik wel geven:

    – Verwachtingsmanagement bij de klant. Als er eenmaal gewerkt gaat worden aan een stuk software is het zo dat in het begin vrij snel veel opgeleverd kan worden. Communiceer duidelijk wat wel en niet testbaar is, anders is bij een eerste opleverincrement meteen het vertrouwen in de stabiliteit weg.
    – Stel per ontwikkelincrement (sprint / iteratie of hoe je het maar wilt noemen) vooraf vast welke acceptatiecriteria gelden en maak hier een priorteitenvolgorde in. Voor deze acceptatiecriteria zou je iets als MoSCoW kunnen gebruiken.
    – Zorg voor voorspelbaarheid in je ontwikkelproces / ontwikkelstraat. Zet vooraf een degelijke en *ingeperkte* structuur neer en houd de ontwikkelaars hieraan. Code reviews, test-driven benaderingen en dergelijke kunnen hiertoe bijdragen. Daarnaast biedt een methode als SCRUM iets moois voor de planbaarheid, namelijk commitment van het team. Als er door het team iets wordt gepland committeren ze zich er in principe aan. Dit legt een noodzakelijk stukje verantwoordelijkheid bij de teamleden die het moeten maken.
    – Naast commitment van het team is ook commitment van de klant noodzakelijk. Als je een vorm van agile ontwikkeling kiest zal een klant er zelf ook veel tijd in moeten steken (om aan te geven wat hij wil en aan te geven of hij heeft gekregen wat hij had gewild). Vuistregel voor mij is als een klant voor een relatief groot project (3 maanden of meer) niet minimaal wekelijks kan afstemmen is er een probleem.

    Geplaatst op 10 mei 2009 om 8:48 Permalink