A finales del mes de julio la empresa convocó a la Representación Legal de los Trabajadores (RLT) para informar sobre Foreworth, una nueva herramienta que pretende implantar en determinados proyectos de GDNe (los cuales se han negado a comunicar a la RLT). Según nos trasladó, sería algo parecido a “SonarQube, pero a nivel individual”, una herramienta destinada a mejorar la calidad, la productividad y la competitividad frente a clientes y otros proveedores.
Pero esa comparación oculta es una diferencia fundamental. Foreworth no se limita a analizar la calidad técnica del código: identifica al usuario que lo genera y trata datos como su rol, fecha de incorporación al proyecto, equipo, porcentaje de asignación y lenguajes utilizados. A partir de esta información calcula métricas de productividad y calidad que podrán incorporarse como una fuente adicional a las valoraciones profesionales.
Por tanto, no estamos ante estadísticas anónimas sobre el funcionamiento general de un proyecto. Estamos ante una herramienta capaz de asociar resultados y métricas a trabajadores .
La empresa afirma que su objetivo es conocer la “salud” de los equipos, comparar proyectos, justificar la calidad ante los clientes y detectar acciones de mejora. Sin embargo, el análisis se centra exclusivamente en quienes desarrollan código. No mide con el mismo nivel de detalle las decisiones de planificación, las estimaciones deficientes, los cambios continuos del cliente, la deuda técnica heredada, la falta de recursos, los errores funcionales ni las decisiones organizativas tomadas desde arriba.
La responsabilidad se presenta como colectiva, pero la vigilancia se dirige hacia los desarrolladores.
Además, la propia empresa reconoce que Foreworth sólo analiza la fase de desarrollo y generación de código, sin estudiar el resto del ciclo de vida del proyecto. A pesar de ello, sus métricas se integrarán en la valoración global, se utilizarán para comparar equipos y podrán formar parte de compromisos con clientes, acuerdos de nivel de servicio e incluso penalizaciones contractuales.
Medir líneas de código o actividad en repositorios no refleja por sí solo el trabajo real. Un trabajador puede generar menos código porque resuelve problemas más complejos, revisa el trabajo de otros compañeros, documenta, corrige deuda técnica, presta apoyo al equipo o trabaja sobre sistemas heredados. Convertir esa realidad en una cifra aparentemente objetiva puede dar lugar a comparaciones injustas y conclusiones falsas.
Hoy puede presentarse como una ayuda para mejorar. Mañana puede utilizarse para clasificar equipos, negar promociones o subidas salariales, condicionar asignaciones a proyectos o construir argumentos sobre un supuesto “bajo rendimiento”.No afirmamos que la empresa haya reconocido expresamente que vaya a utilizarla para despedir. Lo que afirmamos es que no ha ofrecido garantías suficientes para impedirlo.
Según la empresa, la implantación comenzaría en un número reducido de proyectos y alcanzaría aproximadamente al 10 % de las personas de GDNe. El plan presentado consiste en seleccionar los proyectos, conseguir la aprobación del propietario del código, comunicarlo después a los desarrolladores y comenzar el análisis periódico. Es decir, el propietario del código podrá autorizar el uso de la herramienta, mientras que los trabajadores que serán monitorizados se limitarán a recibir una comunicación.
Desde Alternativa Sindical de Clase no nos oponemos a las herramientas que ayuden realmente a mejorar el trabajo. Nos oponemos a que la tecnología se utilice para aumentar la vigilancia, intensificar los ritmos y trasladar a la plantilla la responsabilidad por deficiencias organizativas que no controla.
Las cuestiones que se nos plantean con Foreworth
Si las métricas son únicamente de equipo, ¿por qué necesita identificar individualmente al usuario que genera el código?
Si la finalidad es medir la calidad global del proyecto, ¿por qué sólo se controla a los desarrolladores y no al resto de responsables y fases del trabajo?
¿Quién decidirá qué resultado es bueno o malo y con qué contexto se interpretará?
¿Quién tendrá acceso a los datos individualizados y durante cuánto tiempo?
¿Podrá un trabajador consultar, corregir o impugnar la información asociada a él o ella?
¿Qué peso tendrán estas métricas en las evaluaciones profesionales, promociones, categorías y salarios?
¿Qué garantía existe de que no se utilizarán para justificar un supuesto “bajo rendimiento” o futuras extinciones?
La empresa presenta Foreworth como una herramienta de calidad, pero lo que plantea es un sistema de medición individual sobre quienes generan el código. Una infraestructura que acumula datos sobre nuestra actividad y que, sin garantías claras, puede acabar condicionando nuestra promoción, nuestras condiciones laborales y nuestra continuidad en la empresa.
Por eso debemos exigir información completa, acceso de la RLT a los criterios y resultados, contextualización de cualquier métrica y garantías escritas de que Foreworth no será utilizada para sancionar, despedir, bloquear promociones, limitar subidas salariales ni establecer clasificaciones individuales. La tecnología debe servir para facilitar nuestro trabajo, no para convertir cada actividad en una cifra al servicio del control empresarial.
Pero las exigencias que vayamos a trasladar desde la RLT a la empresa no tendrán la suficiente fuerza si la plantilla permanece al margen como un testigo silencioso del empeoramiento de las condiciones laborales. Afiliarse, participar y alzar la voz no es un gesto simbólico. Es una forma de defensa colectiva. Contacta con nosotros para ampliar las filas del sindicalismo de clase.
Alternativa Sindical de Clase
Organización, solidaridad y acción. Siempre.







.png)

