Adviseren

Als je al de juiste inzichten hebt verzameld, is het tijd om af te ronden. Op één A4-tje vat je samen wat je gevonden hebt en je geeft een advies.

De opzet van die samenvatting ligt erg voor de hand, met dank aan alle vorige stappen. Je wist namelijk bij de risico analyse al wat de belangrijkste onderdelen waren en wat de belangrijkste soorten kwaliteit waren  (functionaliteit, gebruiksvriendelijkheid, beveiliging, enzovoort). En dan ziet zo’n samenvatting er ongeveer als volgt uit.

advies

Let erop dat je oordeel niet alleen afhangt van de dingen die fout zijn. Het hangt ook af van dingen die je nog niet hebt kunnen bekijken. En dat kan allerlei redenen hebben; geen tijd, geen goede testomgeving, zwevende specificaties, noem maar op. Allemaal zaken die ons beperken in het krijgen van genoeg inzicht.

Het laatste stukje is het advies. Je weegt alle resultaten tegen elkaar af schrijft in een paar zinnen je overwegingen op. En wat ik (samen met mijn collega’s) erg krachtig vind, is als het advies eindigt met de zin “Daarom is het advies positief” of “Daarom is het advies negatief“. En dat op basis van de huidige stand van zaken. Alles wat daar tussenin zit, zoals “positief mits”, moet eigenlijk voorkomen worden. Eén uitzondering zou zijn als je na het live zetten nog iets specifieks moet controleren. Maar dat is dus een tekortkoming van je testomgeving en moet in een volgend project voorkomen worden.

De samenvatting en het advies stop je normaal gesproken in één document met de naam “vrijgave advies“. Door nu eens één keer een duur woord te introduceren, krijgt je geschreven advies al snel een plek in het ontwikkelproces. Zeker als het je lukt om die vrijgave adviezen van constante inhoudelijke kwaliteit te laten zijn. Maar dat lukt je; je hebt jezelf namelijk net een simpele en toepasbare methode eigen gemaakt!

> > Nog één keer het overzicht doen?

Plaats als eerste een reactie!

Naam*: E-mail*: