El Problema
Cuando un proyecto de software falla repetidamente a pesar de tener código funcional, el problema rara vez es técnico. Es un gap de traducción entre cómo opera el cliente y cómo el desarrollador interpretó esa operación. Estos son los 4 patrones más comunes:
Procesos No Declarados
El cliente asume que ciertas cosas son obvias. Nunca las menciona porque para él “así se hace siempre.” El desarrollador no pregunta porque no sabe que existen.
Ejemplo: Arqueos de caja que generan saldos negativos legítimos.
Procesos que Mutan
Se acuerda una regla de negocio. Se implementa. El cliente la cambia — a veces sin avisar, a veces verbalmente, a veces porque “siempre quiso otra cosa.”
Ejemplo: Fondos de socios pasan de agregados a separados sin requerimiento formal.
Supuestos Implícitos
El modelo mental del cliente no coincide con el del desarrollador. Ambos creen que están de acuerdo, pero interpretan lo mismo de forma distinta.
Ejemplo: “Deducir de ganancias” para el cliente implica salida real de caja; para el dev es solo descuento en el corte.
Resistencia a Mejoras
La agencia intenta optimizar el proceso del cliente. El cliente lo rechaza porque quiere SU proceso, no uno “mejor.” El resultado: se implementó algo que nadie quiere.
Ejemplo: Se rediseña el flujo de pagos para ser más eficiente, pero el cliente opera con pasos manuales intencionales.
Falla porque traduce mal la realidad del cliente.”
Pre-Sesión — Preparación
Checklist del Facilitador
- Tener el sistema abierto en un dispositivo visible para el cliente (pantalla compartida o presencial)
- Revisar TODOS los procesos core del sistema — saber qué hace cada botón
- Listar los bugs/quejas reportados por el cliente (agrupados por proceso, no por fecha)
- Preparar una lista de procesos a cubrir (mínimo los que tienen bugs activos)
- Tener abierto un documento para captura en vivo (Google Doc, Notion, o el HTML de contratos operativos)
- Grabar la sesión (audio mínimo, video ideal — pedir permiso al cliente)
- Bloquear 2–3 horas sin interrupciones
- Llevar la Matriz de Clasificación impresa o en otra pantalla
Vienes a extraer y documentar.”
Estructura de Tiempo Recomendada
| Bloque | Duración | Actividad |
|---|---|---|
| Apertura | 10 min | Contexto, reglas de la sesión, expectativas |
| Discovery | 90–120 min | Show & Tell proceso por proceso |
| Fantasmas | 20 min | Preguntas de procesos ocultos |
| Cierre | 15 min | Resumen, clasificación, próximos pasos |
Reglas de la Sesión (comunicar al cliente al inicio)
- Toda decisión se documenta en el momento. Si no queda escrito, no existe.
- No hay respuestas incorrectas. Queremos entender cómo opera realmente, no cómo debería operar.
- Si algo cambió desde que lo definimos, es válido. Solo necesitamos saberlo.
- Hoy no se arregla nada. Hoy se entiende. Los fixes vienen después.
Metodología Show & Tell
Para cada proceso, se siguen 3 pasos. El facilitador muestra, el cliente describe, y juntos documentan el delta.
MOSTRAR — “Así funciona hoy”
El facilitador abre el sistema y ejecuta el proceso completo frente al cliente. Sin explicar por qué se hizo así — solo mostrar qué pasa cuando se presiona cada botón.
Objetivo: Que el cliente vea la realidad actual, no lo que cree que existe.
ESCUCHAR — “Descírbeme tu proceso”
El cliente describe paso a paso cómo hace esta operación en su día a día. El facilitador no interrumpe, no corrige, no sugiere. Solo escucha y anota.
Clave: Si el cliente dice algo que contradice lo implementado, no defender el código. Documentar la diferencia.
DOCUMENTAR EL DELTA — “¿Qué no coincide?”
Comparar lo que el sistema hace vs. lo que el cliente espera. Cada diferencia se clasifica inmediatamente usando la Matriz de Clasificación (sección 5).
Regla: Cada delta es un hallazgo. No se juzga, no se prioriza aún. Solo se documenta.
Guión del Facilitador
Estas son las preguntas exactas que se usan en cada proceso. No son sugerencias — son un script. Seguirlo asegura que no se salten pasos críticos.
Apertura del Proceso (repetir para cada uno)
Preguntas Base (después del demo)
Preguntas de Sondeo Profundo
Usar cuando el cliente da respuestas cortas o genéricas. Estas preguntas obligan a pensar en los bordes:
Preguntas Prohibidas (NO hacer durante discovery)
- “¿Pero no habíamos quedado en que...?” — No defender acuerdos previos. Solo documentar la diferencia.
- “Eso es fácil de arreglar” — No prometer soluciones en el momento.
- “Eso no se puede hacer” — No cerrar puertas. Todo se documenta primero.
- “¿Por qué lo cambiaste?” (tono acusatorio) — En vez: “¿Cómo evolucionó esto con el tiempo?”
Matriz de Clasificación en Vivo
Cada hallazgo se clasifica inmediatamente durante la sesión. Esto evita que todo se convierta en una lista amorfa de “cosas por arreglar.”
| Categoría | Significado | Acción | Responsable |
|---|---|---|---|
| BUG | El código no hace lo que se acordó en su momento | Fix técnico sin costo adicional | Agencia |
| GAP | Nunca se habló, nadie lo definió, pero el cliente lo necesita | Definir regla de negocio + evaluar implementación | Ambos |
| MUTACIÓN | Se acordó X, el cliente cambió a Y (con o sin aviso) | Renegociar scope + documentar cambio | Cliente |
| FANTASMA | Proceso que el cliente hace fuera del sistema y nunca mencionó | Evaluar si sistematizar o dejar manual | Ambos |
| MEJORA | El cliente quiere funcionalidad nueva que no estaba en el scope | Cotizar como feature adicional | Cliente |
¿Por qué clasificar en vivo?
- Transparencia: El cliente ve cómo se categoriza cada hallazgo. No hay sorpresas después.
- Responsabilidad compartida: GAPs y MUTACIONES no son “errores de la agencia.” Son descubrimientos conjuntos.
- Priorización natural: Los BUGs se arreglan primero. Las MEJORAS se cotizan. Los FANTASMAS se evalúan.
- Protección de scope: Las MUTACIONES documentadas evitan “pero yo siempre quise esto” meses después.
Cómo comunicar la clasificación al cliente
Si el cliente no está de acuerdo con la clasificación, escuchar su argumento. Si tiene razón, reclasificar. Si no, explicar con calma y dejar la clasificación final pendiente (marcar como “en disputa”).
Protocolo Anti-Mutación
Las decisiones que se toman hoy deben sobrevivir mañana. Este protocolo asegura que cada acuerdo quede documentado, fechado y firmado para que no mute sin registro.
Las 4 Reglas Anti-Mutación
Formato de Decisión en Vivo
Plantilla — Registro de Decisión
Descubrimiento de Procesos Fantasma
Los procesos fantasma son las operaciones que el cliente ejecuta fuera del sistema y que nunca mencionó porque asume que “eso no va en la plataforma.” Son la fuente #1 de bugs inexplicables.
Preguntas de Detección
Hacer estas preguntas AL FINAL de cada proceso, no al inicio. El cliente necesita estar en modo “operación real” para recordar:
Señales de Proceso Fantasma
Si el cliente dice alguna de estas frases, hay un fantasma escondido:
- “Eso lo llevo aparte”
- “Eso no va ahí”
- “Es que eso es diferente”
- “Esas unidades son mías, no del negocio”
- “Eso lo hago yo a mano”
- “Sí, pero aparte de eso también hago...”
Cuando detectes una señal: no la dejes pasar. Seguir con “Cuéntame más sobre eso” hasta que el proceso completo esté documentado.
Formato de Cierre
Resumen de Hallazgos (llenar al final)
Script de Cierre
Los bugs los arreglamos sin costo. Los gaps los implementamos según lo que acordamos hoy. Las mejoras las cotizamos por separado. ¿Te parece bien este plan?
Checklist de Cierre
- Todas las decisiones están documentadas con fecha y responsable
- Todos los hallazgos tienen clasificación (BUG/GAP/MUTACIÓN/FANTASMA/MEJORA)
- Las ambigüedades que quedan abiertas están listadas con responsable de resolver
- Se definió fecha de siguiente revisión/entrega
- El cliente confirmó el resumen y el plan de acción
- Se envió el resumen por escrito al cliente (email/WhatsApp) dentro de 24 horas
Plantilla de Mensaje Post-Sesión
Procesos revisados: [lista]
Hallazgos: [N] total ([X] bugs, [X] gaps, [X] mutaciones, [X] fantasmas, [X] mejoras)
Decisiones confirmadas:
1. [decisión 1]
2. [decisión 2]
Pendientes por definir:
1. [pregunta abierta 1]
Siguiente paso: [acción + fecha]
Si algo de lo que anotamos no coincide con lo que platicamos, avísame antes de que empecemos a implementar. Gracias por tu tiempo.
Plantillas de Captura
Estas plantillas se llenan durante la sesión. Cada hallazgo, cada decisión, cada proceso fantasma tiene su formato para que nada se pierda.