14.1 Playbooks para reunión, contradicciones, review y demo

Al terminar esta lección

• Reconocer qué situación de campo estás viviendo a partir de su disparador, antes de decidir qué hacer.
• Aplicar el playbook correspondiente en orden, sin saltear el registro de evidencia.
• Identificar el atajo que más te tienta en cada situación y explicar por qué no sirve.
• Producir el artefacto de salida que deja trazabilidad: un registro de evidencia, una decisión con autoridad, un desconocido con dueño o un plan de corte.
• Separar una solución pedida por el cliente de la necesidad que la origina.

Cómo usar estos playbooks

Un playbook no es un guion. Es una secuencia corta para cuando estás en una reunión, en el depósito o revisando un diff y no tenés tiempo para reinventar cómo trabajar. Cada uno tiene cuatro partes: el disparador (qué lo activa), los pasos (qué hacés, en orden), el qué NO hacer (el atajo que suele tomarse y sale caro) y el artefacto de salida (lo que queda escrito al terminar).

Lo que une a todos los playbooks es que terminan en algo que otra persona puede leer, discutir y auditar. Si una situación no deja artefacto, la próxima vez que aparezca vas a empezar de cero, y el equipo va a recordar una versión distinta de lo que se decidió.

Usá este árbol para elegir el playbook. Empezá por lo que ves en la situación, no por lo que te gustaría que pasara.

Apéndice A · Playbooks de campo

A.1 Mañana tenés la primera reunión

Qué NO hacer. No diseñes pantallas durante la reunión, aunque el cliente te las pida. No aceptes un "siempre" sin un ejemplo. No prometas una solución ni un plazo. Si el cliente describe la política como si fuera la práctica, pedí ver un caso donde se aplicó.

Artefacto de salida. Una minuta con los episodios revisados, las notas de evidencia (EV) con su tipo y la lista de desconocidos con dueño y fecha.

A.2 El cliente se contradice

Disparador: la misma persona dice dos cosas incompatibles, o un documento del cliente contradice lo que el cliente dijo. Por ejemplo, Marta dice que el precio lo define el ERP, pero la planilla de acuerdos especiales tiene otro precio para el mismo CUIT.

1. No elijas una versión por intuición ni por la que te suena más razonable.
2. Registrá las dos versiones, cada una con su fuente, y mostrá la evidencia concreta: el pedido, la línea, el valor de cada fuente, con fecha.
3. Clasificá la contradicción con los tipos de la lección 2.2, porque cada uno pide una acción distinta: regla condicionada (describen casos distintos: buscá la condición), política deseada vs. práctica (una dice cómo debería ser y la otra cómo es: conservá ambas), cambio de política en el tiempo (fechá cada versión) o dato inconsistente entre fuentes (pedí ambos artefactos y definí la autoridad del dato).
4. Pedí el episodio que la resuelve: un caso real de cada versión, con dueño y fecha.
5. Identificá quién tiene autoridad para resolver esa decisión concreta. Si esa persona decide, registrá la decisión con quién la tomó y con qué autoridad; si todavía nadie puede decidir, dejá un desconocido con dueño.
6. Propagá el cambio a las RN, CU, AC, ADR y pruebas afectadas.

Qué NO hacer. Tomar el dato del ERP "porque es el sistema" sin preguntar si los acuerdos lo sobreescriben. Corregir el documento del cliente delante de todos, o tratarlo como mentira.

Artefacto de salida. Las dos versiones registradas como EV, cada una con su fuente; el tipo de contradicción; el episodio pedido, con dueño y fecha. Una decisión (DEC) con quién la tomó y con qué autoridad, solo si alguien con autoridad para decidir ya lo hizo; mientras tanto, la RN afectada queda provisional o BLOCKED.

A.3 Te piden una solución demasiado pronto

Disparador: "queremos un portal", "¿cuánto tarda una app?", "ya tenemos pensado usar un chatbot". La solución llegó antes que el problema.

Respuesta útil: "Podemos explorar esa alternativa, pero antes necesito confirmar dos cosas que cambian mucho la solución: de dónde sale el precio final y cuándo se reserva el stock. Si eso queda claro, podemos comparar un portal contra opciones más simples con criterios reales."

1. Reconocé el deseo sin rechazarlo: la solución propuesta es un dato sobre lo que el cliente imagina.
2. Pedí el último episodio en el que el problema apareció. Qué pasó, quién lo vio, qué costó.
3. Nombrá los dos o tres unknowns que cambian la solución de verdad.
4. Proponé comparar opciones con criterios, no con gusto.

Qué NO hacer. Fijar plazo, stack o pantallas. Decir "sí, en dos semanas" para cerrar la reunión. Empezar a dibujar la interfaz.

Artefacto de salida. Una hoja de comparación con tres columnas: lo que pide el cliente, la necesidad observada (con su episodio) y los criterios para elegir la solución.

A.4 Stakeholders en conflicto

Disparador: dos personas con autoridad sobre la misma decisión responden de forma incompatible, o una pide algo que otra ya rechazó. En Nexo, Marta (dueña) quiere que el portal confirme pedidos sin esperar, y Sergio (depósito) objeta que el stock físico no coincide con el registro. Ninguno de los dos está mintiendo: ven partes distintas del mismo proceso.

1. Separá posiciones de intereses: qué teme o qué necesita cada uno.
2. Mapeá quién decide qué. El precio, el crédito, el stock físico y el plazo de reserva no tienen la misma autoridad.
3. Registrá ambas posiciones con fuente y fecha, sin declarar una "correcta" todavía.
4. Buscá la decisión más chica que destrabe el siguiente paso: medir el quiebre durante una semana, o confirmar sin reserva firme mientras se valida.
5. Escalá con una pregunta exacta, por escrito, a quien tiene la autoridad.

Qué NO hacer. Decidir a favor de quien habla más fuerte. Promediar reglas incompatibles ("la mitad de cada una"). Hablar de una persona con la otra a espaldas.

Artefacto de salida. Una DEC con autoridad, fecha y alternativa descartada. Si no hay decisión posible todavía, una RN o un desconocido en estado BLOCKED con dueño y fecha de respuesta.

A.5 Dato que no existe

Disparador: "depende", "eso no lo tenemos", o una regla necesita un valor que nadie puede dar. En el caso Nexo, el tiempo de expiración de una reserva y la tolerancia de crédito de los clientes Platino son BLOCKED: si los fijás por intuición, el sistema congela stock o deja vender lo que no existe.

Qué NO hacer. Poner un número razonable ("30 minutos", "un 5%"). Dejar un TODO en el código sin dueño. Hacer que el desarrollador adivine el valor por el nombre de la variable.

Artefacto de salida. Una entrada en el registro de desconocidos (U-xx) con dueño, fecha de respuesta y plan de medición, y un parámetro sin valor definitivo marcado como BLOCKED en la especificación.

A.6 Cambio de alcance

Disparador: "ya que estamos", "sumá también", o una idea nueva que aparece en el medio de una reunión. Se parece a una solicitud pequeña, pero cambia el primer release.

1. Registrá el pedido con fuente: quién lo pidió, en qué contexto y qué objetivo dice que resuelve.
2. Clasificalo como IN, OUT o BLOCKED contra el objetivo del proyecto, no contra lo que es técnicamente interesante.
3. Medí el impacto: qué RN, NFR, slice e integración toca.
4. Llevá el impacto a quien tiene autoridad sobre el alcance (en Nexo, Marta): una decisión de alcance la toma alguien del negocio con autoridad, no vos. Registrá la decisión (DEC) con quién la tomó y con qué autoridad.
5. Actualizá el backlog. Una idea OUT también queda escrita, con su motivo.

Qué NO hacer. Decir "sí, lo vemos". Mover una idea a IN sin DEC porque el dueño la pidió con entusiasmo. Cambiar el alcance en silencio para "no molestar".

Artefacto de salida. Una entrada de backlog con identificador F-xx, clasificación IN, OUT o BLOCKED, objetivo que responde y referencia a la decisión.

A.7 El agente de IA inventa

Disparador: el diff del agente trae una regla, una constante, un estado o un campo que no aparece en ninguna RN, EV o ADR. El caso típico es un descuento de "5% para clientes VIP" que nadie pidió y que el agente deduce del nombre de una tabla.

1. Buscá en el diff reglas, constantes, estados y campos nuevos.
2. Para cada uno, buscá la fuente: ¿hay RN, EV, ADR o caso que lo respalde?
3. Si no hay fuente, no lo aceptes. Eliminalo o márcalo como DESCONOCIDO o BLOCKED.
4. Si el error es conceptual, corregí la especificación antes de tocar el código. Si el error es solo de implementación, corregí el código.
5. Corré los gates focales y revisá que el test cubra el comportamiento nuevo, no solo que pase.

Qué NO hacer. Aceptar el cambio porque los tests pasan: un test escrito después del código puede confirmar la invención. Corregir el test para que coincida con el valor inventado.

Artefacto de salida. Una nota de revisión donde cada elemento nuevo tiene fuente o está marcado como BLOCKED, y un registro de las decisiones que el agente no podía tomar y que tomó una persona.

Prompt de ejemplo para la revisión:

1Revisá el diff adjunto contra RN-01 a RN-09 y los ADR 001 a 006.
2Listá cada regla, constante, estado o campo nuevo que NO aparezca en esos documentos.
3Para cada uno indicá archivo y línea, qué introduce y si toca un punto BLOCKED conocido
4(RN-02, RN-07, cheques pendientes o devoluciones).
5No propongas valores. Si algo parece necesario pero no tiene fuente, marcalo como DESCONOCIDO.

A.8 Revisión rápida de un cambio con IA

1. Releé el objetivo y las RN o NFR que el cambio toca.
2. Revisá el plan y el alcance antes de mirar el código.
3. Ejecutá el diff archivo por archivo, no en bloque.
4. Buscá reglas, constantes y estados nuevos (ver A.7).
5. Ejecutá los gates focales del slice.
6. Si el cambio toca estado, revisá concurrencia, idempotencia y fallos parciales.
7. Actualizá la trazabilidad: RN, AC, prueba y decisión.
8. Mergeá solo con evidencia, no con "se ve bien".

A.9 Deadline

Disparador: una fecha comprometida antes de tener evidencia suficiente. Lo habitual es "para el viernes tiene que estar el piloto".

1. Listá las garantías que no se negocian. En CU-01 son: el precio se calcula en el servidor, no hay pedido confirmado sin decisión de crédito y no hay reservas negativas.
2. Definí el slice mínimo que cumple esas garantías. Un slice por valor completo vale más que varias capas a medio hacer.
3. Escribí explícitamente qué queda OUT y qué queda BLOCKED.
4. Acordá la fecha de la evidencia, no solo la del código.
5. Comunicá el corte por escrito, con las garantías primero.

Qué NO hacer. Recortar garantías para llegar: quitar la idempotencia "por ahora" convierte un reintento en un segundo pedido. Prometer el alcance completo para mantener al cliente contento.

Artefacto de salida. Un plan de corte con las garantías intactas, la lista de OUT y BLOCKED y la fecha en la que se entrega la evidencia.

A.10 Preparar una demo

1. Elegí entre tres y cinco escenarios ligados a objetivos concretos.
2. Usá datos representativos y, si podés, una excepción real.
3. Incluí al menos un fallo o un límite a la vista del público.
4. Mostrá evidencia de estado (qué quedó en la base, qué efectos hubo), no solo la pantalla.
5. Pedí al usuario que intente un caso no guionado.
6. Cerrá con lo aprendido y los próximos desconocidos.

Qué NO hacer. Armar una demo sin fallo para que "no se vea mal". Usar datos sintéticos tan limpios que ningún problema real aparezca.

Artefacto de salida. Un guion con escenarios, el dataset usado y la lista de preguntas de validación que el usuario tiene que contestar.

Practicá: elegí el playbook

Leé cada situación y clasificala en el playbook que corresponde. Hay una respuesta principal por ítem, pero la explicación importa más que la elección.

Para repasar el vocabulario de los playbooks, usá las tarjetas. Dalas vuelta y marcá cuáles sabés de memoria.

Cuando el cliente llega con una solución ya pensada, la tentación es registrarla tal cual. Compará cómo lo dice el cliente con cómo lo registra quien conduce el discovery.

Ahora practicá el playbook de conflicto. Elegí las respuestas y mirá qué pasa con el acuerdo y con la evidencia.

Antes de cerrar, ordenamos los errores más comunes al aplicar estos playbooks.

Errores frecuentes

• Síntoma: la RN tiene un número que nadie mencionó en la reunión. Causa: el analista lo completó para que la regla "cierre". Corrección: marcar la regla como BLOCKED, con dueño, y pedir el número a quien lo tiene.
• Síntoma: la minuta dice "Marta acordó seguir" pero no hay decisión escrita. Causa: se confundió una respuesta cortés con una decisión. Corrección: registrar la DEC con autoridad, fecha y alternativa descartada, o dejar el punto como desconocido.
• Síntoma: un pedido nuevo de último momento ya aparece en IN del backlog. Causa: no se clasificó contra el objetivo del release. Corrección: pasarlo por A.6 antes de tocar el backlog.
• Síntoma: el agente propone una regla y los tests pasan. Causa: el test se escribió a partir de la implementación, no de la fuente. Corrección: buscar la fuente de la regla (A.7) antes de mirar el resultado de los tests.

Para llevarte

• Elegí el playbook por el disparador observable, no por lo que te gustaría hacer.
• Cuando dos personas se contradicen, separá posiciones, mapeá autoridad y pedí la decisión por escrito.
• Un dato que no existe se marca BLOCKED con dueño y fecha. Nunca se reemplaza por un número razonable.
• Recortá alcance antes que garantías. Lo que no entra queda OUT o BLOCKED, escrito.
• Todo playbook termina en un artefacto que otra persona puede auditar. Sin artefacto, no está cerrado.