Context Driven Clichés

Door: Olaf Agterbosch, Managing Consultant bij ViQiT

Herken je het volgende? De laatste jaren hoor ik vaak de woorden ‘Context Driven’ als het om ontwikkelingen in de ICT gaat. Kennelijk geven degenen die het gebruiken aan dat ze bij hun activiteiten veel rekening houden met de context ofwel de totale omgeving waarin hun activiteiten plaatsvinden. Alsof voor die tijd niemand daar rekening mee hield praten ze over het belang van de omgeving en de manier waarop hun producten, diensten en processen daarop moeten aansluiten.

Ik vraag me weleens af waarom mensen ervoor kiezen een open deur in te trappen en dan ook nog eens roepen hoe goed men bezig is. Maar wat nog erger is: mensen gaan het naroepen. Iedereen praat elkaar na en voor je het weet is de nieuwste hype geboren. Een hype die men volledig uitwringt door bijvoorbeeld consultants die niet zullen nalaten het grote belang van deze ontwikkeling te benadrukken. U kunt echt niet meer zonder!

Oude wijn nieuwe zakken. Oude wijn in Agilezakken. Oude wijn in verbleekte zakken…

Kennelijk wel marketingpotentieel

Context Driven testing is hier een voorbeeld van, een overgehypte loot aan de Agile boom. Het leuke is dat er ook niets mis mee is, met je bewust zijn van de omgeving waarin je je werk uitvoert. Wat ik jammer vind is dat veel mensen zich in deze ontwikkeling laten meezuigen. Hard mee rennen met de nieuwste hype.

Loont dat dan? Mogelijk. Een voorspelling van de ontwikkelingen voor de komende jaren, waarin we ons bezig gaan houden met:

  • Context Driven Requirements engineering;
  • Context Driven Applicatie Beheer;
  • Context Driven Regievoering;
  • Context Driven Projectmanagement;
  • Context Driven CRM;
  • Context Driven Innovatie;
  • Context Driven Migratie;
  • Context Driven Whatever, etc.

Wat zegt u? Dat deden we al lang? Dan hebben we kennelijk niet goed opgelet.

Laten we nou toch gewoon eens aan het werk gaan. En ja, werk, zoals de goeden onder ons altijd al deden Context Driven. Of Risk-Based. Of Business Case-Driven. Maar hou alsjeblieft op met die goedkope semantische trucjes. En doe niet zo interessant als je toch weer hetzelfde kunstje uitvoert. Daar wordt het kunstje niet beter van. Probeer eens eenvoudig beter echt toegevoegde waarde te creëren. Misschien minder herkenbaar voor u en anderen, wel effectief!

Geplaatst in Column, Medewerker aan het woord | 4 reacties

Van Psycholoog naar Tester, wie had dat gedacht?

Door: Matthias Coosen, consultant bij ViQiT

Nog niet zo lang geleden begon mijn werkdag in een spreekkamer, twee comfortabele stoelen, en een gesprek met een cliënt over een ‘groep’ die hem al jarenlang lastig viel, tegen hem praatte in zijn hoofd, zijn huis hadden volgehangen met camera’s en waarvan hij vrij zeker wist dat ze hem al zijn geld afhandig wilde maken (ook al had hij dat niet). Enkele maanden later begint mijn werkdag aan een bureau met laptop open en studerend uit een lijvig boekwerk om nieuwe kennis op te doen over dekkingsgraden, testontwerptechnieken, beslistabellen en het V-model. Wat is er gebeurd? Ben ik zelf de cliënt geworden? Nee, vandaag wil ik uit te doeken doen hoe ik de overstap heb gemaakt van Psycholoog naar IT-Tester en hoe deze rollen eigenlijk meer overeenkomsten hebben dan je zou denken.

WWeMensen vroegen wel eens: waarom de keuze voor psychologie? Voor mij lag dit in het mysterie van het brein, dat wilde ik ontrafelen. Ik zag het brein als een grote puzzel waar de oplossing voor gevonden moest worden. Als die oplossing eenmaal gevonden was dan konden we elkaar een stuk beter begrijpen en zouden psychische problemen tot het verleden horen. Eigenlijk zag ik het brein als een systeem wat je kan testen, waar je een kwaliteitsoordeel over kan vellen en wat je dus ook kan herstellen en beter kan maken. Nu heeft mijn carrière in de geestelijke gezondheidszorg me geleerd dat er inderdaad veel te zeggen is over het brein, er is ook wel wat in aan te passen, maar het blijft in grote delen nog altijd een mysterie. Wellicht eigenlijk ook fijner dat we (nog) niet alles over onszelf weten, maar in mijn werk vond ik steeds lastiger om te gaan met de vaagheid en subjectiviteit van ons brein. Voor mijn eigen geestelijke gezondheid was het beter om mijn carrière een andere richting op te sturen.

Als eerste vroeg ik me af wat ik wel prettig vond in mijn werk als psycholoog. Ik vond het onderzoeken boeiend, het diagnosticeren, vragen stellen. Verder het eerste contact met de cliënt, zijn verhaal leren kennen, daar dieper op ingaan. Vervolgens samen kijken naar de mogelijkheden tot verandering, tot een oplossing te komen. Het samenwerken met mijn collega’s was een prettig onderdeel, de gedeelde verantwoordelijkheid, elkaar verder helpen bij lastige situaties. Verder vond ik het altijd fijn als ik iets concreets bereikt had met een cliënt, als hij een maand clean was, als hij weer zelfstandig naar buiten durfde.

De volgende vraag was dan voor mij, welke sector trekt me aan. Ik heb van nature altijd wel een interesse en aanleg gehad voor de IT sector en ben me dus daar meer in gaan verdiepen. Het IT vak is heel breed en er zijn vele verschillende rollen. Door gesprekken met vrienden werkzaam in deze branche en een uitgebreid gesprek met ViQiT kwam de rol van tester steeds duidelijker op mijn netvlies. Ik zag ook de overeenkomst met mijn eerdere rol. Ook als tester ben je aan het onderzoeken, uitpluizen en samenwerken. Net als een psycholoog houd je de ander een spiegel voor, reikt ze handvaten aan, maar laat ze vervolgens zelf het werk doen om tot een oplossing te komen. Zaken waar ik al ervaring mee had, maar dan met ander onderzoeksmateriaal.

Een andere overeenkomst wat ik tijdens mijn opleiding tot tester bemerkte is dat je net als een psycholoog verschillende methoden en technieken gebruikt als een soort gereedschapskist. Afhankelijk van de situatie zit je bepaalde middelen in. Er is niet één oplossing die altijd werkt. Het begint met jezelf te informeren, te overleggen, tot een plan van aanpak te komen en deze vervolgens in te zetten. De samenwerking is hierin ook erg belangrijk, het samen doen wat samen kan, eerst was dat met mijn client, nu wordt dat met mijn teamleden en de verschillende stakeholders. Iets wat je ook terugziet in het proces van agile en scrum werken. In korte tijd maak je iets tastbaars, lever je samen iets concreets op. Zaken die ik leuk vond in mijn oude werk en wat ik ook verwacht veel terug te gaan vinden in mijn komende opdrachten.

Samenvattend lijkt dus de overstap van psycholoog naar tester nog niet eens zo gek. De rollen tonen veel overeenkomsten en het is werk wat eigenlijk altijd doorgaat. Het menselijk brein zal blijven kortsluiten en it systemen zullen kuren blijven vertonen. Gelukkig is er ook altijd ons onderzoeks- en oplossend vermogen om dit te lijf te gaan.

Geplaatst in Medewerker aan het woord | Tags: , , , , , , , , , , | 1 reactie

‘Digital’ en de gevolgen voor testen

‘Digital’ en de gevolgen voor testen.

Door: Nico van Mourik, managing consultant bij ViQiT

Ieder zichzelf respecterende onderneming heeft tegenwoordig een ‘digital’ strategie: van de grote, gebureaucratiseerde onderneming tot de ‘lean & mean’ start-up. Bij de één is het ingebakken in de cultuur en de ander moet nog een omslag maken. Wie zeker een omslag moeten maken zijn de testers, regievoerders en de informatieanalisten.

Waarom heeft digital  zo’n grote impact? Om deze vraag te beantwoorden kijken we eerst naar het begrip ‘digital’ op zich. Digital is eigenlijk datgene waar de hele IT-industrie al decennia mee bezig is: het digitaliseren van gegevens en gegevensstromen. De wijze waarop is echter flink veranderd in de loop der jaren. Waarom dan nu de ‘hype’ in de laatste jaren? Omdat de business, die toch de grootste aanjager van digitale projecten is, tegenwoordig een andere zienswijze heeft op de digitalisering. Waar het digitale deel in het begin een vorm van opslag van gegevens was, evolueerde dit in de loop van de jaren tot ondersteuning van het dagelijkse proces. Met de komst van het web werd digitalisering ingezet als één van de kanalen om klanten te bereiken (net als print, radio, TV, direct sales, etc.). Tegenwoordig is het web zodanig verder ontwikkeld dat iedereen voortdurend online is, of kan zijn. Doordat bijna alle media digitaal zijn, worden ook onze ervaringen digitaal. En met name dat laatste heeft enorme gevolgen voor de ondernemingen, die nu meer en meer beseffen dat ze hierin mee moeten om het niet af te leggen tegen de nieuwe concurrenten die de nieuwe manier van werken in hun organisatie-DNA hebben.

Voor de organisatie van de business betekent dit een enorme omslag. Om de vraag te beantwoorden wat dit voor ons betekent, moeten we eerst eens kijken naar een drietal specifieke kenmerken van een ‘Digital’ strategie:

  • Het gaat om het opbouwen van relaties

In tegenstelling tot eerdere decennia waar organisaties zich concentreerden op het ‘zenden’ van informatie gaat het tegenwoordig om het aangaan, onderhouden en benutten van de relaties onderneming. Het is geen ‘semi Tv-uitzending’ op het web geworden waar je mikt op een doelgroep en hoopt die te bewegen tot een actie. Je moet een band opbouwen met de (potentiële) klanten. Op deze wijze wordt loyaliteit opgebouwd die zich vertaald naar verkoop.

  • Het is een interactief gebeuren

De communicatie gaat twee kanten op. Het alleen zenden van je boodschap is niet meer het belangrijkste. Hierdoor worden je (potentiële) klanten mondiger maar ook actiever. Dat heeft enorme gevolgen voor de onderneming. Als je daadwerkelijk een dialoog aangaat moet je weten wat je hebt besproken met de klant. Naast echt luisteren moet de onderneming ook weten hoe de klant geholpen kan worden, welke informatie nodig is voor het gesprek maar ook welke informatie van nut is voor de klant.

  • Explosie aan communicatiekanalen en berichten

De huidige verregaande digitalisering heeft geleid tot een gigantische hoeveelheid stimuli voor de gemiddelde mens in de westerse wereld. Hoe vind je elkaar in deze oceaan aan informatie en mogelijkheden? Dit is één van de grootste uitdagingen voor organisaties.

Dus ….. wat betekent dit voor ons? We hebben natuurlijk al een flink aantal veranderingen gezien: Agile/Scrum, DevOps, Continuous Delivery, Big Data, etc. Allemaal antwoorden van de IT om mee te gaan met wat de klanten doen. Wanneer we kijken naar het testen & QA hier binnen, merk je dat men moeite heeft om dit te plaatsen. We zijn dan ook op zoek naar hoe het testen zich moet bewegen in deze omgeving.

Meer en meer focus ligt op de business.

Test & QA gaat zich meer en meer naar de business bewegen. We zien dat deze beweging al in gang gezet is en het testen zich al meer richting business processen beweegt. Deze trend wordt nog veel meer doorgetrokken. De ‘digital’ strategie is namelijk een business strategie, met als gevolg dat de stem van de business in de IT steeds groter wordt.  Voor testers van belang maar ook voor regievoering: hoe beheers je de IT binnen je organisatie zodanig dat het mogelijk is om je doelstellingen te behalen op het ‘digital’ terrein?

De beweging richting de business neemt nog veel verder toe voor testers. Werken vanuit de business processen is slechts de eerste stap. We gaan meer en meer toe naar het werken vanuit het perspectief van de eindklant. Zijn of haar perspectief is immers hetgeen waar onze klant mee bezig is.Dat betekent nogal wat voor een tester. De dagen zijn voorbij dat je ‘gewoon goed kon testen’ en dat het niet zoveel uitmaakte of je klant nu bankproducten, overheidsdiensten of pakjes boter verkocht. Het is nu van belang te begrijpen waar jouw klant mee bezig is, welke klanten zij hebben, wat deze klanten belangrijk vinden en hoe ze aangesproken willen worden. Kortom: minder IT en meer business ‘savvy’ zijn.

Continuous testing

Een logisch gevolg van ‘continuous development’. Wanneer we continue aanpassingen willen maken aan de elementen waarmee de organisatie communiceert richting haar klanten, dan moeten we ook zeker weten dat de communicatie kan blijven functioneren op noodzakelijke wijze. Dat betekent op het gebied van functionaliteit, performance, usability en beschikbaarheid. Dit zal voortdurend getoetst moeten blijven worden. In een Europees onderzoek geeft 13% van de respondenten aan, iedere dag de basisfunctionaliteit te testen van hun digitale processen. Één van de belangrijkste argumenten die zij aangeven voor continuous testing is dat zij verwachten dat dit de business dichter bij de IT brengt.

Voor ons als consultants betekent dit dat we onze klanten moeten helpen bij het inrichten hiervan. Continuous testing klinkt natuurlijk geweldig, maar het heeft nogal wat organisatorische consequenties. Belangrijkste stap die we nemen is het daadwerkelijk samen met de klant identificeren van de business processen en de frequentie van testen. Sommige processen wil je inderdaad iedere dag getest zien, andere wellicht minder of zelfs een stuk minder.  Daarbij moet ook bepaald worden wat de diepte van de test gaat worden. Want is het testen van alle mogelijke variaties überhaupt wel zinvol, als het al mogelijk is?

Test automatisering

Lange tijd werd test automatisering als een leuke aanvulling gezien op de ‘echte’ testen die worden uitgevoerd door de testers. Te enthousiaste test automatiseerders werden weggezet als ‘snake oil salesmen’.  Vanzelfsprekend is test automatisering geen ‘silver bullet’ die alle problemen oplost. Geautomatiseerd testen is geen sinecure. Het vergt veel kennis en vaardigheden, maar de behoefte om steeds sneller aan te passen, gecombineerd met een steeds kleiner wordende foutmarge, dwingt organisaties tot geautomatiseerde testen.

Ook hier kunnen we de business ondersteunen. Het daadwerkelijk automatiseren van de testen is meer en meer een development taak geworden, gezien de complexiteit van de systemen onder test. Wel is er een grote behoefte bij de business aan ondersteuning door de testers om te begrijpen wat er nu eigenlijk allemaal  gebeurt bij automatisch testen en hoe ze dit kunnen en moeten aansturen. Veel business managers zijn buitengewoon geïnteresseerd in geautomatiseerd testen, maar schrikken vaak terug voor de complexiteit die daarbij komt kijken.  Waarbij vaak niet zozeer de kosten op zich hen afschrikt, maar het gebrek aan inzicht wat ze nu eigenlijk kopen voor de investering die ze willen doen,.

Configuratiemanagement

Het lelijke eendje in veel ontwikkelteams, en dan met name in de agile teams die om de verkeerde redenen met de agile werkwijze zijn begonnen, is configuratiemanagement. De testers wisten natuurlijk allang dat goed configuratiemanagement cruciaal is voor het succes van testen. Wanneer we steeds sneller opleveren, steeds meer vanuit business processen gaan werken en geautomatiseerd testen steeds geavanceerder wordt is het absoluut noodzakelijk dat we exact weten wat we aanpassen, wat er wordt getest en wat er uiteindelijk wordt gepresenteerd aan de klanten van de organisatie.

Niet echt een sexy onderwerp. Niet bij de business en niet bij de ontwikkelteams. Maar toch rust hier een schone taak om de klant (lees de business) bij te brengen wat het belang is van configuratie management en om hen te helpen dit zodanig in te richten dat de organisatie iedere dag haar digitale omgeving kan aanpassen zonder risico te lopen dat de klantbeleving wordt verstoord.

It’s the data, stupid!

Daar zit je dan met je prachtig uitziende Apps, onlinepagina’s en je razendsnelle Twitter replies. Het probleem is echter dat je of onzin verkondigd óf altijd net achter de feiten aanloopt. Je wordt gezien als een volger i.p.v. een leider. Je directe antwoorden naar je klanten slaan net de plank mis of duren te lang (in de huidige tijd kan 5 minuten wachten al als gruwelijk lang worden ervaren!).

Voorgaande is de nachtmerrie van de business managers. Alles gedaan om je IT-aanpassingen  en business organisaties maximaal te laten aansluiten zodat de klant optimaal geholpen kan worden en dan nog de zaak zien mislukken. De meeste testers onder ons voelen het al aan: ‘it’s the data, stupid!”. Corrupte data, onvolledige data en slecht toegankelijke data kunnen je business proces volledig onderuithalen. Ook al is deze perfect ingericht en wordt het ondersteund door de mooiste softwareoplossingen.

Goede business processen en snelle ontwikkelingen hebben snelle en goede data nodig. Ondernemingen zijn ooit begonnen met IT om hun data beter te maken, makkelijker toegankelijk en sneller beschikbaar. Met de huidige snelheid van ontwikkelingen moet de data ook steeds ‘sneller’ worden. Allereerst zal daarbij de ‘gewone’ gestructureerde data onder de loep moeten worden genomen. Daarna komt Big Data (grote hoeveelheden ongestructureerde data) om de hoek, iets dat bij veel ondernemingen hoog op de agenda staat. De uitdaging om de juiste data, op het juiste moment bij de juiste persoon te krijgen, is iets waar met name in het testen ook veel aandacht aan gegeven moet worden: voordat we live gaan met de applicatie/aanpassing moet worden geborgd dat dit perfect kan worden gerealiseerd in een ‘rommelige’ real-life omgeving.

Samenvattend stel ik dat testen steeds belangrijker wordt, naarmate de digitalisering van de onderneming toeneemt. Wel zal het testen veranderen: van het zo goed mogelijk ondersteunen van de administratieve taken wordt het testen een bewaker van de klantervaringen. Niet alles wordt compleet anders, maar voor de testers zal het een aanpassing zijn. De belangrijkste aanpassing voor de testers is dat ze breder en conceptueler moeten denken. Naast de scherpe analytische en technische vaardigheden zal de tester de mogelijkheid moeten hebben om het totaalplaatje te zien. Als tester worden we niet alleen de vertaler tussen de business en de IT (zie ook de blogpost van Bart) maar ook de vertaler tussen de business en de klanten. Dat vergt een geheel andere denkwijze, maar biedt ook grote kansen om als tester daadwerkelijk een toegevoegde waarde te bieden aan de organisaties die wij helpen.

 

 

Geplaatst in ViQiT in de praktijk | Tags: , , , , , | Een reactie plaatsen

Waarom kunnen IT’ers en gebruikers niet met elkaar praten?

Door: Bart Vullings, consultant bij ViQiT.

Communicatie, dat is een van de grootste succesfactoren in een IT project. Hier zijn de meeste bedrijven en professionals dan ook, terecht, volop trainingen over aan het volgen. Het belang weten we allemaal, een IT project gaat namelijk heel snel een verkeerde kant op als de communicatie niet goed loopt. Maar hoe komt het nu dat de communicatie in een IT project zo lastig loopt? Ondanks het belang en alle aandacht en trainingen die het krijgt. Hoe komt het dat gebruikers en de technische jongens elkaar nog steeds zo lastig duidelijk kunnen maken wat ze willen zeggen?

Type mens?

Welk beeld heb jij als je aan een software ontwikkelaar denkt? Is dat een heel ander type mens dan dat jij zelf bent? Meestal wel (tenzij je een software ontwikkelaar bent, dan neem ik aan dat je aan jezelf denkt). Er worden leuke overzichten gemaakt van hoe mensen uit een IT project elkaar zien.

Een overdrijving natuurlijk, maar met een kern van waarheid. Iedereen ziet elkaar anders dan anderen. Is dit omdat iedere rol ingevuld wordt door een ander type persoon? En is dit dan de reden dat de verschillende rollen zo lastig met elkaar communiceren? Omdat verschillende type personen lastig met elkaar communiceren? Ja en nee. Ja, de meeste mensen gaan werken in een veld waar zij goed in zijn. Een beta persoon wordt eerder een programmeur dan een alfa persoon. Dus zo krijg je automatisch dat mensen die een bepaalde rol hebben qua persoonlijkheid wel bij elkaar in de buurt liggen. En het is zeker zo dat bepaalde persoonlijkheden slechter met elkaar combineren. Maar toch ook nee, dat is het niet alleen.

Het kan niet alleen de persoonlijkheid zijn. Want als je de rollen omdraait (van een ontwikkelaar een tester maakt), dan veranderd er weinig. Je ziet dat iemand die programmeur was zich na verloop van tijd meer en meer als een tester gaat praten. En dat een tester die ontwikkelaar is geworden, als ontwikkelaar gaat praten. Ik maak het zelf ook mee, in mijn carrière (tot nu toe), heb ik verschillende rollen gehad. En ik merk het iedere keer weer, ik ga mij gedragen naar de rol die ik heb.

Belevingswereld

Software ontwikkelen is een complexe bezigheid. Het kost je volledige aandacht om dit goed te doen. Dit geldt ook voor testen, een complexe bezigheid die de volle aandacht nodig heeft om het goed te doen. Het gevolg is dat de rol waar je inzit jouw belevingswereld wordt. Als je meer rollen krijgt, dan gaat dit ten koste van de kwaliteit. Dit is de reden dat de meeste mensen zich specialiseren in een rol. Natuurlijk zijn er de uitzonderingen, de unieke talenten die meerdere rollen tegelijk kunnen doen met behoud van de kwaliteit. Maar ook bij hen ben ik ervan overtuigd dat zij nog veel beter werk zouden doen als zij zich focussen op één rol.

Verschillende belevingswereld, so what?

Een verschillende belevingswereld hebben zorgt voor problemen in de communicatie. Dat kan ik het beste laten zien met een animatie.

Wij kunnen niet bij iedere boodschap onze hele belevingswereld meesturen. We moeten selectief zijn in wat we vertellen. Hierbij doen wij heel veel aannames. En dat is goed, anders geven wij iedere keer zo veel irrelevante of al bekende informatie mee dat de boodschap verloren raakt. Of we zijn er gewoonweg te veel tijd aan kwijt. Dus selecteren en sturen we die boodschap waarvan wij denken dat de ander het begrijpt. Tot zover, nog geen probleem. Als de ander maar dezelfde belevingswereld heeft komt de boodschap zonder problemen aan.

Een voorbeeld: Een beheerder verteld dat de cache van de remote server niet geflushed is tijdens de full crawl. Bij het sturen van deze boodschap heeft de zender een aantal termen niet uitgelegd (cache, remote, server, flush, crawl). Een andere beheerder die dezelfde belevingswereld heeft en dus dezelfde termen kent, heeft geen probleem om de boodschap te begrijpen. Maar verteld hij datzelfde tegen een gebruiker, dan is de kans klein dat de gebruiker ook begrijpt wat er aan de hand is.

Daar zit een lastig punt, je moet jouw boodschap aanpassen aan de ontvanger. Maar hoe doe je dat als je de belevingswereld van de ander niet kent? Dan weet je niet wat de ander wel of niet weet. En dus wat je moet doen om jouw boodschap te laten landen.

Leuk probleem, heb je ook een oplossing?

De echte oplossing zit bij het tackelen van het probleem. Zorgen dat de belevingswerelden voldoende overlappen. En dat de verschillende rollen van elkaar weten waar hun belevingswereld niet overlapt. Zodat zij hun bericht kunnen aanpassen aan degene die het bericht moet ontvangen. En dit kost heel erg veel tijd. Sommigen zijn heel goed in het inleven in een ander en weten iedere boodschap zo te brengen dat de ander het gelijk begrijpt. Voor de meeste mensen kost dit echter vele jaren ervaring.

En wat moet je dan tot die tijd dat bij jou alle samenwerkingen met technische partners zonder problemen lopen? Dan vraag je iemand zoals ik. Want dat is nu wat ik doe: ik ken de belevingswereld van de gebruiker, die van de manager, die van de ontwikkelaar, die van de tester, die van de ontwerper, die van de architect, die van de project manager en waarschijnlijk ook die van je buurman. En dat is de reden dat ik met iedereen kan praten, overal informatie ga halen en dat bij elkaar breng tot een consistent beeld. Als afsluiter een animatie, want daar hou ik wel van.

 

 

Geplaatst in ViQiT in de praktijk | Tags: , , , , | Een reactie plaatsen

Keurslager in softwareontwikkeling

Door: Xander Schreurs, consultant bij ViQiT.

Na enige jaren in de detailhandel te hebben gewerkt heb ik een switch gemaakt naar kwaliteitszorg in ICT. Als ik dan op een verjaardag mag uitleggen wat ik doe komt het vaak tot leuke gesprekken waarin vooroordelen en open deuren niet geschuwd worden. Als kwaliteitsconsultant help ik de kwaliteit te verhogen van een product of proces. Als het even kan help ik mee om de weg ernaartoe te verbeteren, maar hoe dan?

Veel te vaak komen fouten en tekortkomingen van software pas aan het einde van het ontwikkeltraject in beeld. De software zit dan in de testperiode of is al in productie aangekomen. Het herstel van de fout of aanpassing van de software levert vertraging op en leidt tot extra kosten. Er moet immers opnieuw naar het ontwerp gekeken worden. Als het goed gebeurt wordt dit ontwerp getoetst met de stakeholders. Maar wie zijn dat eigenlijk in uw organisatie?

Op een CV heb ik eens gelezen dat iemand zichzelf omschreef als steakholder van het project. Is dat dan die keurslager die de kwaliteit keurt? Vermoedelijk betrof het een tikfout, of wellicht was het wel zo dat deze persoon niet goed wist wat een stakeholder precies is. Feitelijk is iedereen die aan een project meewerkt immers stakeholder. Vaak echter worden deze stakeholders niet goed in kaart gebracht, laat staan geraadpleegd. En juist dat niet raadplegen is funest. Afstemmen met de belanghebbenden voorkomt ellende later in het project.

In goede softwareontwikkeling is elke functie herleidbaar. Als we via deze herleidbaarheid teruggaan naar atomair niveau in software spreken we over requirements. Op basis van requirements worden planningen, contracten en architectuur gemaakt. Als dan later blijkt dat niet alle stakeholders geraadpleegd zijn en de planning, architectuur en contracten zijn gebaseerd op een incomplete set requirements, dan wordt er gehakt gemaakt van het project in plaats van de steak die we voor ogen hadden.

Achterhaal de requirements en valideer ze met de stakeholders. Het klinkt zo simpel, maar in de praktijk blijkt het lastig. Overleggen met mensen leidt in de regel tot tegenstijdige belangen en niet samen te brengen wensen. Dit moet dan onderhandeld worden en dat kost extra tijd. Tijd die zich op termijn wel terugverdiend.

En wat doe ik nou eigenlijk in dat geheel? Soms ben ik degene die aantoont dat de set requirements niet compleet is door er met een kritische blik naar te kijken. Soms ben ik degene die mensen om tafel brengt voor een specialistische blik op deze requirements. Soms ben ik degene die als sparringpartner dient en soms toon ik aan het eind van de rit aan of er aan de requirements voldaan is. Maar meestal ben ik degene die aanbeveelt om aan de basis, de kwaliteit van de requirements, te werken. En vergeet daarbij de kwaliteit van de steak niet.

Ook werken bij ViQiT? Klik dan hier.

Geplaatst in ViQiT in de praktijk | Tags: , , , , | 1 reactie

Wat is een werkgever met gevoel?

Door: Jacco Louwrink

Om dit goed uit te leggen zal ik eerst even mijn geschiedenis vertellen. Sinds september 2013 was ik werkeloos. Na een dienstverband van zes jaar stond ik ineens op straat. Met goede moed op zoek naar een nieuwe uitdaging was ik in de veronderstelling dat ik zo weer aan de slag zou zijn. Dat viel dus tegen. Ook voor mij was de crisis nu echt aangebroken. Maar na een jaar solliciteren en veel teleurstellingen was ik toch eindelijk zo ver dat ik met een potentiële werkgever tot een akkoord kon komen.

Die werkgever is ViQiT: een bedrijf gespecialiseerd in kwaliteitsmanagement in de ICT. Vooral de waarden van waaruit ze werken, zoals ‘resultaat voor inspanning’, spraken mij erg aan. Die sloten naadloos aan bij wat ik zocht. Ze passen erg goed bij mijn persoonlijke profiel.

Op 1 september ben ik begonnen. Wat een heerlijk gevoel was dat! Terug in de realiteit en volop aan de slag in het werk dat ik echt leuk vind. Helaas: het noodlot sloeg voor mij toch weer toe. Maandag 27 oktober zit ik bij de dokter en wordt ik doorverwezen naar het ziekenhuis omdat ze bang zijn dat ik een nekhernia heb. Dus snel naar de neuroloog en een MRI laten maken. En ja hoor, als je denkt alles gehad te hebben, kan dit er ook nog wel even bij. Indicatie van de neuroloog is dat ik toch wel zes tot acht weken uit de roulatie ben. Fijn bericht om dit aan je nieuwe werkgever te moeten melden. Maar het kan nog beroerder. Bij een controle afspraak na een week of vier krijg ik een nieuwe indicatie van herstel. Het kan rustig eind maart worden. Dit omdat de medicatie niet echt aan slaat en ze overwegen om nu injecties te gaan geven. Daar staat dus een periode van 12 weken voor. Hmmmmm dat was nou net niet de bedoeling. Ik begon al te rekenen. Een half jaar contract met optie tot verlengen. Maar van dat half jaar maar 8 weken werken geeft niet echt een positief gevoel dat die verlenging er wel in zit. Dus de zenuwen, voor zover die nog niet spanning genoeg hadden, stonden nu echt strak. Is niet echt bevorderlijk voor het herstelproces.

De afgelopen weken was er bijna om de dag wel contact geweest over hoe het was en of er enige verbetering was te bemerken. Vooral veel interesse in mijn welzijn en niet zo zeer gericht op een voor hun gunstige snelle terugkeer. 16 december is er een gesprek met ViQiT over hoe de stand van zaken. Ik krijg bezoek van onze knopenhakker. Ik maakte me toch wel enigszins zorgen. Hoe zou hij er in staan? Ik had me al voorbereid op een heel moeilijk gesprek.

Wat schetst echter mijn verbazing? Het gesprek was heel erg aangenaam! Er was volop belangstelling over hoe het met mij ging. Natuurlijk is er ook gesproken over dat dit een hele vervelende situatie is, maar dat ik daar ook niets aan kon doen. Het is voor mij misschien nog wel het vervelendste. We spraken over hoe het herstel eruit ziet, dat mijn collega’s het zo jammer vinden dat dit gebeurd ‘want hij was zo lekker op weg’, wat ViQiT eventueel kan bijdragen aan het herstel etcetera. Als laatste kwam de uitspraak dat het allemaal wel heel raar loopt maar dat ze toch het vertrouwen in mij hebben en daarom wel 1 maart het contract willen verlengen.

Dat was nou eens echt een opsteker en zoals ze dat noemen een hart onder de riem steken. Daar wordt een mens echt blij van.

Dat is nou wat ik noem een werkgever met gevoel.

Want zeg nu zelf. Welke werkgever in deze tijd is nu zo sociaal, meedenkend en durft zijn nek uit te steken voor een medewerker die maar acht weken gewerkt heeft!

Ook werken bij ViQiT? Klik dan hier.

Geplaatst in Medewerker aan het woord | Tags: , , , , | 1 reactie

Moeite die loont

Door: Paul Vos

Met het langer worden van de dagen en de eerste berichten van sneeuw is het een goed moment om eens het volgende gedachten experiment uit te voeren. Stel je hebt voor €200,- een ski trip geboekt. Een tijdje later boek je voor €100,- een andere ski trip die ook nog eens leuker is. Maar dan ontdek je dat beide trips op hetzelfde moment vallen. Je kan voor geen van beide trips de tickets annuleren of doorverkopen. Naar welke zou je gaan? De wat duurdere van €200,- of de leukere van €100,-?

De kans is groot dat je voor die van €100,- zou gaan. Daarmee krijg je toch meer waar voor je geld? Dit gedachten experiment is een daadwerkelijke stelling uit een studie waaruit bleek dat meer dan de helft van de respondenten daadwerkelijk op de trip van €200,- zouden gaan. Ondanks dat de duurdere trip minder leuk zou zijn is het ‘verlies’ minder, toch? Dit is nu precies een denkfout die we allemaal maken.

‘Ik eet het broodje toch maar helemaal op want ik heb er immers voor betaald’,

‘Ik kan net zo goed naar deze slechte film blijven kijken want ik heb er al een uur van gezien’

‘Ik kan net zo goed de rest van deze saaie conferentie uitzitten want ik heb er immers al voor fors voor betaald’

Sunk-cost fallacy

Al deze gedachten zijn samen te vatten in een logische denkfout die ‘sunk-cost fallacy’ (letterlijk gezonken kosten) heet. Deze dwaling van onze gedachten is in de economisch wereld een bekend begrip maar in de praktijk blijken we er vaak slachtoffer van. Waar het om gaat is dat we kosten die reeds gemaakt zijn niet nógmaals mee moeten nemen in onze afweging om iets te doen. Kosten die al zijn gemaakt en waar we ogenschijnlijk niets voor terugkrijgen moeten we dan ook als verlies beschouwen en daarmee onze aandacht richten op nieuwe uitdagingen en investeringen. En dat is nu precies waar onze natuur ons in de steek laat. Het nemen van verlies is iets wat ons mensen slecht af gaat. En daarmee blijven we vaak onnodig inspanning leveren terwijl dat niet het resultaat geeft waar we naar op zoek zijn.

Als tester kom ik deze denkfout ook regelmatig tegen. Het maken van een testscript kan soms veel tijd kosten. Als vervolgens blijkt dat de basis voor het script niet correct was zijn we vaak geneigd om het bestaande script vast te houden en aan te passen naar de nieuwe situatie. Als deze wijzigingen niet al te groot zijn dan hoeft dat geen probleem te zijn, maar vaak is het oorspronkelijke script te gedetailleerd en kost het al gauw veel tijd om deze aanpassing door te voeren. Om dit verlies van tijd te voorkomen was het beter geweest om het verlies voor lief te nemen en opnieuw te beginnen. Zeker in het opsporen van potentiële risico’s verdient dit de voorkeur aangezien een hernieuwde blik vaak nieuwe inzichten geeft.

Ook op project, programma of zelfs bestuursniveau gebeurt het nog regelmatig dat er vast wordt gehouden aan eerder geleverde inspanning, ondanks dat die eigenlijk niet het gewenste resultaat gaf en men toch probeert deze om te buigen tot de gewenste situatie. Dit terwijl gewoon stoppen en opnieuw beginnen of iets anders oppakken het daadwerkelijk gewenste resultaat zou geven.

Ondanks het feit dat we vaak te maken hebben met deze mindset is hij gelukkig makkelijk te herkennen en te voorkomen. Ga eens samen zitten met iemand en maak een lijst met de voor en nadelen, uiteraard kunnen wij je daar graag bij helpen. Dit zorgt ervoor dat het gevoel van verlies minder prominent aanwezig is bij de keuze. En stel nu daadwerkelijk eens de resultaten voor de (emotionele of financiële) inspanningen en zorg hiermee dat je slimme keuzes maakt. Want wie wil er nu niet zijn eigen gevoel te slim af zijn?

Geplaatst in Medewerker aan het woord | Een reactie plaatsen