Doscientas posiciones en el backlog, la más antigua de hace año y medio. Ya nadie recuerda quién la registró ni si el problema al que se refiere sigue existiendo siquiera. Cada semana entran más peticiones de las que el equipo cierra, y toda conversación sobre prioridades acaba igual: todo es importante, así que nada lo es. Si diriges una empresa o eres responsable de producto, una lista así no es un problema técnico. Es un problema de decisión. Y se puede resolver sin contratar a tres programadores más.
Antes de acelerar, delegar o recortar nada, hay que ordenar el backlog. No por fecha de registro ni según quién reclama lo suyo en voz más alta.
Paso 1: reparte las peticiones en cuatro cestas
La primera clasificación se hace por impacto en el negocio, no por dificultad técnica:
- Críticas para los ingresos: peticiones que bloquean las ventas, la atención al cliente o la facturación. Cada día de retraso tiene un coste calculable.
- Compliance con fecha límite firme: KSeF, RGPD, el Reglamento de IA. La fecha tope no negocia y la multa puede superar el coste de todo el cambio.
- Quality-of-life: no bloquean nada directamente, pero cuestan tiempo a la gente cada día. Transcripción manual de datos, un informe montado a mano en una hoja de cálculo, apaños a los que todos se han acostumbrado.
- Nice-to-have: ideas que hace un año parecían buenas y por las que nadie ha vuelto a preguntar desde entonces.
De nuestros proyectos sale una observación simple: la última cesta suele ser el 30–50% de toda la lista. Bórrala sin miedo. Si alguna idea hace falta de verdad, volverá sola, y con mejor justificación que la primera vez.
Paso 2: añade el segundo eje, es decir, quién debería hacerlo
Para las peticiones que sobreviven al primer recorte, plantea la segunda pregunta: ¿su ejecución exige un conocimiento profundo de tu dominio o es trabajo estándar de ingeniería? Añadir un campo a un formulario, una integración vía API, un informe nuevo, una migración de datos, pruebas de regresión: todo eso es igual en una empresa de transporte y en un mayorista farmacéutico. La lógica de precios, el algoritmo de planificación de rutas, las reglas de scoring de clientes: eso no lo hará bien nadie que no conozca tu negocio.
De esos dos ejes surge una matriz que ordena las decisiones:
- Urgente y estándar: el mejor candidato para delegar a un socio externo. Entrada y salida bien definidas, poco contexto tribal.
- Urgente y de dominio: tu propio equipo, de inmediato. Aquí no hay atajos.
- No urgente y estándar: delegar por lotes, cuando se acumule un paquete con sentido.
- No urgente y de dominio: aplazado a conciencia, con una fecha concreta de revisión en lugar del eterno «algún día».
Un error frecuente: delegar al revés
Y aquí una opinión, forjada en proyectos de modernización: muchas empresas reparten el trabajo exactamente al revés. Las tareas difíciles, de dominio, las sacan fuera porque «no tenemos gente para eso», y los cambios sencillos los retienen porque parecen baratos. El resultado es doblemente malo. El socio externo pasa años aprendiendo un dominio que la empresa debería controlar por sí misma, porque es su ventaja competitiva. Y el sénior de plantilla quema semanas añadiendo campos a formularios, un trabajo que haría cualquier proveedor solvente. Mantén el núcleo de dominio in-house incluso cuando vaya más despacio. El trabajo estándar, delégalo sin sentimentalismos.
Cómo saber que el backlog se sanea
El número de posiciones de la lista dice poco. Dos métricas lo dicen casi todo:
- La antigüedad de la petición activa más vieja. Si baja de 18 meses a 3, la cola gira de verdad. Si sube, la clasificación fue cosmética.
- El lead time, es decir, la mediana del tiempo desde el registro hasta el cambio funcionando en producción. Es la única medida que el negocio percibe.
Y una prueba de control: el balance mensual entre entradas y cierres. Mientras entre más de lo que sale, ninguna priorización bastará: hay que aumentar la capacidad o recortar con más valentía. Una advertencia: estas métricas se dejan engañar con facilidad. Borrar peticiones antiguas solo para mejorar el gráfico ordena el informe, no la empresa.
Dónde encaja ESKOM AI en este esquema
En este reparto del trabajo ocupamos la columna derecha de la matriz: asumimos los cambios estándar, las integraciones entre sistemas y la automatización de las pruebas de regresión, mientras tu equipo sigue siendo el dueño del núcleo de dominio. Un proceso basado en un equipo de agentes de IA especializados, con una batería completa de pruebas automáticas (unitarias, de integración, E2E, de interfaz, de seguridad y de rendimiento), permite cerrar una petición típica de la cesta «trabajo estándar» en días o semanas; sobre el origen de esa velocidad escribimos en el artículo cómo la IA acorta los plazos de los cambios. Con honestidad: las primeras semanas de colaboración son más lentas, porque tenemos que conocer tu sistema y tu entorno. Ese coste de entrada se amortiza a partir de las siguientes peticiones, así que para una única corrección menor este modelo no tiene sentido. Para un flujo continuo de cambios, tiene mucho.
Por dónde empezar este viernes
Bloquea una hora en el calendario y recorre la lista con una hoja de cálculo al lado: cuatro cestas y luego el segundo eje. Al cabo de esa hora sabrás tres cosas: qué borrar, qué hacer con recursos propios y qué se puede delegar fuera desde ya. Y si quieres repasar este reparto con alguien que lo ha hecho muchas veces, reserva una consulta gratuita a través del formulario de eskom.ai/pl/kontakt. Ven con el backlog exportado. Saldrás con la lista ordenada y con horquillas de plazos realistas para las peticiones que se pueden delegar de inmediato.