El sistema para controlar el alcance sin que el cliente se sienta malentendido
Uso interno · HIXION 2026Sección 01
El scope creep no es un problema de disciplina — es un problema de diseño de sistemas. Cuando nos llega el scope creep, la reacción instintiva es culpar al cliente de pedir de más. Pero eso es un diagnóstico incorrecto.
El cliente no pide cosas de más por mala fe: solo entiende qué quiere cuando ve la solución parcialmente construida. Es una ley del software. El cerebro humano no puede especificar completamente lo que necesita antes de verlo.
El scope creep sucede porque vendemos sustantivos vagos ("módulo de nutrición") sin límites claros, en vez de historias concretas con bordes definidos. El cliente llena los bordes vacíos con su imaginación.
La buena noticia: si el problema es de diseño de sistemas, la solución también es de diseño de sistemas. No necesitamos más disciplina ni conversaciones incómodas. Necesitamos contratos, fórmulas y flujos que conviertan el scope creep en lo que en realidad es:
Sección 02
Cada modelo resuelve el scope creep de una manera diferente. No son excluyentes.
Modelo 01
El contrato define N slots, no features específicas. El cliente decide cuáles llenar. Si quiere cambiar una feature → la intercambia por otra del mismo slot. Si quiere agregar una feature extra → compra un slot adicional.
Sin devoluciones. Sin horas negociadas. Sin ambigüedad.
¿Por qué funciona? El cliente siente que tiene control (elige qué va en sus slots), pero el contrato siempre tiene bordes fijos.
Modelo 02
El proyecto se entrega al precio acordado, sin fondo de mejoras. Al cerrar el proyecto, se firma un retainer mensual a precio fijo = N horas de mejoras continuas + atención a bugs.
Cada entrega se convierte en ingreso recurrente. El cliente sabe que sus ideas "de después" tienen un canal oficial.
¿Por qué funciona? Elimina la ansiedad del cliente de "ahora o nunca" — sabe que el canal de mejoras siempre está abierto.
Modelo 03
El contrato incluye 3 rondas de revisión de alcance predefinidas. Cada ronda adicional tiene un precio fijo establecido desde el inicio.
Simple, transparente, predecible. Como "3 citas incluidas en el plan dental — cita adicional cuesta $X".
¿Por qué funciona? El cliente sabe exactamente qué incluye su contrato y cuánto cuesta pedir más. Sin sorpresas para ningún lado.
Sección 03
El problema de raíz: vendemos sustantivos en vez de verbos. "Módulo de nutrición" es un sustantivo sin bordes — el scope es infinito. Una user story concreta tiene bordes.
"Módulo de nutrición"
Historia + visualización + límites + criterios de aceptación.
Fórmula completa de una feature
FEATURE: [Nombre descriptivo] MÓDULO: [Módulo padre] HISTORIA: Como [nutriólogo / paciente / admin], puedo [acción específica y concreta], para [beneficio claro]. VISUALIZACIÓN: El [rol] ve [componente: lista / calendario / tarjeta / modal] con los campos: [campo1, campo2, campo3]. Acciones disponibles: [crear / editar / eliminar / ver]. LÍMITES EXPLÍCITOS: Fuera de alcance en esta versión: — [lo que NO hace] — [lo que vendrá en Fase 2] CRITERIO DE ACEPTACIÓN: ✓ El [rol] puede [acción] y el sistema [resultado]. ✓ Si [caso de error], el sistema muestra [comportamiento].
Ejemplo real (GR Wellness)
FEATURE: Asignación de plan semanal MÓDULO: Nutrición HISTORIA: Como nutriólogo, puedo crear un plan semanal asignando alimentos de una biblioteca a días específicos de la semana, para estructurar la dieta de mi paciente. VISUALIZACIÓN: El nutriólogo ve un calendario semanal (7 columnas) con los campos: día, tiempo de comida (desayuno/comida/cena), alimento, porción. Acciones: agregar alimento, quitar alimento, duplicar día. LÍMITES EXPLÍCITOS: — No incluye 3 variantes de menú (normal/descanso/actividad) → Fase 2. — No incluye asignación automática por IA → Fase 2. CRITERIO DE ACEPTACIÓN: ✓ El nutriólogo puede asignar ≥1 alimento a cualquier día de la semana. ✓ El paciente puede ver su plan del día en su perfil.
Por qué importan los límites explícitos
La sección LÍMITES EXPLÍCITOS es la más importante del formato. Le dice al cliente exactamente qué NO hace esta versión — y ya le está abriendo la puerta a Fase 2 con lenguaje positivo, no de rechazo.
Sección 04
El error clásico es decirle "no" al cliente cuando pide algo fuera de scope. Eso crea fricción, frustración y sensación de que HIXION no quiere ayudar.
La respuesta correcta nunca es "no" — es "lo documentamos para Fase 2". El Feature Bank es el repositorio oficial de esas peticiones.
La transformación clave
El scope creep deja de ser un problema de control para convertirse en un pipeline de ventas futuras. Cada "no" se convierte en una cotización de Fase 2.
Flujo de respuesta al scope creep
Cliente pide X → "Interesante, ¿qué problema resuelve X para ti?" → "Eso no estaba en el alcance original, pero tiene sentido." → "Lo documentamos en el Feature Bank." → "Al terminar Fase 1, te presento cotización de Fase 2 con X incluido."
El flujo logra cuatro cosas a la vez:
Sección 05
Cuando llega una petición fuera de scope, hay un patrón de tres pasos que funciona sistemáticamente: Valida → Contextualiza → Redirige.
Reconocer la petición sin comprometerse con ella.
"Entiendo perfectamente lo que describes, y tiene mucho sentido."
Anclar la conversación al scope definido, sin confrontar.
"En el alcance actual definimos que el módulo X hace [Y específico]. Esto que describes va más allá de eso."
Ofrecer el canal correcto: Feature Bank → Fase 2.
"Lo documento ahora mismo para la Fase 2 y al terminar te presento la propuesta. ¿Procedemos con la entrega actual?"
El cliente llega con capturas de pantalla de un competidor diciendo "¿podemos hacer algo así?". Es tentador decir que sí en el momento.
Respuesta modelo:
Por qué preguntar "¿qué feature específica?"
El cliente rara vez quiere todo lo que muestra la captura. Suele haber una funcionalidad puntual que le llamó la atención. Al hacer la pregunta, reducís el scope de la petición y ya empezás a documentarla correctamente para el Feature Bank.
Sección 06
El estatuto es el documento que firma el cliente al inicio del proyecto. Es la fuente de verdad para cualquier conversación de scope. Su formato determina qué tan fácil o difícil es defender el scope más adelante.
Cada módulo del estatuto debe seguir esta estructura:
Formato de módulo en estatuto
## MÓDULO: [Nombre del módulo] ### Feature 1: [Nombre] **Historia:** Como [rol], puedo [acción] para [beneficio]. **UI:** [descripción de la vista/componente y campos visibles] **Límites:** No incluye [X], [Y]. **Aceptación:** ✓ [criterio], ✓ [criterio]. ### Feature 2: [Nombre] **Historia:** Como [rol], puedo [acción] para [beneficio]. **UI:** [descripción de la vista/componente y campos visibles] **Límites:** No incluye [X], [Y]. **Aceptación:** ✓ [criterio], ✓ [criterio]. ### Fuera de alcance (Fase 2): - [Feature A — documentada en Feature Bank] - [Feature B — documentada en Feature Bank]
Las tres propiedades críticas de un estatuto bien formado:
El estatuto como herramienta de ventas
Un estatuto bien estructurado no solo protege a HIXION — también impresiona al cliente. Demuestra que sabemos exactamente qué vamos a construir. La precisión genera confianza antes de que empiece el desarrollo.
Los seis componentes de Scope Defense trabajan juntos:
Sección 07
10-15 reuniones sin estructura = discovery reactivo. El cliente llega a cada sesión con lo que se le ocurrió esa semana. Tú reaccionas. Nunca termina.
2 sesiones estructuradas con el protocolo correcto reemplazan 15 reuniones sin metodología. El cliente siente que lo escuchas mejor. Tú sales con scope real y firme.
Para proyectos grandes: 2 sesiones de 1 hora. Para proyectos simples (landing, etc.): 1 sesión de 90 min.
Análisis Operativo — 30 min
Pregunta de apertura: "Cuéntame un día típico de trabajo en tu empresa, desde que llegas hasta que sales."
De ahí extraes: roles, acciones, dolores. Esos son tus módulos naturales. No preguntes qué quieren — pregunta qué hacen.
Mapa de Roles — 15 min
"¿Quiénes van a usar el sistema? ¿Qué tiene que poder hacer cada uno?"
Cada rol = columna. Sus necesidades = módulos. Ejemplo: Admin → Dashboard + Finanzas. Supervisor → Operativo. Conductor → Perfil propio.
Workshop por Módulo — 60 min
Para cada módulo, 4 preguntas fijas:
Priorización — 15 min
"Si solo pudieras elegir 5 cosas para el primer mes, ¿cuáles serían?"
Lo que no elige → Feature Bank → Fase 2. El cliente toma la decisión de scope, no tú. Esto elimina el resentimiento posterior.
Validación de Límites — 15 min
Por cada feature: "Si el sistema hace exactamente esto, ¿sería suficiente para ti?"
Si dice sí → escribes la user story. Si dice "pero también..." → Feature Bank. Nunca negocies en este paso — documenta.
Cuando el cliente no sabe expresar lo que necesita (que es siempre), estas técnicas lo sacan antes de que empiece el desarrollo:
En vez de preguntar qué hacen, vélos trabajar 1-2 horas. Sin hablar. Solo observar y anotar.
Lo que hacen vs. lo que dicen que hacen siempre es diferente. Ahí salen los casos especiales que nunca mencionarían en entrevista. Con la arrendadora, dos horas de shadowing habrían revelado el módulo de conductores completo sin una sola pregunta.
"¿Cuándo algo sale MAL en este proceso? ¿Qué hace el equipo?"
"¿Qué fue lo peor que pasó operativamente el mes pasado?"
Los casos de error revelan más del negocio real que los casos felices. El sistema de alertas de la arrendadora (morosos, vencimientos, mantenimientos) no se habría descubierto preguntando "¿qué quieres ver?" — se descubre preguntando "¿qué es lo que no puede salir mal?"
"¿Qué es lo que NUNCA debería pasar en el sistema?"
Las restricciones que el cliente pone revelan sus prioridades reales y definen los límites del scope. "Nunca que un conductor vea información de otro conductor" → ya tienes el modelo de permisos completo sin haberlo pedido.
Discovery pagado = incentivo correcto
Cuando el discovery es parte incluida en el precio, el cliente no lo valora y lo abrevia. Cuando está cotizado por separado ($8-15k MXN), el cliente llega preparado, con acceso al equipo, y con disposición a profundizar. El costo del discovery se convierte en parte del presupuesto total — y previene el 80% del scope creep posterior.