Este es la primera entrega de una serie de artículos que he escrito sobre el proceso de desarrollo de software y sitios web. Con esta serie planeo exponer algunas de las conclusiones, ideas y anécdotas que he recopilado de libros, artículos y algunas experiencias personales y otras de personas de mi entorno. Mi principal objetivo es brindar una pequeña guía a modo de resúmen sobre un tema que muchas veces no es tocado lo suficiente, o a veces demasiado. Son muchos los sitios que hablan sobre como programar en una tecnología o como hacer que aparezca un efecto en nuestro sitio web. Pero de nada servirán si es que no son acompañados de un marco general que permita a aquellos que se inician en esta vía ubicar cada pieza del rompecabezas.

Comencemos con una historia

Arturo Álvarez regresó aquel día de una entrevista con un nuevo cliente. El nuevo proyecto sonaba bastante bien para él y la reunión que había tenido le había dado una idea sobre lo que debería hacer. Sin pensarlo dos veces, se sentó en su equipo, aquel computador que tanto esfuerzo le había costado armar y comenzó a programar. Clase tras clase, función tras función, comenzó a bosquejar el sistema. Y todo estaba bien.

Al día siguiente, tras haber trabajado toda la noche, se presentó a su cliente con un prototipo funcional. El cliente estaba realmente sorprendido: su anterior conocido le había estimado casi dos meses de trabajo para hacer lo que aquel "tigre" había hecho en un día. Revisó la pantalla, le pareció que estaba bien y lo felicitó. Cancelo también un buen porcentaje del monto definido.

Esa noche Arturo celebró con un par de pizzas, palitos de queso y una sesión de World of Warcraft. Y todo estaba bien.

Como ya había avanzando bastante lo que había acordado, decidió darse unas merecidas vacaciones. De todas formas, le quedaba todavía cuatro semanas -el tiempo que había estimado para la entrega.

Días después continuo con el trabajo. Ya había finalizado la base de datos, las pantallas y terminó finalmente enlazándolas. Contento, acudió a entregar el sistema a su cliente.

Este lo revisó, y le pareció que estaba bien. "Sólo una cosa más, Arturo. Este sistema lo utilizará el Jefe de Operaciones y el de Logística. Por favor, muéstraselos a ellos para ver si no falta algún detalle". Y todo no estuvo bien.

Cada Jefe respectivo revisó el sistema, y lo encontró totalmente errado. Cambios y cambios se fueron acumulando y nuestro amigo Arturo se empezó a preocupar. Ambos Jefes hicieron también que lo revisaran sus subordinados. Y los cambios fueron aumentando. Rehacer la interfaz, agregar estos datos, cambiar la forma de ingresar las órdenes -¡tener diversos tipos de órdenes! Y ya que estaba en eso, ¿porqué no agregar la capacidad de integrarse con sus sistema de correos?¿Y si lo agregan a la Intranet?¿Pueden agregarse luego más procesos, no? ¿La información no la podemos jalar de los proveedores? ¿Y si los empleados la ingresan desde sus casa?

No es necesario mencionar que para este punto, Arturo se encontraba ya con una pistola en la sién, maldiciendo la hora en que decidió ser un programador y preguntándose si no lo aceptaría su hermano en su empresa de procesamiento de papel reciclado.

¿Suena familiar? Desgraciadamente es un escenario muy típico entre los elegimos alguna vez dedicarnos al desarrollo.

¿Necesitamos una metodología?

 La respuesta que muchos le dan es afirmativa. Yo creo que antes de poder responder eso, necesitamos entender qué es una metodología. Existen muchas definiciones sobre el término,  pero principalmente, muchos la describen como el conjunto de recomendaciones para realizar un proceso, extraídas de la experiencia y el juicio de expertos en el tema y que son aceptadas por las personas como tales. Son aquellas buenas prácticas basadas en la experiencia de ajenos que nos ayudarán a evitar errores (o disminuir su incidencia).

Sin embargo, nos enfrentamos a un punto importante: no existe una metodología perfecta. Si aceptamos eso como tal, nos libraremos de muchos problemas. Lamentablemente, el mundo está lleno de personas que adoptarán su metodología como su razón de ser y aunque puedo comprender que sientan que han encontrado el Santo Grial, no hay una única metodología, y no hay ninguna que sea perfecta, así como nngún software lo es.

Revisemos otro punto adicional: cualquiera que sea la metodología que adopten en un proyecto o en la empresa en general, no son recetas que uno puedo utilizar y esperar los resultados de forma directa. No hay verdades absolutas.

¿Pero porqué habría de servirnos una metodología? Por son un conjunto de prácticas y pasos que han sido validadas por el consenso de varios profesionales. Han sido aceptadas como tal porque muestra un seguimiento lógico, entendible y propio.

Realizar un desarrollo de software o de sitio web utilizando una metodología nos permite mantener un orden y estructura sobre cómo hacer el proceso. Nos permite concentrarnos en la lógica y el giro del negocio al que nos abarcamos y no ya en como haremos el seguimiento de los clientes; nos permitirá tener una guía para saber cuando y en qué manera obtener los requerimientos de nuestros clientes y como saber atenderlos.

En la siguiente entrega hablaré sobre en qué casos no aplicaría una metodología, la diferencia (si es que la hay) entre una metodología de desarrollo de software y de sitios web y continuaré con la introducción al tema.