¿Cómo lidiar con un compañero de trabajo mayor con hábitos de trabajo potencialmente malos?

Las otras respuestas cubren mucho, pero agregaré algo ligeramente diferente.

¿Por qué sus procesos le permiten acceder a cualquier servidor de producción de forma abierta?

Debe configurar su sistema de implementación para que sea automatizado, reproducible y cerrado; nadie debería poder eludir el sistema de implementación.

1. Elimine el acceso de todos los desarrolladores a los servidores de producción. Permítales el acceso remoto a los registros del sistema y los depuradores, pero eso es todo.

2. Ejecute toda su compilación y empaquetado de código a través de un sistema de integración continua, como TeamCity.

3. TeamCity crea sus sucursales y etiquetas específicas en git; haga que ejecute las pruebas unitarias y las pruebas de integración.

4. Implemente todo su código a través de un sistema de implementación automatizado como Octopus Deploy: esto tomará la salida empaquetada de su sistema CI y la implementará de manera automática y reproducible en cualquier entorno que haya configurado. Puede implementar ramas específicas en su entorno de desarrollo, promocionar esos paquetes a UAT o Producción, y nunca permitirá que sus desarrolladores se metan en la producción. También le brinda un registro de auditoría completo de lo que se implementó y dónde.

Utilice los procesos para hacer cumplir las restricciones a sus desarrolladores; hasta que lo haga, siempre encontrará a alguien eludiendo sus procesos manuales porque son "mejores que usted".

Si sus desarrolladores no tienen derechos de administrador en los servidores de producción, no pueden eludir sus procesos.

Sus procesos de implementación son parte de su sistema: en el caso de una reconstrucción del servidor, debería poder implementar todo su código de la misma manera que antes. Encontrará esto increíblemente difícil de hacer cuando el proceso de implementación es manual, ya que hay mucho sin documentar, mientras que si el proceso de implementación está automatizado, al menos la configuración de automatización actúa como documentación mínima: solo hace clic en un botón y tiene todos los paquetes relevantes implementados. al nuevo servidor. Sin problemas, sin problemas, recién hecho.

Editar: también, vea mi respuesta a Cómo evitar las malas prácticas de trabajo por parte de los empleados , ya que también es relevante para su situación. Debe actuar como el guardián, y para hacerlo, debe poner en práctica algunas puertas.

Segunda edición: algunas personas en los comentarios han expresado su preocupación de que esta no es una solución inmediata; desafortunadamente, a menos que el desarrollador en cuestión tenga una epifanía de la noche a la mañana, nada menos que la partida del desarrollador será una solución inmediata.

TeamCity y Octopus Deploy (no es necesario que los use, hay otros por ahí) son bastante fáciles de poner en marcha: deberían tardar un día más o menos en instalarse y configurarse, más una hora más o menos por proyecto. configuración.

Sin embargo, incluso el simple hecho de iniciar el proceso de automatización del proceso de implementación debería desencadenar algo en el desarrollador del problema: debería mostrarles de inmediato hacia dónde sopla el viento, y eso puede ser suficiente para que tomen una decisión de una forma u otra. ¿Deberían quedarse y alinearse con el liderazgo del equipo, o deberían continuar siendo insulares y arriesgarse a tener que irse...

Otra cosa a tener en cuenta es que lo que está haciendo este desarrollador es mostrar a otros miembros del equipo que pueden salirse con la suya con una mala práctica. Apuesto a que hay otros miembros del equipo que corrigen silenciosamente en producción, ocultan errores, etc. tipo de cosas que rápidamente lo llevarán a no poder reconstruir un sistema de producción idéntico si surgiera esa necesidad. Y créeme, surgirá.

Hágale saber que está involucrado en una insubordinación y que habrá consecuencias por su insubordinación. Dígale que parte de su trabajo es proteger la integridad del proceso de creación de la ingeniería de software y que él lo está aprovechando.

Si continúa, corte su acceso al servidor maestro y de producción. Luego dígale que está en un PIP donde su primera tarea será explicarle cómo pretende en el futuro cargar su código en el Maestro y la unidad de Producción (*).

Como líder de equipo, necesita un desarrollador senior. No necesitas dolor de cabeza. En particular, un dolor de cabeza que juega a prima donna y actúa como si las reglas se aplicaran a todos menos a él.

(*) Tiene que decírtelo, porque ya se lo dijiste explícitamente, y no tomó lo que le dijiste lo suficientemente en serio como para entenderlo. Cuando la razón no funciona, pruebe la religión, por ejemplo, la cosa del "relámpago en el camino a Damasco". Soy extremadamente flexible en mis métodos y enfoque de gestión :)

Y cuando se le pide que organice todo, responde y dice que tenía prioridades más altas, como implementar cosas nuevas en Producción.

De todo en la pregunta, este me parece el mejor ángulo para actuar. ¿Quién establece sus prioridades? Si sus equipos están organizados como los nuestros, es responsabilidad del líder del equipo establecer sus prioridades. Por lo tanto, hágale saber que reconoce que no le está comunicando sus prioridades lo suficiente y que hará un esfuerzo adicional para asegurarse de que se comuniquen correctamente.

Lo más probable es que una persona como esta tenga una respuesta preparada, porque no será la primera vez que alguien le diga esto. No puedo decir cuál será esa respuesta, pero estará mucho más cerca de cuál es el problema real. Estará a la vista para que puedas manejarlo mejor.

Tal vez estoy siendo demasiado sutil. Por si acaso, seré más directo. Cualquiera que ocupe un puesto de "desarrollador sénior" debe saber lo mal que lo está haciendo cuando el liderazgo se ofrece a "ayudarlo" "haciendo un esfuerzo adicional para asegurarse de que las prioridades sean claras". Deben darse cuenta rápidamente de que lo que eso realmente significa es que están a punto de perder toda libertad de elección en su enfoque hasta que se pongan en forma.

Deja claro que esto es absolutamente esencial.

¿Ya lo has hecho? Como gerente, sé que puede ser difícil confrontar a los empleados directamente cuando están haciendo algo inaceptable. Usted menciona que hubo una conversación algo como esto:

Usted: ¿Puede organizar su código y utilizar correctamente el flujo de trabajo de desarrollo que discutimos?

Desarrollador sénior: Todavía no he llegado a eso porque necesito sacar estas características urgentes.

Lo que me pregunto es, ¿cuál fue tu respuesta a esto? ¿Dejó en claro que no está de acuerdo con esta priorización y, de ahora en adelante, no debe ocurrir ningún nuevo desarrollo hasta que implemente el proceso correcto? Si no, entonces el desarrollador senior realmente no ha recibido un mensaje claro. Podría quedarse pensando que su elección fue la correcta dadas las circunstancias.

El primer paso es indicar claramente lo que espera que suceda.

Veo muchas respuestas que sugieren que le haga saber que su trabajo está en juego, etc. Pero no lo haga hasta que se haya dado este paso básico. Necesita saber que este proceso de desarrollo es obligatorio y que configurarlo tiene prioridad sobre todo lo demás.

El segundo paso es brindarle apoyo para que aprenda el proceso.

Le ofrecería que otro desarrollador le mostrara cómo se configura. Dices que su falta de conocimiento de Git es el problema (a pesar de que dice saberlo). A menos que esté 100% seguro de eso, no hay necesidad de abordarlo directamente. Simplemente indíquele que sería más fácil y rápido para él ver cómo alguien más ya lo tiene configurado, y garantizaría que todos estén haciendo las cosas de la misma manera.

A la larga, si hay un patrón constante de ocultar el hecho de que él no sabe algo con soluciones alternativas, entonces este es un problema que debe abordarse de alguna manera (ya que será bastante perjudicial).

El paso tres es escalar, solo si lo anterior no funciona.

Otras respuestas han dado indicaciones sobre cómo hacerlo.

Hacer que su ruta de confirmación preferida sea obligatoria es una buena práctica por sus propios méritos, pero no la use para resolver este problema.

El problema básico es que el desarrollador senior debe respetar su papel como líder del equipo y aceptar las prácticas que implemente. (Además, por el contrario, debe comunicar claramente sus expectativas si esto no sucede). No hacer esto y, en cambio, ocultar el problema con la tecnología sería un error.

No obstante, una vez realizada la comunicación anterior, también sería una buena idea hacer obligatorio el proceso.

Necesita un control y una revisión adecuados del código. Si entiende el proceso y lo viola sin una razón excepcionalmente buena, no lo necesita en el equipo. Díselo.

Prioridades: es su responsabilidad dejar claras las prioridades. Si se va en una dirección diferente después de que lo hayas hecho y lo haya reconocido, no lo necesitas en el equipo. Díselo.

Recuérdele, si es necesario, que la evaluación de su trabajo por parte del líder del equipo afecta su revisión de fin de año.

Déle una oportunidad justa de explicar por qué este caso fue especial... pero si no tiene una defensa adecuada (a su juicio, no a él) y no está dispuesto a prometer que no volverá a suceder, es tiempo para tener una charla con su gerente.

Hay 2 líneas de ataque necesarias aquí:

1. Necesita un proceso que facilite hacer lo correcto y dificulte hacer lo incorrecto.
2. Necesitas que el equipo esté de acuerdo/acepte qué es lo correcto.

La respuesta de moo ya cubre 1), así que me centraré en 2).

Su equipo debe saber que necesitan una rama estable, una rama compartida algo estable y una estrategia de combinación común que asegure que las personas sepan qué cambio hay en qué rama, lo que significa que todos fusionan las cosas a través de las ramas en el mismo orden. Si no lo saben, envíelos a un entrenamiento obligatorio que lleve a cabo un tercero . Sí, es caro, pero tener un equipo que no entiende de bifurcaciones es más caro a largo plazo.

Por lo general, puede dejar otras decisiones, como abrir una subrama temporal para alguna función, en manos del equipo, siempre y cuando deba asegurarse de que las decisiones que afectan al equipo sean tomadas por el equipo, no por un solo desarrollador.

Puede facilitar el trabajo en equipo con retrospectivas, reuniones en las que, después de cada característica/hito/sprint, el equipo se reúne y analiza cómo podrían haberlo hecho mejor, como equipo; la frecuencia de estas debe ser de una vez cada 1 a 4 semanas y puede encuentre toneladas de material sobre retrospectivas en línea. Si el equipo sabe acerca de la bifurcación, durante las retrospectivas, su único desarrollador debería recibir críticas de todo el equipo, no de usted. Luego puede guiar al equipo para que implemente procesos automatizados que hagan que sea más fácil hacer las cosas bien y muy difícil hacerlas mal. Estos son los procesos descritos por la respuesta de moo.

En términos generales, como supervisor directo, no puede simplemente implementar y hacer cumplir un gran proceso con el que su equipo no está de acuerdo, sin un riesgo muy alto de consecuencias. Si no conocen la bifurcación adecuada, debe capacitarlos en "la forma correcta", luego puede implementar y hacer cumplir procesos menores para obligarlos a trabajar en equipo: una forma común en su caso es exigir un código revisión sobre una fusión para Desarrollar y Dominar; la próxima vez que una combinación se haya hecho mal, ahora puede preguntar a 2 personas qué salió mal, el codificador y el revisor.

Para ello, establezca políticas físicas estrictas que requieran que los cambios se verifiquen en un repositorio específico o no se implementarán, lo que significa que el trabajo no se realiza, lo que significa que él no hace su trabajo y eso es motivo para terminación. Si la estructura de su equipo es "relajada" y los desarrolladores tienen claves para la producción y pueden implementar por su cuenta, o tienen credenciales de base de datos para implementar cambios de esquema de base de datos y no siguen los PROTOCOLOS ESTABLECIDOS POR LA ADMINISTRACIÓN , la conclusión es simple: no te estás manejando bien. Administrar, en un entorno de desarrollo de software, es principalmente diseñar las reglas y protocolos del equipo que los miembros del equipo DEBEN cumplir, no cuidar a los desarrolladores a diario.

No suplicas a tus subordinados que hagan las cosas de cierta manera. Tienes todas las herramientas necesarias a tu disposición para obligarlos a seguir los protocolos adecuados. Esto no es un problema con su empleado, sino un problema con su organización y la falta de estructura y reglas que hagan la vida más simple, más fácil y más eficiente.

Existe una posibilidad en la que nadie ha pensado: que este desarrollador senior simplemente no comprenda cómo debería funcionar el flujo de trabajo y qué debe hacer para mantenerse dentro de ese flujo de trabajo. Que nunca aprendió a usar git correctamente en primer lugar.

Si usa git directamente, entonces todas las cosas que necesita hacer son bastante complicadas, así que espero que tengas alguna herramienta además de eso. Sourcetree funciona bastante bien; Estoy seguro de que hay otros. Una vez configurado correctamente (lo que puede ser un dolor de cabeza), hace la vida mucho más fácil.

Tome a uno de los desarrolladores que hace todo bien y verifique con él cómo está configurada la máquina de este tipo. ¿Tiene las herramientas que todos los demás tienen? Si no, configúrelos. ¿Puede crear una rama? (En mi máquina, está seleccionando la sucursal desde la que desea ramificarse, seleccionando un elemento del menú y escribiendo el nombre de la nueva sucursal). Sin las herramientas adecuadas, es un dolor. Tal vez él realmente no sabe cómo hacer eso.

Vaya con él a través de todas las cosas que necesita hacer. Pídale que escriba todos los pasos que necesita hacer. Eso es lo que hice la primera vez que usé git: escribí todo. La segunda y tercera vez refiné lo que escribí porque no funcionaba del todo y había situaciones que no anticipé. La cuarta a la décima vez usé mis notas para hacer cosas, y luego ya no las necesité. Pude ver a alguien que no sabía qué herramientas usar y cómo usarlas, siendo demasiado orgulloso u obstinado para pedir ayuda a alguien, y creando un lío profano en el camino.

Guau. Simplemente guau. Esto es tan profundamente poco profesional, es increíble. Pero hable primero con Recursos Humanos para asegurarse de que estén de acuerdo y de que no haga nada que pueda ser un problema legal para su empresa. Luego hablas con él, teniendo en cuenta cualquier consejo de Recursos Humanos, y le dices que si vuelve a repetir esto, tomarás medidas para sacarlo del equipo. Lo que probablemente significa de la empresa.

Asegúrese de que Recursos Humanos entienda qué daño puede causar este comportamiento irresponsable.

Cómo convencerlo de que se detenga: al menos dos respuestas aquí terminan con él sin tener el empleo donde está ahora si no cambia. Eso debería ser convincente. Además, las personas que dicen esto son profundamente poco profesionales y peligrosas.

Cuáles son los riesgos: un servidor de producción roto es el riesgo menor. Un servidor de producción que comete errores costosos es el gran riesgo. Imagine un servidor de comercio electrónico que cobra el IVA en lugar de agregar el IVA al precio. Tendrás muchos, muchos clientes muy felices.

¿Es esto un bloqueador?: No realmente. Cuando hago una rama, espero que la rama de desarrollo cambie cuando quiero fusionarme, por lo que no hay diferencia. Si va más allá de la rama de desarrollo a la rama maestra, eso es un asunto diferente. Quien sea responsable de la rama maestra se llevará una gran sorpresa. Por otro lado, si yo fuera el responsable de la rama maestra, todo lo que no estuviera autorizado sería eliminado y quienquiera que lo haya hecho estaría en problemas.

Resumen:

• Además de los problemas técnicos y sociales planteados por otros, usted tiene una gran necesidad inmediata: las acciones de esta sola persona pueden estar produciendo la posibilidad de una falla catastrófica en un solo punto.

  • Es decir, mientras que la mayoría de los 'desastres' ocurren porque varios eventos aparentemente no relacionados y estadísticamente improbables ocurrieron simultáneamente. En este caso, un solo evento puede ser suficiente.

• Si bien es de esperar que su diligencia esté dirigida a optimizar los resultados para su empleador, también es prudente pensar en su propia posición.

  • es decir, el desarrollador, y por lo tanto usted como su gerente, puede estar (y probablemente esté) poniendo el proyecto en riesgo de una pérdida importante (medida en términos de tiempo, recursos, necesidad de replicar el trabajo, integridad del sistema, confianza del cliente y más, y en última instancia, en $ Si tal evento ocurrió y fue grave, incluso si no es el "peor de los casos", no hay razón para esperar que no pierda su trabajo.

• La pérdida anterior, de magnitud aún desconocida, podría ocurrir en cualquier momento: la próxima semana, hoy o nunca.

• Los sistemas normalmente se organizan de modo que se pueda conocer el alcance/rango/magnitud de las consecuencias de cualquier evento razonablemente previsible. En esta situación, este no es el caso, y esto necesita remediarse de inmediato.

  • Si bien sabe que las acciones del empleado lo han puesto en riesgo, hasta ahora desconoce las posibles consecuencias de los eventos probables, posibles y peores que ocurran. Establecer lo que no sabe es el primer paso para arreglar las cosas.

  • Usted está en condiciones de tomar medidas inmediatas para determinar qué es lo que desconoce acerca de toda la situación. hazlo Ahora. Luego establezca qué pasos son urgentes y cuáles pueden retrasarse un poco y luego comience a remediarlo.

__________________________________________________

Nueva pregunta para tu lista:

P0: "¿Cuáles son mis prioridades más urgentes?"

R0: ASEGÚRESE de que lo que tiene sea estable frente a pérdidas catastróficas.

No suena como si lo fuera.
Si no, hazlo así.
¡Ahora!

_________________________

Los posibles peligros y consecuencias a corto plazo y el mejor camino a seguir:

Lo siguiente no pretende ser grosero, pero pretende ser 'robusto'. Por supuesto diga si no está de acuerdo. Si estás de acuerdo. haz algo apropiado AHORA.

Usted (u otros) mencionan "robo de máquina, incertidumbre sobre "copias de seguridad", etc.
Si no SABE si está cubierto contra catástrofes de un solo punto, entonces es SU 'culpa' si sucede algo que elimina una proporción desconocida de su sistema instantáneamente
Si eso sucediera de una manera significativa, debería ser despedido y probablemente lo sería, después de haber implementado todas las actividades correctivas posibles.

Sin más información, mire su segunda (ahora 3ra) pregunta, decida qué riesgos PUEDEN existir que usted no conoce porque el sistema no está controlado y tome medidas inmediatas para eliminar esos riesgos. Esto puede implicar congelar toda la actividad y/o archivos y/o ??? por el desarrollador. Entonces, involúcrelos en el proceso.

______________

Sugerencias de puntos para formar parte de una entrevista (urgente) con el desarrollador:

Entiendo que xxx es el caso. ¿Es esto sí/no?
Si entiendo mal, por favor aclarar.

Bien, si sucede yyy, ¿cuál será el resultado?
(Si la respuesta es incorrecta, diga por qué e itere hasta llegar a un acuerdo.
(Si el ciclo iterativo no se cierra después de un período excesivo, use '45 Clear ' o un equivalente local aceptable :-( :-))

Una vez que se llega a una conclusión en cuanto a las consecuencias. Esto es inaceptable para mí. Esto me pone a mí, a la empresa o al sistema en una situación inaceptablemente peligrosa. Esto DEBE ser abordado ayer. Estoy a punto de implementar xxx. ¿Estás de acuerdo? / ¿Puede sugerir alternativas? Nuevamente, puede resultar un bucle iterativo. De nuevo, puede ser necesario el uso de "GOTO" ( o no :-} ).

Si no hace esto o equivalente será despedido como consecuencia. Algún tiempo.