Mejorar un producto no solo implica desarrollar nuevas funcionalidades, sino también gestionar eficazmente los bugs y la deuda técnica. Como Product Manager, es clave priorizar trabajos técnicos alineados con las necesidades de los usuarios y los objetivos de la empresa, asegurando tanto la calidad del producto como su sostenibilidad a largo plazo.
Cómo gestionar los bugs
Tú lo construyes, tú lo mantienes
Una vez que las funcionalidades están en producción, es posible que te reporten fallos (bugs). A diferencia de los métodos de desarrollo en cascada, donde el producto se transfiere del equipo de build (que desarrolla la solución) al equipo de run (que se encarga del mantenimiento y soporte), hoy en día se recomienda un enfoque donde los desarrolladores que diseñaron la solución también son responsables de ella. «You build it, you run it» (tú lo construyes, tú eres responsable). ¡Las ventajas son múltiples!
- Conocimiento directo: Los desarrolladores comprenden mejor el código que escribieron, lo que les permite solucionar problemas más rápido.
- Respuesta ágil: Minimiza los tiempos de intervención al evitar transferencias innecesarias entre equipos.
- Compromiso: Al estar más cerca de los usuarios, los desarrolladores tienen un incentivo adicional para crear soluciones robustas.
Este artículo es un extracto del libro:
Detectar y priorizar bugs
La gestión eficaz de los bugs pasa por cuatro etapas principales:
1. Detección: Los bugs son creados por la persona que los detecta. Puedes ser tú, como Product Manager, especialmente si un usuario te informa directamente de un error. También pueden ser creados por un miembro del equipo, del servicio de atención al cliente o cualquier otra persona que interactúe con el producto. Los bugs contienen la descripción de los pasos para reproducir el problema, el resultado observado y el resultado esperado. Cuando se detecta un bug en producción, debe tratarse inmediatamente. Esto no significa que deba corregir el bug inmediatamente, pero sí que debe tomar conocimiento de él lo más rápidamente posible, intentar reproducirlo y, si es el caso, documentar los elementos relevantes para la reproducción del bug. Finalmente, debe comunicarse con los stakeholders involucrados.
2. Priorización: no todos los bugs son igual de importantes o urgentes. Por tanto, hay que aceptar que no se podrán corregir todos. Un bug que se produce en producción debe tratarse más rápidamente que un bug que se produce en una versión en desarrollo o en pruebas. Del mismo modo, un bug detectado en el camino crítico de tus usuarios, y que impide el buen funcionamiento de las principales acciones, no tiene la misma criticidad que un bug que se produce en una funcionalidad poco utilizada o que representa un problema menor.
3. Corrección: los bugs más prioritarios se corrigen inmediatamente. En función de la importancia del bug, no dudes en añadir escenarios de prueba adicionales para evitar que se repita en futuras versiones. Los errores menos críticos pueden priorizarse con otras Historias de Usuario al planificar futuras versiones.
4. Validación: una vez corregido el bug, hay que probarlo como una Historia de Usuario clásica y enviarlo a producción. Si el bug es muy crítico, podemos lanzar lo que llamamos un hotfix, es decir, una versión dedicada exclusivamente a la corrección. Si la criticidad es más moderada, el parche puede integrarse en la versión actual. Una vez que el parche esté en producción, hay que informar a las personas afectadas.
Qué es la deuda técnica y cómo gestionarla
Entendiendo la deuda técnica
La deuda técnica es como una deuda financiera: las partes del código que no son óptimas generan "intereses" en forma de problemas técnicos y mantenimiento. Si no se atiende, puede ralentizar el desarrollo y afectar negativamente a:
- Mantenimiento: ya sea correctivo (corregir defectos y errores de una aplicación) o adaptativo (adaptar una aplicación para que siga funcionando con versiones más recientes de los componentes técnicos en los que se basa), el mantenimiento de aplicaciones o software está en el centro de tu trabajo y afecta directamente a los equipos de desarrollo. Cuanto más implique este mantenimiento, más tiempo pasará tu equipo de desarrollo corrigiendo bugs y menos funcionalidad ofrecerá.
- La escalabilidad de un producto: la esencia misma de la gestión de productos es ofrecer las funcionalidades que mejor se adapten a las necesidades reales de los usuarios. Si el producto deja de evolucionar funcionalmente, acabará yendo cuesta abajo. Además, la falta de escalabilidad requerirá intervenciones más largas y difíciles en el código para desarrollar nuevas funcionalidades.
- Fiabilidad: un usuario que se enfrenta a un software inestable o a una aplicación cuyo comportamiento es aleatorio puede volver una segunda vez, pero nunca una tercera.
Cómo dominar la deuda técnica
Hacer un producto que no requiera mantenimiento, cuyas evoluciones sean fáciles y rápidas de implementar y que sea muy fiable, es muy utópico. La deuda técnica es inevitable y a veces deliberada. En algunos casos, el equipo puede tomar la decisión consciente de crear deuda técnica para entregar una funcionalidad dentro de los plazos exigidos.
Cuando se identifica un elemento de deuda técnica (voluntario o no), a menudo gracias a su equipo de desarrollo, debe identificar la táctica para absorberla. Tu trabajo como Product Manager consiste en encontrar el compromiso adecuado para maximizar la escalabilidad y la fiabilidad de tu producto, mientras minimizas el tiempo dedicado al mantenimiento.
El cuadrante de la deuda técnica
Este marco de Martin Fowler de ThoughtWorks categoriza la deuda técnica en cuatro tipos:
Minimizar la deuda técnica
Ahora seguramente te preguntes cómo producir la menor cantidad de deuda técnica posible mientras sigues entregando funcionalidades a tiempo y cómo convivir con una deuda técnica existente intentando, aun así, minimizarla.
En primer lugar, la deuda técnica está vinculada de forma más general a la calidad. Cuando existe una cultura de la calidad en el seno del equipo y con las partes interesadas, cuando se realizan esfuerzos previos mediante la elaboración de Historias de Usuario, test, programación entre pares, DoD, entrega regular de código, etc., parte del problema vinculado a la deuda técnica ya se ha resuelto.
En ciertos casos, se debe prestar especial atención a la deuda técnica para absorberla. Para abordarla, asigna una parte de la capacidad del equipo a la gestión de la deuda para mejorar el rendimiento poco a poco. Así, los desarrolladores podrán implementar:
- La regla del Boy Scout. Deja siempre el código en el que estás trabajando un poco mejor de lo que lo encontraste. Esto permite a tu equipo abordar la deuda técnica de forma casi gratuita. El principio es simple: cada vez que alguien toca un trozo de código, tiene que hacerlo mejor que el estado en el que lo encontró. ¡Se trata de la mejora continua!
- Tareas de refactorización. La refactorización, o reelaboración del código, consiste en reelaborar el código fuente de una pieza de software sin añadir funcionalidad ni corregir errores, pero mejorando su legibilidad para simplificar el mantenimiento o hacerlo más genérico.
- Una lista de deudas pendientes. El backlog de deuda enumera la deuda detectada y las acciones voluntarias de deuda tomadas por el equipo. Cuando tomes una decisión de este tipo, no olvides rellenar los elementos que motivaron tu elección, las tareas para corregir la deuda tomada, el tiempo estimado que llevaría la corrección, así como la fecha prevista para saldar esta deuda. El backlog te ofrece una visión clara de la deuda por saldar, para que puedas priorizarla en función de tus necesidades y de las previsiones de tu roadmaps.
Consejos prácticos
- Plantillas para bugs: Crea una plantilla con campos obligatorios para estandarizar la captura de información clave.
- Sesiones de corrección: Dedica sesiones puntuales para resolver pequeños bugs con diseñadores y desarrolladores.
- Evita crisis: No planees sprints enteros para refactorización; esto puede enviar un mensaje erróneo sobre el control del producto.
Para saber más: descarga nuestro libro Las Claves del Product Management
