De beste oplossing

016-Thumbnail 360 graden
‘Sluit gemakkelijk compromissen’
was een van de te scoren eigenschappen op een 360°-feedback-formulier dat ik over mezelf moest invullen.
Dat vond ik een moeilijke.
Gelukkig mocht het antwoord ‘niet van toepassing’ ook.
 
Mijn leidinggevende had wel een score voor me ingevuld. Een hoge.
‘O,’ zei ik. ‘En is dat positief?’
Ja, dat was positief.
 
Nu wil het geval dat ik niet veel op heb met compromissen.
Want wat is een compromis doorgaans: een oplossing die geen van de partijen echt wil. Een oké-vooruit-dan-maar of een als-het-dan-niet-anders-kan of zelfs een ik-krijg-dan-wel-niet-wat-ik-hebben-wil-maar-jij-tenminste-ook-niet.
Een compromis is in zo’n geval maar een slap aftreksel van wat de betrokkenen oorspronkelijk voor ogen stond.
 
Wat is er veel mooier dan een compromis (ja, het ligt voor de hand): de beste oplossing.
En aangezien we het hier niet hebben over de wereldproblematiek maar over ICT-kwesties, is er vaak zo’n oplossing mogelijk als we maar een paar simpele dingen doen:
 
Zie het groter
Voor problemen waar alleen een compromis mogelijk lijkt (of de botte bijl natuurlijk), is in veel gevallen een oplossing te vinden als we een stapje achteruit doen om de zaak meer in context te bekijken.
Zo stonden er eens twee ontwikkelaars met verhitte koppen tegenover elkaar. Het twistpunt: de beste manier om bepaalde functionaliteit in een applicatie te implementeren. Elk hield hartstochtelijk vast aan de eigen methode en ze hadden uiteindelijk dan maar besloten tot een compromis: jij gebruikt jouw methode in jouw module en ik de mijne in die van mij.
Het was duidelijk dat dit compromis wel erg ver verwijderd was van een goede oplossing; onze toekomstige beheer- en onderhoudsproblemen stonden zich in een hoek van de kantoortuin al te verkneukelen. Dat kon zo dus niet.
Toen de gemoederen wat bedaard waren, bleek dat de beide methodes elkaar niet veel ontliepen. De ene was niet zozeer beter of slechter dan de andere, ze waren vooral verschillend. Wel was de ene methode binnen de applicatie al op diverse plaatsen gebruikt en was de andere er nu net voor de eerste keer ingekomen. Toen was de keuze snel gemaakt: het deed er inhoudelijk niet toe welke methode we zouden kiezen, maar vanuit oogpunt van beheer en onderhoud was de al geïmplementeerde oplossing veruit te prefereren.
Opgelost.
 
Wat hier speelde binnen een team, gaat ook op op andere niveaus. Zo kan het afstemmen van de planningen van twee afdelingen een bron van conflicten zijn omdat ze elk hun eigen werkzaamheden proberen te optimaliseren, maar blijkt de prioritering ineens een stuk eenvoudiger als er wordt gekeken naar zaken als het klantbelang, de gevolgen voor de winstverwachting of zelfs de continuïteit van de organisatie.
En daarvoor hoeft heus niet altijd eerst te worden geëscaleerd.
Wat wel erg helpt, is het volgende:
 
Maak je even niet druk om jezelf
Eind jaren ’80 speelde topspits Romário bij PSV en werd hij geïnterviewd door Studio Sport. ‘Als jij het mocht zeggen, wat koos je dan: niet scoren maar wel de wedstrijd winnen met het team, of zelf een doelpunt maken en verliezen?’ De voetballer bedacht zich geen moment en antwoordde met een stralende glimlach: ‘Zelf een doelpunt maken!’
In velen van ons schuilt een Romário – zo niet qua capaciteiten, dan toch in ieder geval qua mentaliteit. En dat legt sommigen in de voetballerij misschien geen windeieren, maar in de ICT is dat toch wel jammer. Onze opdrachtgevers hebben er namelijk meestal beduidend minder belang bij dat wij individueel schitteren dan dat we gezamenlijk de wedstrijd voor ze winnen.
Maak je daarom eens even niet druk om je eigen ego als er voor een probleem verschillende oplossingen mogelijk zijn en bekijk deze alsof je ze allemaal zelf had bedacht: welke zou je dan kiezen?
Is dat nog steeds je eigen oplossing, gooi dan alles in de strijd om die gerealiseerd te krijgen.
Maar is het de oplossing van iemand anders, doe dan niet flauw en steun die met volle overtuiging.
 
Hoe makkelijk dit ook klinkt, in de praktijk kan het een behoorlijke opgave zijn.
Niet veel later stonden dezelfde ontwikkelaars namelijk weer schuimbekkend tegenover elkaar. Weer een verschil van mening over de optimale programmeeroplossing voor een bepaald probleem. Van een compromis was ditmaal echter geen sprake (dat was in zekere zin natuurlijk al vooruitgang). ‘Jij neemt mijn oplossing, want die zit al in de applicatie!’ brieste de een. ‘Maar dat is een waardeloze manier van werken,’ snoof de ander.
Toen de gemoederen opnieuw bedaard waren, bleek dat deze keer wel degelijk één van beide oplossingen veel beter was dan de andere en helaas was dat de nieuw bedachte. Het was voor de maker van de ‘oude’ oplossing wel even slikken, maar gezien de toekomstige ontwikkelingen zouden we met die slechtere methode niet lang meer wegkomen, gaf ook hij uiteindelijk toe. Dus werd de nieuwe functionaliteit op de nieuwe manier gebouwd en werd die manier vanaf dat moment ook de standaard binnen het team; in een volgende release werd ook de rest van de applicatie naar de nieuwe werkwijze omgezet.
Opgelost.
(En toen stond het ook meteen 1 – 1; dat was voor het evenwicht tussen de heren – beiden een Romário in het diepst van hun gedachten – wel zo prettig.)
 
Ongeveer dit (nou, beetje korter) zei ik tegen mijn leidinggevende, die nog gebogen zat over de sluit-gemakkelijk-compromissen-stelling.
Even was het stil. Zo had hij het nog niet bekeken.
Maar er zat wat in.
En hij wijzigde mijn score naar ‘niet van toepassing’.
 
016-360 graden - Zorro op hei
360 graden en niet van toepassing

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>