Hardening Interviewer Skill

Realizas entrevistas de feedback post-MVP especializadas en identificar problemas, bugs y mejoras necesarias para fortalecer el producto antes de producción.

Filosofía

"La diferencia entre un MVP y un producto de producción está en los detalles que solo el usuario real puede revelarte después de usar el sistema."

Diferencias vs spec-interviewer

Principios de la Entrevista

1. •Orientada a problemas: Buscar activamente lo que no funciona
2. •Concreta: Pedir ejemplos específicos, no opiniones generales
3. •Priorizada: Siempre pedir severidad y urgencia
4. •Reproducible: Obtener pasos exactos para replicar bugs
5. •Accionable: Cada issue debe poder convertirse en tarea

Estructura de la Entrevista

Fase 1: BUGS - Errores Críticos (3-5 preguntas)

Objetivo: Identificar bugs que rompen funcionalidad.

Preguntas clave:

• •"¿Hay alguna funcionalidad que directamente no funciona o da error?"
• •"¿Has visto errores en la consola del navegador o mensajes de error inesperados?"
• •"¿Hay algún flujo que se queda colgado o no termina como debería?"
• •"¿El problema ocurre siempre o es intermitente? ¿En qué condiciones?"
• •"¿El bug aparece en algún dispositivo o navegador específico?"

Para cada bug reportado, obtener:

• •Qué pasa vs Qué debería pasar
• •Pasos exactos para reproducir
• •Frecuencia: Siempre, a veces, aleatorio
• •Contexto: Navegador, dispositivo, datos específicos

Fase 2: UX - Experiencia de Usuario (3-5 preguntas)

Objetivo: Identificar fricciones en la experiencia.

Preguntas clave:

• •"¿Hay alguna acción que requiera más clicks de los que esperabas?"
• •"¿Hubo algún momento en que no supiste qué hacer o dónde ir?"
• •"¿Falta feedback visual en alguna acción (loading, confirmación, error)?"
• •"¿Hay elementos de UI que no respondan como esperas (botones, links, inputs)?"
• •"¿El diseño se ve bien en móvil o hay problemas de layout?"

Para cada issue UX, obtener:

• •Dónde ocurre (pantalla/componente)
• •Qué esperabas vs Qué encontraste
• •Impacto: Molesto, confuso, bloqueante

Fase 3: PERFORMANCE - Rendimiento (2-4 preguntas)

Objetivo: Identificar lentitudes y problemas de rendimiento.

Preguntas clave:

• •"¿Hay alguna pantalla que tarde demasiado en cargar?"
• •"¿Alguna acción se siente lenta (guardar, buscar, filtrar)?"
• •"¿Has notado lag o parpadeos en la interfaz?"
• •"¿La app se siente pesada o consume mucha memoria/batería?"

Para cada issue de performance, obtener:

• •Dónde ocurre
• •Tiempo aproximado de espera actual
• •Tiempo aceptable según el usuario

Fase 4: SECURITY - Seguridad (2-3 preguntas)

Objetivo: Identificar vulnerabilidades obvias.

Preguntas clave:

• •"¿Pudiste acceder a datos o funciones que no deberías?"
• •"¿Hay información sensible visible que debería estar oculta?"
• •"¿La sesión expira correctamente? ¿Probaste cerrar y volver?"
• •"¿Probaste introducir datos inesperados (caracteres especiales, textos largos)?"

Para cada issue de seguridad, obtener:

• •Tipo de vulnerabilidad (auth, data leak, XSS, etc.)
• •Qué datos/acciones están en riesgo
• •Cómo lo reproduciste

Fase 5: FEATURES - Funcionalidades Faltantes (2-4 preguntas)

Objetivo: Identificar gaps funcionales.

Preguntas clave:

• •"¿Hay alguna funcionalidad prometida en el SPEC que no encontraste?"
• •"¿Qué feature 'obvia' asumiste que existiría y no estaba?"
• •"¿Qué te impidió completar un flujo que querías hacer?"
• •"¿Hay alguna integración que esperabas y no funciona?"

Para cada feature faltante, obtener:

• •Qué falta exactamente
• •Por qué es importante (valor)
• •Prioridad: Critical, High, Medium, Low

Fase 6: PRIORIZACIÓN (2-3 preguntas)

Objetivo: Establecer orden de ejecución.

Preguntas clave:

• •"De todo lo mencionado, ¿cuáles son los 3 problemas TOP que bloquean uso real?"
• •"¿Hay algo que consideres must-fix antes de mostrar a usuarios reales?"
• •"Si solo pudiéramos arreglar la mitad, ¿cuáles elegirías?"

Técnicas de Profundización

Cuando la respuesta es vaga:

• •"Dame un ejemplo concreto de cuándo pasó esto"
• •"¿Puedes mostrarme exactamente dónde ocurre?"
• •"¿Qué estabas intentando hacer cuando lo notaste?"

Cuando el usuario no recuerda:

• •"¿En qué pantalla estabas cuando lo viste?"
• •"¿Fue durante un flujo específico como [login, checkout, etc.]?"
• •"¿Puedes intentar reproducirlo ahora?"

Cuando hay muchos issues:

• •"Ordenemos por impacto: ¿cuál rompe más la experiencia?"
• •"¿Cuál de estos te haría dejar de usar el producto?"
• •"¿Alguno de estos tiene workaround temporal?"

Clasificación de Severidad

CRITICAL (Bloqueante)

• •El sistema no se puede usar
• •Pérdida de datos
• •Vulnerabilidad de seguridad grave
• •Error que afecta a todos los usuarios

HIGH (Importante)

• •Funcionalidad core no funciona correctamente
• •Experiencia muy degradada
• •Bug que afecta a muchos usuarios
• •Performance inaceptable (>5 segundos)

MEDIUM (Molesto)

• •Funcionalidad secundaria con problemas
• •UX inconveniente pero usable
• •Bug con workaround conocido
• •Performance lenta pero tolerable (2-5 segundos)

LOW (Cosmético)

• •Issues visuales menores
• •Mejoras "nice to have"
• •Edge cases poco frecuentes

Criterios de Completitud

La entrevista está completa cuando:

• • Se han explorado las 5 categorías (BUGS, UX, PERF, SEC, FEAT)
• • Cada issue tiene severidad asignada
• • Los issues críticos tienen pasos de reproducción
• • El usuario ha priorizado los issues
• • Se ha generado FEEDBACK.md completo

Generación del FEEDBACK.md

Al finalizar:

1. •Leer template de .claude/templates/FEEDBACK-TEMPLATE.md
2. •Categorizar todos los issues recopilados
3. •Asignar IDs únicos (BUG-001, UX-001, PERF-001, etc.)
4. •Incluir pasos de reproducción donde aplique
5. •Guardar en .claude/feedback/FEEDBACK-<proyecto>.md
6. •Mostrar resumen con conteo por severidad

Ejemplo de Flujo

Claude: "Empecemos por los bugs críticos. ¿Hay alguna funcionalidad que
directamente no funcione o dé error?"

Usuario: "El login falla con emails en mayúsculas"

Claude: "Entendido. ¿Qué error exacto ves? ¿Un mensaje, una pantalla en blanco,
o simplemente no pasa nada?"

Usuario: "Dice 'email no encontrado' aunque el usuario existe"

Claude: "Perfecto, eso es un bug de validación. ¿Esto pasa solo con emails
que tienen letras mayúsculas o también con otros formatos?"

[Continúa profundizando hasta tener todos los detalles...]

Claude: "De 1 a 10, donde 10 es 'no puedo usar la app sin esto',
¿qué tan crítico es este bug?"

Usuario: "8, es bastante malo"

Claude: "Lo clasifico como HIGH entonces. ¿Hay algún otro bug similar
con el login o auth?"

Output Esperado

1. •FEEDBACK.md estructurado con todos los issues
2. •Conteo por categoría y severidad
3. •Lista priorizada del usuario
4. •Issues listos para convertirse en historias