En un equipo de inicio de tecnología de software, hay un colega que se percibe que se resiste a este flujo de trabajo deseado:
Por alguna razón, el colega se resiste al flujo de trabajo anterior. Intentar presionar al colega tiene un efecto negativo, debido a la pérdida de motivación autoinformada.
Por resistir, quiero decir, él:
El colega es un conocedor . Pero nuestra suposición es que se enfoca demasiado en los detalles que distraen. Por ejemplo, comienza a usar una herramienta, justo después de estudiar toda su especificación. Pero no necesita conocer cada detalle.
El colega es estudiante de posgrado y está muy involucrado en estudios académicos.
Me pregunto cuál podría ser un buen método para acercarnos a él con respecto a nuestro flujo de trabajo.
Es posible que desee leer un libro o dos sobre cómo lograr cambios en el lugar de trabajo. El método de orden directa del jefe puede funcionar, pero a menudo es subóptimo: las personas pueden seguir las reglas al pie de la letra, pero cuando su espíritu no está en ello, la productividad se resiente.
Su flujo de trabajo no es el estándar en la empresa, pero tiene una adopción mixta. ¿Porqué es eso? ¿Hay fuerza trabajando en contra de eso? ¿La presión de las partes interesadas para trabajar más rápido y simplemente ignorar las reglas significa que algo se termina un día después? incluso cuando esas reglas significan ahorrar días en el futuro?
Tener 1 chico que resiste en una empresa es un caso diferente a tener 1 chico que resiste en tu equipo, cuando este chico también puede ver que es totalmente aceptado en otros equipos para resistir.
Tener los mismos estándares para todos puede ser engorroso, porque algunas reglas pueden tener sentido para algunos equipos pero no para otros. Pero tener una línea base de calidad tiene sentido.
Mencionaste que hiciste un Léame, es un buen comienzo. Pero tal vez una presentación inicial o algo para que la gente se sume sea una buena idea. Para que la gente entienda qué problemas resuelve tu flujo de trabajo.
El tipo que se resiste es estudiante y tiene muchas cosas que aprender. Aprender todas esas herramientas además de la programación puede parecer desalentador, ¡todavía recuerdo esa sensación! Especialmente cuando no entiendes para qué sirven esas herramientas. Una gran diferencia que un nuevo desarrollador tiene que aprender: desarrollar solo y desarrollar en equipo necesita diferentes formas de organización. Eso toma tiempo para ver y entender!
Si yo fuera usted, hablaría con él y le diría que esto es muy importante, no solo para el individuo, sino para la organización en su conjunto. Luego ofrézcase a explicarle y entrenarlo en cada parte por separado. Aprender TDD lleva un tiempo, aprender a hacer buenos compromisos lleva un tiempo, etc. También pregúntale por qué se resiste y cómo puedes ayudar a superar eso.
Un gran obstáculo para el cambio es que las personas que desean cambiar a menudo se enfocan demasiado en lo que quieren y poco en por qué otros se resisten. Sé que ciertamente hice eso en el pasado, y todavía me sucede a veces. Pero por experiencia te puedo decir que la paciencia, una mente abierta y muchas explicaciones pueden cambiar muchas cosas.
Me pregunto cuál podría ser un buen método para acercarnos a él con respecto a nuestro flujo de trabajo.
Si su resistencia es perjudicial para los proyectos en los que trabaja, entonces su gerente debe sentarse con él y mostrarle cómo su "resistencia" está perjudicando el proyecto y recordarle que debe seguir el flujo de trabajo establecido o habrá consecuencias. Si el colega continúa negándose, debe recibir las consecuencias apropiadas.
Mateo Gaiser
usuario3405291
resist
definición en la medida de lo que pude.nicolas
Benjamín
usuario3405291
code
que no está probado, que no tiene una API clara, que no se envía a través del flujo de trabajo de relaciones públicas/problema de Git...usuario3405291
Benjamín
usuario3405291
Steve
usuario3405291