Para las organizaciones basadas en productos o en proyectos internos, tener un Product Owner que sea una parte integral del equipo del proyecto es bastante estándar. Para organizaciones basadas en servicios como por ejemplo Deloitte, donde la mayor parte del trabajo que hacemos se basa en un contrato con un cliente, a menudo es ese cliente el que debe proveer el Product Owner.
Cultivar estas siete conductas que os proponemos a continuación, debe ayudar a cualquier Product Owner, ya sea parte integral del equipo o de un cliente externo, a ser eficaz y ayudar al éxito del proyecto.
Este hábito es clave en el trabajo de un Product Owner que quiera considerarse eficaz. Un Product Owner debe estar completamente involucrado en el proyecto, desde el inicio hasta la finalización (y a menudo más allá).
Es fundamental entender el alcance completo de las características del sistema, estar al tanto de qué características se están desarrollando ahora y cuáles son deseables para el futuro y monitorizar activamente para asegurarse que las historias de usuario se están implementando de la manera en que se han acordado.
La participación regular y continua en el proyecto ayuda a asegurar que el equipo del proyecto siempre esté trabajando para entregar el valor adecuado a negocio.
El Product Owner debe tener el máximo conocimiento acerca del producto que se está desarrollando. El equipo del proyecto a menudo pedirá explicaciones al Product Owner sobre las prácticas comerciales del cliente, así como cualquier regla de negocio o práctica de la industria del cliente que pueda aplicarse. Si el Product Owner no es un experto en la materia, él o ella deben poder comunicarse con otras personas, comités o departamentos, para obtener la información necesaria de manera oportuna y en el tiempo adecuado.
En última instancia, es el Product Owner quien será responsable de comunicar al equipo de proyecto cualquier decisión que afecte al producto, en particular sobre la priorización del trabajo, el proceso de negocio, el diseño de la interfaz de usuario y otros asuntos no técnicos.
Si bien es posible que el Product Owner no siempre esté facultado para tomar esas decisiones, aun no siendo este el escenario deseado, en este caso debe ser capaz de ponerse en contacto con quienquiera que tenga esa autoridad en la organización, y es por lo tanto el responsable de asegurar que las decisiones se tomen y de comunicarlas adecuadamente y en tiempo al equipo del proyecto.
Se necesitan respuestas oportunas a las preguntas, a las solicitudes de información, a la aceptación de los detalles de la historia del usuario y a las pruebas de aceptación, de manera que nos aseguremos que el proyecto se completa a tiempo y dentro del presupuesto.
Los equipos ágiles intentan mantenerse totalmente comprometidos en todo momento, por lo que cualquier demora en la respuesta puede resultar en un trabajo incorrecto o, en casos extremos, en el estancamiento del proyecto. Un proyecto estancado es más caro, porque el equipo del proyecto todavía necesita que se le pague, aunque no sea capaz de hacer ningún trabajo.
Además de ser conocedor de un nuevo producto, al Product Owner se le pide que participe plenamente como parte integral del proyecto de desarrollo de software. Esto significa que se requiere una voluntad de aprender nuevos métodos y técnicas. Es posible que se le pida que utilice una herramienta de requisitos específicos o un sistema de gestión de trabajo que el equipo del proyecto utilizará, o trabaje de una manera en la que no esté acostumbrado a trabajar.
Generalmente un Product Owner sufre un cambio en sus mecánicas habituales de trabajo y debe adecuar el mismo al nuevo escenario. Si somos reticentes al cambio nos enfrentaremos a serios problemas que afectaran al desarrollo del producto y por ende al equipo Scrum.
El equipo del proyecto le escuchará mientras intenta comprender los requisitos de una aplicación. Por favor, escuche al equipo cuando propongan formas alternativas de implementar lo que usted está pidiendo; identifique desafíos técnicos, de programación o de costos de un enfoque o requerimiento en particular; o sugiera características adicionales que no haya considerado previamente. Los miembros del equipo de proyecto no siempre van a ser expertos en su área de negocio, pero son expertos en desarrollo de software y pueden dar una perspectiva fresca.
Uno de los mayores riesgos para cualquier proyecto son las suposiciones. Todos los hacemos, aunque no nos demos cuenta. No asuma que el equipo del proyecto sabe algo acerca de su negocio que usted no les ha dicho. Si quieres que el sistema tenga una característica en particular, asegúrate de pedirla; si hay una restricción de negocio, díselo al equipo; y si no ves algo que quieras que se escriba en las historias de los usuarios, tráelo de nuevo para que el equipo pueda asegurarse de incluirlo si es apropiado.
"Seguir estas conductas harán de ti un Product Owner más eficaz y ayudarán a que el equipo del proyecto esté mejor capacitado para entregar el software deseado, a tiempo y dentro del presupuesto. Todos felices, ¿no?"
Julio Roche es Director del área de System Development&Integration, en la práctica de Consultoría Tecnológica de Deloitte. Profesional con más de 30 años de experiencia en el mundo del desarrollo de soluciones tecnológicas, su labor se encuentra actualmente focalizada en el terreno de la movilidad y la transformación digital, donde lidera el grupo de capacidades de Movilidad dentro de Consultoria. En este grupo se encuentran las capacidades de Desarrollos de Movilidad, Contact Centre Transformation, Asistentes Digitales y Realidad Digital. Es además un referente a nivel nacional dentro del mundo de la Agilidad, habiendo participado en procesos de Transformación Ágil de grandes compañías y organizaciones.