Met een Programma van Eisen geef je als opdrachtgever aan, aan welke eisen en randvoorwaarden het te ontwikkelen systeem moet voldoen. Je wilt voorkomen dat de bekende schommelkarikatuur ook van toepassing wordt op je project. Dat bereik je door te zorgen dat je zelf goed weet wat je wilt, door je eisen helder te communiceren en tevens door op tijd te controleren of alles aan je eisen voldoet.
Om de schommelkarikatuur te verslaan moet een Programma van Eisen drie basisingrediënten bevatten. Deze drie basis ingrediënten versterken elkaar en vormen gezamenlijk een ijzersterk recept.
-
Om te zorgen dat je zelf goed weet wat je wilt heb je een concreet beeld van de gewenste situatie nodig. Dat beeld moet je geleidelijk opbouwen. Het lukt je niet om dat vooraf (voordat de bouw van het systeem is gestart) in de volle breedte en met alle details te overzien.
Voor het Programma van Eisen betekent dit dat je het in delen oplevert of beter gezegd dat je het project opdeelt in kleine deelprojecten. Voor ieder deelproject stel je een mini-PvE op tijdens het voorgaande deelproject. Je begint met de kern van het systeem en bouwt dat met iedere mini-PvE verder uit. Op deze manier hoef je niet alles vooraf te bedenken, maar borduur je voort op de software die in eerdere deelprojecten is opgeleverd.
-
Om je eisen helder te communiceren aan het ontwikkelteam is tweerichtingsverkeer noodzakelijk. Dat is namelijk de enige manier om erachter te komen of je eisen duidelijk zijn en goed geïnterpreteerd worden door de ontvanger.
Voor het Programma van Eisen betekent dit dat je een groot deel mondeling overbrengt en daardoor niet alle details schriftelijk hoeft vast te leggen. Alleen informatie waarop je later terug wilt kunnen grijpen moet expliciet vastgelegd worden. Hoe vaker je mondeling contact hebt met het ontwikkelteam, hoe minder details je hoeft vast te leggen. Bovendien is het veel eenvoudiger om mondeling uit te leggen wat je wilt en hoor je meteen of je boodschap correct overkomt.
-
Om zinvol te controleren of de software aan je eisen voldoet moet je zorgen dat je ruimte hebt om bij te sturen. Het gaat er namelijk om dat je (uiteindelijk) een systeem opgeleverd krijgt dat volledig aan je wensen voldoet. Daarop controleren is belangrijk, maar alleen als er daarna ook ruimte is voor herstelacties komt het perfecte systeem dichterbij.
Voor het Programma van Eisen betekent dit dat de bijbehorende acceptatietesten vroegtijdig moeten worden uitgevoerd. Hoe eerder en hoe vaker je test, hoe eenvoudiger en minder kostbaar het is om de software aan te passen. Voer daarom niet alleen acceptatietesten aan het eind van ieder deelproject uit, maar geef ook tussentijds feedback op schermprototypen en nog in bewerking zijnde onderdelen van het systeem.
Kortom, participeren tijdens de ontwikkeling van de software is effectiever dan vooraf een omvangrijk en gedetailleerd Programma van Eisen opstellen.
Nee brombeer,
Documenteren en vastleggen heeft een zeer slechte business case en is gewoon verspilde moeite. Ik documenteer veel omdat het een vereiste vaak is. Maar ik stop in *al* mijn documentatie woord grapjes en de belofte van gebak als je mij een e-mail stuurt. Ik heb nog *NOOIT* gebak hoeven brengen.
Documentatie moet vanzelf ontstaan en terugvindbaar zijn. Een soort logisch gevolg van communicatie. Maar het vastleggen om het vastleggen is redelijk zinloos.
Belangrijke mensen in het proces/software wat je beheerd hebben vaak wel de kennis of kunnen je in de juiste richting wijzen.
Brombeer zeg nu eens eerlijk: Zo te horen heb je vaak bij gebruikers moeten re-engineeren wat ooit de bedoeling was. Heb jij dat toen netjes gedocumenteerd? En heeft ooit iemand dat gebruikt? Wel eerlijk zijn heh!
De praktijk is dat het re-engineeren af en toe minder kost dan alles achteraf te documenteren met de grote kans dat het toch weer achterhaald is. Kennis moet organisch ontstaan (gecodificeerd of personaliseerd), kunstmatig pielen omdat het moet… ik geloof er niet in.