¿Cómo lidiar con un desarrollador 0.1X en su equipo? Alguien en mi equipo de desarrollo trabaja muy muy lentamente. Hizo el trabajo de medio día en cuatro días. Cual es tu consejo

He sido el desarrollador 0.1x, y a veces todavía lo soy, así que intentaré responder eso, generalmente es falta de motivación o disciplina. Si el tipo careciera de las habilidades tecnológicas pero tuviera motivación, habría leído fácilmente y hubiera seguido molestando tu día a día.

Pero como estás aquí haciendo esta pregunta, supongo que no. Como líder de equipo, su trabajo no es obligar a las personas a presentar su trabajo, sino ayudarlas a tener éxito: hable con ellas, conozca su posición y sus motivos. Su falta de motivación puede venir con un choque de valores / estructura de la empresa o simplemente no le gusta su equipo / producto por alguna razón. Sea lo que sea, sacarlo a la luz resuelve la mitad del problema. En caso de que ofrezca incentivos, explique las alternativas (es decir, amenazas) o acuerde el período en el que se sentará con él y explique en detalle qué / por qué / dónde para que el chico pueda ponerse al día: usted decidirá con esta nueva información.

(Él puede tener algunos problemas de RL realmente serios. Esto también puede explicar la situación, pero es una posibilidad rara, entonces su código sufriría solo en cantidad, no en calidad, como usted implica).

Las revisiones de código ayudan: con ellas le enseñará cómo realmente espera que se haga el trabajo.

Para la variante con la falta de disciplina: las reuniones de scrum diarias pueden ser molestas pero ayudan con una cosa (desde el punto de vista del desarrollador): sabes que mañana tendrías que informar, por lo que al menos tratarás de hacer algo. Si espera 4 días para recibir un comentario, ha esperado 4 veces más de lo que es bueno para un proyecto. Los ciclos de retroalimentación más cortos solucionan el gran problema y enseñan disciplina y competencia al mismo tiempo.

Si el chico carece de habilidad técnica y junior, todo es normal. Si carece de él y es senior (ha estado allí): su departamento de recursos humanos necesita capacitación y su desarrollador actualmente está sobrecargado con toneladas de términos / tecnologías que conoce de memoria pero que no, y está un poco perdido en este momento y está cuestionando su decisión de venir a trabajar aquí.

Sea lo que sea, sin más información, estás en el frío disparando a las sombras. Hable con el chico, obtenga su versión de la historia y decida cuál es el mejor curso de acción. No hay una elección correcta, solo hay una elección junto con suficiente información.

EDITAR: esta regla ayuda: “Si está atrapado con algo pequeño durante más de 15 minutos sin ningún progreso, se pone de pie y se lo dice / ve a alguien”. Nadie es más inteligente que todos nosotros y reinventar la rueda / hacer todo “Scherlock” en algo que el autor puede explicar en pocas palabras, generalmente es inútil y desperdicia tiempo.

He estado en esta posición varias veces, con resultados diferentes cada vez. Todos somos diferentes, así que en este momento quizás no tenga forma de saber si su desarrollador 0.1 madurará alguna vez.

Mi mejor consejo sería mantener una buena comunicación con su propio supervisor inmediato sobre la situación y ofrecerle ayuda. Solicite un par de horas por día para dedicar a la mentoría de la persona. Descubrirá bastante rápido si la persona tiene la claridad mental o no para progresar. Por lo general, las personas caen en uno de los tres cubos:

1. Persona que no sabe codificar pero está aprendiendo rápidamente
2. Persona que nunca aprenderá o aprenderá con el tiempo dado, pero odia cada momento.
3. Persona que aprenderá pero necesita mucha atención / cuidado.

La primera persona es fácil de detectar y en poco tiempo será un miembro productivo de su equipo (incluso si al principio tiene que darle a esa persona piezas más pequeñas para masticar). La dificultad radica en distinguir entre 2 y 3, y no hay forma de averiguarlo sin invertir mucho tiempo para resolverlo. Además de enseñarle a esta persona el tema necesario para el trabajo, debe realizar pruebas y discernir para saber si se trata de un 2 o un 3, y dado un tiempo, probablemente descubrirán lo mismo por sí mismos.

De esta manera, si el desarrollador 0.1 con el que está tratando es un 2, la persona no se sorprenderá si es despedido (e incluso podría irse solo al descubrir su propio disgusto / ineptitud). Y si él es un 3, usted será la razón por la que tuvo éxito. Habrás ganado el respeto duradero de él y de tu supervisor.

Al final del día tienes tres opciones:

1. Ayúdelos a desarrollarse en su rol actual.
2. Cambiar su papel
3. Déjalos ir

Cuál de esos tres debe hacer se reduce a detalles. Comencemos con el último. Es probable que se necesiten decenas de miles de dólares en costos directos y de oportunidad para reemplazar a un miembro del equipo. Parte de este costo puede ser fijo si tiene reclutadores dedicados, pero aún hay tiempo para entrevistar, tiempo para ponerlos al día y el costo de oportunidad de estar en el personal mientras tanto, lo que puede requerir contratistas u otros costos. Por lo tanto, no es una decisión probable, pero le da algo contra lo que pesar.

El primero, en el vacío, es probablemente el mejor . Ayudar a alguien a desarrollarse probablemente generará lealtad tanto de ellos como del resto del equipo. Todos luchan con algo y demostrar que el equipo y la organización invierten en su personal es enorme. Pero eso requerirá tiempo y costo también. Su tiempo para aprender y el tiempo de cualquiera en el equipo para entrenar o el costo de capacitarlos externamente. Otra cosa a reconocer es que algunas personas no podrán cumplir con las expectativas. Esa es una decisión judicial que tendrá que hacer.

El tercero es posiblemente el más difícil. Se basa en que el miembro del personal sea alguien que desea mantener en la organización, así como en tener un rol en el que puedan hacer la transición. Podría presentarse como un cambio permanente o temporal, su situación típica del plan de mejora depende de si juzga que son capaces de alcanzar el nivel de sus expectativas. Lo que lo hace difícil es que es probable que sea una degradación y eso es difícil de tragar. Puede haber consideraciones salariales y, a menos que lo maneje bien, hay muchas posibilidades de que comience a buscar seriamente a otra persona. Si dejas ir a alguien, puedes controlar el tiempo, si se va, podría ser en un mal momento.

Sin embargo, si decides manejarlo, primero debes considerar algunas cosas. El más grande es sobre las expectativas. Usted menciona que el código de la persona era de mala calidad. Una cosa que he notado es que es muy fácil tratar el trabajo de otros que no se hicieron de la manera en que lo hubieras hecho como incorrecto. Haga un esfuerzo por examinar su trabajo a la luz de lo que se les dio. Asegúrese de que no fallaron porque no le leyeron la mente.

También debe considerar su papel y sus expectativas para el mismo. Por ejemplo, si está buscando trabajo de un desarrollador junior y no tenían a nadie trabajando con ellos para obtener una especificación, entonces el problema no está en ellos. Si configuras a alguien para que falle, no deberías enojarte con ellos cuando lo hacen. Otra cosa a considerar es contra quién compara su trabajo. En todos los niveles hay personas que simplemente son mejores. En la mayoría de los casos, hay espacio para diferentes niveles si la habilidad en una organización. Decir “si no es tan bueno como nuestra mejor persona, es una mierda” hace que sea muy difícil contratar y retener personas.

Pero otra cosa importante es que si determina que hay un problema de rendimiento, no lo cubra con azúcar. Abórdelo de inmediato con la persona. Si no cree que vaya a mejorar, entonces debe pasar a la terminación. Es fácil para las personas racionalizar mantener a alguien porque no quieren ser el malo o porque hay preguntas inevitables sobre por qué fueron contratados en primer lugar. No se quede atrapado en costos hundidos e intente no tomarlo personalmente. Si tiene que despedir a alguien, no lo convierte, o usted, en una mala persona; Solo un mal ajuste. No les quites la oportunidad de encontrar una mejor. Al mismo tiempo, no intentes suavizar el golpe. No seas un bastardo al respecto, pero no los estás ayudando al no ser honesto: toma la decisión y los motivos, explícalos para que puedan ser conscientes de sus debilidades en el futuro.

Idealmente, han estado recibiendo suficientes comentarios de que la terminación no es una sorpresa. La gente de Recursos Humanos a menudo habla de cómo no debería ser una sorpresa para nadie. En realidad, ese casi nunca es el caso. Las personas con problemas de rendimiento son a menudo las más propensas a mirar el lado positivo si las cosas, encuentran cosas específicas en cualquier situación particular que hace que sea una cosa única y no un problema pernicioso. En este sentido, a menudo están habilitados por la administración que están demasiado ocupados para abordarlo adecuadamente, no están capacitados o respaldados adecuadamente para hacerlo o quieren ser amables.

El mejor consejo que puedo darte es tener expectativas; expectativas razonables y claramente definidas. Asegúrese de que todo el personal sepa lo que son. Aplicarlos de manera justa. Comunique el fracaso, y los elogios, de manera oportuna y consistente. Si no tiene eso, el problema comienza con el equipo y la organización.

Mi consejo sería buscar la causa raíz del problema. Algunas cosas que puedo pensar:

1. Problema de comunicación: el desarrollador no comprende lo que se espera con precisión y tiene que averiguar qué debe hacer el programa.
2. Complejidad : si combina muchos marcos en una aplicación, puede ser difícil para un programador “manejarlos” a todos. Lleva tiempo entender un marco y usarlo correctamente.
3. Falta de capacidad mental : se requiere una cierta cantidad de “perspicacia” y abstracción para poder programar de manera eficiente.
4. … y muchos otros

Mi segundo consejo sería abierto e intentar encontrar una solución con el desarrollador . Si él o ella confirma el mismo problema, el camino para encontrar una solución es mucho más fácil, incluso si eso significa dejar que el desarrollador. ir.

¡Buena suerte!

Vería muchas cosas antes de concluir que el desarrollador es incompetente. Si bien esto puede parecer contradictorio, ¿ha considerado darle al desarrollador tareas significativamente más difíciles o tareas que requieren un pensamiento mucho más profundo?

Si el desarrollador escribe entre 0 y 1 líneas de código al día, podría ser lo que usted llamó un desarrollador 0.1X. Sin embargo, si está escribiendo 8 líneas de código completamente depurado al día, mientras que los otros desarrolladores producen 80 líneas de código malo, prefiero tener el 0.1Xer.

Porque, amigo mío, el costo de los errores es alto.

Digamos que el costo de corregir errores en la fase de requisitos es de $ 1 / error; en la fase de diseño cuesta $ 10 / error; en la fase de desarrollo es de $ 100 / error; y en la fase de producción es de al menos $ 1000 / error, con su lentitud debido a la captura de todos sus errores en las fases de requisitos / diseño.

Mientras que el resto del equipo no logra atrapar todos sus errores hasta la fase de desarrollo. Su velocidad de 0.1X me salvó, al menos, 10 veces el costo para un desarrollador más rápido para detectar el mismo error. Adivina quién gana esa carrera; No son tus demonios de la velocidad. Es señor tortuga … Sr. 0.1X.

Por otro lado, si lo anterior no es cierto, entonces es posible que desee hablar con él, analizando si una asignación sin codificación tiene más sentido en su caso, como ser el libario de código, hacer pruebas u otra cosa.