Una nueva promoción en Mercato obliga a cambiar la misma regla de descuento en varios servicios. Ingeniería propone unificar esa lógica, mientras Producto quiere lanzar una oferta de packs antes de una campaña. Ambas propuestas necesitan capacidad del mismo equipo. El Product Owner debe entender qué permite cada alternativa, qué riesgo sigue presente si se aplaza y cuánta confianza merecen esas expectativas.
Este caso hipotético sigue la decisión desde una propuesta técnica inicial hasta un elemento que se puede discutir en el Product Backlog. El objetivo es hacer comparables sus consecuencias sin fingir que el riesgo técnico y las ventas futuras siempre pueden expresarse mediante cifras económicas precisas.
Describir la restricción que explica la propuesta técnica
La deuda técnica es una descripción útil cuando una decisión previa de diseño o implementación genera esfuerzo adicional o riesgo en el trabajo posterior. No todo mantenimiento, defecto o tecnología desconocida es deuda. En Mercato, la duplicación de reglas de promociones importa porque cada cambio exige coordinar varias partes y puede dejar al checkout y a las devoluciones aplicando condiciones distintas.
«Refactorizar promociones» explica poco sobre la decisión. La refactorización modifica la estructura interna conservando el comportamiento externo previsto. La propuesta necesita identificar qué problema aborda, dónde se observa y qué seguirá funcionando igual. Si también introduce un modelo nuevo de promociones, ese alcance debe quedar visible en lugar de esconderse dentro de la etiqueta de refactorización.
Convertir el problema en un elemento del backlog que se pueda valorar
El equipo revisa los cambios recientes de promociones y documenta dónde hubo que modificar reglas, qué defectos aparecieron y qué ofertas previstas volverían a tocar ese código. Esas observaciones ofrecen un punto de partida. Si no existe un registro fiable, una investigación acotada puede aportar más que una estimación de ahorro aparentemente segura. Ingeniería explica la dependencia y el Product Owner aporta la próxima campaña y las consecuencias de aplazarla.
Un elemento inicial llamado «Refactorizar promociones» puede pasar a ser «Unificar las reglas de aplicación de descuentos que utilizan checkout y devoluciones antes de introducir ofertas de packs». Su descripción debe conservar la explicación técnica y relacionarla con las decisiones pendientes. Entre la información útil se encuentra:
- La duplicación observada y los recorridos o servicios afectados.
- Los próximos cambios que previsiblemente encontrarán esa restricción y sus fechas conocidas.
- La intervención mínima que Ingeniería considera capaz de reducir el problema y sus limitaciones.
- El rango de esfuerzo, el trabajo de migración y comprobación y las incógnitas relevantes.
- Las evidencias que permitirían comprobar si la intervención consiguió el resultado previsto.
Un elemento técnico no necesita convertirse en una historia de usuario artificial. Sí requiere contexto suficiente para entenderlo y ordenarlo junto al resto del trabajo. Las mejoras pequeñas pueden formar parte de implementar un elemento existente con la calidad acordada; una iniciativa separada necesita una conversación explícita sobre su alcance y efecto esperado. Scrum no prescribe un backlog separado para la deuda ni una asignación fija de capacidad para el trabajo técnico.
Comparar alternativas en el mismo horizonte de planificación
La oferta de packs tiene una fecha de campaña y un resultado comercial esperado, aunque la demanda sigue siendo incierta. Unificar las reglas podría reducir los cambios repetidos y las incoherencias, pero Ingeniería todavía no ha confirmado si las devoluciones pueden utilizar la regla compartida sin una migración mayor. Comparar una funcionalidad detallada con una reescritura indefinida dificultaría valorar la alternativa técnica con el mismo criterio.
El equipo examina por eso tres alternativas para el trabajo previo a la campaña. La tabla documenta los compromisos sin asignar puntuaciones inventadas ni tratar una previsión como un retorno garantizado.
| Alternativa | Efecto esperado | Coste o incertidumbre |
|---|---|---|
| Crear la oferta de packs en la estructura actual | Mantener el alcance y la fecha de campaña si caben la implementación y las comprobaciones. | Repetir los cambios de reglas entre servicios y conservar el riesgo de incoherencias y retrabajo. |
| Unificar primero todas las reglas de promociones | Abordar la duplicación entre checkout y devoluciones antes de añadir la oferta. | Migración más amplia, compatibilidad incierta con devoluciones y posible retraso de la campaña. |
| Unificar las reglas necesarias para esta oferta | Reducir la duplicación en un alcance acotado mientras avanza la campaña. | Mantener otras reglas sin cambios y gestionar su coexistencia hasta una decisión posterior. |
La alternativa acotada merece investigarse, pero no es automáticamente la mejor solución intermedia. Puede añadir un adaptador temporal cuyo mantenimiento cueste más que la duplicación eliminada. Ingeniería debe examinar esa posibilidad antes de que el equipo dé por acertado el enfoque incremental. La guía de arquitectura de software aporta contexto para entender estas dependencias.
Explicar qué cambia cuando se aplaza
Aplazar el trabajo técnico puede implicar repetir comprobaciones manuales en cada promoción, aceptar un riesgo conocido de incoherencia o limitar las ofertas que se pueden introducir. Aplazar la funcionalidad puede suponer perder una campaña o retrasar una oportunidad de probar la demanda. Estas consecuencias deben describirse en un periodo comparable, incluida la frecuencia con la que se espera modificar la parte afectada del sistema.
Una regla que cambia a menudo y otra igual de desordenada que está a punto de retirarse plantean prioridades distintas. El equipo debe evitar suponer que toda deuda crece al mismo ritmo o debe eliminarse. Puede decidir mantener un área estable cuando el beneficio esperado de intervenir no justifica su coste, dejando constancia de qué haría cambiar esa decisión.
Si la duplicación actual ya está provocando devoluciones incorrectas, el perjuicio activo al cliente requiere su propia respuesta. Corregir las transacciones afectadas y decidir cómo evitar que vuelva a ocurrir pueden avanzar conjuntamente, pero sus alcances deben quedar visibles. El artículo sobre cómo priorizar bugs como Product Owner aborda la valoración del impacto inmediato y la respuesta correspondiente.
Acordar una intervención acotada y evidencias de finalización
En el caso de Mercato, el equipo puede investigar primero si las reglas de aplicación de la oferta de packs se pueden compartir sin cambiar los cálculos de devoluciones. La investigación debe tener un límite de tiempo, una pregunta concreta y un resultado que permita decidir. Si la respuesta es negativa, el equipo vuelve a las alternativas más amplias con mejores evidencias en lugar de ampliar la iniciativa sin explicarlo.
Para una implementación acordada, finalizar requiere algo más que declarar que el código está más limpio. Puede ser necesario demostrar que las reglas seleccionadas tienen una única fuente mantenida, que checkout y devoluciones conservan el comportamiento acordado y que el despliegue dispone de un procedimiento de recuperación. Las comprobaciones concretas dependen de la arquitectura. Los ejemplos de criterios de aceptación explican cómo hacer verificable el comportamiento esperado, mientras sigue aplicándose la Definition of Done del equipo.
Después de la siguiente promoción comparable, Producto e Ingeniería pueden revisar si hicieron falta menos cambios coordinados, si persistieron las incoherencias y qué trabajo introdujo la nueva estructura. Un lanzamiento aislado no permite establecer una tendencia fiable de productividad. Sí puede mostrar si la restricción original sigue presente y si todavía se justifica una intervención posterior.
Mantener visible la decisión cuando cambian las prioridades
El Product Owner responde de la ordenación del Product Backlog y los Developers conservan la responsabilidad sobre cómo se realiza el trabajo y el cumplimiento de las medidas de calidad acordadas. Una refactorización habitual dentro de un elemento no necesita convertirse en un caso de negocio por cada cambio de código. Una intervención más amplia que desplaza una campaña sí necesita una conversación visible sobre capacidad, dependencias y efecto en los objetivos de producto.
Si Mercato aplaza el resto de la unificación, el registro debe identificar el área que queda sin cambios, las consecuencias conocidas y el evento que activa una nueva revisión. Puede ser la próxima oferta que afecte a devoluciones o la aparición repetida de incoherencias. Reservar un porcentaje para trabajo técnico puede formar parte de un acuerdo de planificación, pero no demuestra que esta intervención concreta merezca la pena.
El libro Deuda técnica para Product Managers desarrolla la evaluación de intervenciones, la comunicación de sus consecuencias y la comparación con oportunidades de producto. Para llevar un cambio a través de los entornos, CI/CD y releases para Product Managers aporta el contexto de despliegue y lanzamiento.
Referencias
- La Guía Scrum: Product Backlog, Developers y Definition of Done.
- Scrum.org: una perspectiva profesional sobre deuda técnica y Product Backlog.