DA4 2010-2011 (Florida Ciclos Formativos): noviembre 2010

Sacado de http://www.ingsoftagil.com/

"Últimamente se están sucediendo varias noticias relacionadas con el problema de la precariedad laboral en el sector de la informática. El tema lleva sobre la mesa desde siempre, pero las dificultades actuales en el mercado laboral lo están acentuando.
Los debates sobre la cuestión casi siempre degeneran en guerras incendiarias ente los propios perjudicados. Sobre todo, cuando se tocan aspectos como el intrusismo, los colegios, o la utilidad de los planes de estudio. Un ejemplo es la famosa discusión entre ingenierosdeprimera.com y Ricardo Galli, creador de Meneame.com.
Otras veces el foro se convierte en una colección de insultos contra las cárnicas, como pasaba con www.trabajobasura.com, y otros sitios parecidos. Esto suele ser poco productivo, porque no logra cambiar nada.
Para mi, la raíz del problema de la precariedad laboral no está en las cárnicas, ni en la ausencia de colegios o sindicatos. La raíz está en la contratación de perfiles poco cualificados, y su consideración como peones albañiles.
Cuando digo perfiles poco cualificados no me refiero a titulados o no titulados. Me refiero a personas sin ninguna vocación, y sin ningún interés por aprender, empezando por aquellos, tanto informáticos como otros titulados, que afirman que "no han estudiado una ingeniería para acabar picándo código", o que "la labor de un ingeniero no es poner los ladrillos".
Precisamente las cárnicas, el bodyshopping, la deslocalización a otros a países, y gran parte de los males del mundo de los servicios de software, no son más que consecuencias de esta consideración del programador como un peón albañil.
A veces son estas mismas personas, los que desprecian la programación, quienes más se quejan del intrusismo. Pero estaréis de acuerdo en lo incoherente que resultaría revindicar la programación como una competencia exclusiva de los ingenieros informáticos, y mantener al mismo tiempo que la programación es impropia de un ingeniero. Tan incoherente como protestar por la contratación de licenciados en informática como "picadores", al mismo tiempo que se protesta por la contratación como programadores de profesionales de otras titulaciones. No tiene sentido tampoco que sean los menos cualificados para la programación, que son aquellos que la desprecian, quienes etiqueten a todos los demás como perfiles no cualificados para el desarrollo de software.
Más de uno estará pensando que no es la programación lo que les preocupa, sino la dirección o gestión de proyectos de software. Piensan que la verdadera labor de un ingeniero no es programar o poner ladrillos, sino dirigir proyectos o diseñar los sistemas.
Las personas que piensan así generalmente no están cualificadas para programar, ni para gestionar proyectos. Para lo primero es evidente: quien piense que programar es como poner ladrillos, es que no ha programado en su vida. Pero la programación no es una actividad de construcción, sino de diseño. No quiero extenderme demasiado, la mejor explicación al respecto es el artículo de Jack Reeves: el código es el diseño.
En cuanto a lo segundo, quienes piensan que lo propio de un ingeniero es ser jefe de proyecto, lo que reflejan es una concepción taylorista del proceso de desarrollo de software, y con esa mentalidad es difícil gestionar proyectos en la actualidad.
Permitidme un paréntesis sobre la gestión de proyectos. Creo que conocéis cual es la concepción taylorista y creacionista del proceso de desarrollo de software. Aquella basada en la división de las actividades de análisis, diseño , construcción y pruebas, entre distintos grupos de personas, con distintos niveles jerárquicos de responsabilidad, mediante un proceso secuencial, dentro de sistemas formales documentalmente pesados. Éste es el enfoque ortodoxo y académico que promueven las prestigiosas consultoras. Nada que ver, por supuesto, con el verdadero desarrollo profesional de software.
He visto alguna vez por Barrapunto chistes sobre el tema. Efectivamente, si a un consultor le encargasen auditar el desarrollo del kernel de Linux, se llevaría las manos a la cabeza: ¿dónde están los diagramas UML?, ¿dónde está el diagrama de Gantt?, ¿y los documentos de diseño?, ¿qué hacen todos estos ingenieros picando código?. Si un consultor soltara estas preguntas en las listas de correo del kernel, todos los hackers se reirían de él, aunque no creo que perdieran mucho tiempo con la guasa, tienen cosas más importantes que hacer. Pero cuando este mismo discurso se mantiene dentro de una empresa, ante un foro de gerentes, directivos, y otros consultores, todos acaban congratulándose de que alguien por fin les entienda, y de que se proponga empezar a hacer las cosas bien, de forma "industrializada", como una "ingeniería".
El taylorismo es obsoleto en todas las demás ingenierías desde los años 70, cuando se desarrolló el toyotismo. No se si os sonarán términos como "Lean", "Kanban", "Jidoka", o "Kaizen", propias del ámbito industrial, pero seguro que sí os suenan las metodologías ágiles de desarrollo como Scrum o Programación Extrema, donde no hay ni jefes, ni analistas, ni testers, sino simplemente equipos de desarrolladores auto-organizados, donde todos prueban, codifican, analizan y documentan. La ingeniería de software es, curiosamente, una de las disciplinas más reaccionarias ante estos enfoques. Habría que tirar a la basura, o mejor, quemar en la hoguera, toda la bibliografía taylorista sobre ingeniería de software, que parte de la visión de la programación como una actividad de construcción, y del programador como un peón albañil.
Las grandes consultoras han apoyado el taylorismo, o el desarrollo de software mediante mano de obra barata y poco cualificada, porque durante muchos años ha sido un modelo muy rentable. Cuanto más improductivo es el modelo, más personal requieren sus clientes, y durante más tiempo, lo que implica mayores ingresos y beneficios. Si además se establecen procesos formales lentos y pesados, basados en la elaboración de montañas de documentación, los proyectos requerirán cada vez más recursos y más tiempo. Esta dinámica no es realmente intencionada, ni es exclusiva de la ingeniería de software. La tendencia de toda organización a multiplicar la burocracia para maximizar el esfuerzo fue descrita por primera vez por Cyril Northcote Parkinson en 1955, y es conocida como la Ley de Parkinson.
Es difícil hablar de calidad, talento, experiencia o cualificación dentro de un mundo como el del sector de las IT y los servicios de software, que es exactamente como el que describió Parkinson, aunque él se refiriese a la administración colonial británica. La productividad no importa, y las personas no son más que material fungible.
El resultado inicial de este modelo ha sido el prestamismo laboral o el bodyshopping, que tan rentable fue para las cárnicas y las presuntas consultoras, transformadas en ETTs encubiertas. En poco tiempo lograron colocar a tanta gente que la demanda de informáticos se disparó, y muchos treparon de forma vertiginosa. El primer varapalo llegó en el 2000 con la crisis de la puntocom, y la puntilla llegó con el inicio de los procesos de externalización y deslocalización a otros países durante la década siguiente, en busca de mano de obra barata.
El efecto del offshoring o la deslocalización para las consultoras españolas ha sido devastador. Se han ido quedando progresivamente sin proyectos, a medida que sus clientes trasladaban sus desarrollos a países como la India. Quisiera poner como ejemplo Movistar, que hace un par de años trasladó los desarrollos de sus sistemas de información a las software factories de Accenture en Argentina. Estos procesos de externalización y deslocalización en Telefónica siguen su curso aún. Hace unas semanas, por ejemplo, se comentó la concentración de unos 300 trabajadores en protesta por la externalización de Telefónica I+D a Ericcson e Indra.
Los cientos de Trabajadores de I+D que han sido "invitados" a cambiar de empresa, son pocos comparados con los cerca de 2000 que Telefónica segregará a Telefónica Global Technology, la nueva empresa del grupo.
La presidenta de TGT es la argentina María Fernanda Torquati, anterior directora de sistemas de información de Telefónica. Podéis encontrarla en la foto junto a Cristina Fernández de Kirchner, y otros directivos de Telefónica y Accenture.
Mientras en España ésta deslocalización implica la destrucción de cientos de puestos de trabajo, en Argentina supone la creación de miles de ellos, aunque posiblemente no muy estables. El modelo que se está exportando allí es el modelo de las cárnicas, que tanto daño ha causado en España.
La moda de la deslocalización proviene de otro tipo de industrias, como la del sector textil o el sector del automóvil, donde existen actividades de fabricación intensivas en mano de obra. Lo que se trasladan son las actividades de construcción o fabricación, mientras el diseño se mantiene en Europa. No tendría sentido deslocalizar el diseño, ya que no suele ser una actividad acometible por fuerza bruta, sino por personal altamente experto y cualificado, y su deslocalización a países en vías de desarrollo no implicaría ninguna reducción de costes. De hecho, el offshoring de las actividades de diseño multiplica los costes, ya que merma la productividad y la calidad, entre muchas ochas.
Gran parte de las empresas que promovieron durante los 90 un offshoring de las actividades de I+D a países como la India, se encuentran ahora en un proceso inverso de retorno a sus países de origen. Una muestra sintomática de esta marcha atrás es la obra "Decline and Fall of The American Programmer" de Edward Yourdon (1992), vaticinando la desaparición de los programadores en EEUU como consecuencia de la deslocalización. La mejor muestra de que estaba equivocado es "Rise & Resurrection of the American Programmer", el libro que escribió después para explicar por qué había fallado en todos sus vaticinios. Si visitáis estas obras en Amazon, echad un vistazo a los comentarios de Peter Norving, director de desarrollo de Google. Podéis comprobar por las fechas que en España acarreamos un desfase respecto a estas tendencias.
La precariedad laboral en el sector de las consultoras y los servicios de software es simplemente consecuencia de un prejuicio: la consideración de los informáticos como peones albañiles. La subcontratación, la contratación de perfiles poco cualificados, el fenómeno de las cárnicas, y la deslocalización a países en vías de desarrollo, no son más que consecuencias directas de esta visión de los informáticos como albañiles, y de su labor como una actividad que puede hacer cualquiera, acometible por fuerza bruta.
Mientras, las consultoras en España han sido víctimas de sus propios errores, ya que aquello en lo que han fallado miserablemente es en explicar que lo que los proyectos requieren no es fuerza bruta, ni mano de obra barata, sino personal experto y cualificado. Este personal cualificado también es más barato, ya que es más productivo, y no sólo produce más, sino que produce mejor o con mayor calidad. Al fin y al cabo eso es lo que realmente la gente espera de un consultor: alguien cualificado y experto.
Cuando las consultoras decidieron dejar de ser consultoras, para convertirse simple y llanamente en ETTs de mierda, operando al borde de la legalidad, firmaron sus sentencias de muerte. Creo que muchas empresas deberían estar planteándose hoy si quieren ser realmente ETTs encubiertas, y dedicarse a competir en mano de obra barata (lo que se me antoja harto difícil), o volver a ser consultoras, y empezar a combatir desde ya los procesos de deslocalización en sus clientes. Claro, es poco creíble que los mismos que han defendido las bondades del offshoring y de las software factories, defiendan ahora un modelo completamente contrario.
Hoy las consultoras deberían ser las primeras interesadas en defender un modelo basado en la productividad, en la experiencia, la cualificación y el talento. Y los informáticos también. En vez de combatir la precariedad laboral mediante colegios, sindicatos y privilegios, creo que deberíamos unir esfuerzos en erradicar el prejuicio inicial, que es la consideración de los programadores como peones albañiles, y la programación como una actividad de construcción. Hace falta para ello reescribir los libros sobre ingeniería de software desde el principio, y eso es lo que yo he pretendido hacer con "Ingeniería de Software Ágil"."