Al terminar esta lección
- Conducir una entrevista de discovery que avance por episodios, fuentes y frecuencia, y reconocer cuándo una pregunta cierra la conversación.
- Clasificar preguntas buenas y malas según qué desbloquean y qué presuponen.
- Detectar en un dossier los hechos inventados, las declaraciones marcadas como verificadas y las decisiones tomadas antes de tiempo.
- Reescribir un dossier para que cada línea tenga categoría, fuente o pregunta abierta con responsable.
Caso DICSA · La primera reunión
Llegás a la oficina de DICSA con el brief de una página y una libreta. El dueño te saluda y dice lo que ya sabés: el equipo vende sin mirar stock y quieren una app móvil. Tenés 40 minutos. Lo que sepas de la empresa va a salir de lo que preguntes, y cada respuesta que consigas tiene que ir a la libreta con su fuente: quién lo dijo, cuándo y si alguien lo puede confirmar.
Esta simulación reproduce esa reunión. Vos conducís; el mentor no tiene un guion que te entregue. Responde lo que preguntás, con la precisión que le pidas, y entrega documentos solo cuando pedís uno y explicás el motivo.
Cómo funciona la entrevista simulada
Antes de empezar, tené en cuenta tres reglas. La primera es que las respuestas son ejemplos ficticios. Sirven para practicar la conducta de conducir una entrevista; no son datos de DICSA y no las podés citar como hechos del caso. La segunda es que el mentor responde solo lo que se pregunta: si preguntás por un tema genérico, recibís una respuesta genérica, y si preguntás por un episodio, recibís un episodio. La tercera es que cada elección tiene consecuencias, que se muestran en el feedback.
Hay tres señales que conviene observar mientras jugás. Una es si pediste episodios con fecha y personas. Otra es si preguntaste por la fuente de cada dato. La tercera es si propusiste una solución antes de que hubiera una decisión que resolver. Las ramas buenas las tienen las tres; las malas suelen perder una de ellas.
Primera reunión en DICSA · entrevista con el mentor
Sos el analista de Eje Z. Tenés 40 minutos y el brief de una página. El mentor interpreta al dueño y a administración: responde lo que preguntás y entrega documentos solo si pedís uno con un motivo. Todas las respuestas son ejemplos ficticios para practicar la conducta; no son datos de DICSA.
Dueño (mentor, ejemplo ficticio)
Gracias por venir. Ya sabés lo principal: el equipo vende sin mirar stock y necesitamos una app. ¿Por dónde empezamos?
¿Qué respondés?
Cuando termines, mirá tu recorrido antes de leer el feedback de cada nodo. Anotá la cantidad de elecciones buenas, aceptables y riesgosas. Después respondé una pregunta: ¿en qué punto dejaste de tener un episodio y empezaste a tener una opinión? Ese punto es el que más te conviene revisar.
Leer las ramas
Las ramas de la simulación siguen un patrón. Las buenas preguntas abren un episodio, piden la fuente de un dato o piden frecuencia y muestra. Las malas tienen tres formas típicas: aceptan una solución antes de tener un problema, juzgan a una persona o piden una cifra sin método.
La comparación siguiente muestra la diferencia en una sola pregunta, que es la que más se repite en discovery.
La misma intención, dos formas de preguntar
"¿Cuál es el problema con el stock?"
Produce una respuesta general, del tipo "a veces no coincide", que no sirve para diseñar nada.
"Contame la última vez que un pedido se confirmó y después no se pudo entregar. ¿Qué pasó en cada paso y de qué registro sacaste esa información?"
Produce un episodio con pasos, personas y fuente. Si la fuente es "de memoria", ya tenés un hallazgo que habrá que contrastar.
La diferencia no está en el tono. La pregunta fuerte pide tres cosas a la vez: un caso concreto, los pasos y la fuente. Cuando el entrevistado no puede responderlas, esa falta es información.
Un segundo patrón es la pregunta por frecuencia. "¿Pasa seguido?" recibe un "sí" o un "no" que depende de quién lo dice. "¿Cuántos casos así recordás el último mes, y cuál fue el más reciente?" recibe una cifra con un período. La primera respuesta es una impresión. La segunda es un punto de partida para contar.
Clasificá las preguntas
Ahora separá preguntas buenas de malas. La clasificación no pide que la pregunta sea perfecta. Pide que puedas decir qué desbloquea o qué presupone. Una pregunta que parece inocente puede cerrar la conversación si ya trae la respuesta adentro.
Preguntas buenas y malas para DICSA
Clasificá cada pregunta según lo que desbloquea o lo que presupone. Buena: abre un episodio, una fuente, una autoridad o una frecuencia. Mala: cierra la conversación, sugiere la solución, juzga a una persona o pide un número sin método.
¿Cuál fue la última vez que una nota de crédito se emitió por un precio que no coincidía con lo acordado? Contame qué pasó desde el pedido hasta la nota.
¿La app tendría que mostrar el stock de los dos depósitos?
¿Ustedes se dan cuenta de que el problema es el stock?
Cuando un vendedor cierra un precio especial, ¿dónde queda escrito? ¿Quién lo puede cambiar después?
¿Cuánto les cuesta el problema por año?
¿Te parece que deberíamos hacer una app?
¿Qué pasó la última vez que uno de los dos depósitos no tenía lo que el vendedor había prometido? ¿Dónde está registrado?
¿Cómo es un día normal de un vendedor, desde que abre el teléfono hasta que confirma un pedido?
Entonces, ¿el error es de los vendedores?
¿Qué documento me podrías prestar? Lo voy a usar para ver cómo se registra un acuerdo de precio, así que necesito saber cuál es el que tiene esa información.
Después de clasificar, comprobá tu criterio con una pregunta de control: ¿cuál de tus respuestas es una opinión que podrías convertir en episodio? Escribila reformulada en la libreta, con el episodio que pedirías.
Dossier con inventos
Un dossier es el registro de discovery. Cada línea tiene que decir de dónde sale. Este dossier fue escrito por un alumno después de la primera reunión: mezcla hechos del brief con afirmaciones que no están en ningún lado. Encontrá las líneas que no podés rastrear, o que tomaron una decisión antes de tiempo.
¿Qué afirmaciones de este dossier no tienen fuente?
Hacé clic en las líneas que afirman algo que no podés rastrear al brief, que marcan como verificado algo que no lo está, o que deciden antes de discovery.
Hay una tentación en estos dossiers: como el texto tiene forma de registro, parece confiable. La forma no alcanza. Un campo "fuente" que dice "dueño" no prueba que el dueño lo haya dicho; un campo "estado" que dice "verificado" no prueba que alguien haya verificado nada.
Ver la lectura del dossier
Lo que hay que hacer con cada línea marcada:
- Línea 9: borrarla de hechos. Si el dato importa, va a preguntas abiertas: "¿Cómo usan los vendedores el celular hoy, y para qué?".
- Línea 14: cambiar el estado a "a verificar con episodios" y registrar qué episodio falta.
- Líneas 21 y 22: pasar el margen a pregunta abierta con responsable (quién define precios y márgenes). No hay fuente que lo respalde.
- Líneas 24 y 25: el 6 de cada 10 no tiene método de medición ni muestra. Si se quiere saber, se diseña la muestra, y la fuente "observación en depósito" se reemplaza por la fecha y el alcance real de lo observado.
- Línea 27: es un resultado esperado de una solución todavía no definida. Se reescribe como hipótesis a contrastar, con el criterio que la haría falsa.
- Líneas 30 y 31: se pasan a una sección de ideas y se marcan como "pedidos de solución" con la pregunta de qué decisión cambian.
Lo que queda después de esta limpieza es poco: cinco hechos, algunas declaraciones y preguntas. Es el dossier honesto. Tiene menos líneas y más valor, porque cada una puede defenderse.
Reescribí el dossier
Reescribí las secciones de declaraciones, supuestos, decisiones y preguntas del dossier anterior. Cada línea debe tener categoría y fuente. Los valores sin fuente pasan a preguntas abiertas con responsable. No agregues datos de DICSA que no estén en el brief. Podés omitir lo que no sirva.
Qué cuesta un dato inventado
Una línea sin fuente en un dossier no se queda quieta. Se usa como base para la línea siguiente. El diagrama muestra cómo una de las líneas inventadas del dossier llega, en pocos pasos, a un test y a un presupuesto. Ningún paso es malicioso; cada uno parece razonable porque el anterior ya "estaba escrito".
Lo que hace peligrosa a esta cadena es que, al llegar a la última caja, nadie vuelve a la primera. El test pasa, el presupuesto está aprobado y el dato original nunca fue verificado. Por eso el control correcto no está al final de la cadena: está en la línea 1. Si una línea del dossier no tiene fuente, no entra al siguiente artefacto.
Esa es la razón por la que los unknowns importan tanto. Un unknown bien escrito detiene la cadena antes de que empiece. Un dato inventado la deja correr.
Leer las ramas en detalle
Más allá de la comparación anterior, la simulación tiene patrones que se repiten. Reconocerlos sirve para la reunión real, donde las respuestas no vienen con etiqueta de bueno o malo.
| Patrón de la rama | Qué consigue | Qué lo rompe |
|---|---|---|
| Pedir un episodio y luego su fuente. | Una cadena de hechos con quién los vio y dónde quedó registrado. | Aceptar el episodio sin preguntar cómo se sabe. Queda una historia, no un hecho. |
| Preguntar frecuencia con período y muestra. | Un número que se puede contar y repetir. | Aceptar "siempre" o "nunca" como respuesta final. Son impresiones que hay que contrastar. |
| Pedir el recorrido paso a paso con roles. | Handoffs, vueltas y puntos donde el pedido se detiene. | Preguntar solo por quién es responsable. El responsable formal casi nunca es quien resuelve el problema. |
| Llevar la opinión a un episodio. | Transformar una creencia en algo que se puede comprobar o descartar. | Discutir la opinión. El entrevistado y vos terminan defendiendo posiciones y no buscando el caso. |
| Pedir un documento con motivo explícito. | Acceso a evidencia, y una relación de confianza sobre el uso de la información. | Pedir "todo lo que tengas". Genera una pila de papeles sin pregunta, y el entrevistado la vive como una auditoría. |
| Proponer una solución después de la decisión, nunca antes. | Una solución con criterio de éxito y un dueño de la decisión. | Responder "¿qué pantallas?" con una lista. La conversación cambia de problema a diseño sin que nadie lo note. |
Un detalle que suele pasar por alto: el mentor de la simulación cambia de tono cuando lo presionás. Con preguntas abiertas responde con detalle. Con preguntas que traen la respuesta adentro responde con cortesía. En una reunión real, el mismo cambio es la señal de que la pregunta fue sugestiva, y de que lo que te dijeron no es confiable todavía.
Cuando la respuesta es "no tengo ese dato"
En la simulación, el mentor responde "no tengo ese dato" o "eso lo maneja otro" cuando la pregunta sale de su conocimiento. En una empresa real, esa respuesta aparece con frecuencia, y es fácil tratarla como un fracaso de la reunión. No lo es. Es una observación con dos lecturas posibles, y las dos son útiles.
La primera lectura es que el dato existe pero está en otra persona o en otro registro. Eso te da un responsable y una fuente que buscar. La segunda es que el dato no existe o no se registra. Eso es más importante todavía: el costo que se menciona no tiene medición, y la primera tarea deja de ser analizar el costo y pasa a ser construir el registro que permita medirlo.
Hay una trampa frecuente en ese momento. Para no quedar mal, el analista responde con una estimación ("más o menos, calculo que") y el interlocutor la acepta. Desde ese momento, la estimación tiene forma de dato y empieza a viajar por el dossier. La respuesta correcta a "no tengo ese dato" es anotarlo como unknown con responsable, decir cuándo volvés y pedir quién puede contestarlo.
Un ejercicio de control: cuando la simulación te responde "no tengo ese dato", volvé a leer tu última pregunta y decidí si pediste un número o un registro. Si pediste un número, la pregunta probablemente necesita reformularse en términos de registro, con período y motivo.
Playback y cierre de la reunión
Antes de irte, devolvés lo que entendiste. El playback no es un resumen para quedar bien. Es la prueba de que entendiste lo que el interlocutor quiso decir, con episodios concretos, para que lo corrija. Si lo que devolvés incluye algo que no te dijeron, el playback lo va a mostrar.
Un playback útil tiene tres partes: los episodios que escuchaste, lo que todavía no entendiste y lo que vas a hacer después con cada cosa. No tiene que incluir ninguna solución ni prometer plazos.
Playback al dueño de DICSA
Escribí el playback de cierre de la primera reunión en cuatro o cinco frases. Usá episodios que hayas escuchado, marcá lo que todavía no entendiste y decí qué vas a pedir o verificar. No prometas ninguna solución ni plazo, y no uses datos que no estén en la libreta.
La minuta de la reunión
Después de cada reunión, la libreta se convierte en una minuta. La minuta es un artefacto de discovery: registra qué se escuchó, de quién y con qué grado de confianza. Sin esa separación, dentro de tres semanas no vas a saber qué dijo el dueño y qué dedujiste vos.
El siguiente formato es una plantilla vacía. Los campos son la estructura que sirve para cualquier empresa; los valores los completás con lo que pasó en la reunión.
reunion:
fecha: AAAA-MM-DD
asistentes_por_rol: []
objetivo_declarado: ""
episodios:
- id: EP-01
que_paso: ""
cuando: ""
quien_lo_vivio: ""
fuente: ""
confianza: confirmado_con_documento | relato_unico | relato_contradicho
hechos_confirmados: []
declaraciones_a_verificar:
- id: DEC-01
de_quien: ""
texto: ""
como_se_verifica: ""
pedidos_de_solucion:
- texto: ""
decision_que_cambia: ""
para_quien: ""
unknowns:
- id: U-01
pregunta: ""
responsable_que_puede_responder: ""
decision_que_bloquea: ""
documentos_pedidos:
- documento: ""
motivo: ""
fecha_pedida: AAAA-MM-DD
proxima_reunion:
objetivo: ""
preguntas_por_episodio: []
Algunas reglas de uso. Un episodio con confianza "relato único" no se convierte en hecho hasta que aparezca otra fuente. Un pedido de solución nunca entra a la lista de requisitos: su campo "decisión que cambia" es obligatorio y, si está vacío, el pedido queda sin alcance. Un unknown sin responsable se considera pendiente, no resuelto. Y los documentos pedidos sin motivo no se registran, porque el brief dice que se entregan cuando se pide con uno.
Si cursás sin mentor ni par, la minuta sigue siendo obligatoria. Lo que cambia es el destino de las preguntas que no podés responder: quedan registradas como pendientes, con la fecha en que las hiciste y el tipo de persona que podría contestarlas. No las completes con lo que creés que respondería el dueño.
Si cursás sin mentor ni par
La simulación reemplaza el rol del mentor solo en parte. Un alumno que cursa de forma autónoma no tiene quien le conteste en vivo, y eso cambia el método, no las reglas. Tres cosas se mantienen. La primera es separar hechos, declaraciones y supuestos en el registro. La segunda es no completar huecos con suposiciones. La tercera es dejar visible lo que no se pudo verificar.
Cuando no hay forma de conseguir una respuesta real, la autoevaluación tiene que decirlo. Escribí en el dossier "pendiente de verificación con DICSA" y no "verificado por autoevaluación". La diferencia es la que la rúbrica de la lección 13.3 va a mirar.
Qué entrega el proyecto final
El proyecto final se evalúa por evidencia. Una simulación como la de esta lección sirve para ensayar la conducta; el proyecto real tiene que producir artefactos que sostengan cada decisión. Esta es la lista de lo que se espera de un proyecto completo en DICSA.
- Discovery: preparación, mapa de stakeholders, episode trace, inventario de evidencia, contradicciones, glosario y unknowns priorizados.
- Definición: objetivos, métricas, frontera IN / OUT / BLOCKED, RN y NFR, y casos de uso principales.
- Sprint de Arquitectura: ASR, dominio, decisiones, integraciones, seguridad, concurrencia y consistencia, despliegue, riesgos, pruebas e implementación incremental.
- Specification Bundle de un slice.
- Implementación con registro de uso de IA, plan previo, diff revisable y decisiones humanas.
- Evidencia de tests y trazabilidad.
- Demo con usuario y defensa técnica y comercial.
Las fases son el recorrido que lo organiza.
Fase A, discovery. Preparás investigación, primera reunión, episode tracing, evidencia, stakeholders, glosario, AS-IS y reglas. Entregás también los unknowns que decidiste no resolver y por qué.
Fase B, especificación. Elegís un slice con valor observable. Definís IN / OUT / BLOCKED, casos de uso principales, RN y NFR, garantías, escenarios y un Specification Bundle compacto.
Fase C, arquitectura. Identificás ASR, dominio, decisiones, persistencia, integraciones, seguridad, consistencia, idempotencia, observabilidad y despliegue, según corresponda. Incluís ADR solo para decisiones que realmente lo merezcan.
Fase D, construcción. Implementás al menos un slice con un agente, bajo el ciclo plan → checkpoints → diff → tests → review. Conservás evidencia de qué decisiones rechazaste o devolviste a la spec.
Fase E, demostración. Ejecutás el plan de pruebas por riesgo, preparás la demo y defendés la solución frente a un panel. El panel tiene que poder pedir trazabilidad desde una decisión de negocio hasta un test.
La rúbrica con la que se evalúa todo esto está en la lección 13.3.
Comprobá tu criterio
DICSA también usa ERP y WhatsApp. ¿Qué demuestra transferencia del aprendizaje?
Errores frecuentes
Síntoma: en la entrevista, las respuestas del mentor te parecen hechos y las copiás en el dossier. Causa: olvidaste que la simulación es un ejercicio y que sus respuestas son ficticias. Corrección: en un caso real, cada respuesta vale solo con su fuente; si no la tenés, va como pregunta abierta.
Síntoma: el dossier tiene "estado: verificado" en líneas que nadie contrastó. Causa: confundiste "lo escuché" con "lo verifiqué". Corrección: el estado "verificado" exige un episodio, un documento o una observación registrados. Sin eso, el estado es "a verificar".
Síntoma: usás el mentor como generador de ideas y terminás con una app diseñada en la primera hora. Causa: aceptaste una solución como si fuera un requisito. Corrección: cada pedido de solución se traduce a la decisión que cambia y a un criterio de éxito antes de discutir pantallas.
Síntoma: el agente que hace de mentor responde con cifras y nombres propios. Causa: le pediste que completara huecos. Corrección: la instrucción tiene que decirle que solo responda con el brief literal y que diga "no tengo ese dato" cuando no lo tenga. Verificá cada cifra antes de usarla.
IA EN ESTA FASE
Qué puede hacer el agente. Simular a un mentor que responde solo con el brief literal, clasificar preguntas con el criterio de esta lección y señalar líneas de un dossier que no tienen fuente.
Qué no debe decidir. Qué hecho es verdadero en DICSA, qué estado merece una declaración y qué decisión de solución conviene. Tampoco debe completar respuestas que no están en el brief, aunque la simulación se vea más fluida si lo hace.
Contexto mínimo útil. El brief literal, las reglas de la simulación y el dossier. No pases el canon de Nexo ni artefactos de otros casos: el agente tiende a reutilizarlos.
Cómo verificar. Cada cifra o nombre que el agente devuelva tiene que estar en el brief. Cada línea marcada como defecto tiene que citar la regla que incumple. Si el agente afirma algo sin fuente, devolvelo como pregunta abierta.
Prompt de trabajo.
Actuá como el dueño de DICSA en una entrevista de discovery. Tu única fuente de información es el
brief de abajo, copiado literal. Respondé solo lo que te pregunten, en una o dos frases.
Si la pregunta pide un dato que no está en el brief, respondé: "No tengo ese dato" y no inventes
cifras, nombres ni episodios. Si la pregunta es genérica, respondé con algo genérico y no
completes con detalles. No hagas recomendaciones técnicas.
BRIEF:
[pegar el brief literal]
Para llevarte
- Pedí episodios con fecha, pasos y personas. Una opinión general no alcanza para decidir nada.
- Preguntá siempre por la fuente de un dato y por quién puede cambiarlo.
- Tratá las cifras sin método como preguntas abiertas, nunca como hechos.
- Un dossier es honesto cuando cada línea tiene categoría, fuente o responsable, no cuando tiene muchas líneas.
- Si un pedido de solución aparece antes de la evidencia, traducilo a la decisión que cambia y dejalo como hipótesis.
¿Cómo valoras el contenido técnico de esta lección?
Tu feedback nos ayuda a mejorar los laboratorios prácticos de Eje Z.