Esto tiene que estar para mañana

En una etapa laboral anterior, sufría a menudo el típico ataque inesperado según el cual un manager o jefe de proyecto venía a pedirme a mí y a mi equipo la corrección o puesta en producción de algo que por arte de birlibirloque se había convertido ese día en crítico. A lo mejor lo tenía en el cajón olvidado hasta que le explotó en las manos.

Nada peor para un programador que tener que resolver un bug o incluir una nueva característica con la presión del tiempo, sobre todo si no estaba previsto.

Esto puede parecer a excusa, pero cuando trabajamos excesivamente presionados vamos dejando atrás las buenas prácticas, los buenos hábitos y el formalismo de probar y probar por el camino; cuando el tiempo aprieta aligeramos nuestro trabajo sin darnos cuenta de que esto tiene un precio tremendo y en ocasiones los resultados son catastróficos: se actualizan cosas que suponemos que funcionan bien y creemos que no deben dar problemas (sin imaginar algún tipo de efecto secundario), olvidamos los rigores de la gestión de versiones (claro, nos han dicho que es algo crítico) y además apenas tenemos tiempo de probar todo el sistema, por poner sólo unos ejemplos. Para resumir, cuando tenemos encima de la mesa algo crítico lo olvidamos todo y nos centramos en el problema.

La cuestión no está tanto en poder gestionar estas situaciones ocasionalmente sino cuando estas se convierten en crónicas y el modo habitual de trabajar; en ese caso el software resultante será de pésima calidad. Es tema recurrente en El Libro Negro del Programador, así que dejad que os recuerde que código de mala calidad es igual a problemas: soluciones inmantenibles, más costosas por las dificultades de introducir nuevos cambios, incapacidad de ser asumidas con facilidad por nuevos miembros del equipo y, en definitiva, programadores frutrados que dedican más tiempo a depurar que a crear código de valor.

Trabajar bajo la presión de problemas no previstos por nosotros constituye el típico escenario en el que quien presiona no tiene ni idea de software: sólo ve programadores cuyo trabajo debe ser igual que conectar cables, o están bien puestos o están mal puestos, no hay más. Personalmente considero que quien lidera un equipo de desarrolladores debe tener profundos conociemientos de software.

Siempre, y lo digo taxativamente, siempre que me he encontrado en esta situación el diagnóstico ha sido el mismo: gestores de proyecto mal planificados y con una organización pésima; el problema es que esta falta de trabajo eficaz termina trasladándose a los miembros del equipo de desarrollo. Tampoco podemos excusar a clientes que de un día para otro encuentran un bug crítico que hará temblar su organización: si se ha hecho bien el trabajo, esta situación no se debe dar.

En cualquier caso, si nos encontramos en esta tesitura y detectamos que para llegar a tiempo tenemos que dejar cabos sueltos y entrar en una zona de riesgos, debemos notificarlo adecuadamente a los managers; basta un simple correo que con sutileza pero con contundencia debemos advertir de la falta de tiempo para probar exhaustivamente o implementar los cambios solicitados (esto es una manera de delegar responsabilidades).

También es una cuestión de actitud: ¿estamos para que viertan sobre nosotros la mala organización de quienes jerárquicamente están por encima?, ¿es esto profesional?. He visto cómo algún proyecto ha fracasado no por la falta de pericia y buen hacer de los desarrolladores, sino por problemas de gestión.

El saber decir "lo siento, esto no se puede hacer de aquí a mañana" tiene efectos positivos que debemos considerar: estamos honrando nuestro trabajo (no nos pagan por trabajar, el profesional busca hacer un buen trabajo, que no es lo mismo) y, además, uno o dos noes de este tipo hará recapacitar a quien lo provoca e intentará evitarlos en el futuro (para lo que simplemente tendrá que organizarse mejor).

Este tipo de situaciones demuestra también una falta total de productividad: cuando se convierten en crónicas entonces ya sabemos en el tipo de compañía en la que trabajamos. Cuando identificamos un manager cuya idiosincrasia de trabajo es el caos, entonces la salida que nos queda es intentar cambiar de grupo de trabajo, departamento o compañía: un profesional se hace profesional precisamente haciendo un magnífico trabajo, éste es su currículum y su manera de progresar.

Como desarrolladores que nos debemos ganar la vida desde la calidad de nuestro trabajo debemos considerar como máxima que la mayor parte de nuestras actividades deben estar correctamente planificadas, debemos tener un roadmap claro aunque incluyamos un pequeño percentaje de nuestro tiempo para deviaciones e imprevistos.