Actualmente estoy implementando Scrum y un cambio a Ruby on Rails dentro de mi organización. Contamos con un equipo de seis desarrolladores, de los cuales solo dos tienen experiencia en Ruby on Rails. Dos de los otros desarrolladores se están familiarizando con Rails relativamente rápido, pero el tercero es reacio, se queja constantemente de Rails y de que no le gusta el marco.
He brindado entrenamiento moral, así como varios recursos para que pasen la curva de Rails lo más rápido posible, pero parece que no puedo lograr que esta persona se comprometa con nuestras metas de Sprint y herramientas de trabajo (es decir, Rails). Una vez que se frustra por algo, entra en un bloqueo mental que molesta al resto del equipo (incluyéndome a mí, aunque manejo los eventos con calma). Creo que es más una rabieta o un ajuste que un problema técnico real en términos de aprender el marco.
¿Alguna idea o comentario que pueda ayudarme a ser un mejor gerente y, con suerte, lograr que esta persona participe?
La mejor manera que he encontrado para ayudar a todo un equipo oa un miembro individual del equipo a embarcarse en un nuevo proyecto/tecnología/habilidad/mal necesario es la "subversión". (tenga en cuenta las citas irónicas)
Una persona que está fuertemente en contra de cierta tecnología (en este caso) claramente se siente aislada o ignorada o que su estatus en el grupo está siendo socavado. Entonces, su trabajo como PM siempre implicará administrar las personalidades de su equipo, y esta no es una excepción.
La gente quiere sentir que su posición es segura, que se valoran sus aportes y opiniones, que se escucha su voz. Así que vas a tener que analizar por qué esta persona se siente como se siente.
Entonces, una vez que haya resuelto la causa subyacente (y las descripciones anteriores son solo algunas de ellas y probablemente MUY simplificadas), entonces, como PM, debe volver a validar su posición en el grupo dándole un trabajo que la tranquilice. Asi que...
Todas estas soluciones son simplistas, por supuesto, pero espero que le den una idea de cómo lograr que todo su equipo y el desarrollador disidente "compren" el nuevo marco Rails. Haz que lo posean. Aborde sus objeciones solicitando su solución dentro del marco (es decir, descartar Rails no es la respuesta). Si puede hacer que el desarrollador se concentre en los detalles para superar sus propias objeciones, obtendrá la aceptación que necesita y un equipo más pacífico.
Dado que solo he escuchado su versión de las cosas, no estoy dispuesto a asumir que el problema es la persona de la que está hablando. Si bien estoy de acuerdo en que hay un problema, el problema involucra a las personas, los procesos y la gestión del cambio. Será necesario que reconozca esto antes de que el problema pueda resolverse a satisfacción de todos.
Lo más probable es que tengas que hacer algunos cambios en la composición de tu equipo. Eso no es una acusación del miembro del equipo; es simplemente que la gestión eficaz del cambio a veces requiere cambios en el personal.
Si hace esta pregunta en un sitio de preguntas y respuestas diferente, como Workplace SE , es posible que obtenga una respuesta diferente. Sin embargo, desde la perspectiva de la gestión de proyectos, y especialmente desde una perspectiva ágil, no ha implementado el cambio organizacional correctamente.
En la programación, cambias una cosa simple a la vez para que puedas depurarla. Ha cambiado al menos dos cosas complejas al mismo tiempo y está luchando para depurarlo.
Scrum (o cualquier marco de gestión de proyectos) requiere capacitación y tiempo para implementarse de manera efectiva. Además, los marcos ágiles requieren la aceptación de todo el equipo, no solo del gerente del proyecto.
Si tiene miembros del equipo que no están interesados en prácticas ágiles o ceremonias de Scrum, y realmente ha agotado todos los momentos de enseñanza y oportunidades de entrenamiento, entonces debe asumir la responsabilidad de haber prescrito un marco sin haber creado primero la aceptación. Después de hacer eso, debe formar un equipo que contenga personas autoorganizadas que quieran seguir un marco ágil.
En el frente del trabajo, ha introducido una serie de cambios en la descripción del trabajo del equipo, incluido el cambio:
Si ha cambiado todo eso, probablemente también haya cambiado el producto que está construyendo. Eso es mucho cambio en la descripción del trabajo de una persona, y no todos en TI quieren ser multifuncionales o aprender nuevos lenguajes y marcos que no se ajusten a sus patrones cognitivos.
Algunas personas disfrutan la oportunidad de usar nuevas tecnologías o trabajar en un nuevo proyecto, mientras que otras prefieren la estabilidad y permanecer dentro de una zona de confort bien definida. Si acaba de cambiar la descripción del trabajo de alguien de programador de .NET o Java en una tienda en cascada a desarrollador de Ruby on Rails en una organización de Scrum y/o DevOps, seguramente habrá personas que no pueden o no quieren hacer el cambio.
Si el equipo no condujo este cambio a la pila de tecnología, entonces la gerencia debe estar lista para asumir la responsabilidad de haber cambiado la descripción del trabajo. Además, tanto la alta gerencia como el gerente del proyecto deben esperar tener que volver a capacitar y reformar un equipo en torno a una nueva pila de tecnología.
No todo cambio es responsabilidad del empleado. Es fantástico que cinco de los seis miembros de su equipo actual estén de acuerdo con los nuevos proyectos y marcos tecnológicos. Ahora es su trabajo determinar si hay un rol para alguien que no se ajuste a su nuevo modelo de TI.
Quizás esta persona pueda asumir un rol diferente dentro de la empresa o del equipo. Tal vez haya otros proyectos u otros equipos en los que esta persona pueda trabajar, que puedan ser de más interés para ella. Si no, básicamente estás diciendo: "Adoptar el nuevo paradigma o encontrar un nuevo trabajo".
Como negocio, esa puede no ser una perspectiva irrazonable. Sin embargo, desde el punto de vista de la creación de equipos, generalmente obtendrá mejores resultados al reconocer que no todas las personas son adecuadas para todos los equipos o culturas organizacionales. Tenga esto en cuenta siempre y cuando decida realizar cambios en la composición de su equipo, ya que nada destruye la cohesión del equipo tan rápido como culpar a los trabajadores por los resultados de las decisiones estratégicas de la empresa.
Trate esto como un cambio en los requisitos del trabajo, en lugar de un problema interpersonal. No solo es un enfoque más constructivo que tratar de asignar culpas, sino que también es más probable que resulte en una resolución objetiva.
El hecho es que Rails es un marco anticuado, lento y con errores.
Supongo que se ha visto obligado a asumir algún trabajo de proyecto heredado que exige su uso, pero debe reconocer que trabajar en este proyecto no será beneficioso para las carreras de sus desarrolladores.
A menos que los compenses con un aumento de salario, trabajando desde casa, menos horas o algo así, los buenos se irán a trabajar a otro lado.
La solución es sencilla. Pregúntele al desarrollador: "Si fuera un profesional independiente, ¿cuánto cobraría más por un proyecto de Rails que por un proyecto de 'idioma favorito'?" Entonces págales el porcentaje extra
nvoigt