De ontwikkelmethode ‘Quick & Clever’ zou diverse voordelen bieden boven traditionele ontwikkelmethoden, zoals de mogelijkheid te volstaan met minder projectmedewerkers. Marco Dekkers is echter niet overtuigd. Diverse aannames zijn volgens hem discutabel, en er worden beweringen gedaan die weinig overtuigend overkomen bij gebrek aan onderbouwing.
In het artikel ‘Gebruiker als voedingsbodem’ (Computable, 15 december 2000) beschrijft Kees Augustijn zijn ‘Quick & Clever’-methode voor systeemontwikkeling beschrijft. Bij de gepresenteerde methode zijn diverse kanttekeningen te plaatsen.
Wat in de eerste plaats opvalt, is dat het artikel een aantal aannames bevat die discutabel zijn. Zo wordt er gesproken over niet-kwantificeerbare eisen aan informatiesystemen. Het is een gegeven dat alle eisen kwantificeerbaar zijn, mits men de juiste meetschaal definieert. Bronnen waaruit kan worden geput zijn onder andere de ISO 9126-norm van de International Organization for Standardization en de Planuage-methode van kwaliteitsdeskundige Tom Gilb (http://www.result-planning.com). Zowel het ISO-model als de methode van Gilb demonstreren op overtuigende wijze dat alle vereisten die aan systemen gesteld kunnen worden, kwantificeerbaar zijn. Bovendien bieden dergelijke hulpmiddelen ontwikkelaars en gebruikers een gemeenschappelijke taal waarin het systeem beschreven kan worden.
Een andere aanname in het artikel is dat het hanteren van verschillende (technische) testfasen tot stijging van doorlooptijd en kosten leidt. Inmiddels is het ook binnen de ICT doorgedrongen dat gefaseerd testen leidt tot vroege detectie van fouten, waardoor de kosten en doorlooptijd voor herstel binnen de perken blijven. Een gefaseerde testaanpak draagt ertoe bij dat fouten niet over het hoofd gezien worden. Daardoor wordt voorkomen dat zij verderop in het ontwikkelproces tot forse inspanningen voor herstel leiden.
Een andere aanname in het artikel is dat bij het hanteren van de traditionele ontwikkelmethode (daarover straks meer) de kosten voor het uitbreiden van de functionaliteit in nieuwe versies dusdanig hoog zouden liggen, dat er nauwelijks nieuwe versies kunnen worden uitgebracht. Dit zou het gevolg zijn van het ‘op analyse en documentatie gerichte karakter’ van deze methode. Een onderbouwing voor deze stelling wordt niet gegeven. Uitbreidbaarheid van functionaliteiten valt of staat echter niet met de gehanteerde ontwikkelmethode, maar met de mate waarin eisen helder worden gedefinieerd en de wijze waarop wordt bewaakt dat het eindresultaat aan de eisen voldoet. In de slotalinea wordt de aanname gedaan dat bij het hanteren van de ‘Quick & Clever’-methode het uitbrengen van nieuwe versies geen bottleneck meer vormt, omdat ‘er zo’n ervaring is met het enorme aantal deelversies tijdens het hele ontwikkeltraject’. Deze stelling gaat voorbij aan de veelvoorkomende situatie dat de betrokken ontwikkelaars tijdens de beheerfase vaak niet meer beschikbaar zijn voor het ontwikkelen van nieuwe versies (bijvoorbeeld als er sprake is van inhuur). Het borgen van de kennis – door deze in de een of andere vorm te documenteren – is derhalve een effectievere benadering om ervaring zeker te stellen, dan het hanteren van de geschetste methode.
Traditioneel
Door het hele artikel heen wordt de ‘Quick & clever’-methode vergeleken met de ’traditionele ontwikkelmethode’. Nergens wordt duidelijk gemaakt naar welke traditionele methode wordt verwezen en derhalve blijft onduidelijk waar de vergelijking op gebaseerd is.
In het artikel worden vijf eisen geformuleerd waar een systeem voor het beheren van klantenbestanden aan moet voldoen. Deze eisen zijn derhalve algemeen dat zij op elke vorm van administratieve automatisering betrekking kunnen hebben. Eisen zoals ‘de functionaliteit van het systeem moet zo gedetailleerd mogelijk afgestemd zijn op de praktijk’ en ‘de toegevoegde waarde van het systeem moet de kosten voor ontwikkeling, implementatie en beheer rechtvaardigen’ zijn niet specifiek te noemen.
Het artikel bevat diverse beweringen die weinig overtuigend overkomen bij gebrek aan een onderbouwing. Zo wordt onder meer gesteld dat het enige zinvolle dat gebruikers kunnen controleren, het informatiesysteem zelf is. Uit eigen ervaring weet ik dat wanneer gebruikers in projecten bijvoorbeeld ook het functioneel ontwerp beoordelen, dit vaak tot zeer constructieve resultaten leidt. Een andere stelling in het betreffende artikel is dat door het delen van rollen het aantal deelnemers aan een project misschien slechts een kwart bedraagt van de groep die volgens de traditionele methode aan de slag zou gaan. Stel dat in een traditioneel project zeven ontwikkelaars, drie gebruikers en twee testers het werk verrichten, impliceert dit dan dat door het hanteren van de beschreven methode drie mensen hetzelfde resultaat zouden bereiken? Dat lijkt mij weinig aannemelijk; een dergelijke bewering zou op zijn minst een zeer gedegen onderbouwing moeten hebben. Deze wordt echter niet geboden.
Alternatieven
Imponerend is de stelling dat de effectieve bouwtijd binnen een ‘Quick & Clever’-traject wel 80 procent van de totale doorlooptijd van het project kan beslaan, versus 10 tot 20 procent bij de traditionele methode. Helaas wordt geen inzicht verschaft in de bron van deze cijfers. Onduidelijk is of zij op onderzoek of projectevaluaties zijn gebaseerd, of dat er hier slechts een slag naar wordt geslagen.
De beschreven methode biedt voorts een aantal zaken die door andere, meer gangbare, methoden al sinds jaren onderkend zijn. Zo wordt er uitgegaan van een grote betrokkenheid van eindgebruikers, die lid uitmaken van het projectteam. Dit is niets nieuws. Rapid Application Development methoden zoals de Dynamic System Development Methodology (DSDM) gaan hier al jaren van uit. Wat ontbreekt in de benadering die in het artikel wordt voorgestaan, is aandacht voor en betrokkenheid van andere belanghebbenden, zoals het lijnmanagement, financieel management, auditors, enzovoort. Een zorgvuldige inventarisatie van de belanghebbenden en hun eisen aan de uitkomst van het project bevordert de acceptatie door alle betrokkenen.
De hier beschikbare ruimte is te beperkt om alle kanttekeningen ten aanzien van de ‘Quick & Clever’-methode de revu te laten passeren. Hopelijk is wel gedemonstreerd dat rondom de methode enkele serieuze vraagtekens bestaan. Organisaties die de beperkingen van ’traditionele’ ontwikkelmethoden willen omzeilen, doen er wellicht goed aan om zich te verdiepen in alternatieven (zoals DSDM).
Marco Dekkers Productmanager Kza Kwaliteitszorg