Product Owner

Artículo

7 conductas clave para desarrollarte como Product Owner

Cuando se trata de desarrollo ágil, el Product Owner es generalmente considerado como el rol más importante en el proyecto. Aunque en realidad, todos los roles son igualmente importantes, es el Product Owner quien, en última instancia, negociado con el equipo, toma las decisiones acerca de qué características se incluirán en el sistema, en qué orden serán trabajadas y cuándo serán aceptadas como hechas. Los proyectos ágiles sin un Product Owner eficaz y empoderado, están condenados al fracaso.

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.

Conducta nº1. Participar

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.

Conducta nº2. Estar bien informado

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.

Conducta nº3. Tomar decisiones

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.

Conducta nº4. Ser receptivo

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.

Conducta nº5. Estar dispuesto a aprender cosas nuevas

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.

Conducta nº6. Hacer preguntas

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.

Conducta nº7. No Asumir

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

Julio Roche es Specialist Director del área de System Development&Integration, en la práctica de DxD de Deloitte. Profesional con más de 25 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, lo que le ha llevado a estar involucrado en procesos de implantación de metodologías ágiles desempeñando todos los roles que estas enumeran. Ha sido Agile Coach&Trainer, Scrum Master, Product Owner y parte del Development Team.