Volgens de klassieke werkwijze van een it-project doe je eerst hard je best om iets te maken wat zo goed mogelijk aansluit bij de ooit geformuleerde klantwensen. Op een gegeven moment ben je daarmee klaar, en moet de klant (vaak de business) je gaan vertellen of ze vinden dat je je werk goed gedaan hebt. Deze laatste stap noemen we dan de acceptatie van je product.
Een probleem wat ik echter heel vaak in de bi-wereld tegen kom is dat de werkelijkheid niet zo eenvoudig is als bovenstaande theorie. Dit heeft een aantal oorzaken.
In de praktijk is het vrijwel onmogelijk om de requirements (de specificaties) van de bi-oplossing 100 procent van te voren te formuleren. De klant is vaak niet op de hoogte van details van het operationele proces die van belang zijn voor implementatie, en dus gevolgen hebben voor de requirements. Een klant is daarnaast ook niet goed in staat (het is immers niet waarvoor hij betaald wordt) om exact zijn wensen te formuleren.
Ook zie je vaak dat gedurende de ontwikkeling van een Data Warehouse de werkelijkheid verandert, dus requirements die ooit zo zeker leken kunnen verschuiven. Ik zie bovendien altijd gebeuren dat zodra een klant de beschikking krijgt over de producten van een Data Warehouse vrijwel meteen zijn informatiebehoefte verschuift.
Uiteindelijk is het doel van je Data Warehouse niet om conform specificaties op te leveren, maar om de business het best te helpen. Dit laatste is natuurlijk veel fuzzier en minder geschikt om je project mee te sturen maar levert je wel de hoogste klanttevredenheid op.
Sommige organisaties verlangen een formele acceptatiehandtekening, maar mijn voorkeur heeft het altijd om een zachte overgang te hebben tussen de development, acceptatie en productie-fasen van een bi-project. Je kunt daarbij nog steeds harde milestones afspreken, dus het geheel blijft stuurbaar.
Op een gegeven moment ben je technisch ver genoeg om de klant er mee te laten werken. Je hebt er in je projectaanpak voor gezorgd dat je iets generiekers en breders hebt gebouwd dan de strikte wensen van de klant. Doordat de klant daadwerkelijk kan werken met de data, zonder dat hij operationeel afhankelijk is van de correctheid van alles kun je er voor zorgen dat de klant meer mee gaat denken. Gaandeweg krijgt de klant een gevoel van de waarde van het Data Warehouse dat verder gaat dan het simpele gegeven dat een rapport wel of niet correct is. Bovendien kan de klant zelf op een gegeven moment beoordelen of, gegeven de inmiddels bereikte betrouwbaarheidsgraad, het geheel operationeel een toegevoegde waarde heeft. In mijn ervaring is dat punt eerder bereikt dan een 99 procent betrouwbaarheid.
Hoe is de ervaringen hiermee bij collega's?
In Computable 21 van 21 oktober jl. werd dit artikel ook geplaatst. Dhr. Van Zutphen gaat in op de formele acceptatiestest en problemen die in de bi-wereld daarmee samenhangen.
Een formele (gebruikers)acceptatietest dient om de klant, de business te laten vertellen dat de ontwikkelaars hun werk goed hebben gedaan. Na die constatering kunnen de ontwikkelaars van hun taak ontheven worden en kan het product overgedragen worden naar productie. Een acceptatietest is dus geen doel, maar een middel om samen, ontwikkelaars en (een vertegenwoordiger van de) eindgebruikers, vast te stellen dat het product gereed is om te gebruiken.
Hoe het bewust ingeplande en gezamenlijk gehouden evaluatiemoment genoemd wordt lijkt me niet zo belangrijk. Het kan een acceptatietest heten zoals in de klassieke aanpak of een ‘sprint review meeting’ bij een Agile-methode als Scrum.
Dat zo’n gezamenlijk evalutiemoment plaats vindt lijkt me wel belangrijk. En als, zoals dhr. Van Zutphen stelt, dat mogelijk is zonder formele acceptatiehandtekeningen, maar met afgesproken harde ‘milestones’ dan is dat m.i. prima. Ik vraag me dan wel af waaruit die harde milestones bestaan? En hoe vastgesteld wordt dat zo’n milestone bereikt is (toch niet via een formele acceptatietest)?