Sharing IT Best Practices with youSharing IT Best Practices with you
Kwaliteitsbewustzijn
Bij het maken van producten in het algemeen is altijd sprake van een zeker kwaliteitsbewustzijn. Als niet dit het geval zou zijn zouden schepen zinken, huizen onbewoonbaar zijn en is een voetbal na één trap lek. Vaak wordt uitgegaan van beproefde concepten die tot norm verheven zijn. Dit maakt nieuw onderzoek overbodig en drukt de kosten. Als toch iets nieuws gewenst is wendt men zich tot dure bureaus die het product zullen ontwikkelen. Instituten zoals TNO of KEMA zullen het product dan testen op veiligheid en betrouwbaarheid.
Ook bij de bouw van applicaties is enig kwaliteitsbewustzijn onontbeerlijk, de gebruiker moet immers zijn werk kunnen doen. Hoewel er voor auto’s, gebouwen, schepen en speelgoed reeds lange tijd minimumeisen bestaan is het kwaliteitsbewustzijn binnen de IT pas later goed doorgedrongen.
Iedereen heeft gevoel voor kwaliteit, in de meeste gevallen is dat een subjectief gevoel. Bij het denken aan kwaliteit komen vaak de volgende termen naar voren:
Blijkbaar is kwaliteit een vaag begrip.
Hoewel kwaliteitsbewustzijn iets is dat zich moeilijk laat omschrijven bestaat er een grote behoefte om de kwaliteit van producten vast te stellen. Pas als de kwaliteit van een product bekend is kan het vergeleken worden met de kwaliteit van andere producten of met aan het product gestelde normen. Hierbij rijst de vraag “Wat is kwaliteit”. Het begrip kwaliteit en daarmee het kwaliteitsbewustzijn vraagt om een nadere definitie.
Dat wil zeggen :
Met deze definitie zijn drie meetpunten voor kwaliteit geïntroduceerd wat een hele stap vooruit is ten opzichte van het alleen maar herkennen van kwaliteit. Toch kan over deze meetpunten nog een hele strijd losbranden tussen de klant en de leverancier. Want aan het einde van de rit is niet altijd duidelijk wat alweer alle opties waren, wat de gestelde tijd was en wat zijn (na meer- en minderwerk) aanvaardbare kosten?
Als een webshop beweert dat bestellingen binnen 24 uur worden geleverd heeft dat bedrijf bij de klant een bepaalde verwachting gewekt. Zo’n bewering doen je dan ook niet zomaar als webshop. In de eerste plaats vereist dit een groot vertrouwen in DHL of andere besteldiensten. Ten tweede dienen alle producten op voorraad te zijn, wat een enorme investering vergt. In de derde plaats dient de gehele orderverwerking soepel te verlopen, men kan zich daarbij niet veroorloven dat het informatiesysteem voor langere tijd buiten werking is.
De webshop levert volgens definitie twee echter pas kwaliteit als de bestelling bijvoorbeeld dezelfde dag of direct de volgende morgen wordt afgeleverd.
Het is echter de vraag of de klant daar wel zo blij mee zal zijn. Waarschijnlijk is hij meer tevreden als hij het exacte moment van aflevering kan afspreken.
Met andere woorden de klant zal voor zichzelf zijn verwachtingen moeten definiëren.
Of wel de requirements, eisen en normen die hij aan producten en diensten stelt moeten vastleggen.
De vragen over de opties, de gestelde tijd en de kosten die bij definitie één nog onbeantwoord bleven moeten hier door de klant vooraf al beantwoord zijn.
Bij definitie twee waren we het al eens over de gestelde eisen. Het venijn van definitie drie zit hem in de staart. Software ontwikkelaars weten namelijk in de meeste gevallen niet wat de vanzelfsprekende behoeften van de gebruikers zijn.
Aan de ontwikkelaar dus de opdracht om deze behoeften zoveel mogelijk in kaart te brengen en aan te geven wat wel en wat niet mogelijk is. Aan de gebruiker de opdracht om zijn behoeften (lees verwachtingen) zoveel mogelijk naar voren te brengen. Deze activiteiten vinden plaats tijdens het vooronderzoek, de informatie analyse en de requirements analyse.
Het doel van deze activiteiten moet zijn om alle vanzelfsprekende behoeften over te hevelen naar de gestelde eisen en de onmogelijke verwachtingen bij te stellen.
In een winkel speelt een dergelijk proces zich niet af. De klant verwacht daar echter ook kwaliteit. Vandaar de toenemende eisen ten aanzien van de productspecificaties (ingrediënten) op de verpakking en op bijsluiters. Hierdoor neemt de kwaliteit van het product toe.
De beginfase van een project zal door het uitwerken van de verwachtingen langer duren dan verwacht; dit wordt echter terugverdient aan het eind omdat er dan minder vragen zijn t.a.v. niet eerder geuite verwachtingen. Uiteindelijk zien klant en leverancier beide tevreden terug op een geslaagd project.
Discussieer mee op LinkedIn.
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.