Het gevaar van aannames op basis van ervaring

Stel je voor... je rijdt naar een bepaalde plaats

Een plaats waar je de afgelopen 5 jaar elke dag naartoe gereden bent, steeds via dezelfde route, over dezelfde verlaten weg, waar je nog nooit een andere auto hebt gezien. Geleidelijk aan raak je vertrouwd met deze route en ga je ervan uit dat je, zoals altijd, de enige auto bent op deze weg. Maar dan, op een gegeven moment, doemt er ineens een auto voor je op... er bleek al die tijd een zijstraat te zijn geweest, maar dat was je nog nooit opgevallen, of misschien was je dat al helemaal vergeten. Je trapt op de rem en komt gelukkig net op tijd tot stilstand. Aannames zijn je bijna fataal geworden.

Gelukkig zijn in ons werk de aannames nooit zo levensbedreigend als de aannames die we doen in het verkeer. Toch kunnen aannames verregaande gevolgen hebben en we moeten altijd uit blijven kijken.

Stel je voor dat je een website developer bent.

Je nieuwste klant is op zoek naar een nieuwe site voor een bejaardentehuis, omdat de huidige site verouderd is en niet goed opvalt. Dus je bouwt een nieuwe opvallende website gebaseerd op de veronderstelling dat men met 'opvallend' het volgende bedoelt: modern design, social media functies, dynamische inhoud. Maar de site blijkt niet zo succesvol als de klant had verwacht... Dat is vreemd... Je hebt precies gebouwd wat de klant wilde. Maar heb je ook gebouwd wat de bezoekers van de site willen? De gemiddelde gebruiker is tussen de 50 en 65 jaar en is op zoek naar een nieuw thuis voor hun vader en/of moeder. Zij zijn niet opgegroeid in het digitale tijdperk en voelen zich misschien helemaal niet op hun gemak als ze surfen op een opvallende, dynamische website vol met twitterfeeds en links naar social media. Het enige wat ze willen is een goede indruk krijgen van het bejaardentehuis en ze willen er gerust op kunnen zijn dat daar goed voor hun ouders zal worden gezorgd.

Hoe meer ervaring je opbouwt, hoe meer je er voor moet waken dat je geen aannames doet. Doe dus altijd nog een keer extra navraag bij je klant EN de doelgroep.

Een ander bekend ervaringsgevaar is 'de vloek van kennis'. Hoewel het klinkt als een nieuwe film in de Pirates of the Caribbean serie, is de vloek van kennis een cognitief vooroordeel waar nagenoeg iedereen met vakkennis in een specifieke sector door wordt beïnvloed. Het betekent dat beter geïnformeerde partijen het uiterst moeilijk vinden om over problemen te denken vanuit het perspectief van minder geïnformeerde partijen. Je vraagt je misschien af waarom economen er niet altijd in slagen de juiste beursvoorspellingen te doen. Iedereen met wat geld om handen kan aandelen kopen. Je hoeft er geen expert voor te zijn, of zelfs maar verstand te hebben van economie. Dat is de voornaamste reden waarom economen het vaak bij het verkeerde eind hebben. Zij beschikken over gespecialiseerde kennis, en kunnen daardoor niet verder kijken dan deze expertise. Ze vinden het dus moeilijk om zich voor te stellen hoe minder geïnformeerde mensen zullen reageren op veranderingen in de markt.

Hetzelfde geldt voor IT. Dat is waarom we altijd op moeten blijven letten, en moeten blijven denken vanuit het oogpunt van de klant. Inzicht krijgen in hun ervaring en standpunt is de sleutel tot het creëren van de perfecte oplossing voor de eindgebruiker.

Dus hoe gaan we om met aannames...?

Ik zou graag zeggen 'nou gewoon,' en je een prachtige oneliner geven... Maar zoals altijd is 'gewoon' niet het correcte antwoord.

Om de drang om op de automatische piloot over te schakelen (waardoor de vloek van de kennis zijn kans kan grijpen) te bestrijden, hebben we een methodologie ontwikkeld die gebaseerd is op verschillende Agile principes. Hierdoor worden we gedwongen onze gebaseerdeindgebruiker bij elke fase van het project te betrekken. Het proces begint als onze klanten na aan het denken zijn over een project, maar nog geen oplossing hebben gedefinieerd. En het eindigt... nou, eigenlijk nooit. De eindgebruiker verwerft nieuwe inzichten door met je oplossing te werken. Dit kan dan vervolgens resulteren in nieuwe verbeteringen.

Met de watervalmethode wordt aan het begin van een project van tevoren een analyse gemaakt door een business analist. Soms wordt de gebruiker bij deze analyse betrokken, maar dit is niet altijd het geval. Vervolgens gaan ontwikkelaars in conclaaf om in afzondering iets te ontwikkelen. Komt er na verloop van tijd witte rook uit de schoorsteen... dan begint het proces van user acceptance testing (UAT). Het moet pijnlijk voor de ontwikkelaars zijn als ze zich na het testen realiseren dat het product dat zij o zo zorgvuldig hebben samengesteld niet de oplossing biedt waar de gebruikers op hadden gehoopt. Het is dan te laat om ingrijpende veranderingen door te voeren zonder daar veel meer tijd en budget voor uit te trekken.

Met een Agile projectmethode kom je een heel eind. Door om de 2 à 3 weken testbare versies uit te brengen, kunnen de gebruikers tijdens de ontwikkeling van het project geleidelijk de functionaliteit testen en hun feedback geven. Met deze aanpak worden de inzichten van de gebruiker die zijn verkregen gedurende het project er meteen in verwerkt. Dit garandeert een betere afstemming tussen de behoeften van de gebruiker en de oplossing die je aan het creëren bent voor hun behoeften. Gebruikers van deze methode zijn voorstander van 'continue implementatie': een werkwijze waarbij nieuw ontwikkelde functies onmiddellijk worden geïmplementeerd in een productieomgeving in plaats van in batches om de 2 à 3 weken. Dit stelt ons in staat het systeem (en daarmee ook de achterliggende aannames) in de praktijk te valideren, waardevolle feedback te krijgen van echte gebruikers, en gerichte experimenten uit te voeren om te valideren welke aanpak het beste werkt.

Door onze methodologie te combineren met constante betrokkenheid van de gebruikers voorkom je de meest rampzalige aanname in IT: dat wij weten hoe de werknemers hun werk doen en wat ze nodig hebben... het gevaar van ervaring!

Maar moeten we er altijd voor zorgen dat aannames worden voorkomen?

Laat me het wat ingewikkelder maken.

Nogmaals... Stel je voor: Je gaat al 10 jaar naar dezelfde supermarkt. We kunnen gerust aannemen dat de cornflakes nog steeds in hetzelfde gangpad staan, zelfs op dezelfde plank als gisteren. Als je niet zou aannemen waar je de cornflakes kunt vinden... tja, in dat geval zou je enorm veel tijd verspillen, omdat je de hele winkel door moet om te zoeken. En dat niet één keer, maar ieder keer weer.

Hetzelfde geldt voor ons werk. Als we ons werk zouden doen zonder op onze ervaring te vertrouwen, zouden we niet in staat zijn om inschattingen te maken wat betreft budget en tijd. Elke inschatting is gebaseerd op aannames. Hoe meer ervaring je hebt, hoe nauwkeuriger deze aannames zullen zijn. Maar leiden zij tot goede en betrouwbare inschattingen? Niet noodzakelijkerwijs.

Nog even weer terugkomend op mijn rij-metafoor... We nemen elke dag dezelfde route naar werk. Op basis van mijn ervaring kan ik inschatten dat het me 30 minuten zal kosten om naar werk te rijden. Maar wat als er op de radio files zijn aangekondigd en ik heb dat niet gehoord... Dan is mijn inschatting dus niet juist.

Bij ACA Group gebruiken we een aantal basispraktijken bij het maken van inschattingen. Om te beginnen: het is een teamsport. Wij maken inschattingen nooit alleen, en hoewel inschatten een serieuze zaak is, doen wij dat met behulp van een spel genaamd Planning Poker. Laat me het uitleggen: planning poker is gebaseerd op het principe dat we als groep betere inschattingen kunnen maken. Dus lezen we het verhaal (chunks van de functionaliteit) hardop voor, waarna iedereen een kaart neemt (die staat voor de complexiteit) en deze met het cijfer naar beneden op tafel legt. Als iedereen een kaart heeft gekozen, worden ze allemaal tegelijk omgedraaid. Als er verschillende nummers verschijnen, discussiëren we over 'hoe' en 'waarom'. De aannames die de basis vormen voor de inschatting die iemand heeft gemaakt, komen zo bovendrijven en kunnen dan worden besproken en gevalideerd. Dan volgt er een nieuwe inschattingsronde. Het proces gaat net zo lang door tot er consensus is bereikt. Het eindresultaat: een betere inschatting en een grondig begrip van de aannames met betrekking tot deze inschatting. Deze expliciete aannames zijn er om gevalideerd te worden door onze stakeholders, een prima eerste tool om ons begrip van de scope te valideren. Dus elimineren we altijd alle aannames? Los van het feit dat dit bijna onmogelijk zou zijn, zorgt het expliciet maken van aannames er ook voor dat een hoop verspilling wordt voorkomen.

Wil je meer weten over deze Agile Estimation? Lees dan dit boek van Mike Cohn.

Hé! Dit is tegenstrijdig... Dus hoe zit het met deze aannames?

Moeten we ze proberen te vermijden? Of moeten we erop vertrouwen?

Als je aanneemt dat je alles weet, zul je nooit meer verwondering ervaren.
Zoals Aristoteles al zei: "Het was hun verwondering, verbazing, die de mensen ertoe heeft aangezet te filosoferen."

Een proces dat aannames valideert door middel van goed uitgevoerde experimenten en snelle feedback, heeft bewezen geweldige resultaten opgeleverd. Het komt er dus op neer dat, mits je aannames goed beheert, ze prachtige dingen voort kunnen brengen. Wees je er wel van bewust dat de Vloek van Kennis op de loer ligt en wacht om op een onbewaakt ogenblik de macht over te nemen.

Wil je ook deel uitmaken van ons team?

Wil je een van onze teamleden ontmoeten?
Wil je ook deel uitmaken van ons team?
Wij zijn altijd op zoek naar nieuwe gemotiveerde professionals om het ACA-team te komen versterken!
Neem een kijkje op onze nieuwe ACA-vacaturewebsite: http://www.aca-it.be/jobs