Escrito por Juan Martín Gimenez Yunis, Senior Frontend Developer en Distillery
No me malinterpretes: el trabajo de los PM y PO es excelente. Sois los que entendéis a los usuarios, navegáis por las limitaciones empresariales y convertís el caos en una visión coherente del producto. Pero, ¿y si pudiéramos llevar ese trabajo, ya de por sí excelente, al siguiente nivel? En esta nueva era configurada por la IA, existe la oportunidad de crear una sinergia mucho más poderosa entre el producto y la ingeniería. Déjame que te explique a qué me refiero.
En experiencias anteriores en diferentes equipos, me he encontrado con historias de usuario que simplemente decían: “Ver Figma adjunto para el diseño”. Sin nombre de marco. Ninguna sugerencia de sección. Sólo un enlace a un archivo con docenas de marcos. Casi unas tazas de café después, encontraba el componente que necesitaba, enterrado en un grupo anidado.
No estoy señalando a nadie, es un problema de proceso que afecta a todos los equipos con los que he trabajado. Los jefes de proyecto hacen malabarismos con un millón de prioridades. Los desarrolladores cambian constantemente de contexto. El sistema crea fricciones.
Pero ésta es la parte emocionante: esto ya no tiene por qué ocurrir.
El verdadero problema: historias de usuario que hay que reescribir antes de poder utilizarlas
Esto es lo que ocurre en la práctica: Recibo una historia de usuario, y antes de que pueda siquiera empezar a codificar -o alimentar con ella mis herramientas de desarrollo de IA- tengo que reescribirla. Tengo que añadir los casos extremos que faltan, aclarar los criterios de aceptación y encontrar el enlace MCP correcto para dar a la IA el contexto de diseño adecuado (más adelante hablaremos de esto). La historia tal y como está escrita no es procesable; es un punto de partida para una conversación.
Esto importa ahora más que nunca. Según el Consorcio para la Calidad de la Información y el Software (CISQ), la mala calidad del software costará a la economía de EE.UU. unos 2,41 billones de dólares en 2022, y una parte importante de ello se debe a problemas de requisitos. Cuando las especificaciones no son claras, se cuelan los errores, se acumulan las repeticiones y todo el mundo pierde tiempo.
Esta es la fricción central. Si las historias de usuario fueran claras y completas desde el principio, los desarrolladores podrían tomarlas y correr, ya sea codificando manualmente o utilizando asistentes de IA. En lugar de eso, dedicamos tiempo a traducir las intenciones en especificaciones.
Y hay un factor agravante: cada PM tiene su propio estilo. Algunos escriben criterios de aceptación detallados utilizando formatos estructurados como Dado/Cuando/Entonces; otros escriben párrafos sin formato u omiten por completo los casos extremos. Esta incoherencia crea un impuesto oculto en todos los equipos.
La solución: Los subagentes de IA como el gran ecualizador
Hace unas semanas, asistí a un taller de Cursor en el que uno de los ponentes era un responsable técnico de MercadoLibre centrado en la productividad GenAI. Presentó el Desarrollo Basado en Especificaciones (SDD) y me enteré de que MercadoLibre había organizado un taller interno sobre este tema para más de 7.000 desarrolladores.
La idea central: “La codificación vibe no funciona a escala empresarial”. Necesitas especificaciones estructuradas.
Aquí está la oportunidad para los equipos de producto: un subagente de IA para toda la empresa que ayude a cada PM a escribir mejores historias de usuario.
Imagínate: en lugar de obligar a los PM a cambiar su forma de trabajar, les das un asistente de IA preconfigurado con las convenciones de tu empresa. El PM describe lo que necesita de forma natural. El subagente hace preguntas aclaratorias: “¿Qué ocurre si no se encuentra el correo electrónico? ¿Durante cuánto tiempo debe ser válido el enlace de restablecimiento?”. En función de las respuestas, redacta una historia de usuario completa y estandarizada.
Para los PM, esto también es una victoria: menos tiempo en reuniones de alineación e hilos de Slack aclarando lo que querías decir. Detectas lagunas antes de que los desarrolladores empiecen a trabajar. No necesitas memorizar plantillas: el subagente se encarga de la estructura.
¿Para los desarrolladores? Pasamos menos tiempo descodificando y más tiempo construyendo. ¿Para la organización? Cuando un PM senior se va, su sabiduría sobre cómo escribir buenas especificaciones no sale por la puerta, sino que queda integrada en el subagente que todos utilizan.
Empezar: tres cosas que puedes hacer ahora
1. Empieza con enlaces Figma precisos (éste es un superpoder). En lugar de enlazar archivos Figma enteros, selecciona el componente concreto y copia su enlace (Cmd+L en Mac). Esa URL incluye un nodo-id que apunta directamente a ese elemento exacto. Se acabaron las búsquedas del tesoro. Este sencillo cambio puede ahorrarte horas de idas y venidas por sprint, tanto a ti como a los desarrolladores. Para conocer los detalles técnicos, consulta la guía del servidor MCP de Figma.
2. Experimenta con Claude para redactar. Pega tu historia de usuario en Claude y pregúntate: “¿Qué casos extremos me faltan? ¿Qué preguntas podría tener un desarrollador? Te sorprenderá lo que aparece, y tardarás dos minutos. Piensa en todos los hilos asíncronos de Slack y las reuniones de alineación que esto podría sustituir.
3. Habla con tus desarrolladores. Pregúntales: “¿Cuál ha sido la última historia frustrante de implementar?”. Sus respuestas te dirán exactamente en qué debes centrarte, y te agradecerán que se lo preguntes.
¿Qué te parece?
Las herramientas existen. Empresas como MercadoLibre ya se están moviendo. La cuestión es si nosotros, los PM y los desarrolladores juntos, aprovecharemos esta oportunidad.
Algunas fuentes:
- CISQ: Coste de la mala calidad del software 2022 – La estimación de 2,41 billones de dólares
- GitHub spec-kit – Conjunto de herramientas SDD de código abierto
- Guía del servidor Figma MCP – Vinculación precisa del diseño
- Claude Sub-agents Docs – Configurar agentes de IA