Tal y como había prometido, comparto este resumen de la charla en Commit-Conf donde presenté el flujo de peer reviews que pusimos en práctica en el equipo Neptune en Automattic para compartir conocimiento por medio de revisión por los pares y generar un proceso de aprendizaje. (Nota: también mencioné este recap en EDUNOVATIC2019).
Bien. Lo primero es lo primero, este es el video.
¿Qué es lo que hacemos?
Empecé explicando en qué consiste el flujo
En pocas palabras, cada Happiness Engineer que toma parte en el proceso, decide lo que envía para ser revisado. Primeramente nos centramos en los Robots Rojos – así es como llamamos a los Feedbacks negativos-. Los robots rojos significan oportunidades perdidas para agradar a un cliente y concentran oportunidades de aprendizaje. También compartimos los robots verdes o feedback positivo, con el objetivo de aprender buenas lecciones de lo que los otros han hecho. El envío por sí mismo es muy directo, porque usamos un post de blog con p2 theme, que se etiqueta y convierte en un to-do item que se cerrará una vez se haya cosechado suficiente feedback de los compañeros.
Tenemos dos objetivos. En primer lugar y lo más imprtante, queremos aprender del proceso. Se trata de compartir conocimiento y procesos. No se trata de calificar o juzgar a los compañeros, para que las interacciones tengan una puntuación -y consecuentemente las personas-. Se trata decomprender nuevos enfoques para enriquecer los nuestros. Adicionalmente, tratamos de generar impactos fuera del propio proceso, como issues en GitHub, recopilar ideas para mejorar la plataforma, hacer seguimiento con el usuario por email cuando la revisión por los pares así lo aconseja… entre otros muchos.
Para terminar, la implementación del proceso es una discusión abierta y horizontal, donde todo el mundo puede tomar parte o si lo prefiere, solo echar un vistazo.
¿Fue realmente un éxito?
Lo fue. Tenemos varias pistas que nos hacen pensar en este sentido.
- Feefdback no solicitado, espontáneo, y siempre positivo por parte de los miembros del equipo.
- Numerosos impactos en otros equipos y flujos. Post publicados en los blogs de otros equipos en la compañía, emails de seguimiento para redondear el servicio que dimos a clientes, Informes de errores en GitHub…
- El número de revisiones por los pares que se hicieron (Más de mil con algo más de 6 revisiones por interacción compartida).
- El hecho de que el equipo considerara (9.8/10) nuestro proceso de revisión por los pares como un generador de impacto positivo en el equipo y de team bonding.
- Que el proceso fue adaptado o reutilizado para compartir conocimiento en 5 equipos más en apenas 3 meses desde que presentamos los resultados.
- La respuesta directa y anónima a una pregunta directa:
Factores claves para el éxito.
Lo primero que hicimos fueron brainstorm en los 1:1 semanales. La idea era respuder a la pregunta ‘¿Qué tres cosas te vienen a la cabeza que podrían ser más definitorias para justificar el éxito del proyecto?’. Con las respuestas, elimiando las repetidas o fusionando algunas, hicimos una encuesta en la que cada miembro del equipo podía calificar lo de acuerdo que estaba con cada aserción.
Clasifiqué los puntos clave en los que estuvimos de acuerdo (con notas por encima de 8.5/10 en el grado de respaldo de la pregunta) en 5 grupos. Y como resumen, estos fueron esos 5 factores:
- Horizontalidad. Todo el mundo puede participar y sus participaciones son igualmente bienvenidas. Nadie tiene una posición de privilegio desde la que juzgar.
- Apertura. Otros participanes de fuera del equipo son igualmente bienvenidos. Incluso con frecuencia se menciona gente que se piensa que pueden aportar un punto de vista interesante que genere aprendizajes. En todo caso, como la implementación es un P2 que se ve desde toda la compañía es común tener participaciones de fuera del entorno del propio equipo.
- Basado en el theme P2. Primero no necesitamos aprender una nueva herramienta o APP, porque esto es de uso común en la compañía. Esto siempre es un plus. Pero además, Los P2 son muy flexibles, se pueden incluir videos e imágenes, mencionar a gente para pedir su opinión, son directamente buscables -al ser páginas web- y cualquier discusión se integra en la base de conocimiento sin necisdad de ninguna operación complementaria.
- La finalidad es aprender y compartir conocimiento, no generar estadísticas o poner notas. Esto libera un montón de tensión y permite que se focalize en conversaciones interesantes y significativas en lugar de gastar energías en juzgar a otros miembros del equipo.
- Consideramos esto un ejercicio increible para fortalecer el equipo.
La guinda del pastel ¿Qué dicen los miembros del equipo?
Los protagonistas de todo el esfuerzo fueron precisamente -fuimos- los miembros del equipo Neptune en Automattic, así que no podía dejar pasar la oportunidad para mostrar exactamente lo que opinan. Así que vimos este video. Me dijeron que lo puse un poco rápido, pero aquí se puede parar… creo..:
Gracias, Neptunians. Gracias, Commit-confers
Millones de gracias al equipo Neptune de Automattic. Y millones de gracias a la audiencia de la charla en commit por escucharme durante media hora.
Un gran abrazo a Sofía Martín que me dio un feedback completo y sólido sobre esta charla y una buen conversación camino a casa. Y un enardecido agradecimiento a MrFoxTalbot por el feedback, pero también por todas las fotos que tomaste en el evento y tu resumen para A8c.
