Product owner: Crear o mejorar

¿Cómo podemos escoger entre crear nuevas funcionalidades o mejorar lo existente?
crear o mejorar

El Product Owner es el encargado de la gestión del Backlog del producto. Para ello, entre sus responsabilidades está la priorización de los siguientes trabajos a realizar. Estos pueden ser, entre otros, añadir nuevas funcionalidades o mejorar lo existente ¿Cómo escoger entre crear o mejorar? Sigue leyendo

En nuestros smartphones es normal recibir notificaciones cuando una aplicación o el SO tienen actualizaciones disponibles. En cada actualización, es normal encontrar un espacio donde se enumeren las características que se añaden o las correcciones sobre las que aplican. Aunque existan casos donde se limiten a escribir correcciones de errores y mejoras en la aplicación, lo ideal es que el usuario reciba la información detallada para manejar las expectativas respecto al cambio en la app.

Para crear el paquete de la actualización, como Product Owner necesitas priorizar el Backlog en función de la estrategia del producto. A tu disposición tienes un listado de funcionalidades nuevas que ofrecer a tus usuarios, pero también hay correcciones o mejoras que incluir en los sistemas y que no tienen por qué ofrecer una mejora directa a los usuarios. Para tomar una decisión deberás escuchar al equipo de desarrollo para entender los beneficios de las mejoras y así poder priorizarlas correctamente junto a las nuevas funcionalidades.

Sin embargo, ¿qué ocurre cuando la carga de nuevas funcionalidades y mejoras no está nivelada?

Más funcionalidades que mejoras
A priori esta solución debería tener a nuestros usuarios más contentos, porque incorpora funcionalidades nuevas en cada actualización. Pero, con el paso del tiempo, es muy probable que nuestra aplicación empiece a mostrar errores o problemas. Aunque hayamos construido nuestro software con mucha calidad existen imprevistos a los que el equipo de desarrollo tiene que prestar atención: actualización de librerías externas, nuevos dispositivos sobre los que desplegar el software, aumentar capacidad para soportar más usuarios… Al final el usuario acabará descontento porque tiene a su disposición un montón de funcionalidades que no funcionan o tienen muchos errores.

Más mejoras que nuevas funcionalidades
Dentro de las mejoras podemos encontrar acciones para optimizar los sistemas sobre los que se ha construido el equipo. Dedicar iteraciones a la mejora de los sistemas, puede ayudarnos a tener una base sólida sobre la que construir nuestro producto. Pero, mientras tanto, el usuario no notará grandes cambios ni obtendrá nuevas funcionalidades.

Dentro de las mejoras también hay acciones para corregir deuda técnica, es decir, solucionar problemas que se producen por no haber cuidado el desarrollo del software. Si como Product Owner comienzas a priorizar más deuda técnica que nuevas funcionalidades de nuestro producto, puede ser un indicador de que el producto no se ha ido construyendo con la calidad necesaria. Corregir este tipo de deuda es más costoso que desarrollar el software con unos estándares mayores de calidad. El esfuerzo de crear una funcionalidad con calidad, es mucho menor que aumentar la calidad de una funcionalidad que ha ido creciendo con el tiempo.

En el equilibrio está la virtud
Un Product Owner tiene que prestar atención a estos casos. En el Product Backlog no solo debes incluir las funcionalidades si no todos los trabajos que el producto necesite. Los refinamientos son un buen lugar para identificar junto al equipo de desarrollo todas las mejoras que requiere el producto. Es necesario que como dueño del producto comprendas bien el beneficio de la mejora y qué impacto puede tener en el producto, para poder priorizarla frente al resto de nuevas funcionalidades.

Una herramienta que te puede ayudar son las métricas. En uno de nuestros clientes hemos puesto al servicio de los equipos un gráfico en el que por cada iteración se identifica la cantidad de funcionalidad vs mejoras. Esta información ha servido a los equipos para iniciar conversaciones sobre cómo están construyendo su producto y qué acciones necesitan tomar para mejorar. Para completar esta información, habrás de comprobar que la satisfacción del usuario respecto del producto no disminuye al incluir las mejoras. Esto puedes hacerlo durante la review, mientras se muestra el incremento de producto a los usuarios que asisten al evento o mediante algún mecanismo de encuesta a los usuarios finales.

Si quieres saber más sobre cómo priorizar, te dejamos algunos de nuestros artículos anteriores:

Tabla de contenidos

Comparte:

Más artículos

Matriz RACI: ¿en qué nos puede ayudar?

La matriz RACI o Matriz de Asignación de Responsabilidades es una herramienta que nos permite identificar los roles y las responsabilidades de determinadas tareas en un proyecto de forma muy visual.

Sprint Reviews: ¿Cómo dominarlas?

La Sprint Review es un evento de Scrum de cierre de iteración. Supone un ejercicio de inspección, adaptación y transparencia sobre el producto que estamos construyendo.

Suscríbete y mantente al día de las novedades

¿Alguna duda?

¡Reserva 30 minutos con uno de nuestros expertos y soluciónala!