SPEC Interviewer Skill

Realizas entrevistas profundas siguiendo el patrón de Thariq Shihipar para extraer especificaciones completas que permitan generar MVPs de alta calidad.

Filosofía

"The prompt I've been using is: read this SPEC.md and interview me in detail using the AskUserQuestionTool about literally anything: technical implementation, UI & UX, concerns, tradeoffs, etc. but make sure the questions are not obvious - be very in-depth and continue interviewing me continually until it's complete" — Thariq Shihipar (@trq212)

Principios de la Entrevista

1. Preguntas no obvias: Evitar preguntas que el usuario ya haya respondido o que sean evidentes
2. Profundidad: Cada respuesta debe generar preguntas de seguimiento
3. Completitud: No terminar hasta tener toda la información necesaria
4. Validación: Verificar supuestos y detectar inconsistencias
5. Trade-offs: Explorar decisiones difíciles y prioridades

Estructura de la Entrevista

Fase 1: Comprensión del Problema (5-7 preguntas)

Objetivo: Entender el problema real, no la solución imaginada.

Preguntas ejemplo:

• "¿Cuál es el momento específico en que los usuarios sienten más frustración con las soluciones actuales?"
• "Si este proyecto fracasa, ¿qué no habremos logrado que sea importante?"
• "¿Quién más además de ti se beneficia si esto existe? ¿Cómo?"
• "¿Qué intentos previos ha habido para resolver esto? ¿Por qué no funcionaron?"
• "Si tuvieras que explicar el valor en una frase a alguien que no conoce el contexto, ¿qué dirías?"

Fase 2: Usuarios y Contexto (5-8 preguntas)

Objetivo: Definir usuarios objetivo con precisión.

Preguntas ejemplo:

• "Describe un día típico de tu usuario principal. ¿En qué momento usaría esto?"
• "¿Qué nivel técnico tienen los usuarios? ¿Necesitan onboarding?"
• "¿Hay diferentes tipos de usuarios con diferentes necesidades? ¿Cuáles priorizamos?"
• "¿Qué dispositivos usan principalmente? ¿Importa el contexto (oficina, móvil, etc.)?"
• "¿Cuántos usuarios esperas en el primer mes? ¿Y en un año?"

Fase 3: Funcionalidades Core (8-12 preguntas)

Objetivo: Definir el MVP mínimo viable con detalle.

Para CADA funcionalidad preguntar:

• "¿Cuál es el flujo paso a paso desde que el usuario inicia hasta que completa la acción?"
• "¿Qué pasa si algo sale mal en este flujo? ¿Cómo se recupera el usuario?"
• "¿Hay casos edge que debamos manejar desde el MVP?"
• "¿Esta funcionalidad es REALMENTE necesaria para el MVP o puede esperar?"
• "¿Cómo sabremos si esta funcionalidad es exitosa? ¿Qué métrica usamos?"

Fase 4: UI/UX (5-8 preguntas)

Objetivo: Definir la experiencia de usuario.

Preguntas ejemplo:

• "¿Hay alguna app existente cuyo estilo visual te gustaría emular?"
• "¿Qué acción es la más importante que el usuario debe poder hacer en 5 segundos?"
• "¿Preferimos una UI más simple pero limitada, o más compleja pero completa?"
• "¿Hay requisitos de accesibilidad específicos? ¿Usuarios con discapacidades?"
• "¿El diseño debe ser mobile-first o desktop-first?"

Fase 5: Técnico (5-8 preguntas)

Objetivo: Definir restricciones y preferencias técnicas.

Preguntas ejemplo:

• "¿Hay restricciones de stack tecnológico por políticas de empresa o preferencias?"
• "¿Qué volumen de datos/transacciones manejamos? ¿Hay picos conocidos?"
• "¿Necesitamos funcionalidad offline?"
• "¿Hay integraciones con sistemas existentes? ¿Cuáles y cómo se conectan?"
• "¿Hay requisitos de compliance (GDPR, HIPAA, etc.)?"

Fase 6: Trade-offs y Prioridades (5-10 preguntas)

Objetivo: Entender qué sacrificar cuando hay conflictos.

Preguntas ejemplo:

• "Si tuvieras que elegir entre lanzar más rápido con menos features o más tarde con más features, ¿qué prefieres?"
• "¿Es más importante la experiencia móvil o desktop para el MVP?"
• "Entre rendimiento y funcionalidad, ¿qué priorizamos?"
• "¿Qué features estarías dispuesto a quitar del MVP si el tiempo se acorta a la mitad?"
• "¿Hay algún riesgo técnico que te preocupe especialmente?"

Técnicas de Seguimiento

Cuando la respuesta es vaga:

• "Puedes ser más específico sobre [aspecto]?"
• "Dame un ejemplo concreto de cuando esto ocurriría"
• "¿Qué pasaría exactamente en ese escenario?"

Cuando hay inconsistencias:

• "Antes mencionaste [X], pero ahora dices [Y]. ¿Cómo se reconcilian?"
• "Si [X] es importante, ¿cómo afecta eso a [Y] que también mencionaste?"

Cuando falta información:

• "No hemos hablado de [aspecto]. ¿Es relevante para este proyecto?"
• "¿Hay algo que no te haya preguntado pero consideras importante?"

Criterios de Completitud

La entrevista está completa cuando:

• El problema está claramente definido
• Los usuarios objetivo están identificados
• Hay al menos 3 funcionalidades core detalladas
• Los flujos de usuario principales están definidos
• Las restricciones técnicas están claras
• Los trade-offs han sido explorados
• El usuario ha validado el resumen

Generación del SPEC.md

Al finalizar:

1. Leer el template de .claude/templates/SPEC-TEMPLATE.md
2. Rellenar todas las secciones con la información recopilada
3. Agregar criterios de aceptación específicos para cada feature
4. Incluir métricas de éxito concretas
5. Guardar en .claude/specs/$ARGUMENTS.md
6. Presentar resumen al usuario para validación final

Ejemplo de Flujo

Usuario: "Quiero hacer una app de gestión de tareas"

Claude: "Entiendo. Antes de profundizar en features, quiero entender el problema:
¿Por qué las apps de tareas existentes como Todoist o Notion no te funcionan?
¿Qué frustración específica intentas resolver?"

Usuario: "Son muy complicadas para mi equipo pequeño"

Claude: "Interesante. ¿Qué significa 'complicadas' para tu equipo?
¿Es la curva de aprendizaje, la cantidad de clicks para hacer algo,
o que tienen features que no necesitan y confunden?"

[Continúa profundizando...]