Geef je collega’s betere feedback (met Ryan Schaefer van Viget)

Lees het transcript:

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

Ben Aston:

Welkom bij de DPM-podcast, waarin we verder gaan dan de theorie om advies te geven dat werkt voor het leiden van betere digitale projecten. Bedankt dat je luistert. Ik ben Ben Aston, oprichter van The Digital Project Manager.

Hoe ga je om met het geven van feedback aan de mensen in je team? Omarm je het omdat je nu eenmaal gelijk hebt — je bent tenslotte projectmanager — of vermijd je het omdat je bang bent dat je niet serieus wordt genomen? Misschien krijg je feedback en denk je dat niemand echt begrijpt wat je bedoelt, of misschien zelfs heeft gehoord wat je hebt gezegd. Maar als projectmanagers zijn wij verantwoordelijk voor het succes, en dat is lastig wanneer onze teams zo vaak de verkeerde richting lijken op te gaan.

Ontdek daarom in de podcast van vandaag enkele eenvoudige manieren om feedback te geven die je teams helpen beter werk te leveren en je projecten op koers te houden.

Vandaag praat ik met Ryan Schaefer. Ryan is van het ontwerpen en bouwen van websites overgestapt naar het managen van de ontwikkeling ervan. Hij werkt in Washington D.C. bij een bureau dat Viget heet. Hallo, Ryan.

Ryan Schaefer:

Hoi Ben. Bedankt dat je me hebt uitgenodigd.

Ben Aston:

Leuk. Ryan, vertel eens wat over je huidige rol. Ik ben vooral benieuwd hoe je de overstap hebt gemaakt van design en development naar projectmanagement. Dat is een vraag die we vaak krijgen. Wat doe je nu precies? Is het puur projectmanagement, of duik je ook nog regelmatig de inhoud in?

Ryan Schaefer:

Ik zou zeggen dat het meer richting puur projectmanagement gaat. Een van de dingen die de overstap van het uitvoerende werk in design en development naar projectmanagement makkelijker maakte, was dat ik begreep welke gedachten en processen achter die ontwerp- en ontwikkelingsaspecten schuilgingen.

Daardoor kan ik met de zeer getalenteerde ontwerpers en ontwikkelaars hier op een gelijkwaardig niveau praten. Ik hoef niet te vragen wat afkortingen betekenen, welke tools ze gebruiken en dergelijke.

Bij een eerder PR-bureau had ik een dubbele rol: ik werkte aan accounts én aan de uitvoering. Dat hielp me nadenken over hoe ik dingen aan een klant zou uitleggen en hoe we met andere teamleden zouden samenwerken. Daardoor was de overgang naar volwaardig projectmanagement gelukkig vrij natuurlijk.

Ben Aston:

Maar hoe gebeurde het? Wat was het moment waarop je zei: “Oké, dat is het. Ik word projectmanager”?

Ryan Schaefer:

Het had deels te maken met de wens om dingen vanuit een helikopterperspectief te managen in plaats van in een silo te werken. Maar de belangrijkste reden was dat ik bij een bureau wilde werken waar iedereen gepassioneerd was over digitaal en vooruitstrevend dacht. Dat verandert vanzelfsprekend de manier waarop we als beschaving en zeker als land leven. Omringd zijn door mensen die dat zagen en waardeerden, en die bovendien zeer bekwaam waren in hun digitale vakgebied, was iets waar ik deel van wilde uitmaken. Uiteindelijk zou dat me ook professioneel helpen groeien.

Ben Aston:

Vertel eens wat over wat je nu doet. Hoe ziet de rol van een projectmanager bij Viget eruit?

Ryan Schaefer:

Allereerst: het is Viget. Dat horen we vaak.

Ben Aston:

Vid-get? Vig-et?

Ryan Schaefer:

Viget, ja.

Ben Aston:

Ik ben zelfs naar de website gegaan en heb op een kat geklikt waarop stond dat het Viget is.

Ryan Schaefer:

Ja, er is zo’n knop waarmee je hallo kunt zeggen. Dat is Viget.

Ben Aston:

Dat krijg je als je een grappige naam hebt. Wat betekent het eigenlijk?

Ryan Schaefer:

“Samen bloeien” in het Latijn.

Ben Aston:

O, natuurlijk.

Ryan Schaefer:

Iets in die richting.

Ben Aston:

Mijn moeder zou zich voor me schamen. Mam, het spijt me. Ze geeft Latijn. Ik zou dit soort dingen moeten weten.

Ryan Schaefer:

Latijn was mijn minst favoriete vak op de middelbare school. We moesten het volgen. Ik kan niet geloven dat we het moesten volgen, maar goed.

Ben Aston:

Nou, het heeft je goed voorbereid op alle talen die je nu spreekt, toch?

Ryan Schaefer:

Ja, precies. Mijn rol bij Viget als projectmanager omvat dus veel verschillende dingen. Natuurlijk zijn er de belangrijkste verantwoordelijkheden van een projectmanager, zoals tijdlijn, budget, planning, personeelsbezetting en middelen. Daarnaast doen we ook dingen die specifieker zijn voor productmanagement. We hebben hier geen aparte productmanagers, dus projectmanagers zijn verantwoordelijk voor veel gebruikersreizen, featuredefinitie, kwaliteitsborging en testen, en voor een volledig begrip van de bedrijven waarmee je werkt en de producten die je van binnen en van buiten helpt bouwen.

Ben Aston:

Dus het is project- én productmanagement?

Ryan Schaefer:

Ja, het is een-

Ben Aston:

Een combinatie van beide.

Ryan Schaefer:

Ja. Ze liggen in zekere zin in elkaars verlengde en het is nuttig om ze samen te doen. Tegelijkertijd zijn ze verschillend genoeg om voor afwisseling te zorgen wanneer je wilt overschakelen van aan het project werken naar het project leiden.

Ben Aston:

Kun je iets vertellen over projecten waaraan je nu werkt?

Ryan Schaefer:

Zeker. Ik ben een paar weken geleden overgestapt naar één enkel project, fulltime. Dat is me nog nooit eerder overkomen. We werken aan een grote marketingwebsite en daarnaast aan een soort portaal voor verschillende doelgroepen. Die kunnen inloggen en voor elke doelgroep wordt andere data opgehaald.

We vernieuwen in feite het hele ecosysteem, werken het ontwerp van al hun digitale materialen voor het publiek bij en maken vervolgens een roadmap voor toekomstige producten, zoals misschien een app. Het is behoorlijk omvangrijk en ik vind het geweldig om me in één project te kunnen verdiepen, het echt te leren kennen en er meer over te leren.

Ben Aston:

Je hebt het over een native-applicatie. Ik weet dat je binnenkort tijdens de DPM Summit een Lightning Talk geeft met tips voor het managen van een native-applicatie. Kun je een korte versie van je talk geven? Wat ontdek je over native-applicaties?

Ryan Schaefer:

Mijn talk is gebaseerd op wat ik heb geleerd tijdens het grootste project waaraan ik hier heb gewerkt: een ontwerp- en ontwikkelingsproject voor een Android-app.

Ik vertel wat ik heb geleerd en vooral wat de verschillen zijn tussen het managen van een native-applicatie en een gebruikelijker webproject, plus de beste werkwijzen daarvoor. Ook wil ik ingaan op specifieke technische vereisten waarvan je je als projectmanager bewust moet zijn.

Een paar voorbeelden: de kosten van een fout zijn bij een app erg hoog, omdat de app kan crashen. Bij een website druk je bij een fout meestal gewoon op Command-R of iets dergelijks om opnieuw te laden. Ook zijn de talen waarmee je native apps schrijft anders dan JavaScript, dat je voor webapps gebruikt. Bij native apps moet je 90% van een oplossing bedenken, tegenover 30 tot 40% bij webapps, waarbij JavaScript het verschil voor je invult.

Daarnaast zijn er systeembeperkingen en andere beperkingen, zoals offlinebeperkingen, waar je bij apps rekening mee moet houden. Hoe werkt een app wanneer die offline is? Hoe werken de menuknoppen op je telefoon samen met de app en waar brengen ze je naartoe? Dat soort zaken.

Ben Aston:

Je hebt webapps en native apps gebouwd. De trend die ik zag, was dat iedereen webapps maakte omdat ze eenvoudiger en sneller te bouwen zijn. Hoe kijk jij naar webapps tegenover native apps en de richting waarin dat zich ontwikkelt?

Ryan Schaefer:

Een interessante ontwikkeling die we als bedrijf zien en waarin we onze weg zoeken, is de opkomst van diensten zoals Squarespace, Beams binnen WordPress en Weebly. Dat zijn zeer praktische diensten waarmee mensen met beperkte technische kennis een goed uitziende website kunnen opzetten.

Door de lage kosten en de toegankelijkheid daarvan is het moeilijker om traditionele marketingwebsites te vinden om te bouwen. Native apps zijn nog niet op dezelfde manier toegankelijk geworden, dus daar zien we veel potentieel. En het is natuurlijk ook gewoon leuk om te kunnen zeggen dat je een app hebt.

Ben Aston:

Ja.

Ryan Schaefer:

Een ander aspect is dat er nog veel software en producten zijn die nog niet zijn ontdekt. Het project waar ik nu aan werk, bijvoorbeeld een portaal voor gebruikers achter een inlogscherm, biedt mogelijkheden die je niet op Squarespace of iets vergelijkbaars kunt bouwen.

Er zijn veel mogelijkheden voor maatwerk. Dat is interessant voor ontwerpers en ontwikkelaars, maar we kunnen op dit gebied ook nog veel ontdekken om het creëren van producten voor bedrijven spannender te maken.

Ben Aston:

Je bouwt apps en grote marketingwebsites. Wat zit er in je projectmanagementgereedschapskist? Hoe beheer je de producten en projecten waaraan je werkt? Welke zaken wil je aan het begin van een project altijd opzetten?

Ryan Schaefer:

Het is belangrijk om sterk te beginnen. Daarom faciliteer ik graag een discussiegerichte kick-off met de klant. Een verkennend gesprek is erg nuttig: je bespreekt wat de organisatie nu doet, wat het product wel en niet doet en waar ze naartoe willen. Ik organiseer ook graag workshops over problemen, doelen en doelstellingen, en interviews met belanghebbenden.

Dat zijn allemaal zaken die je niet uit het verkoopproces kunt halen, hoe gedetailleerd je ook probeert te zijn. Zodra je dit allemaal goed begrijpt — en het is belangrijk om daar in de scope rekening mee te houden, want het kan een paar weken of langer duren — begin je met al die kennis. Daardoor kun je sneller starten, efficiënter bouwen en uiteindelijk een beter eindproduct opleveren.

De tools om dat allemaal te ordenen kunnen behoorlijk uitgebreid zijn. Airtable is erg goed, net als GitHub Projects. Zen Hub kun je samen met GitHub gebruiken, en Trello. We hebben ze allemaal gebruikt, afhankelijk van de voorkeuren van klanten en onze eigen aanbevelingen.

Ben Aston:

Zijn er specifieke projectmanagementtools die je onlangs hebt ontdekt en die je leven makkelijker maken, zoals handige trucs of snelkoppelingen?

Ryan Schaefer:

Twee dingen. Ten eerste heb ik behoorlijk wat tijd besteed aan de sneltoetsen op mijn computer. Er zijn er zo veel en ze besparen echt tijd — misschien maar seconden, maar wel honderden keren per dag.

Het andere is-

Ben Aston:

Wat is de beste sneltoets die je onlangs hebt ontdekt?

Ryan Schaefer:

Command-Shift-T. Daarmee open je het laatst gesloten tabblad.

Ben Aston:

Handig.

Ryan Schaefer:

Ja, een goede.

Ben Aston:

Mijn favoriete recente sneltoets — ik had hier vroeger een aparte app voor — is Windows-V. Ik gebruik Windows, en in Windows 10 krijg je daarmee je kopieer- en plakgeschiedenis.

Ryan Schaefer:

Wauw.

Ben Aston:

Volgens mij voor altijd. Ik weet het niet zeker, ik heb het niet gecontroleerd. Ik ben iemand die graag het risicovolle spel speelt waarbij ik iets in Kladblok typ, het kopieer, vervolgens iets anders ga doen en vergeet het te plakken. Mijn kopieer- en plakgeschiedenis, waarin ook afbeeldingen staan, vind ik daarom erg handig. Dus Windows-V en Command-Shift-T, zei je dat? Kijk eens aan. Dat zijn jullie sneltoetsen van de week.

Ryan Schaefer:

Dat is een hele goede.

Ben Aston:

Nog iets anders?

Ryan Schaefer:

De nieuwe tool die ik gebruik en die veel voor me heeft veranderd, is Notion. Ken je die?

Ben Aston:

Ja.

Ryan Schaefer:

Het is een soort werkruimte-app. Je kunt hem gebruiken voor notities en samenwerking. Hij werkt ook offline, heeft een erg overzichtelijke gebruikersinterface en laat je inhoud insluiten, schakelaars toevoegen en eindeloos pagina’s nesten binnen subpagina’s. Er is ook een web- en mobiele app, dus je kunt hem overal gebruiken. Bovendien is hij erg aanpasbaar.

Daardoor kan ik tijdens een gesprek de app snel openen, iets typen wat ik nodig heb en het daarna of tijdens het gesprek eenvoudig netjes maken.

Ben Aston:

Met alle projecten waaraan je werkt, en zelfs met de tools waarover we het net hadden: wat vind je moeilijk? Wat zijn enkele dagelijkse uitdagingen in je rol? Wat is het lastigste aan je huidige werk?

Ryan Schaefer:

Veel dingen. Eén daarvan is niet genoeg tijd hebben. Maar ik denk dat het lastigste, of een van de lastigste dingen, het wisselen van context is.

Als projectmanager heb je normaal gesproken capaciteit voor meerdere projecten en vaak veel vergaderingen in je agenda. Je springt dan op het ene moment van de ene vergadering naar de andere en moet onderweg naar de volgende vergaderruimte alles voor dat project weer in je geheugen laden. Dat vind ik erg moeilijk. Ik probeer dit op te lossen door zeer zorgvuldige notities te maken waar ik direct naar kan verwijzen. Ik maak ook graag voor elke vergadering een agenda. Daarnaast neem ik aan het begin van de dag even de tijd om met een kop koffie na te denken over de status van elk project, waar het aan het begin van de dag staat en waar het aan het einde van de dag zou moeten staan. Dat probeer ik voortdurend te verbeteren.

Een andere uitdaging is een goede manier vinden om samenwerking en de kick-off te faciliteren tijdens de overdracht van ontwerpers naar ontwikkelaars. Vaak krijg je een prachtig ontwerp van de ontwerper, die samen met een UX-specialist heeft gewerkt. Alles ziet er geweldig uit en vervolgens wil je dat een ontwikkelaar ernaar kijkt en ermee instemt voordat je het aan de klant laat zien. Het is vaak niet duidelijk hoe je alle verschillende front-endfuncties en de werking in het beheergedeelte documenteert en definieert op basis van alleen een statisch ontwerp.

Daarom onderzoeken we met Airtable en vergelijkbare tools manieren om de contentstructuur zo op te zetten dat elk onderdeel van de ontwerpen aan elkaar wordt gekoppeld. Zo kan een ontwikkelaar aangeven: “Oké, zo gaat dit werken en zo gaat dat werken. Daarom kost het een week of iets dergelijks, dus we kunnen het binnen de tijd en het budget doen.”

Dat kan een nogal arbeidsintensief proces zijn en het is nog volop in ontwikkeling, maar hopelijk levert het uiteindelijk veel op.

Ben Aston:

Vertel daar eens meer over, want Airtable is in feite een soort combinatie van spreadsheet en database.

Ryan Schaefer:

Ja.

Ben Aston:

Is er een integratie met InVision, Sketch of de tool die je gebruikt voor je ontwerp en Airtable? Werkt het zo?

Ryan Schaefer:

Er zijn integraties, maar wij gebruiken voornamelijk Figma. Ik denk niet dat Airtable daarmee geïntegreerd is.

We hebben een paar verschillende dingen geprobeerd, bijvoorbeeld links in een Google-spreadsheet. Ik weet niet of we al op het punt zijn waarop we het op een zinvolle manier kunnen integreren met een tool die we zouden gebruiken. Ik weet ook niet of we een tool zouden kiezen omdat die met Airtable integreert. De grootste aantrekkingskracht is volgens mij dat het een relationele database is. Daardoor kun je heel eenvoudig dingen binnen de database aan elkaar koppelen. Het is bovendien goed schaalbaar, goed leesbaar en heeft een overzichtelijke interface.

Ben Aston:

Voor mensen die Airtable nog nooit hebben gebruikt: stel dat je verschillende bladen hebt. Hoe structureer je Airtable? Kun je daar iets meer inzicht in geven?

Ryan Schaefer:

Zeker. Als we beginnen met UI-verkenningen, documenteren we waar elk navigatie-item naartoe gaat met behulp van een sitemap. Daarna kun je een ander onderdeel maken — ze worden geen tabbladen genoemd, ik ben het juiste woord even kwijt, maar ze zien er effectief uit als tabbladen. Vervolgens kun je vastleggen wat je momenteel hebt door er vanaf het andere tabblad naar te verwijzen, nieuwe gebieden toevoegen en het onderscheid tussen de nieuwe gebieden op verschillende manieren aangeven. Dat kan eenvoudig met labels en categorieën, of door verschillende blokken te gebruiken die elk specifieke koppen, kleuren of iets dergelijks hebben.

Zo krijgt iedereen gedurende het project een overzichtelijk, gemakkelijk te begrijpen document dat als centrale bron van waarheid voor alles kan dienen.

Ben Aston:

Dat is interessant. Dit is vaak een grote uitdaging: hoe ga je van UX-ontwerp naar development en behoud je de vereisten?

Ryan Schaefer:

Precies.

Ben Aston:

Hoe leg je dat vast? Airtable gebruiken is een heel interessant idee. Ik had daar nog niet eerder aan gedacht, maar ik vind het goed dat je bijvoorbeeld kunt aangeven: “Dit is hetzelfde menu als dat je daar gebruikt.” Als je dit in Word of Google Spreadsheets doet, blijf je herhalen, kopiëren en plakken. Daarna wijzig je het op één plek en vergeet je het op een andere plek aan te passen. Omdat het een database is, kun je gewoon naar het menu-item of iets vergelijkbaars verwijzen. Dat is echt een goed idee.

Laten we het hebben over je artikel. Voor degenen die het nog niet hebben gelezen: het gaat over feedback geven op een manier die het project ten goede komt en uiteindelijk een beter product of project oplevert.

Kun je voor mensen die het artikel nog niet hebben gelezen jouw kijk op feedback geven delen? Als projectmanagers kunnen we daar soms bang voor zijn. Ik ben benieuwd waarom je denkt dat we ons inhouden en waar we volgens jou bang voor zijn.

Ryan Schaefer:

Ik denk dat er een paar redenen zijn waarom we ons inhouden.

De eerste is menselijk: we willen onze teamgenoten niet beledigen of het werk dat ze hebben gedaan onderuit halen. Daarnaast voelen we ons misschien niet zelfverzekerd genoeg over onze mening wanneer we feedback geven aan inhoudelijke experts, zoals ontwerpers en ontwikkelaars.

Dat zijn begrijpelijke zorgen. Uiteindelijk sta jij als projectmanager echter het dichtst bij de klant en kijk je met een frissere blik dan iemand die diep in het werk zit. Je kunt het perspectief van de eindgebruiker het beste simuleren. Je biedt dus een ander perspectief op het werk dan degene die het daadwerkelijk maakt.

Je mag je daarom zeker voelen in die deskundigheid en dat perspectief. Je kunt zeggen: “Ik zie dit als projectmanager voor het eerst. De gebruiker ziet dit ook voor het eerst. Brengt het duidelijk over wat de organisatie doet? Spreekt het de doelgroepen aan? Is het duidelijk dat dit een vervolgkeuzemenu is?” Die reactie helpt mensen een stap terug te doen en die zaken te toetsen aan verwacht gebruikersgedrag of aan de bedrijfsdoelstellingen.

Ben Aston:

Ik begrijp dat perspectief. We kunnen de bewakers zijn van succes en van de gebruikerservaring, juist dankzij die frisse blik.

In je artikel geef je tien aanwijzingen voor het geven van goede feedback. De eerste is dat je jezelf moet voorbereiden en vanuit een geïnformeerde positie moet handelen, bekeken vanuit het perspectief van zakelijk succes. Je noemt een grondige projectanalyse met de klant. Je begint nu aan een nieuw project en doet zo’n analyse. Wanneer weet je of je voldoende geïnformeerd bent? Hoe pak je zo’n grondige analyse aan zodat je dingen echt goed begrijpt en niet alleen denkt dat je iets weet?

Ryan Schaefer:

Een goede vraag. Ik denk dat je nooit helemaal zeker weet of je volledig geïnformeerd bent, en dat is prima.

Ben Aston:

Ja.

Ryan Schaefer:

Ik noemde verkennende gesprekken. Dat is volgens mij een goed startpunt, omdat je leert hoe het bedrijf zichzelf ziet en waar het naartoe wil. Bijvoorbeeld: “Dit is iets waarover onze CEO beslist. Gaan we dit bedrijf overnemen? Gaan we fuseren? Gaan we naar de beurs?” Wat het ook is.

Als je vervolgens met leidinggevende belanghebbenden praat, krijg je een beeld van hoe ze dat willen uitvoeren. Dat levert opnieuw inzicht op vanuit een hoger perspectief. Zodra je een discussiegerichte kick-off start met de mensen die direct bij het project betrokken zijn, krijg je inzicht in de manier waarop het project aansluit op wat de leidinggevenden willen doen en hoe dat verband houdt met de bredere bedrijfsdoelen. Al die zaken moeten uiteindelijk worden gecommuniceerd en zichtbaar zijn in wat je probeert te bereiken.

Je moet tijdens al die gesprekken voldoende specifieke informatie verzamelen om te begrijpen wat ze willen doen. Als je dat begrijpt, ben jij het middel waarmee je hen helpt daar te komen: door hun communicatie te verfijnen, hun merk uit te dragen via een nieuw uiterlijk, hun boodschap te verbeteren of aan te bevelen dat we het product uitbreiden en een app bouwen met bepaalde functies.

Het is een voortdurend proces en vereist aan het begin een flinke investering. We richten ons sterk op ontdekkingsfasen die bedoeld zijn om precies de vragen te beantwoorden die je net stelde. Zoals ik al zei, is dat erg nuttig, het stroomlijnt het proces aanzienlijk en leidt uiteindelijk tot een beter eindproduct.

Ben Aston:

Om geïnformeerd te zijn, moeten we onze klanten begrijpen. We moeten begrijpen hoe succes er voor hen uitziet vanuit zakelijk perspectief, en we moeten de gebruikers en hun behoeften begrijpen: wat zal bij hen aanslaan om dat zakelijke succes te stimuleren? Je noemde ook geïnformeerd zijn over best practices en het je verdiepen in verschillende vakgebieden.

Je hebt ervaring met development en design. Hoe ziet het je verdiepen in andere vakgebieden er voor jou uit? Hoe maak je jezelf vertrouwd met kwaliteitsborging, UX of andere zaken waar je niet volledig bekend mee bent, zodat je met enige basiskennis toch succesvol feedback kunt geven?

Ryan Schaefer:

Als je hiermee vertrouwd raakt en op een gegeven moment gedetailleerdere feedback aan teamleden kunt geven, moet dat op een diplomatieke en objectieve manier gebeuren, niet op een subjectieve manier.

Om vertrouwd te raken met die zaken moet je volgens mij zoveel mogelijk met mensen in je team praten en eerlijk zijn over de hiaten in je kennis. Als ik vanuit development kom en minder vertrouwd ben met gebruikerservaring, moet ik niet bang zijn om mee te kijken met een UX-specialist terwijl die een grote audit uitvoert.

Daarnaast moet je de dingen gewoon doen. Er zijn enorm veel hulpmiddelen als je wilt leren programmeren of ontwerpen. Je kunt veel inspiratie halen uit projecten die je team heeft gedaan. Let op trends en dergelijke en lees artikelen. Ik probeer vijf uur per week iets te ontwerpen, mijn programmeervaardigheden op peil te houden en artikelen te lezen. Naarmate je meer vergaderingen bijwoont en langer in de digitale wereld werkt, neem je dat soort kennis bovendien vanzelf op.

Ben Aston:

Welke websites bezoek je om op de hoogte te blijven van wat er speelt?

Ryan Schaefer:

Thedigitalprojectmanager.com is een goede.

Ook A Girl’s Guide to Project Management is goed. Adweek is interessant om te zien welke kant de creatieve sector opgaat. Voor development is W3Schools geen nieuwssite, maar het biedt hulpmiddelen om allerlei effecten uit te proberen, zoals CSS, JavaScript en meer backendonderwerpen. Dat zijn goede plekken om te beginnen.

Ben Aston:

Je had het over het aanscherpen van je eigen vaardigheden. Ik ben daar een groot voorstander van: eigen hack- en zijprojecten om ermee vertrouwd te raken. Je kunt veel beter met een ontwikkelaar praten als je zelfs maar een basisbegrip hebt van hoe dingen samenhangen en werken.

Begin dus iets te maken. Maak je eigen portfolio-website of wat dan ook. Iets lezen is één ding; het zelf doen en kijken wat er gebeurt is iets anders. Als je een ontwerper vertelt dat hij iets gewoon moet doen, helpt het om het zelf te proberen. Zo begrijp je hoeveel of hoe weinig moeite het kost, wat kan helpen wanneer we mensen feedback geven.

Ik ben benieuwd of je verhalen hebt over momenten waarop dit bij jou verkeerd uitpakte. Wanneer we feedback geven, kunnen we denken dat we goed geïnformeerd zijn, maar het is hun werk en zij zijn de professionals. Heb je ooit meegemaakt dat iemand zei: “Hou op, Ryan. Jij bent de ontwerper niet, ik wel. Hiervoor word ik betaald. Ik heb niets aan jouw feedback”?

Hoe ga je ermee om wanneer mensen je mening niet serieus nemen omdat je alleen de projectmanager bent?

Ryan Schaefer:

Dat is mij gelukkig nog niet overkomen. Dat komt deels door de geweldige mensen met wie ik werk. Daarnaast is het belangrijk om het perspectief van de klant centraal te stellen. Dat is een perspectief dat je team moet en zal respecteren. Vooral wanneer je laat zien hoe hun beslissingen, de logica die ze hebben ontwikkeld en de systemen die ze hebben opgezet, rechtstreeks verband houden met de doelstellingen die we aan het begin van de fase hebben bepaald en afgesproken.

Het gaat dus minder om: “Ik vind die kleur niet mooi”, en meer om: “We weten dat hun merkrichtlijnen deze kleur als tertiaire kleur gebruiken. De kleur neemt veel ruimte in beslag. Zou dat voor hen onaangenaam kunnen zijn?” Je ontwerper heeft daar waarschijnlijk al over nagedacht en zal een onderbouwing hebben. Als die voor jou logisch is, zal die ook voor de klant logisch zijn. Als de ontwerper er nog niet over heeft nagedacht, is het goed dat die persoon zich daarvan bewust wordt. Vervolgens kan hij het besluitvormingsproces uitleggen of de nodige aanpassingen maken.

Ben Aston:

Een nuttig punt uit je artikel is dat het niet allemaal op jou neerkomt. Je kunt het perspectief van de klant bieden, maar je noemde ook dat je de juiste mensen moet inschakelen voor moeilijke gesprekken. Als een ontwerper de verkeerde kleur gebruikt, hoef jij dat niet alleen op te lossen. Je kunt de creatief directeur erbij betrekken en vragen: “Vind je het goed om deze andere kleur te gebruiken?” Zo krijg je ook het perspectief van anderen en draag je niet alleen de verantwoordelijkheid om alles wat juist is te bewaken.

Je noemde ook dat je rekening moet houden met verschillende reacties van je team. Mensen reageren verschillend op feedback. Je hebt het over wat harde liefde en over motiverende interacties, maar ook over het voorkomen dat je boodschap onduidelijk wordt.

Dat is lastig. We willen aardig zijn en niemands gevoelens kwetsen. Hoe vind je de balans tussen harde liefde, een duidelijke boodschap en toch constructief blijven? Je had het ook over constructieve lof. Hoe geef je die lof zonder je feedback onduidelijk te maken? Het klinkt ingewikkeld.

Ryan Schaefer:

Het is geen exacte wetenschap en ik wou dat ik een duidelijk stappenplan had. Als projectmanager beschik je waarschijnlijk over een zekere emotionele intelligentie. Daarmee kun je ter plekke aanvoelen hoe mensen je feedback ontvangen en daarop reageren.

Wat vooral helpt om negatieve reacties te beperken en te bepalen of iemand motivatie, aanmoediging of juist harde liefde nodig heeft, is specifiek zijn. Als projectmanager bepleit je geen subjectieve zaken, want dat is waarschijnlijk niet jouw rol. Je bepleit objectieve beslissingen die, zoals ik al zei, aansluiten bij de doelen van het project.

Probeer daarnaast altijd subtiel te laten merken dat je vertrouwen hebt in het vermogen van die persoon om het werk uit te voeren. Dat werkt bemoedigend, ongeacht of iemand opbouwende kritiek persoonlijk opvat of er juist onverschillig tegenover staat en die gebruikt om van te leren.

Ik vind het zelf prettig om in vrijwel elke context goede dingen over mezelf te horen, zolang het niet neerbuigend klinkt. Als je specifiek bent in je feedback, klinkt die uiteindelijk niet neerbuigend.

Ben Aston:

Tot slot: stel dat mensen naar deze podcast hebben geluisterd en denken: “Mijn UX- of designteam zal nooit naar me luisteren. Ze zien me alleen als iemand die administratie doet.” Wat is dan één eerste stap of één belangrijk punt dat mensen moeten onthouden wanneer ze het gevoel hebben dat hun stem niet telt?

Ryan Schaefer:

De eerste keer dat je iets ziet dat niet klopt — een prototype, ontwerp of wat dan ook — hoef je niet meteen je mening te geven, zeker niet als je het voor het eerst ziet. Neem de tijd, ga terug naar je bureau, bekijk het en maak wat aantekeningen. Bedenk waar het ontwerp of artefact volgens jou tekortschiet en, belangrijker nog, welke verbeteringen je voorstelt.

Zo krijg je de tijd om de oefeningen te doorlopen die zij ook hebben gedaan. Bovendien kom je voorbereid en met een goede onderbouwing voor je suggesties. Hoe meer tijd je neemt en hoe grondiger en vollediger je bent, hoe meer je teamlid je feedback zal respecteren en hoe meer die persoon ervoor openstaat om je ideeën in de volgende iteratie te verwerken.

Ben Aston:

Dat is goed advies. Mensen kunnen soms in de verdediging schieten wanneer we simpelweg zeggen: “Ik vind dit echt niet mooi” of “Ik denk niet dat dit goed werkt.”

Neem vooral de tijd wanneer je niet zeker bent van je mening om goed te onderzoeken waarom je denkt dat iets niet klopt. Zorg voor een onderbouwing. Zeg niet: “Ik vind het niet mooi.” Zeg bijvoorbeeld: “Ik denk niet dat dit helemaal goed zit. Dat komt doordat de klant heeft aangegeven dat het dit moet doen, en ik weet niet zeker hoe dat gaat gebeuren. Kun je me uitleggen hoe jij denkt dat het moet werken?”

Je kunt vragen stellen, je verdiepen in de keuzes van degene die het werk heeft gemaakt en vervolgens zeggen: “Dit zou volgens mij een manier kunnen zijn om aan die behoefte te voldoen.”

Een onderbouwing geven, vragen waarom iemand een bepaalde keuze heeft gemaakt en vervolgens oplossingen voorstellen is volgens mij erg belangrijk. Schets dingen op een whiteboard als dat kan. Ik teken zelf altijd dingen in een notitieboek of op een whiteboard, zodat het niet voelt alsof ik het ontwerp overneem. Je komt gewoon met ideeën. Dat kan ervoor zorgen dat je team effectiever met je feedback aan de slag kan.

Ryan, enorm bedankt dat je bij ons was. Het was geweldig om je erbij te hebben.

Ryan Schaefer:

Heel erg bedankt. Ik waardeer het.

Ik ben benieuwd wat jij ervan vindt. Heb je ooit geprobeerd feedback te geven? Hoe werd die ontvangen? Was het team boos of waren ze juist blij dat je iets had opgemerkt waar ze zelf nog niet aan hadden gedacht?

Laat ons weten wat je vindt. Reageer op het artikel en ga naar thedigitalprojectmanager.com om lid te worden van ons Slack-team. Daar vind je allerlei interessante gesprekken over alles wat met projectoplevering te maken heeft.

Als je vandaag iets interessants hebt gehoord, abonneer je dan en neem een paar minuten de tijd om een eerlijke beoordeling achter te laten voor de DPM-podcast op Apple Podcasts. We hechten veel waarde aan je beoordelingen en recensies. Alvast hartelijk bedankt.

Tot de volgende keer. Bedankt voor het luisteren.