Muchos ambientes laborales ejercen presión para que se trabajen más de ocho horas al día, para que se contesten correos a cualquier hora y para que voluntariamente se regale el tiempo libre — vacaciones, noches y fines de semana— sin quejarse. ¿Ha contribuido la filosofía Agile a disminuir este problema?
Todos conocemos como va el cuento: las empresas venden el alma al diablo en tiempos de oferta y luego, como no podía ser de otra forma, los presupuestos estimados no coinciden con la realidad. Las consecuencias —entre muchas varias— impactan enormemente en la cantidad de trabajo fuera de horas que los equipos de proyectos se ven obligados a realizar para cumplir con las promesas inviables hechas durante los procesos de venta. El Overtime es la herramienta comodín para solucionar estos desfases.
Son muchos los argumentos a favor y en contra del Overtime. Desde estudios que sugieren que trabajar fuera de horas es totalmente dañino para la salud, como estudios que sugieren que cada persona debe tener la libertad individual de elegir. Además del famoso debate contemporáneo entre el Work-life Balance y el Work Life Integration.
O trabajar para vivir o vivir para trabajar. Cuestión de gustos.
Curiosamente nuestra percepción sobre las horas trabajadas por semana ha venido cambiando con el devenir de los siglos. Quizá los conceptos de estado de bienestar y calidad de vida serían incompresibles para alguien que habitó el mundo no menos de doscientos años atrás. En concreto, Juliet Schor estimó que las horas de trabajo totales de un trabajador por año durante los siglos XX y XXI son considerablemente menores que durante el siglo XIX (De 60 horas por semana en 1900 a 40 horas por semana en la actualidad).[1]
Pero la evidencia parece indicar que la tendencia actual es nuevamente creciente(hasta casi 60 horas por semana) [1]. Y, en general, son realmente muy pocos los trabajadores que a día de hoy pueden disfrutar de cuarenta horas de trabajo semanales. En especial —tema que nos atañe— en el mundo de los proyectos de software.
La propuesta de Agile de lograr en el largo plazo lo que llaman la sustainable pace es teóricamente impecable, pues son los miembros del equipo quienes deciden su carga de trabajo. Aplicando procesos iterativos e incrementales, por ejemplo, cuando los equipos logran su velocidad de crucero se genera cierto grado de predictibilidad que reduce considerablemente los esfuerzos en horas extras. En concreto, un estudio llevado por Chris Mann y Frank Maurer de la Universidad de Calgary[2] en 2005 encontró que usar prácticas Agile puede reducir más de un 10% la cantidad de overtime.
Pero esto parece no ser más que un estudio anecdótico. En la práctica, estas condiciones no se cumplen por múltiples razones: Por un lado, en los inicios de los proyectos no suele generarse un clima de confianza tal que permita al equipo alcanzar su velocidad de crucero. Las presiones constantes de los responsables del proyecto o del producto, someten al equipo a tal nivel de estrés, que terminan sobrepasando forzosamente su carga de trabajo normal; Por otro lado, son muchas las empresas que adoptan procesos ágiles más de fotografía que de radiografía y la forma en que se estructuran suelen ser un gran factor contribuyente a este problema: empleados que intentan obtener resultados por encima de las expectativas para conseguir ascensos, bonos empresariales resultadistas, amenazas de despidos y presiones por parte de los responsables, etc.
Aunque los procesos ágiles pueden ayudar a reducir el Overtime, no lo pueden hacer por si solos.
Los proyectos suelen predecir su éxito o fracaso en función de cómo se articulen desde el comienzo. La manera en que negociamos, definimos el alcance y establecemos las condiciones y acuerdos de trabajo tienen una influencia significativa en el resultado. Es aquí dónde quizá debamos buscar.
El problema, entonces, parece poder cortarse de raíz solo si atendemos al proceso de venta. Pero es un círculo vicioso: la feroz y depredadora competencia que proponen los clientes no dejan margen de actuación. Las licitaciones en las que participan los proveedores suelen ser malintencionadas y existe, en muchos casos, un claro aprovechamiento de los clientes para conseguir precios muy por debajo de lo que realmente cuestan los proyectos.
Aunque Agile propone un tipo de contrato abierto (bolsa de horas, time and materials y alcance variable), en muchos casos no es una opción atractiva para un cliente que simplemente quiere compromisos e hitos en una fecha determinada. Compartir las gestión y los riesgos no es una opción cómoda. Y los clientes lo saben.
Hace falto algo más. ¿Pero qué puede ser?
La respuesta, más allá de los argumentos morales o empresariales, desde luego no es sencilla y queda mucho camino por recorrer. Mucho. Y lamentablemente va mucho más allá de un cambio de metodología. Todavía se puede hacer mucho dinero tratando mal a la gente.
Referencias
[1] Ellwood B. Mark. THE INEFFICIENCY OF OVERTIME
[2] Mann, Chris, and Frank Maurer. 2005. A case study on the impact of Scrum on overtime and customer satisfaction. In Proceedings of the Agile Development Conference, 70–79. IEEE Computer Society.
Image: (c) 2013,Peter Doucette, Todos los derechos reservados
1 comentario