Cómo mantener alineados a producto e ingeniería sin más reuniones

El equipo de producto conoce la necesidad del usuario, el objetivo de negocio, el contexto del mercado y el razonamiento estratégico detrás de la hoja de ruta. El equipo de ingeniería conoce las limitaciones técnicas, las implicaciones de la arquitectura, las estimaciones de esfuerzo y los riesgos operativos. Cuando estos dos cuerpos de conocimiento conectan, el equipo construye lo correcto de la manera correcta. Cuando no lo hacen, ocurre una de estas dos cosas: ingeniería construye algo técnicamente excelente que no resuelve el problema del usuario, o producto especifica algo que es inviable de construir y tiene que ser redefinido a mitad del sprint.

La respuesta estándar a esta falta de alineación es programar más reuniones: planificación de sprint, refinamiento de la pila de trabajo, sincronizaciones multidisciplinares, sesiones de preplanificación y las diversas variantes de "metamos a todos en una sala". Estas reuniones ayudan, pero abordan el síntoma (la falta de alineación) en lugar de la causa (el conocimiento desconectado).

Por qué las reuniones no solucionan la alineación

Las reuniones proporcionan alineación en el momento en que ocurren. La alineación se deteriora inmediatamente porque el contexto compartido en la reunión se transmitió de forma verbal y no está disponible para nadie que no haya asistido, ni para nadie que haya estado allí pero haya olvidado los detalles una semana después.

Una reunión de planificación de sprint donde producto explica el contexto del usuario e ingeniería explica las limitaciones técnicas genera alineación para las personas en la sala, para ese sprint. El gestor de producto (PM) que se incorpora a mitad del sprint no tiene el contexto. El ingeniero que estuvo ausente tampoco. Las decisiones tomadas durante la reunión no se documentan, por lo que cuando surge una pregunta más tarde ("¿por qué decidimos excluir la funcionalidad X?"), la respuesta tiene que reconstruirse de memoria.

El resultado son más reuniones para restablecer la alineación que se había logrado en la reunión anterior. La carga de reuniones crece no porque el equipo no se esté comunicando, sino porque la comunicación no perdura.

El contexto compartido como solución estructural

La solución estructural consiste en hacer que el conocimiento de cada equipo sea accesible para el otro, de forma fácil de buscar y actualizada, sin necesidad de reuniones para cerrar la brecha.

Contexto de producto para ingeniería. Cuando el PRD (documento de requisitos de producto), la investigación de usuarios y la justificación de la hoja de ruta se pueden buscar junto con los registros de decisiones de ingeniería y la documentación del sistema, los ingenieros pueden comprender el "por qué" detrás de lo que están construyendo sin tener que esperar a que un gestor de producto se lo explique en una reunión.

Contexto de ingeniería para producto. Cuando las limitaciones de arquitectura, los registros de decisiones técnicas y la documentación del sistema son consultables por los gestores de producto, estos pueden evaluar la viabilidad y el alcance antes de presentar solicitudes a ingeniería, lo que se traduce en menos reuniones de "¿podemos construir esto?" y más propuestas de "esto es lo que queremos construir, basándonos en lo que sé sobre las limitaciones".

Historial de decisiones compartido. Cuando tanto las decisiones de producto como las de ingeniería están en la misma base de conocimientos unificada, cualquiera puede rastrear el razonamiento desde la necesidad del usuario, pasando por la decisión de producto, hasta la implementación técnica. La cadena de razonamiento es visible en lugar de estar encerrada en silos de equipos separados.

La documentación autogenerada a partir de los canales de Slack, reuniones y actividad de GitHub de ambos equipos crea este contexto compartido de forma automática. Las discusiones de producto sobre las necesidades de los usuarios y las discusiones de ingeniería sobre las limitaciones técnicas fluyen hacia la misma capa de conocimiento accesible, visible para ambos equipos.

Qué cambia en la práctica

La planificación del sprint se vuelve más rápida. Cuando ingeniería ya ha leído el contexto de producto y producto ya ha leído las limitaciones técnicas, la reunión comienza desde un entendimiento compartido en lugar de pasar los primeros treinta minutos estableciéndolo.

Las dudas a mitad de sprint se resuelven sin reuniones. Un ingeniero que se pregunta "¿por qué este requisito está estructurado de esta manera?" busca en la base de conocimientos de producto y encuentra la investigación de usuarios o la discusión con las partes interesadas que lo explica. El PM que se pregunta "¿sería viable añadir esto?" busca en los documentos de ingeniería y encuentra el contexto de arquitectura que responde a la pregunta.

Los nuevos miembros del equipo se adaptan más rápido. Un gestor de producto que se incorpora al equipo lee el historial de decisiones de ingeniería. Un ingeniero que se incorpora lee la justificación del producto. Ambos son productivos antes porque el contexto está documentado y es localizable, en lugar de estar guardado en las cabezas de sus compañeros.

Preguntas frecuentes

Ya usamos Jira/Linear para la alineación. ¿En qué se diferencia esto? Las herramientas de gestión de proyectos realizan un seguimiento de lo que se está construyendo y cuándo. No capturan por qué se está construyendo de esa manera, qué necesidad del usuario aborda, qué alternativas se consideraron o qué limitaciones técnicas dieron forma al enfoque. La base de conocimientos proporciona el contexto que las herramientas de gestión de proyectos asumen pero no contienen.

¿No trasladará esto simplemente el problema de las reuniones a los documentos? Solo si los documentos requieren creación y mantenimiento manual, que es por lo que la documentación autogenerada es importante. La documentación se genera a partir de la actividad existente en lugar de crearse como una tarea independiente. El equipo trabaja de la misma manera que siempre lo ha hecho. El contexto se conserva automáticamente.

¿Qué pasa con el aspecto relacional del trabajo multidisciplinar? El contexto compartido se encarga de la transferencia de conocimientos que actualmente ocurre en las reuniones. La construcción de relaciones, la colaboración creativa y la resolución de conflictos que también ocurren en las reuniones multidisciplinares deben continuar de forma síncrona. Reducir las reuniones informativas libera tiempo para las relacionales.

Lecturas relacionadas: Cómo reducir las reuniones, Cómo crear una base de conocimientos de producto, El impuesto de coordinación. Páginas relacionadas: Documentos autogenerados, Para gestores de producto, Para equipos de ingeniería.