¿Cómo trato con un miembro del equipo que sigue asumiendo tareas que no puede resolver?

Dudaba si debería publicar esto en los programadores, pero creo que este problema es generalmente aplicable.

Tenemos un miembro junior del equipo (alrededor de dos años en la empresa) que sigue asignándose tareas grandes y difíciles que habrían sido más adecuadas para un desarrollador senior. Dado que cualquiera puede elegir cualquier elemento del trabajo pendiente, es difícil evitarlo.

Por supuesto que es bueno que sea ambicioso, pero cuando se atasca se desespera. En lugar de dar un paso atrás y considerar por qué las cosas no funcionan, a menudo termina yendo demasiado lejos por el camino equivocado. Luego comienza a bombardear a otros desarrolladores con preguntas que a menudo no podemos responder porque no proporciona el contexto.

Dado que quiero que trabajemos en equipo de la manera más eficiente posible, he probado un par de soluciones diferentes:

  • Dile exactamente qué hacer. Me consume mucho tiempo y, al final, es posible que ni siquiera entienda su propia solución.
  • Dé pistas en lugar de respuestas específicas. A veces esto tiene éxito, pero a veces simplemente termina por el camino equivocado aún más, especialmente si no entiendo el problema por completo.
  • Programación en pareja . Estaba bastante reacio a la idea, y cuando lo intentamos no funcionó tan bien. No tomó el mando, solo esperó que yo le dijera qué escribir.
  • Inmediatamente dígale que no tome una tarea en particular . Funcionó una o dos veces, pero requirió una pequeña mentira blanca de por qué no debería tomar esa tarea. No siento que tenga la autoridad para prohibirle trabajar en algunas tareas.

Actualización: Gracias por todas las respuestas. Esperemos que sigan siendo útiles para futuros visitantes. En cuanto a mi historia...

Se lo mencioné a mi gerente (que ya había observado el comportamiento) y le sugerí que intentáramos involucrarnos antes y tratar de asegurarnos de que dividiera las tareas demasiado grandes en partes más pequeñas. Mi gerente estaba más en la línea de que debería decirle directamente que no asumiera tareas difíciles. No estoy del todo contento, pero ya veremos.

Esta es, por supuesto, la razón por la que la mayoría de las empresas no permiten que las personas elijan lo que quieren hacer. Solo funciona si todos son realmente buenos y realmente responsables. Inteh mundo real que no es cierto.
¿Eres su manager?
No, no lo soy. Tenemos el mismo título, pero he trabajado unos cinco años más en la empresa que él. Fui su mentor cuando empezó y me escucha. Casi nunca es difícil o antipático.
¿Dividir los problemas en partes más pequeñas? ¿Hacer que escriba documentos de diseño que serán examinados colectivamente? ¿Enviarlo de vuelta a la escuela (bromea)?
Dividir el problema en partes más pequeñas es realmente un muy buen consejo. A menudo, el desarrollador que elige una tarea también es responsable de dividirla en subtareas, por lo que no sería extraño que le sugiera que la subdivida aún más si se atasca. El riesgo es que terminemos con algo a medio terminar, pero esa podría ser una situación más manejable.
Entonces, para que quede claro, ¿está operando en un entorno Agile con un equipo verdaderamente autoorganizado y sin un Scrum Master designado? Y para ser claro nuevamente, ¿no hay una supervisión gerencial específica aquí? (por ejemplo, ¿nadie es el gerente directo de esta persona?) Pregunto porque he estado en esta situación y tengo una respuesta, pero quiero asegurarme de tener toda la información correcta frente a mí....
El rol de maestro de scrum se rota entre los miembros del equipo. Tenemos un gerente directo, pero aún no ha intervenido. ¡Me interesaría saber qué piensas de todos modos!
¿Cómo espera que aprenda a resolver los problemas? ¿Si no lo dejas tratar de resolver los problemas?
Sus acciones plantean la pregunta, ¿por qué sigue haciendo esto? Parece que está asumiendo desafíos con el objetivo de aumentar sus habilidades, para poder conseguir un nuevo trabajo con un título más alto. Todo su esfuerzo probablemente sea entrenamiento gratuito para su próximo movimiento.
Considere retomar la tutoría simplemente sentándose con él y discutiendo el problema en el que está trabajando.

Respuestas (7)

Los equipos autoorganizados en un entorno de desarrollo Agile (cualquier entorno, en realidad) pueden ser cosas maravillosas y producir grandes resultados tanto tangibles (producto) como intangibles (cultura, moral, etc.). Pero en la base de los equipos autoorganizados que funcionan suelen estar estos principios básicos :

  • competencia: todos saben cómo hacer las tareas
  • colaboración: todos trabajan juntos en lugar de individualmente
  • motivación: todos tienen un buen enfoque e interés en las tareas que tienen entre manos
  • confianza y respeto: todos reconocen la competencia de los demás en el equipo, a través de la colaboración y los esfuerzos de trabajo en general
  • continuidad: todos han estado juntos y han aprendido a trabajar en equipo durante algún tiempo

Por lo que describe, su equipo tiene algunos problemas con tres de estas cosas: alguien no es competente en algún aspecto del trabajo, los intentos de colaborar y resolver este problema no van bien, y debido a eso, la confianza y el respeto probablemente estén sufriendo. también.

Esto no hace que el equipo sea feliz y productivo, como bien sabes... y esto es precisamente lo que tiene el gerente del equipo (o el líder del equipo, o como llames a la persona a la que reportan oficialmente los miembros del equipo). intervenir y manejar a la persona que está teniendo dificultades con algún aspecto del proceso debido a algo que le falta. En este caso, la falta de habilidad para juzgar adecuadamente las tareas a realizar, la falta de habilidad para pedir ayuda y colaborar productivamente, etc.

Estas no son cosas que el resto del equipo debe resolver, incluso si es un equipo autoorganizado; todavía hay un gerente funcional cuyo trabajo debería ser resolver estos problemas.

Ahora, habiendo dicho todo eso, ustedes (¿todos?) deben ser elogiados por elegir un montón de cosas que son completamente razonables y que generalmente funcionan en estas situaciones . ¿Eliminar la capacidad de "elegir" por un momento y decirle a la persona directamente qué hacer? Gran idea, y también una que el gerentedebe ser responsable, no los miembros del equipo, a menos que no sea oneroso para todos ustedes (pero lo será). ¿Empujar a alguien hacia el camino correcto que no ven? Súper, esa es una forma de colaboración. ¿Pero si no llegan allí? Entonces todavía no están allí y estás en la misma posición y más atrás. ¿Programación en pareja? Brillante: funciona para mucha gente, es una excelente forma de colaboración directa, y el hecho de que dudara en hacerlo o hacerlo bien muestra que hay un problema de personas que debe resolver alguien que no sea usted (por ejemplo, el gerente ).

El líder del equipo que me reporta tuvo exactamente esta situación recientemente, y juntos trabajamos en cada uno de los pasos anteriores, 1: 1 entre este gerente y su empleado no del todo a la altura que estaba arruinando el resto del equipo, y el resultado fue que el miembro del equipo fue despedido, no por falta de intentos por parte de todos, sino por falta de aptitud y, hasta cierto punto, de competencia.

Entonces, la solución para que todos ustedes promulguen es que no pueden promulgar una solución. Involucre a su gerente y plantee los problemas tan claramente como lo ha hecho aquí, tanto en términos de lo que ha intentado, dónde salió mal y dónde usted y su equipo necesitan ayuda.

Su análisis del problema es acertado: de hecho, estamos empezando a ver que la confianza y el respeto dentro del equipo están empezando a sufrir. Espero que no tenga que dejarlo ir, porque creo que se puede cambiar y se puede reintegrar como parte del equipo nuevamente si comienza a concentrarse en las cosas en las que es bueno.

Hay una razón por la que durante cientos de años las tareas fueron asignadas por los gerentes, ya sabes. Te acabas de encontrar por qué.

Si desea continuar haciendo esto (que reconozco que es una moda actual, una que siento que no estuvo bien pensada), entonces tal vez necesite clasificar las tareas según el tipo o nivel de desarrollador que puede asumirlas. Si alguien quiere hacer la transición a un puesto de mayor jerarquía o a uno fuera de su experiencia actual, quizás se le permita asumir esas tareas, pero solo con un tipo específico de orientación (como hacerlo como parte de un par) o solo con la aprobación. del líder del equipo después de que la persona argumente cómo lo manejaría. Es desastroso dejar que los desarrolladores se vuelvan locos en tareas para las que actualmente no están capacitados o no tienen el juicio o la experiencia para poder realizarlas. Es malo para la empresa, es malo para los clientes y, en última instancia, es malo para los desarrolladores que se ven afectados.

Esta no sería mi primera opción, pero tienes razón. Necesitamos una barrera que evite que los miembros del equipo demasiado inexpertos se limiten a profundizar en lo que les apetezca, incluso si es con las mejores intenciones.
sí, algunas tareas requieren que tengas un cierto nivel de conocimiento
Iba a comentar y preguntar "¿quién es el gerente?" porque es por eso que tienes (¿presumiblemente?) Gerentes.
Aparte, "cientos de años" es una exageración, ya que el concepto actual de gestión es un producto de la revolución industrial y la producción en masa, y probablemente tenga menos de 100 años.
Bueno, los maestros dando órdenes a sus aprendices es bastante antiguo. Y casi toda la ciencia de la administración eventualmente proviene del entorno del Ejército, desde los hoplitas griegos y los legionarios romanos hasta Ghenghis Khan... Creo que debemos estar agradecidos de que la práctica de la aniquilación no esté tan de moda.
Aprender una habilidad (cómo forjar, cómo cultivar, cómo improvisar) es muy diferente del trabajo de oficina. Al final del día, aprendes a hacer un zapato de un zapatero en el primero, y en el segundo haces lo que dice el jefe sin importar si hace un zapato o una dona (incluso si se supone que debes hacer un zapato) porque ese es tu trabajo. El concepto actual de "gestión" nace en la fábrica donde no está claro el producto final, pero sí el objetivo de llegar de A a B.
@DeerHunter: Bueno, los despidos son la herramienta moderna de destrucción :)
@jmac No estoy de acuerdo con su afirmación de que son muy diferentes del trabajo de oficina... solo porque los resultados finales son un poco menos tangibles, el esfuerzo es para un objetivo común. Me imagino que un nuevo aprendiz de herrero podría preguntarse por qué necesita talar árboles y su maestro podría no molestarse en explicar, pero la madera se necesita para el carbón, que se necesita para el fuego, que se necesita para la fundición/herrería... eso es gestión en sus fundamentos.

Fomentar sus buenos hábitos

Asumir desafíos es bueno. Hacer preguntas es bueno. Tratar de resolver las cosas por sí mismo es bueno. Cualquiera que sea la solución que busques, asegúrate de no dañar los aspectos positivos de él como miembro del equipo, de lo contrario, sufrirás a largo plazo.

Identifica sus malos hábitos

Entonces, ¿cuál es el verdadero problema aquí? Has enumerado un montón de síntomas:

  • no puede resolver el problema
  • Hace preguntas sin contexto.
  • Se toma el tiempo de otros desarrolladores.

Pero ¿por qué sucede esto? ¿Cuál es el mal hábito real en el corazón de estos comportamientos? ¿Es que no se da cuenta cuando ha mordido más de lo que puede masticar? ¿Es que tiene demasiado orgullo para pedir ayuda para abordar el problema desde el principio desde que lo eligió? ¿Es que quiere aprender cosas nuevas pero no tiene una manera fácil de obtener orientación cuando no puede justificarlo como parte de la solución de un problema?

Sugeriría involucrarse antes. Ya que fuiste su mentor y él confía en ti, podrías intervenir antes en el proceso de una manera no amenazante para darle una manera fácil de hablar sobre lo que te está haciendo. Algo como, "Vaya, ese problema en el que estás trabajando parece un desafío realmente interesante. Me encantaría escuchar tu proceso de pensamiento al respecto; siempre estoy buscando nuevas formas de resolver estos problemas más complicados". Es una forma no amenazante de ver cuál es el problema real y ayuda a entrar en una etapa más temprana.

Encuentre una manera de sortear sus malos hábitos

Es mucho más fácil hacer crecer el talento que corregir los malos hábitos. Si comprende mejor su motivación y por qué tiene problemas, puede encontrar la mejor manera de evitar esos escollos mientras lo mantiene motivado y usa esos buenos hábitos para lo mejor. Si quiere una retroalimentación positiva sobre cómo abordar los problemas desafiantes, puede sugerirle buenos problemas para que los aborde y asegúrese de felicitarlo cuando haga un buen trabajo. Si necesita obtener apoyo en las primeras etapas para trabajar en todo el problema antes de comenzar, puede encontrar una manera de establecer un tiempo durante las reuniones del equipo para tener una lluvia de ideas o crear una oportunidad para que trabaje con alguien para el concepto. (pero no hasta el punto de la programación en pareja).

Siempre es más fácil concentrarse en los malos hábitos porque siempre son las cosas molestas que causan problemas a otras personas. El problema es que centrarse en los malos hábitos sin cultivar los buenos corre el riesgo de matar la motivación y embotar su talento natural al hacer que concentre su energía en lo que no es bueno.

No es necesario ser gerente para actuar como tal, apoyar a los miembros del equipo es una buena práctica para cualquier persona en cualquier posición.

+1 por abordar el problema... y usar encabezados mientras lo hacías :-)
Creo que su principal mal hábito es que no se da cuenta cuando va en la dirección equivocada y está desarrollando algo que no funcionará. La participación temprana es buena, pero no siempre funciona. Incluso si discutimos el problema al principio, la solución trazada puede resultar incorrecta, ya que no entendimos todo el problema. Entonces se siente como si hubiera empeorado las cosas.
Sin embargo, no me malinterpretes, tienes algunos puntos realmente buenos que intentaré recordar cuando los necesite. :)
Quizás soy un simple mortal, pero generalmente cuando hago un trabajo creativo tratando de encontrar un problema constructivo, intento cosas que tampoco funcionan. Tiendo a llamar a este proceso de fracaso y éxito "aprendizaje".
Votado a favor. Con suerte, el OP tiene reuniones diarias de pie donde se pueden expresar los obstáculos. De lo contrario, es posible que el desarrollador en cuestión no sienta que tiene una salida para los problemas.

Probablemente deberías tener una conversación directa sobre su impacto negativo en el flujo de trabajo del equipo cuando "muerde más de lo que puede masticar". Si puede dar ejemplos puntuales sobre dónde ha dejado caer la pelota y cómo ha impactado al equipo. El objetivo no debe ser solo que deje de exceder su alcance, sino desarrollar una estrategia para perfeccionar las habilidades que necesita para convertirse en un mejor programador. Al menos te estás acercando y teniendo la conversación.

Creo que es consciente de los problemas que está causando, pero está en conflicto con su deseo de probarse a sí mismo. Le dije antes de comenzar una tarea que debería "leer sobre tecnología X", pero eso no ayudó. Siento que para que esto funcione necesito pensar en algo más concreto para decirle. ¡Aunque no es un mal consejo!

Trate de recomendarle proyectos para que los tome, podría jugar con ellos como si fueran importantes y necesitaran terminarse de inmediato. Si esto no funciona, llévelo a un lado por un momento y siéntelo. Explíquele que es importante aprender lo básico y que, dado que conoce a la empresa, debe concentrarse en las otras tareas. No le digas que tome tareas más simples, encuentra una forma alternativa de decir esto; por ejemplo, diga tomar una tarea que solo use estos 3 archivos que se usan comúnmente (o lo que sea). Puede mencionar cómo a menudo se confunde con algunas tareas y decir que es mejor tomar las que son menos intrínsecas y más cortas para completar.

Podrías decir algo como "Sé que eres ambicioso, y esto es genial, pero teniendo en cuenta que te has estancado en estas tareas, primero debes familiarizarte con las más simples como estas".

Es una buena idea, pero me preocupa no poder ver constantemente todo lo que hace. A menudo no nos damos cuenta de que es un problema antes de que ya sea demasiado tarde. ¡Aunque me gustan mucho tus ejemplos de fraseo!
Administrar quién hace qué trabajo es realmente el trabajo del gerente. ¿Ha planteado sus preocupaciones con él?
No todavía. Voy a tener una reunión personal con mi gerente mañana. Por eso hice la pregunta, para obtener ideas sobre cómo abordar lo que percibo como un problema.

Si tiene este problema, el resto del equipo tendrá el mismo problema. Tengo curiosidad por saber por qué esto no se escala al gerente del equipo, porque obviamente habrá algún impacto en el progreso del proyecto como resultado de los retrasos adicionales causados ​​por las ineficiencias. Dado que es un entorno de equipo, y las personas realmente necesitan trabajar juntas en armonía, esto debe resolverse en equipo para que él tampoco lo tome como algo personal. En el peor de los casos, la persona no es adecuada para el equipo (técnicamente o socialmente) y es posible que deba ser eliminada (si nada más funciona). Pero no es realmente su problema el que debe tratar, sino el problema del líder/gerente del equipo, así que asegúrese de plantearlo a la(s) persona(s) adecuada(s).

Con suerte, el gerente se encargará de eso, así que sea sincero con esta persona sobre la posición en la que ha puesto a todos cuando el gerente solicite comentarios. Hágale saber que no le va a mentir y que estas son las cosas que le voy a decir.

Ofrecer ayuda. Si cree que ha tomado una tarea demasiado grande, configure las pautas. Hágale saber que puede dedicarle un breve período de tiempo y luego mostrar algún progreso o abandonar la tarea. Permitir preguntas en un tiempo determinado. No se le permite simplemente interrumpir. Ha abusado de ese privilegio durante algún tiempo.

Si él es reacio a programar parejas, no debe esperar que funcione al principio. Se va a resistir ya ser difícil como un niño. Empeorará antes de mejorar. Sientes que esto es importante, apégate a él hasta que se sume a bordo o sufre las consecuencias. Y debe haber consecuencias.

Me parece que todo el mundo estaría mejor si no hiciera nada en lugar de todos estos esfuerzos contraproducentes. Incluso si se asigna a sí mismo una tarea, ponga a alguien más en ella también. Simplemente no veo lo que tienes que perder. El jefe se dará cuenta mucho antes.

¿Cómo trato con un miembro del equipo que sigue asumiendo tareas que no puede resolver?
RespuestasAquíPolítica de privacidad1y, 0v