Redacción de Especificaciones y Traspaso a Ingeniería sin Fricción

Su última especificación tenía ocho páginas. Ingeniería la abrió una vez el lunes, revisó los encabezados rápidamente y no volvió a abrirla. El jueves, dos historias estaban bloqueadas porque nadie sabía si la exportación debía incluir registros archivados. En la siguiente revisión del sprint, el 40% del trabajo había sido rehecho. Le culparon por la especificación extensa. Culparon a ingeniería por no leerla. Nadie arregló el sistema.

Ese es el ciclo. Esta es la forma de romperlo.

Por Qué su Última Especificación no se Leyó

He visto este patrón en tres equipos en el último año. Cada uno tenía un stack diferente, un dominio diferente, el mismo patrón: el PM produce una especificación larga, ingeniería produce un sprint largo, y la brecha entre lo que se escribió y lo que se construyó se llena con reelaboración.

El número del 40% de reelaboración no viene de una encuesta. Es lo que los equipos encuentran cuando realmente lo cuentan. Revise los tickets de su último sprint, marque cada historia que cambió de alcance, obtuvo un ticket de seguimiento o se lanzó con un error conocido que se remontaba a «no lo sabíamos». Esa es su tasa de reelaboración. La mayoría de los equipos que hacen este ejercicio honestamente terminan entre el 30 y el 50%.

La especificación no causó esto sola. Pero la especificación es el lugar más económico para corregirlo. El código es costoso de reescribir. Un documento es gratuito de reescribir, y un documento de 1 página se reescribe mucho más que uno de 8 páginas.

Esto es lo que reemplazamos a la novela.

La Especificación de 1 Página

Siete secciones. Cada una justifica su lugar. Si una sección no está haciendo trabajo real, no va dentro.

# [Nombre de la Funcionalidad]

**Problema**
Qué está roto o falta para el usuario. Una oración. Usuario real, dolor real. No «los usuarios no pueden hacer X». Más bien: «Los representantes de ventas no pueden exportar su pipeline para compartirlo con su gerente antes de las reuniones 1:1, así que lo capturan en pantalla y lo pegan en Slack.»

**Hipótesis**
Si lanzamos [cosa], entonces [resultado] ocurrirá, porque [razón]. Una oración. Esto es en lo que apostamos.

**Métrica de Éxito**
El único número que nos dice si ganamos. No tres. Uno. Sea específico: «El 30% de los representantes de ventas que ven su pipeline usan Exportar dentro de los 14 días del lanzamiento.» Añada un indicador adelantado si el indicador rezagado tarda demasiado en leerse.

**Alcance**
Qué está incluido. Lista de viñetas, máximo 7 elementos. Cada viñeta es algo que un usuario puede hacer o ver.

**Anti-Alcance**
Qué NO está incluido, aunque alguien lo pedirá. Lista de viñetas. Sea específico: «Plantillas de exportación personalizadas: no en v1. Exportaciones programadas: no en v1. Reordenación de columnas CSV: no en v1.» Esta es la sección que salva su sprint.

**Casos Límite**
Las cinco cosas que se romperán si no las consideramos ahora: estados vacíos, errores, conjuntos de datos grandes, permisos, ediciones simultáneas. Liste los reales para esta funcionalidad.

**Preguntas Abiertas**
Las decisiones para las que aún no tenemos respuestas, con nombres asignados. «¿La exportación incluye tratos archivados? @ravi confirmará con operaciones de ventas el miércoles.»

Eso es todo. Una página. La especificación completa.

La característica clave es el anti-alcance. La mayoría de los PM lo omiten porque parece negativo o porque piensan que «obviamente no vamos a hacer X». Nunca es obvio para ingeniería. Nunca es obvio para diseño. Nunca es obvio para la parte interesada que le escribe el viernes preguntando por qué su funcionalidad favorita no está incluida. El anti-alcance es la sección a la que apunta cuando alguien intenta ampliar el trabajo durante el sprint. Sin él, está argumentando de memoria. Con él, está señalando una línea en la que todos dieron su visto bueno hace dos semanas.

He lanzado funcionalidades sin anti-alcance y terminé reconstruyendo el flujo de exportación dos veces porque la primera versión asumía datos sin filtrar y la segunda se adaptó para manejar filtros guardados. Dos ingenieros, tres semanas. Todo evitable con una sección de anti-alcance de 4 viñetas que tardó 90 segundos en escribirse.

La Revisión Previa de Ingeniería (15 Minutos)

La especificación no va directamente de su computadora a Jira. Pasa por una revisión de ingeniería de 15 minutos primero, y usted trae un borrador, no un documento terminado.

La configuración:

• Quiénes: el líder técnico, un ingeniero senior, usted. Eso es todo. Sin diseño todavía. Sin PM par. Sin gerente.
• Cuándo: antes de haber mostrado la especificación a nadie más. Antes de que diseño haya comenzado. Antes de que las partes interesadas hayan opinado.
• Qué trae: la especificación de 1 página, marcada como BORRADOR. Las secciones de Problema e Hipótesis son firmes. Todo lo demás es material de discusión.
• Qué obtiene: una lista de casos límite que omitió, una idea aproximada del esfuerzo y un «este es el enfoque incorrecto» temprano si lo es.

La agenda, mantenida en una nota adhesiva:

0-2 min:  Problema e hipótesis (usted habla)
2-8 min:  Ingeniería identifica problemas en el alcance y los casos límite
8-12 min: Ingeniería propone dos o tres direcciones de implementación
12-14 min: Preguntas abiertas, quién es dueño de cada una
14-15 min: «¿Estamos bien en la dirección general?», sí/no/tal vez

Si la respuesta es «no» o «tal vez», no escribe más especificación. Va a corregir el encuadre del problema o el enfoque. La mayoría de los problemas de especificación son problemas de encuadre disfrazados.

La razón por la que esto funciona: ingeniería revisando una especificación a medio hacer le da su mejor pensamiento antes de estar en modo defensivo. Una vez que una especificación está «terminada», la revisión se convierte en una crítica de su trabajo. Cuando es un borrador, están co-creando. El mismo ingeniero que habría escrito un comentario de 12 puntos en Jira dirá en cambio «¿qué tal si simplemente añadimos un indicador al endpoint de exportación existente?» y le ahorra una semana.

El Documento de Arranque

Una vez que la especificación de 1 página pasa la revisión previa y diseño ha opinado, usted escribe el documento de arranque. Este es el que se fija en el canal del equipo. Es un contrato.

Cuatro secciones, cada una breve:

Tabla RACI, un nombre por rol

Un comité no puede rendir cuentas. Un nombre sí puede.

Si no puede llenar la fila «Con autoridad» con un solo nombre, el proyecto no está listo para comenzar.

Hitos con Fechas

Tres o cuatro hitos. Fechas reales. No «al final del sprint».

• 14 de marzo: Diseño listo, desarrollo comienza
• 21 de marzo: Endpoint de backend detrás del indicador de funcionalidad, prueba interna en staging
• 28 de marzo: Beta con 10 clientes
• 4 de abril: Día de demo (no negociable)
• 11 de abril: Disponibilidad general

Fecha de Demo: No Negociable

Elija una fecha. Dígasela al equipo. Dígasela a las partes interesadas. Dígase a usted mismo que hará la demo de lo que exista en esa fecha, aunque sea imperfecto.

Las fechas de demo que se mueven no son fechas de demo. Son aspiraciones. Lance lo que tiene. Si lo que tiene es la mitad de una funcionalidad, haga la demo de la mitad de una funcionalidad y explique qué queda. Así se construye la confianza. El equipo que hace demos cada dos semanas aunque el resultado sea imperfecto siempre termina siendo más rápido que el equipo que hace demos cuando todo está pulido.

Criterios de Cancelación

Esta es la sección que nadie quiere escribir y que todos necesitan.

«Dejaremos de construir esto si: los clientes beta no usan la exportación dentro de los 7 días de activación, O la latencia del backend supera los 800ms en p95 con nuestro conjunto de datos de prueba, O más de dos clientes reportan problemas de precisión de datos durante la beta.»

Tres condiciones. Concretas. Medibles. Acordadas de antemano.

Sin criterios de cancelación, toda funcionalidad vive para siempre. Con ellos, el equipo tiene respaldo para dar la voz de alto. He cancelado dos funcionalidades en los últimos 18 meses usando esta sección, y ambas veces los ingenieros me lo agradecieron. Nadie quiere pasar tres semanas más en algo que no está funcionando. Solo necesitan permiso, por escrito, acordado de antemano.

Loom en lugar de Reunión (Generalmente)

¿La reunión de traspaso donde le explica a ingeniería la especificación durante 30 minutos? Omítala. Grabe un Loom de 4 minutos en su lugar.

Qué incluye en el Loom:

1. La especificación de 1 página en pantalla, usted explicándola.
2. Dos flujos de demo: el camino feliz y un caso límite.
3. Las tres cosas que más espera que sean preguntas.
4. Una oración al final: «Dejen las preguntas en el hilo, responderé antes del final del día.»

Qué le da: ingeniería lo ve a 1,5x de velocidad cuando está lista, no cuando su calendario lo permite. Las preguntas van en un hilo, lo que significa que todos ven la respuesta una vez en lugar de que usted explique lo mismo en tres mensajes directos de Slack. Los ingenieros nuevos que se unen al proyecto dos semanas después ven el mismo Loom en lugar de interrumpir a alguien.

Cuándo Loom no funciona: cuando el proyecto es genuinamente ambiguo y el equipo necesita debatir en tiempo real. Cuando la confianza es baja y el trabajo asíncrono parece que el PM está esquivando. Cuando hay compromisos estratégicos reales que necesitan una sala. Para esos casos, haga la reunión. Para todo lo demás, Loom.

La Definición de «Terminado»

Los criterios de aceptación escritos como «el usuario puede iniciar sesión» no son criterios de aceptación. Son un deseo.

Use Dado / Cuando / Entonces. Ejemplos concretos, datos reales, estados reales.

Mal:

El usuario puede exportar el pipeline.

Bien:

Dado que soy un representante de ventas con acceso de visualización a mi pipeline, Y he aplicado un filtro que muestra solo los tratos de mi propiedad con etapa = «Negociación», Cuando hago clic en Exportar y selecciono CSV, Entonces se descarga un archivo llamado pipeline-2026-04-28.csv que contiene exactamente los tratos visibles después del filtro, con las columnas: Nombre, Etapa, Monto, Fecha de Cierre, Propietario.

Caso límite (resultado vacío): Si el filtro no devuelve tratos, mostrar un aviso: «No hay tratos para exportar», y no descargar ningún archivo.

Caso límite (conjunto de datos grande): Si el filtro devuelve más de 10.000 tratos, poner la exportación en cola y enviar el archivo por correo cuando esté listo. Mostrar un aviso: «Exportación en cola. Le enviaremos el archivo por correo.»

Son dos minutos más de escritura. Son tres días de discusiones ahorradas. El ingeniero de QA lee esto y escribe una prueba. El ingeniero de backend lee esto y conoce el contrato del endpoint. El líder de customer success lee esto y sabe qué decirles a los clientes beta. Un artefacto, cuatro trabajos.

No omita los casos límite. En los casos límite es donde vive la reelaboración.

Plantilla de Retrospectiva Post-Lanzamiento

Veinte minutos. Cinco preguntas. Publicada en el canal de Slack del equipo dentro de una semana de la disponibilidad general.

**[Nombre de la funcionalidad], Retrospectiva Post-Lanzamiento**

1. ¿Qué no estaba claro en la especificación?
   (Una viñeta por persona, sin debates, solo listado.)

2. ¿Qué omitimos en el alcance, qué apareció que no habíamos planificado?
   (Esfuerzo, riesgo, dependencia, cualquier cosa.)

3. ¿Qué reelaboración ocurrió y por qué?
   (Sea específico. «Reconstruimos el filtro persistente dos veces porque no decidimos a tiempo entre URL y almacenamiento local.»)

4. ¿Qué caso límite nos golpeó?
   (El que desearíamos haber incluido en la especificación desde el primer día.)

5. ¿Qué va en la próxima especificación?
   (Un cambio concreto a la plantilla o al proceso.)

, Respuestas en el hilo antes del viernes. Resumiré y publicaré los cambios a la próxima especificación el lunes.

El objetivo no es asignar culpa. El objetivo es evolucionar la plantilla. La siguiente especificación recibe una mejora. Luego la siguiente recibe otra. Seis meses después, el proceso de especificación de su equipo es materialmente mejor que cuando empezó, y nadie tuvo que sentarse en una retrospectiva de 90 minutos para lograrlo.

Mantengo un archivo llamado spec-improvements.md con una viñeta por retrospectiva. Tiene dos pantallas de largo después de un año. Es el documento más valioso que tengo.

Antipatrones Habituales a Vigilar

Algunos patrones que aparecen una y otra vez. Nómbrelos en voz alta en el momento en que los vea. Mueren cuando se nombran.

• El traspaso de «diseño tiró por encima de la pared». Diseño termina, deja un enlace de Figma en la especificación, desaparece. Ingeniería encuentra una interacción que los prototipos no cubren, le pregunta a diseño, obtiene «use su criterio». Tres días después se lanza mal. La solución: diseño se une al arranque. Su fila RACI es «Consultado» con un nombre asignado. Están disponibles para preguntas de interacción durante el primer sprint.

• La especificación que crece durante el sprint. Una parte interesada le escribe el martes: «Oye, ¿podemos añadir X a este lanzamiento?» Usted dice que sí porque decir que no parece político. El viernes el equipo va atrasado. La solución: anti-alcance. Señálelo. «X está en v2. Lo registré.» Listo.

• El anti-alcance faltante. Ingeniería construye la funcionalidad y luego pregunta «¿qué pasa con los registros archivados?» Usted dice «buena pregunta, añadamos eso». Eso es el anti-alcance filtrándose de vuelta como una pregunta trampa. La solución: el anti-alcance está en la especificación desde el primer día. Cualquier cosa que no esté en la lista de alcance está, por defecto, fuera.

• La sorpresa del día de demo. Llega el día de la demo. El PM no ha visto el desarrollo desde el lunes. La mitad de los flujos no funcionan como decía la especificación. Las partes interesadas se van confundidas. La solución: el PM hace una revisión privada con el líder de ingeniería 24 horas antes del día de demo. Los desajustes se detectan cuando aún son corregibles.

Cierre

Una especificación es un contrato, no un ensayo.

La especificación de 1 página es breve porque las especificaciones breves se leen. La revisión previa de ingeniería dura 15 minutos porque cualquier cosa más larga se convierte en una reunión que nadie quiere. El documento de arranque tiene un nombre por rol porque los comités no pueden rendir cuentas. Loom reemplaza la explicación presencial porque la escritura asíncrona escala y los calendarios de reuniones no. Dado/Cuando/Entonces existe porque «el usuario puede iniciar sesión» ha producido mil inicios de sesión rotos.

El anti-alcance y los criterios de cancelación son las dos secciones que la mayoría de los PM omiten y la mayoría lamenta haber omitido. No las omita. Son el seguro más económico que comprará jamás.

Más breve, más preciso, con el visto bueno de todos. Ese es todo el juego.

Aprenda Más

• Descripción de Puesto de Product Manager
• Planificación de Sprint que no se Arrastra
• Comunicación del Roadmap para Equipos Multifuncionales
• Trabajar con Diseño: Traspaso entre PM y Diseñador