'Nee' is ook een antwoord

Het begint al in de kleutertijd, de kleuter-puberteit, 'wil ik hebben'. Dan moet je geen slappe knieen hebben om 'Nee' te durven zeggen als die lieve kleuter je smekend aankijkt. Maar 'Nee' zeggen kan ook iets opleveren. Namelijk aandacht voor iets anders. Iets wat misschien wel meer waarde oplevert. Of het nu gaat om een stuk fruit in plaats van een lolly. Of het lezen van een boek in plaatsen van het surfen langs tik-tok filmpjes. Wat is wijsheid? En vooral de vraag 'wat zijn de criteria of principes die bepalen of Nee, en het aangeboden alternatief, het betere of beste antwoord is, gegeven de context van de vraag'?

(bron: kekmama.nl)
Maar hoe weten we dan of Nee het juiste antwoord is om een investering te plegen, gegeven een bedrijfssituatie waarin een probleem wordt onderkend of een kans wordt geroken? Starten we een verandertraject omdat de ander (de concurrenten) het ook doet, is het wijs om te leren leven met het probleem of is de timing correct? Of moeten we iets anders doen zodat we ons kunnen onderscheiden van de concurrent?
Het is de kunst om voor start van de verandering en tijdens het onderzoeken van de situatie en het vorm geven van de verandering de criteria voor het verwerpen van het verandervoorstel, het Nee zeggen, helder te formuleren. Zodat belangrijke stakeholders tijdens en na de beoogde verandering we kunnen (blijven) meten of de veronderstelde voordelen worden behaald. Om zo op de juiste manier de investering te evalueren en waar nodig correctieve acties te definieren.

ICT, psychologie, filosofie of kunst?

Een aantal dagen per week begeleid ik werkgroepen van de AD-opleiding van Zuyd ICT. In die ruimte staat een kast met boeken die stof vangen. Zo ook een boek van Philippe Kruchten over de zogenaamde Rational Unified Process. Het boek, second edition, dateert uit het jaar 2000. En als ik het doorneem lijkt het wel alsof alle waarheden over software-ontwikkeling de revu passeren. Alsof alle methoden-bedenkers, bv. SCRUM of Safe en bijbehorende trainings-instituten er een goed-bekkende-saus overheen hebben gegooid. Dat wordt ook wel eens genoemd 'oude wijn in nieuwe zakken'. En omdat er ook zoiets bestaat als 'als je een groene volvo hebt zie je opeens overal groene volvo's' en ieder citaat uit dit boek wellicht kan worden gecounterd met een tegenargument wil ik jullie één passage uit het boek toch niet onthouden. De passage is afkomstig uit het hoofdstuk Iteratief ontwikkelen. Het is een uiteenzetting van werkwijzen om te komen tot een juist benadering van software ontwikkeling. Na de constatering dat het bouwen van een wolkenkrabber of brug als een sequentieel proces kan worden aangepakt, somt de auteur op waarom deze vlieger niet opgaat voor software ontwikkeling.

En komt zo tot het statement
"Software engineering has not reached the level of other engineering disciplines (and perhaps it never will) because the underlying "theories" are weak and poorly understood, and the heuristics are crude. Software engineering may be misnamed. At various times it more closely resembles a branch of psychology, philosophy or art then engineering. Relatively straightforwarded laws of physics underlie the design of a bridge, but there is no strict equivalent in software design. Software is "soft" in this respect"
Bron: Kruchten, P. (2000). The Rational Unified Process: An Introduction (2nd Edition) (2de editie). Addison-Wesley Professional.

Met deze uitspraak in het achterhoofd is het voor een opdrachtgever of development team wellicht makkelijker te accepteren dat niet alles voorspelbaar is. Maar toch tot resultaat zal leiden. Al is het niet in een rechte lijn. Neemt niet weg dat methodisch te werk gaan een zekere mate van onvoorspelbaarheid kan verminderen.