Al terminar esta lección
- Clasificar una frase del cliente como hecho, declaración, regla, hipótesis, desconocido o decisión, y justificar la etiqueta.
- Reescribir el pedido de una solución ("necesitamos un portal") como una descripción observable del problema.
- Detectar en un borrador técnico las decisiones de negocio que se colaron sin evidencia.
- Registrar un desconocido con su decisión afectada, su fuente posible y lo que bloquea.
- Usar un agente de IA para ordenar notas sin dejar que promueva una hipótesis a regla.
1. Llegó un cliente. Todavía no diseñes
La velocidad temprana suele ser engañosa. Diseñar una solución sobre un negocio incomprendido no acelera el proyecto: adelanta el momento en que vas a descubrir que estabas construyendo la cosa equivocada.
La razón es económica. Un error de comprensión cuesta casi nada mientras vive en una pregunta o en una nota, y cuesta cada vez más a medida que otras cosas se apoyan en él: un modelo de datos, un contrato de API, un conjunto de tests que lo certifican, un script de migración, un cliente que ya lo usa.
Esta lección enseña el vocabulario y los hábitos para quedarte a la izquierda de ese diagrama el mayor tiempo posible, sin caer en el extremo opuesto: el análisis infinito.
1.1 La primera decisión profesional es qué no afirmar todavía
Abrir el editor demasiado pronto es un síntoma. El problema real aparece antes: alguien toma una decisión sobre el negocio sin saber si es verdadera. Puede ser una tabla diseñada a partir de una pantalla imaginada, un estado inventado porque "suena lógico", una regla de crédito copiada de otro cliente o un endpoint que fuerza una granularidad que todavía no entendemos. La forma de trabajo de Eje Z intenta mover el costo de equivocarse hacia artefactos baratos de cambiar: preguntas, modelos, tablas de reglas, casos de uso y pruebas.
Por eso "el código es consecuencia" no significa que exista una etapa interminable de documentación. Significa que cada decisión costosa debe tener una justificación más barata que el código que depende de ella. Si una decisión puede validarse con una pregunta al usuario, no se la descubre después de una migración. Si una regla puede expresarse con ejemplos, no se espera a que un cliente la rompa en producción.
En una PyME, la información rara vez llega como una especificación. Llega como frases de dueños, hábitos de operadores, planillas heredadas, mensajes de WhatsApp, estados del ERP, excepciones conocidas por una sola persona y decisiones que nadie considera "reglas" porque llevan años haciéndose de memoria. Tu trabajo inicial es convertir ese ruido en conocimiento con distintos niveles de confianza.
Cómo se ve una decisión que se coló
Imaginá que leíste el brief de Nexo un viernes a la tarde y, con la mejor intención, dejaste listo el borrador de la tabla de pedidos para el lunes. Nada de lo que escribiste es disparatado. Todo suena razonable. Ese es el problema.
Decisiones de negocio que se colaron en un DDL
Este borrador se escribió después de leer solo el brief. Hacé clic en las líneas que contienen una decisión de negocio que nadie confirmó, no en las que son simple infraestructura.
Cinco líneas, cinco apuestas silenciosas. Si el lunes alguien construye una pantalla sobre ese DDL, las apuestas se vuelven contratos. Cuando aparezca el primer pedido de un cliente de contado, o el primer pedido que espera una autorización durante la tarde, o un cliente que compra por WhatsApp aunque exista la web, vas a pagar el costo de cada una a la vez.
La alternativa no es un DDL "más cuidadoso". Es no escribirlo todavía y dejar en su lugar un registro de lo que habría que saber para escribirlo.
1.2 Hecho, declaración, regla, hipótesis, desconocido y decisión
Para trabajar con confianza variable necesitás un lenguaje común. Estas seis etiquetas no son burocracia: son la manera de que dos personas (o una persona y un agente) lean la misma frase y coincidan en cuánto se puede apoyar sobre ella.
| Etiqueta | Cómo reconocerla | Qué permite hacer |
|---|---|---|
| HECHO | Lo observaste en un sistema, documento, registro o conducta verificable. | Puede sostener una conclusión acotada, siempre conservando fuente y fecha. |
| DECLARACIÓN | Una persona afirma algo sobre el proceso. | Abre una línea de investigación. Puede ser correcta, incompleta o idealizada. |
| REGLA | Condición de negocio confirmada con resultado y autoridad. | Puede convertirse en contrato, criterio de aceptación y test. |
| HIPÓTESIS | Interpretación provisional útil para investigar. | Permite diseñar preguntas o prototipos, no imponer comportamiento. |
| DESCONOCIDO | Dato que necesitamos y todavía no tenemos. | Bloquea únicamente las decisiones que dependen de él. |
| DECISIÓN | Elección de alcance, análisis, diseño o política, con quién la tomó y con qué autoridad. | Debe registrar por qué existe, quién la tomó, qué evidencia la habilita y qué consecuencias trae. |
La disciplina parece pequeña, pero cambia la conversación. "El ERP tiene el stock" es una declaración. "En el pedido 48172, el ERP mostraba 8 unidades de AX-442 en CBA, 6 estaban reservadas a mano en la pizarra para pedidos ya impresos y todavía no preparados, y el pedido pedía 3: al picker le faltó una" es un hecho (es un adelanto: ese pedido lo vas a reconstruir en la reunión 1, en el módulo 2). "El sistema nuevo debe reservar stock al confirmar" todavía no es una regla, a menos que el negocio haya definido qué significa confirmar, en qué fuente se reserva y qué ocurre si el pedido no termina.
Cada etiqueta, con su ejemplo y su contraejemplo
Entender una etiqueta es poder decir cuándo una frase no la merece. Estos son los errores de rotulado más comunes entre devs con experiencia.
HECHO. Es una observación con fuente y fecha: un pedido real, una captura del ERP, una planilla entregada. El contraejemplo típico es tratar como hecho algo que alguien te contó con total seguridad. "El stock del ERP siempre está desfasado" suena a hecho, pero es una declaración hasta que tengas dos o tres casos concretos para contrastar. Un hecho tiene además un alcance limitado: que el pedido 48172 tuviera un faltante no prueba que el 40 por ciento de los pedidos lo tenga.
DECLARACIÓN. Es lo que una persona dice sobre el proceso. No es "mentira", y tampoco es un hecho: está formulada desde un lugar, con una memoria y un interés. La dueña dice "el ERP ya tiene los productos y los precios"; un vendedor dice "si es cliente de años lo dejamos pasar". Ambas son declaraciones valiosas, y la segunda contradice parte de lo que se espera de la primera. Declarar no es lo mismo que decidir: puede ser el relato idealizado de cómo debería funcionar.
REGLA. Exige cuatro cosas: una condición, un resultado, una autoridad que la confirma y una frontera ejemplificada. "El cliente no puede pasarse del límite" es una intención. "Un cliente estándar no confirma un pedido si saldo más total supera el límite; si es igual, pasa; con un centavo más, queda bloqueado, y lo confirma administración" es una regla porque se puede convertir en test sin interpretar nada. Más adelante en el curso, Nexo va a tener reglas así; hoy no tiene ninguna, y está bien.
HIPÓTESIS. Es una conjetura que te permite formular preguntas. Para ser útil tiene que poder ser falsa: "una reserva con expiración evitaría que dos vendedores prometan la misma unidad" se puede contrastar con episodios concretos. "El sistema debería ser intuitivo" no se puede refutar con nada que observes. Y una hipótesis nunca se usa para imponer comportamiento: sirve para decidir qué preguntar o qué prototipo mostrar.
DESCONOCIDO. Es un dato que necesitás y no tenés. Su disciplina consiste en bloquear solo lo que depende de él. Un desconocido bien escrito dice qué decisión frena; uno mal escrito es una queja ("falta información sobre crédito").
DECISIÓN. Es una elección de alcance, análisis, diseño o política, registrada con quién la tomó y con qué autoridad. Las de análisis y diseño te pertenecen a vos y al equipo: ni el cliente ni el agente las toman por vos. Las de alcance y política de negocio las toma alguien del negocio con autoridad, y vos las registrás. Una decisión sin evidencia que la habilite es una apuesta; está permitido apostar, pero hay que escribirlo.
Cómo cambia la confianza
Las etiquetas no son categorías fijas: una frase puede ascender. Lo que casi nunca ocurre (y es el atajo más peligroso) es el salto directo de declaración a regla.
Cada flecha del diagrama es trabajo concreto. Pasar de DECLARACIÓN a HECHO es pedir un pedido real, abrir una planilla o mirar el estante. Pasar de HECHO a REGLA es el trabajo de los módulos 3 y 4. Si te encontrás saltando una flecha, lo normal es que esté entrando una invención.
Rotulá cada frase
Elegí la etiqueta que mejor describe el estatus de cada frase en este momento del proyecto. Algunas frases cambiarían de etiqueta con más evidencia.
«El ERP ya tiene los productos y los precios.» (mensaje de la dueña)
En el pedido 48172 (adelanto del módulo 2), el ERP mostraba 8 unidades de AX-442, 6 estaban marcadas a mano en la pizarra de depósito como reservadas y el picker informó que faltaba una para completarlo.
«Si es cliente de años lo dejamos pasar y después arreglamos.» (un vendedor)
Una reserva con expiración evitaría que dos vendedores prometan la misma unidad.
¿Cuánto tiempo puede esperar una reserva mientras se autoriza un exceso de crédito?
En una orden de muestra figuran dos columnas de precio: lista 4.200 y acordado 3.950.
El primer slice será registrar un pedido con precio, crédito y reserva; el portal para clientes queda para después.
Tras revisar tres pedidos reales con administración: un cliente estándar no confirma si saldo más total supera el límite; si es igual, pasa.
«Los vendedores pierden tiempo copiando pedidos de WhatsApp.» (la dueña)
El registro de evidencia como artefacto
Las etiquetas son útiles solo si quedan escritas. El formato más simple que escala es un archivo estructurado con una entrada por afirmación. Este es el que vas a usar durante todo el módulo, con las afirmaciones del brief:
# Cada entrada apunta a una fuente. Nada entra sin fuente ni fecha.
- id: AF-01
tipo: DECLARACIÓN
texto: "El ERP ya tiene los productos y los precios."
fuente: { tipo: mensaje, ref: "00-brief/brief-original.md", autor: "Marta (dueña)" }
fecha: 2026-10-12
confianza: baja # una persona afirma algo sobre un sistema; no lo vimos
pregunta_que_abre: "¿Los precios que cobra cada cliente salen del ERP o de otra fuente?"
decisiones_afectadas: [autoridad-de-datos, integracion]
- id: AF-02
tipo: DECLARACIÓN
texto: "El stock nunca coincide del todo."
fuente: { tipo: mensaje, ref: "00-brief/brief-original.md", autor: "Marta (dueña)" }
fecha: 2026-10-12
confianza: baja
pregunta_que_abre: "¿Entre qué fuentes no coincide, de cuánto y en qué momento del pedido se nota?"
decisiones_afectadas: [reserva, modelo-de-stock]
- id: AF-03
tipo: HIPÓTESIS
texto: "Una reserva con expiración evitaría que dos vendedores prometan la misma unidad."
fuente: { tipo: analista, ref: "02-incertidumbre/plan-investigacion.yaml" }
fecha: 2026-10-12
se_refuta_si: "No encontramos ningún caso de unidad prometida dos veces en los últimos pedidos."
confianza: baja
Tres cosas para notar. Primero, tipo nunca es REGLA en esta etapa. Segundo, la hipótesis no pretende ser verdadera: incluye el campo se_refuta_si, que es lo que la vuelve útil. Tercero, decisiones_afectadas conecta cada entrada con lo que realmente importa: sin esa conexión, el registro es un diario.
Qué hacés cuando llega una frase nueva del cliente
Ordená los pasos desde la llegada de la frase hasta decidir si bloquea tu trabajo. Usá las flechas para mover cada paso.
- Posición 1 de 6: Conectarla con la decisión que podría cambiar si resultara falsa.
- Posición 2 de 6: Decidir si bloquea algo hoy o si puede esperar a la próxima reunión.
- Posición 3 de 6: Copiar la frase literal, con autor, fecha y canal por el que llegó.
- Posición 4 de 6: Escribir la pregunta que la contrastaría con un episodio, un documento o un sistema.
- Posición 5 de 6: Separar la frase en afirmaciones atómicas (si dice dos cosas, son dos entradas).
- Posición 6 de 6: Rotular cada afirmación: ¿HECHO, DECLARACIÓN, HIPÓTESIS o DESCONOCIDO?
1.3 El contrato de un slice
Un slice es la unidad mínima que puede atravesar todo el proceso y producir valor observable. No es "hacer backend" o "hacer la pantalla de pedidos". Un slice típico es "registrar un pedido mayorista con validación de crédito y reserva de stock". Ese objetivo cruza reglas, interacción, dominio, persistencia y pruebas. Trabajar por slice fuerza a verificar integración temprano y permite que la especificación viaje con una pieza coherente de comportamiento.
Trabajar por slices evita dos errores opuestos. El primero es intentar especificar todo el producto antes de construir nada. El segundo es implementar tickets desconectados que nunca demuestran un resultado de negocio. En Nexo, un buen primer slice podría ser "registrar un pedido mayorista válido, calcular el precio autorizado, evaluar crédito y reservar stock sin sobreventa". Es suficientemente pequeño para revisar y suficientemente completo para revelar integraciones, reglas y riesgos reales.
Dividir el trabajo por capas o por slices
Tickets: «crear tablas de pedidos», «armar la API REST», «hacer la pantalla de carga». Cada uno se puede cerrar sin saber si el conjunto sirve. A las tres semanas hay una base, una API y una pantalla, y nadie puede mostrar un pedido que se confirme respetando crédito y stock. Los desconocidos aparecen todos juntos, en la integración.
Un único objetivo observable: «un pedido mayorista válido se registra con precio autorizado, crédito evaluado y stock reservado». Cruza todas las capas, pero con el mínimo de cada una. A los pocos días se puede mostrar algo, y los desconocidos (precio, crédito, reserva) aparecen uno por uno, mientras todavía es barato resolverlos.
Un slice, en esta etapa, también se puede escribir como un contrato de investigación: qué se quiere demostrar, qué cruza, qué lo bloquea. Es un artefacto chico que alinea al equipo y al agente sobre qué se está tratando de entender.
slice: registrar-pedido-mayorista-valido
objetivo: >
Registrar un pedido mayorista válido con precio autorizado, crédito evaluado
y stock reservado sin sobreventa.
valor_observable: >
Un pedido que depósito puede preparar sin que vuelva a ventas por precio,
crédito o disponibilidad.
cruza: [precio, credito, reserva, estados-del-pedido, auditoria]
no_incluye: [portal-para-clientes, recomendaciones, facturacion-fiscal]
estado: candidato # todavía es una decisión provisional, no un compromiso
desconocidos_que_lo_bloquean:
- U-01 # qué significa "estar bien de cuenta"
- U-03 # quién autoriza un exceso y cómo queda registrado
- U-04 # cuándo se reserva y por cuánto tiempo
Fijate en estado: candidato. Elegir un slice en el primer día es una decisión de alcance, y las decisiones de alcance con poca evidencia se marcan como provisionales. Los códigos U-nn son los desconocidos que armás en la lección 1.2.
Qué puede hacer el agente: convertir un brief comercial en una lista de incógnitas; clasificar notas provisoriamente; proponer preguntas de contraste; detectar palabras vagas como "siempre", "rápido" o "cliente especial".
Qué no debe decidir: declarar que una frase del cliente es una regla confirmada; elegir el alcance; decidir que hace falta un portal; completar valores faltantes con una "suposición razonable".
Contexto mínimo útil: brief original, lista de fuentes, etiquetas permitidas y una instrucción explícita de no convertir hipótesis en requisitos.
Cómo verificar: cada ítem producido por el agente vuelve a una fuente humana o documental. Si no tiene fuente, queda como pregunta o hipótesis.
Prompt de trabajo:
Rol: revisor de discovery. No proponés software.
Contexto adjunto:
- 00-brief/brief-original.md (mensaje literal de la dueña)
- Etiquetas permitidas: HECHO, DECLARACIÓN, HIPÓTESIS, DESCONOCIDO.
Tarea: para cada afirmación del brief
1. Separala en afirmaciones atómicas.
2. Rotulala con una sola etiqueta y explicá en una línea por qué.
3. Para cada DECLARACIÓN, escribí qué evidencia faltaría para elevarla a HECHO
y una pregunta concreta que pediría un episodio, no una opinión.
4. Marcá las palabras vagas ("nunca", "demasiado", "compren solos").
Reglas: no inventes reglas, valores ni plazos. Si falta información, escribí
DESCONOCIDO. No uses la etiqueta REGLA.
Cómo revisar lo que devuelve el agente
Un agente bien instruido devuelve algo parecido a esto. Mirá con ojo de revisor, porque la mayoría de los problemas están en detalles que suenan razonables:
| Afirmación | Etiqueta | Por qué | Pregunta |
|---|---|---|---|
| El stock nunca coincide del todo | DECLARACIÓN | Descripción general sin ejemplos | ¿Podemos ver un pedido reciente donde el ERP y el estante difirieron? |
| El ERP tiene los productos y precios | HECHO | Es un sistema ya instalado | ¿Qué campos de precio expone? |
| Los clientes quieren comprar solos | HIPÓTESIS | Interpretación del deseo de la dueña | ¿Qué clientes lo pidieron y cuándo? |
La segunda fila está mal rotulada: que el ERP esté instalado es un hecho, pero lo que afirma el brief ("tiene los productos y los precios") es una declaración hasta que lo contrastes. Es el error más frecuente de los agentes y de los devs apurados: confundir la existencia del sistema con la verdad de lo que se dice de él. La tercera fila es más sutil: "los clientes quieren comprar solos" es una hipótesis válida, pero quedó sin se_refuta_si, así que todavía no sirve para investigar.
Regla práctica de revisión: para cada fila, escribí al lado de qué archivo de 01-evidencia/ sale. Si no podés, la fila vuelve a ser una pregunta.
1.4 Qué significa realmente “entender el problema”
En un proyecto real no existe un momento mágico en el que el cliente entrega “los requerimientos”. Lo que llega son síntomas, pedidos de solución, restricciones heredadas, ejemplos incompletos y palabras que cada área usa con un significado diferente. Entender el problema consiste en transformar ese material en afirmaciones que puedan ser discutidas y verificadas. El trabajo del analista no es completar silenciosamente los huecos, sino hacerlos visibles y decidir cuáles bloquean el próximo paso.
Una buena forma de comprobar si todavía estamos demasiado cerca de la solución es intentar describir el problema sin mencionar pantallas, frameworks ni módulos.
Describir la solución o describir el problema
«Necesitan un portal.»
Nombra un artefacto. No dice qué pasa hoy, quién lo sufre ni cómo sabríamos si mejoró. Cierra el espacio de soluciones antes de investigar.
«Los vendedores reconstruyen manualmente pedidos que llegan por varios canales, y parte de la decisión de crédito depende de información que no está en el ERP.»
Describe una situación que se puede investigar, deja abiertas varias soluciones y permite medir si el software futuro mejora algo.
Esta diferencia parece semántica hasta que se paga el costo de equivocarse. Si asumimos portal, podemos diseñar autenticación, catálogo y carrito durante semanas sin haber descubierto que la mayor demora ocurre después de recibir el pedido, cuando alguien reconcilia precio, crédito y stock físico. El problema no era capturar el pedido. El problema era decidir si podía confirmarse con información distribuida entre personas y sistemas.
El mismo cuidado, aplicado a las preguntas
Lo que vale para las afirmaciones vale para las preguntas. Una pregunta de opinión invita a un relato idealizado; una pregunta de episodio fuerza a reconstruir lo que pasó, y de ahí salen los datos, las herramientas y las excepciones.
Pregunta de opinión o pregunta de episodio
«¿Cómo manejan el crédito?»
«¿Los descuentos son complicados?»
«¿Les gustaría que el sistema autorizara solo?»
Respuestas esperables: una política ideal, un «depende» o un sí complaciente. No dejan fuente ni dato verificable.
«Abramos el último pedido que se pasó del límite: ¿qué hizo cada persona, en qué orden y con qué herramienta?»
«En este pedido figura lista 4.200 y acordado 3.950: ¿qué acuerdo lo explica y dónde está escrito?»
«La última vez que dejaron pasar a un cliente, ¿qué pasó después?»
Respuestas esperables: un caso con fechas, personas y documentos. Dejan evidencia y suelen revelar la excepción.
Del pedido de una solución al problema observable
La dueña dice «queremos una web para que los clientes compren solos». Reescribí esa frase como una descripción del problema que no mencione pantallas, portales ni tecnología, y que deje abierta más de una solución posible.
1.5 La incertidumbre también se diseña
En Eje Z no buscamos eliminar toda incertidumbre antes de avanzar. Eso produciría análisis interminable. Buscamos saber qué incertidumbre existe, qué decisión afecta y cuánto cuesta equivocarse. Un DESCONOCIDO sobre el texto de un botón rara vez bloquea arquitectura. Un DESCONOCIDO sobre quién puede autorizar un sobregiro sí puede cambiar permisos, auditoría, estados y pruebas. La disciplina consiste en conectar cada incógnita con su impacto.
Para cada desconocido importante conviene registrar cuatro cosas: qué necesitamos saber, por qué importa, quién podría aportar evidencia y qué parte del trabajo queda bloqueada hasta resolverlo. Esto convierte “nos falta información” en una lista operativa. También evita el hábito peligroso de llamar “supuesto” a una decisión que en realidad estamos tomando por comodidad.
- id: U-03
que_necesitamos_saber: "Quién puede autorizar que un cliente se pase del límite y cómo queda registrado."
por_que_importa: "Define permisos, estados del pedido, auditoría y qué prueba habría que escribir."
quien_puede_aportar: ["administración/crédito", "dirección"]
evidencia_que_lo_resolvería: "Los dos últimos pedidos que se autorizaron, con el mensaje o documento de la autorización."
bloquea: ["diseño de permisos", "estados del pedido", "criterios de auditoría"]
no_bloquea: ["catálogo", "texto de la pantalla de carga"]
costo_de_equivocarse: alto # toca dinero y trazabilidad
El campo no_bloquea es el más subestimado. Escribirlo te obliga a decir qué sí se puede avanzar mientras tanto, y esa es la diferencia entre un plan y una lista de quejas.
Señal de senioridad: poder decir “esto todavía no lo sé, y por esta razón no necesito saberlo hoy” es tan importante como detectar lo que sí bloquea. El objetivo no es documentación exhaustiva. Es control explícito del riesgo de interpretación.
Vocabulario de la lección
Frente
HECHO
Nexo B2B · Primera grieta en el brief
Marta, la dueña de Nexo, había resumido el proyecto como “queremos que los clientes hagan pedidos solos y dejen de escribir por WhatsApp”. Durante la conversación previa a la reunión, sin embargo, agrega una frase que cambia la investigación: “Igual los vendedores siempre tienen que mirar si el cliente está bien de cuenta”. No sabemos qué significa “estar bien”, dónde se consulta ni si es condición para todos los pedidos.
La reacción apresurada sería agregar una validación de crédito al portal. La reacción profesional es abrir preguntas: ¿el límite es un monto fijo?, ¿depende de la categoría?, ¿el saldo se calcula en tiempo real?, ¿hay cheques pendientes?, ¿quién puede autorizar una excepción?, ¿la autorización queda registrada?, ¿hay clientes de contado que no deberían pasar por ese flujo? Ninguna de estas preguntas busca diseñar la pantalla. Buscan descubrir la decisión que hoy toma la empresa.
Un vendedor, por mensaje, dice algo distinto: “Si es cliente de años lo dejamos pasar y después arreglamos”. Esta declaración no invalida lo dicho por Marta ni confirma una política de sobregiro. Produce una contradicción útil. Ahora sabemos que la regla declarada y la conducta operativa pueden diferir.
Así queda el registro después de esa conversación. Observá cómo la contradicción se preserva en lugar de resolverse:
- id: AF-04
tipo: DECLARACIÓN
texto: "Los vendedores siempre tienen que mirar si el cliente está bien de cuenta."
fuente: { tipo: conversacion, autor: "Marta (dueña)" }
fecha: 2026-10-12
pregunta_que_abre: "¿Qué significa «estar bien»? ¿Dónde se consulta y es condición para todos los pedidos?"
decisiones_afectadas: [credito, alcance-del-primer-slice]
- id: AF-05
tipo: DECLARACIÓN
texto: "Si es cliente de años lo dejamos pasar y después arreglamos."
fuente: { tipo: mensaje, autor: "vendedor (sin nombre)" }
fecha: 2026-10-13
tension_con: AF-04
pregunta_que_abre: "¿Cuál fue la última vez que se dejó pasar a un cliente? ¿Quién lo permitió y cómo se «arregló» después?"
decisiones_afectadas: [credito, autorizaciones, auditoria]
El primer resultado de Nexo, entonces, no es un backlog. Es una carpeta con evidencia parcial: objetivo comercial, actores candidatos, dos declaraciones en tensión y una lista de preguntas que decidirá el alcance del primer slice. El alumno debería sentir cierta incomodidad. Esa incomodidad es información: todavía sería irresponsable elegir la solución.
El vendedor dice «si es cliente de años lo dejamos pasar y después arreglamos», y la dueña dijo que el vendedor «siempre» mira si el cliente está bien de cuenta. ¿Cómo lo registrás?
Errores frecuentes
- Síntoma: el registro de evidencia tiene reglas redactadas en tiempo imperativo ("el sistema debe...") el primer día. Causa: una declaración se escribió con el formato de un requisito. Corrección: reescribila como DECLARACIÓN con autor y fecha, y agregá la pregunta que pediría un episodio.
- Síntoma: un DDL, un endpoint o un mockup aparecen antes de que exista un solo desconocido registrado. Causa: se diseñó para sentirse productivo. Corrección: guardalo en una carpeta de bocetos, listá cada decisión que contiene y convertí cada una en una pregunta.
- Síntoma: todo está rotulado como HECHO porque "lo dijo el dueño". Causa: se confunde la autoridad de quien habla con la verificabilidad de lo dicho. Corrección: HECHO exige una observación; la autoridad sirve para confirmar una REGLA, no para convertir una declaración en observación.
- Síntoma: hay veinte desconocidos y ninguno dice qué bloquea. Causa: se registró incertidumbre como queja. Corrección: cada desconocido lleva la decisión que frena y la que no frena (
bloqueayno_bloquea). - Síntoma: el agente devolvió "reglas de negocio" prolijas y las pegaste en el documento. Causa: se trató su salida como fuente. Corrección: todo lo que produce un agente entra como PROPUESTA; vuelve a una fuente humana o documental o queda como hipótesis.
- Síntoma: las preguntas empiezan con "¿cómo manejan...?" y las respuestas son políticas ideales. Causa: preguntas de opinión. Corrección: pedí el último caso concreto y reconstruilo paso a paso.
Para llevarte
- Antes de diseñar, rotulá: HECHO, DECLARACIÓN, REGLA, HIPÓTESIS, DESCONOCIDO o DECISIÓN. Cada etiqueta dice cuánto se puede apoyar sobre una frase.
- Una afirmación asciende con trabajo concreto (un pedido real, una planilla, un episodio); saltar de declaración a regla es donde entran las invenciones.
- Un desconocido bien escrito dice qué necesitamos saber, por qué importa, quién lo puede aportar y qué decisiones bloquea y cuáles no.
- Describí el problema sin mencionar pantallas ni tecnología; si no podés, todavía estás pegado a la solución.
- Preferí preguntas de episodio a preguntas de opinión: dejan evidencia y suelen revelar la excepción.
- Un slice se elige por el resultado de negocio que demuestra; mientras falte evidencia, es un candidato, no un compromiso.
- El agente ordena y propone; no rotula con autoridad, no completa valores y no decide alcance.
¿Cómo valoras el contenido técnico de esta lección?
Tu feedback nos ayuda a mejorar los laboratorios prácticos de Eje Z.