En el contexto actual a menudo nos preguntamos sobre la manera de distribuir el conocimiento entre los miembros del equipo y ser capaces de tener un equipo que sea consciente de su mapa de habilidades, que va ayudarnos a conseguir nuestros objetivos.
Es común encontrarnos en los equipos de producto con perfiles expertos en un campo específico ya sea tecnológicamente o de una pieza del producto en sí con respecto a los demás que posiblemente lo sean en otro campo. Es muy probable que esto nos cree silos que hace que el equipo se enfrente a situaciones que según la demanda u objetivos el mayor peso esté en una parte o varias del producto a la vez, lo que nos podría generar un entorno donde el intercambio de conocimiento no fluye, cuellos de botella y frustración.
La práctica de “Team competency matrix” que propone Management 3.0 puede ser un gran aliado en este propósito, aunque antes tendríamos que reflexionar y hacernos preguntas sobre nuestro contexto y el punto donde se encuentra nuestro equipo. En esta línea podemos basarnos en el modelo de Tuckman para conocer más sobre el punto que se encuentra nuestro equipo y así preguntarnos en qué etapa se encuentra. Este input será muy valioso de cara a conocer qué le falta a nuestro equipo para avanzar a la siguiente etapa o consolidar la actual y ser conscientes de si esta práctica nos aporta valor en ese momento.
En el siguiente diagrama visualizamos las etapas de desarrollo de un equipo y como afectan en dos ejes: rendimiento del equipo y efectividad o madurez. Si observamos la imagen puede dar la sensación que los equipos evolucionan de una forma lineal pero no siempre es así, es posible que un equipo se quede estancado en una etapa de su desarrollo o incluso ir hacia atrás en su evolución según las situaciones a las que se vaya enfrentando.
Un equipo que se encuentre en etapas más primitivas como “grupo de trabajo” o “pseudo equipo” va a tener unas necesidades diferentes a una etapa cercana del “equipo potencial” por lo que el equipo demandará el establecimiento de acuerdos y formas de trabajo para avanzar. Para esta práctica lo óptimo sería buscar una etapa cercana al equipo potencial, para que tenga el impacto que queremos, o al menos tener superada la de pseudo team. Además es posible complementarlo con modelos de liderazgo como por ejemplo las escaleras de liderazgo de David Marquet que nos ofrecerán un input en relación al liderazgo que se ejerce.
Para introducir esta práctica podemos dividirla en 3 grandes bloques:
En el primero necesitamos analizar qué enfoque queremos darle a nuestra práctica:
- Enfoque generalista donde el objetivo es la autoevaluación de las habilidades de los miembros del equipo ya sean profesionales o no, aquí entrarían tanto hard como soft skills.
- Centrado en el producto y los diferentes grupos o partes funcionales desglosado por las competencias técnicas que existen para evolucionar cada parte del producto. Por ejemplo, si hablamos de un producto de retail podríamos tener: pedidos, inventario o logística como dominios y dentro de cada uno de estos habría competencias técnicas tales como habilidad con frameworks de desarrollo, integraciones con otros, uso de APIs, esto es algo que necesita ser acordado y será de diferente de un producto a otro.
- Combinación de ambos.
Para el segundo bloque es necesario acordar la escala de nivel de conocimiento que vamos a usar en nuestro contexto, se podría usar la siguiente relacionándolo con colores:
- (Amarillo) nada de conocimiento, (Morado) conocimiento básico, (Azul) puede desenvolverse pero con ayuda, (Rosa) puede hacerlo de forma independiente y (Verde) conocimiento experto, puede ayudar a otro compañero.
- Con un enfoque en el producto en esta etapa sería perfecto para definir cuantas personas son necesarias o requeridas para poder dar respuesta a cada competencia del producto.
En el tercer bloque se agrupan las siguientes actividades:
- Cada miembro del equipo ha hecho previamente un ejercicio interno de posicionarse en un nivel de conocimiento de cada competencia y dominios, que luego será compartido en un espacio con los demás con el objetivo de completar un mapa de conocimientos del producto.
- Para un enfoque generalista el ejercicio es parecido pero no es tan concreto sino que el ámbito es mucho más abierto para que cada miembro reflexione sobre qué habilidades poseo que le puede venir bien al equipo y ese sería el punto de partida.
- Por último se puede aprovechar este espacio para que cada uno exponga a los demás sobre las competencias en las que le gustaría desarrollarse.
Esta práctica también encaja cuando queramos definir un rol y co-crear las habilidades necesarias. Como acciones que pueden emerger estaría el planteamiento de prácticas como pair programming o shadowing, además si trabajamos por objetivos u OKR podemos detectar que tan difícil puede resultarnos conseguir ciertos resultados según nuestro mapa de habilidades del producto, lo que nos hará focalizarnos que el intercambio de conocimiento fluya hacia un lado u otro para la evolución de nuestro producto.
Finalmente, el impacto generado puede ser diverso, entre las que puedo destacar: mejor comunicación y flujo de intercambio de conocimiento, reconocimiento entre los miembros del equipo por lo que aporta cada persona, visibilidad de las necesidades reales del equipo de producto.
Imagen: Unsplash | Chang Duong
Agile Delivery Manager at Keepler. "I am passionate about people and creating environments where teams can develop their potential. Generating value through transparency allows me to challenge myself and be better every day."
0 comentarios