Cuando se trata de Gestionar Producto, en ciclos de desarrollo de software, basados en Scrum o alguna otra metodología ágil de ciclos e incrementos, tenemos el permanente desafío de planificar, priorizar y reorganizar el backlog y roadmap.
Hace tiempo un colega y amigo se refirió a su trabajo, por más apasionante que le resulta, como un tanto amor-odio-tóxico, en el sentido de que "muchas veces el desafío de priorizar nos consume la vida, el tiempo y la paciencia: queremos cumplir con todo y con todos", dijo.
¿Qué soluciones hay, entonces, a los incrementos y evolutivos de un producto de software?
Hay que liderar en base a necesidades propias de la plataforma o producto. Y esto compite con los servicios y necesidades del equipo comercial, y además contra reloj con los clientes, partners, project managers e implementadores.
Entonces, ya no solo alcanza con que el Product Manager tenga en claro el roadmap, y el Product Owner ordenado el backlog, y el Project Manager al día el proyecto, plazos, ceremonias y entregas.
¿Cómo podemos socializar el avance del proyecto y co-gestionar el avance de manera consistente?
Algunas sugerencias:
- Disponibilidad a todas las partes involucradas los tableros de alto nivel, actualizados en vivo o de mínimo, al día.
- Gantt abierto, visible, y cuestionable: debemos revisarlo regularmente con los equipos y estar disponibles a atender consultas, reclamos y feedback de todo, en especial sobre los plazos y prioridades.
- El backlog debe entenderse como una gran pila de trabajo futuro, pero al mismo tiempo, limitarlo de forma clara a la capacidad disponible. ¿Por qué solo tomamos estas tareas o cuánto podremos abarcar en este Q? ¿Por qué no entra en sprint?
- Transparentar cambios, prioridades y necesidades. Un comentario sencillo despeja especulaciones: "parece que esta tarea es una tontería, pero lo necesita urgente este proyecto estratégico que nos permitiría duplicar la facturación en el próximo Q", deja claro el por qué esto va sobre el resto.
Gestión del producto compartida con los usuarios y clientes
Recuerdo que hace una década sorprendía que HP tuviera foros donde los usuarios podían plantear consulta de productos, y había además de un equipo de soporte atento a todo ello, también muchos usuarios de diferente nivel de experiencia haciendo aportes, respondiendo, acompañando.
Pasa también con la recepción de ideas y sugerencia de mejoras con opción a voto. Atlassian, empresa detrás de Jira, Confluence, Bitbucket, y muchas otras, admiten que los usuarios y clientes puedan publicar features, necesidades. Esto queda muchas veces en revisión rápida del equipo de producto y luego se pone a votación.
A mí me gusta mucho como lo ha encarado Render:
Render es una plataforma de computación en la nube, que de forma moderna, descontracturada y acercándose a un público más de developers, está creciendo muy rápido y fuerte. ¿Cómo lo gestiona?
Tiene un apartado que denominan Feedback. Es sencillo, de interfaz simple y limpia, sin vueltas ni burocracia.
¿Lo bueno? Ya no depende de que un asistente de la cuenta, un newsletter llegue, sino que está publicado parcialmente el roadmap/backlog para que los diferentes stakeholders puedan interactuar, proponer, votar, priorizar.
También, además de las features, servicios de infraestructura, Render lo usa para proponer nuevas regiones de servicio, nuevos puntos de presencia de red:
¿Cómo gestionas tu o tus equipos el ciclo de incrementos y evolutivos? ¿Qué te parecen estas ideas?
Puedes ver más sobre product owner, scrum, project manager y analista funcional en mi blog, además de comprender formas de escalar proyectos ecommerce de manera consistente y con resultados increíbles en diferentes plataformas.
Top comments (0)