Voorwoord
“If I have seen further than most men, it is because I stood on the shoulders of giants”
In 1671 deed Isaac Newton bovenstaande beroemde uitspraak. Hij besefte dat hij een aantal belangrijke wetten had gedefinieerd die de basis zouden leggen voor de moderne natuurkunde. Hij besefte ook dat hij dat niet alleen had gedaan. De grootste kracht van Newton was het inventariseren van de reeds bestaande kennis om daar vervolgens op verder te bouwen.
Het definitieve besluit om een boek te gaan schrijven werd genomen in januari 2001. Hoewel het plan er al langer was, ontbrak het al die jaren aan een tweetal zaken. In de eerste plaats was er slechts een vaag idee waar het boek over moest gaan en hoe het opgezet zou moeten worden. In de tweede plaats was er onvoldoende inspiratie en tijd om er aan te beginnen. In september 2000 verkochten mijn compagnon en ik ons adviesbureau. Dit betekende dat ik vanaf januari 2001 een nieuwe functie kreeg in een andere werkmaatschappij. Deze nieuwe functie bleek voldoende ruimte te bieden om te beginnen aan het schrijven van dit boek. Doordat er meer ruimte ontstond, kwam ook de inspiratie om de ervaringen uit mijn loopbaan in de informatietechnologiebranche (mondvol, hierna gewoon IT-branche) toe te vertrouwen aan het papier. Het duurde echter enige tijd voor ik de juiste afbakening en vorm had gevonden. Laat ik dit toelichten.
In 1986 ben ik afgestudeerd als elektrotechnisch ingenieur aan de Technische Universiteit te Eindhoven. In de doctoraalfase van mijn studie bewoog ik mij echter al richting het vak informatica. Na de studie zocht ik ook werk in deze discipline. De eerste jaren werkte ik als freelancer in veel crisisprojecten. Dit kwam enerzijds omdat dit een eigenschap is van de meeste software projecten, anderzijds wilden inkoopafdelingen van grote bedrijven als Philips alleen freelancers inhuren als een project echt uit de hand dreigde te lopen. Van 1993 tot 1996 werkte ik voor een groot softwarehouse in de functie van adviseur. De werkzaamheden bestonden voornamelijk uit het doorlichten van projecten en afdelingen en het begeleiden van verbeteringstrajecten. In 1996 startten mijn compagnon en ik een eigen adviesbureau. In vier jaar tijd groeide het bedrijf uit naar ongeveer 25 medewerkers. Naast het ondernemen bleef er voor mijzelf voldoende tijd over om de advieswerkzaamheden te continueren. Hiernaast begon ik vanaf 1996 met veel plezier gastcolleges te geven aan de universiteit in Eindhoven, hetgeen in 2000 resulteerde in een parttime aanstelling als universitair docent. Vanaf 1997 ben ik bovendien voorzitter van de Nederlandse stichting voor Software Process Improvement, SPIder genaamd. Deze stichting tracht nieuwe ontwikkelingen en ervaringen op het gebied van procesverbeteringen onder een zo groot mogelijk publiek bekend te maken.
Terugkijkend op de ruim veertien jaar ervaring ben ik nog steeds verbaasd. De IT-branche is uitermate onvolwassen en zal dit vooralsnog ook blijven, alle investeringen om het tij te doen keren ten spijt. Organisaties investeren al vanaf de tachtiger jaren in steeds geavanceerdere project management methoden en technieken om grip te krijgen op projecten. Er wordt geïnvesteerd in dure technologie (CASE-tools) om het ontwikkelen van software te vergemakkelijken. Standaarden en modellen als ISO 900x en het Capability Maturity Model (CMM) worden in de armen gesloten om alle processen vast te leggen en te verbeteren. De resultaten zijn echter teleurstellend gebleken, hetgeen niet verwonderlijk is. Waar het echt aan ontbreekt zijn duidelijke basisregels, die bekend zijn bij en gevolgd worden door alle betrokkenen. Indien je een boottocht wil maken is een goede uitrusting uiteraard van belang. Maar alleen investeren in complexe en dure apparatuur is niet voldoende. Het is met name van belang dat ieder bemanningslid op het schip op elk moment weet wat er van hem of haar wordt verwacht: vakmanschap! Dit geldt zowel bij het voorbereiden, het uitvaren, de tocht op zee, het aanmeren in de haven en het schoonschip maken. In de IT-branche moeten we helaas constateren dat er onvoldoende aandacht is voor vakmanschap. Het ontbreekt aan een aantal algemeen geaccepteerde basisregels. Er wordt aangerommeld en toch verwacht men bij elk volgend project verbeteringen ten opzichte van het vorige project zonder dat er daadwerkelijk anders wordt gewerkt. De investeringen voor verbeteringen richten zich zelden op het achterhalen en vastleggen van deze engineeringwetten. Zo zijn er organisaties die tientallen miljoenen investeren in nieuwe technologie en modeladopties. Op de werkvloer zelf verandert er echter niets. Tegelijkertijd worden massaal omgeschoolde en duurbetaalde biologen ingehuurd om software te ontwikkelen. Nu is er uiteraard niets mis met biologen en ook niet met het omscholen van mensen van het ene naar het andere vak. Maar dat de illusie bestaat mensen in 3 maanden tijd te kunnen bekwamen in dit complexe vak, verbaast mij in hoge mate en u hopelijk ook.
Er is echter meer aan de hand. Ook universiteiten verzuimen vakmensen op te leiden. Met name technische universiteiten richten zich teveel op “Computer Science” in plaats van “Software Engineering”. In Nederland leiden technische universiteiten ingenieurs op. Maar deze ingenieurs zijn niet in staat om op voorspelbare wijze betrouwbare producten te bouwen, op tijd en binnen budget, hierbij gebruikmakend van bewezen werkmethoden. Zij zijn niet opgeleid tot vakmensen. Bovendien verzuimen universiteiten om onderzoek te doen naar welke werkmethode wel of niet geschikt is om als standaard te worden geadopteerd.
Een triest beeld? Ja, maar ook realistisch en gegeven het grote tekort aan informatici moet gevreesd worden dat de situatie op korte termijn niet zal verbeteren. Het in korte tijd omscholen van mensen met een totaal verkeerde vooropleiding zal niet zomaar verdwijnen. Het verhuren van deze omgeschoolde niet-informatici tegen exorbitant hoge tarieven zal bij velen de eurotekens in de ogen doen verschijnen. Is er hoop? Met dit boek tracht ik in ieder geval te komen tot eenvoudige, krachtige basisregels. Pas als deze regels geaccepteerd en toegepast worden, loont het om verdere investeringen te doen in verbeteringen van methoden en technieken, nieuwe technologieën en procesvolwassenheid. Is er dan nooit eerder nagedacht over zulke wetten? Uiteraard wel, het zou getuigen van naïviteit om te veronderstellen dat dit boek vol met oogopeners en nieuwe ideeën zit. Maar, de meeste boeken richten zich in detail op een specifiek deelgebied van de informatica. Bovendien worden vaak ideeën en concepten gepresenteerd, die een te hoog theoretisch karakter hebben. Het wordt daarmee voer voor wetenschappelijke academici en andere dromers, maar levert aan de dagelijkse praktijk nauwelijks een bijdrage.
In mijn ogen ontbreekt een overkoepelend boek dat een gemeenschappelijk en praktisch referentiekader aanreikt voor management, projectleiders en (toekomstige) informatici. Want waar hebben we behoefte aan? Aan simpele regels die door alle betrokkenen als standaard worden geaccepteerd, die niet meer ter discussie worden gesteld. We moeten software gaan schrijven en projecten gaan managen volgens de drie grondregels van het SAS-principe:
Terug naar de te kiezen afbakening en vorm. Bij het schrijven van een boek bestaat vaak de neiging om zo volledig mogelijk te willen zijn. De auteur eindigt dan met een dik boek, dat zoveel relevante en gedetailleerde informatie bevat dat de essentie verloren gaat. Om dit project overzichtelijk te houden heb ik besloten de volgende afbakening te hanteren. U vindt in dit boek als projectleider geen uitgebreide beschrijving van een nieuwe project management aanpak. U vindt als manager van een organisatie(-onderdeel) ook geen beschrijving van een nieuwe manier om software organisaties te beheren of te verbeteren, ondersteund met veel empirische ervaringscijfers. U vindt als informaticus in een projectteam ook geen inhoudelijke richtlijnen voor het gestructureerd schrijven van formeel bewijsbare software. U vindt als student ook geen uitputtend leerboek over het fascinerende vakgebied der informatica. Wat vindt u dan wel?
Ik heb besloten aan de hand van een analogie wezenlijke principes de revue te laten passeren. Elke wezenlijke fase van een software project wordt beschreven aan de hand van een vergelijkbare fase in een fictief bouwproject. Vervolgens wordt ingegaan op de parallel met een software project. Dit leidt tot een aantal basisregels die van belang worden geacht. Geen theoretische maar praktische regels, die iedereen kan begrijpen en die niets te maken hebben met “hemelfietsen”. Beide benen aan de grond, want door de wolken loopt geen weg. Deze regels zijn vaak een nadere uitwerking van de overkoepelende grondregels. Elk hoofdstuk wordt afgesloten met wat luchtige toelichtingen, metaforen en vragen/opdrachten. Deze zijn voortgekomen uit ontwikkelde trainingen, colleges en praktijkervaringen. Zij benadrukken nog eens de essentie van wat in het betreffende hoofdstuk naar voren is gekomen.
De vergelijking met een fictief bouwproject wekt misschien de illusie dat de stof in dit boek alleen betrekking heeft op nieuwbouw software projecten. Het tegendeel is waar. In de eerste plaats wordt er veel aandacht besteed aan verwachtingsmanagement en project management. En de hierbij behandelde onderwerpen kunnen ook toegepast worden op bijvoorbeeld het implementeren van een standaard software pakket in een organisatie. De stof in dit boek is dus algemener toepasbaar dan strikt op het ontwikkelen van nieuwe software. In de tweede plaats is er ook aandacht voor het onderhouden van software. Er wordt aannemelijk gemaakt, dat veel facetten die een rol spelen bij nieuwbouwprojecten ook van toepassing zijn op onderhoudsprojecten. Verder wordt ingegaan op het feit, dat de onderhoudsfase een onderschatte fase is (hier wordt het meeste geld uitgegeven) en dat uit de onderhoudsfase verkregen informatie uiterst waardevol is voor nieuwbouwprojecten. In de derde plaats wordt het boek besloten met het zoeken naar een oplossing om de voortdurende “software crisis” te doorbreken. Hierbij wordt de rol van overheid, onderwijs en bedrijfsleven onder de loep genomen.
Blijft natuurlijk nog de vraag voor wie dit boek is geschreven. Voor projectleiders, voor managers, voor informatici, voor studenten, of alleen maar voor mijzelf? Laat ik maar eerlijk zijn. Het boek is geschreven voor ons allemaal. Het is geschikt voor elke informaticastudent die nieuw in het vak komt kijken (universiteit of hogeschool). Zij kunnen zien wat belangrijk is in de toepassing van het vak en hoe het vak nog aan het worstelen is om een echt vak te worden. Ook hun docenten kunnen er gebruik van maken, hierbij ondersteund door de vele voorbeelden, vragen en opdrachten in elk hoofdstuk. Maar het boek is ook voor alle informatici die al kort of lang in het vak werkzaam zijn. Zij kunnen nieuwe begrippen leren, hun eigen ervaringen toetsen of gewoon weer eens een aantal zaken nalezen, helder op een rij gezet. Tenslotte kunnen managers, die direct of zijdelings met de toepassing van informatica te maken hebben, hun voordeel ermee doen. Het boek verschaft inzicht in de hoofdlijnen, de essenties. Met deze inzichten kunnen zij wellicht als volwaardiger gesprekspartner fungeren binnen of buiten de eigen organisatie. Te ambitieus? Nee, ik denk het niet, maar oordeelt u zelf.
En de benodigde voorkennis? Enige affiniteit of ervaring met software maken helpt. Bepaalde zaken zullen sneller worden herkend en er kunnen vergelijkingen worden gemaakt met eigen ervaringen. Maar zoals eerder gezegd, dit boek is ook geschikt voor studenten. Dit is in de praktijk ook gebleken, want de behandelde stof komt voor een groot gedeelte voort uit gegeven colleges (eerste tot en met derde jaar informatica-onderwijs, postacademisch onderwijs). Het belangrijkste is dat u als lezer interesse heeft voor het vak, als starter of als ervaren iemand.
Welnu, ik ga aan de slag. Ik hoop voor de herfstvakantie klaar te zijn. Eens kijken of het lukt.
O ja, nog een tip, gebaseerd op de adviezen van mensen die het boek reeds lazen. Lees het boek in chronologische volgorde (dus van voor naar achter) en neem de tijd: bijvoorbeeld een hoofdstuk per avond. Sla bij voorkeur niet teveel over, want er zit een bepaalde opbouw in het verhaal.
Ik wens u veel leesplezier!