{"id":37611,"date":"2015-11-12T12:11:00","date_gmt":"2021-02-10T11:00:15","guid":{"rendered":"https:\/\/www.globallogic.com\/latam\/insights\/blogs\/equipo-tradicional-vs-equipo-agil-ser-po-proxy\/"},"modified":"2025-01-30T11:41:35","modified_gmt":"2025-01-30T11:41:35","slug":"equipo-tradicional-vs-equipo-agil-ser-po-proxy","status":"publish","type":"insightsection","link":"https:\/\/www.globallogic.com\/latam\/insights\/blogs\/equipo-tradicional-vs-equipo-agil-ser-po-proxy\/","title":{"rendered":"Equipo tradicional vs equipo \u00e1gil: Ser PO proxy"},"content":{"rendered":"
Uno de los principales problemas que nos encontramos al momento de introducir un equipo \u00e1gil (externo o interno) en una empresa con metodolog\u00edas tradicionales es la falta de un rol que represente \u201cla voz\u201d del cliente: el ProductOwner (PO). Este rol es indispensable para poder construir en tiempo y forma el producto m\u00e1s adecuado para el negocio.<\/p>\n
Dado que este impedimento es un riesgo extra del proyecto, en este breve documento explicamos un rol llamado PO Proxy, que sustituye el rol inexistente del PO y permite mitigarlo.<\/p>\n
\u00bfQue es un ProductOwner?<\/strong><\/p>\n En la mayor\u00eda de los proyectos \u00e1giles de consultor\u00eda, el rol de ProductOwner(PO) es representado por el l\u00edder de proyecto del lado del cliente,que tiene como objetivo llevar adelante la construcci\u00f3n de un producto adecuado a las necesidades del negocio.<\/p>\n Las responsabilidades propias de un PO son:<\/p>\n Adem\u00e1s, es imprescindible que el PO trabaje en estrecha colaboraci\u00f3n con las partes interesadas, facilite la comunicaci\u00f3n del equipo y los grupos de inter\u00e9s y se asegure de que el equipo est\u00e9 construyendo el producto correcto.<\/p>\n \u00bfQu\u00e9 sucede si se presenta un equipo mixto: \u00e1gil y tradicional?<\/strong><\/p>\n El l\u00edder de un equipo tradicional no siempre entiende y presenta las habilidades o caracter\u00edsticas propias de un PO, pudiendo representar un impedimento extra en el proyecto. Si se presenta este caso en el equipo del cliente, ser\u00e1 necesario que el equipo \u00e1gil cubra ese rol desde el inicio para una mejor integraci\u00f3n de la metodolog\u00eda.<\/p>\n Luego del relevamiento realizado por un equipo \u00e1gil, interactuando con un cliente con metodolog\u00eda tradicional, se arrib\u00f3 a la conclusi\u00f3n de que era necesario elegir un PO proxy.\u00c9ste actuar\u00eda como \u201ctraductor\u201d del l\u00edder del cliente, desde una perspectiva tradicional y la llevar\u00eda a una perspectiva \u00e1gil, permitiendo al equipo representar algunas funciones del PO, tales como priorizar el backlog de trabajo y los resultados esperados por el negocio en corto y mediano plazo, necesarias para poder avanzar con objetivos claros.<\/p>\n El rol de PO proxy fue cubierto por el analista funcional del equipo, quien al conocer del negocio y participar de todas las reuniones de equipo y con clientes, pudo tomar varias de las decisiones que corresponden al PO, con el fin de organizar la correcta construcci\u00f3n del producto.<\/p>\n \u00bfCu\u00e1l fue el resultado de contar con un PO proxy?<\/strong><\/p>\n Con el apoyo del equipo y en constante comunicaci\u00f3n con los involucrados, el equipo \u00e1gil pudo llevar adelante el proyecto, con altibajos en varios momentos, debido precisamente a que no ten\u00eda la potestad de tomar ciertas decisiones concernientes al PO del cliente, y \u00e9ste a su vez no ten\u00eda el apoyo interno suficiente como para lograr respuesta a consultas y realizar definiciones necesarias para el avance del desarrollo del producto.<\/p>\n Es un gran desaf\u00edo participar de un proyecto donde el PO no puede tener claros ciertos aspectos que pueden cambiar el curso de lo que se espera del producto en ciertos momentos, y definir las prioridades de manera clara y objetiva, teniendo siempre como prioridad construir el producto adecuado para el negocio, dentro del contexto.<\/p>\n Conclusi\u00f3n:<\/strong><\/p>\n Si una empresa es tradicional en su enfoque del desarrollo de proyectos, se hace dif\u00edcil la integraci\u00f3n del POa un equipo \u00e1gil. Los problemas comunes en este sentido son la p\u00e9rdida de tiempo en cuestionar los procesos(sprints, dailys, etc), y el costo del tiempo en el aprendizaje y la adaptaci\u00f3n para colaborar al desarrollo del producto dentro de la metodolog\u00eda \u00e1gil, lo que incluye: definir historias de usuario, criterios de aceptaci\u00f3n, entender el armado de sprint, etc.<\/p>\n Por otro lado, tambi\u00e9n podr\u00eda ser riesgoso que el PO sea alguien sin conocimiento del negocio o carezca de las habilidades blandas necesarias que le permitan ser un buen negociador y tener buena relaci\u00f3n con todos los interesados.<\/p>\n Es recomendable capacitar a los futuros PO nacidos en metodolog\u00edas tradicionales, especialmente para aquellos que tengan ganas de adquirir conocimientos sobre la metodolog\u00eda \u00e1gil y asuman la responsabilidad que eso conlleva.<\/p>\n Gracias a esta capacitaci\u00f3n, el POpodr\u00e1 obteneruna variedad de herramientas que le permitan colaborar para que tanto el equipo de desarrollo del producto como los due\u00f1os del producto obtengan lo deseado de la mejor manera y en el menor tiempo posible, aportando un valor agregado que conduzca al equipo al logro de un proyecto exitoso.<\/p>\n\n