Al terminar esta lección
- Separar, en un brief incompleto, hechos, declaraciones, pedidos de solución e hipótesis propias.
- Decidir qué parte del proceso de Nexo se transfiere a DICSA y qué parte no, justificándolo con una señal concreta.
- Redactar un objetivo de discovery en una frase y un primer lote de preguntas por episodio.
- Elegir una técnica de discovery según la señal observada, y explicar en qué caso no alcanza.
13. Graduación: enfrentar una empresa nueva
La evaluación final no pregunta definiciones. Te pone frente a una empresa que no es Nexo y observa si podés ejecutar el proceso sin que un mentor complete los huecos por vos. Esta lección no te da la solución de DICSA. Te da un método para empezar, criterios para decidir qué hacer con cada respuesta que consigas y un mapa para elegir técnicas sin recetas.
13.1 Brief de transferencia · DICSA
DICSA distribuye insumos industriales a talleres y pequeñas fábricas. Tiene 14 vendedores, dos depósitos, una cuenta corriente por cliente y una combinación de ERP, Excel y WhatsApp. El dueño afirma que "el problema es que el equipo vende sin mirar stock" y pide una app móvil. Administración dice que el mayor costo real son notas de crédito por precios y condiciones mal aplicadas. No se entrega información adicional hasta que el estudiante la pida.
El caso está deliberadamente incompleto. El mentor o evaluador responde únicamente a lo que preguntes y entrega documentos cuando los pidas con un motivo. Todo lo que sabés de DICSA está en ese párrafo. Lo que agregues después tiene que venir con fuente: una respuesta, un documento, una observación o una medición.
Antes de tomar ninguna decisión, clasificá cada frase del brief. Es la forma más rápida de ver qué sabés y qué estás asumiendo.
Clasificá cada frase del brief
Elegí la categoría que describe lo que la frase te permite afirmar. Pensá qué evidencia necesitarías para pasarla a otra categoría.
DICSA distribuye insumos industriales a talleres y pequeñas fábricas.
Tiene 14 vendedores y dos depósitos.
El problema es que el equipo vende sin mirar stock.
Necesitamos una app móvil.
El mayor costo real son las notas de crédito por precios y condiciones mal aplicadas.
Probablemente el ERP no esté actualizado con los precios.
Lectura del ejercicio. Las frases del dueño y de administración son declaraciones: describen cómo ven el problema, con la autoridad de quien las dice. Pueden ser exactas, y aun así no son requisitos. Hasta que haya episodios, documentos o mediciones, son hipótesis de trabajo que hay que verificar. La frase sobre la app no dice qué problema resuelve, y tu hipótesis sobre el ERP es un salto que el caso no te autoriza a dar.
13.1.1 Qué se transfiere del proceso y qué no
Lo que tiene que sobrevivir a Nexo es el criterio: qué preguntar primero, cómo separar evidencia de interpretación, cómo registrar lo que no sabés, cuándo cortar el alcance y cómo hacer que cada promesa tenga una prueba. Lo que no se transfiere son los artefactos concretos. Un CU-01 de Nexo nació de un pedido, un crédito y un depósito con reglas específicas. Si lo reutilizás con nombres de DICSA, estás copiando respuestas que nadie te dio.
Copiar Nexo contra transferir criterio
Primera reunión con preguntas de Nexo: "¿Cómo se reserva el stock?" Después armás la lista de RN, CU y ADR del caso anterior y le cambiás los nombres.
Primera reunión con preguntas de episodio: "Contame la última vez que una nota de crédito llegó por algo que se había acordado de palabra." Después dejás que la respuesta decida qué artefacto hace falta. Si ninguno hace falta, no lo hacés.
La tabla separa lo que viaja de lo que se queda en Nexo. Leela con una pregunta en mente: ¿este elemento depende de una señal de DICSA o de algo que pasó en Nexo?
| Elemento del proceso | Se transfiere | No se transfiere |
|---|---|---|
| Separar hecho, declaración, pedido de solución e hipótesis | Siempre. Es la disciplina base de cualquier discovery. | Las categorías ya llenas de Nexo. Cada caso tiene las suyas. |
| Preguntar por episodios concretos | El método: "¿cuál fue la última vez que pasó?". | Las preguntas sobre el pedido 48172 o la pizarra del depósito de Nexo. |
| Identificar la fuente de autoridad de cada dato | La pregunta "¿quién manda sobre este dato?". | La conclusión de que el ERP manda sobre productos y clientes. En DICSA eso hay que averiguarlo. |
| Frontera IN / OUT / BLOCKED | La estructura de la decisión y la obligación de justificar cada exclusión. | El corte del primer release de Nexo. |
| Unknowns con responsable y próximo paso | Siempre. Un unknown sin dueño es una deuda invisible. | La lista de unknowns de Nexo (vencimiento de reserva, sobregiro, cheques). |
| Patrones técnicos: transacciones, outbox, idempotencia | Solo cuando una señal concreta los pide. | La idea de que una integración o un stock siempre requieren outbox o bloqueo. |
| Tests derivados de promesas | El principio: cada promesa necesita un oráculo que diga si se cumplió. | Los casos T01 a T12 de Nexo. |
| Cantidad y nombre de artefactos | La regla de que cada artefacto responde a una decisión. | Las trece entregas del cuaderno y sus títulos. |
Un ejemplo de lo que no conviene transferir. Nexo tiene un problema de carreras por la última unidad, y por eso sus artefactos hablan de reservas, invariantes y transacciones. DICSA no tiene nada de eso dicho en el brief. Si tu primera hipótesis es "hay que reservar stock", estás aplicando un patrón de Nexo sin señal. Podrías tener razón después de investigar, pero hoy no tenés evidencia para decirlo.
La prueba práctica de la transferencia es simple. Si un artefacto de DICSA se parece a uno de Nexo, preguntate si lo necesitás por algo que apareció en DICSA o porque lo hiciste en Nexo. Si es lo segundo, eliminalo o reemplazalo por una pregunta.
13.1.2 Checklist de arranque de discovery
El arranque tiene orden porque cada paso depende del anterior. No podés elegir una técnica si no sabés qué pregunta responde, y no podés preguntar bien si no separaste lo que el brief afirma de lo que solo alguien dijo. Ordená los pasos antes de mirar cualquier solución.
Ordená el arranque de discovery
Usá las flechas para dejar los pasos en el orden en que conviene hacerlos. El orden importa porque cada paso alimenta al siguiente.
- Posición 1 de 7: Listar lo que no se sabe y a quién le corresponde responder cada cosa
- Posición 2 de 7: Elegir la primera técnica según la señal observada
- Posición 3 de 7: Identificar qué documentos o sistemas existen y quién los administra
- Posición 4 de 7: Escribir el objetivo de discovery en una frase, sin mencionar tecnología
- Posición 5 de 7: Separar el brief en hechos, declaraciones, pedidos de solución e hipótesis propias
- Posición 6 de 7: Anotar qué no se va a diseñar todavía, y por qué
- Posición 7 de 7: Preparar preguntas por episodio para la primera conversación
Ese orden es un punto de partida, no una receta. Si la primera conversación muestra que el problema es otro, volvé al paso uno y reclasificá. Eso no es fracasar: es lo que se espera de un discovery.
Usá el checklist como autoevaluación. Marcar una casilla registra lo que vos creés haber hecho. La aprobación, en cambio, requiere que alguien revise tus notas y tus preguntas.
Checklist de arranque (autoevaluación)
Marcá cada ítem cuando lo hayas hecho con tus propios artefactos. El checklist registra tu autoevaluación; la aprobación requiere revisar la evidencia.
Ahora el objetivo. Un objetivo de discovery describe algo que vas a entender antes de decidir. No describe lo que vas a construir.
Objetivo de discovery en una frase
Escribí el objetivo de discovery para DICSA en una frase. Debe decir qué vas a entender antes de decidir algo, sin mencionar app, stock, ERP ni tecnología. Después agregá una segunda frase con el criterio observable que te diría que el objetivo se cumplió.
13.1.3 Banco de preguntas para un brief incompleto
El banco no es un guion. Cada pregunta desbloquea algo distinto: un episodio, una fuente de autoridad, un costo medible o un responsable. Antes de usar una pregunta, decidí qué querés desbloquear con ella. Si no lo sabés, no la hagas todavía.
Las preguntas buenas tienen tres rasgos: piden un episodio o un registro, dejan que la respuesta te sorprenda y no traen la conclusión adentro. Cuando una pregunta sugiere la respuesta, el interlocutor la confirma por cortesía y no te dice nada nuevo.
Episodios y consecuencias
- ¿Cuál fue la última vez que alguien prometió algo que después no se pudo cumplir? ¿Qué pasó en cada paso? Desbloquea la cadena real y el primer episodio para reconstruir.
- ¿Qué decisión cambiaría en la semana si esto estuviera resuelto? ¿Quién la toma hoy? Desbloquea el objetivo y los dueños de decisión.
- ¿Cómo sabe hoy un vendedor si puede prometer una entrega? ¿Qué mira, en qué pantalla o en qué papel? Desbloquea las fuentes que usa cada rol.
Notas de crédito y condiciones
- ¿Qué tipos de nota de crédito emiten, por qué motivo, y cuál es la más frecuente? Desbloquea las categorías del costo.
- De las notas de crédito del último trimestre, ¿cuántas vinieron de un precio pactado que no se cargó y cuántas de una condición que cambió después? Desbloquea las causas y su proporción, con la muestra que se pida.
- ¿Quién autoriza una condición especial y dónde queda escrita? Desbloquea la autoridad y la auditoría.
Autoridad de los datos
- ¿Cuál es la fuente de referencia para el precio? ¿Y para la condición de pago? ¿Y para el saldo de la cuenta corriente? Desbloquea el mapa de autoridad.
- Cuando dos registros no coinciden, ¿cuál se usa y quién decide? Desbloquea las reglas de precedencia y sus excepciones.
Coordinación entre áreas
- ¿Qué pasa entre que el vendedor confirma y que el pedido se prepara? ¿Quién toca el pedido en cada paso? Desbloquea los handoffs.
- Cuando un pedido sale de uno de los dos depósitos, ¿quién decide de cuál? ¿Puede salir de los dos? Desbloquea la regla de depósito.
La app y sus expectativas
- ¿Qué haría cada persona distinto si la app existiera? Pedí la respuesta por separado para vendedor, administración, depósito y dueño. Desbloquea el criterio de éxito.
- ¿Qué cambiaría en un mes si la app funcionara bien? ¿Cómo lo medirían y con qué punto de partida? Desbloquea métricas y línea base.
Documentos y cierre
- ¿Qué documento me podrías prestar? Lo voy a usar para ver cómo se registra un caso como el que describiste, así que necesito saber para qué. Desbloquea la evidencia.
- ¿Qué de lo que te pregunté no sabés? ¿A quién le preguntarías? Desbloquea los unknowns con responsable.
13.1.4 Qué técnica elegir según la señal
Las técnicas de discovery no son un menú para llenar. Cada una responde a una señal. Si la señal no está, la técnica sobra y tu tiempo se va en un artefacto que nadie va a usar. La tabla relaciona lo que observás con la técnica que corresponde, lo que produce y el caso en el que no alcanza.
| Señal observada | Técnica | Qué produce | Cuándo no alcanza |
|---|---|---|---|
| Relato general, sin fechas ni personas ("siempre pasa", "el equipo no mira"). | Episode tracing: reconstruir dos o tres episodios reales con fecha, persona y documento. | Mapa de episodios con sus pasos y fuentes. | Cuando nadie puede confirmar el episodio. Queda como unknown con responsable. |
| Dos personas describen el mismo proceso de forma distinta. | Triangulación: contrastar con documentos y, si se puede, observar el trabajo (shadowing). | Matriz de contradicciones con la versión de cada fuente. | Cuando no hay acceso a documentos ni a observación. La contradicción se registra abierta; no se resuelve eligiendo la versión que más gusta. |
| Un costo se menciona sin número. | Muestreo de registros y análisis exploratorio sobre una exportación, con el criterio de muestra declarado. | Conteo por causa, con tamaño y período de la muestra. | Cuando el registro no existe o no guarda la causa. Entonces el unknown es el registro mismo, y la primera tarea es crearlo o pedirlo. |
| Precios o condiciones con excepciones. | Tabla de decisión: condición, resultado, quién autoriza y fuente. | Reglas con condición y resultado observables. | Cuando la excepción depende de una persona y no hay regla escrita. Se registra como excepción no modelada. |
| Pedido de solución (una app, un sistema, una pantalla). | Rastrear la necesidad: qué decisión cambia, para quién y con qué dato. | Criterio de éxito medible y la decisión que afecta. | Cuando nadie puede decir qué conducta cambiaría con la solución. Entonces todavía no hay alcance que definir. |
| Responsabilidades borrosas entre áreas, pedidos que "se pierden" entre personas. | Mapa de roles y handoffs con carriles por actor. | Quién hace qué y dónde se corta el flujo. | Cuando el problema es de incentivos o cultura. El mapa muestra el síntoma; no lo arregla. |
| Datos de cuenta, saldo o condiciones de cliente que alguien cambia a mano. | Antes de cualquier técnica: fuente de autoridad y auditoría del dato. | Definición de quién puede cambiar el dato y cómo queda registrado. | Cuando no existe política escrita. Va a BLOCKED con responsable y pregunta concreta. |
Ahora la lectura para DICSA. El brief tiene cuatro señales distintas, y cada una pide una técnica distinta.
La primera es "el equipo vende sin mirar stock". Es un relato general sin episodios, así que corresponde reconstruir episodios reales antes de cualquier otra cosa. La segunda es el costo de las notas de crédito por precios y condiciones. Tiene un costo declarado por una fuente, sin número, y menciona condiciones que se aplican mal: pide muestreo y una tabla de decisión. La tercera es el pedido de una app. Es una solución, y la técnica es rastrear qué decisión cambiaría. La cuarta son 14 vendedores, dos depósitos y tres herramientas. Eso sugiere coordinación entre áreas y pide mapa de handoffs.
De las cuatro señales, la segunda es la que más conviene investigar primero, porque combina un costo declarado con un dato que todavía no existe. Eso no prueba que el origen sea el precio ni que el stock no importe. Solo dice que es el lugar donde la evidencia puede aparecer con más rapidez.
La tabla no te dice qué técnica usar en el caso. Te dice qué pregunta te está haciendo la señal. Si dos señales aparecen juntas, empezá por la que tiene dato más cercano a una fuente y tratá la otra como unknown con responsable.
El diagrama muestra el mecanismo que se repite en toda la graduación. El discovery no es lineal: cada respuesta puede abrir un hueco que vuelve a la pregunta.
13.1.5 Lo que todavía no conviene hacer
Hay cinco tentaciones típicas en el primer día. Cada una se siente productiva y adelanta una decisión que la evidencia todavía no permite tomar.
- Dibujar casos de uso antes de tener episodios. Los actores y las relaciones salen de cómo se trabaja, y eso todavía no lo sabés.
- Elegir una base de datos o una arquitectura. Ninguna señal de DICSA pide hoy una decisión técnica de ese nivel.
- Estimar plazo o costo de la app. Sin alcance, cualquier número es una opinión con formato de presupuesto.
- Prometer la app en la primera reunión, aunque sea como "veremos". El cliente la escucha como compromiso.
- Pasar la declaración del dueño a requisito. Un requisito necesita una regla con condición y resultado, y de eso todavía no hay nada.
Vocabulario del método
Glosario del método de transferencia
Frente
Hecho del brief
Errores frecuentes
Síntoma: la lista de requisitos de DICSA tiene 30 puntos y ninguna fuente. Causa: copiaste la estructura de Nexo y llenaste los huecos con suposiciones. Corrección: borrá la lista, volvé a las preguntas por episodio y registrá cada punto nuevo como hecho, declaración o unknown, con su fuente.
Síntoma: el glosario dice que "stock disponible" es lo que muestra el ERP. Causa: asumiste la fuente de autoridad. Corrección: preguntá qué miran los vendedores, qué miran en depósito y cuál de los registros gana cuando no coinciden. Escribí la respuesta con su fuente.
Síntoma: el objetivo de discovery menciona una app. Causa: el pedido de solución se volvió objetivo. Corrección: reformulá el objetivo como algo que vas a entender antes de decidir, y dejá la app como una hipótesis que hay que contrastar con una decisión concreta.
Síntoma: los unknowns aparecen como "TODO técnico" en una lista de tareas. Causa: confundiste una pregunta de negocio con una tarea de desarrollo. Corrección: escribí cada unknown con la pregunta, el responsable que puede contestarla y la decisión que bloquea.
IA EN ESTA FASE
Qué puede hacer el agente. Ordenar las frases del brief en las cuatro categorías, proponer preguntas por episodio a partir de un objetivo que vos escribiste y listar supuestos implícitos en un texto.
Qué no debe decidir. Qué es un hecho, qué técnica corresponde ni cómo se llama una regla. Tampoco debe completar respuestas del dueño, aunque el texto sea verosímil.
Contexto mínimo útil. El brief literal, tu objetivo de discovery y las preguntas que ya hiciste. No le pases el canon de Nexo: el objetivo es que no lo use como modelo.
Cómo verificar. Cada frase que el agente marque como hecho tiene que citar el brief. Cada pregunta tiene que poder hacerse en una reunión real. Si aparece "DICSA tiene X" sin fuente, devolvelo como declaración a verificar.
Prompt de trabajo.
Tenés el brief de DICSA, copiado literal abajo. Solo podés afirmar como hecho lo que esté
en ese texto. Para cada frase: (1) clasificala como hecho del brief, declaración a verificar,
pedido de solución o hipótesis; (2) si es hipótesis, escribí la pregunta que la verificaría.
No propongas tecnología, nombres de reglas ni artefactos. Si algo falta, decí "falta" y no
lo completes.
BRIEF:
[pegar el brief literal]
Para llevarte
- Separá siempre hechos, declaraciones, pedidos de solución e hipótesis propias antes de preguntar.
- Transferí el criterio de Nexo, no sus artefactos. Si un elemento viene de Nexo y no de una señal de DICSA, sacalo.
- Empezá por episodios concretos, con fecha y persona. Las opiniones generales no alcanzan para diseñar nada.
- Elegí la técnica según la señal observada, y escribí en qué caso no alcanza.
- Registrá cada cosa que no sabés con responsable y decisión que bloquea. No la rellenes con suposiciones.
Última escena de Nexo · Lo que el proyecto deja detrás
Semanas después del primer release, Nexo puede explicar por qué un pedido quedó pendiente, quién autorizó una excepción y qué precio se aplicó. Los reintentos no duplican pedidos y las carreras de última unidad están cubiertas. Sigue existiendo trabajo pendiente: discrepancias físicas, sustituciones y procesos fiscales. El éxito no fue "digitalizar toda la empresa", sino construir un núcleo confiable y un mapa explícito de lo que todavía falta.
El alumno debería poder mirar hacia atrás y señalar cómo cambió la comprensión. El brief inicial hablaba de un portal. El sistema terminado existe porque descubrimos reglas, autoridades, invariantes y límites. Esa diferencia es el verdadero producto del recorrido.
¿Cómo valoras el contenido técnico de esta lección?
Tu feedback nos ayuda a mejorar los laboratorios prácticos de Eje Z.