Trabajar con producto y diseño como un solo equipo
La secuencia clásica —producto define, diseño dibuja, ingeniería construye— produce tres versiones distintas del mismo plan y una discusión al final. Trabajar juntos no es reunirse más: es cambiar en qué momento aparece cada uno.
El modelo por etapas es cómodo de organizar y caro de ejecutar. Producto escribe un documento, diseño lo convierte en pantallas, ingeniería lo construye, y en la última semana alguien descubre que el flujo dibujado requiere tres llamadas a un servicio externo que tarda dos segundos cada una.
Ese descubrimiento estaba disponible el primer día, gratis, si alguien de ingeniería hubiera estado en la conversación. Trabajar como un solo equipo es, sobre todo, eso: adelantar el momento en que aparecen las restricciones.
Cuándo entra cada uno
| Etapa | Producto | Diseño | Ingeniería |
|---|---|---|---|
| Entender el problema | Conduce | Participa: observa usuarios | Participa: aporta lo que muestran los datos y los registros |
| Explorar soluciones | Participa | Conduce | Participa: dice qué es barato y qué es caro, temprano |
| Definir el alcance | Conduce | Participa | Conduce en conjunto: el corte en rebanadas es una decisión técnica y de producto |
| Construir | Disponible para decidir | Disponible para resolver detalles | Conduce |
| Medir y ajustar | Conduce | Participa | Participa: instrumenta y muestra el uso real |
Antes de seguir, predecí
Lo que hace un equipo que funciona así
| Práctica | Qué resuelve | Costo |
|---|---|---|
| Los tres miran juntos a un usuario usando el producto | Elimina la discusión sobre qué necesita la gente: la vieron los tres | Una hora por mes |
| Un canal único del trío, no uno por disciplina | Las decisiones dejan de reconstruirse tres veces | Cero |
| Ingeniería pone precios durante la exploración | El diseño nace dentro de lo posible | Media hora por idea |
| Diseño revisa lo construido antes del release | Los detalles que se pierden en la implementación aparecen a tiempo | Quince minutos por entrega |
| Cortar en rebanadas se decide entre los tres | La primera rebanada tiene sentido para el usuario, no sólo para el código | Una reunión por funcionalidad |
| Los tres ven las métricas después del release | Nadie queda esperando a que otro le cuente si funcionó | Cero |
Las tensiones normales
Un equipo sano no es uno sin tensión: las tres disciplinas optimizan cosas distintas y eso es lo que las hace útiles juntas. Lo que cambia es cómo se resuelven.
| Tensión | Mala resolución | Buena resolución |
|---|---|---|
| Diseño quiere una animación cara | Ingeniería dice que no se puede | Poner el precio y decidir juntos: «dos días; ¿vale más que el filtro por fecha?» |
| Producto quiere más alcance | Ingeniería promete y se atrasa | Mostrar el corte: «entra esto o aquello, no los dos» |
| Ingeniería quiere refactorizar | Se hace a escondidas | Explicarlo en costo de demora: «cada cambio acá cuesta el triple» |
| Diseño pide consistencia, producto pide velocidad | Gana el que insiste más | Acordar qué parte es del sistema de diseño y qué parte puede ser provisoria |
| Aparece un pedido urgente de afuera | Se acepta sin evaluar | Los tres miran qué se corre y avisan juntos |
Cuándo aparece la restricción
El proyecto: un flujo de alta de clientes con validación contra un servicio externo. Ocho semanas.
Lo que preguntan sobre esto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica