feb
20
2009

Domeinverkenning – echt

De afgelopen weken waren weer mooi! Twee weken echt domeinmodelleren. Het goed leren kennen van de taal en het bedrijfsproces van een nieuwe klant. Ik heb het altijd leuk gevonden om zo’n fase door te maken en je krijgt niet alle dagen de kans om dat voor twee volle weken te doen op lokatie van de klant.

Voorbereiding, uitvoering en afronding van deze fase duurde natuurlijk nog wel wat langer dan twee weken and uiteraard had ik veel hulp nodig van collega’s. Een flinke investering voor een nog niet gecontracteerd project, ook al is het project het zeker waard om zoiets te doen. Gelukkig was de klant bereid om ons te betalen voor deze modelleerfase. Dit maakte het mogelijk om het op de juiste manier te doen, met een sessie om de visie te bepalen, domeinmodelleringssessies en opgenomen interviews met gebruikers van het oude systeem dat vervangen moet worden. En alles gedocumenteerd in vier documenten die de visie, requirements, architectuur en planning & proces belichten van het toekomstige project. Natuurlijk moet het daar niet stoppen! Maar onze klant wil een afweging maken van de offerte tegen dat van een concurrent, dus we moeten nog even wachten. Maar alles lijkt goed te gaan.

We hebben een agile offerte voor het project gemaakt. Het bevat een opsomming van de kosten voor het hele project, binnen bepaalde bandbreedtes. Daar kun je gewoon niet buiten, een klant moet kunnen zien of het starten van het project ook maar een kans heeft om het waard te zijn. Natuurlijk, werkend op een agile manier, kun je niet alles uitdetailleren. Beter gezegd, dat wil je helemaal niet, om dathet alleen maar tijd en geld kost en het project niet verder gaat helpen. Want tijdens het ontwikkelen gaan dingen veranderen. Dat wil je juist.

Het is een behoorlijke uitdaging om een agile project in te schatten. Maar een klant moet op de een of andere manier zijn beslissing ergens op kunnen baseren. Ik denk dat het belangrijkste is om eerlijk te blijven. Uitleggen waar en waarom je niet helemaal zeker van iets kunt zijn, wat ervoor zorgt dat de kosten hoger of lager uitkomen, wat de veiligheidsmaatregelen zijn om bepaalde afspraken te kunnen halen die je maakt, zoals het halen van een bepaalde deadline. Als je start met oneerlijkheid heeft het project ook nooit een eerlijke kans, volgens mij. En de klant heeft nooit een eerlijke kans om kosten, risico’s en kwaliteit van je voorstel af te wegen. Dit gaat een keer duidelijk worden tijdens de implementatie, transitie- of productiefase. En terwijl het al behoorlijk moeilijk is om een bduf/waterval project op te leveren dat door een acceptatiefase heen komt en later onder de motorkap een zootje blijkt te zijn, is het bijna onmogelijk om dat te doen in een agile project, waar je dat kunstje keer op keer zult moeten herhalen.

Geschreven door Rick | Tags: , , |

Reageren? - Geef een reactie »

Rss feed voor commentaar op deze post. TrackBack URL

Geef een reactie

Powered by WordPress | Aeros Theme | TheBuckmaker.com WordPress Themes

Better Tag Cloud