Viviendo en el bazar (tal como dice el manual)

Con frecuencia se hacen analogías entre los desarrollos software y otras disciplinas de la ingeniería, incluso se ha acuñado el término ingeniería del software como una manera de expresar la formalidad de ciertas aproximaciones, al mismo tiempo este término parece rozar la ironía; se trata de técnicas de ingeniería del software (¿ no le parace que es algo así como decir, "si, pero no del todo" ?).

Es deseable disponer de un método claro, que me pueda reportar resultados predecibles, incluso con personal poco cualificado, pero ¿es el software un proceso predecible?. Si las reglas de juego cambian suele aducirse a una mala planificación, pero ¿realmente esto es siempre así?. Existe una creencia generalizada por la cual el software es fácil de cambiar y resulta complejo ir contra esta corriente. Los negocios cambian, la competencia cambia, nunca se sabe dónde aparecen nuevas oportunidades y el software no hace más que reflejar esta situación.

En los procesos de ingeniería las técnicas aplicadas han tenido años de experimentación y mejora, construir un edificio o trazar una carretera no es algo exclusivo de los últimos 60 años, aun así, no parace que sea el paraiso de orden y eficacia que la profesión informática piensa. Si, es una especie de mito en la profesión informática que ha llegado a adoptar nombres y términos de estas profesiones para designar a roles ; p.ej. Arquitecto de software. Lo más triste es que cuando un buen y altamente productivo programador, confundido por algunos mensajes, cree que ha llegado el momento de "evolucionar" deja de ser programador para ser Arquitecto. Lo cierto es que suele ser el principio del fin de un buen profesional.

En determinados proyectos informáticos la técnica es aplicable, pero en otros parece que no es así y las metodologías pasan de la utilidad al estorbo con facilidad. Si aparece una situación poco predecible no parece adecuado emplear un método que requiere un proceso predecible. Durante un tiempo intentará pequeños ajustes hasta que descubra que el modelo que está aplicando sencillamente no lo sirve.

Si, efectivamente, muchos proyectos hacen uso de técnicas disciplinadas y ordenadas para redefinir la realidad y conseguir un resultado predecible. Entonces, ¿ por qué vuelven a ocurrir situaciones de desastre en tantos proyectos ?. La repuesta no parece simple pero hay una serie de circunstancias que concurren en muchos proyectos que intentan la aplicación de metodologías:

• No son suficientemente conocidas o simplemente son difíciles de aplicar. Muchas de las metodologías exigen un gran esfuerzo de aplicación, no son siempre bien entendidas y la cantidad de información generada queda, de alguna forma, fuera de control. La falta de preparación de los equipos o la complejidad de las mismas dificultan su aplicación, los ajustes en las planificaciones obligan a los equipos a saltarse aspectos importantes de las metodologías con lo que se incurre en situaciones caóticas con mucha facilidad.


• No suelen ser adaptables. Las metodologías tradicionales, inspiradas en prácticas de la ingeniería, se basan en procesos que incorporan fases más o menos predecibles. Requieren de unas complejas tareas de descripción y diseño que permitan predecir el trabajo posterior. Suponen pequeñas desviaciones que pueden ser incorporadas en el proceso, pero grandes variaciones pueden llegar a invalidar todo lo establecido.


• Una de las frases más escuchadas últimamente es; "el problema con este proyecto es que los requerimientos no están cerrados". En la práctica, muchas veces ni siquiera es deseable contar con requerimientos estables. Lo que hoy puede ser un buen juego de requerimientos puede que no lo sean tanto en los próximos tres meses, y esto, de forma generalizada, es mal acogido por las aproximaciones metodológicas tradicionalmente aplicadas.


• No todas las metodologías parecen adecuadas para todos los tipos de proyectos. Es evidente que un proyecto de e-business no parece necesitar la misma metodología que la industria aeroespacial, los compromisos y prioridades son muy diferentes. En realidad, no todos los proyectos de e-business tiene porqué requerir la misma aproximación metodológica.

Aunque tremendamente positivas, parece que las metodologías no resultan infalibles.

Ah, por cierto, soy consciente que no empleo el término metodología con corrección, debería decir método, sin más. Metodología se refiere al estudio del método, pero la verdad es que están tan extendido el uso de metodología como método que no lo voy a cambiar.

Observemos el uso de las metodologías (métodos) tradicionales y tratemos de entender algunos de sus problemas. Para esto no enumeraré distintas metodologías, sino que se analizarán algunos de los aspectos más generales que tienen lugar en las prácticas habituales.

Al fin y al cabo ¿ qué es una metodología ?.

Un buen punto de partida podría estar en los inicios de la metodología en sí. Descartes, en su obra "Discurso del método para dirigir bien la razón y buscar la verdad en las ciencias" (más conocido por "El Discurso"), establece una serie de reglas que entiende que son de aplicación a cualquier aproximación metódica y que vienen a ser algo así como:

1. Evitar los prejuicios


2. Dividir los problemas en tantas partes como sea posible.


3. Partir de lo simple antes de pasar a lo complejo.


4. No dejar nada fuera.

Hasta aquí todo bien; se describe una procedimiento analítico, buscando la exahustividad mediante un procedimiento iterativo. Ciertamente Descartes no cerró el debate sobre el método científico pero estas prescripciones pueden ser una forma sensata de ser metódico y, cuando menos, puede ser una excelente receta.

En su escrito "Reglas para la dirección del espíritu" se puede leer:

"Pues por método yo entiendo reglas ciertas y fáciles, mediante las cuales, todos los que observan exactamente no supondrán jamás verdadero aquello que es falso, y llegarán, sin fatigarse en esfuerzos inútiles, al conocimiento verdadero de todo lo que pueden alcanzar".

Se ha resaltado la necesidad de la facilidad de las reglas como una táctica que permita su aplicación manteniendo uno de los objetivos enunciados: "sin fatigarse en esfuerzos inútiles".

Siguiendo en la misma idea, me sorprendió tremendamente cuando leyendo el famoso libro de estrategia bélica oriental; "Sun Tzu, El arte de la guerra" ,me encontré con el siguiente párrafo:

Por lo tanto, los que conocen las artes marciales no pierden el tiempo cuando efectúan sus movimientos, ni se agotan cuando atacan. Debido a esto se dice que cuando te conoces a ti mismo y conoces a los demás, la victoria no es un peligro; cuando conoces el cielo y la tierra, la victoria es inagotable.

Que interpretado viene a decir algo así como "considere realmente conseguir que lo dificil se convierta en fácil". No parace mala receta ¿ no ?.

La diversidad de orientaciones metodológicas a lo largo de la historia señala que la cuestión del método es algo más que una cuestión de procedimiento, pero en lo que suelen coincidir los distintos autores es en que el método posibilita una aproximación progresiva a la adquisición de conocimiento. Y en este punto vuelve a ser interesante señalar que la obtención de conocimiento se realiza en un proceso progresivo.

No sé que conocimientos científicos tiene usted, es posible que proceda de estudios de ingeniería o de otras disciplinas, pero resulta muy interesante ver qué uso ha hecho la ciencia de una aproximación metódica para conseguir logros tan productivos.

¿ Qué es ser un científico ?; pues así, de golpe, aquel que aplica el método científico, pero ¿ sólo hay un método científico ?, pues si y a la vez no. La respuesta puede paracer ambigua, pero en su formulación reside parte de la esencia del método científico.

El método científico es uno, pero se trata de un "armazón" abstracto que en su secuencia, en los primeros pasos, dirige hacia la redifinición del propio método para adaptarlo a la investigación en curso. En sus primeras fases exige planear el resto de fases, y por planear no me refiero a hacer una hoja de proyecto, me refiero a definir técnicas, pasos, métodos, aproximaciones tácticas para abordar la investigación.

A ningún científico se le ocurriría abordar una investigación sin planear el método a usar (siempre, por supuesto, bajo las metadirectrices del método científico), pero en la profesión informática es curiosos cómo, la más de las veces, el método usado se define con anterioridad al problema. Esto es así hasta el punto que en muchas compañías, como Reponsable del Proyecto se entiende a una persona que sabe aplicar los pasos definidos en un mètodo concreto, independiente del problema con el que se afronte.

La verdad es que a estas alturas no nos debería extrañar tanto los resultados que se llegan a obtener en los proyectos informáticos: Según el informe del Standish Group’s Chaos Report, se reportó una relación de éxito en el 34% en los proyectos, no quedando clara la influencia del método usado como variable independiente al ofrecer una varianza muy poco significativa. El dato de por sí ya es interesante, pero también fíjese como el informe evalúa el método usado pero sin ofrecer medidas de relación con el tipo de problema con el que se enfrentó cada proyecto. Parece que la tendencia a considerar el método particular, por si mismo, está más establecida de lo que parece.

Algunas compañías decidieron romper esta tendencia, y su iniciativa no ha pasado desapercibida. Un ejemplo es Toyota y su Just in Time. En los escritos de Shigeo Shingo uno de los aspectos centrales, y que nos acerca al tema que estamos tratando, es cómo expone la necesidad de aplicar el método científico a los procesos industriales. Curioso, ¿ no ?, y más si se considera qué representa Toyota en el mundo de los procesos.