Mi equipo actual es bastante joven técnicamente (casi todos tenemos menos de un año de presencia en mi empresa), en el marco de software que está utilizando mi empresa.
La persona que tiene mayor experiencia en ese marco, tiene un año y medio de experiencia y no tiene experiencias laborales previas, excepto esta.
El resto del equipo se ha ido o está trabajando en diferentes proyectos.
Sin embargo, tenemos proyectos que entregar.
He discutido con mi CTO, pero también con el equipo, sobre la mejor manera de organizar esto y, sinceramente, creo que esta es la forma óptima, después de haberlo pensado una y otra vez.
La idea es hacer que todos contribuyan con lo que saben, por ejemplo, el tipo senior que tiene el conocimiento técnico del marco pero no una gran experiencia de trabajo de software y uno de nuestros nuevos que tiene grandes habilidades de software, experiencia pero no un gran conocimiento de la plataforma. . Eso significa poner en espera hasta que esté lista la idea de los equipos de funciones.
Sin embargo, a alguien de otro equipo se le ocurrió esta idea, con la que no estoy de acuerdo.
Como se dijo anteriormente, el objetivo es crear equipos destacados, cada equipo tendrá un colaborador bueno/excelente y también capacitar a las personas para que se suban al tren. Y también para entregar los proyectos que tenemos entre manos.
La pregunta es la siguiente y es más una forma de decir "convénceme de que estoy equivocado":
¿Alguien ha intentado con un equipo nuevo, crear equipos de características cuando "Pone a nuestra persona 'superior' en la codificación y le pide al resto del equipo que trabaje en más proyectos menores hasta que tengan las habilidades necesarias". ?
Gracias
Esto realmente parece una situación que requiere un pensamiento ágil:
Como mínimo, usaría la programación en pares para familiarizarme con el marco, junto con las revisiones del código del equipo (por ejemplo, en Github PRs o similar), lo que también ayudaría con la calidad y el intercambio de conocimientos.
Si literalmente tuviera solo 1 persona con una familiaridad significativa con el marco, rotaría a esa persona a través de emparejamientos con todos los demás.
Construiría un entrenamiento estructurado en el marco para el resto del equipo en mi horario al principio. Tal vez haya un período de 2 a 4 semanas en el que FrameworkExpert esté emparejado con otra persona que realice el trabajo de características, mientras que el resto del equipo está estudiando el marco, trabajando juntos en un libro o tutorial, con FrameworkExpert sirviendo como recurso para preguntas. Luego, en el próximo período de 2 a 4 semanas, tal vez pueda tener a la mitad del equipo trabajando en funciones, mientras que la otra mitad continúa entrenando.
Implementé una medida similar dos veces en un entorno de inicio y no funcionó como se esperaba porque las personas se fueron por una forma más dirigida de aprender con el objetivo de validar sus habilidades con una licenciatura/maestría.
La decisión inicial tuvo implicaciones y me obligó a:
. planificar cómo educarlos (y ayudarlos cuando surjan preguntas y cuando pueda);
. revisar su trabajo brindándoles retroalimentación sobre cómo mejorar (con CI/CD esto también está implícito y se convierte más en un estándar);
. aún asegúrese de que las cosas se entreguen (y asuma una gran responsabilidad al respecto).
Fue un proceso que no tomó más de 3-6 meses y fue bastante intenso. Esto era bueno para mí en términos de gestión de personas además de hacer mi trabajo y estaba dispuesto a hacerlo. El problema fue que la gente se fue 1 o 2 meses después.
Con todo, me parece que la propuesta tiene en mente la continuidad. Viene con un costo pero, no obstante, es una inversión que puede dar sus frutos siempre que haya un compromiso tanto de los miembros senior como de los demás. También puede tener consecuencias como la pérdida del miembro senior.
Entonces, desde mi experiencia, estoy de acuerdo con la persona del otro equipo solo si se cumplen ambos requisitos (esto reduce los riesgos:
. los recursos tienen contratos a largo plazo y/o sabe que está dentro de sus planes continuar en la empresa por lo menos 1 año;
. el miembro senior está dispuesto a hacerlo.
Si tal persona existe en su empresa, es posible que su equipo deba contratar a un "mentor interno" o "consultor interno" que pueda encargarse de ayudar a su equipo a comprender los desafíos que enfrentan y controlar los riesgos técnicos de su implementación.
Esto no significa que esta persona "escribirá el código", obviando así el beneficio y la mayor parte del papel de su equipo, sino que establecerá el rumbo que su equipo debe seguir mejor en estos desconocidos. -ustedes aguas. Este mentor actúa como experto en la materia (SME) y tiene la responsabilidad de guiarlo sobre qué es lo mejor que puede hacer sin tener que encargarse de hacerlo.
Acéptalo: la probabilidad es alta en este momento de que uno o varios de ustedes cometerán errores simplemente porque (todavía) no sabían que estaban cometiendo uno. Vuestro equipo de puente necesita llevar un piloto a bordo, porque, aunque la mayoría de vosotros más o menos sabéis cómo gobernar el barco, "aquí hay dragones..."
andy k