Beleefd vertellen een incompetente software project vrijwilliger ze zijn te onervaren

Je kunt die kwestie helemaal naast je neerleggen.

Je hoeft er niet eens bedrieglijk over te zijn.

Zeg hen gewoon dat het deel van het project waar ze realistisch gezien mee kunnen helpen nu af is (want dat is, dat is helemaal de waarheid) en dat je weer contact met hen opneemt als er iets anders naar voren komt waar ze mee kunnen helpen. Dit heeft belangrijke voordelen:

• Je verbrandt geen bruggen.
• Het kan de junior ontwikkelaar ertoe aanzetten om meer te leren in een poging om vaardigheden te verwerven die relevanter zijn voor het project.
• Je ontslaat ze niet of insinueert dat ze helemaal incompetent zijn.
• Dit is normaal voor collaboratieve vrijetijdsprojecten. Op een gegeven moment eindigt het werk dat iemand zonder bepaalde vaardigheden kan doen.

Met deze strategie vermijd je het probleem dat je ze moet “ontslaan”.

Je kunt ze ook opnieuw toewijzen aan taken die gedaan moeten worden, maar je hebt geen ontwikkelaar nodig om ze te doen, of taken die secundair zijn (leuk om te hebben). Meestal omvat dit:

• Schrijven van docs
• Code review
• Uitgebreid Q/A testen

Wees op zoek naar taken die je niets kosten als ze slecht gedaan zijn, maar die wel veel helpen als ze enthousiast worden voltooid.

Ik weet niet zeker of je ze helemaal uit het project moet ontslaan, je zou ze ook kunnen verplaatsen naar een positie waar ze andere mensen (waaronder jou) niet blokkeren.

Ten eerste klinkt het alsof het grootste probleem voor jou de coaching is - dus schaal de coaching terug. Je zou zoiets kunnen zeggen als:

Hé Bob, op dit moment is er veel aan de hand in mijn leven en ik kan gewoonweg geen tijd meer vinden voor onze trainingen [of hoe je ze ook noemt], sorry daarvoor.

dan, verplaats ze ‘uit de weg’ door ze een of twee eenvoudige taken toe te wijzen met niet-dringende prioriteit. Als ze kunnen leren en de taak in hun eentje kunnen volbrengen: geweldig, geef ze iets uitdagender en herhaal tot je hun niveau van competentie hebt gevonden. Zo niet, kom dan terug naar hen wanneer de taak met prioriteit is opgeschoven (wanneer het snel nodig is). Als je er diplomatiek over wilt doen, kun je zeggen:

Hé Bob, we hebben de documentatie / vertalingen / uitgevoerde testen / foobar binnenkort nodig. Zou je daar voor kunnen zorgen en dan neem ik in de tussentijd de ontdooier over?

Het helpt echt als je jezelf ervan kunt overtuigen dat documentatie en testen belangrijke taken zijn - want ze zijn are. Veel ontwikkelaars willen geen documentatie schrijven en dat bezegelt het lot van menig klein open source softwareproject: hun software lost een probleem op, maar de meeste mensen kunnen er niet achter komen hoe ze het moeten gebruiken, dus niemand gebruikt het.

Tot slot: u noemt “Ik heb nog nooit met andere ontwikkelaars gewerkt” en het is mij niet helemaal duidelijk hoe u het werk in uw project organiseert. Het organiseren van software ontwikkeling is een zeer waardevolle skillset, dus misschien wil je deze kans wel gebruiken om zelf te leren en te groeien. Leer om werk op te splitsen in taken en subtaken, om afhankelijkheden te achterhalen, om de benodigde tijd in te schatten, om te prioriteren wat belangrijk is en wat kan wachten, om te peilen wie wat kan doen. Leer hoe u het beste kunt communiceren met uw collega’s en hoe u opnieuw kunt plannen als de dingen niet werken zoals u verwachtte. Gebruik de samenwerkingstools (issue tracker, versioning systeem, etc.).

Misschien dat methodologieën en vogue in het bedrijfsleven op dit moment (Scrum, Kanban, etc.) je een aantal nuttige richtlijnen zouden geven.

Ten eerste ben ik het eens met het deel over het bedanken van de vrijwilliger voor zijn tijd/inspanning tot nu toe, en zeggen dat het deel van de primaire ontwikkeling waar je hem voor nodig had, af is.

Mag ik je aanraden, voor jullie beiden, om te investeren in een extra mentorschapsessie. Het onderwerp: laat zijn slechte zelf zien hoe hij eenheidstests moet schrijven. Vertel hem dan dat als hij meer technologische hulp wil doen (in tegenstelling tot andere soorten), hij moet beginnen met het uitbreiden van de stal van DeepL. De voordelen:

• Je krijgt unit tests!

• Vrijwilliger wordt geïntroduceerd in de belangrijke aard van unit tests!

• Als vrijwilliger is traag of komt vast te zitten, het niet interfereren met de hoofdlijn ontwikkeling

Dan, net als bij andere antwoorden, kunt u bedelen meer training, als je hebt verloren elke speling in je schema.

Omdat ze een vrijwilliger zijn, denk ik niet dat het nodig is om ze te “ontslaan”, omdat het zo onbeleefd zou zijn om het zo te verwoorden. In plaats daarvan zou het misschien beter zijn om te zeggen dat het vrijwilligerswerk waar je ze voor nodig hebt, nu al klaar is. Ook, wees er zeker van dat je ze vriendelijk bedankt voor het werk dat ze al gedaan hebben, geef commentaar op het succes ervan en hun persoonlijke groei, maar geef ze gewoon geen nieuwe taken.

Dit werkt vooral voor vrijwilligers, omdat ze technisch gezien nooit in dienst zijn geweest, alleen helpen waar ze nodig waren en als je het kunt verwoorden op een manier die laat zien dat ze geslaagd zijn in het doen van hun taak, dan moet het met positieve gevoelens worden beantwoord in plaats van negatieve.

Heel erg bedankt {naam}, {X} een deel van het project is goed bezig en werkt goed! Je hebt alles gedaan wat ik nodig had, maar als het goed met je is zou ik je kunnen vragen om in de toekomst nog wat meer werk te doen?

Vragen of het goed is voor iets wat ze willen is heel handig omdat het de metaforische brug die je noemde met je houdt, het zorgt ervoor dat ze het met je eens zijn, het geeft ze de opties die ze ooit kiezen om je doel te bereiken om ze te stoppen met werken aan het huidige project en het is beleefd.

Helaas zal dit niet in alle gevallen werken en ik weet niet de details van je project/wat hij is toegewezen. Als je moet kiezen tussen wat boller zijn of liegen, zou dat op de lange termijn waarschijnlijk helpen (dat wil niet zeggen dat je je moet concentreren op het slechte!).

Je hebt ons veel geholpen en verbeterd, maar ik denk dat het beter zou zijn als {moeders} en ik de resterende taken afronden.

en

Als er in de toekomst iets komt dat beter geschikt is voor je vaardigheden zal ik het zeker naar je toe sturen.

kan in sommige gevallen geschikter zijn.

Mijn lezing van deze situatie is… laten we zeggen een beetje cynisch. Daarbuiten is er voortdurend het advies voor nieuwe ontwikkelaars om hun namen te krijgen op pull-verzoeken als een manier om hun GitHub-credit voor potentiële werkgevers te verbeteren. Op andere sites is er voortdurend advies voor nieuwe ontwikkelaars om deel te nemen aan een open-sourceproject als een manier om ervaring op te doen. Die ervaring gaat ten koste van de tijd die de meer senior devs besteden aan die projecten.

Terwijl ja, de junior dev geeft hun vrije tijd op - ik zie het niet als zodanig. Dit is een junior dev die gratis mentorschap krijgt en de bouw hervat ten koste van een door jou uitgevoerd vrijwilligersproject. (Naar mijn mening) zijn de kosten van mentorschap op een vrijwilligersproject zelden de tijd waard, tenzij de persoon zich inzet voor het project en er een oprechte interesse in heeft die verder gaat dan de GitHub-credit.

Er zijn twee wegen te overwegen.

Mentor de junior dev. Je blijft je inzetten en zorgt ervoor dat het ingezonden materiaal voldoet aan jouw normen voor het project. Je primaire rol hierin is die van mentor om ervoor te zorgen dat zowel je project als de junior dev’s zich inzetten voor het project zijn wat je verwacht.

Mentor de junior dev niet. Je tijd als vrijwilliger om aan je project te werken is net zo waardevol, zo niet meer, dan zijn tijd. Er zijn waarschijnlijk velen die de winkel sluiten als voorbereiding om te zeggen “het is klaar” en door te gaan naar een ander project. Vaak zijn dit vervelende en saaie taken, maar ze moeten nog gedaan worden. Dingen zoals:

• documentatie - laat een andere persoon alle geschreven tekst doorlezen en zorg voor de juiste spelling, interpunctie, grammatica, opmaak, enzovoorts.
• style cleanup - pak je favoriete linter en voer de code door volgens de stijl die je wilt. Log alle stijlopschoonmaakitems als probleem per bestand op te schonen.
• testschrijven - werk aan het verbeteren van de codedekking. Er moeten altijd tests worden geschreven.

Realiseer je en onthoud dat als er een taak is die je 4 uur voor jezelf moet doen, of 3 uur van je tijd en 8 uur van de junior dev tijd, er niet veel zin is om de junior dev het te laten doen, tenzij je rekening houdt met de waarde van het hebben van de junior dev ervaring opdoen.

Kijk naar wat elke persoon (jij en de junior dev) uit de regeling halen. Jullie zijn allebei vrijwilligers. Als er niet iets voor een vrijwilliger is om te doen - dat is oké.

Vertel ze de waarheid, maar blijf bij de feiten.

Wees rechtuit en eerlijk en leg de feiten op zoals je ze hier hebt gepresenteerd:

• Achteraf gezien zie je nu dat de hoeveelheid hulp die ze nodig hebben erg tijdrovend is. Het is begonnen met het belemmeren van je eigen vermogen om aan het project te werken.
• Je bent het project aan het afronden. Je nadert een punt waarop je niet meer aan het project zult werken. Laat ze weten wat de redenen hiervoor zijn. (Bijvoorbeeld.., misschien wordt het vervangen door een nieuw project met betere ondersteuning/financiering of is er gewoon niet veel werk meer te doen)
• Bedank ze voor alle moeite die ze in dit project hebben gestoken, en vertel ze dat je hoopt dat de ervaring nuttig is geweest voor de ontwikkeling van hun vaardigheden.
• Mogelijk bieden ze aan om een ander project te vinden waar ze ontwikkelingswerk kunnen blijven doen, misschien nog één in lijn met hun huidige niveau.

Wees je ervan bewust dat ze zouden kunnen reageren door te vragen of ze kunnen blijven werken zonder zo'n nauwlettend toezicht. Als het haalbaar is, zou je kunnen overwegen om bewust meer afstand te nemen van de aanpak en dan gewoon hun werk te herzien als het done is (bijv. als een pull-verzoek). Het is aan jou of dit haalbaar is. Als u een kleine verandering voor hen kunt vinden om te implementeren, zou u dit kunnen overwegen. Als je het probeert en het gaat niet goed, kun je ze specifiek laten zien wat er mis is met hun werk, en moet je misschien terugkomen op deze discussie over het niet hebben van tijd en het afbouwen van het project.

Dingen niet om te zeggen:

• Je ontslaat ze.
• Je geniet niet meer van het project vanwege hen.
• Ze zijn incompetent of iets anders over hun aangeboren vermogen.

Soms is het beter om niet alles te zeggen wat je denkt en voelt. Niet omdat je oneerlijk bent, maar omdat je weet dat je gevoelens en gedachten niet helemaal objectief zijn. Onze oordelen worden soms vertroebeld door onze onvervulde verlangens, dus soms houden we onze mond over gedachten en gevoelens waarvan we weten dat ze niet echt geldig zijn.

Ja, er is een inherent risico dat je hun gevoelens zou kunnen kwetsen. Any benadering hier brengt risico’s met zich mee. Als je niets doet, loop je het risico dat je gefrustreerd raakt en het op een niet-constructieve manier loslaat, en als je liegt of de waarheid verdoezelt, loopt de andere persoon het risico om erachter te komen wat er werkelijk is gebeurd. Eerlijk zijn heeft de verdienste dat je de ander vertrouwt om de situatie zelf te evalueren en de dingen te komen zien zoals jij dat doet. De persoon kan zien dat je niet oneerlijk bent en dat je probeert de situatie objectief te benaderen. Als ze je standpunt niet begrijpen, is het oké om het met hen uit te praten en uit te leggen; dat is niet echt mogelijk als je niet rechtuit bent.

Als je voelt dat de andere persoon begint te twijfelen aan het feit dat je vriendschap zal voortduren, maak dan duidelijk dat je het wilt voortzetten. Hoe je dat doet valt buiten het bestek van deze vraag, want het hangt af van de specifieke kenmerken van de reactie van de andere persoon.