Formalizar hasta paralizar.

Acabo de leer, en una de esas casualidades que necesariamente se dan en cualquier proceso caótico (como lo es mi lectura en el reader) estos dos artículos:

Por un lado,El 73% de las pruebas de desarrollo ágil han sido un éxito (Navegápolis), que comienza con las siguientes citas:

"...Los estándares para mejora de procesos de software se han tenido como forma para superar estos retos. CMMI es un ejemplo de estándar empleado por empresas de software. Según los datos del Instituto de Ingeniería de Software (SEI), aplicar este tipo de mejora suelen suponer entre tres y cinco años, y también requiere bastante inversión, de 10.000 a 45.000 euros por ingeniero (Jones 1999)... Finalmente, más del 70% de estos procesos de mejora fallan..."

"...El 73% de las pruebas de desarrollo ágil realizadas se han considerado un éxito. El estudio ha empleado métodos ágiles en el desarrollo de software empotrado en 68 empresas, implicando a 1.800 ingenieros en 17 compañías europeas en un periodo de dos años y medio..."

Luego, ¿Granizada sobre mi proyecto? El regreso de los cuellos de botella fantasma (Dirección de Proyectos):

Nuestro miedo al conflicto –en un proyecto, aunque sea en pequeñas dosis, es inevitable- hace que, para evitar que llueva y mojarnos, sobreenfriemos el ambiente. Lo único que conseguimos es crear artificialmente una situación metaestable que dura lo que se tarda en que cualquiera de los pequeños detalles que se suceden continuamente en el proyecto, una mínima chorrada, desate la caja de los truenos y una tremenda granizada asole nuestro proyecto. ¿Efecto mariposa? No, efecto “todo va bien”. Y, como dice Murphy, si crees que todo va bien en el proyecto es que no te estás enterando de nada.

Atravesar un proceso de desarrollo de software es atravesar el conflicto: con los clientes, su negocio, el "nuestro", el de cada uno de los integrantes del equipo en particular... entre todos con la tecnología, las comunicaciones, el tiempo y el uso de los recursos.

Conflicto implica riesgo y oportunidad. Sin conflicto no habría proyecto.

Pero los seres humanos (y sobre todo aquellos que son responsables de la dirección de un proyecto o inversores en él) hemos desarrollado cierta aversión al riesgo, y por ende cierta aversión a los conflictos.

Así que buscamos formas de minimizar el riesgo (conflicto), manteniéndolo dentro de ciertos parámetros, que son controlados obsesivamente. De una manera o de otra, con mayor o menor énfasis, los pasos especificados por cualquier metodología (desde el tradicional ciclo de vida hasta Scrum o Xp) intentan manejar el conflicto (riesgo).

Por ello se especifican detalladamente los requisitos o se tiene a un cliente en el equipo de desarrollo. Se diseña en forma cada vez más detallada hasta llegar a la más ínfima porción de código o se diseña pensando en el cambio continuo. Se prueba intensivamente toda la funcionalidad o se realizan varias entregas incrementales....

Como vemos, las metodologías son opuestas pero el objetivo es siempre el mismo: la minimización del riesgo, la resolución del conflicto antes de que éste aparezca (diseñamos todo para que no haya cambios o diseñamos para el cambio antes de que éste se presente).

Del otro lado del mostrador, en donde el término "metodología de desarrollo de software" no significa absolutamente nada, el cliente (o el inversor) también quiere minimizar el riesgo.

¿Pero cómo? No puede controlar el proceso, sólo el avance... pero ¿cómo podría diferenciar un sistema completado en un 50% de una muy bonita cáscara vacía?

Puede requerir que se cumpla con determinadas prácticas que son, a juicio de expertos (personas u organizaciones) en las que él confía, las mejores. Es decir, por referencias, de la misma manera en que confiamos en un plomero que viene a arreglar ese problemilla de humedad tan molesto.

Y aparecen las certificaciones.

Perfecto. Pero cierta lógica perversa en cómo se instrumentan las certificaciones tergiversa las cosas.

El cuento es conocido se lo mire por donde se lo mire:

Del lado de los grandes es "he invertido tiempo y dinero en certificarme, ahora quiero que ésto sea una barrera de entrada para mis competidores". Una vez que la empresa está certificada, cantará loas a su proceso de desarrollo certificado por más paralizante que éste sea o incluso por más que el nivel de adopción real sea mínimo. Hacer lo contrario sería tirar la inversión a la basura. El mismo razonamiento desincentiva cualquier cambio en la metodología (en los papeles). La certificación, por definición, vuelve conservadoras a las organizaciones.

La certificación puede volver tan burocrático y enredado el proceso de desarrollo que el producto final sufre brutalmente... pero "hacia fuera" nunca será culpa de la certificación (al fin y al cabo hemos pagado tanto por ella...), sino que se buscarán otros chivos expiatorios.

Del lado de los pequeños es "tengo que certificarme para vender, pero me impone ciertas prácticas que me son nocivas y encima una inversión en consultoría completamente desproporcionada de acuerdo a mi nivel de actividad". El peso de los procesos que requiere la certificación es enorme para un equipo pequeño y acostumbrado al trabajo informal, y el costo es un hueso duro de digerir para la estructura financiera de la pyme.

Por otro lado, admitámoslo, está la perversidad del papel de las empresas consultoras / certificadoras / auditoras. Es inevitable pensar en que ésta y su cliente tienen el mismo objetivo: que el cliente se certifique. La "inversión en dinero" de la gran empresa va a parar a manos del consultor, que tendrá más interés en lograr su objetivo en tanto mayor sea la inversión. No importa cuánto se lo disfrace: el consultor cobra por certificar a la empresa, no por mejorar su proceso de desarrollo.

Y le ponemos el moño pensando en que cuando la certificación falla, el consultor también falla. Ésto puede no ser relevante en una pyme que nadie conoce, pero no lograr certificar una gran empresa puede significar una fea mancha en el prontuario de la consultora.

La teórica separación entre consultores y auditores, por más que sea "materializada" en las especificaciones de la certificación, en la práctica no beneficia a ninguno de los involucrados. Esta inevitable asociación de intereses permite poner en duda todo el proceso.

En definitiva, las grandes empresas siempre terminan certificadas de cualquier cosa (¡hasta de amigables con el medio ambiente!), mientras que las pequeñas... a veces sí, a veces no.

Creo que he dejado claro (si no fue así ya es tiempo de aclarar) que no tengo problemas con ninguna metodología, sino con el proceso mismo de certificación. CMMI puede ser fabuloso, pero la certificación en CMMI, como otra ya en Scrum, XP o lo que sea, me parece sospechosa en cuanto a su utilidad para el proceso de desarrollo del producto (claro que no así para su venta o promoción).