¿Es conveniente tener a un equipo en el que todos sepan de todo? Hace poco viví un debate interesante: si en un equipo todos tuvieran los conocimientos de todo, evidentemente más efectivos no podrían ser… Pero ¿qué pasaría? ¿nos necesitaríamos los unos a los otros o llegaríamos, nos pondríamos los cascos y trabajaríamos? ¿Se perdería nuestra comunicación? Mmmmm…particularmente prefiero que la haya.
Eso no significa que no debamos ir aprendiendo. Desde mi punto de vista un equipo efectivo no es aquel en el que todos saben de todo, es el que cumple los requisitos necesarios para cubrir las necesidades que le surjan. ¡Somos uno!
¿Cómo podemos saber si cubrimos esas necesidades? Yo uso una matriz de conocimientos.
El procedimiento
Reunimos a todo el equipo de desarrollo. El ejercicio suele durar entre una hora y una hora y media.
Recopilación de conocimientos
Lo primero de todo es hacer una lista de todos los conocimientos que sean necesarios en el equipo. Yo siempre lo he hecho con conocimientos funcionales, pero podría hacerse con conocimientos técnicos. El mismo equipo los lista en una pizarra, en forma de columna.
Valoración individual
Junto a la columna de conocimientos añadimos una columna por cada uno de los miembros del equipo. Cada uno de ellos se evaluará con una de las siguientes opciones:
- Dejo el espacio en blanco – No sé de qué me estás hablando.
- Pongo un cuadrado o pinto en color rojo – Aprendiz: me suena, pero no podría trabajar solo en eso.
- Pinto un triangulo o pinto en color azul – Novato: podría trabajar solo en eso.
- Dibujo una estrella o pinto en color verde – Maestro: lo conozco perfectamente, podría enseñar a otra persona.
El individuo que se está evaluando no tiene por qué tener la última palabra, el resto del equipo debe tener la total libertad y confianza para debatir sus decisiones.
Recuento
Cuando todos terminen, creamos dos nuevas columnas, en una pondremos IDEAL, y en otra ACTUAL.
En la columna IDEAL, el equipo debe decidir cuántos maestros, novatos y aprendices sería necesario tener en el equipo para ser eficaces en cualquier situación (vacaciones, urgencias…)
Una vez lo han rellenado, en la columna ACTUAL contamos lo que realmente tiene el equipo, y viendo las diferencias sabremos en qué conocimientos hay que empezar a buscar acciones de mejora para llegar a lo IDEAL.
Este es un ejemplo:
Si detectamos que hay muchas diferencias entre lo IDEAL y lo ACTUAL, y que aparecerán muchas acciones a tomar, no hace falta tomarlas todas de golpe. Vamos sin prisa pero sin pausa. En este caso, junto con el equipo, decidimos empezar sólo por un par de acciones y decidí poner columnas ESTADO con la fecha de las revisiones, con la intención de ir revisando cada cierto tiempo la matriz en función de las acciones tomadas.
Otro ejemplo:
Acciones
En el caso de los equipos en los que he realizado este ejercicio, las acciones tomadas han sido realizar formaciones entre los miembros del equipo, empezar a trabajar en PairProgramming para aprender más unos de otros, que los miembros menos experimentados en algún conocimiento cogieran tareas de esos conocimientos…
Conclusión
Está claro que cada matriz puede revisarse cuando haya cualquier tipo de cambio en el equipo, si entran más miembros, pero sobretodo si el equipo decrece 🙂
Espero que os haya sido útil, y ya sabéis que con todos mis post pretendo aprender también de vosotros, así que cualquier comentario/feedback que me ayude a mejorar esta matriz será muy bienvenido.
Hola.
En nuestro equipo también realizamos la matriz de conocimientos tanto técnicos como funcionales.
Creo que lo importante es conocerse como equipo y poder tomar acciones tanto para disminuir las diferencias entre los componentes, así como para que no sigan aumentando.
Entre las acciones que hemos ido realizando nos han salido como vosotros realizar pair-programming y code review, que permite traspaso de conocimiento tanto técnico como funcional dentro del equipo.
De algunas de las deficiencias técnicas también se tomaron decisiones de formación en ciertos ámbitos de programación (TDD, diseño)
A nivel entre equipo se plantearon formaciones funcionales y crear una Comunidad de prácticas para compartir inquietudes y conocimientos técnicos.
¡Muchas gracias Marc!
Es cierto que se puede detectar también una falta global en el equipo y se puede escalar esa necesidad de formación, en este caso técnica. Me lo apunto ?
Siempre es bueno que los propios miembros del equipo se erijan como expertos o novatos, además promueve la iniciativa de auto formación del equipo. A nivel técnico también es interesante reconocer las T-Skills, sobretodo para saber el tema de compensación de conocimientos en momentos de bajas circunstanciales o finales.
Enhorabuena por el blog!