Complex probleem? Een simpele oplossing is genoeg

0

De dagelijkse praktijk van de IT specialist bestaat uit het oplossen van problemen.  Nu houdt een IT specialist wel van een uitdaging.  De oplossing wordt dan ook vaak gezicht in de lijn van het probleem, dat vaak complex is. Geef een ingewikkeld probleem aan een groep hoogopgeleide puzzelaars en je krijgt een ingewikkelde oplossing.  Engineers zullen niet vaak zeggen dat iets té complex is. Ze zien het juist als een mooie uitdaging. Want een probleem waarvoor geen oplossing gevonden kan worden bestaat niet.

zero-gravity-pen_Het verhaal gaat dat NASA in de jaren 60 op zoek was naar een pen voor gebruik door astronauten tijdens een ruimtereis. Ze legden deze vraag neer bij hun beste engineers, die 3 jaar later en enkele miljoenen verder met de oplossing kwamen: Een pen die kon schrijven in gewichtsloosheid, bestand was tegen 3 keer normale druk en temperaturen tussen tot 150 graden aankon. Toen ze deze oplossing aan hun Russische collega’s lieten zien, vertelden deze Russische collega’s dat ze hun astronauten gewoon een potlood meegaven.

Achterliggende vraag of wens

Dit voorbeeld geeft helder weer dat we vaak proberen het probleem op te lossen (mijn pen werkt niet in gewichtsloosheid) en niet kijken naar de achterliggende vraag of wens (schrijven in de ruimte). We moeten daarom vaker stil staan bij de achtergrond van onze problemen. Zijn ze wel echt een probleem, of alleen maar een symptoom? Kunnen we wellicht een ingewikkelde oplossing voorkomen door te onderzoeken wat de oorzaak is?

Indicatoren

Als oplossingsgerichte IT Engineers worstelen we met dit dilemma. Zijn we slechts bezig met het oplossen van problemen? Of zijn we echt de oorzaken aan het wegnemen? En hoe herken je dit? Indicatoren hiervoor zijn bijvoorbeeld onevenredige complexiteit of een oplossing die lijkt te werken maar ergens anders veel problemen veroorzaakt.

De volgende vragen kunnen helpen bij het vinden van de achterliggende oorzaak:

  • Waarom hebben we dit echt nodig?
  • En waarom hebben we dat dan nodig?
  • Wat gebeurt er als we niets doen en deze functie helemaal weg laten?
  • Wat is de achterliggende reden van het implementeren van deze regeling/code/functie?
  • Hebben we al deze uitzonderingen echt nodig? En als ze optreden, kunnen we ze dan anders afhandelen?
  • Wat zou er gebeuren als dit hele systeem er niet is?
  • Wie heeft er last als dit verkeerd gaat?

Speurtocht essentieel

De speurtocht naar de achterliggende oorzaak kan bevestigen dat de complexiteit echt nodig is. Of er kan blijken dat er een eenvoudigere oplossing mogelijk is. Het kan zelfs blijken dat er helemaal geen oplossing meer nodig is omdat de achterliggende noodzaak is weggevallen. Deze speurtocht is essentieel. Want je wilt zeker niet overblijven met een oplossing waarvoor je op zoek moet naar een probleem.

AMIS streeft er naar om zijn IT oplossingen eenvoudig te houden.  Dit maakt de realisatie goedkoper en het product beter onderhoudbaar. En dat is een mooie uitdaging voor onze Engineers: ga op zoek naar een oplossing die hetzelfde kan maar die eenvoudiger is.

 

About Author

Robbrecht van Amerongen is Business Innovation Manager at AMIS Services. He has a vast experience in managing software development and delivery projects and growing the development unit of AMIS. He is able to utilize new technologies and methodologies to valuable products and services for his customers. His expertise lies in all aspects of software engineering; ranging from continuous delivery, provisioning, cloud computing, user experience and wearables.Robbrecht is also an Agile coach and Certified Agile Master. He has experience in managing Agile projects with Scrum (first with DSDM) ranging back to 1999. Robbrecht is a strong proponent of the agile principles. Robbrecht is agile examiner for the agile foundation, practitioner and master certificate.

Comments are closed.