¿Cómo manejas un desacuerdo con un PM sobre alcance vs calidad?

#No pelees por valores, pelea por definiciones

La mayoría de las discusiones de alcance contra calidad son en realidad discusiones de definición disfrazadas de desacuerdo. Un PM suele referirse a "calidad" como pulido — una animación más bonita, un caso borde poco frecuente, un estado vacío que podría verse mejor. Un ingeniero suele referirse a "calidad" como confiabilidad — sesiones sin crashes, corrección de datos, nada que falle en silencio. El primer movimiento, antes de que nadie se atrinchere, es dejar explícito qué sabor de calidad está realmente en discusión, porque en la conversación se mezclan y casi nunca son lo mismo en la realidad.

#Clasifica en no negociable y negociable, en voz alta

Mantengo una lista corta, genuinamente corta, de cosas que no se mueven sin importar la fecha: sesiones sin crashes, pérdida o corrupción de datos, seguridad, cumplimiento de accesibilidad donde hay exposición legal, y corrección en todo lo que toque dinero. Todo lo demás — pulido visual, casos borde poco comunes, un estado vacío que sería agradable mejorar — es negociable y puede lanzarse como una mejora rápida después. Nombrar esta lista en voz alta ante un PM, en vez de tratar cada preocupación de calidad como igual de sagrada, es en sí mismo el movimiento de credibilidad: le dice que no vas a pelear por todo, lo cual hace que aquello en lo que sí te mantienes firme pese más.

#Lleva datos, no adjetivos

"Esto no se siente terminado" pierde cualquier negociación. "Esto afecta al tres por ciento de las transacciones en el mercado al que nos expandimos el próximo trimestre" gana la mayoría. Un PM quiso lanzar un flujo de reintento de pago sin manejar un caso borde específico de timeout de red porque era "poco frecuente" — sacar analítica del beta mostró que esa condición exacta de timeout afectaba aproximadamente al tres por ciento de las transacciones en un mercado con conectividad inestable al que la empresa se estaba expandiendo activamente. Ese único número convirtió "poco frecuente" en una línea de ingresos, y convirtió la conversación de un desacuerdo de sensaciones en una lectura compartida de la misma hoja de cálculo.

#Ofrece opciones, nunca solo un veto

Nunca te presentes solo con un "no". Llega con dos o tres opciones reales, cada una con su alcance, calidad y fecha explícitos: lanzar el alcance completo tarde, lanzar un alcance reducido en la fecha original con el caso borde riesgoso detrás de un flag, o lanzar en fecha aceptando un riesgo acotado y nombrado con un parche de seguimiento ya agendado y en el calendario de alguien. Eso te convierte en alguien que resuelve el problema del PM junto a él, en vez de alguien parado frente a su fecha.

#Escala el trade-off, no a la persona

Cuando genuinamente no se llega a un acuerdo, escala la decisión en sí — con tu recomendación adjunta — a quien sea dueño de la decisión de release, en vez de escalar una queja sobre el PM. El planteamiento que funciona: "aquí están las tres opciones, aquí el riesgo de cada una, esto es lo que yo elegiría, quiero que esta decisión quede registrada por quien sea dueño de ella." Eso mantiene intacta la relación con el PM para el próximo desacuerdo, que lo habrá.

#Sabe dónde está realmente tu propia línea

A veces la decisión cae dentro de tu propia autoridad como ingeniero responsable del sistema, y un crash en un flujo de pago no es algo que se negocie. Prepárate para decir con claridad, "no voy a dar el visto bueno para que esto se lance en este estado", y explicar el riesgo específico en una frase — sin dejar de reconocer que la presión de la fecha límite es una restricción real que no estás ignorando, solo una que no anula esta línea en particular.