Dire gentilmente a un volontario incompetente di un progetto software che è troppo inesperto

Non c'è bisogno di essere ingannevoli.

Non c'è bisogno di essere ingannevoli.

Dite loro semplicemente che la parte del progetto che possono realisticamente aiutare è finita (perché è così, questa è tutta la verità) e che li contatterete di nuovo se salta fuori qualcos'altro che possono aiutare. Questo ha dei vantaggi chiave:

• Non stai bruciando nessun ponte.
• Può spingere lo sviluppatore junior ad imparare di più nel tentativo di acquisire competenze più rilevanti per il progetto.
• Non li stai licenziando o insinuando che sono incompetenti.
• Questo è normale per i progetti di collaborazione nel tempo libero. A un certo punto, le cose che qualcuno senza certe competenze può fare, finiscono.

Usando questa strategia, si evita completamente il problema di doverli “licenziare” del tutto.

In alternativa, è possibile riassegnarli a compiti che devono essere fatti ma che non hanno bisogno di uno sviluppatore per farli, o compiti che sono secondari (bello averli). Di solito, questo include:

• Scrivere documenti
• Revisione del codice
• Test Q/A approfonditi

Essere alla ricerca di compiti che non vi costano nulla se sono fatti male, ma che vi aiutano molto quando li completano con entusiasmo.

Non sono sicuro che tu debba licenziarli completamente dal progetto, potresti anche spostarli in una posizione in cui non blocchino altre persone (te compreso).

Innanzitutto, sembra che il problema principale per te sia il coaching - quindi ridimensiona il coaching. Potresti dire qualcosa del tipo:

Ehi Bob, attualmente mi stanno succedendo un sacco di cose nella mia vita e non riesco più a trovare il tempo per le nostre sessioni di allenamento [o come le chiami], mi dispiace.

Poi, spostali “fuori dai piedi” assegnando loro uno o due semplici compiti con priorità non urgente. Se sono in grado di imparare e completare il compito da soli: ottimo, date loro qualcosa di più impegnativo e ripetete fino a quando non avrete trovato il loro livello di competenza. In caso contrario, tornate da loro quando il compito è salito di priorità (quando è necessario a breve). Se volete essere diplomatici a riguardo, potreste dire:

Ehi Bob, abbiamo bisogno della documentazione / traduzioni / test eseguiti / foobar presto. Potresti occupartene tu e io nel frattempo mi occupo del defrobulatore?

È davvero utile se riesci a convincerti che la documentazione e i test sono compiti importanti - perché sono. Molti sviluppatori non vogliono scrivere documentazione e questo suggella il destino di molti piccoli progetti di software open source: il loro software risolve qualche problema ma la maggior parte delle persone non riesce a capire come usarlo, quindi nessuno lo usa.

Infine: lei parla di “non ho mai lavorato con altri sviluppatori prima d'ora” e non mi è del tutto chiaro come organizza il lavoro nel suo progetto. Organizzare lo sviluppo di software è un insieme di competenze molto prezioso, quindi potreste voler sfruttare questa opportunità per imparare e crescere voi stessi. Imparate a suddividere il lavoro in compiti e sottocompiti, a capire le dipendenze, a stimare il tempo necessario, a prioritizzare ciò che è importante e ciò che può aspettare, a valutare chi può fare cosa. Imparate a comunicare al meglio con i vostri colleghi e a replicare quando le cose non vanno come vi aspettavate. Usate gli strumenti di collaborazione (issue tracker, sistema di versioning, ecc.).

Forse le metodologie in voga nel mondo del business al momento (Scrum, Kanban, ecc.) vi darebbero delle linee guida utili.

In primo luogo, sono d'accordo con la parte che riguarda il ringraziamento al volontario per il suo tempo/sforzo fino ad oggi, e dico che la parte dello sviluppo primario su cui avevate bisogno di lui è terminata.

Posso consigliarvi, per il vostro bene, di investire in un'altra sessione di mentoring. L'argomento: mostrate il suo cattivo sé come scrivere test unitari. Poi ditegli che se vuole fare più aiuto con la tecnologia (al contrario di altri tipi di aiuto), dovrebbe iniziare ad espandere la scuderia di DeepL. I vantaggi:

• Si ottengono test unitari!

• Il volontario viene introdotto all'importante natura dei test unitari!

• Se il volontario è lento o si blocca, non interferisce con lo sviluppo della linea principale

Poi, come per altre risposte, si può chiedere l'elemosina per un maggior allenamento, dato che si è perso un po’ di tempo nel programma.

Essendo un volontario, non credo che sia necessario “licenziarli”, in quanto una formulazione del genere sarebbe alquanto scortese. Dire invece che il lavoro di volontariato per il quale avete bisogno di loro è finito per ora potrebbe essere più appropriato. Inoltre, assicuratevi di ringraziarli gentilmente per il lavoro che hanno già svolto, commentate il suo successo e la loro crescita personale, ma non date loro nuovi compiti.

Questo funziona soprattutto per i volontari, perché non sono mai stati tecnicamente impiegati, ma solo per dare una mano dove ce n'era bisogno e se potete esprimerlo in modo da dimostrare che sono riusciti a svolgere il loro compito, allora non ricevere più compiti dovrebbe essere accolto con sentimenti positivi piuttosto che negativi.

Grazie mille {nome}, {X} parte del progetto è in piedi e funziona bene! Avete fatto tutto ciò di cui avevo bisogno, ma se vi va bene potrei chiedervi di lavorare ancora un po’ in futuro?

Chiedere se va bene per qualcosa che a loro piace è molto utile, perché mantiene il ponte metaforico di cui avete parlato, li mette d'accordo con voi, fornisce loro le opzioni che scelgono per realizzare il vostro obiettivo di fermare il loro lavoro sul progetto in corso ed è educato.

Purtroppo questo non funzionerà in tutti i casi e non conosco i dettagli del vostro progetto/quello che gli è stato assegnato. Se dovete scegliere tra essere un po’ più schietti o mentire, essere schietti sarebbe probabilmente d'aiuto a lungo termine (questo non vuol dire che dovete concentrarvi sul male!).

Ci avete aiutato e migliorato molto, ma penso che sarebbe meglio se {altri} e io portassi a termine i compiti rimanenti.

e

Se in futuro arriverà qualcosa di più adatto alle vostre capacità, sarò sicuro di mandarvelo.

Potrebbe essere più appropriato in alcuni casi.

La mia lettura di questa situazione è… diciamo un po’ cinica. Là fuori, c'è costantemente il consiglio per i nuovi sviluppatori di ottenere i loro nomi sulle richieste di pull come un modo per migliorare il loro credito GitHub per i potenziali datori di lavoro. Guardando là fuori su altri siti, c'è un costante consiglio per i nuovi sviluppatori di aderire ad un progetto open source come un modo per acquisire esperienza. Questa esperienza viene a scapito del tempo speso per il tutoraggio degli sviluppatori più anziani su questi progetti.

Mentre sì, gli sviluppatori junior stanno rinunciando al loro tempo libero - non lo vedo come tale. Si tratta di un junior dev che riceve un tutoraggio gratuito e riprende a costruire a spese di un progetto di volontariato gestito da voi. (Secondo me) il costo del mentoring su un progetto di volontariato raramente vale il tempo a meno che la persona non sia impegnata nel progetto e abbia un interesse genuino in esso al di là del credito GitHub.

Ci sono due percorsi da considerare.

Mentor the junior dev. Continuerai ad accompagnare ogni impegno e ad assicurarti che il materiale presentato sia all'altezza dei tuoi standard per il progetto. Il vostro ruolo principale è quello di mentore per assicurarvi che sia il vostro progetto che i giovani sviluppatori si impegnino nel progetto siano quelli che vi aspettate.

Non fate da mentore ai giovani sviluppatori. Il vostro tempo di volontariato per lavorare al vostro progetto ha lo stesso valore, se non di più, del suo tempo. È probabile che molti chiudano il negozio in preparazione per dire “è fatta” e passare a un altro progetto. Spesso questi sono compiti noiosi e noiosi, ma devono comunque essere fatti. Cose come:

• documentazione - fai leggere ad un'altra persona tutto il testo scritto e assicurati che abbia la corretta ortografia, punteggiatura, grammatica, formattazione e così via.
• pulizia dello stile - prendi il tuo linter preferito ed esegui il codice secondo lo stile che vuoi. Registra tutti gli elementi di pulizia dello stile come problema per ogni file da pulire.
• test di scrittura - lavora per migliorare la copertura del codice. Ci sono sempre dei test da scrivere.

Realizza e ricorda che se c'è un compito che ti richiederà 4 ore per farlo da solo, o 3 ore del tuo tempo e 8 ore di quello dello junior dev, non c'è molto senso di business / tempo nell'avere lo junior dev che lo fa, a meno che tu non stia tenendo conto del valore di avere lo junior dev che guadagna esperienza.

Guarda in che cosa ogni persona (tu e lo junior dev) sta uscendo dall'accordo. Siete entrambi volontari. Se non c'è qualcosa da fare per un volontario, va bene.

Dite loro la verità, ma attenetevi ai fatti.

Siate diretti e onesti e esponete i fatti come li avete presentati qui:

• Con il senno di poi, vedete che l'aiuto di cui hanno bisogno richiede molto tempo. Ha iniziato a ostacolare la vostra capacità di lavorare sul progetto.
• State liquidando il progetto. Vi state avvicinando a un punto in cui non lavorerete più al progetto. Fategliene conoscere le ragioni. (Ad esempio,
• Ringraziateli per tutti gli sforzi che hanno profuso in questo progetto e dite loro che sperate che l'esperienza sia stata utile per sviluppare le loro capacità.

• Eventualmente offrite loro di aiutarli a trovare un altro progetto in cui possano continuare a fare il lavoro di sviluppo, magari uno in più in linea con il loro attuale livello di competenza.

• Siate consapevoli che potrebbero rispondere chiedendo se possono continuare a lavorare senza una supervisione così stretta. Se è fattibile, potreste prendere in considerazione l'idea di adottare intenzionalmente un approccio più distaccato e poi semplicemente rivedere il loro lavoro quando è fatto (ad esempio, come richiesta di pull). Sta a voi decidere se è fattibile. Se riuscite a trovare un piccolo cambiamento da implementare, potreste considerare questo. Se lo provate e non va bene, potete mostrare loro cosa c'è di sbagliato nel loro lavoro, e potreste aver bisogno di tornare a questa discussione sul fatto di non avere tempo e sul fatto che il progetto si sta concludendo.

Cose non da dire:

• Li stai licenziando.
• Non ti piace più il progetto a causa loro.
• Sono incompetenti o qualsiasi altra cosa sulla loro capacità innata.

A volte, è meglio non dire tutto quello che pensi e senti. Non perché sei disonesto, ma perché sai che i tuoi sentimenti e i tuoi pensieri non sono completamente oggettivi. I nostri giudizi sono a volte offuscati dai nostri desideri insoddisfatti, quindi a volte teniamo la bocca chiusa su pensieri e sentimenti che sappiamo non essere veramente validi.

Sì, c'è un rischio intrinseco che si possano ferire i loro sentimenti. Ogni approccio comporta dei rischi. Non fare nulla rischia di diventare frustrato e di liberarsene in modo non costruttivo, e mentire o falsificare la verità rischia di far scoprire all'altra persona ciò che è realmente accaduto. Essere onesti ha la virtù di fidarsi dell'altra persona per valutare la situazione in prima persona e venire a vedere le cose come le vedete voi. La persona può vedere che non sei ingiusto e che stai cercando di affrontare la situazione in modo obiettivo. Se non capisce il tuo punto di vista, va bene parlarne con loro e spiegarglielo; questo non è possibile se non sei diretto.

Se senti che l'altra persona inizia a dubitare che la tua amicizia continuerà, metti in chiaro che vuoi continuare. Come farlo va al di là di questa domanda, perché dipende da come l'altra persona risponde.