Cómo lidiar con un desarrollador difícil

Consíguelo, más temprano que tarde. El dolor a corto plazo de su pérdida llevará al resto del equipo a aprender lo que sabía el hombre indispensable e inspirar a menos hombres indispensables en el futuro. Consulte https://blogs.msdn.microsoft.com/eric_brechner/2018/02/01/good-engineers/

TLDR: En lugar de tratarlo como un problema, una perspectiva es ver sus acciones como una oportunidad para mejorar su proceso.

Reseñas de código

refactorizó una parte de la aplicación sin consultar con el equipo

¿Por qué un desarrollador es capaz de realizar una refactorización a gran escala sin el conocimiento y consentimiento del Equipo? Mi sugerencia es implementar revisiones de código obligatorias (a menudo realizadas a través de solicitudes de extracción) en todo el código aceptado. Esto no es solo un beneficio cuando se trata de este desarrollador. Todo el código es mejorado por un segundo par de ojos. También es una buena manera de facilitar el intercambio de conocimientos.

Discusiones de Arquitectura

También está planteando numerosas ideas (incluidas las arquitectónicas) y trata de forzarlas.

Personalmente, no veo el problema aquí. Una de las cosas que aprendí de un profesor en la universidad que realmente me quedó grabada es la idea de que "Ningún tema debe ser tabú". En un entorno ideal, cualquier tema debería poder ponerse sobre la mesa. Las ideas suficientemente malas se revelarán pronto, a través de la discusión y la investigación, como tales.

Y siempre existe la posibilidad de que una idea aparentemente mala solo lo parezca debido a sesgos preexistentes y, cuando se examina de cerca y racionalmente, se sostiene bien. Además, el acto mismo de tal escrutinio fomenta una cultura de aprendizaje. Si uno debe ser capaz de respaldar sus posturas, entonces debe comprenderlas a fondo. Esto ayuda a evitar los cultos de carga . Deben descubrirse nuevos conocimientos para escudriñar adecuadamente las ideas, y deben difundirse para llegar a un consenso.

En lugar de ver tales discusiones como una amenaza, véalas como una oportunidad para aprender y enseñar.

A menos que tenga una fecha límite estricta y un desarrollador siga intentando impulsar debates de una hora que involucren a todo el equipo. Sin embargo, incluso entonces, no debe decir simplemente "No, está equivocado", sino "No tenemos tiempo para discutir en este momento. Por ahora, haremos X, y podemos volver a visitarlo la próxima semana". "

Destacamento Profesional

Cada intento de mostrarle cómo se debe hacer algo de una manera más simple termina en una larga y emotiva discusión (se comporta como si hubiera sido atacado).

Una de las lecciones más valiosas que cualquier desarrollador puede aprender es "Yo no soy mi código". Un ataque al código escrito por un desarrollador nunca debe interpretarse como un ataque al desarrollador. Parece que su desarrollador 'problemático' aún no ha aprendido esto. Tienen los otros desarrolladores? ¿Tiene?

Debe fomentar un entorno seguro donde se fomente este tipo de mentalidad. Varias formas de hacer esto, pero una de las más efectivas es con el ejemplo. Pídele a otra persona que revise tu código. Pídales que señalen todos los defectos. Luego simplemente arréglalos, de buen humor, sin ponerte a la defensiva. Agradezca a su revisor por cualquier cosa nueva que aprenda durante el proceso. Anime a otros desarrolladores a hacer lo mismo. Eventualmente, la cultura de su empresa evolucionará hacia una en la que esta sea la norma esperada.

Esto, por supuesto, se complica por el hecho de que él no es un empleado de su empresa. Sin embargo, eso no cambia el objetivo de crear un entorno en el que los desarrolladores sientan que están a salvo de verse afectados negativamente por una mala revisión del código.

En su OP, tiene algunos sesgos en juego aquí que creo que debe analizar. No tengo idea de cómo estos sesgos influyen en sus observaciones, pero sé que lo son, simplemente porque nuestros prejuicios siempre influyen en la situación y usted fue muy amable al exponerlos: edad, cultura.

En segundo lugar, lo presentó como desarrollador de clientes. Entonces, esta no es una persona a la que "controlas" frente a un PM. En cambio, es una parte interesada del cliente. Lo que significa que debe tratarlo como una parte interesada del cliente, con impactos tanto favorables como desfavorables en su alcance, sus costos y su cronograma.

Esto es gestión de stakeholders 101. ¿Cómo se involucra? ¿Cuáles son sus tareas? ¿Qué información necesitas de él? ¿Qué información necesita él de usted? ¿Qué riesgos del proyecto son causados ​​por él y qué acciones necesito para mitigarlos? Y así. No vas a sacarlo de la caja de arena, por lo que debes descubrir cómo jugar con él. No hay respuestas fáciles aquí, pero lo primero que haría sería incorporarlo como socio. Involúcrelo, forme parte de la discusión y difunda la probable alienación que siente y a la que está respondiendo. Es manipulación, pero puedes generar resultados favorables a partir de ella en lugar de tratar de combatirla.

Traté con este tipo de desarrolladores antes y siempre es una pesadilla trabajar con ellos por las razones que está experimentando. Lo que me ha funcionado en el pasado:

1) Mantenga un registro RAID donde se registren todos los riesgos relacionados con el proyecto. Esto actuará como una pista de auditoría. 2) Cada vez que ocurra un riesgo o un problema debido al carácter x, escale a la alta dirección mostrándoles el registro de RAID y cómo ha afectado el estado RAG del proyecto.

Como Scrum Master, no puede hacer que despidan a esta persona, ya que no está administrando personas sino apoyando al equipo; en el mejor de los casos, puede hacer que la gerencia esté al tanto de la interrupción que está causando x persona. Luego manejarán al individuo en consecuencia.

Parece que esto realmente es una carga para el equipo y debe resolverse lo antes posible para que pueda concentrarse en las cosas importantes. Su desarrollador suena motivado al final y eso es algo muy bueno en mi opinión.

En general, todos los desarrolladores deben recibir el mismo trato y no haría ninguna excepción como scrum master, ya sea su desarrollador especial o cualquier otra persona del equipo. El equipo debe definir correctamente un acuerdo de trabajo en conjunto y, en el peor de los casos, se llega a una decisión por mayoría en el equipo. La gente necesita entender por qué el equipo quiere trabajar como ellos quieren.

Tal vez su desarrollador no use las últimas y mejores cosas que existen, pero si tiene mucha experiencia, podría convencerlo de que no reconstruya y reconsidere todo porque es nuevo, o podría ver los beneficios y quedarse. lo.

Me entristece ver todas las respuestas que sugieren una salida fácil o una solución simple que involucra una parte de sofocación continua del miembro del equipo. Como se indicó anteriormente, debe obtener esos acuerdos de trabajo redactados y comprometidos por todo el equipo a través de ceremonias destinadas a generar los acuerdos.

A partir de ahí, utilizando sus prácticas ágiles, es fundamental configurar la cultura del equipo para promover que los miembros del equipo se hagan responsables unos a otros por sus acciones y resultados. Cuando esto se hace con éxito, todavía tengo que encontrar un desafío de equipo que estos enfoques amplios puedan resolver, explícitamente en el caso que presentó.

Intente administrarlo por objetivos, o cada sprint, el equipo tiene objetivos. Dado que es el desarrollador senior más (el más antiguo) del equipo, pídale que se asegure de que se cumplan los objetivos.

Yo, mi organización, tengo el poder de mover a los desarrolladores que son un dolor para el equipo. Por lo general, creo recursos en la sombra y cualquiera que intente mostrar una mala actitud o ser un obstáculo en las actividades del proyecto, los reemplazo. Trato de advertirles o trato de explicar por qué el marco es importante y si no veo ninguna mejora, los reemplazo.

A veces, decirles que si siguen siendo difíciles les dará una calificación más baja o los despedirá, establecerá la actitud correcta.