Dingen goed voor elkaar krijgen (met Michael Luchen van Crema)

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot is niet altijd 100% correct.

Ben Aston:

Het is waardeloos wanneer dingen niet werken en wanneer we weken of een maand besteden aan het bouwen van een project, om vervolgens tijdens de laatste UAT te worden teleurgesteld door een sluwe bug. Maar waarom lijkt dat bijna altijd te gebeuren en kunnen we er iets aan doen? Als je last hebt van bugs, blijf dan luisteren, want in de podcast van vandaag bespreken we hoe we dingen goed voor elkaar kunnen krijgen met een verbeterd product en proces en de magie van een kwaliteitsmanagementplan.

Bedankt dat je luistert. Ik ben Ben Aston, oprichter van projectmanagers. Welkom bij de DPM-podcast. We hebben de missie om projectmanagers te helpen slagen en mensen die projecten beheren te helpen betere resultaten te leveren. We zijn er om je te helpen je vaardigheden op het gebied van projecten naar een hoger niveau te tillen. Ga naar thedigitalprojectmanager.com voor meer informatie over onze trainingen en bronnen die we via lidmaatschap aanbieden. Deze podcast wordt mogelijk gemaakt door Clarizen, de leider op het gebied van software voor enterpriseproject- en portfoliomanagement. Ga naar clarizen.com voor meer informatie.

Vandaag praat ik met Michael Luchen. Michael is een van onze vaste DPM-experts. Hij is productcoach bij Crema. Dat is een digitaal productbureau dat web- en mobiele apps maakt voor vernieuwende bedrijven en marktleiders. Hij werkt normaal gesproken op afstand vanuit D.C. en helpt teams hun samenwerking te verbeteren om complexe problemen te analyseren en op te lossen. Hij heeft onder andere met Adidas en Callaway Golf gewerkt en is coach bij Crema. Vandaag praten we met hem over het opstellen van een kwaliteitsmanagementplan. Hallo Michael, welkom bij de show.

Michael Luchen:

Hé Ben, hoe gaat het?

Ben Aston:

Goed, bedankt. Ik ben benieuwd: nu we al een aantal jaren met elkaar praten en podcasts opnemen, is je rol geëvolueerd. Ik ben geïnteresseerd in je huidige coachrol, waarvan ik denk dat het een nieuwe functietitel is. Kun je ons vertellen wat een coach is? Wat is een productcoach en wat betekent dat bij Crema?

Michael Luchen:

Zoals je al zei, komt dit voort uit ongeveer zeven jaar praktische ervaring met project- en productmanagement. Eerlijk gezegd wordt de rol op dit moment nog gedefinieerd. We proberen uit te zoeken wat een coachrol bij Crema inhoudt. Op dit moment benaderen we het eenvoudigweg als een dienend leiderschap dat klanten helpt agile werken te begrijpen en betere versies van zichzelf te worden. Gewoonlijk treed ik op als facilitator, productstrateeg en design thinker om hen te helpen problemen opnieuw te formuleren en vernieuwende benaderingen te identificeren. Wat ik interessant vind aan deze nieuwe rol en deze nieuwe onderneming voor Crema, is dat we in een drukke sector een verschil proberen te maken vanuit een heel unieke invalshoek die niet voorschrijvend is. Er zijn zoveel voorschrijvende coachingsprocessen en wij willen anders zijn.

Ben Aston:

In je rol werk je dus met een klein team rechtstreeks met een klant. Is dat meer een strategische rol dan wanneer je de roadmap van het project of product probeert te definiëren?

Michael Luchen:

Ja, het is—

Ben Aston:

Of ligt de focus meer op oplevering?

Michael Luchen:

… Het lijkt op wat je net noemde. Het is iets breder en meer gericht op mensen. Een van de dingen die ik zo leuk vind aan projectmanagement, is dat ik me kan richten op het creëren van een gezonde omgeving voor teams, zodat ze hun beste werk kunnen doen. Dit neemt dat idee eigenlijk over en helpt klanten de hulpmiddelen en denkwijze te krijgen die ze nodig hebben om binnen hun teams een gezonde, productieve cultuur en omgeving te creëren en echt goede resultaten te behalen.

Ben Aston:

Met wat voor uitdagingen krijg je te maken wanneer je klanten helpt die opleveringsmentaliteit te veranderen?

Michael Luchen:

Er kunnen veel uitdagingen ontstaan, maar volgens mij heeft het ermee te maken dat resultaten niet altijd onmiddellijk zichtbaar zijn. Dit is niet iets waarbij ik kan binnenkomen en zeggen: doe dit en alles wordt beter. Er is daar zeker veel van te vinden: leer framework X en je team zal slagen. Maar ik denk dat het belangrijk is om de volledige context van de cultuur binnen de organisatie te begrijpen en te beseffen dat leiders die je begeleidt tijd nodig hebben om te experimenteren en uit te zoeken hoe die lessen landen.

Ben Aston:

Ja, absoluut. Ik denk dat het zo waar is dat er geen enkel proces is dat absoluut juist is voor jouw organisatie of bureau. Als je simpelweg de stappen volgt, krijg je niet plotseling magische resultaten. Er bestaat geen wondermiddel of zilveren kogel waarmee je al je problemen ineens kunt oplossen. Soms denken mensen: agile is het wondermiddel. Vervolgens moeten we definiëren wat dat betekent. Dat klinkt als een interessante rol die je daar nastreeft. Doe je dat voornamelijk op afstand of werk je ook op locatie met klanten?

Michael Luchen:

Zeker een combinatie. Op dit moment, terwijl we dit opnemen, volledig op afstand. Maar ik denk dat relaties persoonlijk kunnen worden opgebouwd, dus als het mogelijk is, is het altijd goed om coaching persoonlijk te starten. Ik heb echter gemerkt dat je ook via Zoom-gesprekken of met Loom schermdeling een echt productief en betekenisvol gesprek kunt voeren, begeleiding kunt geven, een vraag kunt beantwoorden of kunt samenwerken op Mural-borden. Het kan dus op beide manieren.

Ben Aston:

We hebben het over werken op afstand. We zitten natuurlijk midden in de coronacrisis en quarantaine en je hebt onlangs een workshop voor ons gegeven over werken op afstand. Voor iedereen die die workshop heeft gemist, of voor jou nu je terugkijkt op het leven en werken op afstand terwijl iedereen daartoe wordt gedwongen: wat is voor jou de meest impactvolle tip of techniek om niet gek te worden wanneer je alleen en op afstand werkt? Hoe ga je om met dat gevoel van isolatie? Normaal gesproken vertelde je dat je naar coworkingruimtes ging. Ik weet zeker dat je veel ervaring hebt met thuiszitten. Wat doe je om het vol te houden?

Michael Luchen:

Dat is een heel goede en actuele vraag. Mentaal probeer ik te onthouden dat ik samenwerk met andere mensen. Daarom zijn zoveel mogelijk videogesprekken via Zoom ongelooflijk waardevol geweest. Het klinkt in deze tijd eenvoudig, zeker nu Zoom de meest gedownloade gratis app lijkt te zijn, maar ik probeer dat bewust vanuit een samenwerkingsperspectief te benaderen: laten we gewoon met mijn team in een Zoom-gesprek stappen en dingen bespreken. Je kunt non-verbale interacties zien en die zijn vooral als projectmanager erg waardevol. Ik ga zelfs zo ver dat ik soms een tweede scherm gebruik als ik mijn scherm deel, zodat ik ieders gezicht nog steeds kan zien.

Ben Aston:

Dat is goed advies. Zoom is een geweldig hulpmiddel, maar de verleiding bestaat om met Slack gewoon dingen te gaan typen. Dan vergeten we dat we een heleboel communicatie missen en ook de mogelijkheid om relaties op te bouwen. Een gesprek is anders wanneer je een Zoom-gesprek voert. Kleed je dus aan, voer ook een Zoom-gesprek en ik denk dat het zeker zijn vruchten afwerpt.

Ben Aston:

Je vertelde dat je zowel op afstand als persoonlijk coacht. Nu gebeurt natuurlijk alles op afstand. Kun je iets vertellen over enkele projecten waaraan je momenteel werkt?

Michael Luchen:

Op dit moment stap ik volledig over van productmanagement naar de coachrol. Ik rond momenteel een groot, meerjarig enterpriseontwikkelingsproject af. Het is geweldig om dit met een coachingsmentaliteit te benaderen, omdat er zeker veel overlap is wanneer je coaching naar het niveau van de praktijk brengt. Verder kijk ik vooruit naar het uitbouwen van deze coachingsdiensten en vooral naar de onderscheidende factor waarmee Crema hierin verschil kan maken en klanten met bescheiden zelfvertrouwen kan dienen.

Ben Aston:

Als je nadenkt over de uitdagingen van klanten die je helpt aanpakken, wat zijn dan enkele belangrijke knelpunten in de oplevering die je als potentiële kansen voor deze rol identificeert?

Michael Luchen:

Ik heb daar een interessante metafoor voor bedacht. We benaderen coaching ongeveer zoals een semester binnen een universitair curriculum. De reden daarvoor is dat effectieve coaching volgens mij vooral draait om experimenteren: de mensen die ik coach moeten zelf kunnen experimenteren en leren. Mijn rol bestaat in feite uit het optreden als facilitator, gids en mentor met praktijkervaring.

Dat betekent dat we regelmatig inchecken, retrospectives houden, observaties doen en notities delen. Dan zeg je bijvoorbeeld: misschien wil je dit eens bekijken of proberen tijdens je volgende vergadering. Zo creëer je een ritme, zodat we na enkele weken of maanden kunnen terugkijken en zeggen: wauw, er is zeker duidelijke vooruitgang geboekt. Ik heb het gevoel dat mijn team meer kan produceren.

Ben Aston:

Hoe help je een organisatie prioriteiten te stellen wanneer je gebieden identificeert die meer agile zouden kunnen worden? Binnen een grote organisatie zijn er veel verschillende processen. Hoe help je klanten bepalen welke aspecten van hun proces of oplevering geschikt zijn als laaghangend fruit om op een meer agile manier aan te pakken?

Michael Luchen:

Volgens mij begint het met een enquête en een gesprek. Misschien doe je de enquête niet alleen met één contactpersoon bij de klant, maar ook met projectmanagers, ontwikkelaars en anderen die bij het proces betrokken zijn of willen worden. Je begint met een enquête om te bepalen welke problemen zij zelf als het belangrijkst ervaren. Daarna nemen mijn team en ik de tijd om de enquête te bekijken en te vergelijken met de onderliggende signalen die we hebben gehoord. Zo kunnen we aanbevelen om verder te gaan met de twee of drie belangrijkste gebieden, omdat die waarschijnlijk echt goede resultaten opleveren als we er nu mee aan de slag gaan.

Ben Aston:

Dat klinkt slim. Veel succes ermee.

Michael Luchen:

Bedankt.

Ben Aston:

Ik wil teruggaan naar je artikel en het onderwerp waarmee we begonnen: kwaliteitsmanagement. Als je het artikel waarover we praten nog niet hebt gelezen, bekijk het dan op thedigitalprojectmanager.com. Het heet ‘Een kwaliteitsmanagementplan ontwikkelen’. Michael doorloopt daarin stap voor stap een zeer grondig proces om een kwaliteitsplan op te stellen. Als jullie lid zijn, krijgen jullie ook toegang tot de template voor het kwaliteitsmanagementplan, de lijst met doelapparaten en de kwaliteitseisen, zodat jullie dit alles heel eenvoudig in de praktijk kunnen brengen.

We gaan hier niet te diep in op het proces voor het maken van het plan, omdat dat in het artikel staat. In het kort legt Michael uit hoe je een kwaliteitsplan voor je project of product kunt maken. Ik wil beginnen met het idee van kwaliteit. Je begint met het creëren van een gedeeld begrip van wat kwaliteit voor je project betekent. Waarom is het volgens jou zo moeilijk om daar grip op te krijgen?

Michael Luchen:

Om de context van kwaliteit en deze discussie te schetsen: ik zie twee dingen. Er is productkwaliteit en proceskwaliteit. Productkwaliteit is de kwaliteit van je tastbare of digitale product en omvat alle resultaten van het werk van je ontwerpteam, ontwikkelteam en anderen. Proceskwaliteit is iets waarop wij als projectmanagers veel invloed hebben. Het verwijst naar het proces dat we creëren en dat vervolgens het vermogen van ons team beïnvloedt om resultaten te behalen. Een metriek die we allemaal kennen is bijvoorbeeld velocity, waarmee je kunt meten hoe het proces verloopt.

Een gedeeld begrip van kwaliteit bereiken is voor veel teams moeilijk, vanwege alle subjectiviteit en emoties die ermee gepaard kunnen gaan. Je hebt veel verschillende belanghebbenden, waaronder je eigen team van ontwikkelaars en ontwerpers, die vanuit verschillende perspectieven en om verschillende redenen naar kwaliteit kijken. Een klant kan bijvoorbeeld een bepaald kwaliteitsniveau willen dat aan de verwachtingen voldoet, terwijl een ontwikkelaar vooral waarde kan hechten aan codekwaliteit en schone code en de perfecte code wil schrijven. We moeten dus helpen die balans te vinden.

Ben Aston:

Laten we het over die balans hebben. Bij agile hebben we acceptatiecriteria voor een gebruikersverhaal die de parameters van dat verhaal definiëren. Dit is wat het verhaal moet doen; dit zijn de acceptatiecriteria waaraan het moet voldoen om als voltooid te worden beschouwd.

Daarnaast hebben we de definitie van voltooid, waarbij alles wordt beschreven wat als algemene regel voor alle gebruikersverhalen geldt. Bij agile proberen we waarde iteratief te leveren. Soms lijkt kwaliteit voor mij echter op gespannen voet te staan met die agile aanpak. Wat is belangrijker: voldoen aan alle acceptatiecriteria en de definitie van voltooid, waarde leveren, of beide en daardoor gewoon langzamer werken?

Michael Luchen:

Dat is een goede vraag. Ik denk dat dit de kern raakt van waarom ik dit soort onderwerpen zo interessant vind. Ik geloof dat aandacht voor kwaliteit niet strijdig is met agile. Het versnelt teams juist en maakt teams die agile praktijken toepassen sterker. Als je aan het begin van een project met je team gaat zitten en definieert wat kwaliteit wel en niet betekent, helpt dat om de aandacht van je team op de juiste zaken te richten tijdens het bouwen en opleveren van het werk. Het maakt duidelijk wat wel en niet in aanmerking komt.

Ook bij praktische zaken zoals acceptatiecriteria kunnen die criteria agile ondersteunen, als je ze vanuit het juiste perspectief bekijkt. Stel bijvoorbeeld dat je team in een sprint aan een gebruikersverhaal werkt en dat er al acceptatiecriteria zijn. Tijdens de ontwikkeling stuiten de ontwikkelaars op een technisch obstakel, waardoor een onderdeel van de acceptatiecriteria verandert.

Dat opent een geweldig gesprek. Het betekent niet dat we moeten vertragen en teruggaan naar de oude manier. We kunnen als team kort pauzeren, de acceptatiecriteria bijwerken en ze gebruiken om kwaliteit te ondersteunen.

Ben Aston:

Het gaat volgens mij om het veranderen van onze kijk op kwaliteit. Kwaliteit hoeft niet op gespannen voet te staan met het snel leveren van waarde. We moeten kwaliteit juist zien als een belangrijk onderdeel van waarde. Als we iets waardevols leveren, maar het voldoet niet aan de kwaliteitscriteria die we hebben vastgesteld, levert het misschien niet zoveel waarde als het zou moeten of kunnen. We moeten ons begrip van kwaliteit dus opnieuw formuleren: kwaliteit is een onderdeel van de waarde die we creëren.

Michael Luchen:

Precies.

Ben Aston:

In je aanpak praat je over het verdelen van verantwoordelijkheden voor kwaliteitsmanagement. Dat is interessant, omdat grotere bureaus of organisaties vaak speciale QA-teams hebben, terwijl het uiteindelijk ook de taak van de projectmanager of ontwikkelaars kan worden. Je pleit voor een test engineer. Waarom is die rol volgens jouw ervaring zo belangrijk?

Michael Luchen:

In mijn eerste jaren als projectmanager deed ik zelf QA. Nu ik met test engineers samenwerk, merk ik een enorm verschil. Die rol is belangrijk omdat je een getraind kritisch oog voor kwaliteit nodig hebt. De test engineer is vanuit mijn perspectief de beste projectmanagementpartner op elk project. Die persoon kijkt naar de details van wat wordt gebouwd en opgeleverd op een manier die geen enkele andere rol in het team doet.

Ze verdiepen zich technisch in de details, maar bekijken ook de bredere gevolgen van de ontwikkeling en hoe wat we doen uiteindelijk bij gebruikers terechtkomt. Wanneer je een test engineer op die manier laat werken, wordt die persoon een kernlid van het team dat de waarde van ontwikkelaars, ontwerpers en zeker ook mijn eigen rol vermenigvuldigt.

Ben Aston:

In mijn ervaring verschilt de mentaliteit van een test engineer of QA-analist sterk van die van een projectmanager. Als projectmanager denk ik altijd aan het optimale pad. Wanneer ik iets test, denk ik: dit is wat je doet. Ik ken het product en weet hoe het hoort te werken. Bovendien heb ik er belang bij dat het niet kapot is, omdat ik wil dat het werkt en we er niet meer tijd aan hoeven te besteden.

Een QA- of test-engineermentaliteit is anders. Zij hebben ervaring met het breken van dingen en met het bekijken van de klantervaring door middel van verkennend testen. Ze zoeken manieren waarop het ideale pad niet werkt en waarop iets kan breken. Dat zorgt voor veel meer nauwkeurigheid en grondigheid en verhoogt de kwaliteit van het eindproduct, omdat er altijd bugs zullen zitten in wat we maken.

In je artikel bespreek je het bepalen van doelapparaten. Dat is vaak erg lastig. Klanten kunnen een oude telefoon hebben of verwachten dat alles werkt op Internet Explorer 6, een BlackBerry of oude browsers. Hoe werk je met klanten die willen dat het product op alle apparaten uit het verleden, heden en de toekomst werkt?

Michael Luchen:

Het bepalen van doelapparaten is een van mijn favoriete oefeningen. Het helpt niet alleen om de focus op kwaliteit en de investeringen van het team te beperken, maar ook om de gewenste resultaten voor gebruikers af te bakenen.

Wanneer een klant elk apparaat en elk besturingssysteem ooit ondersteund wil hebben, kun je vragen gaan stellen over de gebruikers die je daadwerkelijk ondersteunt en wat zij nodig hebben. We maken grappen over ondersteuning voor Internet Explorer, maar soms leiden zulke vragen tot waardevolle gesprekken. Misschien gaat het om een zeer specifieke app die deze ondersteuning echt nodig heeft.

Het gesprek over doelapparaten helpt jou, je team en de klant dus om de gebruiker centraal te stellen en op basis van prioriteit en benodigde tijd te bepalen wat wel en niet belangrijk is.

Ben Aston:

Dat is goed advies. Een waarschuwing voor iedereen die een werkomschrijving schrijft of acceptatiecriteria definieert: wees voorzichtig wanneer je beschrijft welke apparaten je ondersteunt. Schrijf niet simpelweg dat iets op alle mobiele apparaten en desktopapparaten werkt, nu en voor altijd. Het zal niet alleen niet werken in oude browsers; naarmate browsers zich ontwikkelen, kunnen dingen ook stoppen met werken.

Je website of product kan eerst prima werken en vervolgens kan Google een nieuwe browserversie uitbrengen, waarna alles ineens stukgaat. Wiens schuld is dat? Het is de moeite waard om vooraf vast te leggen dat het niemands schuld is, maar iemand moet uiteraard betalen voor het feit dat iets wat werkte niet meer werkt.

Het is dus belangrijk je doelapparaten te bepalen en daar heel duidelijk over te zijn. Dit kan je flink opbreken als je het niet zorgvuldig definieert.

Laten we het hebben over testgevallen. We gaan nu dieper in op de details. Veel mensen hebben gehoord van testgestuurde ontwikkeling, maar er wordt ook tijdens het werk getest en gedocumenteerd. Dan ontstaat de vraag: hebben we een testplan nodig en hoe beheren we dit? Wat vind je vanuit jouw ervaring van testgestuurde ontwikkeling? Levert die de juiste resultaten op in termen van waarde? Testen je engineers tijdens het werk en documenteren ze terwijl ze bezig zijn, of gebruiken jullie een zeer grondig testplan?

Michael Luchen:

Bij Crema hebben onze test engineers het bedrijf geleid naar het inzicht dat kwaliteit de verantwoordelijkheid van iedereen is. Onze ontwikkelaars passen testgestuurde ontwikkeling toe en schrijven integratietests voor de onderdelen waarvoor dat zinvol is. Wanneer de functionaliteit bij een test engineer terechtkomt, kan die persoon zich meer richten op handmatig testen vanuit het perspectief van de gebruiker, geautomatiseerde tests schrijven, verkennende tests voor randgevallen uitvoeren en meer.

Ben Aston:

De vijand van verantwoordelijkheid van iedereen is natuurlijk dat niemand verantwoordelijk is. Hoe stimuleer je kwaliteit als waarde binnen de organisatie? Hoe ziet dat er praktisch uit?

Michael Luchen:

Het begint met een basis van educatie. We hebben Slack-kanalen waarin we erover praten en zorgen dat er voortdurend discussie is over wat kwaliteit voor onze projecten betekent. Vanuit praktisch oogpunt kunnen projectmanagers processen opzetten waarmee teams tussentijds kwaliteitscontroles kunnen uitvoeren.

Wij gebruiken bijvoorbeeld JIRA. De workflows maken het mogelijk om codebeoordelingen af te dwingen als we dat willen. Hoewel ‘afdwingen’ misschien een sterk woord is, omdat het uiteindelijk onderdeel is van het werk, zorgt het ervoor dat iets wat van ‘in uitvoering’ naar ‘op de testomgeving’ gaat eerst door een codebeoordeling gaat. Wanneer het van de testomgeving naar QA gaat, hebben we daar een volledig proces voor om te garanderen dat het voldoende tijd en dekking krijgt.

Ben Aston:

Kwaliteit integreren in het proces zelf dus. Niet alleen zeggen: we bouwen het onderdeel en dan is het klaar, waarna we het misschien nog aan QA geven. Een onderdeel van de ontwikkeling is dat het wordt getest. Dat is een sterke aanpak. Je noemde ook het integreren van unit tests in de code tijdens de ontwikkeling. Dat leidt tot de vraag hoe je handmatig en geautomatiseerd testen combineert. Hoe sterk is jullie geautomatiseerde testen en hoe bepaal je wanneer het de moeite waard is? Het kost immers veel tijd om dit op te zetten.

Michael Luchen:

Handmatig testen is erg waardevol en laaghangend fruit. Je kunt er eenvoudig mee beginnen. Het is vooral waardevol wanneer de gebruikerservaring erg uitgebreid is of wanneer het niet de moeite waard zou zijn om geautomatiseerde tests op te zetten. Een voorbeeld is een slepen-en-neerzetteninteractie binnen een app.

Geautomatiseerd testen is juist geweldig wanneer je iets steeds opnieuw doet. Lange, complexe informatieformulieren zijn daar een goed voorbeeld van. Bonuspunten als je test engineer automatisch ingevulde testgegevens kan schrijven met alle vreemde tekens waar onze apps zo dol op zijn.

Ben Aston:

Jullie aanpak van het kwaliteitsmanagementplan lijkt dus neer te komen op dingen goed doen wanneer kwaliteit onderdeel is van het geïntegreerde ontwikkelproces, maar ook op het vermijden van een uniforme aanpak. De methode wordt aangepast aan het project en zelfs aan de onderdelen waaraan je werkt. Hoe zorg je ervoor dat je in zo’n organisch proces vertrouwen hebt dat je de juiste aanpak volgt?

Michael Luchen:

Ik aarzel omdat ik een groot voorstander ben van het organische proces. Net zoals je velocity over enkele sprints bepaalt om jezelf voor de rest van het project succesvol op te stellen, bekijk ik kwaliteit op dezelfde manier. Bij de start van een project doen we altijd een eerste poging. Het artikel dat ik schreef over het maken van een kwaliteitsmanagementplan biedt een goed raamwerk, zodat je begint met een stevige basis.

Dat blijft echter altijd een aanname. Zeker wanneer een team nog niet eerder heeft samengewerkt, zullen zaken tijdens de eerste paar sprints of weken vanzelf veranderen en zich ontwikkelen. Je moet bereid zijn te accepteren dat dingen een beetje kunnen veranderen, maar niet dat ze drastisch afwijken. Misschien bereiken we de eerste release van het product en ontdekken we dat niemand een van onze doelapparaten gebruikt. Dan moeten we de flexibiliteit hebben om de lijst met doelapparaten aan te passen, zodat we meer tijd en energie kunnen besteden aan andere gebieden.

Daar moet je echt op voortbouwen. Wanneer ik daarna aan een nieuw project begin, baseer ik dat op de ervaring van het vorige project, maar altijd met aandacht voor het nieuwe team.

Ben Aston:

Gezond verstand speelt een enorme rol in kwaliteitsmanagement. Als we niet opletten, kunnen we in de richting gaan van kwaliteit boven alles. Dan maken we een zeer solide kwaliteitsmanagementplan met allerlei controles en tegenwichten, maar wordt het uiteindelijk net als documentatie iets wat we alleen doen omdat het moet. We moeten ergens het midden vinden: controles, tegenwichten en een plan, maar ook gezond verstand en aanpassing tijdens het werk.

Dat sluit opnieuw aan bij de agile aanpak. We moeten niet zo dogmatisch zijn over het kwaliteitsmanagementplan dat we geen ruimte laten voor wat losser, verkennend testen. We moeten ons kunnen aanpassen om uiteindelijk waarde te blijven leveren, stapsgewijs en met steeds meer kwaliteit.

Michael Luchen:

Precies.

Ben Aston:

We hebben onlangs een podcast gelanceerd op onze zustersite. Die heet The QA Lead. Als je geïnteresseerd bent in QA en met test engineers en QA-specialisten werkt, wijs hen dan op QAlead.com. Als projectmanager is het ook de moeite waard om de post te bekijken. Die is zeer uitgebreid en bevat een voorbeeld en templates die we via het lidmaatschap delen.

Als je nog geen kwaliteitsmanagementplan gebruikt, bekijk dit dan. Het helpt je na te denken over je proces, je project of product en hoe je meer waarde kunt leveren door een product van betere kwaliteit op te leveren.

Deze tips zijn allemaal waardevol geweest, maar wat bij mij vooral bleef hangen, is het idee dat kwaliteit iets is wat we binnen de hele organisatie moeten cultiveren. Of we nu wel of geen test engineers hebben, iedereen moet nadenken over kwaliteit. Niet alleen in de zin van: is dit kapot of niet? Het is ook een weerspiegeling van ons proces en iets waar de hele organisatie aandacht aan moet besteden. Werkt alles? Hoe kunnen we het verbeteren? We hebben een meer iteratieve mentaliteit nodig. Michael, heel erg bedankt voor je inzichten.

Michael Luchen:

Bedankt.

Ben Aston:

Ik ben benieuwd wat jij ervan vindt. Wat zijn jouw tips en trucs om projecten of producten met kwaliteit op te leveren? Vertel ons wat wel en niet werkt. Heb je verhalen over mislukkingen of successen die je wilt delen? Laat het weten in de reacties hieronder.

Als je meer wilt leren en vooruitgang wilt boeken in je werk, sluit je dan aan bij onze community met een DPM-lidmaatschap. Ga naar thedigitalprojectmanager.com/membership voor toegang tot ons Slack-team, templates, workshops, spreekuren, e-books en meer. Als je het gesprek van vandaag interessant vond, abonneer je dan en blijf in contact via thedigitalprojectmanager.com. Tot de volgende keer en heel erg bedankt voor het luisteren.