Diciéndole educadamente a un incompetente voluntario de un proyecto de software que es demasiado inexperto

Simplemente diles que la parte del proyecto en la que pueden ayudar de forma realista ya está terminada (ya que lo está, esa es toda la verdad) y que te pondrás en contacto con ellos de nuevo si surge algo más en lo que puedan ayudar. Esto tiene ventajas clave:

• No estás quemando ningún puente.
• Puede incitar al desarrollador junior a aprender más en un esfuerzo por obtener habilidades más relevantes para el proyecto.
• No los estás despidiendo ni insinuando que son incompetentes en absoluto.
• Esto es normal para los proyectos de colaboración de tiempo libre. En algún momento las cosas que alguien sin ciertas habilidades puede hacer terminan.

Usando esta estrategia, estás evitando completamente el problema de tener que “despedirlos” en absoluto.

Alternativamente, puedes reasignarlos a tareas que necesitan ser hechas pero que no necesitan un desarrollador para hacerlas, o tareas que son secundarias (agradable de tener). Normalmente, esto incluye:

• Redacción de documentos
• Revisión de código
• Pruebas exhaustivas de calidad

Esté atento a las tareas que no le cuestan nada si se hacen mal pero que ayudan mucho cuando las completan con entusiasmo.

No estoy seguro de que tengas que despedirlos completamente del proyecto, también podrías moverlos a una posición donde no bloqueen a otras personas (incluyéndote a ti).

En primer lugar, parece que el principal problema para ti es el entrenamiento - así que reduce el entrenamiento. Podrías decir algo como:

Oye Bob, actualmente están pasando muchas cosas en mi vida y simplemente no puedo encontrar tiempo para nuestras sesiones de entrenamiento [o como sea que las llames] por más tiempo, lo siento.

Luego, muévelos “fuera del camino” asignándoles una o dos tareas simples con prioridad no urgente. Si pueden aprender y completar la tarea por sí mismos: genial, dales algo más desafiante y repite hasta que encuentres su nivel de competencia. Si no, vuelva a ellos cuando la tarea haya subido de prioridad (cuando se necesite pronto). Si quieres ser diplomático al respecto, podrías decir:

Hey Bob, necesitamos la documentación / traducciones / pruebas ejecutadas / foobar pronto. ¿Podrías encargarte de eso y yo me encargaré del defrobulador mientras tanto?

Realmente ayuda si puedes convencerte de que la documentación y las pruebas son tareas importantes - porque son serán. Muchos desarrolladores no quieren escribir documentación y eso sella el destino de muchos pequeños proyectos de software de código abierto: su software resuelve algún problema pero la mayoría de la gente no puede averiguar cómo usarlo, así que nadie lo usa.

Por último: mencionas “Nunca he trabajado con otros desarrolladores antes” y no me queda muy claro cómo organizas el trabajo en tu proyecto. Organizar el desarrollo de software es una habilidad muy valiosa, así que quizás quieras usar esta oportunidad para aprender y crecer por ti mismo. Aprende a desglosar el trabajo en tareas y subtareas, a averiguar las dependencias, a estimar el tiempo necesario, a priorizar lo que es importante y lo que puede esperar, a calibrar quién puede hacer qué. Aprende a comunicarte mejor con tus compañeros de desarrollo y a replantearte cuando las cosas no salen como esperabas. Utilice las herramientas de colaboración (issue tracker, sistema de versiones, etc.).

Tal vez las metodologías en boga en el mundo de los negocios en este momento (Scrum, Kanban, etc.) le den algunas pautas útiles.

Primero, estoy de acuerdo con la parte de agradecer al voluntario su tiempo/esfuerzo hasta la fecha, y decir que la parte del desarrollo primario en la que le necesitabas ha terminado.

Puedo recomendar, por el bien de ambos, que inviertan en una sesión de tutoría más. El tema: muestra a su yo malo cómo escribir las pruebas de la unidad. Entonces dígale que si quiere hacer más ayuda tecnológica (a diferencia de otros tipos), debería empezar a expandir el establo de DeepL. Las ventajas:

• ¡Recibe pruebas de unidad!

• ¡El voluntario se introduce en la importante naturaleza de las pruebas de unidad!

• Si el voluntario es lento o se atasca, no interfiere con el desarrollo de la línea principal

Entonces, como en otras respuestas, puede comenzar más entrenamiento, ya que ha perdido cualquier holgura en su horario.

Como son voluntarios, no creo que sea necesario “despedirlos” en absoluto, ya que redactarlo así sería bastante grosero. En cambio, decir que el trabajo voluntario para el que los necesitas ha terminado por ahora podría ser más apropiado. Además, asegúrese de agradecerles amablemente el trabajo que ya han hecho, comente su éxito y su crecimiento personal, pero no les dé nuevas tareas.

Esto funciona especialmente para los voluntarios, ya que nunca fueron empleados técnicamente, sólo ayudaban donde se les necesitaba y si puede expresarlo de una manera que demuestre que tuvieron éxito en su tarea, entonces el hecho de no recibir más tareas debería ser recibido con sentimientos positivos en lugar de negativos.

¡Muchas gracias {nombre}, {X} parte del proyecto está en marcha y funcionando bien! Has hecho todo lo que necesitaba pero si te parece bien, podría pedirte que hicieras más trabajos en el futuro.

Preguntar si está bien para algo que les gustaría es bastante útil ya que mantiene el puente metafórico que mencionaste, les hace estar de acuerdo contigo, les proporciona opciones para que, sea cual sea lo que elijan, consigas tu objetivo de hacer que dejen de trabajar en el proyecto actual y es educado.

Desafortunadamente esto no funcionará en todos los casos y no conozco los detalles de tu proyecto/lo que le asignaron. Si tienes que elegir entre ser un poco más directo o mentir, ser directo probablemente ayudaría a largo plazo (¡eso no quiere decir que debas centrarte en lo malo!).

Nos has ayudado y mejorado mucho, pero creo que sería mejor si {otros} y yo completáramos las tareas restantes.

y

Si algo más adecuado para tus habilidades aparece en el futuro me aseguraré de enviártelo.

Podría ser más adecuado en algunos casos.

Mi lectura de esta situación es… digamos que un poco cínica. Ahí fuera, hay constantemente consejos para que los nuevos desarrolladores consigan sus nombres en las solicitudes de extracción como una forma de mejorar su credibilidad en GitHub para los posibles empleadores. Mirando otros sitios, hay consejos constantes para que los nuevos desarrolladores se unan a un proyecto de código abierto como una forma de ganar experiencia. Esa experiencia viene a costa del tiempo que pasan los devs más veteranos en esos proyectos.

Aunque sí, los devs más jóvenes están renunciando a su tiempo libre - no lo veo así. Este es un dev devoto junior que está recibiendo tutoría gratuita y reanuda la construcción a expensas de un proyecto de voluntariado dirigido por usted. (En mi opinión) el costo de la tutoría en un proyecto voluntario rara vez vale la pena a menos que la persona esté comprometida con el proyecto y tenga un interés genuino en él más allá de la credibilidad de GitHub.

Hay dos caminos a considerar.

Mentor el dev. junior. Seguirá guiando cada compromiso y asegurándose de que el material presentado está a la altura de sus estándares para el proyecto. Su papel principal en esto es el de mentor para asegurar que tanto su proyecto como el de los devas juveniles se comprometan con el proyecto es lo que usted espera.

No sea mentor del devas juvenil. Su tiempo como voluntario para trabajar en su proyecto es tan valioso, si no más, que su tiempo. Es probable que haya muchos que cierren en preparación para decir “está hecho” y pasar a otro proyecto. A menudo estas son tareas tediosas y aburridas, pero todavía tienen que hacerse. Cosas como:

• documentación - hacer que otra persona lea todo el texto escrito y se asegure de que tiene la ortografía, puntuación, gramática, formato correcto, etc.
• limpieza de estilo - tomar su linterna favorita y ejecutar el código a través de ella de acuerdo con el estilo que desee. Registra todos los elementos de la limpieza de estilo como tema por archivo a limpiar.
• escritura de prueba - trabaja para mejorar la cobertura del código. Siempre hay que escribir pruebas.

Date cuenta y recuerda que si hay una tarea que te llevará 4h para hacerla tú mismo, o 3h de tu tiempo y 8h del tiempo del desarrollador junior, no tiene mucho sentido comercial/tiempo hacer que el desarrollador junior la haga a menos que estés teniendo en cuenta el valor de que el desarrollador junior gane experiencia.

Mira lo que cada persona (tú y el desarrollador junior) está consiguiendo del acuerdo. Ambos son voluntarios. Si no hay algo que un voluntario pueda hacer, está bien.

Tell them the truth, but stick to the facts.

Be straightward and honest and lay out the facts as you’ve presented them here:

• With the benefit of hindsight now, you see that the amount of help they require is very time consuming. Ha comenzado a obstaculizar su propia habilidad para hacer el trabajo en el proyecto.
• Está dando cuerda al proyecto. Te estás acercando a un punto en el que ya no trabajarás en el proyecto. Hazles saber las razones de esto. (Por ejemplo.., quizás está siendo reemplazado por un nuevo proyecto con mejor apoyo/financiación o simplemente no queda mucho trabajo por hacer.)
• Agradézcales todo el esfuerzo que han invertido en este proyecto, y dígales que espera que la experiencia haya sido útil para desarrollar sus habilidades.
• Posiblemente ofrézcase a ayudarles a encontrar otro proyecto en el que puedan continuar trabajando en el desarrollo, quizás uno más acorde con su nivel actual de habilidad.

Sea consciente de que podrían responder preguntándoles si podrían continuar trabajando sin una supervisión tan estrecha. Si es factible, podría considerar la posibilidad de adoptar intencionadamente un enfoque más alejado de las manos y luego simplemente revisar su trabajo cuando esté hecho (por ejemplo, como una solicitud de extracción). Depende de usted si esto es viable. Si puedes encontrar un pequeño cambio para que ellos lo implementen, podrías considerar esto. Si lo intentas y no sale bien, puedes mostrarles específicamente qué es lo que está mal en su trabajo, y puede que necesites volver a esta discusión sobre no tener tiempo y que el proyecto se termine.

Cosas no que decir:

• Los estás despidiendo.
• Ya no disfrutas del proyecto por su culpa.
• Son incompetentes o cualquier otra cosa sobre su habilidad innata.

A veces, es mejor no decir todo lo que piensas y sientes. No porque seas deshonesto, sino porque sabes que tus sentimientos y pensamientos no son completamente objetivos. Nuestros juicios están a veces nublados por nuestros deseos insatisfechos, así que a veces mantenemos la boca cerrada sobre pensamientos y sentimientos que sabemos que no son realmente válidos.

Sí, hay un riesgo inherente de que puedas herir sus sentimientos. Cualquier enfoque aquí conlleva riesgos. No hacer nada arriesga que te frustres y lo liberes de una manera no constructiva, y mentir o falsear la verdad arriesga que la otra persona descubra lo que realmente pasó. Ser honesto tiene la virtud de confiar en que la otra persona evalúe la situación por sí misma y llegue a ver las cosas como usted lo hace. La persona puede ver que no estás siendo injusto y que estás tratando de abordar la situación objetivamente. Si no entiende tu punto de vista, está bien hablar con ella y explicarle; eso no es realmente posible si no eres sincero.

Si sientes que la otra persona empieza a dudar de que tu amistad continúe, deja claro que quieres continuarla. Cómo hacerlo está fuera del alcance de esta pregunta, ya que depende de los detalles de cómo responda la otra persona.