La Teoría Española del Valor, las horas extra no se pagan

Hay una frase que se me ha quedado grabada en la cabeza. Fue hace mucho tiempo, en una de las grandes consultoras de software. Estábamos hablando de las condiciones de un proyecto y alguien preguntó por las horas extra, a lo que el responsable respondió «no solemos hacer muchas, pero si hay que quedarse te quedas».

Si estás sonriendo puede ser por dos cosas: o porque te ha tocado sufrirlas y te resulta irónico, o porque las gestionas y te duele que la gente no entienda la presión a la que están sometidas las empresas para cumplir plazos y presupuestos.

Lo que resulta triste es que esta costumbre, la de estrujar a la gente exigiendo horas no retribuidas, tiene nombre y se llama Teoría Española del Valor. Está recogida en el libro Peopleware de Tom de Marco y Timothy Lister y aparece casi al principio, como uno de los síntomas más contundentes de una mala gestión empresarial. Si leemos en la página 17, encontrarás lo siguiente: «Los directivos de la Teoría Española sueñan con alcanzar nuevos niveles de productividad a través del simple mecanismo de las horas extraordinarias no remuneradas. Dividen cualquier trabajo que se haga en una semana entre cuarenta horas, no entre las ochenta o noventa horas que el trabajador realmente dedica«.

Es perturbador la claridad, simplicidad y contundencia con la que de Marco y Lister recogieron en poco más de cuatro líneas de texto el dogma de la gestión del trabajo que impera en muchas consultoras de software. En realidad no es algo exclusivo de la cultura española y ocurre en todo el mundo, ya que los autores recogían en el libro la frustración de tener, una y otra vez, que rebatir la creencia de que esta es la única forma de ser competitivo en la actualidad. La «actualidad», en el momento de escribir el libro, era a mediados de los 80 en Estados Unidos en empresas americanas, no españolas. Aunque tenemos que reconocer que esto es la norma aquí. Treinta años después, cinco o seis revoluciones tecnológicas más tarde, las cosas siguen exactamente igual o peor. ¿Cuánto?

Según datos del Instituto Nacional de Estadística, en los primeros meses de 2018 se han realizado unos diez millones de horas extra no remuneradas. DIEZ MILLONES. Eso es equivalente a más 6.000 puestos de trabajo, que al salario mínimo interprofesional son unos 45 millones de Euros. Es un trabajo que se ha hecho y que se ha cobrado, sin pagar a los empleados. Y eso siendo generosos con el cálculo y asumiendo un sueldo mínimo. ¿Es normal esta forma de hacer las cosas? Si miras el gráfico de la derecha, debe ser que sí, porque aunque en los últimos cinco años hay un ligero descenso, la media sigue estando por encima de las 700.000 horas semanales no remuneradas.

Ni la llegada de Internet, ni el paradigma de la oficina sin papeles, ni el teletrabajo, ni la revolución en la gestión ágil, ni la digitalización de procesos. Nada ha servido en treinta años para cambiar una forma de pensar en la que los responsables de cuenta fijan fechas arbitrarias de entrega de los proyectos sin consultar a las personas que tienen que realizarlos y, cuando la realidad y las dificultades técnicas se imponen en el camino, la única respuesta es: «haced lo que queráis, quedaros las horas que sea, pero esto tiene que estar listo para el jueves». Eso lo he vivido yo varias veces y seguro que tu, lector, también lo conoces.

No sé cual es la causa. Lo que sí sé es que existe un efecto perverso en todo esto cuando, después de varios días de trabajo extenuante de la plantilla, renunciando a comidas, sueño e incluso vida familiar, llega el jueves, se entrega el proyecto y el responsable se ve reforzado en su posición, jactándose de que la gente se queja de vicio y que esa entrega confirma que la suya es la forma de trabajar correcta. Y no lo es.

¿Cómo podemos razonar que una práctica que lleva implantada décadas y que parece ser uno de los elementos clave en la rentabilidad de las empresas de tecnología, no sea la forma correcta de hacer las cosas? Por los índices de rotación del personal; aquí tienes un artículo sobre cómo calcularlo. La informática es una profesión curiosa, en la que NADIE se mete para ganar dinero. De verdad, no he conocido en 30 años a nadie que se metiera en esto para hacerse millonario. Todos nos hemos metido porque nos encantaba cacharrear, jugar con las máquinas, construir. La forma en que se gestionan las cosas consigue de forma sistemática que gente que adora su trabajo (los informáticos) terminen odiando su profesión.

Porque podría hablarte mucho de cómo la Inspección de Trabajo ha dicho que se va a tomar mucho más en serio lo de la vigilancia, o las dos sentencias del Tribunal Supremo que dicen que los trabajadores fijos también deben fichar y contabilizar todas las horas realizadas. Pero a mí lo que me interesa es la realidad práctica, la forma en que los gestores de proyecto podemos afrontar esta realidad. Cuando un responsable de cuenta te dice que si no acepta esas condiciones de plazos y costes pierde el contrato ¿qué puedes decirle?

Mi respuesta más habitual es que a lo mejor ese cliente no te interesa. Sí, sí… ya sé que me vas a decir que en un mundo ideal todos somos felices y los pajaritos cantan, pero que el mundo es gris y que las cosas son así, que no puedes ser selectivo por lo que te entra por la puerta porque entonces cierras la empresa. Hay muchas formas de segmentar el mercado y no todas las empresas que optan por implantar un criterio de selección de clientes terminan en la quiebra; más bien al contrario. Déjame que me explique.

Cuando digo que «no te interesa» quiero decir que te preguntes si realmente es rentable trabajar de esa forma; porque cuando entras en una negociación en la que el único criterio de concesión es el coste (porque si no aceptas esas condiciones no te lo dan) te has quedado sin armas de negociación. Si lo único que te queda es bajar las horas, ¿qué harás cuando otro lo baje un poco más? 

Adoptarás la Teoría Española del Valor, que dice que el número de horas trabajadas es cuarenta a la semana, con independencia del número de horas reales que se hagan. Así los plazos y costes laborales siempre cuadran. Pero ¿qué harás cuando no puedas bajar más, cuando la gente no aguante más y se vaya? Ninguna empresa parece tener en cuenta los costes de renovación de personal, los enormes plazos de aterrizaje y formación informal, hasta que el nuevo empleado es verdaderamente productivo.

Creo que una de las cosas que debemos aceptar para romper este círculo vicioso es la premisa que distingue las metodologías ágiles de las secuenciales (cascada). Y no es que las ágiles sean mejores o peores, que no lo son, sino que están pensadas para responder a entornos de gran incertidumbre, en las que los clientes no saben lo que quieren con claridad y tu no sabes cómo fabricarlo con certeza.

En estas situaciones, comprometer plazos y costes como se viene haciendo desde hace tanto tiempo es una pésima gestión del riesgo, porque comprometes márgenes contra la incertidumbre y, cuando no se cumplen las expectativas, imputas la diferencia a las horas extra, enmascarando el déficit con el trabajo no remunerado de la plantilla, que se lleva la peor parte sin que se le recompense de forma alguna. La entrega a tiempo no es un éxito de gestión. Por eso es por lo que en estos entornos no deberíamos usar marcos como el PMBoK ni comprometer fechas.

Lo que sí podríamos hacer es seguir un modelo alternativo que siguen muchas empresas, que es la bolsa de horas. Tu no comprometes un proyecto cerrado en tal fecha, sino que contratas un cierto número de horas mensuales a un proyecto en el que, mes tras mes, se va entregando valor con las sucesivas entregas. Esta alternativa, que seguramente habrás visto en algún sitio, es perfectamente compatible con Scrum y reduce enormemente el problema de las horas extra y los incumplimientos.

Si trabajas con la Administración o ciertos clientes, puede que me digas que esa forma de trabajar es muy bonita, pero que cuando te llega un pliego de condiciones hay que dar una oferta cerrada. Voy a decirte algo y piénsalo detenidamente: ¿qué prefieres, decir desde el principio a las claras que ofreces una relación estable por bolsa de horas o entregar cualquier cosa y luego decir que el proyecto está «en mantenimiento» para solventar las meteduras de pata de la fecha límite? Eso de «en mantenimiento» es una de las expresiones que, cuando las oigo, sé positivamente que la empresa que la usa no tiene ni idea de cómo gestionar un proyecto. No hay proyectos en mantenimiento; hay proyectos terminados o no terminados, funcionalidades acabadas o no acabadas, pero no «en mantenimiento». En mantenimiento sólo significa que no sabéis dónde estáis, qué quiere el cliente (lo normal es que no lo sepa ni él), lo que hace falta, cuánto va a costar o cómo se hace.

Lo que falla no es la oficina virtual, ni Internet, ni los técnicos, sino la negativa a aceptar que un mercado de gran incertidumbre requiere una metodología y un contrato que refleje esa incertidumbre. No con penalizaciones que irritan a todas las partes, sino con una comprensión del problema y un plan que haga frente a esa realidad. El PMBoK es perfecto para proyectos en entornos maduros. Y Scrum puede estar muy bien en entornos de incertidumbre. Recuerda el viejo dicho japonés: para un martillo, todo son clavos. No caigas en ese error.

Dejar una contestacion

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *