Soy el líder técnico de un proyecto de software dedicado a administrar el año de trabajo de las "personas VIP" de una gran empresa.
Básicamente, para simplificar esta publicación, el proyecto es una combinación de una red social (entre esas personas VIP) y una red de reuniones, donde cualquiera de ellos podría estar al tanto y participar en sus respectivas reuniones anuales.
Curiosamente, mi Product Owner no es una de esas personas VIP, sino alguien que las gestiona de forma remota (creando reuniones, etc., estableciendo su perfil, etc.).
Es parte del Equipo de Secretaría.
Argumenta que conoce su trabajo y por lo tanto piensa dominar sus necesidades.
Se supone que el proyecto evoluciona a través de principios ágiles, para recibir comentarios temprano, pero:
El problema es:
Recibimos algunos comentarios de que la gente VIP encuentra el software muy ligero pero interesante, pero el propietario del producto no puede soportar la palabra "ligero".
Los clientes no son conscientes de la cantidad de tareas internas dedicadas al Equipo de Secretaría; Soy sensible a su "cita".
El Product Owner piensa erróneamente que el software es para SU equipo más que para personas VIP y está equivocado.
¿Cómo hacer que el propietario del producto se dé cuenta de que no se enfoca en el cliente correcto y que es un gran riesgo con respecto a la vida útil del proyecto, ya que todo el presupuesto del proyecto se gasta casi por completo?
Cómo hacer que el propietario del producto se dé cuenta de que recibir comentarios como "un proyecto bastante bueno, pero le faltan algunas funciones prometidas después de 5 meses de trabajo" no es como "¡Guau, increíble!" ¿comentario?
Me decepcionó mucho como líder técnico cuando el cliente dijo: "¡¿5 meses para eso?!"; de hecho, solo ven un número muy, muy corto de funciones con las que pueden "jugar".
El descanso está oculto para ellos.
Asumiré que lo que el "VIP" quiere está en algún lugar entre lo que piensas y lo que cree el PO. Agregaré algunos hechos a esa suposición: el VIP realmente no sabe lo que quiere, de todos modos no granular. Además, seguramente cambiarán de opinión sobre algunos de los detalles.
En Scrum y otros enfoques iterativos, los comentarios de Sprint Review harán transparente lo que quiere el VIP. ¿Con qué frecuencia demuestra el trabajo realizado en un incremento y una iteración al VIP? ¿Por qué han pasado 5 meses y el PO puede tomar estas decisiones si está tan equivocado?
Si tiene evidencia objetiva de que la PO está equivocada, hable con ella o intensifique el problema. De lo contrario, es posible que desee preguntarle al administrador de procesos (también conocido como Scrum Master, PM) sobre la efectividad de las reuniones de revisión de sprint.
Solía entregar una encuesta rápida de cara feliz, cara neutral y cara triste a los asistentes a la reunión de revisión del sprint. Proporcionó una base neutral y objetiva para proponer el cambio.
Buena suerte y tenga cuidado con las predisposiciones y los sesgos cognitivos :)
Intentaría usar los instrumentos que Scrum proporciona de forma inmediata: Sprint Review y Sprint Retrospective.
Cómo puede ayudar Sprint Review:
Dado que las personas VIP son las partes interesadas del software que desarrolla, deben participar en la demostración de iteración. Con esas personas en Demo, puede pedirles comentarios inmediatos sobre si consideran que la función entregada es valiosa o si evalúan el valor en alguna escala. También puede ofrecerles una vista de las funciones que se encuentran actualmente en un backlog y cuáles creen que son las mejores candidatas para incluir en la próxima versión.
Cómo puede ayudar Sprint Retrospective:
Puedes operar con los números. Reúna las estadísticas de los puntos de la historia u otra medida del esfuerzo que utiliza en su equipo para las tareas que brindan valor para las "características orientadas a la Secretaría" y para las "características orientadas a VIP". Cada iteración pide a tu Product Owner que justifique los valores.
También abriría la pregunta a las partes interesadas para que consideren dividir el equipo en dos subequipos, cada uno de los cuales tendría su propio propietario del producto. Como justificación daría el hecho de que tender a entregar código "orientado a Secretaría" e ignorar el código "orientado a VIP" hace que este último gane la deuda técnica lo que encarece la entrega con el tiempo.
nvoigt