meerwerk

Het is een bekend verschijnsel in de IT wereld heb ik begrepen. Opdrachtgevers die bij gebrek aan inzicht in de complexheid van hun opdracht eindeloos blijven hameren op onbelangrijke details. Er woedt zelfs een discussie op het net over dit fenomeen waarbij teruggegrepen wordt op een voorbeeld uit de zestiger jaren. Toen werd al geconstateerd dat het veel eenvoudiger was om toestemming te krijgen een complexe atoomcentrale te bouwen dan een beslissing te bereiken over de bouw van een fietsensschuurtje [http://bikeshed.org/].

Ook ik grijp tijdens mijn verzuchtigingen over mijn werk graag terug op de bouwwereld. Ik probeer mijn toekomstige gebruikers uit te leggen dat we gezamelijk een huis aan het bouwen zijn, maar kom vaak niet verder dan een discussie over de kleur van het behang. Vaak hoor ik dat ik in dit soort gevallen moet kiezen voor een pragmatische opstelling. Laat de gebruikers ruzieën over de behangkleur en bouw ondertussen het huis zoals jij denkt dat het goed is. Er schuilt echter een groot risico in deze benadering, want zodra de bewoners het nieuwe pand betrekken weten ze feiloos wat ze anders hadden gewild.

Er zijn veel ontwikkelaars die geen moeite hebben met de harde opstelling waarbij alle nieuwe wensen die tijdens of na het bouwen op tafel komen zonder pardon als meerwerk worden bestempeld.  Dan hadden ze maar eerder en beter moeten nadenken over wat ze nu precies willen. Zij hebben geen boodschap aan het feit dat de meeste eindgebruikers geen flauw idee hebben van wat ze willen tot ze het zien. Ik vind eigenlijk dat je als ontwerper en bouwer van IT systemen heel nauwkeurig moet kunnen inschatten welke wensen en eisen je gebruikers in de  loop van het proces waarschijnlijk nog zullen formuleren. Bovendien moet je sowieso zorgen voor generieke oplossingen met grote flexibiliteit waarin late aanpassingen betrekkelijk eenvoudig zijn in te passen.

Verreweg de beste aanpak is het zo snel mogelijk bouwen en tonen van versies die het ook werkelijk doen. Op die manier bereik je sneller het stadium waarbij je goed kan inschatten wat de gebruikers eigenlijk willen en wat op den duur wel of niet gaat werken. Fail early and fail often is het bekende moto voor deze manier van ontwikkelen. Het is de aanpak zonder uitgebreide analyses en brainstormsessies vooraf, maar met mogelijk een grote betrokkenheid van de gebruikers en minder meerwerk.