Fuckowski, memorias de un ingeniero

¿Cómo es posible que un individuo absolutamente lego en materia de software sea capaz de dirigir un proyecto sin que se le vea el plumero? ¿No debería hacerse evidente su incompetencia? ¿No debería fracasar el proyecto estrepitosamente? Sin embargo, estos individuos conservan sus puestos durante años (normalmente hasta la quiebra de la empresa).

La clave de este misterio está en el proyecto bicicleta.

Grosso modo, las fases de un proyecto bicicleta son: Análisis de requisitos, diseño, implementación, fase de pruebas, entrega, revisión. En la fase de análisis de requisitos el cliente informa de lo que desea, en la fase de diseño se da forma al producto, en la fase de implementación se codifica, en la fase de pruebas se comprueba que todo haya ido bien. Las cuatro primeras fases pueden parecer las más importantes, pero en un proyecto bicicleta resultan ser del todo prescindibles. Se deja todo a la fase de revisión (que le suele tocar a uno).

En estas primeras fases nuestro amigo manager no trabaja (recordemos que simplemente es incapaz), tan sólo sale del paso. Hasta la fase de entrega no hay nada de que preocuparse, se trata de disimular. Pero claro, algo tangible hay que tener, algo que enseñar a la directiva en las reuniones. ¿De dónde se saca? Simplemente se baja de internet o se compra. Digamos que el cliente necesita un sistema de workflow, accesible por web y que sea escalable. Pues bien, se va uno a un buscador y se introduce “cheap web-based workflow system java source code download”. Se navega un poco, se busca un producto con colorido futurista, se saca la tarjeta de crédito, y voila. El proyecto bicicleta ya tiene forma.

A continuación nuestro amigo manager designa un equipo de desarrollo para las fases dos, tres, y cuatro. La experiencia le ha enseñado que para proyectos bicicleta se deben escoger desarrolladores cuanto más lerdos mejor, para que no se den cuenta del pastel (aquí se sigue el principio del “traje del emperador”).

Podemos empezar a sospechar que en la mesa de al lado se esta cociendo un proyecto bicicleta cuando el equipo de lerdo-desarrollo juega al 69 profesional. Se intercambian comentarios-perla muy pomposos, tales como “los canales de intercambio de información son muy limpios”, “el factor usabilidad es determinante en el diseño de los javabeans”, “ya he incrementado el número de parámetros del constructor, te mando el punto class por mail”, o “este JSP tiene tres mil líneas porque he aplicado un patrón FACADE de acceso concentrado”.

Dos meses después llegamos a la fase de pruebas. Obviamente el producto es una mierda. Pero las pruebas corren a cargo del mismo equipo, y los niños de uno nunca son feos. Así que con la cabeza bien alta, se prepara un zip, un manual de instalación, y entrega tú, Carlitos, que a mí me da la risa. ¿Estado del proyecto? Entregado. Viernes noche. Cena de proyecto. Aplausos, risas, más 69. El lunes llegarán las sorpresas.

Ilustremos la fase de revisión con un ejemplo gráfico:

El proyecto porsche

Llega el lunes y uno abre el correo. Subject: “Incidencias en el proyecto Porsche”. Te requieren “un par de días” para “echar una mano” con “unos bugs”. Reunión dentro de quince minutos.
Entras al despacho. Ahí esta nuestro amigo manager. Te explica la historia: el proyecto Porsche es uno de los más punteros de la empresa (uno sospecha que es puntero a null). Se han aplicado novedosas técnicas de diseño e implementación y se ha conseguido entregar un producto perfectamente acorde a los requisitos del cliente: un porsche descapotable, seguro, ligero, veloz, de bajo consumo y de bajo coste. Se ha hecho rápido y bien. Un éxito. En la fase de revisión han surgido unas pequeñas incidencias que hay que revisar.

Bien. Vamos a ver la maravilla. Entramos al hangar del proyecto porsche, y ahí está la criatura: una bicicleta. De paseo. Sin cambio de piñón ni nada. Lleva una pegatina detrás del sillín con el logo de la empresa y la palabra “PORSCHE”. En la cesta va un certificado de AENOR. Aquí uno normalmente monta en cólera y empieza a gritar que quiere ir a hablar con el director, los socios fundadores, los clientes, los accionistas, el papa de Roma. Uno quiere ver a alguien colgado en la plaza pública.

Lo que sucede acto seguido es que a uno le llevan a un despacho en recursos humanos y le aplican de nuevo el método combinado “Ludovico/Habitación 101″. La chavala de RRHH, que se suele llamar Maika o Ivon y va vestida con ese traje de pantalón negro y tacones estilo mujer corporativa con master en dirección de empresas, nos interroga con voz de Valium 500:

[Ivon] Señor Fuckowski, ¿cuáles son sus quejas respecto al proyecto porsche?

[yo] ¿¿¡PERO QUE PORSCHE!??

[Ivon] El proyecto porsche, uno de los mas punteros en…

[yo] ¡¡Que sí, que sí, que me sé la película!! ¡¡Pero es que “eso” es una bicicleta, y se supone que tengo que convertirla en un porsche en dos días, y me han dado un destornillador y un bote de pintura!!

[Ivon] Señor Fuckowski, es cierto que el porsche presenta algunas incidencias, pero..

[yo] ¡¡BICICLETA!! ¡¡BICICLETA!!

[Ivon] Señor Fuckowski, ¿está atravesando una crisis personal? Debe haber una razón para su postura negativa acerca del porsche.

[yo] No. Estoy perfectamente. O lo estaba, hasta que vi la bicicleta.

[Ivon] Habitación 101, señor Fuckowski .

Habitación 101. Silla con correas. Camisa de fuerzas. Logos de la corporación. Certificaciones de calidad. Proyector XGA. Pantalla panorámica que muestra una enorme bicicleta de paseo. Allí nos espera el director de la empresa.

[director] Señor Fuckowski, describa usted este porsche.

Me ahorraré los detalles de la tortura, pero implica disertaciones sobre la actitud positiva, la creencia en la visión de la empresa, la auto motivación, la letra pequeña del contrato. En definitiva, que si no ves el porsche vas a la calle.

Después del almuerzo ya está uno perfectamente motivado, asistiendo a una conference call entre la empresa, representada por el manager, y el cliente, representado por un consultor con traje negro y corbata chillona, contratado ayer, que cobra 100 euros la hora mas dietas, y al que no le interesa decir “meteos la bicicleta por donde os quepa” y cobrar 25 euros por quince minutos.

[consultor] Bien, vamos a clarificar las incidencias respecto al porsche. Lo primero que hemos notado es que le faltan dos ruedas.

[manager] Sí, hemos optado por el diseño minimalista que va con nuestra visión de empresa: “práctico, funcional, óptimo”.

[consultor] Ya veo. Pero un porsche con dos ruedas no casa con nuestro modelo de negocio. Lo necesitamos de cuatro ruedas.

[manager] Creo que podremos refactorizar el porsche y hacer un clone para añadir dos ruedas extras, ¿cierto? -me mira a mí

[yo] ¡¡Sí, jajaja!! ¡¡Chupado!! Dame una hora.

[consultor] Perfecto. Bien, la segunda incidencia. No encontramos la capota.

[manager] Sí. Lo querías descapotable, ¿no?. Pues hemos simplificado mucho la usabilidad retirando la capota.

[consultor] Bien, pero no sólo la queremos quitar, también la queremos poner.

[manager] Ah. Eso no está especificado en los requisitos iniciales, así que lo consideraremos funcionalidad extra y lo cobraremos por separado. ¿Que impacto tiene este nuevo requerimiento en el sistema? -me vuelve a mirar.

[yo] Afortunadamente los interfaces están muy limpios, así que podremos modificar la capa externa sin impacto en el kernel, jajaja.

[consultor] Perfecto. Otra cuestión, ¿dónde están el contacto y la llave? Cualquiera podría robarnos el porsche.

[manager] Hemos optado por el modelo multiusuario para la implementación inicial, pero podemos añadir un módulo de seguridad al sistema, ¿no?

[yo] ¡¡Siiii!! ¡Precisamente tengo aquí un módulo de encriptación SSL para porsche!

[consultor] Brillante. Sólo dos incidencias más. Se requiere demasiado esfuerzo al usuario para completar tareas con el sistema. ¿Podrías cambiar los pedales por un motor?

[manager] En principio queríamos dar la máxima libertad de acción al usuario, por lo que hemos optado por un modelo de cliente pesado.

[consultor] Bien, pero consideramos excesiva la cantidad de trabajo que se deja al usuario.

[manager] Podemos llegar a un compromiso razonable entre la libertad del usuario y la automatización de procesos, ¿no es cierto?

[yo] Indudablemente. Sustituiremos el motor de giro asistido por pedales por uno compatible asisitido por pistones. Quizá requiera añadir un módulo de almacenamiento externo para combustible, pero siempre lo podríamos poner en la cesta, jajaja.

[consultor] Estoy contigo al cien por cien. La última: el sistema no ha superado las pruebas de rendimiento. En los requisitos consta que el sistema debe alcanzar los doscientos por hora.

[manager] El rendimiento siempre puede variar dependiendo de la plataforma. Las especificaciones de este sistema son “carretera de hielo con un 70% de pendiente descendiente”.

[consultor] Bien, verificaré qué plataforma estamos utilizando en explotación. Pero creo que vamos a necesitar más velocidad.

[manager] Siempre podemos afinar el kernel, ¿no es cierto?

[yo] Cierto como que me llamo Fuckowski.

[consultor] Muy bien, caballeros. Ha sido un placer.

Tres de la mañana. Un termo de café. Un cubo de pintura, un destornillador. Y una bicic.. un porsche.

Web | Alfredo de Hoces