Biljarten lijkt op software maken was eerder te lezen op Infoworld.

Een groot deel van het geld dat in softwareprojecten wordt gepompt, wordt gebruikt om mislukte projecten te repareren. Meestal worden zaken hersteld die eigenlijk al vanaf het begin slecht zijn aangepakt. De reden? Managers en klanten stellen van tevoren specificaties op die niet kloppen. Doe het voortaan anders.

Volgens het Standish Group Chaos Report (2003) mislukt 15 procent van de it-projecten. Aan meer dan de helft van de overige projecten hapert nogal wat. Slechts 40 procent van de klanten is tevreden. Oorzaken zijn bijvoorbeeld het foutief inschatten van de benodigde uren, een onhandige teamstructuur en een gebrek aan klantparticipatie. Ook zelfoverschatting en gebrekkig scopemanagement spelen een rol.

Het grootste probleem is desondanks iets anders. In Engeland wees een studie onder 1027 projecten uit, dat mislukkingen meestal gerelateerd zijn aan het watervalmodel. In meer dan 80 procent van de mislukte projecten was dit de oorzaak ('IT Projects Sink or Swim', British Computer Society Review). Simpel gezegd, de analisten en managers hebben van tevoren de functionele vereisten opgesteld - en ze hadden het mis.

De a priori valkuil

Het klinkt logisch om te bepalen wat je gaat maken voordat je aan de slag gaat. Het ligt voor de hand om een applicatie eerst te ontwerpen en pas daarna te gaan programmeren. "Hoe beter het ontwerp, hoe minder het zal veranderen tijdens het project", denkt men. Deze redenering gaat helaas niet op. Een gedetailleerd a priori ontwerp heeft een zwak punt. Het is ontzettend moeilijk om van tevoren alle details in een keer goed te hebben.

Een voorbeeld is een spelletje poolbiljart. Alle vijftien ballen met een enkele stoot in de pockets doen belanden, is theoretisch mogelijk. De stunt blijkt in de praktijk vrijwel onmogelijk, hoe goed je er van tevoren ook over nadenkt. Er zijn ontelbare factoren die niet in te schatten zijn. Een kleine hobbel in het doek gooit al roet in het eten. De kleinste afwijking in het begin veroorzaakt een enorme uitwijking aan het eind. Biljarten lijkt op software maken. Echt.

Het punt is dat een applicatie gemaakt wordt door en vooral voor mensen, in een echte omgeving - en niet in een laboratorium. Er zullen oncontroleerbare dingen gebeuren. Voortschrijdend inzicht, onverwachte gebeurtenissen en wederzijdse miscommunicatie zorgen er voor, dat het gedetailleerde ontwerp gegarandeerd vol met fouten zit. De klanten hebben namelijk geen boodschap aan een abstract ontwerp. Ze willen een stuk software. Om een berg papier duidelijk te laten maken wat een werkend stuk software gaat doen, moet je van goede huize komen. Voor alle anderen is het gewoon een uitstekende manier om een project om zeep te helpen.

Alternatieven

De meeste projectmanagers geloven ten onrechte dat een goede ureninschatting pas kan worden gemaakt nadat alle features tot in detail zijn uitgewerkt. Het geeft een vorm van schijncontrole, omdat een groot deel van de details later niet blijkt te kloppen. Dit geldt ook voor de klanten. Dat wat u vraagt aan het begin van een project is vaak niet wat u nodig heeft aan het eind. Bovendien is datgene waar u een handtekening onder zet vaak niet wat u denkt. Een uml-ontwerp lijkt namelijk in de verste verte niet op een applicatie. Bovendien willen klanten altijd alles hebben, dus in een a priori ontwerp staan een hoop overbodige specificaties. Ook overbodige specificaties zijn niet gratis, dus dat is achteraf echt niet leuk.

Wat is het alternatief? Specificaties die achteraf niet blijken te kloppen, zijn veel duurder dan specificaties die later worden aangescherpt. Het is dan ook veel veiliger om de te bouwen toepassing alleen globaal te beschrijven voordat het project van start gaat. Vervolgens kunnen tijdens het project de specificaties worden uitgediept - samen met de klant. Dit hoeft niet eens zo veel tijd te kosten.

"Modelleren is moeilijk!", roepen de fabrikanten van hulpmiddelen zoals Rational. "Ontwerpen is een kunst!", schreeuwen de implementatiepartners. Welnu, ik zal u een beroepsgeheim verklappen. Er is helemaal niet zo veel nodig voor een succesvol model. Een klant, een paar slimme mensen, een whiteboard, wat stiften en iedere week een half uurtje tijd over zijn de enige voorwaarden. Er zijn een aantal ontwikkelmethoden die deze manier van werken hebben omarmd. De bekendste zijn eXtreme Programming (XP), SCRUM en eigenlijk tegenwoordig ook DSDM.

Achteraf tevreden

Het ergste is nog, dat er door een gedetailleerd a priori ontwerp een soort spastische situatie ontstaat als het gaat om voortschrijdend inzicht. Wie kent ze niet, de Change Request Procedures? Als een soort boeman bewaakt de projectmanager het oorspronkelijke ontwerp. Van mening veranderen kan kennelijk niet. Iedereen lijkt te vergeten dat er maar een ding echt belangrijk is: een tevreden klant. En met tevreden bedoel ik niet van tevoren tevreden, maar achteraf tevreden. Voelt u het verschil?

Sander Nagtegaal
18 oktober 2004