¿Cómo resolver conflictos en el trabajo en equipo?

Personalmente, no sentiría que la relación es mejor si contribuyo a sacar un producto de mala calidad cuando sé que la solución es sospechosa. Entonces, la opción 2, ir con una solución menos que ideal, es algo con lo que tendría muchos problemas y probablemente me haga sentir un poco resentido por tener que trabajar con alguien a quien no se le puede enseñar.

Dicho esto, es importante elegir tus batallas. ¿Es esta una encrucijada crítica en el proyecto o es algo no crítico? ¿Es esta un área en la que está bien que la persona #2 cometa un error y aprenda de él o es un error que podría arruinar significativamente el proyecto?

Dejaría que la respuesta a esas preguntas sea su guía para decidir qué hacer. Si el error de la persona n.° 2 es algo que se puede corregir más tarde, tal vez deje que la persona n.° 2 aprenda de él. Sin embargo, si es una muy mala idea, manténgase firme y continúe buscando formas de comunicar la solución a la persona #2.

Parte de ser un gran desarrollador es aprender de los errores y tener espacio para cometerlos. Es un delicado equilibrio entre el éxito del proyecto y el crecimiento individual.

Opción 3: La Persona 1 y la Persona 2 discuten el problema/tarea/tema y las posibles soluciones/formas, así como los antecedentes. Eligen juntos la mejor manera de hacer las cosas. La calidad del producto es mejor y, de hecho, hicieron un trabajo en equipo.

Mi punto aquí es que las personas en cuestión se comunican y ambos probablemente aprenderán algo de ello. Ambas personas tienen un conjunto de conocimientos diferente y compartirán su conocimiento con la otra persona. Por lo tanto, esta opción no solo encontrará la mejor manera de hacer las cosas, sino que también aumentará las habilidades y el conocimiento.

Tenga una reunión con Person1 y Person2 primero por separado y luego juntos. Si existe la posibilidad de que puedan trabajar juntos, entonces deles lo que necesitan para hacerlo.

Establezca una fecha límite para usted mismo, cuando revise el problema, digamos un mes, y verifique si están en el camino correcto o no.

Si no muestran ningún signo de posible cooperación en el futuro, o después de la fecha límite aún no pueden trabajar juntos, saca a uno de ellos del equipo.

Para mí la integridad del equipo valora más que un individuo. Prefiero trabajar con un buen grupo, donde solo hay desarrolladores promedio, que con un grupo ineficiente donde hay un par de " héroes " y " magos ".

Tampoco es una opción. Son más signos y síntomas de un equipo que aún no ha madurado. Es una descripción clásica de lo que ocurre durante las etapas tormentosas del desarrollo del equipo.

Por lo tanto, debe observar los conceptos básicos de la formación de equipos: descripción de roles con límites, reglas de compromiso, mayor control sobre las tareas, una fortaleza más autoritaria por parte del líder del equipo que la que tendría más adelante, etc.

Si tu equipo está exhibiendo este tipo de cosas, todavía no eres un equipo.

Sí, estoy de acuerdo con David Espina aquí. Un buen PM resolverá esto manipulando cuidadosamente una reunión, es decir, cuestionar a ambos (no interrogar) de la manera normal, jugar al tonto si es necesario para que expliquen de una manera que usted, como (supuestamente) gerente menos técnico, pueda comprender, esta es una excelente manera para que se expliquen entre sí los méritos de lo que están pensando. Pasé más de 20 años como desarrollador, tengo bastante experiencia y puede ser molesto cuando alguien llega al mismo nivel y no comprende al mismo nivel técnico: es simplemente la naturaleza humana. Explicarle a alguien que debe saber/entender es una cosa, explicarle al jefe que no es tan técnico es otra olla de pescado. Las mentes frescas a menudo tienen algo que aportar, a veces, lo que suena genial es simplemente inviable a largo plazo (¡todos hemos visto esto!) y el tipo de dientes largos puede darse cuenta de esto antes del gasto del descubrimiento a la mitad de la línea. Esta es sin duda la parte más importante del trabajo de un PM, controlar a su equipo, mantener la producción alta, pero equilibrada con la moral y, a largo plazo, tomar la decisión decisiva cuando la pelota está en su cancha. En el peor de los casos, obtenga un tercer oído, otro técnico (con suerte, uno que ambos respeten) y déjelos presentar sus casos. En cuanto a dejar que fracasen como experiencia de aprendizaje, no lo haría. Las fallas ciertamente vendrán, como experimentará, no quiero que el resto del equipo sufra por la sesión de capacitación de una persona, y eso se duplica para mis usuarios y mi administración. ) y el tipo de dientes largos puede darse cuenta de esto antes del gasto del descubrimiento a la mitad de la línea. Esta es sin duda la parte más importante del trabajo de un PM, controlar a su equipo, mantener la producción alta, pero equilibrada con la moral y, a largo plazo, tomar la decisión decisiva cuando la pelota está en su cancha. En el peor de los casos, obtenga un tercer oído, otro técnico (con suerte, uno que ambos respeten) y déjelos presentar sus casos. En cuanto a dejar que fracasen como experiencia de aprendizaje, no lo haría. Las fallas ciertamente vendrán, como experimentará, no quiero que el resto del equipo sufra por la sesión de capacitación de una persona, y eso se duplica para mis usuarios y mi administración. ) y el tipo de dientes largos puede darse cuenta de esto antes del gasto del descubrimiento a la mitad de la línea. Esta es sin duda la parte más importante del trabajo de un PM, controlar a su equipo, mantener la producción alta, pero equilibrada con la moral y, a largo plazo, tomar la decisión decisiva cuando la pelota está en su cancha. En el peor de los casos, obtenga un tercer oído, otro técnico (con suerte, uno que ambos respeten) y déjelos presentar sus casos. En cuanto a dejar que fracasen como experiencia de aprendizaje, no lo haría. Las fallas ciertamente vendrán, como experimentará, no quiero que el resto del equipo sufra por la sesión de capacitación de una persona, y eso se duplica para mis usuarios y mi administración. pero equilibrado con la moral ya la larga, tomando la decisión decisiva cuando la pelota está en su campo. En el peor de los casos, obtenga un tercer oído, otro técnico (con suerte, uno que ambos respeten) y déjelos presentar sus casos. En cuanto a dejar que fracasen como experiencia de aprendizaje, no lo haría. Las fallas ciertamente vendrán, como experimentará, no quiero que el resto del equipo sufra por la sesión de capacitación de una persona, y eso se duplica para mis usuarios y mi administración. pero equilibrado con la moral ya la larga, tomando la decisión decisiva cuando la pelota está en su campo. En el peor de los casos, obtenga un tercer oído, otro técnico (con suerte, uno que ambos respeten) y déjelos presentar sus casos. En cuanto a dejar que fracasen como experiencia de aprendizaje, no lo haría. Las fallas ciertamente vendrán, como experimentará, no quiero que el resto del equipo sufra por la sesión de capacitación de una persona, y eso se duplica para mis usuarios y mi administración.

¿Has considerado usar revisiones de código? Deje que el desarrollador más débil haga su trabajo. Revisa su código y bríndales comentarios estructurados. Deles tiempo para realizar cambios en función de sus comentarios y vuelva a evaluar su entregable. Si después de un cierto período de tiempo comienza a ver mejoras, entonces está en el camino correcto y el desarrollador más débil eventualmente mejorará.

Esto supone que el desarrollador más débil comprende completamente que tiene menos experiencia y puede aceptar todas las críticas estructuradas.