Ya he hablado en otras ocasiones sobre la importancia de decidir qué es exactamente lo que vamos a hacer cuando estamos desarrollando software. Incluso a veces me atrevería a decir que tan importante como saber lo que vamos a hacer es saber lo que NO vamos a hacer.

Hace poco he tenido que planificar las funcionalidades que íbamos a incluir la siguiente versión de una de las aplicaciones estándar que desarrollamos en la empresa para la que trabajo y, quizá por experiencias no muy positivas en versiones anteriores (hay que ser positivos, de todo se aprende), he acabado planteándome un factor que a veces se ignora durante las planificaciones: el riesgo.

Me refiero al riesgo en el sentido más amplio de la palabra, no al riesgo que aparece en los Diagramas de Gantt y otras herramientas típicas de ingeniería del software (disciplina de la que, por cierto, ya hablaré en algún momento).

En toda aplicación existen partes funcionalmente más importantes que otras. Si estás desarrollando un procesador de texto, es mucho más importante poder guardar un documento que poder cambiar el interlineado entre párrafos, por ejemplo. Obviamente realizar desarrollos que afectan a las partes más importantes de la aplicación supone un riesgo mayor, aunque también hay ocasiones en que permiten obtener mayores beneficios.

Además, los que nos encargamos de hacer la aplicación somos conscientes de que hay partes de la aplicación que, internamente, son más complejas de tocar. A veces esto se debe a que están mal diseñadas, en cuyo caso podemos considerarlas como deuda técnica (technical debt) y deberíamos reservar un hueco para refactorizarlas; pero otras veces se trata simplemente de tareas inherentemente complejas que no podemos (o no sabemos) simplificar.

Modificar estas partes más complicadas de tocar supone un riesgo mayor, porque es más fácil introducir fallos y, en ocasiones, también es más difícil encontrarlos durante las pruebas (incluyo aquí test unitarios, de integración, manuales, betas, todo lo que estés usando para controlar la calidad).

Por último, algunos desarrollos son arriesgados de por si debido a que son más complicados de realizar (aunque afecten a partes de la aplicación fáciles de tocar), porque no estamos seguros de si serán útiles o no, o por cualquier otro motivo.

Por desgracia, muchas veces este tipo de factores no se tienen en cuenta (o tan en cuenta como deberían) y cuando llega el momento de priorizar nuestro backlog de producto, sólo nos guiamos por cosas como:

• El tiempo que se tarda en implementar la funcionalidad/historia-de-usuario/lo-que-uses.
• Lo prioritario que es algo, ya sea basándonos en las peticiones de nuestros usuarios o en nuestra visión del producto.

Ambos son factores razonables. El primero es que va a marcar si tendremos tiempo o no de implementar las cosas en la siguiente versión y el segundo actúa como “indicador” de valor para dar prioridad a aquellas cosas que se supone que van a generar más valor. Sin embargo, centrarnos sólo en esos dos factores sin tener en cuenta el riesgo que entraña cada implementación es… arriesgado.

Por una parte, podemos comprometer la estabilidad de la aplicación al añadir muchas áreas de incertidumbre simultáneamente y, creéme, prefiero un procesador de textos que no es capaz de cambiar el interlineado que uno que pierde mi trabajo cada 5 minutos.

Por otro lado, cuando añadimos muchas cosas con riesgo elevado en la misma versión/sprint/lo-que-uses, también estamos dificultando cumplir los objetivos de tiempo que tenemos impuestos, porque es más fácil que las cosas se compliquen durante la fase de implementación o pruebas y no podamos mantener la planificación original.

Hay veces que es necesario asumir riesgos y eso no es malo, pero lo que es importante es ser consciente de que se están asumiendo. Está claro que el que no se arriesga no consigue nada, pero también está claro que arriesgarse a lo loco es una receta clara para el fracaso.

A veces es preferible limitar los riesgos que asumimos en cada versión y avanzar más despacio, si eso nos permite mantener la aplicación más sólida y segura.