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.

Viviendo en el bazar: La diversidad siempre gana

Una característica que tiene lugar en los proyectos Open Source y sobre la que no se suele hablar es la diversidad.

En los proyectos abiertos no se suele controlar el ingreso de los miembros del proyecto, no se verifican calificaciones técnicas ni se realizan pruebas de inteligencia ni de personalidad, no se buscan perfiles concretos, no hay entrevista previa, sencillamente la gente se incorpora al proyecto.

No me refiero exclusivamente a la diversidad étnica, o de sexo, ni de nacionalidad (que, por supuesto, también ocurren) me refiero a la diversidad al completo, incluyendo diversidad de personalidades, diferentes estilos impersonales, distintas culturas, etc.; al no controlar lo que puede haber, resulta que hay de todo. Puede que tengan más cosas en común de las que parecen, pero al menos hay una que si es segura; el interés por un objetivo común.
Este aparente caos que seguramente no sea entendido por muchos departamentos de Recursos Humanos, resulta en una ventaja casi imbatible: la diversidad.

Las pruebas que se han mencionado anteriormente, con sus muchos aspectos positivos, en la práctica tienden a configurar equipos homogéneos; la mayoría de los participantes tienen formación similar, estudios similares, personalidades similares. Es normal si se considera que muchas de las pruebas se basan en estudios estadísticos en los que las desviaciones no suelen favorecer al candidato.

La diversidad en los equipos promueve una mejor toma de decisiones y una mejor resolución de problemas. Décadas de investigación1 han demostrado que la heterogeneidad suele batir a la homogeneidad en casi todas las situaciones. Equipos de hombres y mujeres resuelven mejor los problemas que equipos de un solo sexo, grupos con varios especialistas funcionan mejor que equipos de un solo tipo de especialistas.

No resulta sencillo abordar la diversidad, estamos acostumbrados a una concepción idílica del trabajo en equipo formado por fantasías de perfecta cooperación y sin conflictos. La gente suele preferir trabajar con gente que sea parecida a ella misma. Los estereotipos de grupo pueden llegar a tener impactos negativos sobre el grupo y se tiende a excluir a "lo diferente" de las redes de información del grupo.

La diversidad puede crear conflictos difíciles de resolver sobre todo si transcienden de los límites de la cooperación. En los proyectos Open Source llega a resultar una ventaja el que los integrantes ni siquiera se conozcan físicamente, a lo que se une la compartición de objetivo ("estamos construyendo algo juntos").

Los equipos se empobrecen si excluimos a la diversidad, de la misma forma que se empobrece la vida misma. Necesitamos a los críticos, a los solitarios, a los opositores, a los que lo hacen todo "a su manera" y a otras formas de "notificadores de problemas". Es necesario observar distintas formas de liderazgo y respuesta al liderazgo, incluso resistencia y oposición al liderazgo que sea capaz de mantenerlo en sus límites, se necesitan gente dinámica a innovadora capaz de crear ideas y se necesita gente no tan creativa pero más metódica capaz de llevarlas a cabo, se necesita crítica y escepticismo capaces de mantener el entusiasmo desbocado controlado por la fría duda.

Quizás, en las dinámicas de equipo, la frustración individual no sean tan importantes como la eficacia del grupo, pero atención; no debemos perder el respecto por la individualidad mientras observamos el valor de la cooperación.

Viviendo en el bazar (Intro)

En 1997, Eric Steven Raymond publicó su famoso documento "The Cathedral and the Bazaar" en el que analiza su participación directa en un proyecto Open Source asumiendo el rol de coordinador del proyecto. A mediados de 1998 llega a mis manos un ejemplar de este documento en el que veo plasmada, por primera vez, lo que a muchos empezaba a representar un movimiento cuando menos sorprendente.

¿ Cómo era posible que se estuviese generando tanto software y de tan buena calidad en un entorno aparentemente caótico ? Los participantes de los proyectos no reciben recompensa económica alguna (al menos directa o a corto plazo), cualquiera puede sugerir cambios e incluso realizarlos, no se parte de especificaciones iniciales, los diseños se rehacen sin mayores problemas y la documentación parece escasa. Hmmmm, esto me recuerda que tengo que hablar sobre la importancia de la motivación intrínseca respecto a la extrínseca. Si de verdad quiere un equipo ganador, recuerde estas palabras; motivación intrínseca (ya hablaré sobre esto, no lo dude).

No podía evitar comparar estos resultados con los proyectos informáticos que me rodeaban. Todos estos proyectos se desarrollaban en lo que Raymond denomina el estilo "Catedral" (en el que incluye, además de las consideraciones económicas, intensos formalismos más o menos restrictivos junto con fuerte tendencia a la aplicación de aproximaciones metodológicas tradicionales) y sus resultados no eran malos, incluso podía decirse que eran buenos, excepto cuando eran comparados con otros proyectos Open Source. Ninguno de los proyectos que observaba resistía la comparación dignamente.

A lo largo de estos años he seguido observado esta circunstancia en otras compañías, en otros proyectos, he recogido información y sensaciones de otros profesionales y sus experiencias y, por fin, me he decidido a plasmar una buena parte de las impresiones en una serie de artículos. He de dar las gracias a un querido amigo y compañero que en un artículo de su blog me trajo a la memoria lo que al final será el hilo conductor de esta serie.

Vivir en el cambio, en el dinamismo, en proyectos donde el Cliente representa nuestro principal control de calidad, con tecnologías emergentes y novedosas y con la presión de ajustes constantes en los presupuestos, es lo que me ha llevado a titular esta serie "Viviendo en el bazar" , ya que es en el bazar de Eric Steven Raymond donde se dan estas circunstancias, son las que debemos conocer y asumir y a las que no tenemos que temer. Seguramente será ahí donde reencontremos la ilusión de diseñar sistemas que algún día tuvimos y que de alguna forma se ha ido apagando por el camino.

Viviendo en el bazar reflexionará sobre algunas de las practicas habituales en la realización de proyectos, preguntándose qué podemos estar haciendo tan diferente respecto a la comunidad Open Source y repasando algunas de las creencias más extendidas en el mundo del desarrollo del software.

Espero que su lectura le resulte útil, pero si no fuera así, confío que por lo menos le introduzca en un mundo distinto, le haga reflexionar sobre cómo hace las cosas o, sencillamente, cómo querría hacerlas.