Problemen, problemen...
"De basisregel is dat je niet langer dan een half uur mag rommelen."
Ik wordt regelmatig gevraagd om technische problemen op te lossen. De methode voor het oplossen van een probleem is simpel. Je kunt elk probleem aan als je een probleem op een vaste manier aanpakt; de methode is namelijk even eenvoudig als veelzijdig. Overigens kan een probleem natuurlijk nog steeds ingewikkeld of zelfs onoplosbaar zijn. Echter, het achterhalen van de oorzaak van een probleem is al meer dan de helft van de oplossing.
5 stappen voor het oplossen van problemen:
- Isoleren
- Analyseren
- Documenteren
- Repareren
- Verifiëren
Ik realiseer me dat dit flauw en simpel klinkt, maar alle goede methodieken lijken simpeler dan ze zijn. Laat ik beginnen met een belangrijk uitgangspunt, dat in de filosofie bekend staat als Ockhams Razor ('het scheermes van Ockham'): hetgeen vrij vertaald zoveel wil zeggen als 'iets is zo simpel als mogelijk, totdat het tegendeel wordt bewezen'. Het is belangrijk om je bij Het Oplossen Van Problemen het jezelf niet moeilijker te maken als strict noodzakelijk en uit te gaan van de simpelste verklarende oplossing. Een probleem is altijd kleiner dan je denkt; de impact vaak groter dan je weet.
Omdat ik in de IT werk, zal ik mijn verhaal IT-gerelateerd maken. In de praktijk kun je het echter overal toepassen.
Alleereerst moet je Isoleren: Wat is het probleem? Is het mijn probleem? (Zeker in grote organisaties moet je niet andermans problemen gaan oplossen, omdat je daarmee uiteindelijk overspannen thuis komt te zitten, maar dat is een ander verhaal) Wanneer ontstaat het probleem? Is het probleem herhaalbaar? Is er een recente verandering? Is er wel een probleem? Vraagt 'men' wel om het oplossen van het probleem? Is er eerder aan het probleem gewerkt?
Vaak komt een probleem binnen als 'het systeem doet het niet' of in soortgelijke onzin. Hierbij moet je je realiseren dat 'het systeem' ook helemaal niets hoeft te doen. Bovendien is het feit dat iets niet of gedeeltelijk werkt vaak slechts een (slecht) symptoom van een ander probleem. Het is dus zaak om heel goed uit te zoeken wat exact het probleem is. Hierbij is het van belang dat je door blijft spitten tot je heel precies weet wat er daadwerkelijk faalt. Veel problemen vooroorzaken verderop in de keten pas problemen. Hierbij moet je zoeken naar wat in Java de rootcause heet; de eerste veroorzaker.
Veel oorzaken verschuilen zich achter andere problemen. Zorg dat je tot in detail elke stap van het probleem kan volgen. Wat werkt en wat werkt niet meer? Verklein het probleem en de scope. Breek het in stukjes en maak die dan weer kleiner. In welke situatie ontstaat het probleem? Heb je te maken met een enkel probleem of met meerdere door elkaar? Daarbij is het nog makkelijk als iets gewoon stuk is, maar met intermitterende problemen ("soms doet-ie het, soms niet") is het heel belangrijk om de wel en niet gevallen heel goed te onderzoeken.
Tijdens het isoleren, moet je continue Analyseren waar je bent, wat je weet, hoe ver je nog moet, wat je nog niet weet en of je al weet wat het probleem veroorzaakt. Continue, na elke stap is er dus reflectie nodig. Pas als je een stap hebt uitgesloten moet je doorgaan naar de volgende. Pas als je bepaald hebt wat de volgende stap is kun je doorgaan. Je moet continue je zoekstrategie aanpassen en evalueren. De basisregel is dat je niet langer dan een half uur mag rommelen. Soms helpt rommelen je namelijk even op het goede spoor. Moet je langer rommelen, dan is strategie en (zelf-) coördinatie veel belangrijker. Ook onder tijdsdruk of externe druk moet je je niet gek laten maken. Gestructureerd werken levert niet per definitie de korste oplostijd op, maar wel de beste oplossing. Bovendien kun je de oplostijd kwantificeren ("Ik moet nog 5 dingen testen dus het duurt nog maximaal 3 uur").
Als ik aan een probleem werk, zorg ik altijd voor pen en papier. Je moet namelijk aantekeningen maken. Wie heb je gesproken? Wat is de foutcode? Wie kun je nog bellen en wat is zijn telefoonnummer? En teken ook eens een plaatje en verifiëer met anderen dat je het snapt wat het probleem is en waar het zit. Zorg zeker dat je weet wat je gedaan hebt en documenteer stappen die ongedaan kunt maken. Probeer tijdens het zoeken ook niet meer stuk te maken en voorkom al helemaal dat je een destructieve stap maakt. Onthoud dat je nog steeds aan het zoeken bent en niet 'aan het proberen'. En schrijf op wat je doet, wat je hebt gedaan en wat je nog wilt gaan doen. Want misschien moet je morgen verder of moet een collega het van je overnemen.
Vragen is goed. Indien van jou wordt verwacht om een probleem op te lossen, verwacht niemand dat je het alleen doet. Ook al ben je nog zo thuis in de materie, een mens heeft het nodig om dingen te spiegelen. Hoe vaak zie je niet plots het probleem nadat je een ander hebt proberen uit te leggen wat je doet en waarom? Zelf kun je in cirkeltjes draaien en praten met iemand trekt je uit deze cirkel. Bovendien is het vaak belangrijker om de goede vraag te stellen dan het juiste antwoord te geven.
Indien je heel zeker weet wat het probleem is, kun je pas door naar de laatste fase: Repareren. Maken en testen. Verifiëren en controleren. Check and Double Check.
Overigens is men mij vaak dankbaar geweest doordat ik alleen maar vertelde waar het probleem zat, wat het veroorzaakte en hoe men het kon gaan oplossen of voorkomen. Niet alle problemen hoeven altijd te worden opgelost!
Maar een probleem is uiteindelijk pas opgelost als het geïsoleerd, geanalyseerd, beschreven, gerepareerd en getest is. Indien één schakel ontbreekt is het probleem nog steeds 'open' en je werk niet af.
Maar als je dan uiteindelijk een probleem hebt opgelost, mag je jezelf best belonen en anderen delen in het succes. Tenslotte geldt: gebak dient de mens.
Overigens is er ook een heel leuk boekje: Winnie the Pooh on Problem Solving.
