NOTICIAS · · 2 MIN DE LECTURA
La Voyager 1 y el coste basal de los proyectos
La NASA arregló el software de una nave a 24.000 millones de kilómetros. Una buena excusa para hablar de lo que cuesta mantener todo lo que construimos.
En abril de 2024, tras cinco meses de trabajo, un equipo de ingenieros de la NASA consiguió desplegar software nuevo a 24.000 millones de kilómetros de la Tierra. La Voyager 1 había dejado de enviar datos legibles al centro de control en noviembre de 2023, después de que fallara uno de sus chips de memoria, y claro, mandar al informático de turno a repararlo parecía inviable.
Tras esta hazaña de desarrollo de software, enviada a producción el 18 de abril, la Voyager 1 volvió a enviar telemetría (los datos sobre el estado de la propia nave), y el equipo confiaba en recuperar con una segunda actualización los datos de los instrumentos científicos. Lo cuenta la propia NASA.
El coste basal
El metabolismo basal es la cantidad de energía que necesita el cuerpo humano para mantenerse con vida a lo largo del día: lo que gastamos simplemente por existir. Pues bien, este concepto se puede aplicar a la gestión de proyectos y, cómo no, al desarrollo de software. Y eso también lo saben en la NASA.
Si pensamos en la implementación de una funcionalidad, su coste basal es la suma de la complejidad que añade al sistema (dependencias, código, nuevos errores…) y del coste que provoca en el desarrollo o la evolución del resto de piezas que son incompatibles, están acopladas o hay que actualizar.
Un error común es descuidar el coste basal y pensar que, si una funcionalidad no se toca, su coste continuo es cero. Quizá esta visión venga de profesiones como la arquitectura o la construcción, donde los proyectos se entregan y, en principio, no necesitan mantenimiento. Pero no suele ser así en la gestión de proyectos ni en el software.
Si fuera cierto, el gráfico sería una sucesión de funcionalidades cuyo coste vuelve a cero sin dejar mantenimiento. Pero eso solo pasa en un mundo ideal.
La capacidad es finita
La realidad es que los costes basales de cada funcionalidad se van sumando hasta alcanzar la capacidad del equipo de desarrollo (o del equipo de gestión, en el caso de los proyectos). A partir de ese momento se empieza a perder la oportunidad de innovar, simplemente por tener que ocuparse del mantenimiento del propio sistema.
Conclusión
La idea lean detrás de todo esto es buscar la simplicidad en todos los procesos y eliminar desperdicios (muda, 無駄). Lo que nos dicen Lean y sus variantes, como Lean IT, es que es mejor eliminar las funcionalidades que no tienen el impacto deseado, la obsolescencia y las dependencias.
Simplicidad es el arte de maximizar la cantidad de trabajo no hecho.
Principios del Manifiesto Ágil
