Últimamente tuvimos un proyecto, en el que el cliente estaba ocupado de gira. Como se formó el equipo habitual de scrum, la gerencia decidió nombrar a nuestro analista como propietario del Producto ya que el Cliente no podrá participar activamente. El analista fue quien trabajó estrechamente con el cliente para el análisis de requisitos y la redacción de especificaciones.
El cliente no tiene tiempo para revisar los dos primeros lanzamientos. Todo salió bien hasta que el cliente vio el tercer lanzamiento; no estaba satisfecho con algunas funcionalidades, y esas fueron introducidas por el propietario del producto de turno (nuestro analista).
Nos dijeron que esperemos hasta que el equipo de diseño finalice la maqueta de todas las páginas y el cliente verificó cada una y aprobó continuar trabajando. El equipo Scrum está allí, pero no hay sprints: terminamos el trabajo casi como el clásico método de cascada.
¿Es una buena idea nombrar al miembro o maestro del equipo scrum como propietario del producto? ¿Necesitamos seguir scrum en ausencia de la participación del cliente / propietario del producto?
Scrum funciona mejor con un cliente real en su lugar. Hay un par de desafíos reales al tratar con clientes que no están acostumbrados al diseño iterativo de productos.
Las etapas de diseño con una hoja en blanco tienden a aparecer en el cielo muy rápidamente, y generalmente profundizan en un par de cuestiones secundarias y no tienen suficiente profundidad en la funcionalidad central necesaria. Realmente necesita un hombre de paja para que el cliente lo separe para que las reuniones de diseño se desarrollen con éxito. Al enfocarse en un solo aspecto a la vez, está ayudando a su cliente a aprender diseño iterativo.
Los clientes asustados (como lo hizo con su experiencia) no se dan cuenta de que los proyectos ágiles anticipan una cierta cantidad de trabajo (controlado) como parte del proceso. Lo que les cuesta comprender es que a medida que avance el desarrollo del producto, habrá menos momentos de "Oh, Dios mío". Más importante aún, la parte con la que la mayoría de los clientes tienen dificultades es que los momentos de "Oh, Dios mío" no requieren mucho dinero para solucionarlos debido al corto tiempo entre los ciclos de revisión / planificación.
Gestionar las expectativas del cliente es muy difícil. Es un buen equilibrio de educación al cliente, aplacar e incluso aprender a decir "no". El cliente no siempre puede venir semanalmente o quincenalmente. A veces solo pueden venir una vez al mes. Está bien. Siempre y cuando les muestres lo que hiciste para abordar sus inquietudes el mes anterior, y luego concéntrate en el trabajo de este mes, será de gran ayuda para que el proyecto funcione sin problemas. La conclusión es que, en ausencia del cliente, usted tiene alguien que puede hacer recomendaciones razonables para algunas preguntas. Debe ser alguien familiarizado con los objetivos que el cliente intenta alcanzar.
fuente
Idealmente, el propietario del producto tiene cierto nivel de autoridad y conocimiento sobre el proyecto. Lo mismo podría haber sucedido si el cliente asignó a un empleado de nivel inferior que luego fue desestimado en una fase posterior que requiere que casi comience de nuevo.
fuente
Gracias por tu publicación. Me doy cuenta de que es viejo, pero creo que has planteado un gran caso y aquí están mis $ .02:
Problema 1: nombrar al analista como PO en su caso acorta seriamente el marco de scrum. ¿Por qué? Porque solo la OP puede hacer juicios de valor, evaluaciones de ROI, priorización y elecciones decisivas que fluyen del negocio, no de la tecnología, ni siquiera de la familiaridad con el producto. Estoy seguro de que tu sr. El analista hizo un trabajo fantástico imitando la orden de compra, pero finalmente tuvo que adivinar los deseos, valores y opciones que vendrían de su orden de compra. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ . A menos que el cliente le haya otorgado POA al analista (poco probable), no estará en condiciones de aceptar o rechazar nada en la revisión de sprint.
¿Podría este enfoque posiblemente funcionar? Sí, pero tendría que haber una transferencia total de responsabilidades mientras su cliente estaba fuera. El jefe de su cliente necesitaría estar de acuerdo con el sustituto y no se revertiría ninguna decisión razonable tomada. ¿Suena probable? Es más probable que obtenga una orden de compra temporal de la organización de su cliente (¡lo que ciertamente no está exento de inconvenientes!) Pero si su sr. analista trabajó con la orden de compra temporal, cualquier decisión incorrecta vendría del negocio, manteniendo así las funciones de su equipo limpias.
Problema 2: "el cliente no tiene tiempo para revisar". Gran problema (y uno con el que me encontré recientemente). PO debe estar presente para aceptar el producto. Nadie más puede 'firmar el cheque'. La ausencia de PO significa que la insatisfacción ocurre más tarde, potencialmente más retrabajo y pérdida de confianza. Más fundamentalmente, siento que el cliente no participa activamente en su proyecto: no hay tiempo para el standup diario, no hay tiempo para responder preguntas, etc.
Problema 3: "nos dijeron que esperemos hasta que el equipo de diseño termine la maqueta". Y ahora están fuera del scrum por completo. La gente que hace la maqueta debe ser parte de su equipo multifuncional. No puedo decir si esto es causado por la falta de comprensión de la administración del scrum o una reacción de choque a su tercer lanzamiento.
Pregunta: ¿Dónde estaba tu scrum master en todo esto? El SM normalmente reconocería el peligro del conflicto de roles y la falta de participación de la OP, ambos obstáculos / peligros que deben abordarse.
fuente