Shared Understanding — ¿Cómo se comunican las especificaciones de producto?
Cuando eres responsable de liderar el desarrollo de un nuevo producto es necesario entender cuál es la manera efectiva de comunicarte con tu equipo, la persona encargada de esta posición suele denominarse product lead. Existen otras definiciones similares a las del product lead: product manager, product owner, etc. Lo importante es que todas tienen la responsabilidad de lanzar nuevos productos o servicios, desde la ideación hasta la entrega de los mismos. El camino que tomamos para llegar a la meta de entrega puede variar. Como muchas otras cosas en la vida, no hay un libro o instructivo que te dicte paso a paso cómo lograrlo.
El principal reto para lanzar un producto es la comunicación.
Existen distintas herramientas para comunicar una idea, desde un dibujo en una servilleta hasta prototipos dinámicos creados en apps como Invision. El problema es que no todos interpretamos lo que vemos de la misma manera. Por esta razón las empresas de tecnología promueven la practica de redactar stories para complementar los prototipos. Cada story va contenida en una tarjeta en tu tablero de tareas. Las stories nos ayudan a traducir la idea en una tarea que un equipo puede realizar.
¿Cómo se comunican las especificaciones de producto?
Aunque no hay una manera oficial de documentar una especificación de producto; hay mejores practicas. A fin de cuenta, cada organización y equipo define sus reglas para lograr un shared understanding. Puedes empezar con una idea definiendo los requerimientos con tu equipo, pero los mismos pueden ir cambiando con el tiempo de acuerdo a las necesidades que van enfrentando.
En albo usamos una herramienta llamada JIRA, en ella registramos las especificaciones que van ligadas a la entrega de un producto o servicio. Nuestro equipo actualmente cumple una lista de los siguientes requerimientos mínimos para considerar que una especificación está “lista” para meterse al horno de producción:
- Un título fácil de entender. ej. “Implementar nuevo intro screen”
- Un user story o job story, dependiendo cuál aplica mejor para el requerimiento. Lo importante es responder estas tres preguntas: ¿Quién está teniendo problemas? ¿Qué problemas solucionar? y ¿Por qué solucionar esos problemas?
- Una lista de criterios de aceptación, lo mínimo necesario para que la tarea pueda funcionar. ej. “Al cerrar la pantalla debe llevarte a home”
- Un link al prototipo y assets gráficos
- Un link que te lleva a la visualización del flujo de la implementación, el diagrama de flujo
- Un responsable
- Una estimación del tiempo o esfuerzo que llevará completar el trabajo. El trabajo de un product lead no acaba con tener la documentación lista.
En teoría cuando ya tienes tu prototipo, tu diagrama de flujo, y las especificaciones listas (con stories y criterios de aceptación), puedes dar el banderazo para iniciar. Aún así, la realidad es que es común que llegues un tiempo después a revisar el trabajo y ¡no va como esperabas!
Los requerimientos de producto, prototipos, flujos, y otros documentos, son excelentes herramientas de apoyo, pero no quiere decir que por haberlos entregado hay un “entendimiento en común” y una definición de “lista.”
“Shared understanding” o entendimiento en común es asegurarse que todos los involucrados en la entrega del producto tengan la misma imagen mental de lo que es el producto a entregar. Es algo que suena fácil, pero no lo es. No es algo que se soluciona en una sola junta, son necesarias varias conversaciones. Incluso cuando ya están trabajando en el desarrollo de producto, es importante comunicarse constantemente y que exista la mayor transparencia posible entre los involucrados. Al final, hay que revisar si lo entregado cumple con la definición de “lista” que se acordó al principio.
Una anécdota para entender la importancia de tener shared understanding:
Mi primer proyecto en albo fue diagnosticar el proceso de onboarding actual para identificar oportunidades de mejora. Teníamos un drop rate de casi 40% en un paso donde los usuarios ingresaban su correo, y tenían que esperar un código. Identifiqué también otros pasos que no necesariamente tenían que editarse, pero sí re-ordenarse.
Mi teoría inicial fue crear un nuevo flujo donde eliminaba el requerimiento del código de confirmación por correo, y re-ordenaba las otras pantallas. Básicamente lo que le pedí al equipo de desarrollo fue quitar un par de pantallas y re-ordenar otras dos. Hicimos prototipos, flujos y tuve varias sesiones donde comunicaba los cambios antes de iniciar.
Al momento de ejecutar salieron muchos problemas. Pensé que como yo había logrado comunicar y hacer entender a mi nuevo equipo de desarrollo los requerimientos para cambiar el onboarding, nada podía fallar.
¿Por qué falló la implementación en el primer intento?
En resumidas cuentas, todos en nuestro equipo éramos nuevos y habían muchas areas de oportunidad en cuanto a comunicación con el resto de la compañía. A pesar de que en nuestro equipo todos entendíamos el objetivo, teníamos una fuerte dependencia con el equipo que desarrolló la base de datos originalmente. El problema radicó en que nosotros sabíamos perfectamente qué cambios hacer de nuestro lado, pero el resto de los equipos de los que dependíamos no tenían ese “shared understanding”, y no teníamos el nivel de transparencia que necesitábamos para ejecutar el proyecto en conjunto.
Perdimos tiempo re-ejecutando los esfuerzos debido a la falta de shared understanding y transparencia.
Resolver un reto que parecía sencillo se volvió algo muy complicado. Fue necesario parar todo y volver a tener sesiones de entendimiento, pero esta vez involucrando a los otros equipos. Fue necesario repetir todo el proceso de comunicación a nivel compañía por que nuestro cambio involucraba a varios departamentos.
¿Pudimos haberlo evitado?
Probablemente. Es importante que todo el equipo y la compañía estén alineados a los cambios organizacionales, entiendan los objetivos del momento, y se tenga una comunicación transparente entre las dependencias.
El rol del product lead:
Ser un product lead/manager es como ser el pegamento entre el área de diseño, desarrollo y negocio. Puedes poseer muchas habilidades técnicas, pero es más importante tener soft skills para conectar con las personas, entenderlas, y ayudarlas a mantenerse enfocados en la meta.
Para ser un product leader más efectivo es necesario conocer bien a los integrantes de tu equipo, sus dependencias, y facilitar la comunicación entre los mismos. Cada grupo de personas tiene un comportamiento diferente, y una manera distinta de ver las cosas. Si comprendes los motivadores y presiones que afectan a cada individuo y grupo de la compañía, es más fácil prever las dinámicas de interacción. Es muy importante saber escuchar. Se recomienda realizar una revision diaria para atacar los problemas antes de que estos escalen.
Si tienes alguna pregunta sobre product management puedes contactarme directamente y con gusto podemos platicar.
