In een programma van eisen en wensen staan de requirements voor het te ontwikkelen systeem. Bij uitbesteding aan een interen of externe leverancier moet je immers duidelijk maken aan welke eisen het systeem moet voldoen. Opstellen van een programma van eisen en wensen is daarvoor al decennia lang gebruikelijk.

De problemen die opdrachtgevers ondervinden met het uitbesteden van software ontwikkeling zijn ook al tientallen jaren onveranderd. In de bekende karikatuur met de schommel wordt dat treffend geïllustreerd.

Schommelkarikatuur

Hier lees je waarom het mijns inziens niet lukt om de schommelkarikatuur te verslaan.

Programma van eisen en wensen opstellen

Het opstellen van een programma van eisen en wensen is niet eenvoudig. Tenminste als je het over een traditioneel programma van eisen hebt.

Maar het kan ook anders. Er zijn tegenwoordig andere, effectievere manieren om een softwareontwikkeltraject in goede banen te leiden. Voor een doeltreffend programma van eisen moet je slimme manieren vinden om:

  1. De business te helpen hun eisen en wensen helder te krijgen
  2. De eisen en wensen duidelijk over te brengen aan de ontwikkelaars
  3. Op tijd te controleren of de ontwikkelde software aan de gebruikersbehoeften voldoet

Het recept hiervoor bestaat uit drie basisingrediënten. Ze versterken elkaar en vormen gezamenlijk een ijzersterk recept waarmee je de schommelkarikatuur de baas wordt.

1. Concreet beeld gewenste situatie

Om de business te helpen bij het expliciet maken van hun eisen en wensen hebben ze een concreet beeld van het gewenste systeem nodig. Dat beeld moeten ze geleidelijk opbouwen.

Het is niet mogelijk om alles op voorhand te overzien. Daarom is het niet reëel om van de business stakeholders te verlangen dat ze hun complete set van eisen en wensen in een traditioneel programma van eisen opnemen.

Mini programma van eisen en wensen

Het Programma van Eisen kun je beter in delen laten opstellen. Of beter gezegd je gaat in kleine deelprojecten werken. Voor ieder deelproject laat je dan een mini-PvE opstellen. Dat doe je kort van tevoren, namelijk tijdens het voorafgaande deelproject.

In het eerste deelproject laat je een basale versie van het systeem ontwikkelen. Die initiële versie laat je steeds verder uitbreiden in de opeenvolgende deelprojecten. Dit worden incrementen genoemd. En daarvoor stel je steeds een mini-PvE op.

De business stakeholders hoeven zo niet meteen het complete plaatje te overzien. Ze kunnen zich op basis van de reeds opgeleverde software een steeds concreter beeld vormen. En ze kunnen voortborduren op de in de voorgaande deelprojecten opgeleverde functionaliteit.

2. Tweerichtingsverkeer

Om de eisen duidelijk over te brengen aan de ontwikkelaars is tweerichtingsverkeer noodzakelijk. Dat is namelijk de makkelijkste manier om erachter te komen of de eisen duidelijk zijn en goed geïnterpreteerd worden door de ontvanger.

Voor het Programma van Eisen betekent dit dat je als opdrachtgever (vertegenwoordigd door business stakeholders en/of een business analist) een groot deel mondeling overbrengt. Niet alle details hoeven dan schriftelijk vastgelegd te worden. Alleen de informatie waarop je later terug wilt kunnen grijpen.

Hoe vaker er mondeling contact is met de ontwikkelaars, hoe minder details je hoeft vast te leggen. Ook is het een stuk eenvoudiger om mondeling uit te leggen wat je van het systeem wilt. En je krijgt meteen terugkoppeling of je boodschap correct overkomt.

3. Ruimte voor herstelacties

Controleren of de software aan de gestelde eisen voldoet is geen overbodige luxe. Maar dat is alleen zinvol als er ruimte is om bij te sturen. Je wilt immers een systeem opgeleverd krijgen dat aan je behoeften voldoet. Maar dat komt alleen in zicht als er ruimte is voor herstelacties.

Voor de acceptatietesten die je op basis van een programma van eisen uitvoert, betekent dit dat ze vroegtijdig moeten plaatsvinden. Hoe eerder en hoe vaker je test, hoe eenvoudiger en minder kostbaar het is om de software aan te passen.

Alleen acceptatietesten aan het eind van ieder deelproject uitvoeren, is niet voldoende. Organiseer ook tussentijds feedback op schermprototypen. Of beter nog op in ontwikkeling zijnde onderdelen van het systeem.

Bottom line

Participatie tijdens de ontwikkeling van de software is vele malen effectiever dan een gedetailleerd programma van eisen.

Besteed je kostbare tijd en die van de stakeholders daarom niet aan het opstellen van een allesomvattend programma van eisen, maar aan actieve deelname aan het project. Dan creëer je de mogelijkheid om de eisen en wensen gaandeweg scherp te stellen, te communiceren en feedback te geven op de ontwikkelde software.

In het online programma Meester in agile requirements ontdek je op welke andere punten agile practices indruisen tegen traditionele werkwijzes. Aanrader voor traditioneel opgeleide vakmensen die werk van hoge kwaliteit willen blijven leveren.

Nicole de Swart

Misschien vind je dit ook interessant

4 reacties

  • Marc Commandeur

    Mooi stukje met een bekend verhaal waar ik me voor een deel in herken. Ik zie echter ook een paar valkuilen.

    Als in eerdere deelprojecten de kern van het systeem gebouwd is (ingrediënt 1), dan kan het een valkuil zijn dat de opdrachtgever teveel ruimte neemt (ingrediënt 3) en wenst dat de kern (te veel) wordt veranderd. Dat kan ten koste gaan van het budget en/of de op te leveren functionaliteit.

    Indien je een te groot deel van je PvE mondeling overbrengt en alleen een deel van de informatie expliciet vastlegt (ingrediënt 2), kan het heel makkelijk gebeuren dat afspraken en/of beslissingen verloren gaan en/of vergeten worden.

    Ik denk dat heel erg goed is met nieuwe ideeën te komen en uit te proberen. Ik denk echter ook dat we goed moeten uitkijken dat lessen die we in het verleden hebben geleerd (b.v. “bezint eer ge begint” en “documentatie is belangrijk”) niet uit het oog verloren moeten worden.

    • Nicole de Swart

      Marc, Bedankt voor je reactie en waarschuwing voor valkuilen. Heel verstandig uiteraard om lessen te trekken uit het verleden.

      Je 1e valkuil herken ik. Het mooie hieraan is dat de opdrachtgever zelf gaat over zowel de wijzigingen, het budget als de op te leveren functionaliteit. Hij kan alleen een gefundeerde beslissing nemen over tijd, geld en functionaliteit (en terugkomen op eerdere afspraken) als hij de consequenties kan overzien. Ik vind dat we ervoor moeten zorgen dat hij die beslissing kan nemen.
      Overigens zijn software-aanpassingen tegenwoordig veel eenvoudiger en minder kostbaar bij gebruikmaking van de moderne technische practices.

      Je 2e valkuil wordt groter naarmate de tijd tussen het ontstaan van de informatie/beslissing en de implementatie daarvan door het agile team langer wordt. Als daar niet meert dan enkele dagen tussen zit speelt het nauwelijks. Bewust kiezen dus wat je documenteert.

  • Rein

    Bij aanbesteden heb je een goed uitgewerkt PvE nodig, om te krijgen wat je wilt. Projecten in stukjes knippen levert achteraf problemen op ivm aanbestedingsregels.

    • Nicole de Swart

      Rein, heb je een goed uitgewerkt PvE echt nodig om te krijgen wat je wilt of is het om goede (traditionele) aanbestedingsafspraken te kunnen maken?
      Als het goed is krijg je bij een aanbesteding een systeem opgeleverd dat aan de vooraf afgesproken eisen voldoet. Maar is dat ook het systeem dat voldoet aan de echte behoeften van de business?
      Hebben jullie niet te maken met (dure) RFC´s en getouwtrek over de kosten?

Geef een reactie