Dizer educadamente a um voluntário incompetente do projecto de software é demasiado inexperiente

Pode ficar completamente do lado dessa questão.

Nem precisa de ser enganador acerca disso.

Basta dizer-lhes que a parte do projecto em que podem realisticamente ajudar está concluída agora (uma vez que é, isso é inteiramente verdade) e que os contactará novamente se surgir algo mais em que eles possam ajudar. Isto tem vantagens chave:

• Não está a queimar nenhuma ponte.
• Pode levar o desenvolvedor júnior a aprender mais num esforço para adquirir competências mais relevantes para o projecto.
• Não os está a despedir ou a insinuar que são incompetentes de todo.

• Isto é normal para projectos colaborativos de tempo livre. A certa altura as coisas que alguém sem certas competências pode fazer acabam.

• Usando esta estratégia, está a evitar completamente o problema de ter de as “despedir”.

• Em alternativa, pode reafectá-las a tarefas que precisam de ser feitas, mas não precisa de um programador para as fazer, ou tarefas que são secundárias (é bom ter). Normalmente, isto inclui:

• Documentos de escrita

• Revisão de código

• Testes exaustivos de Q/A

Esteja atento a tarefas que não lhe custam nada se forem mal feitas mas que ajudam muito quando as completam entusiasticamente.

Não tenho a certeza se tem de os despedir totalmente do projecto, pode também deslocá-los para uma posição em que não bloqueiem outras pessoas (incluindo você).

Primeiro, parece que o principal problema para si é o coaching - por isso reduza o coaching. Podias dizer algo como:

Hey Bob, actualmente há muita coisa a acontecer na minha vida e eu simplesmente já não consigo encontrar tempo para as nossas sessões de treino [ou como quer que lhes chames], desculpa lá isso.

Depois, move-os “para fora do caminho” atribuindo-lhes uma ou duas tarefas simples com prioridade não urgente. Se eles conseguirem aprender e completar a tarefa por si próprios: óptimo, dê-lhes algo mais desafiante e repita até encontrar o seu nível de competência. Se não, volte para eles quando a tarefa tiver subido de prioridade (quando for necessário em breve). Se você quiser ser diplomático sobre isso, você poderia então dizer:

Hey Bob, precisamos da documentação / traduções / testes executados / foobar em breve. Pode tratar disso e eu assumo entretanto o defrobulador?

Ajuda muito se conseguir convencer-se que a documentação e os testes são tarefas importantes - porque eles são. Muitos devs não querem escrever documentação e isso sela o destino de muitos pequenos projectos de software de código aberto: o seu software resolve algum problema mas a maioria das pessoas não consegue perceber como usá-lo, por isso ninguém o usa.

Finalmente: menciona “Nunca trabalhei com outros programadores antes” e não está muito claro para mim como organiza o trabalho no seu projecto. Organizar o desenvolvimento de software é um conjunto de competências muito valioso, por isso pode querer usar esta oportunidade para aprender e crescer por si próprio. Aprenda a dividir o trabalho em tarefas e subtarefas, a calcular dependências, a estimar o tempo necessário, a dar prioridade ao que é importante e ao que pode esperar, a avaliar quem pode fazer o quê. Aprenda como melhor comunicar com os seus colegas e como replanear quando as coisas não correm como você esperava. Use as ferramentas de colaboração (issue tracker, versioning system, etc.).

Talvez as metodologias em voga no mundo empresarial neste momento (Scrum, Kanban, etc.) lhe dêem algumas orientações úteis.

Em primeiro lugar, concordo com a parte de agradecer aos voluntários pelo seu tempo/forço até à data, e dizer que a parte do desenvolvimento primário em que precisavam dele está concluída.

Permitam-me que recomende, para vosso bem, que invistam em mais uma sessão de tutoria. O tema: Mostrar o seu mau eu como escrever testes unitários*. Depois diga-lhe que se ele quiser fazer mais ajuda tecnológica (ao contrário de outros tipos), deve começar a expandir o estábulo de DeepL. As vantagens:

• Recebe testes unitários!

• O voluntário é apresentado à natureza importante dos testes unitários!

• Se o voluntário for lento ou ficar preso, não interfere com o desenvolvimento da linha principal

Então, como em outras respostas, pode implorar mais treino, uma vez que perdeu qualquer folga na sua agenda.

Como eles são voluntários, não creio que seja necessário “despedi-los”, uma vez que uma formulação como essa seria tão grosseira. Em vez disso, dizer que o trabalho voluntário para o qual se precisa deles está terminado por agora talvez seja mais apropriado. Além disso, não deixe de lhes agradecer gentilmente pelo trabalho que já fizeram, comentar o seu sucesso e o seu crescimento pessoal, simplesmente não lhes dê novas tarefas.

Isto funciona especialmente para os voluntários, uma vez que eles nunca foram empregados tecnicamente, apenas ajudando onde eram necessários e se você pode dizer de uma forma que mostre que eles conseguiram fazer a sua tarefa, então não receber mais tarefas deve ser recebido com sentimentos positivos em vez de negativos.

Muito obrigado {nome}, {X} parte do projecto está a funcionar bem! Fizeram tudo o que eu precisava, mas se estiver tudo bem convosco, posso pedir-vos que façam mais algum trabalho no futuro?

Perguntar se está tudo bem para algo que gostariam*** é bastante útil, pois mantém a ponte metafórica que mencionaram, faz com que concordem convosco, proporciona-lhes opções que sempre que vos escolhem cumprem o vosso objectivo de os impedir de trabalhar no projecto actual e é educado.

Infelizmente isto não vai funcionar em todos os casos e eu não conheço os detalhes do seu projecto/o que lhe foi atribuído. Se tiver de escolher entre ser um pouco mais brusco ou mentiroso, ser brusco provavelmente ajudará a longo prazo (isto é, não dizer que se deve concentrar no mau!).

Você ajudou-nos e melhorou muito, mas penso que seria melhor se {outros} e eu completasse as restantes tarefas.

e

Se algo mais adequado às suas capacidades aparecer no futuro, terei a certeza de o enviar à sua maneira.

Talvez seja mais apropriado em alguns casos.

A minha leitura desta situação é… digamos um pouco cínica. Lá fora, há constantemente o conselho para que os novos criadores obtenham os seus nomes em pedidos de extracção, como forma de melhorar a sua credibilidade no GitHub para os potenciais empregadores. Olhando lá fora para outros sites, há conselhos constantes para os novos desenvolvimentos aderirem a um projecto de código aberto como uma forma de ganhar experiência. Essa experiência vem à custa do tempo gasto como mentor dos devs mais experientes nesses projectos.

Embora sim, os devs mais novos estão a desistir do seu tempo livre - eu não vejo isso como tal. Este é um jovem que está a receber tutoria gratuita e a retomar a construção à custa de um projecto de voluntariado gerido por si. (Na minha opinião) o custo do mentoring num projecto voluntário raramente vale o tempo, a menos que a pessoa esteja comprometida com o projecto e tenha um interesse genuíno no mesmo para além do crédito do GitHub.

Há dois caminhos a considerar.

Mentor o dev. júnior Você vai continuar a pastorear cada compromisso e certificar-se de que o material apresentado está à altura dos seus padrões para o projecto. O seu papel principal é o de um mentor para assegurar que tanto o seu projecto como os compromissos do jovem dev. O seu tempo no voluntariado para trabalhar no seu projecto é tão valioso, se não mais valioso, como o seu tempo. É provável que haja muitos a fechar a loja em preparação para dizer “está feito” e passar para outro projecto. Muitas vezes estas tarefas são enfadonhas e aborrecidas, mas ainda precisam de ser feitas. Coisas como:

• documentação - faça outra pessoa ler todo o texto escrito e certifique-se de que tem a ortografia correcta, pontuação, gramática, formatação, etc.
• limpeza de estilo - pegue no seu linter favorito e passe o código através dele de acordo com o estilo que deseja. Registre todos os itens de limpeza de estilo como edição por arquivo a ser limpo.
• teste de escrita - trabalhe para melhorar a cobertura do código. Há sempre testes para serem escritos.

Perceba e lembre-se que se há uma tarefa que o vai levar 4h para fazer você mesmo, ou 3h do seu tempo e 8h do tempo do dev júnior, não há muito sentido de negócio / tempo em ter o dev júnior a fazê-lo a menos que esteja a ter em conta o valor de ter o dev júnior a ganhar experiência.

Olhe para o que cada pessoa (você e o dev júnior) está a sair do acordo. Ambos são voluntários. Se não há nada que um voluntário possa fazer - não faz mal.

Diga-lhes a verdade, mas mantenha-se fiel aos factos.

Seja directo e honesto e exponha os factos tal como os apresentou aqui:

• Com o benefício de uma visão a posteriori, vê que a quantidade de ajuda de que eles necessitam é muito demorada. Começou a dificultar a sua própria capacidade de trabalhar no projecto.
• Está a dar cabo do projecto. Está a aproximar-se de um ponto em que já não vai trabalhar no projecto. Diga-lhes as razões para isso. (Por exemplo, talvez esteja a ser substituído por um novo projecto com melhor apoio/financiamento ou simplesmente já não há muito trabalho a fazer)
• Agradeça-lhes todo o esforço que investiram neste projecto, e diga-lhes que espera que a experiência tenha sido útil para desenvolver as suas capacidades.

• Possivelmente ofereça-se para os ajudar a encontrar outro projecto onde possam continuar a fazer trabalho de desenvolvimento, talvez mais um de acordo com o seu actual nível de capacidades.

• Esteja ciente de que eles podem responder perguntando se podem continuar a trabalhar sem uma supervisão tão apertada. Se for viável, pode considerar a possibilidade de tomar intencionalmente uma abordagem mais descontraída e depois apenas rever o seu trabalho quando este estiver done (por exemplo, como um pedido de puxar). Cabe a si decidir se isto é viável. Se conseguir encontrar uma pequena mudança para eles implementarem, pode considerar isto. Se tentar e não correr bem, pode mostrar-lhes especificamente o que está errado com o seu trabalho, e pode precisar de voltar a esta discussão sobre não ter tempo e o projecto acabar.

Coisas não* para dizer:

• Está a demiti-los.
• Já não gosta do projecto por causa deles.
• São incompetentes ou qualquer outra coisa sobre a sua capacidade inata.

Por vezes, é melhor não dizer tudo o que pensa e sente. Não porque seja desonesto, mas porque sabe que os seus sentimentos e pensamentos não são completamente objectivos. Os nossos julgamentos são por vezes toldados pelos nossos desejos não realizados, por isso por vezes mantemos a boca fechada sobre pensamentos e sentimentos que sabemos que não são realmente válidos.

Sim, há algum risco inerente de você poder ferir os seus sentimentos. A abordagemny_ aqui acarreta riscos. Não fazer nada arrisca-se a ficar frustrado e a libertá-lo de uma forma não construtiva, e mentir ou enganar a verdade arrisca-se a que a outra pessoa descubra o que realmente aconteceu. Ser honesto tem a virtude de confiar na outra pessoa para avaliar a situação em si e vir a ver as coisas como você vê. A pessoa pode ver que não está a ser injusta e que está a tentar abordar a situação de forma objectiva. Se não compreender o teu ponto de vista, não faz mal falar com eles e explicar; isso não é realmente possível se não fores directo.

Se sentires que a outra pessoa começa a duvidar que a tua amizade vai continuar, deixa claro que queres continuar. Como fazê-lo está para além do âmbito desta pergunta, pois depende da forma específica como a outra pessoa responde.