Calidad y consultoras, software factories y demás.

Hoy leí por un lado Welcome to the machine en Oh My Blog! I Can’t Believe It!, que nos relata la experiencia del desarrollo de software desde las trincheras de los grandes ejércitos:

[…] Pongamos que trabajas en un proyecto en el que participa un consorcio de diecisiete empresas, y estás subcontratado por parte de una de esas empresas […]

[…] Y entonces el alucinómetro estalla cuando te dicen que no hay diseño ni especificaciones hechas. Que tu vayas tirando código, que ya ellos haran ingeniería inversa para sacar la especificación y diagramas de clases y demás en base a lo que tu hagas […]

Más tarde me crucé con Burro (o consultor) grande, ande o no en Diario de un director de sistemas:

[…] Como otras veces, el debate sobre el precio y el valor de las consultoras grandes. […] Yo estuve siete u ocho años en una de esas consultoras. […] No cabe duda de que en el coste hora de un consultor de estas compañías estás pagando una parte de la oficina de Picasso o La Moraleja, la esponsorización de una estrella del golf o un equipo de Fórmula 1, y los salarios "indecentes" (es una forma de hablar, yo no los considero así) de los socios o partner o principals, según como se llamen en cada casa. Todo esto es verdad. No creo que nadie lo discuta.

[…] tampoco ofrece dudas que un documento bien preparado por gente de estas compañías suele significar un cuidado en la presentación y en el contenido bastante mayor del que te presentan otras empresas más pequeñas. Y lo mismo que hablamos del documento podemos aplicarlo al desarrollo y ejecución de los proyectos, siempre y cuando estemos hablando de proyectos de cierta magnitud/dificultad […]

¿Qué imagen es más cercana a la realidad? ¿La de la consultora de renombre y proyectos desastrosos que de alguna manera terminan funcionando o la de la experta en la ejecución de proyectos a gran escala bajo estrictos estándares de calidad? Tal vez no haya una única respuesta, sino dos caras de la misma moneda.

Hablando de imágenes, de percepciones, es deber aclarar primero fuentes y preconceptos. Mi visión es la del programador, del desarrollador que conoce un poco tras bambalinas e intuye otro tanto. Aunque nunca he trabajado en una gran consultora o en una empresa con un área de desarrollo gigantesca como las que se mencionan, conozco y he compartido proyectos con programadores y analistas que sí y con los que he comentado muchas veces los contrapuntos entre éstas y los equipos pequeños o medianos.

A partir de esa muestra de experiencias (y juzgando contra mis propios estándares), yo me formé la idea de que:

• La irracionalidad de la metodología empleada (no la enunciada, sino la de todos los días), ya sea etiquetada como ágil o tradicional, llega a extremos insospechados transformándose en un conjunto de rituales vacíos.

• La conveniencia de las herramientas y lenguajes que se utilizan con respecto a los requerimientos de cada proyecto es -por lo menos- cuestionable en la mayoría de los casos. Se utiliza un martillo y todos los proyectos son clavos. Si el cliente pide tornillos se le entregan clavos en cajas de tornillos.

• La robustez de la arquitectura de los proyectos es similar a la del queso gruyere. De todas maneras su utilización (es decir, cuánto se respeta en la práctica esa estructura enunciada) es prácticamente nula.

• La calidad del código suele ubicarse entre mediocre y WTF.

• Los documentos de análisis internos (no los bonitos que se presentan a los clientes sino los que se terminan utilizando, si es que existen) no sirven más que de punto de partida para que los desarrolladores hagan volar su imaginación.

• Y por supuesto, las modificaciones y el mantenimiento son un infierno para ellos…

• que de todas maneras es raro que tengan que soportar por más que un par de años (la rotación es vertiginosa).

Ya sé, ya sé, hay proyectos y proyectos. La misma firma de pobre desempeño en uno desenvolverse bien en otro, y mucho tendrá que ver con ello el control y la seriedad del otro lado del mostrador. Pero sigamos.

El cliente de “Pelota Plus Consulting” no es “Megaempresa S.A” que necesita un ERP. El cliente es el gerente-de-lo-que-sea de “Megaempresa” que contrata a “Pelota Plus” sabiendo que toma una decisión irreprochable más allá del resultado del proyecto, y eso es lo que compra: cierta (mas no absoluta) seguridad para sí más allá de los resultados. ¿Para qué arriesgarse? “Megaempresa” tiene mucho dinero para gastar y el precio está consolidado por el mercado.

La atención que brinda la consultora a su cliente (el gerente-de-lo-que-sea) es inigualable: un contrato importante con muchos ceros a la derecha, presentaciones, carpetas, folletos, aulas para capacitación, equipos, gente de traje con una tarjetita a la altura de la solapa y toda la parafernalia necesaria para hacer de él alguien importante dentro de “Megaempresa”.

Todos los puntos oscuros que mencioné al principio son invisibles tanto para el cliente como para “Megaempresa”. Conforman una deuda técnica que la consultora adquiere (resultado inevitable de la industrialización del desarrollo) pero que luego transfiere a “Megaempresa” al facturarle capital e intereses (más su propio margen de beneficio) en forma de horas de mantenimiento. El cliente no sabe -ni le interesa- por qué se tardan 8 horas en correr un botón de un formulario.

¿Que se podría hacer mejor? No tiene que ser perfecto, sólo funcionar. ¿Que podría ser más barato? La pequeña consultora o equipo de desarrollo implica más riesgo y el cliente ya está asumiendo mucho… si la cosa se complica él puede terminar viendo el partido desde la tribuna.

Por lo menos así lo veo yo.