¿El backlog cuesta dinero?

Mantener inventario cuesta dinero. Ya sean sacos de plástico apilados al lado de la máquina para ser inyectado, tomates en una nevera de un restaurante, o pantalones en un camión esperando su transporte, es dinero almacenado. Además existe la posibilidad de que si hay una inundación, entran bichos, o simplemente se pasa de moda, pierde su valor.

Lo más fácil sería que no fuera necesario mantener ese material almacenado, pero claro eso tiene otros costes asociados. No te puedes quedar fuera del negocio por no tener ruedas para fabricar más coches o cerveza para servir un día caluroso. De ahi el Sistema de producción Toyota, precursor del «Lean manufacturing» o la Teoría de las restricciones o limitaciones (Theory of Constraints, TOC).

Pero, ¿esto también sucede cuando hablamos del desarrollo de un producto digital?

Pues si, que no sea un producto físico y tangible, no significa que no tenga grandes costes asociados.

En cada una de las etapas por las que pasa el código antes de llegar al consumidor final, es «producto almacenado». Desde la User Story definida por el product owner, hasta el tiempo que un tester se pone a probar el código desarrollado, es material almacenado.

El coste del inventario de código es enorme.

En algunos casos pueden tardar meses en llegar a las manos del consumidor final. Esto puede ser la diferencia entre sacar al mercado un producto novedoso o estar constantemente copiando a los más vendidos. Y es que ser el primero muchas veces marca la diferencia en un mercado donde los consumidores están constantemente pensando en la siguiente novedad.

Y dado que los recursos que normalmente se disponen en las empresas son escasos, es muy importante focalizar y no perder tiempo en escribir algo que no va a ser utilizado o salir a producción.

Backlogs

Durante el desarrollo de un producto digital pueden surgir muchas ideas de funcionalidades que jamás llegan a ver la luz. Tal cual vienen, ya sea en una sesión de grooming o porque un cliente o alguien de la empresa hizo una sugerencia, se escriben y se almacenan en un backlog.

El problema es que el 90% de las cosas que están en el backlog nunca se implementarán. NUNCA.

Por ello cada minuto que se gasta escribiéndolas, detallándolas, diseñándolas o discutiéndolas es tiempo desperdiciado.

La mente es compleja, y como describe la metodología GTD® (Getting Things Done® de David Allen) es mejor poner algo por escrito y dejar de pensar en ello, que no tenerlo rondando por la cabeza y estar inquieto. Pero debe almacenarse en el lugar correcto y de la forma correcta. A lo mejor una línea de texto en la herramienta que uses de forma personal como PO bastará para almacenar esas ideas que jamás se programarán.

Por ello, no permitas tener más de un mes o dos de trabajo en la lista de backlog. Y una vez que el backlog esté lleno, si quieres meter algo nuevo, borra un elemento de lo que ya está dentro.

En mi caso he llegado a un nivel en el que no avanzo un diseño ni documento nada sobre una User Story a no ser que sepa seguro que el equipo de desarrollo lo va a hacer. Otra cosa es que tengamos dudas sobre si hacer A o B y hagamos un prototipo rápido para testearlo.

Listado de errores

Lo mismo sucede con los errores (o bugs) detectados en la herramienta. De repente, hay más de 200 incidencias con la etiqueta de error en el JIRA, algunos de los cuales ya se han solucionado con otras tareas, nunca pueden volverse a reproducir o no vale la pena dedicar tiempo porque sólo afectan a un porcentaje muy pequeño de usuarios (y encima de los que te generan menos beneficios).

Cuando piensas en cuanto tiempo se ha tardado en reportar y escribir esos errores, y como a pesar de su existencia tu producto es vendido, y usado una y otra vez por miles de usuarios, dices, ¿me estoy centrando en mejorar mi producto?

Por ello, usa un sistema que permita decidir si merece la pena reportar ese error, y no permitas que pase más de 2-4 semanas en arreglarse. Si tienes errores más importantes, para y arréglalos hasta que sientas que estás solucionando cosas sin importancia. Una vez hecho eso limpia el listado de errores. No te preocupes si son gordos volverán.

Esto me suena a cuando hacemos tests con usuarios. Es mejor hacer 2 tests con usuarios, uno primero con 5-6 usuarios y otro segundo con otros 5, que hacer uno solo con 10. ¿Por qué?

Test de usuarios

Imagen del libro de Steve Krug «No me hagas pensar»

Con 5-6 personas, se van a detectar, por ejemplo, 4 errores problemas grandes de usabilidad y 3 pequeños. Es mucho mejor parar y arreglar esos 4, y volver a probar con 5 usuarios nuevos que no gastar este tiempo y dinero en 10 usuarios que seguramente detecten los mismos errores.

Funcionalidades no lanzadas

Otro de los grandes sitios donde se almacena inventario de software es en aquellas funcionalidades no lanzadas. Muchos equipos siguen sin hacer «continuous deployment» o porque no lo tienen integrado como parte de su procedimiento o porque su proceso de deploy es costoso.

Tener una funcionalidad desarrollada y que tardé en llegar a manos del cliente puede ser la diferencia entre que la empresa sobreviva o no. Por ello intenta realizar lanzamientos a producción tan a menudo como sea posible, cuanto más pequeños mejor. Aparte de tener a los usuarios finales felices con novedades cada semana, el proceso de testeo será más rápido. Tu equipo lo agradecerá.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *