Discovery y delivery, juntos

Descripción

Cada vez que un equipo escucha "hagamos discovery antes de construir", aparece la misma objeción, casi siempre razonable en la superficie: "¿no nos va a atrasar?". Si el equipo ya tiene un roadmap del trimestre y un ritmo de entrega que sostener, agregar entrevistas, tests y prototipos suena a agregar trabajo encima del trabajo que ya existe. Esta lección responde esa objeción directamente, y la respuesta no es "el discovery vale la pena aunque atrase" — es que, bien organizado, el discovery no atrasa la entrega, porque no compiten por el mismo tiempo.

La idea se llama dual-track: discovery y delivery son dos tipos de trabajo distintos, que corren en paralelo, dentro del mismo equipo, al mismo tiempo — no en secuencia, no como fases separadas. Mientras el equipo prueba la suposición riesgosa de una apuesta nueva, sigue entregando el resto del backlog que ya tiene evidencia detrás. Esta lección muestra, con números, cuánto tiempo se ahorra un equipo que organiza su trabajo así, comparado con uno que trata discovery y delivery como pasos secuenciales.

Conexión con el módulo. La lección 3 mostró el peligro de tratar el discovery como una fase única al inicio (big-bang research). Esta lección completa esa idea desde otro ángulo: el discovery no solo debe ser continuo en el tiempo — también debe correr en paralelo con la entrega, no antes ni en vez de ella. Son dos caras de la misma corrección: el discovery no es una fase que interrumpe el trabajo del equipo, es un tipo de trabajo que convive con el resto, todo el tiempo.

Una analogía: cocinar y poner la mesa al mismo tiempo

Cuando organizas una cena, no cocinas primero de principio a fin y después empiezas a poner la mesa — harías esperar a los invitados mucho más de lo necesario. Cocinas y pones la mesa en paralelo: mientras algo hierve a fuego lento sin necesitar atención constante, tienes las manos libres para poner los platos, los vasos, los cubiertos. Son dos tareas distintas, con ritmos distintos, que un mismo anfitrión puede sostener a la vez sin que ninguna de las dos sufra.

Discovery y delivery funcionan igual dentro de un equipo de producto. Mientras el equipo prueba una suposición riesgosa —una tarea que, como viste en la lección 5, no necesita mucho tiempo de trabajo activo, solo tiempo de calendario para que el test corra—, el resto del equipo sigue entregando funcionalidades que ya tienen su propia evidencia y no están esperando a nadie. Ninguna de las dos tareas exige que la otra se detenga.

Ejemplo trabajado: secuencial contra paralelo, con números reales

Volvemos al test de discover de la lección 5: 9 días calendario para conseguir evidencia sobre la suposición riesgosa de recommendations. Al mismo tiempo, el equipo tiene otro trabajo pendiente en el backlog — por ejemplo, terminar de entregar fasterCheckout y savedPaymentMethods, dos apuestas que ya tienen su propia evidencia y no dependen de nada del test de recomendaciones. La pregunta es: ¿cuánto tiempo total pasa si estas dos cosas se hacen una después de la otra, contra cuánto pasa si corren en paralelo?

// Dos tracks corriendo en paralelo, no en secuencia: mientras el track de
// discovery prueba la suposicion riesgosa de recommendations, el track de
// delivery sigue enviando otras cosas del backlog que ya tienen evidencia real.
function parallelDuration(tracks) {
  return Math.max(...tracks.map((t) => t.calendarDays));
}

const discoveryTrack = { name: 'discovery: probar la suposicion de recommendations', calendarDays: 9 };
const deliveryTrack = { name: 'delivery: shippear fasterCheckout y saved payment methods', calendarDays: 12 };

const sequential = discoveryTrack.calendarDays + deliveryTrack.calendarDays;
const parallel = parallelDuration([discoveryTrack, deliveryTrack]);

console.log('=== Discovery y delivery: secuencial vs en paralelo ===\n');
console.log(discoveryTrack.name + ': ' + discoveryTrack.calendarDays + ' dias');
console.log(deliveryTrack.name + ': ' + deliveryTrack.calendarDays + ' dias');
console.log('\nSi se hacen en secuencia (uno despues del otro): ' + sequential + ' dias.');
console.log('Si corren en dos tracks en paralelo (dual-track): ' + parallel + ' dias.');
console.log('Ahorro: ' + (sequential - parallel) + ' dias -- sin trabajar mas horas, solo en paralelo.');

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== Discovery y delivery: secuencial vs en paralelo ===

discovery: probar la suposicion de recommendations: 9 dias
delivery: shippear fasterCheckout y saved payment methods: 12 dias

Si se hacen en secuencia (uno despues del otro): 21 dias.
Si corren en dos tracks en paralelo (dual-track): 12 dias.
Ahorro: 9 dias -- sin trabajar mas horas, solo en paralelo.

El punto central de parallelDuration() es simple pero fácil de perder de vista en la práctica: cuando dos tareas no dependen una de la otra, el tiempo total no es la suma de sus duraciones — es el máximo de las dos. El equipo no necesita 21 días para hacer ambas cosas; necesita 12, porque mientras el test de discovery corre en calendario (nueve días, la mayoría de los cuales no requieren trabajo activo del equipo — solo esperar a que los 50 usuarios compren o no), el resto del equipo sigue entregando fasterCheckout y savedPaymentMethods sin ninguna interrupción.

Por qué esto no significa "el discovery es gratis"

Fíjate en algo importante que el modelo de hoy simplifica a propósito: parallelDuration asume que discovery y delivery no compiten por las mismas personas al mismo tiempo. Eso es cierto solo si el equipo lo organiza así — alguien tiene que dedicar los 3 person-days del test de discovery (de la lección 5) sin quitárselos por completo al trabajo de delivery. En la práctica, dual-track no significa "discovery no cuesta nada" — significa que su costo, medido en tiempo de calendario, no se suma al de la entrega, aunque su costo en person-days sí exista y haya que planearlo. Por eso la comparación de la lección 5 —costo en personDays— y la de esta lección —tiempo en calendarDays— responden preguntas distintas y complementarias: cuánto trabajo humano cuesta, y cuánto tiempo de calendario toma.

Errores comunes

Tratar dual-track como "dos equipos separados". Qué pasa: al escuchar "dos tracks", alguien entiende que hace falta crear un equipo de discovery separado del equipo de delivery — normalmente un equipo de investigación o UX aislado, que entrega hallazgos "por encima de la pared" al equipo que construye. Por qué pasa: la palabra "tracks" suena a "equipos" o "carriles separados" en el sentido organizacional. Cómo detectarlo: el equipo que hace discovery nunca es el mismo que construye lo que ese discovery valida, y la comunicación entre ambos pasa por documentos formales en vez de conversación directa. Cómo corregirlo: dual-track describe dos tipos de trabajo, no dos equipos — el mismo equipo hace discovery y delivery, a veces las mismas personas en distintos momentos de la semana. Jeff Patton, quien acuñó el término, insiste en esto: "two tracks, not two teams".

Usar "estamos en modo discovery" para justificar detener toda la entrega. Qué pasa: cuando el equipo empieza a validar una apuesta nueva, pausa por completo el resto del trabajo de entrega —incluidas apuestas que ya tienen evidencia y están listas para construirse— con el argumento de "estamos enfocados en discovery esta semana". Por qué pasa: es más simple mentalmente tratar el trabajo como una sola cosa a la vez, y "modo discovery" suena a una fase legítima, parecida al big-bang research de la lección 3, aunque bajo un nombre distinto. Cómo detectarlo: el calendarDays real de un test de discovery termina siendo mucho mayor al estimado, no porque el test en sí tome más tiempo, sino porque todo lo demás se detuvo a esperarlo. Cómo corregirlo: vuelve al ejemplo de hoy — el ahorro de dual-track viene exactamente de no detener el resto del trabajo mientras el discovery corre en paralelo.

Ignorar que discovery sí consume person-days reales. Qué pasa: en la dirección opuesta, un equipo entusiasmado con el ahorro de tiempo de calendario que vio en el ejemplo de hoy concluye que el discovery "no cuesta nada", y deja de planear quién va a dedicarle los personDays reales que necesita (3, según la lección 5). Por qué pasa: el número más llamativo de esta lección es el ahorro en calendarDays, y es fácil generalizar esa gratuidad aparente al costo completo. Cómo detectarlo: nadie está asignado explícitamente a correr el test de discovery — se asume que "va a pasar solo" mientras el resto del equipo sigue con delivery. Cómo corregirlo: recuerda la distinción de esta lección — dual-track ahorra tiempo de calendario, no de trabajo. El costPersonDays de la lección 5 sigue siendo real y sigue necesitando que alguien lo tenga asignado en su semana.

Ejercicios

Ejercicio 1 — Calcula un tercer escenario. Sin ejecutar Node, si el equipo tuviera que correr dos tests de discovery en paralelo con el mismo track de delivery (el de discovery original de 9 días, más uno nuevo de 15 días para otra apuesta, junto al track de delivery de 12 días), ¿cuál sería el parallelDuration de los tres tracks juntos?

Ver solución

parallelDuration = Math.max(9, 15, 12) = 15 días — el track más largo de los tres, sin importar cuántos tracks corran en paralelo. Este ejercicio muestra que el ahorro de dual-track escala bien con más tracks paralelos: agregar un segundo test de discovery no suma su duración a las demás — solo importa si se vuelve, o no, el track más largo del conjunto. La secuencia equivalente (sumar los tres) hubiera dado 9 + 15 + 12 = 36 días — más del doble.

Ejercicio 2 — Identifica el error. Un compañero dice: "Nuestro equipo hace dual-track: tenemos a una diseñadora dedicada 100% a discovery, y al resto del equipo dedicado 100% a delivery, cada quien en su carril". ¿Qué error de esta lección está describiendo, aunque use el vocabulario correcto?

Ver solución

Está describiendo el primer error de esta lección: "dos tracks, dos equipos" — exactamente lo que Jeff Patton advierte que dual-track no significa. Tener una sola persona permanentemente asignada a discovery, separada del resto que solo construye, recrea el problema de la "pared" entre investigación y construcción: los hallazgos de discovery llegan al equipo de delivery de segunda mano, filtrados por una sola persona, en vez de que el equipo completo participe de ambos tipos de trabajo en distintos momentos. El dual-track real permite que cualquiera del equipo, incluyendo quienes construyen, participen en una entrevista o ayuden a diseñar un test — no separa a las personas por track de forma permanente.

Ejercicio 3 — Diseña tu propio dual-track. Para un equipo con un test de discovery de 5 días calendario pendiente y tres tareas de delivery en curso de 4, 6 y 3 días calendario respectivamente, calcula el parallelDuration total y compáralo con el tiempo que tomaría si el equipo insistiera en terminar el discovery antes de empezar cualquier delivery.

Ver solución

En paralelo: parallelDuration = Math.max(5, 4, 6, 3) = 6 días — el equipo termina todo en 6 días, limitado por la tarea de delivery más larga, no por la suma de todo. Si en cambio el equipo insistiera en terminar el discovery primero y solo después empezar el delivery (el patrón secuencial que esta lección desaconseja), el tiempo sería 5 + max(4, 6, 3) = 5 + 6 = 11 días como mínimo (asumiendo que las tres tareas de delivery sí pueden correr en paralelo entre ellas una vez que empiezan). La diferencia —11 días contra 6— es, otra vez, el mismo tipo de ahorro que viste en el ejemplo trabajado: nada relacionado con trabajar más rápido o más horas, solo con no encadenar tareas que no necesitan estar encadenadas.

Resumen y siguiente paso

En esta lección respondiste la objeción más común contra el discovery —"¿no nos va a atrasar?"— con un modelo concreto: cuando discovery y delivery corren en dos tracks paralelos, el tiempo total no es la suma de ambos, es el máximo de los dos. En el ejemplo de hoy, eso significó 12 días en vez de 21 para completar el test de discovery de recommendations y entregar el resto del backlog planeado. También viste la advertencia necesaria: dual-track ahorra tiempo de calendario, no trabajo — el costPersonDays de correr el discovery sigue siendo real y necesita estar planeado, y "dos tracks" describe dos tipos de trabajo del mismo equipo, no dos equipos separados.

Antes de avanzar deberías poder: explicar, con tus propias palabras, por qué el tiempo de dos tareas independientes es el máximo y no la suma; identificar cuándo alguien está confundiendo "dual-track" con "dos equipos separados"; y distinguir el ahorro en tiempo de calendario del costo real en trabajo humano.

La lección 7 cierra el módulo con la última pieza necesaria antes del proyecto: ahora que sabes por qué el discovery vale la pena, cómo se organiza en el tiempo, y cómo convive con la entrega, hace falta protegerte de la trampa más común de todas — actividades que un equipo llama discovery, sin serlo de verdad.

Recursos

• Jeff Patton, "Dual Track Development" — jpattonassociates.com/dual-track-development. La fuente original del término y de la advertencia central de esta lección: "two tracks, not two teams". En inglés.
• Marty Cagan (SVPG), "Discovery vs. Delivery" — svpg.com/discovery-vs-delivery. Cómo un equipo balancea aprendizaje rápido con entrega de calidad, sin que uno le reste tiempo al otro. En inglés.
• Marty Cagan (SVPG), "Continuous Discovery" — svpg.com/continuous-discovery. El artículo original de 2012 sobre hacer discovery en paralelo con la entrega, en vez de como una fase que la precede. En inglés.