¿Qué ocurre tras las puertas de la fábrica del trabajo en software? A través de un análisis del proceso de trabajo de los programadores de computación, Larissa Petrucci complejiza ciertas nociones del trabajo cognitivo y del trabajo inmaterial.
A lo largo de sus investigaciones, que incluyen entrevistas con trabajadores de esta industria, Petrucci ha encontrado una adaptación de la organización científica del trabajo con otras prácticas precedentes. Incluso desafía la noción vigente respecto a lo que imaginamos que ocurre en esta industria tan reciente como específica. La investigadora habla de “Flexibilización Taylorizada”, concepto que en inglés realiza un juego de palabras haciendo referencia al nombre de Frederick Winslow Taylor, iniciador de la organización científica del trabajo, y la palabra ‘tailored’, que se traduciría como ‘a medida’.
La conversación también menciona a Harry Braverman, quien publicó en 1974 ‘Trabajo y capital monopolista’, llevando nuevamente la atención de los sociólogos sobre el proceso de trabajo. Allí el autor entre otras cosas presenta su famosa ‘tesis sobre la degradación del trabajo’, en la cual -en modo simplificado- argumenta que el capital tiende a reorganizar el proceso de producción (entre otras formas a través de la introducción de tecnología) de forma tal que las tareas requieren cada vez menos calificaciones por parte de los trabajadores, abaratando los costos de producción.
Resaltando las similitudes en las formas de control y disciplina de estos trabajadores con aquellos en la industria automotriz, la investigadora nos impulsa a discutir a su vez, las posibilidades de resistencia y organización colectiva en este estratégico sector.
Lola Loustaunau (LL): Lo primero que quiero preguntarte es ¿qué consideras que es específico sobre estudiar el proceso de trabajo de la producción de software?
Larissa Petrucci (LP): Creo que la propia naturaleza de la producción de software tiene algunos componentes particulares. Especialmente porque es una industria que se mueve muy rápido. Todo el tiempo se desarrolla software nuevo, lo que significa que las necesidades de tus clientes también van a cambiar. Si bien en la manufactura de ciertos productos sabes cuál es el producto final, en el software es más difícil de anticipar. Esto a su vez significa que hay tanto continuidades como diferencias entre la organización del proceso del trabajo, y las formas de control y disciplina de la fuerza de trabajo en la manufactura y en la producción de software.
LL: ¿Esto significa que ves la emergencia de nuevas formas de organización y control del proceso de trabajo que son específicas a la producción de software?
LP: Sí y no. Tentativamente he llamado a la forma de organización del trabajo que he encontrado en la producción de software ‘Taylored Flexibility’. Actualmente, la mayoría de las compañías de software usan AGILE, un sistema para organizar el trabajo. AGILE es en realidad el nombre de una filosofía de organización del trabajo en software donde podemos encontrar distintos métodos específicos, pero en general todos siguen una idea de desperdicio mínimo, mejora continua, aumento de la predictibilidad y flexibilidad frente al cambio.
Si le preguntas a un experto en AGILE te dirá que no es un método, es un marco, una filosofía con principios que guían la forma en la que el trabajo debe ser realizado. De alguna forma AGILE es un derivado del toyotismo o de la producción flexible. En la década de 1990, la producción de software enfrentaba un desafío similar al que enfrentó Toyota en los años 1950: necesitaban minimizar riesgos y gastos.
La producción de software solía estar organizada bajo un método llamado Cascada (Waterfall). En el método Cascada, de forma similar al fordismo, se usaba una línea de ensamblaje secuencial, la cual ha sido llamada la ‘línea de ensamblaje virtual o digital’. Como sucedía con Ford, al final de la línea tenías productos con muchos errores y no había otra solución que empezar de cero. Esto era aún más problemático en una industria donde los tiempos son tan rápidos, implicando que muchas veces el producto ya debía cambiar completamente, generando una gran insatisfacción de parte del cliente. AGILE busca solucionar este problema a través de la incorporación de muchos aspectos del toyotismo a la producción de software, cambiando totalmente la línea de trabajo.
AGILE introdujo equipos con funcionalidad cruzada. Antes había un equipo de diseñadores, un equipo de ingenieros, un equipo haciendo pruebas de calidad, cada uno trabajando en un momento distinto del proceso, similar a la línea fordista. Con AGILE, cada equipo suele tener un diseñador, uno o dos ingenieros, una persona haciendo control de calidad, y un ‘dueño del proyecto’ o manager, que supervisa todo el desarrollo. Usualmente, si la compañía usa SCRUM, que es un tipo de AGILE, el trabajo se organiza en lo que se llaman sprints. Los sprints son periodos de dos semanas en los que se organizan metas parciales. AGILE trata de evitar organizar el trabajo en horas, y en cambio habla de ‘historias’ (que son subproductos o metas todavía más parciales). La cantidad de trabajo necesaria para finalizar las metas del sprint se calculan en ‘puntos narrativos’ de cada historia. Si uno sigue el Manifiesto de AGILE, explícitamente dice que no hay que traducir los puntos narrativos a horas. Pero claramente eso no sucede, porque los líderes de los equipos en última instancia necesitan saber cuántas horas va a tomar cada punto narrativo lo que implica que las horas que se trabajan varían Lo que emerge en mi investigación es que esto no significa necesariamente que los trabajadores trabajan más de 40 horas por semana.
LL: ¿AGILE trata explícitamente de borrar la conexión entre un producto y horas de trabajo?
LP: Si, trata de borrar la relación entre horas de trabajo y productividad. Sin embargo, si se sigue el método SCRUM por ejemplo, los trabajadores deben medir su velocidad (velocity) en cada sprint. Tu velocidad es básicamente cuantos puntos narrativos hiciste en una semana, cuan productivo fuiste.
LL: ¿Entonces los trabajadores tienen que registrar sus horas?
LP: Sí, por supuesto. La cuestión es que puede llevarte 60 o 20 horas completar un punto narrativo, y la productividad se calcula siempre en un periodo de dos semanas. Además, el registro sucede a través del mismo programa que se usa para crear el nuevo software, forzando a los trabajadores a tratar de aumentar su velocidad cada semana, siendo cada vez más y más rápidos. Algunos de los trabajadores que entrevisté dijeron explícitamente, que intentan no registrar su velocidad porque les da miedo la forma en la que el manager los controla de forma tan inmediata. La filosofía oficial de SCRUM dice que ayuda a organizar el trabajo a través de una ‘Teoría Empírica del Control de Procesos’ (Empirical Process Control Theory), que es básicamente una organización científica del trabajo. He analizado múltiples videos de management y una de las cosas que recomiendan a las compañías que recién están comenzando a implementar AGILE es que los managers caminen hacia los escritorios de los trabajadores y calculen el tiempo que les lleva terminar un punto narrativo para poder predecir más efectivamente cuánto les va a llevar terminar un determinado proyecto.
LL: No hemos ido muy lejos de Taylor entonces…
LP: Exacto, y es por eso que yo me refiero a esta forma de organización del proceso de trabajo como ‘Taylored Flexibility’. AGILE toma elementos de la organización científica del trabajo de Taylor vis a vis esta ‘Teoría Empírica del Control de Procesos’, y suma ciertos elementos del toyotismo para lograr flexibilidad y predictibilidad, elementos que pueden ser muy difíciles de lograr a la vez. La forma en la que las empresas de software buscan flexibilidad es volviendo al cliente y al producto, sin prometer un producto final en particular. La introducción de AGILE no cambia solo la organización de la producción, cambia el producto que se está vendiendo.
Si una compañía usa AGILE ‘puro’ -algo que es muy difícil de hacer y que casi ninguna compañía hace- el cliente no pide un producto, cuenta un problema que necesita resolver o una necesidad que tiene. La compañía se compromete a una línea de tiempo para resolver el problema o la necesidad, pero no a producir un producto en particular. El producto final puede ser tan grande o pequeño como se determine que sea necesario para satisfacer la necesidad del cliente, pero siempre tratando de crear lo que llaman el ‘menor producto viable’, o sea tan pequeño como sea posible, con la menor cantidad de trabajo, con la menor cantidad de inversión, en la menor cantidad de tiempo. Este acercamiento para minimizar el desperdicio (waste) les da a los ingenieros mucho menos margen para ser creativos en la programación, porque necesitan resolver todo de la forma más simple y rápida posible. Esto significa en muchos casos, como me dijo un manager que entrevisté, que tiene que evitar que los programadores realicen el tipo de programación más creativa que los suele entusiasmar.
LL: ¿Conectas esta situación con la tesis de Harry Braverman sobre degradación del trabajo?
LP: Comencé a pensar en la degradación del trabajo debido a la existencia de los Coding Bootcamps, campos de entrenamiento para programadores que suelen durar entre 6 y 12 semanas. Los trabajadores suelen pagar ellos mismos la cuota. Las compañías acuden a hacer el reclutamiento de nuevos programadores. En estos programas acelerados, los trabajadores aprenden a programar de forma muy limitada y específica. Lo que AGILE intenta crear son ‘especialistas generales’ (generalizing specialists) Estos programas cortos reemplazan a un título universitario en ciencias de computación o ingeniería. De hecho, mucha gente que entrevisté que trabajan como programadores tiene títulos universitarios pero en otras áreas no relacionadas en absoluto con programación.
LL: ¿Entonces AGILE es predicción + flexibilidad + intensificación de los tiempos de trabajo: una mezcla de taylorismo y toyotismo?
LP: Si, de hecho el toyotismo es en sí mismo una forma híbrida, que toma elementos del fordismo y los mezcla con ciertos métodos de organización nuevos. Entonces creo que es incorrecto pensar que Ford o Toyota estaban implementando modelos totalmente nuevos. Lo mismo ocurre con AGILE, no es totalmente distinto del método ‘Cascada’, ni es totalmente diferente de otras formas de organización del proceso de trabajo anteriores, es una forma híbrida que mezcla organización científica del trabajo con producción flexible.
LL: ¿Qué es lo que aquellos que estudian los procesos de producción de software no han podido captar aún de lo que sucede en esta industria?
LP: Muchos de los argumentos que se hacen acerca de cómo se logra que los trabajadores en la industria del software realicen su trabajo, o cómo se controla y disciplina la fuerza de trabajo del trabajador ‘cognitivo’ o ‘intelectual’, se centran en el rol del control ‘cultural’, y enfatizan el rol de la cultura empresarial: el compromiso que se cultiva entre los trabajadores y la compañía a través de cierta identificación con la empresa. Inclusive aquellos académicos más preocupados por el rol de la disciplina sólo señalan el papel de la internalización de la vigilancia y la supervisión a través del trabajo en equipo.
Sin duda, es verdad que AGILE busca fomentar una forma particular de compromiso de los trabajadores; intenta empoderar a los trabajadores de software y que ‘no se supone que haya jefes, sino líderes que inspiren a los trabajadores a hacer fuertes compromisos sobre cuánto trabajo van a hacer’. Entonces, en parte, los argumentos que se hacen sobre formas de control cultural son verdad, esto sucede en la producción de software, pero lo que nadie dice es que hay disciplina en la forma en que AGILE estructura materialmente el trabajo.
Los trabajadores son a su vez, y yo diría principalmente, controlados a través de una organización del proceso de trabajo que los obliga a trabajar lo más rápido posible para lograr llegar a la meta que fijaron con su equipo y que incluye evaluaciones permanentes de desempeño que afectan si vas a recibir un aumento o no, que afectan si vas a seguir teniendo trabajo o no, y no sólo tú sino todo tu equipo. Tienes que ir a reuniones todos los días donde debes reportar como fue tu desempeño el día anterior, y qué problemas estás enfrentando. Entonces, mientras pensamos que los trabajadores de software han ganado autonomía en el lugar de trabajo, AGILE realmente intensifica la visibilidad sobre el propio proceso de trabajo. Si tú no logras llegar a tu meta en el sprint, eso va a tener un impacto muy negativo para ti. De tal manera, no es sólo ‘cultura’, son todos estos mecanismos que reorganizan la forma en la que se realiza el trabajo para tratar de aumentar la productividad y la eficiencia. AGILE nos muestra que a pesar de que el trabajo en software es ‘digital’ y que requiere una mano de obra altamente calificada —elementos que han llevado a ciertos autores a argumentar que esto disrumpe el antagonismo capital/trabajo porque esta forma de trabajo se vuelve más difícil de disciplinar y controlar— los trabajadores de la industria del software no han escapado del comando del capital sobre el proceso de producción y su búsqueda permanente de aumentar la productividad, la eficiencia y la predictibilidad. Creo que esto además tiene serias implicaciones para los tipos de innovación que son posibles dentro del capitalismo. Muchos trabajadores entrevistados explicaron que se sienten obligados a 1) buscar atajos para llegar a cumplir las metas, 2) crear nuevos programas en pequeños incrementos de forma tal que los usuarios necesitan estar constantemente renovando el producto que compraron (obsolescencia programada) y 3) los trabajadores se ven obligados a cumplir con demandas organizacionales que limitan seriamente la posibilidad de ser creativos.
LL: ¿Cuáles son tus críticas a aquellos que conectan la producción de software con una forma de trabajo inmaterial, que sería fundamentalmente distinta de la producción de otras mercancías?
LP: Mi crítica primariamente es que creo que esos análisis perpetúan un dualismo entre trabajo mental y manual que asume que 1) hay procesos de trabajo que tienen lugar “fuera de” o sin ‘el cuerpo’ y, 2) que el trabajo intelectual, por ocurrir ‘en la mente’, escapa a formas disciplinarias conectadas con el cuerpo. Un ejemplo claro es que muchas veces asumimos que los trabajadores de software trabajan desde sus casas, o desde cualquier lado, ¿no? Porque si, son trabajadores digitales, virtuales, pueden trabajar donde quieran. Pero la realidad es que casi ninguno de los que entrevisté trabaja desde su casa. De hecho, el manifiesto AGILE dice que es preferible que los trabajadores estén en un mismo lugar, que los equipos estén trabajando en un mismo espacio, uno junto al otro, y esto es —lo dice explícitamente— para que la información circule lo más rápido posible entre los equipos y para que el proceso de trabajo sea siempre visible para los managers. AGILE asume directamente que la información circula más rápido en persona, de cuerpo a cuerpo que a través de un chat o en una plataforma virtual. Eso es algo que quienes estudian trabajo cognitivo no han sabido reconocer o incorporar: el hecho de que los cuerpos de los trabajadores ‘inmateriales’ están siendo agrupados de la misma forma que Ford o Taylor agruparon a los distintos obreros manuales en un fábrica. Muchos autores asumen que el trabajo intelectual no es susceptible a las mismas formas de control que el trabajo manual, y creo que AGILE nos da evidencia concreta de que al contrario, este tipo de trabajo es susceptible a formas de organización científica del trabajo, bajo formas muy específicas y rígidas de control de eficiencia y productividad.
LL: ¿Crees que AGILE impacta la posibilidad de organización colectiva de estos trabajadores?
LP: AGILE crea una forma de consentimiento que impide que los trabajadores se agiten y organicen similar a la que lograba Toyota, principalmente por su forma post-burocrática, post-jerárquica de organizar los equipos. Muchas empresas han otorgado cierto espacio para que los trabajadores tomen decisiones dentro de los equipos o tengan ‘voz’ y esto crea cierto nivel de consentimiento en la producción, sin duda. Sin embargo, creo que la creencia de que los trabajadores de software no pueden ser organizados colectivamente de la misma forma que los trabajadores en manufactura por ejemplo, es infundada. Como dije, al contrario de lo que muchos creen, los programadores no están aislados en sus casas, sino que en la mayoría de los casos trabajan juntos en oficinas. Creo que cometemos un error al desestimar la capacidad y posibilidad de organización colectiva de estos trabajadores.
Hice un estudio piloto con una organización internacional bastante amplia que nuclea trabajadores de software/tecnología. Una de las cosas que están haciendo es intentando organizarse de forma intersectorial, no sólo programadores sino junto a trabajadores de logística, trabajadores de mantenimiento y limpieza, trabajadores de comida, dentro de las mismas compañías de tecnología y software.
Especialmente en los Estados Unidos, luego de la elección de Donald Trump como presidente, vemos la emergencia de organizaciones de trabajadores de software que están cada vez más conscientes de las implicaciones políticas del software que están construyendo. Muchos programadores están cada vez más incómodos con las formas en las que su trabajo es utilizado, incluso algunos entrevistados reconocen que son indirectamente parte del complejo industrial militar, y esto los ha movilizado a la acción. Por ejemplo, un grupo de trabajadores de una corporación que crea software de seguridad utilizado por ICE y por la policía, comenzó una campaña que se llama ‘Tech no lo construirá’ (‘Tech won’t build it’) y decidieron realizar una huelga reteniendo su trabajo, rehusándose a construir software que iba a ser utilizado en los centros de detención de ICE. En otro caso, los trabajadores de Amazon firmaron una carta pidiéndole que cambie ciertas prácticas que tienen un gran impacto ambiental, intentando organizarse para no programar más software que agrava el cambio climático. Los trabajadores de Amazon dicen que el software que construyen constituye casi la mitad de internet globalmente. Si ellos interrumpen su proceso de trabajo, las ramificaciones podrían ser masivas. Creo que los trabajadores de software están comprendiendo el poder de su trabajo.
Por supuesto necesitamos más conversaciones, necesitamos más y mejor organización, necesitamos elevar la conciencia de clase, no estoy diciendo que todos los trabajadores de software están listos para romper sus computadoras y dejar ya mismo de construir software para ICE, pero sí que estamos viendo muchas más conversaciones al respecto, en muchos lugares de Estados Unidos y en el resto del mundo, sobre el rol que los trabajadores de software pueden y necesitan tener en el enfrentamiento de la crisis global que atravesamos.