Hace tres semanas estaba mirando una página de Notion pasadas las diez y media de la noche. Un cliente había enviado un briefing para una plataforma de reservas personalizada. El briefing tenía cuatro puntos y un emoji. Literalmente solo: "como Calendly pero para peluquerías caninas 🐶". Eso era todo. Sin flujos de usuario. Sin casos extremos. Sin idea de si querían un SaaS o una instalación de un solo inquilino. Y necesitaban una especificación antes del viernes.
Solía temer esos momentos. Ahora casi espero que ocurran.
Porque he construido un flujo de trabajo alrededor de Claude que convierte ese tipo de caos en una especificación estructurada y defendible en un par de horas. Lo he refinado en quizás 40 proyectos en Seahawk durante el último año y medio, y me ha salvado de al menos tres reescrituras de "pero pensé que haría X" que habrían costado dinero real.
Déjame explicarte esto bien.
---
Por Qué Un Briefing Vago Es En Realidad Un Buen Punto De Partida
Esto es lo importante sobre los briefings vagos: contienen señal. Lo de Calendly para peluquerías caninas te dice la industria, el producto de comparación, y la escala implícita (pequeña empresa, no empresa). Eso no es poco.
El error que solía cometer era intentar inmediatamente ampliar el briefing yo mismo. Haría suposiciones, las metería en un documento, y luego un cliente firmaría algo que era 40% mis conjeturas. Eso es un desastre esperando suceder.
Claude no tiene ese problema. Pregunta. O mejor dicho, cuando lo incitas correctamente, genera las preguntas que deberías haber estado haciendo.
Mi primer movimiento en cualquier proyecto nuevo es pegar el briefing crudo en Claude y pedirle que identifique cada suposición que tendría que hacer para construir la cosa. No características. Suposiciones. El resultado es usualmente 15-25 preguntas, y aproximadamente un tercio de ellas son las que habría pasado por alto.
Para el proyecto de la peluquería canina, Claude sacó a la luz cosas como: ¿el peluquero tiene múltiples miembros del personal, o es una operación en solitario? ¿La reserva necesita tener en cuenta el tamaño de la mascota afectando la duración de la cita? ¿Hay un depósito o captura de pago en el momento de la reserva? Yo no había pensado en lo del tamaño de la mascota en absoluto. Tampoco el cliente, como resultó. Lo capturamos en la llamada de descubrimiento en lugar de la semana tres.
---
La Estructura De Prompt Que Realmente Funciona
He probado muchas formas diferentes de hacer prompts para trabajo de especificación. Cosas genéricas como "ayúdame a diseñar una aplicación de reservas" te dan basura genérica. Lo que funciona es una entrada estructurada que da a Claude suficiente contexto para restringir su salida.
Aquí está la plantilla aproximada que uso ahora:
- Definición de rol. Le digo a Claude que actúa como gerente senior de producto que ha enviado B2B SaaS antes y es alérgico al alcance expandido.
- Briefing crudo. Pégalo tal como está, por muy áspero que sea.
- Restricciones. Rango de presupuesto, stack de tecnología si se conoce (usamos WordPress/WooCommerce para la mayoría de sitios de cliente, Laravel personalizado para cualquier cosa más pesada), cronograma, tamaño del equipo.
- Formato de salida. Pido un documento estructurado con secciones específicas: declaración del problema, personas de usuario, flujos de usuario principales, lista de características (MVP versus post-lanzamiento), preguntas abiertas, y riesgos.
La parte de restricciones es la que la mayoría de gente omite. Importa enormemente. "Presupuesto: £8,000, cronograma: 8 semanas, dos desarrolladores y un diseñador a tiempo parcial" produce una especificación muy diferente al mismo briefing sin restricciones. Sin ellas, Claude felizmente especificará un producto que tomaría seis meses y £60k construir. Lo cual es divertido de leer e inútil para enviar.
---
Iterando La Especificación Con Prompting Adversarial
Obtener un primer borrador de especificación es lo fácil. El verdadero valor está en la iteración.
Después de que Claude produce el documento inicial, ejecuto lo que llamo una pasada adversarial. Literalmente le pido: "Ahora argumenta en contra de esta especificación. ¿Dónde es más probable que ocurra scope creep? ¿Qué hemos subestimado? ¿Qué característica de esta lista causará más deuda técnica en 12 meses?"
Seahawk tuvo un cliente fintech allá por 2022 que quería un dashboard para rastrear carteras de microinversión. La primera especificación se veía sólida. La pasada adversarial identificó que la característica "actualizaciones de precios en tiempo real" en el MVP estaba haciendo mucho trabajo pesado y probablemente requeriría una arquitectura WebSocket que no teníamos en nuestro timeline ni presupuesto. Lo atrapamos. Lo acotamos a polling cada 60 segundos para el MVP, con tiempo real como característica de fase dos. El cliente estuvo de acuerdo. ¿Lo hubiéramos atrapado sin la pasada adversarial? Quizás. Pero probablemente no hasta que alguien estuviera tres semanas dentro de la construcción.
El paso adversarial suma tal vez 20 minutos al proceso. Vale la pena cada vez.
---
Traducir la Especificación en Historias de Usuario
Una vez que la especificación es lo suficientemente sólida como para no avergonzarme de ella, me muevo a la generación de historias de usuario. Aquí es donde Claude realmente brilla, porque escribir buenas historias de usuario es tedioso y fácil de hacer mal.
Devuelvo la especificación a Claude y le pido historias de usuario en el formato estándar: "Como [rol], quiero [acción] para que [resultado]." También le pido que marque los criterios de aceptación para cualquier cosa no trivial, porque "como groomer quiero bloquear tiempo de vacaciones" tiene un número sorprendente de casos extremos (¿bloques recurrentes? ¿qué zona horaria? ¿notifica a clientes con citas existentes?).
Hay algunas cosas que insisto:
- Las historias deben escribirse para una persona específica, no un "usuario" genérico
- Cada historia obtiene una estimación de complejidad aproximada (S/M/L, nada más granular que eso en esta etapa)
- Cualquier cosa en el bucket "L" se marca para una descomposición adicional antes de que vaya a Jira
Ese último punto importa. Una historia L en una reunión de planificación de sprint es básicamente una granada. Hacer que Claude las identifique temprano significa que tenemos una conversación antes de que alguien comience a construir.
---
Dónde Trazo la Línea con Claude
Quiero ser honesto sobre esto, porque veo muchas opiniones entusiastas sobre IA haciendo todo ahora.
Claude no es bueno tomando decisiones. Es excelente presentando opciones y trade-offs, pero la decisión real sobre si construir un sistema de notificaciones personalizado o usar Novu (que hemos usado en tres proyectos y recomendaríamos) aún requiere alguien que conozca el proyecto, el cliente y las capacidades del equipo.
También lo he encontrado poco confiable en cualquier cosa que involucre versiones específicas de bibliotecas o comportamientos de API específicos. Para discusiones de arquitectura amplia está bien. Para "¿esta versión específica de WPGraphQL manejará este patrón de consulta específico bajo carga?", prefiero probar que confiar.
¿Y honestamente? El prompt mismo requiere habilidad. Un junior en mi equipo intentó usar el mismo workflow y obtuvo especificaciones mediocres, porque la restricción y el framing de rol no eran lo suficientemente precisos. La herramienta amplifica a quien la está usando. No es una crítica, solo vale la pena ser realista al respecto.
---
Organizar el Resultado en un Documento Vivo
La especificación que produce Claude no es el artefacto final. Es un insumo.
Mi entregable real a un cliente es un documento Notion que se construye a partir del resultado de Claude pero reorganizado en un formato que tiene sentido para la aprobación. Típicamente:
- Resumen ejecutivo (3-4 oraciones, sin jerga)
- Alcance (qué está incluido, qué está explícitamente excluido)
- Personas de usuario (2-3 máximo, más que eso es ruido en esta etapa)
- Flujos principales (escritos como pasos numerados, no prosa)
- Tabla de características (columnas: característica, MVP o fase 2, esfuerzo aproximado, responsable)
- Preguntas abiertas (cualquier cosa que bloquee una decisión, con una persona nombrada responsable de responderla)
- Riesgos y mitigaciones
Esa sección de preguntas abiertas es algo que empecé a hacer después de un proyecto en 2020 que se torció porque todos asumían que alguien más había resuelto la política de retención de datos. Asignar una persona a cada pregunta abierta significa que no se queda ahí indefinidamente.
El documento de Notion se comparte con el cliente, comenta directamente en él, y hacemos una llamada de 45 minutos para revisarlo. Nada llega a un desarrollador hasta que cada pregunta abierta tenga respuesta.
---
The Actual Time Savings, Honestly Stated
Antes de este flujo, una especificación para un proyecto de mediana complejidad (digamos, un portal de membresía o una tienda de comercio electrónico personalizada) me tomaba un día y medio. Escribir, dudar, reescribir. Enviar un borrador a un colega, obtener comentarios, incorporarlos.
Ahora es más cerca de dos a tres horas para el borrador asistido por Claude, luego quizás otra hora de edición humana y pulido orientado al cliente. Digamos tres a cuatro horas en total.
Ese no es un ahorro trivial durante un año. En Seahawk entregamos especificaciones en quizás dos o tres proyectos al mes. Incluso con una estimación conservadora, eso son 50-70 horas al año que no paso escribiendo especificaciones desde cero.
Pero la verdadera victoria, honestamente, es la calidad. El análisis adversarial en particular atrapa cosas que hubiera pasado por alto. El surfeo de suposiciones al inicio significa que las llamadas de descubrimiento son más productivas porque estamos discutiendo decisiones reales, no yo intentando llenar vacíos que no había notado.
---
FAQ
¿Este flujo funciona también para herramientas internas o solo para proyectos de clientes?
Sí, y a veces funciona mejor para cosas internas porque conoces al usuario mejor de lo que cualquier brief de cliente puede decirte. Usé esencialmente el mismo proceso cuando estábamos especificando la propia herramienta de seguimiento de tiempo interna de Seahawk el año pasado. La entrada de restricciones fue fácil porque sabía el presupuesto (£0 en gasto externo, un desarrollador, tres semanas) y las personas eran literalmente gente de la oficina.
¿Puede un fundador no técnico usar esto sin un desarrollador?
Hasta cierto punto. Los pasos de surfeo de suposiciones e historias de usuario funcionan bien sin conocimiento técnico. Donde se complica es en el análisis adversarial y la estimación de esfuerzo. Necesitas algo de experiencia para saber cuándo Claude está subestimando la complejidad. Si no eres técnico, haz ese paso con alguien que haya lanzado software antes, aunque sea solo una llamada de una hora.
¿Cómo manejas la información confidencial del cliente cuando usas Claude?
Anonimizo cualquier cosa sensible antes de que vaya a un prompt. Los nombres de clientes se convierten en "[Cliente]", cualquier dato de identificación personal se elimina. También uso Claude a través de la API para cualquier cosa genuinamente sensible, donde aplican los términos de manejo de datos empresariales de Anthropic, en lugar del producto de consumo. Vale la pena leer la política de uso de Anthropic antes de decidir qué es apropiado para tu contexto.
¿La especificación siempre sobrevive el primer contacto con los desarrolladores?
No. Y no debería. La especificación es una función de forzamiento para tener las conversaciones correctas temprano, no un contrato que congela el pensamiento. Lo que les digo a los clientes es: la especificación es una comprensión compartida de lo que estamos construyendo hoy. Cambiará. Lo que hace es hacer que esos cambios sean visibles e intencionales en lugar de accidentales.
---
Una especificación no es un documento. Es un argumento. Estás argumentando que entiendes el problema lo suficientemente bien como para construir algo que valga la pena construir. Claude no hace ese argumento por ti. Pero es un socio de sparring notablemente útil mientras descubres qué realmente quieres decir.
Eso vale la pena dos horas del tiempo de cualquiera.