Inicio > Gestión TI > Programando para las Instituciones Estatales

Programando para las Instituciones Estatales

jueves, 4 de enero de 2024 Dejar un comentario Ir a comentarios

Todo comienza una mañana con la llamada telefónica de una consultora. Días atrás, habíamos estado mirando ofertas en Infojobs y una nos llamó la atención: buscaban programadores en PHP y MySQL, con conocimientos medios de Javascript y CSS; valoraban usabilidad, accesibilidad y el uso de algún framework para el desarrollo. Apenas hay más datos, quizá el horario de trabajo y el tipo de contrato. Suena bien, como otros tantos, así que echamos el curriculum tempranito para que sea de los primeros que revisan y a ver qué pasa.

Nos llaman, se presentan y nos comunican que hemos sido seleccionados para una entrevista personal en la dirección que corresponda. Aparecemos bien acicalados y disfrazados de chaqueta como Dios manda. Un señor regordete con pinta de bonachón y unas gafas redondas sin montura nos muestra nuestro currículum impreso y comienza a comentarlo en voz alta… lo tenemos impresionado: carrera, Máster, años de experiencia, muchas webs programadas online, página personal,… somos la opción perfecta. Comienza a describirnos el trabajo para el que nos presentamos:

– Como has visto por la oferta, necesitamos programadores en PHP y MySQL que sepan de estándares y accesibilidad. Es para un gran proyecto que estamos gestionando con un importante cliente. Vamos a necesitar a varios programadores con tu perfil, por lo que si además conoces a más como tú, nos encantaría entrevistarles.

– Ok; suena bien. ¿Me puede hablar un poco del proyecto en cuestión?

– La verdad es que no conocemos los detalles. Sabemos que se trata de un desarrollo con GLPI, Nagios y programación web basado en Software Libre. Sólo tenemos las especificaciones del cliente que son las que pusimos en la oferta: PHP, MySQL, Javacsript, CSS, … ¿Sabes lo que es un entorno LAMP?

– Si claro, un entorno de desarrollo web basado en el Linux, Apache, MySQL y los lenguajes de servidor PHP, Perl y Phyton. Del resto, Nagios me suena, pero GLPI no lo he oído en mi vida; ¿de qué va?

– No lo sé; el cliente dijo que utilizaban GLPI, pero que no era imprescindible. El resto nos sirve. Lo del LAMP es importante, hay gente que no sabe lo que es.

– Ah vale. Eso del GLPI lo veremos sobre la marcha. ¿Quién es el cliente?

– Eso no podemos revelártelo. Solo te puedo adelantar que está por María de Molina, cerca de Avda. de América. Creo que es la línea 6 de Metro…

– Si, es la 6, pero ¿no pueden decirme quién es el cliente ni dónde está exactamente? ¿Y cómo llego?

– Cuando firmemos el contrato, al día siguiente te acercas de nuevo por aquí y nos vamos para allá en coche. Así aprovechamos y te presento a tus compañeros.

– Hmmm… estooo… pos bueno, pos sale…

Llega la parte económica; se discute un rato sobre el sueldo anual, las compensaciones por transporte, los tickets restaurant, etc… Si todo marcha, te citan en un par de días para cerrar el contrato. Ya está: ninguna pregunta técnica, ninguna prueba, nada de nada. Nuestro entrevistador es un responsable de grupo más dentro de una cárnica gigantesca a la que nunca más volveremos. Poco sabremos de quiénes son los jefes, o el resto de empleados; como mucho nos facilitarán el correo electrónico de un par de personas con las que tratar temas del tipo vacaciones, horas extra y poco más.

Llamas a los colegas para comentarles la noticia y resumirles por encima lo que, como mínimo, es una entrevista atípica. Les cuentas que te van a contratar para una empresa que parece importante, pero de la que no sabes ni cómo se llama ni dónde está. Les dices que comienzas de inmediato, en un par de días y que un coche te llevará hasta la nueva oficina. Tus amigos te escuchan extrañados…

– ¿Qué no sabes dónde está tu empresa? ¿Te lleva un coche directamente? ¿Te van a vendar los ojos por el camino?

– Lo de los ojos no, pero el resto más o menos si. Suena raro, pero ya he firmado… si no me gusta, pues lo dejo y ya está. Tengo seis meses de prueba.

– Ufff, seis meses… joder; que raro suena todo… Bueno en fin, ya te llamo pasado mañana a eso de las 12:00 y me cuentas por dónde andas… no vaya a ser que te secuestren o algo así…

– Anda ya hombre… Pero si; dame un toque y ya te cuento.

Llega el día y te pones de camino. Ya en la cárnica, te espera el entrevistador y un taxi. Un transporte público nos tranquiliza, aunque de normal, a hora punta, un taxista por Lima realmente nos infundiría más miedo que calma. Efectivamente, llegamos a una calle cercana a María de Molina, una paralela, junto a un edificio bastante grande con una placa oficial en la puerta: «Ministerio de Administración Pública. Gobierno de España». Nuestra oficina está en la segunda planta: a partir de ahora, somos lo que en la jerga oficial se conoce como unexterno.

Entramos en el complejo hasta la cocina: dos guardias de seguridad levantan la mirada y nos saludan sin realmente mirarnos. No hay ningún tipo de control, no nos piden DNI, ni nombre, nada de nada. Si en la mochila lleváramos una bomba, a los seguratas se la traería al fresco. De hecho, la experiencia luego me demostró que alguien podía pasearse por el edificio entero con algo tan exótico como dos crías de tigre blanco sacadas del Circo Mundial… pero eso es otra historia que deberá ser contada en otra ocasión.

Llegamos a nuestro despacho, una sala que recuerda a un escobero levemente readaptado: 15m2 sin ventanas donde se hacinan 6 programadores más. Es septiembre, media mañana y ya hace un calor insoportable. Algunos de los presente desconoce la utilidad de los desodorantes.

Tras las presentaciones y la asignación de las primeras tareas, compruebas que tus compañeros controlan el tema: ven Battlestar Galactica, han memorizado los diálogos de IT Crowd en inglés y llevan camisetas de Linux o Gnome. Dicen saberse más IPs que números de teléfono y tienen sobre la mesa el último número impreso de la revista Todo Linux junto a un pingüino de peluche. Madre mía… y yo aquí con mi camisa de botones y mi propio portátil… tengo que parecer un bicho raro.

Dos semanas más tarde, has conocido a la mayoría de los colegas de trabajo; con un poco de suerte, hasta has visto de reojo a tus jefes directos tras muchos papeles en sus respectivos despachos: camino al baño, pasas por delante ellos. De tu empresa no tienes noticia alguna, solo un par de correos en tu bandeja de entrada con una frase que, a partir de ahora, se repetirá a lo largo de tu vida laboral como un mantra, una simple pregunta que teñirá nuestros días de gris y nos perseguirá en interminables pesadillas: «¿Has imputado?»

Imputar… eso es lo único que le importa a la cárnica de turno. Es su moneda de cambio: el cacho de carne que tienen asignado en el cliente (nosotros) genera beneficios según el número de horas que trabaja por lo que tiene que quedar constancia semanal de cuánto tiempo hemos estado clavados a la silla.

Para los que tienen la suerte de desconocer el proceso, imputar supone conectarse remotamente a la web de tu empresa, utilizando IE6 por supuesto, esperar varios minutos hasta que la aplicación se carga, llamar por teléfono para que te reasignen una contraseña que ha caducado, volver a entrar y esperar varios minutos porque la conexión ha caducado también y todo para, finalmente, darle a un botón que la mayoría de las veces dispara un error Javascript. Vamos, lo más apropaido en términos de productividad.

Realmente nadie comprueba la hora a la que llegas o a la que te vas, solo es una apreciación personal de los responsables: si cada vez que alguien asoma la cabeza por el zulo te ve, es que lo estás haciendo bien. Si dices que has estado tus 40 horas semanales, pues perfecto. La doble cara de este descontrol, es que cuando a los jefes les presionan desde más arriba, terminan echándote la bronca porque alguna vez has salido 10 minutos antes. Da igual que ese día no hayas comido, o que gracias a la eficacia del transporte público madrileño, estuvieras 25 minutos antes de la cuenta sentado en tu sitio… A veces toca echar broncas, es parte de su trabajo, y algo habrás hecho mal…

Poco a poco, tenemos constancia de que en el mismo edificio hay más programadores repartidos por otras plantas: existe el grupo de los javeros, gente a la que nunca conoces y que trabajan en amplios despachos disfrazados con camisa y corbata. Se les ve competente porque alguna vez te cruzas con ello por las escaleras. Si un día con más tiempo libre hacemos una excursión por el Ministerio, podemos incluso verlos a través de las ventanas de ojos de buey de algunos despachos: 3 ó 4 tipos en cada una de las amplias habitaciones, con sus portátiles y iPods, en perfecto silencio… parece cómodo.

También están los de sistemas; unos tipos dispersados en una sala con una gran cámara frigorífica en la que se han puesto los servidores. Esta gente aprovecha las horas de la comida para devorar series a través de Internet. Durante su jornada, guardan con recelo secretos inconfesables para hacerse fuertes contra recortes de plantilla: simplemente son imprescindibles. Todo ha sido montado de un modo tan precario que solo unos pocos saben cómo funcionan; los de sistemas lo saben y se aprovechan de ello. Cuando les pides permisos para cambiar alguna configuración que tiene ver con ellos, te invitan a realizar una petición formal por mail, de estas cosas tiene que quedar constancia… Lo entiendo: es el pan de sus hijos y con eso no se juega. Da igual que haga falta una mañana entera y varios correos para aumentar la memoria disponible del PHP… hay que pasar por ellos si o si.

Los programadores PHP tenemos que ser como la peste. Da igual los metros cuadrados útiles de un espacio… siempre puede caber una mesa más, da igual que sea de despacho o una auxiliar en la que iría una impresora; de todos modos, ¿para qué iban a necesitar más espacio? Más que arquitectos de código somos un cruce entre contorsionistas y profesionales del Tetris: mesas que reubicar, enchufes que expandir con interminables regletas, cables que se enredan en pies y patas de silla… pero no importa; total, tampoco hay oxígeno… estos desarrolladores de camisetas raras en realidad hacen la fotosíntesis a partir de las ondas wifi: nunca se quejan demasiado.

Y continúa nuestro trabajo. Hasta el momento hemos estado refactorizando código que escribieron otros antes que nosotros y ampliando aplicaciones de una complejidad absurda con nuevas funcionalidades pedidas a la carta. Pensamos que estamos ante proyectos críticos hechos en una sola tarde que ahora tenemos que arreglar para cubrir una emergencia; así que documentamos todo bien para que cuando se rehaga, sepamos por dónde van los tiros. Pero con el tiempo, descubres que realmente los tiros van directamente a nuestras sienes: nada se rehace, eso es perder el tiempo: los programas son los que son, lo que vaya surgiendo ya se incrustará como sea sobre lo anterior. A veces, una modificación menor puede suponer cambiar 6 ó 7 archivos distintos debido a la duplicación de código: es normal, cada nuevo programador, si no entiende algo, lo machaca directamente con piezas nuevas. Una misma función PHP para formatear una fecha puede encontrarse fácilmente más de 10 veces en una aplicación estándar.

Con el tiempo, nuestras sospechas sobre la metodología de trabajo surgida el primer día se han ido confirmado: directamente no existe, no hay. En la carrera invertimos un año estudiando metodologías de programación: las tradicionales, las ágiles, el entonces nuevo SCRUM… Con el Máster, nos ampliaron los conceptos con ejemplos reales como la XP o la fantástica TDD. Incluso se dedica un semestre a revisar y profundizar en la metodología MÉTRICA V3 la cual, según la Wikipedia:

«Métrica v3 es una metodología de planificación, desarrollo y mantenimiento de sistemas de información. Promovida por el Ministerio de Administraciones Públicas del Gobierno de España para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas.»

Y hasta aquí podemos leer. Lo dice la Wiki y nos lo creemos pero ya está. En el mundo real de la Administración, esta metodología no existe. De hecho, allí nadie conoce de qué va, ni como se implementa, ni cómo funciona. Para ser sinceros, el hecho de que no se utilice nada semejante es algo que agradecemos porque estas metodologías están desfasadas con respecto a las ágiles. Lo que no podemos entender es cómo grandes proyectos de implantación a nivel nacional, no posean ninguna documentación: como bromeábamos entre amiguetes, para saber qué es lo que hace una determinada aplicación, tenemos que leernos su código fuente. No vamos a encontrar otro papel en ningún sitio. Con suerte, alguien tiene una cadena de correos en su bandeja de entrada en la que se pedían determinadas mejoras y funcionalidades. Esa puede ser nuestra documentación más exhaustiva.

En cuanto al desarrollo en si, apenas se prueban las novedades implementadas: se trabaja directamente sobre un entorno de Producción cuando hay prisas. Y esto es otra de las cosas que necesitan de algo más de explicación: existe un entorno al que llaman Preproducción y en el que se suponen que vuelcan las mejoras para ser probadas antes de lanzarlas al definitivo de Producción. Ambos sistemas se alimentan de un repositorio en Subversion que permite el control de versiones. Sin embargo, pese a que suena un procedimiento correcto, la forma en que se gestiona elimina toda la utilidad que podamos presuponerle: los entornos de pruebas y el real, no son iguales. Esto significa que algo que funciona en pre, no tiene porque hacerlo en pro. Además de esto, hay veces que los repositorios no se corresponden, por lo que hay tantas diferencias entre un entorno y otro, que hace falta echar mano de scripts adicionales para realizar subidasseguras que discriminen determinados archivos.
Finalmente, al repositorio de Subversion tienen acceso todos los usuarios con permiso de root. Esto quiere decir que el último que llegaba, podía comenzar a hacer commits masivos de modificaciones que otro más tarde subía a pro confiando que todo había sido probado. Para más lío, como siempre figura como «commitante» el usuario root, nadie puede saber quién es el responsable real de un posible error crítico. Como anécdota, todos allí recordamos cómo muchos meses después del despido de un compañero, su usuario continuaba haciendocommits al repositorio general de forma regular: un claro Expediente X.

Con el tiempo aparecían las facturas físicas: las prisas y el estrés de proyectos absurdamente ambiciosos sin apenas plazo se entremezclaban haciendo mella en los programadores. Es raro aquel nuevo recurso que dura más de 4 ó 5 meses.

La presión incluso llevó a un compañero a tomarse casi un año de baja por problemas físicos derivados del sobre esfuerzo: un conocido proyecto publicado de forma extraordinaria en el BOE con una fecha de implantación inmediata, requirió de una movilización especial 24/7. Casi 10 días en los que apenas hubo un minuto de descanso durante los cuales, altos cargos como la Directora General, el Secretario de Estado o Prensa, convivían con nosotros recordándonos que no cabía la posibilidad de no entregar en el día establecido: resultado de ello, las bajas no tardaron en aparecer.

Pero como de costumbre, siempre hay algo más: además de estrés físico, quedó claro que puede dañar la salud mental de algunos… durante nuestro paso por el sector público, vemos pasar a todo tipo de personajes cada cual más curioso. El hecho de que ninguna persona con capacidades técnicas (ni psicológicas) evalúe a los nuevos candidatos favorece el que lleguen a plantilla desde becarios demasiado verdes hasta individuos con claros problemas emocionales.

Dentro de la categoría de programadores inestables, no puedo pasar por alto el caso de un señor que apareció un buen día por la puerta. A simple vista, quedaba claro que no era como los demás: poseía un aire tímido y reservado que hacía dudar sobre si estábamos ante un verdadero genio matemático o un simple pirado. El tiempo reveló que íbamos más hacia lo segundo. Tras varios meses, descubríamos que, en sus propias palabras, era un cunnilingüista frustado, adicto a la nicotina ya fuera extraída del tabaco o de unos chiclets ilegalizados en la Unión Europea, un programador que había decidido que no quería programar más. Tras varios episodios consecutivos en los que quería hacerse cargo de todos los proyectos del Ministerio, envío un día una carta en cuya copia figuraban todas las listas ministeriales y algunos de los medios de comunicación más amarillistas (El chino, Ojo, etc…). En dicha misiva culpaba a la sociedad de haberlo desterrado al ostracismo, de haber hecho de él lo que ahora era. Tenía una curiosa lista de peticiones donde solicitaba desde una entrevista en persona con el presidente hasta el deseo vital de conocer al líder israelí Benajmín Netanyahu… Entre medias, la reflexiones inconexas que realizaban se convirtieron en algo memorable. Algunos se tomaron la carta a broma; otros temían que un día reapareciera con un rifle de asalto por aquel edificio descuidado; otros simplemente nos lo olíamos y no le dimos mayor importancia. A día de hoy, continúa desaparecido.

Pero no solo los externos están presionados. También sufren estrés los altos cargos: recuerdo cómo a falta de un día para entregar un proyecto imposible de concluir en el plazo, me llamó la responsable (jefa) del proyecto. Su trabajo se basaba en pedir requisitos día tras día, sobre la marcha. A cada petición, el proyecto sufría un lógico retraso: hay que meter algo nuevo y modificar lo anterior para que encaje. Así que cuando me preguntó a qué hora se pondrá la aplicación completa en Producción, le contesto que no llegamos. He trabajado más de doce horas diarias durante la última semana pero no está listo: no se han realizado pruebas en un entorno real, faltan partes por implementar, hay aún aspectos que no hemos definido con precisión… Así que serán necesarios al menos 3 ó 4 días más. La jefa del proyecto reacciona ante la mala noticia como cabe esperar de un alto cargo público: comienza a reírse histéricamente desde el otro lado del teléfono. Se ríe durante un par de largos minutos balbuceando frases sueltas a medio terminar: «no está listo», «salimos mañana y no está»… Las carcajadas se entremezclan con los balbuceos y casi siento miedo… Le paso el teléfono a mis compañeros para que la oigan. Si espero a contarlo más tarde pensarán que exagero. Finalmente la aplicación se entregó dos días más tardes sin mayor impacto oficial. Sin embargo, esta señora fue cesada al poco después. Obviamente, la presión pudo con ella y la dejó fuera de juego.

Pero no sería justo hablar solo de los compañeros más raros. También hay grandes profesionales con los que se puede mantener una conversación inteligente; colegas de trabajo con los que terminas yéndote de vacaciones durante un largo puente o tomando una cañas un viernes por la noche. Son verdaderos héroes anónimos que aguantan firmemente toda la porquería que se desprende de una interminable cadena de cargos a cada cual más incompetente. Desde aquí, mi reconocimiento a todos ellos: gente valiosa que realmente se toma en serio su trabajo y que me han ayudado de una u otra forma a ser mejor programador. Cuando las cosas funcionan, es gracias a ellos; cuando fallan, es por culpa de la incompetencia ajena.

Comparte y diviertete:
  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • BarraPunto
  • Bitacoras.com
  • BlinkList
  • Blogosphere
  • Live
  • Meneame
  • MSN Reporter
  • MySpace
  • RSS
  • Suggest to Techmeme via Twitter
  • Technorati
  • LinkedIn
  • email
  • FriendFeed
  • PDF
  • Reddit
  • Wikio IT
  • Add to favorites
  • blogmarks
Top Footer