Estimación de un error notificado por un cliente
Cómo estimar un error notificado por un cliente: la descripción que figura en el ticket determina su envergadura. Cómo distinguir entre una corrección de una sola línea y una respuesta que consume todo el sprint.
El problema no es el tamaño. El problema es el cliente.
Un error notificado por un cliente conlleva un alcance que el equipo no puede apreciar solo a partir del ticket. La solución técnica podría consistir en una sola línea de código. Sin embargo, el trabajo que lo rodea —reproducir el error con los datos del cliente, redactar un informe posterior al incidente, elaborar la respuesta, decidir si se debe abonar el importe en la cuenta y comunicarse con otros clientes afectados— suele constituir la mayor parte del proceso. Nada de eso figura en el ticket. Todo ello merma la velocidad.
Tenga en cuenta dos aspectos: la solución y la respuesta. La solución consiste en el «planning poker» habitual. La respuesta, en cambio, resulta poco familiar para los equipos de ingeniería y suele subestimarse sistemáticamente; de ahí que los errores de los clientes parezcan prolongarse a lo largo del sprint, incluso cuando la votación con las cartas ha dado un resultado bajo.
Lo que se dice en la sala
Backend: «La corrección consiste en una sola línea».
PM: «¿Qué cuenta lo ha publicado?»
Asistencia técnica: «Su gestor de servicios al cliente solicita un análisis de la causa raíz para el viernes».
Pregunta principal: «¿Hay otras cuentas afectadas? ¿Debemos enviarles un correo electrónico?»
Pregunta de control de calidad: «¿Podemos reproducir el problema con sus datos, o necesitamos una exportación con datos anonimizados?»
Preguntas que conviene plantearse antes de votar
- ¿Quién lo ha notificado y cuál es su ARR, SLA o estado contractual?
- ¿Se debe realizar una evaluación de la respuesta a la crisis (RCA) o un análisis a posteriori de forma externa?
- ¿Hay otras cuentas afectadas y cómo podemos averiguarlo?
- ¿Debemos conceder un abono, realizar un reembolso o prorrogar el periodo de prueba?
- ¿Quién redacta la respuesta dirigida al cliente? ¿Y figura esa respuesta en este ticket?
- Reproducción: ¿datos del cliente, volcado depurado o datos sintéticos?
Separar resulta útil: la corrección es una solicitud, la respuesta es otra. Ambas pasan por el «planning poker»; solo una de ellas tiene carácter técnico.
Calcule la corrección y la respuesta por separado. El nombre de la cuenta es lo que hace que la respuesta sea tan extensa.
Consulte los errores habituales en el Planning Poker para conocer los riesgos que conlleva votar sobre tareas que no son responsabilidad del equipo. Eche un vistazo a los demás ejemplos prácticos de estimación, o organice una sesión gratuita de Planning Poker con ambas historias preparadas.