¡El software no es ingeniería civil!

Hacer software es complejo. Cada vez exigimos que nuestros software sean “más rápidos, mejores y más inteligentes™”. Hemos cambiado nuestra forma de ver al software y este a su vez ha cambiado nuestra forma de vida. Cosas que hoy parecen tan naturales de hacer con nuestros teléfonos eran ciencia ficción hace apenas unos años.

Indudablemente dependemos cada vez más del software y la necesidad se incrementará a futuro.

Los negocios no han escapado de esta revolución lógica y ya muchos identifican la necesidad real que tienen de automatizar y tener un software que les ayude con su operación diaria.

Y es aquí donde entramos en el problema: necesito contratar un desarrollo de software.

Un proyecto de construcción de software

“Es como hacer una casa”

Históricamente hemos usado analogías que nos permitan imaginar y comprender de una manera más fácil el proceso de construcción de software, un proceso que por naturaleza es difícil de visualizar.

Así que nos decidimos pensar que hacer software, es como hacer una casa. Y tiene sentido, especialmente cuando los desarrolladores nos hablan de etapas y entregables.

Todos hemos visto — aunque sea brevemente — cómo los trabajadores en un construcción levantan poco a poco el edificio, usando los planos para saber en donde deben ir las diferentes partes de la casa: pisos, habitaciones, puertas y ventanas, etc.

Implícitamente sabemos que antes de construir, podemos hacer todos los cambios que queramos al diseño de la casa, pero una vez iniciada la construcción, cualquier cambio puede ser muy caro o simplemente imposible, dependiendo de la magnitud del cambio.

Si tratásemos de hacer un resumen del proceso general de construcción de una casa, podríamos llegar a la siguiente lista:

  • Estudio del terreno
  • Elaboración de los planos
  • Preparación de las bases
  • Construcción
  • Detalles finales

Al final, es un proceso predecible, fácil de visualizar y comprensible incluso para nosotros que no somos ingenieros civiles o arquitectos. Nos pone un orden, nos da expectativas y sobre todo, podemos ver — literalmente — el avance el proyecto.

En realidad, no es como una casa

Cuando comenzó a desarrollarse software a mediados del siglo pasado, se vio una necesidad expresa de tener un proceso concreto y ordenado, donde todas las partes tuviesen expectativas comunes y pudiésemos observar el avance el proyecto. No había precedentes. Era algo totalmente nuevo. Necesitábamos algo que nos diera contexto y nos ayudara a entender este nuevo trabajo.

Se hicieron análisis de requerimientos y se plasmaron diseños (planos). Se tenían trabajadores que seguían los planos para construir el software y se trabajó por etapas.

No es difícil ver por qué comenzamos a comparar la edición de una casa con la construcción de software.

Sin embargo, a diferencia de una casa, hay cosas que difieren grandemente en software:

  • Es difícil de imaginar, sobre todo los proceso que involucran muchas variables y cuyos resultados dependen de la entrada de los datos.
  • Las necesidades cambian constantemente.
  • Es maleable, incluso después de construido.
  • Se presentan cambios en los requerimientos.
  • Se deben considerar factores como cantidad de usuarios al mismo tiempo.
  • Es intangible.

A pesar de esto seguimos viendo el software como si fuese la construcción de una casa; seguimos contratando como si fuera un producto.

Software es un servicio, no un producto

A todo esto, lo que quiero decir es que debemos dejar de ver al software como la compra de un producto — una casa, por ejemplo — donde yo tengo voz en el proceso de desarrollo, sino más bien como un servicio profesional donde yo soy una parte fundamental de dicho proceso de construcción.

La mejor manera de garantizar que una contratación de desarrollo de software salga mal es entregar un documento de requerimientos (los planos) y desligarse por completo hasta que “mi software” esté listo.

Cuando hacemos software, lo natural es comenzar a encontrar necesidades una vez que se haya iniciado el proceso de desarrollo. Para que estas necesidades se construyan correctamente, es de suma prioridad ser participe del proceso y estar en constante comunicación con sus asesores tecnológicos, comúnmente denominados programadores.

Dicho desarrollo explorativo, donde se va encontrando qué hacer conforme se avanza en el proyecto, es la forma correcta de hacer software. Tratar de plasmar todas mis necesidades en un documento de requerimientos (planos) no solamente es innecesario sino que también viene a ser una tarea, para fines prácticos, imposible.

Debemos dejar de ver al software como un producto. Mientras este pensamiento no cambie, seguiremos teniendo problemas a la hora de contratar para un desarrollo.


Pablo Peraza es el Director Ejecutivo de Ciris Informatic Solutions

Puede visitarnos en www.ciriscr.com