Het gevaar van checklisten.

ITpedia staat overvol met checklisten van velerlei aard. Deze checklisten kunnen je helpen bij het beoordelen van IT producten en IT organisaties. Omdat het kant en klare checklisten zijn kan je meteen aan de slag en dat scheelt veel tijd. Daarbij kunnen de checklisten je op punten wijzen waar je nog niet eerder aan hebt gedacht. Niet te min schuilt er een aantal gevaren aan het gebruik van checklisten. Voordat je lukraak begint met invullen wil ik je graag eerst op deze punten wijzen.

De gevaren waarmee je te maken kan krijgen bij het gebruiken van checklisten

 1. Onbezonnen beginnen.

 Stel je hebt een ontwerp voor je liggen. Je leest het even door en legt het vervolgens langs de bijhorende checklist. Stjap Stjap Stjap, klaar.
Deze werkwijze kan tot vervelende situaties leiden waarbij de makers van het ontwerp met je in discussie zullen gaan. Je moet vooraf duidelijk maken dat het ontwerp tegen een bepaalde checklist gehouden zal worden en wat er wordt verwacht. Daarnaast moet je ook de checklist goed doorlezen en de vragen als het ware mappen op het ontwerp. Er moet in je hoofd een soort synchronisatie plaatsvinden tussen het ontwerp en de checklist. Van beide moet je de bedoeling begrijpen.

2. De verkeerde checklist.

Niet iedere methodologie gebruikt hetzelfde jargon. De invulling van het begrip Ontwerp kan in jou project anders zijn als in het checklistensysteem. Je moet dus wel opletten welke checklist je pakt en eventueel bepaalde checklisten combineren als dat nodig is.
Een ander voorbeeld van een verkeerde checklist is als er wordt gewerkt aan een speciaal project. Opdrachten die niet vaak voorkomen of onder speciale omstandigheden plaatsvinden kunnen afwijken van het in de checklist gevraagde. Het is vervelend als je er achter moet komen als je halverwege de checklist bent.

3. De te gedetailleerde checklist.

Soms kom je op checklisten vragen tegen waarvan je je afvraagd waarom ze er op staan. Bepaalde vragen zijn inderdaad niet altijd in alle gevallen nodig. Ze staan echter vanwege de volledigheid op de lijst. Deze vragen kunnen eenvoudig geskipt worden of als gemiddeld worden beoordeeld.

4. De onvolledige checklist.

Dit is het grootste gevaar van het gebruik van checklisten. Je vertrouwt op de checklist, rond hem af en denkt dat alles goed is. Alleen net die ene cruciale vraag ontbreekt waardoor het project toch nog tegenslag krijgt te verduren. Het bestaan van de checklisten is fijn, maar ontslaat je er niet van om na te blijven denken.

We willen natuurlijk geen afbreuk doen aan het checklistensysteem want de voordelen wegen ruim op tegen de nadelen. We willen je echter wel waarschuwen voor de genoemde gevaren. Het advies is om de beoordeling van IT producten goed voor te bereiden en wel overwogen de checklisten te kiezen. Blijf nadenken en maak gebruik van je eigen kennis en ervaring. Lees hier meer over het gebruik van de checklisten van ITpedia.

Boeken over dit onderwerp

User Stories Applied: For Agile Software Development

Auteur: Mike Cohn
The best way to build software that meets users’ needs is to begin with ‘user stories’: simple, clear, brief descriptions of functionality that will be valuable to real users. In User Stories Applied, Mike Cohn provides you with a front-to-back blueprint for writing these user stories and weaving them into your development lifecycle.
Europrijs: 47,95
Bestellen

Ant in Action 2nd edition of Java Development with Ant

Auteur: Steve Loughran
Ant in Action is een complete gids voor het bouwen testen, hergebruiken en inzetten van Java applicaties met gebruik van Ant. Zowel kleine persoonlijke projecten als grote bedrijfsprojecten waaraan meerder teams samenwerken worden in het boek beschreven.
Europrijs: 38,95
Bestellen

Meer boeken over BiSL vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Aansluiting tools op organisatie 21 vragen.
Sidebar