La fricción entre los gerentes de producto y los ingenieros es uno de los problemas más predecibles en los equipos de software y uno de los que más consistentemente se maneja mal.
PMs siento que los ingenieros rechazan todo sin ofrecer alternativas. Los ingenieros sienten que PMs se comprometen con los plazos y el alcance sin comprender la complejidad técnica. Ambas partes suelen tener razón sobre los puntos ciegos de la otra parte, y ambas suelen estar equivocadas sobre las intenciones de la otra parte.
Las retrospectivas de sprint estándar rara vez solucionan este problema porque tienden a permanecer dentro de los límites del equipo. Ingenieros retro con ingenieros. PMs informe a PMs. La tensión interfuncional simplemente se acumula hasta que estalla en una reunión de planificación o en un plazo incumplido.
Una retrospectiva dedicada a la ingeniería de productos reúne ambas perspectivas en la misma sala con una estructura que hace que la conversación sea productiva en lugar de combativa.
Los cuatro puntos de fricción recurrentes
Antes de diseñar la retrospectiva, conviene nombrar honestamente las tensiones. En la mayoría de los equipos, se agrupan en cuatro categorías.
1. Requisitos que parecen claros pero no lo son
Un PM escribe una especificación que considera exhaustiva. Un ingeniero lo lee y tiene quince preguntas. El PM se siente como si el ingeniero fuera quisquilloso. El ingeniero siente que el PM no ha pensado en los casos extremos.
La raíz del problema rara vez es la pereza de cualquiera de las partes. PMs y los ingenieros piensan en los productos de manera diferente. PMs pensar en los viajes de los usuarios y los resultados comerciales. Los ingenieros piensan en los flujos de datos, la gestión del estado y los modos de falla. Una especificación completa desde una perspectiva está llena de lagunas desde la otra.
2. Velocidad versus calidad
PMs son responsables del envío a tiempo. Los ingenieros son responsables cuando algo falla en la producción. Estos incentivos van en direcciones opuestas y ninguno de los dos está mal.
El conflicto se manifiesta en debates sobre la reducción del alcance, la cobertura de las pruebas, la minuciosidad de la revisión del código y si se deben tomar atajos técnicos. Sin una conversación explícita sobre estas compensaciones, cada parte asume que a la otra no le importa lo que importa.
3. Deuda Técnica
Los ingenieros ven que la deuda se acumula y necesitan tiempo para abordarla. PMs ven una acumulación de funciones orientadas al usuario y luchan por justificar el trabajo que es invisible para los clientes. El resultado: la deuda se aplaza hasta que empieza a causar incidentes, momento en el que todos coinciden en que debería haberse solucionado antes.
4. Estimaciones y previsibilidad
PMs necesidad de comunicar los cronogramas a las partes interesadas. Los ingenieros se resisten a dar estimaciones porque saben cuánta incertidumbre existe. El PM escucha "No quiero comprometerme" y el ingeniero escucha "solo dime lo que quiero escuchar". Ninguna interpretación es exacta.
Configurando la retrospectiva
Ejecútelo trimestralmente o después de lanzamientos importantes. Mensualmente es demasiado frecuente: los patrones necesitan tiempo para desarrollarse.
Quien asiste: Gerentes de producto, líderes tecnológicos e ingenieros senior. Mantenga el grupo entre 6 y 10 personas. Si el grupo es más grande, la conversación se vuelve performativa.
Duración: 90 minutos. Las retrospectivas multifuncionales toman más tiempo que las del mismo equipo porque se necesita tiempo para generar un entendimiento compartido, no solo problemas superficiales.
Facilitación: Utilice un facilitador neutral, idealmente alguien que no sea un PM o un ingeniero del equipo. Un gerente de ingeniería, un scrum master o alguien de otro equipo funcionan bien. El trabajo del facilitador es evitar que la conversación se convierta en un debate y garantizar que ambas partes se sientan escuchadas.
Una estructura que funciona
Parte 1: Colección de doble perspectiva (20 minutos)
Haga que PMs y los ingenieros escriban tarjetas de forma independiente respondiendo las mismas tres preguntas:
- ¿Qué funcionó bien en nuestra colaboración este trimestre?
- ¿Dónde nos frenó la fricción?
- ¿Qué le gustaría que la otra parte entendiera mejor?
El tercer mensaje es el importante. Saca a la luz suposiciones y frustraciones que normalmente no se expresan.
Recoge todas las tarjetas de forma anónima. Esto es importante: las personas escriben de manera más honesta cuando su nombre no aparece adjunto, especialmente cuando se trata de tensiones interfuncionales.
Parte 2: Discusión temática (40 minutos)
Agrupa las tarjetas por temas. Los más comunes incluyen: claridad de requisitos, proceso de estimación, decisiones de priorización, brechas de comunicación y manejo de deuda técnica.
Para cada tema, evite la tentación de debatir quién tiene razón. En lugar de eso, pregunte:
- ¿Para qué está optimizando cada lado? (Por lo general, ambas partes tienen objetivos legítimos que están en tensión).
- ¿Dónde se está rompiendo el traspaso? (La mayor parte de la fricción ocurre en los límites entre roles, no dentro de ellos).
- ¿Qué información le falta a cada lado? (Muchos conflictos son en realidad asimetrías de información disfrazadas).
Parte 3: Acuerdos Específicos (30 minutos)
No te vayas con intenciones vagas. Salir con acuerdos de trabajo específicos a los que ambas partes se comprometan.
Los buenos acuerdos de trabajo son:
- observables -- Puedes saber si están sucediendo o no.
- bilaterales -- Ambas partes cambian algo, no sólo una de las partes exige a la otra.
- Caja de tiempo -- Pruébelos durante un trimestre y evalúe.
A continuación se muestran ejemplos de acuerdos que tienden a funcionar:
Para mayor claridad de los requisitos: "PMs y los líderes tecnológicos pasarán 30 minutos juntos antes de compartir cualquier especificación de característica con el equipo en general, específicamente para identificar casos extremos y limitaciones técnicas".
Para estimación: "Los ingenieros proporcionarán estimaciones de rango (mejor caso/probable/peor caso) en lugar de estimaciones de un solo punto, y PMs comunicará el rango a las partes interesadas en lugar de solo el mejor caso".
Para deuda técnica: "El 20% de la capacidad de cada sprint está reservado para trabajos priorizados por ingeniería. PMs no asigna esta capacidad y los ingenieros no necesitan justificar elementos individuales, pero los ingenieros comparten un resumen trimestral de en qué se dedicó el tiempo".
Para discusiones sobre el alcance: "Cuando es necesario reducir el alcance, el PM propone qué cortar y el ingeniero propone cómo simplificarlo. Ambas opciones se discuten antes de tomar una decisión".
Manejando las conversaciones difíciles
Algunos temas descarrilan constantemente las retrospectivas interdisciplinarias. Aquí se explica cómo manejarlos.
"Nunca tenemos tiempo para deuda técnica". No debatir si la deuda técnica importa. En lugar de eso, pregunte: ¿cuál es el costo de la deuda actual? Si los ingenieros pueden señalar incidentes específicos, ralentizaciones o problemas de experiencia de los desarrolladores causados por la deuda, la conversación pasa de lo abstracto a lo concreto. PMs responder a los datos de impacto, no a solicitudes abstractas de calidad del código.
"Los requisitos siguen cambiando". Los requisitos cambian porque el mercado cambia, llegan comentarios de los usuarios y las partes interesadas cambian las prioridades. La pregunta no es si los requisitos cambiarán, sino cómo se comunican los cambios y qué tan tarde llegan en el proceso. Centrarse en el proceso: ¿en qué punto del desarrollo se debe considerar congelado el alcance? ¿Cuál es la ruta de escalada para los cambios después de ese punto?
"La ingeniería siempre subestima". Dale la vuelta a esto: ¿el equipo realiza un seguimiento de la precisión de las estimaciones a lo largo del tiempo? Si no, empieza. Después de algunas series de datos, la conversación pasa de las acusaciones a los patrones. Quizás el equipo subestime constantemente un tipo de trabajo específico (integraciones, migraciones) y sea preciso en otros. Eso es procesable.
"PMs no entiendo lo complejo que es esto." Esto suele ser cierto, y también es trabajo del ingeniero hacer visible la complejidad. Si un ingeniero dice "esto es difícil" y el PM escucha "esto es difícil", nada cambia. Si el ingeniero dice "esto requiere cambios en tres servicios, una migración de la base de datos y tiene un riesgo de tiempo de inactividad si la migración falla", el PM puede realmente razonar sobre la compensación.
Cómo se ve bien con el tiempo
Después de tres o cuatro de estas retrospectivas, debería ver cambios concretos:
- Menos sorpresas en la planificación de sprints porque PMs y los líderes tecnológicos se están alineando antes
- Conversaciones más honestas sobre compensaciones en lugar de enfrentamientos pasivo-agresivos
- Repetición del trabajo reducida porque los requisitos se exploran desde ambas perspectivas antes de que comience el desarrollo.
- La deuda técnica se aborda de forma incremental en lugar de aplazarla hasta que provoque una crisis.
- Las estimaciones se vuelven más precisas porque el equipo se está calibrando con respecto al desempeño pasado.
El objetivo no es eliminar la tensión entre producto e ingeniería. Cierta tensión es saludable: significa que ambas partes están defendiendo lo que importa. El objetivo es hacer que esa tensión sea productiva en lugar de corrosiva.
Prueba NextRetro gratis -- Facilite retrospectivas multifuncionales con recopilación de tarjetas anónimas y flujos de trabajo de discusión estructurados.
Última actualización: febrero 2026
Tiempo de lectura: 7 minutos
