Quizá no es un buen día para escribir porque hoy es de esos días en que programar SÍ es una mierda. Un ex-compañero me diría que, después de 5 años en esto, es lógica esta sensación de hartazgo. Que ya me toca padecer "el síndrome del jardinero ausente". Este síndrome es ese que se produce cuando uno se quema con las miserias de esta profesión y piensa "yo me tenía que haber hecho jardinero" o, en los casos más extremos del síndrome, "como me toque un dinerillo me voy a comprar una finca en el pueblo abandonado más remoto y voy a vivir de mi propio huerto ecológico". Con el tiempo vi que hay quien cambia jardinero por pastelero o panadero. Y luego estoy yo que, siendo más de asfalto que un semáforo y poco hábil para las artes culinarias, nunca sé la profesión a la que asociar el síndrome aunque creo que sé notar los síntomas.
Acabo de buscar, por dar algo de rigor al texto, si hay alguna base científica a problema. He de decir que la búsqueda solo ha dado como resultado la entrada del blog en el que este compañero le puso nombre al síndrome. A lo mejor aquí hay un filón sobre el que investigar para alguna de esas universidades que hace informes surrealistas y absurdos que nadie sabe quién habrá solicitado.¿Lo proponemos?¿Os sentís o habéis sentido "jardineros ausentes"?
El caso es que, mientras intento alejar al pequeño jardinero que me atormenta, me pregunto cuáles son los motivos por los que, en esto del desarrollo de software, siempre se opta por hacerlo mal para hacerlo (supuestamente) rápido. Supongo que no es un mal solo de nuestra profesión, que en otras también pasa. Pero el mal de muchos ni me consuela ni mucho menos me ayuda a comprender.
Pongamos un ejemplo fuera de nuestro ámbito. Imaginemos que los obreros que contratamos para una reforma en casa dicen al jefe de obra que alicatar la cocina lleva 6 días en vez de los 3 previstos. Puede ser porque han encontrado un problema estructural en un muro, porque el pedido de material se retrasa o simplemente porque cuando dijeron el tiempo que se tardaba partían de la base de que era una cocina de 7 metros cuadrados y la realidad mide 67 (que no es mi caso, no os creáis). Para empezar no me imagino a los obreros planteándole "soluciones" al jefe, en plan:
Acabo de buscar, por dar algo de rigor al texto, si hay alguna base científica a problema. He de decir que la búsqueda solo ha dado como resultado la entrada del blog en el que este compañero le puso nombre al síndrome. A lo mejor aquí hay un filón sobre el que investigar para alguna de esas universidades que hace informes surrealistas y absurdos que nadie sabe quién habrá solicitado.¿Lo proponemos?¿Os sentís o habéis sentido "jardineros ausentes"?
El caso es que, mientras intento alejar al pequeño jardinero que me atormenta, me pregunto cuáles son los motivos por los que, en esto del desarrollo de software, siempre se opta por hacerlo mal para hacerlo (supuestamente) rápido. Supongo que no es un mal solo de nuestra profesión, que en otras también pasa. Pero el mal de muchos ni me consuela ni mucho menos me ayuda a comprender.
Pongamos un ejemplo fuera de nuestro ámbito. Imaginemos que los obreros que contratamos para una reforma en casa dicen al jefe de obra que alicatar la cocina lleva 6 días en vez de los 3 previstos. Puede ser porque han encontrado un problema estructural en un muro, porque el pedido de material se retrasa o simplemente porque cuando dijeron el tiempo que se tardaba partían de la base de que era una cocina de 7 metros cuadrados y la realidad mide 67 (que no es mi caso, no os creáis). Para empezar no me imagino a los obreros planteándole "soluciones" al jefe, en plan:
- No tenemos material pero tu tranquilo, sabemos que tiene que estar mañana así que colocamos el que nos sobró de la última obra por encima, simulando que es el que pidió el cliente. Tú no te preocupes que mañana tu tienes la foto de la cocina "ya acabada" y luego ya se cambia, si no se tarda nada.
Tampoco me imagino al jefe (o como ahora gusta más, el líder) diciéndoles:
-Pues tiene que ser en 3 días cueste lo que cueste. Y esto no se le puede decir al cliente. ¡Que va a pensar de mi ... digoooo... de nosotros si le digo que nos lleva el doble de tiempo! Y si hay que "hacer un esfuerzo" pues se hace, pero en la nómina nada, ya veremos cómo se compensa. ¿El problema estructural del muro dices?.... Eso lo vamos arreglando luego en los ratos libres que tengamos cuando vayamos poniendo el fregadero y la nevera, que seguro que ahí hay un hueco. Además me dijisteis que poner la nevera llevaba dos horas pero seguro que en una hora la tenéis instalada, que sois unos exagerados... El caso es que no nos puede parar lo del muro ahora, hay que seguir adelante.
¿Alguien se lo imagina? Porque seguro que si cambiamos "problema en el muro" por "error en el core de la aplicación" y pasamos de "simular que está puesto usando el material de la obra anterior" a "simular con datos a pincho la carga en el front para la demo" no nos suena tan raro. Y menos el echar horas gratis. Es que "el cliente lo quiere ya".
Sin embargo, con el ejemplo de la obra, quiero pensar que, como a mí, sí os suena a exageración. No imagino como usuales estas conversaciones, porque lo que parece obvio que lo que pasaría es:
Sin embargo, con el ejemplo de la obra, quiero pensar que, como a mí, sí os suena a exageración. No imagino como usuales estas conversaciones, porque lo que parece obvio que lo que pasaría es:
1. El problema estructural del muro una vez alicatado se hace 100 veces más complicado de arreglar y eso si es que se puede. Este problema se va a quedar ahí y lo que se dirá para justificar esa decisión es que, con suerte, para cuando alguien se entere "será problema de otro". Y al final, no hay suerte.
2. En el caso del material reutilizado y sobrepuesto para salir del paso, la realidad es que va a notarse en cuanto el dueño venga a verlo y toque o nos pida la foto desde otro perfil. ¿Consecuencia? Cliente cabreado que desconfía de nuestro trabajo, menos receptivo a nuestras sugerencias y explicaciones. Más crítico con lo que hacemos y más desconfiado.
3. Sobre "hacer un esfuerzo", también conocido como "echar horas por la cara", para llegar a tiempo ¿qué se puede decir?. Las prisas nunca son buenas consejeras. Se pierde interés, concentración, y así, en un despiste, se taladra donde no se debe y ... más problemas.
Todo para evitar decirle a quién nos contrató que necesitamos más tiempo.¿Qué pasa si somos el dueño del piso y nos dice el responsable de la obra que necesita 3 días más? Si expone los motivos de forma clara, lógica y siendo transparente, ¿va a ser tan problemático?¿No vamos a entender que ha surgido un imprevisto en el muro difícil de identificar previamente y que no se debe ignorar? Si se ha visto un trabajo adecuado hasta la fecha, ¿vamos a pensar que se está inventando el problema para sacarnos más pasta? Si no tiene el material, ¿no vamos a entender que no se puede avanzar? Es verdad que se deberían haber manejado unos márgenes de tiempo contando con ciertos riesgos. Pero antes de romper todo acuerdo, ¿no intentaremos buscar una solución que permita a ambas partes encajar el problema del mejor modo? Para nosotros, con la obra en marcha, tampoco es tan fácil romper con todo, volver a pedir presupuestos, meterse en pleitos para recuperar el dinero... Y si sale todo adelante a través de una relación sana y transparente y el resultado es de calidad, ¿no acabaremos satisfechos a pesar de los altibajos en el proceso?¿No vamos a recomendar la empresa a otros?
Y aun así, todos tiramos con el apaño en vez de ir a por la solución más completa. Los desarrolladores, porque no nos consideren vagos o torpes, por ser resolutivos o porque simplemente nos hemos rendido a que nunca haya tiempo para hacerlo bien. El jefe-lider (o scrum master/product owner), por evitar afrontar problemas, porque ya va todo demasiado cogido con pinzas y ya se han tenido que plantear demasiadas excusas y, según avanza el tiempo, porque hay "presiones de arriba", ya que el cliente está al borde de la explosión de cólera, va a llamar a otra empresa y, además de no pagar la parte hecha, va a reclamar una indemnización que nos va a llevar a la bancarrota, por lo menos.
Al final, el resumen es siempre el mismo: el yo de hoy disimula sus errores, lanza el problema para otro lado y el yo del mañana lidiará con él si vuelve. Al de hoy, no le importa qué va a volver y en forma de monstruo mayor. Lo que importa es que el pequeño monstruo actual se solucione rápido. Y rápido debe ser antónimo de bien...
