In een traditionele ict-ontwikkelomgeving vormt de testfase van een project vrijwel altijd de kreukelzone. Als bijvoorbeeld de bouwfase is uitgelopen wordt vaak de tijd die voor het testen van het product is gereserveerd ingekort om nog op tijd (of zo snel mogelijk) te kunnen opleveren. Het grondig testen van het product wordt dan ondergeschikt gemaakt aan de opleverdatum. Ondanks het belang dat van goed testen wordt ingezien.
Oók bij het opstellen van de requirements is de testfase vaak het kind van de rekening. Als het überhaupt al is ingepland. Er zijn al ontwerpers en ontwikkelaars vrijgemaakt of ingehuurd en men wil aan de slag. Een ander argument dat je dan wel eens hoort is: ‘Requirements veranderen toch altijd.’ Het toetsen van requirements wordt dan gezien als verspilling van tijd. Kortom, het toetsen van requirements wordt meestal niet of slechts marginaal gedaan, want men wil aan de slag. Tijd is geld.
Dat is eigenlijk heel raar. Als we naar een paar statistieken kijken, dan blijkt dat opgestelde requirements vaak nog heel veel ruimte laten voor fouten, aannames en verwarring:
- 44 procent van de projecten wordt gestopt door problemen met requirements (Standish Group).
- 56 procent van alle gebreken in software hebben hun oorsprong in de requirements (James Martin).
- 82 procent van alle herstelwerkzaamheden komt door fouten in de requirements (James Martin).
Daar komt nog eens bij dat goedkoop duurkoop is. Al in 1978 heeft Barry W. Boehm aangetoond dat hoe later in de ontwikkeling van een product een fout wordt ontdekt, hoe hoger de kosten zijn om deze te herstellen. Deze kosten nemen zelfs schrikbarend toe. Tot wel duizend keer meer wanneer een fout pas wordt ontdekt in productie.
Het laten toetsen van requirements mag je dus niet overslaan. Het kost relatief heel weinig tijd, maar bespaart later in het project, of tijdens beheer, een hoop herstelwerkzaamheden, en dus geld.
Maar wat als je toch in de kreukelzone terecht komt? Als er nauwelijks meer tijd over is of gegeven wordt voor het grondig laten toetsen van alle requirements? Hier mijn vijf tips om hier zo goed en efficiënt mogelijk mee om te gaan en nog zoveel mogelijk fouten, aannames en verwarring op te sporen.
1. Wacht niet totdat alle requirements zijn verzameld.
Begin al met tussentijds toetsen zodra de requirements, of gedeelten ervan, stabiliseren.
2. Laat belanghebbenden minimaal hun eigen requirements reviewen.
Bij voorkeur zo snel mogelijk na het interview of de workshop. Ik heb regelmatig meegemaakt dat iemand dan zei: ‘Heb ik inderdaad zo gezegd, maar nu ik het op papier zie staan bedoel ik het toch eigenlijk anders.’
3. Laat alleen de meest kritische requirements grondig inspecteren en laat de rest alleen reviewen.
Een formele inspectie door deskundigen uit verschillende disciplines kost veel meer tijd dan een informele, vaak collegiale review. Bepaal op basis van de prioriteit van de requirements welke de meest kritische zijn.
4. Geef een checklist mee.
Checklists helpen mensen om naar specifieke problemen te zoeken. Het maakt ze (weer) opmerkzaam op veel voorkomende fouten.
5. Maak eventueel gebruik van software.
Er is tegenwoordig software op de markt waarmee je requirement-documenten automatisch en heel snel kunt laten controleren op woorden en begrippen die tot verwarring kunnen leiden. Echter, gebruik dit alleen als extra hulpmiddel en niet als vervanging van mensen. Het doen van aannames en het interpreteren van woorden en begrippen blijft immers mensenwerk!
Er zijn vast nog meer tips.
Wat doe jij als jouw kreukelzone steeds kleiner wordt?
Herkenbaar. Ik zie dat in projecten de bottleneck vaak zit in het onjuist of onvolledig specificeren van de requirements (dat is immers een vak apart). Ook is er vaak onvoldoende duidelijk wat de prioriteiten zijn. D.m.v. bijv. de MoSCoW-methode kan dit gemakkelijk in kaart gebracht worden, maar dit blijft vaak achterwege. Daar waar het belang van testen inmiddels wel doorgedrongen is, vind ik dat het belang van heldere requirements nog onvoldoende aandacht heeft in projecten en voorbereidingen daarvan. De business denkt vaak nog teveel in oplossingen en we moeten als business consultants en functioneel beheerders veel beter inzichtelijk maken wat de impact is van een gebrek aan goede requirements. Een goede “Lessons Learned” aan het einde van het project kan daar ook bij ondersteunen, maar dat zie ik zelden in de praktijk gebeuren.
Wat ook kan helpen is dat je een 3e partij betrekt bij het bewaken van de specificaties zodat zowel de opdrachtgever als de implementerende partij zich aan moeten verantwoorden.
Dat lijkt alsof het meer burocratie oplevert maar als je bedenkt dat je er veel meer fouten uit haalt dan zal het per saldo veel onnodige kosten uitsparen.
Sterker nog: altijd toetsen! Na de testfase komt nog de invoering. En als ze er tijdens de invoering achter komen dat het systeem beter nog wat strakker of gebruiksvriendelijker kan, dan vang je nog altijd de invoering af van een snel achterhaalde release.
Ga zodra specificaties afkomen, deze daarom met de programmeur, de tester en de functioneel beheerder doorvlooien. Met zijn drieën zien zij meer dan ieder alleen. Bovendien stimuleert het bijzonder om met zijn drieën de defecten in een document aan te wijzen.
Checklists helpen zeker, maar waar haal je die vandaan? Eerdere reviews zijn een goede bron.
Als de auteur erbij is als ze aan het vlooien zijn, krijgt hij ook de achtergronden van de opmerkingen te horen. Daarmee kan hij gericht de specificatie verbeteren.
Voor de kosten hoeft men het reviewen (of inspecteren) niet te laten: een review door drie mensen van een document van 15 pagina’s kost zo’n 3000, 3500 Euro, inclusief aanpassen van het document. Een nieuwe release kost één ton tot een miljoen.
Het tijdgebrek is vooral een kwestie van agenda’s. Probeer maar eens in Outlook met drie collega’s een afspraak te maken voor twee uur.
Tijd heb je niet – die maak je. Het is een kwestie van prioriteit. Daarmee is het de verantwoordelijkheid van de projectmanager of teammanager om de reviewers tijd te laten maken.
@Mirjam,
Veel is op te lossen door er voldoende kennis tegenover te zetten, maar ook door niet opnieuw dezelfde vragen te bedenken. Kennis is voor veel mensen iets wat niet grijpbaar is en niet goed herkenbaar.
Review is ook een goed middel.
Er zit overigens veel verschil in een aanbesteding voor “20 krentenbollen in een dozijn of maar 5 in een dozijn…”
@Mirjam
Als aanvulling op punt 3 kun je er wellicht voor kiezen om niet zozeer de “meest kritische” reqs te reviewen, maar de meer highlevel cq businessrequirements. Als daar veel verbeterpunten uitkomen, kun je ervoor kiezen om ook de bij die respectievelijke highlevel/businessrequirements onderliggende detailrequirements te reviewen/inspecteren. Hoe meer high level je een fout veroorzaakt, des te groter zal ook de schade zijn als je deze in detail uitwerkt.
Met enige verbazing, met alle Respect, frons ik de wenkbrauwen bij het lezen. Regel 1 is de basis waar je precies HET grootste probleem dat je ZAL veroorzaken wanneer je begint zonder dat je je requirements helder hebt.
Volkomen los van welke methode of instrument je gebruiken wil voor het verzamelen van je requirements. De fout die hier gemaakt word? Dat is dat je geen duidelijk waarde gaat toekennen aan het proces wat je voor ogen hebt. Enig idee waar dat toe zal gaan leiden? Een proces dat problemen zal kennen, vertraging of over budgettering.
Elk TO of FO valt of staat met een compleet overzicht van de requirements. Anders is het een eenvoudige IT wetmatigheid dat wanneer je namelijk de waarde niet helder vast hebt staan, het proces, vroeg of laat, stagneren zal.
Het is een zeer bekende denkfout dat je ‘zomaar ergens’ kunt beginnen waar IT als materie de basis vormt. Die kreukelzone? Nergens voor nodig.
@allen: hartelijk dank voor jullie reactie en/of aanvullende tips.
Een derde,onafhankelijke partij mee laten draaien tijdens het toetsen van requirements kan inderdaad heel handig zijn om aannames en interpretatieverschillen vanuit bedrijfsspecifiek jargon op te sporen.
Het is zeker ook aan te bevelen om tijdens een grondige (Fagan)-inspectie de auteur cq opsteller van de requirements aanwezig te laten zijn. Maar zorg er wel voor dat iedere deelnemer zijn rol goed kent tijdens de sessie, zodat deze niet alsnog eindigt in een ‘Poolse landdag’ en veel kostbare tijd opslokt.
Houdt dus het doel van een inspectie goed voor ogen. Het doel van inspecteren is nl. om zo snel mogelijk zo veel mogelijk fouten te vinden en suggesties te doen voor verbeteringen. Het doel van inspecteren is niet om problemen op te lossen, jezelf als auteur te verdedigen of om de auteur af te kraken.
Echter, deelnemers laten zich over het algemeen gemakkelijk verleiden tot discussies over of iets werkelijk een fout is, over de scope van het project of over mogelijke oplossingen voor de fouten. Een goede, onafhankelijke moderator kan dit helpen voorkomen.
@ Mirjam,
Nu klinkt het toch als dat het project niet goed bemenst is. Wanneer de goede mensen in het project zitten is er echt geen moderator nodig, dat zou de projectleider ook als (bindende?…) factor in zich moeten hebben.
@Maarten,
Helemaal mee eens, het gaat om de rol van ‘moderator’, om iemand die het proces bewaakt dat in een kort tijdsbestek alleen mogelijke fouten, aannames, interpretatieverschillen en verbetersuggesties worden gemeld. Deze rol kan het best worden vervuld door iemand die verder van de inhoud staat en dat kan dus ook de projectleider zijn.