Het stereotype developer stamt nog uit de jaren 80. De pukkelige nerd, de gamer, de hacker, de verlegen jongen die niet met meisjes durft te praten. Maar tijden veranderen, en developers ook. In het tijdperk van online marketing zijn goede developers belangrijker en schaarser dan ooit. Bij de meeste bedrijven zie je minstens één vacature open staan voor een development functie. Volgens het UWV heeft de sector de hoogste vacaturegraad van alle sectoren. Hoe kun je dan de beperkte tijd van de developer die je hebt, zo effectief mogelijk gebruiken? Goede communicatie is key, maar dat is nou net het punt waar het vaak bij developers moeizamer verloopt. Mijn naam is Roos en ik, als developer, kan je vertellen hoe je het beste met 'ons' kan communiceren!
Als je kijkt waar de meeste projecten planningwise op uit lopen, is het antwoord vaak communicatie. Of dit nou vanuit de klant of vanuit het development team is. Één van de twee partijen heeft niet duidelijk genoeg gecommuniceerd met de ander. Dit zorgt niet alleen voor problemen in het huidige project, maar ook de volgende projecten die uitgesteld kunnen worden of zelfs volledig van de planning worden geschoven. Dat is voor niemand leuk, klant ontevreden, bedrijf ontevreden, developer ontevreden, oftewel iedereen ontevreden. Dat wil natuurlijk niemand, daarom hieronder vier tips om de communicatie vanuit jouw kant wat soepeler te laten verlopen. Nou ga ik niet beweren dat alle developers hetzelfde zijn. De onderstaande tips zijn uit mijn eigen ervaring met developers ontstaan. De typische developer bestaat niet meer, niet alleen dat typische nerd schrijft code, ze zijn er tegenwoordig in alle vormen en maten. Zo komen er bijvoorbeeld steeds meer vrouwelijke developers bij! Maar communicatie blijft universeel een probleem. En daarin kun jij een handje helpen. Maar als het probleem bij de developer ligt waarom zou jij het dan oplossen? Omdat zij het waarschijnlijke te druk hebben, ze minder goed zijn in zich aanpassen, en omdat jij er uiteindelijk baat bij zal hebben. Met de onderstaande tips zorg je er niet alleen dat de communicatie, maar het hele project soepeler verloopt.
Weet wat je wil
Door wat extra tijd te nemen in het begin van het proces kun je een hoop tijd besparen aan het einde van het proces. Gebruik die tijd om te onderzoeken wat jij en je collega’s precies willen. Door “oh kan dit er ook nog bij” te voorkomen kun je veel tijd en onrust op de planning besparen. Het kan namelijk zijn dat de hele structuur van de code van het product anders moet worden, voor wat voor jou een makkelijke toevoeging lijkt. Developers zijn slecht in nee zeggen, ze denken in oplossingen. Als je vraagt of iets mogelijk is zullen ze altijd ja zeggen, maar of daar de tijd voor is, hebben ze waarschijnlijk nog niet over nagedacht. Als je niet weet wat de mogelijkheden zijn, ga dan in gesprek met de developer en laat je adviseren, maar houd zelf ook de planning van het project in de gaten.
Wees direct in je communicatie
Er zit een groot verschil tussen hoe developers communiceren en hoe bijvoorbeeld marketeers communiceren. De meeste developers zijn no-nonsense. Ze willen graag weten waar het op staat en kunnen niet snel tussen de regels door lezen. Als je iets lelijk vindt, dan willen ze dat horen. Door direct te zijn in je communicatie zal het proces een stuk sneller gaan. Een onderdeel daarvan is om besluitvaardig te zijn. Knopen zullen doorgehakt moeten worden. Dus wees duidelijk in wat je wil, maar sta open voor advies. Als je je ergert aan het gedrag van een developer, zeg het dan ook op een directe manier. Ze zullen subtiele hints niet snappen.
Gebruik vaste feedback momenten
Feedback is nodig, hoe goed je briefing ook is, er is altijd ruimte voor interpretatie. Maar waar je developers gek mee maakt is te vaak, te veel en onduidelijke feedback. Als je met je hoofd in de code zit, heb je hier je volledige aandacht voor nodig. Voor de mensen die geen code schrijven, je kunt het schrijven van code vergelijken met het maken van een enorme sudoku. Zet een cijfer verkeerd, en de sudoku werkt niet meer. Met elk element wat je toevoegt wordt de sudoku groter en ingewikkelder.
Na de briefing maken de developers de sudoku op en vullen hem in. Ze sturen de sudoku op en krijgen feedback. Alle gekregen feedback passen ze in één keer aan. Na het opsturen van de sudoku gaan ze verder met de volgende sudoku. Stel je voor, je bent bezig met een sudoku en voor kleine feedback puntjes moet je steeds weer heen en weer tussen de vorige en de huidige sudoku. Dan kom je niet verder met de nieuwere sudoku en je concentratie is volledig weg, de productiviteit zakt enorm.
Om deze situatie te voorkomen, neem rustig de tijd om feedback te geven. Laat er meerdere mensen naar kijken, noteer de punten, maak een wandeling en kijk er nog een keer naar. Noteer de punten en stuur ze in één keer op of op vaste momenten bij een groter project. Zo houd je je developer blij, en de productiviteit hoog.
Zorg voor een ontspannen sfeer
Als je de hele dag bezig bent met “sudoku’s” maken, moet je af en toe even een break hebben. Developers hebben wat vaker behoefte aan afleiding, dit heeft niet altijd te maken met laksheid. Dit pauzemoment kun je creëren door een tafelvoetbaltafel neer te zetten of de developers stimuleert om af en toe een rondje te laten lopen. Pauzes zorgen ervoor dat de kwaliteit van de code hoog blijft en er minder fouten gemaakt worden. En een kleine pauze waarbij de developer van zijn computer weg gaat is een stuk effectiever dan wanneer de developer op Reddit beland, want krijg hem er dan maar weer eens af.
Ook vinden de meeste developers een goede werksfeer belangrijker dan carrière maken. Ze hebben meer respect voor iemand die zijn werk gewoon goed doet dan iemand die hoog van de toren blaast. Dus doe maar normaal tegen developers, want ze zijn al gek genoeg, maak eens een grapje met ze, in plaats van over ze. Stuur ze eens een meme, en ze zullen altijd van je houden.