Capítulo 16: On-site Customer y feedback loop
Capítulo 16: On-site Customer y feedback loop
Jueves de la tercera semana. Ana ha estado sentada con el equipo todos los días desde el inicio. Hoy, una conversación casual revela cuánto impacto tiene su presencia constante. El equipo descubre que el On-site Customer no es un lujo: es la práctica que más acelera el desarrollo.
Anterior: Sustainable Pace | Siguiente: Retrospectiva profunda
La pregunta de las 10:15
Diego está en pair con Elena. Están trabajando en la story de confirmación de movimiento que pidieron los stakeholders.
Diego (Dev): “Elena, ¿la confirmación debería ser un diálogo modal o una notificación?”
Elena (Dev): “No sé. Depende de lo que prefiera el usuario.”
En un proyecto normal, escribirían un comentario en un ticket de Jira, esperarían a que el PO lo viera (quizás mañana), y mientras tanto harían una suposición. Pero Ana está a tres metros de distancia.
Diego (Dev): “Ana, pregunta rápida. ¿La confirmación de mover tarjeta debería ser un diálogo que bloquee todo o una barra que aparece abajo diciendo ‘tarjeta movida, deshacer’?”
Ana (PO): “La barra de deshacer. Los diálogos modales interrumpen el flujo. Lo que quiero es que si alguien mueve algo por error, pueda deshacerlo rápido. No que tenga que confirmar cada movimiento.”
Diego (Dev): “Perfecto. Eso es más simple además.”
Elena (Dev): “Resuelto en treinta segundos.”
El contraste con el pasado
Después de esa interacción, Elena comparte una historia.
Elena (Dev): “En mi proyecto anterior, el product owner estaba en otra ciudad. Teníamos reunión con él los martes por la tarde. Una vez tuve una duda sobre cómo debía comportarse una pantalla. Le envié un mensaje el miércoles. Me respondió el viernes. Mientras tanto, hice una suposición. Resultó que era incorrecta. Perdí tres días de trabajo.”
Diego (Dev): “Tres días por una pregunta.”
Elena (Dev): “Tres días por la distancia entre la pregunta y la respuesta.”
Carlos (TL): “Kent Beck llama a esa distancia ‘feedback delay’. Cuanto mayor es el delay, mayor es el riesgo de construir lo incorrecto. Con Ana aquí, el delay es de treinta segundos.”
Ana levanta la vista de su computadora.
Ana (PO): “Y para mí también es valioso estar aquí. Escucho las discusiones técnicas y entiendo mejor las limitaciones. Cuando Carlos dijo ayer que la concurrencia era compleja, yo ya sabía qué significaba porque lo vi con el bug.”
El stand-up de 10 minutos
Cada mañana a las 9, el equipo tiene un stand-up. No es una ceremonia formal: es una conversación parados frente al tablero.
Carlos (TL): “¿Qué hicimos ayer? ¿Qué hacemos hoy? ¿Hay algo que nos bloquee?”
Hoy el stand-up es particularmente rápido.
Diego (Dev): “Ayer terminé la barra de deshacer movimiento. Hoy empiezo los tests de concurrencia para las stories nuevas.”
Elena (Dev): “Ayer avancé en la validación de columnas. Hoy la termino y empiezo con los estilos básicos.”
Carlos (TL): “Ayer hice pair con Diego en la tarde. Hoy hago pair con Elena.”
Ana (PO): “No hay bloqueos. Tengo una reunión con la directora a las 3, así que si necesitan algo, pregúntenme antes.”
Diez minutos. Todos saben qué está pasando. Nadie necesita leer un reporte de estado de 20 páginas.
Decisiones en tiempo real
A lo largo del día, Ana toma cuatro decisiones más sin necesidad de reuniones formales:
-
Elena le pregunta si los colores de las etiquetas de equipo deberían ser fijos o elegibles por el usuario. Ana dice fijos por ahora, elegibles después.
-
Diego descubre que la barra de deshacer necesita un timeout. Ana decide cinco segundos: suficiente para reaccionar, no tanto como para confundir.
-
Carlos pregunta si los tableros archivados deben ser accesibles. Ana dice que por ahora no, pero los datos no se borran.
-
Elena pregunta si el nombre del tablero puede tener emojis. Ana se ríe y dice que sí.
Carlos (TL): “Cuatro decisiones de producto en un día, sin una sola reunión formal. En un proyecto con el PO remoto, cada una de estas habría sido un ticket, un correo, una espera.”
Ana (PO): “Y cada espera es una oportunidad para que el equipo asuma algo incorrecto.”
Carlos (TL): “Exacto. El On-site Customer no es estar aquí por control. Es estar aquí para reducir la distancia entre la pregunta y la respuesta a cero.”
El costo de la presencia
Diego plantea una duda honesta.
Diego (Dev): “Ana, ¿no te aburres? Pasas horas aquí y a veces nadie te pregunta nada.”
Ana (PO): “No. Cuando no me preguntan, estoy trabajando en el backlog, hablando con stakeholders, refinando stories futuras. Y cuando me preguntan, puedo responder al instante porque tengo el contexto fresco.”
Elena (Dev): “¿Y tu jefe no te dice que deberías estar en otras reuniones?”
Ana (PO): “Mi jefe ve resultados. Un producto funcionando en tres semanas que otros equipos no logran en tres meses. No le importa dónde me siento, le importa qué se entrega.”
Práctica XP del capítulo
On-site Customer: Kent Beck establece que un representante del negocio debe estar físicamente con el equipo, disponible para responder preguntas en tiempo real. El On-site Customer no es un lujo ni una formalidad: es una práctica que elimina el delay de feedback más común en software — la espera por decisiones de producto. Cuando el customer está presente, las decisiones se toman en segundos en vez de días. El ahorro acumulado a lo largo de un proyecto es enorme.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Toma decisiones instantáneas, trabaja en backlog, demuestra el valor de estar presente |
| Carlos | Facilita stand-up, conecta la presencia de Ana con los principios XP |
| Diego | Aprovecha la proximidad de Ana, hace preguntas al instante |
| Elena | Comparte el contraste con proyectos donde el PO estaba ausente |
Anterior: Sustainable Pace | Siguiente: Retrospectiva profunda