archivo

Archivo de la etiqueta: overtime

¿Es realmente rentable hacerlo? Una cosa es que sea de la opinión de que una persona rinde más y mejor con una dedicación completa a un proyecto y otra que niegue que en ocasiones sí que puede ser rentable tener a una persona compartida entre varios proyectos porque así se va a poder gestionar mejor los períodos de valle y carga y se va a tener una mayor seguridad de que la persona va a estar ocupada en tareas facturables un porcentaje de tiempo mayor.

Como siempre, un análisis del contexto es el que te llevará a tomar una determinada decisión (acertada o no), no obstante, en caso de duda, soy partidario de reducir ese fraccionamiento todo lo posible.

Hay que tener en cuenta que no siempre van a coincidir valles y picos de carga, es más, es muy probable que la mayoría de los proyectos en los que trabajes tengan una carga importante, lo que te llevará muy probablemente a una situación de overtime y ese no será el único problema, ya que los cambios de contexto llevarán más tiempo, lo que se sumará a la situación de que estés trabajando en un proyecto y, sin embargo, estés pensando en el resto.

Es curioso, tu tiempo estará compartido pero la presión que sentirás será muy similar a la que tendrías si trabajaras a tiempo completo en cada uno de los proyectos.

Un error muy frecuente que nos encontramos con las estimaciones lo tenemos en pensar que se van a dar condiciones ideales: no se van a sufrir interrupciones inesperadas, no vamos a sufrir contratiempos técnicos y la capacidad calculada para cada persona no va a sufrir cambios (en el momento en que una persona por el motivo que sea no puede ir a trabajar un día, rompe ya los esquemas).

Si a eso le sumamos lo difícil que resulta acertar, estamos sometiendo cada sprint a una presión que los desarrolladores no van a poder aguantar porque la realidad será que para cumplir los compromisos se tendrá que incrementar la capacidad de todos y eso se traduce en overtime. El otro camino es dejar historias de usuario comprometidas para más adelante (sacarlas de la pila de sprint). Ambas soluciones son malas. La primera porque no es sostenible, ya que incluso los equipos más motivados no pueden aguantar un ritmo por encima de sus capacidades físicas durante un tiempo prolongado y la segunda porque perdemos predecibilidad y fiabilidad.

Ten en cuenta en que fase del proyecto te encuentras, no tienes el mismo conocimiento al principio que tras la sexta o séptima iteración y ten en cuenta que no se puede asegurar capacidades del 100% de nadie. Se puede estar asignado al proyecto un 100% pero prever una capacidad para el sprint inferior a esa, si después resulta que no han existido contratiempos y puede estar al 100% pues mejor, ya que así aprovechará para ayudar a otros compañeros, para ayudar a resolver contingencias que hayan podido ocurrir en la iteración, para refactorizar, etc…).

El equipo recibe muchas presiones (y quién esté libre de pecado que tire la primera piedra) para que asuma el mayor número de historias de usuario posible. Se tiene que aprender a decir que no y a respetar las condiciones para que un conjunto de personas puedan cumplir sus compromisos sin tener que reventarse.

Las prisas, esas prisas. Esa intención de tratar de sacar el máximo valor posible al presupuesto a costa de la presión y un esfuerzo de los desarrolladores por encima de lo recomendable, es algo en lo que hemos caído la mayoría.

Es el tiempo el que te enseña que tal vez de esa forma ganes alguna batalla pero terminarás perdiendo las guerras.

No puedes someter a los desarrolladores a una sobrecarga de trabajo y a una presión excesiva durante un tiempo prolongado. Llegado el momento todos podemos hacer un esfuerzo pero esa línea se debe adaptar a límites sostenibles lo antes posible y no mantenerse (o empeorar) porque al final, los desarrolladores no podrán mantener el ritmo y se resentirá todo, primero las personas, segundo el equipo, tercero el producto y cuarto el proyecto.

Para Niklaus Wirth: “La presión del tiempo corrompe gradualmente el estándar de calidad y perfección del ingeniero, y esto tiene un efecto muy negativo tanto en las personas como en los productos”.

Salvo que cumplir un determinado plazo sea esencial (y que lo sea de manera objetiva porque después la realidad termina mostrando en muchos casos que esos plazos inamovibles eran más caprichos que otra cosa), hazte el planteamiento de que lo más recomendable es conseguir un valor óptimo del producto y eso se consigue, entre otros factores, con un equipo implicado, motivado y con energía.

La productividad pasa por ser efectivo y no por echar más horas. Los que nos dedicamos al mundo del desarrollo de software sabemos que en diferentes ocasiones tenemos que echar horas de más para completar determinadas tareas, sin entrar a analizar si es algo que se debe admitir o no, sabemos que en ocasiones es necesario y la mayoría lo tenemos asumido.

También sería de interés que los responsables de las organizaciones lo tuvieran asumido y reconociesen ese esfuerzo de alguna manera y no hablo de palmaditas en la espalda. Ahora bien, si el sobreesfuerzo es consecuencia de haber dejado las cosas para última hora o por no haber hecho un buen trabajo, no se debe esperar, por lógica y por justicia para el resto de tus compañeros que encima te recompensen.

Sin embargo, echar más horas puede ser efectivo a corto plazo pero perjudicial a medio y largo plazo, sobre todo si esas horas de más se convierten en interminables jornadas que abarcan prácticamente todos los días de la semana. No somos robots, no somos máquinas, más pronto que tarde notaremos física e intelectualmente ese agotamiento y el resultado de nuestro trabajo será un reflejo de ello. Por ese motivo es fundamental saber repartir los esfuerzos y dejar las heroicidades para los superhéroes ya que esa no es nuestra misión.

La competitividad no pasa por malvender proyectos a costa de las personas que después tienen que realizarlos y/o a costa de las satisfacción final del usuario, sino pasa por ser efectivo, ahí es donde se marca la diferencia porque lo otro es capaz de hacerlo cualquiera y, además, suele tener, a la larga, efectos negativos.

He comentado muchas veces que tener nuestra atención repartida en múltiples proyectos termina siendo contraproducente para los proyectos, porque no se les dedica ni el tiempo ni la energía que necesitan, y para nosotros mismos que terminamos desgastados y frustrados al ser conscientes de que independientemente de nuestros aciertos y errores, los resultados podrían haber sido mejores si hubiéramos estado más encima en el día a día.

Lo queramos o no, terminaremos cayendo en el overtime, no solo por el hecho de echar más horas, sino porque los problemas nos los llevamos a casa. Y conforme esta situación se extienda en el tiempo, menos será nuestra energía y productividad, a la par de que nos sentiremos menos motivados por el hecho de que parece que hemos caído en un bucle del que no podemos salir.

Quienes tienen responsabilidad de gestión tienen que tratar de determinar cuál es límite de cada persona, con el objeto no de llegar a él, sino de tratar que no se supere (son dos actitudes diferentes ante un mismo problema).

Yo he cometido el error y así lo atestigua más de un artículo en los primeros tiempos de este blog, de apoyar el hecho de que las tareas potenciales asignadas a una persona sean superiores al 100% para tratar de evitar situaciones en las cuales no hayan posibles tareas a asignar.

La realidad viene a demostrar que aunque esa situación se pueda dar, lo normal es que la carga se sitúe por encima de ese 100% y se caigan en los problemas indicados anteriormente.

Es fundamental que la carga de trabajo se adapte a nuestra capacidad, más allá de eso, los resultados no son buenos, de ahí que resulte fundamental la gestión del WIP (Work in progress).

Yamamoto Tsunetomo en el Hagakure dejó evidencia de lo importante que resulta adecuar la atención a nuestra capacidad: “Es necesario saber concentrarse en una sola cosa, todos los oficios deben ser realizados con concentración”.

Soy partidario de no retrasar las entregas que se fijan. Es cierto que no siempre he pensado he pensado así y tampoco os puedo asegurar que mañana no cambie de opinión ya que independientemente de que uno tenga un background el presente condiciona, y mucho.

Si no se va a llegar y el incremento de la capacidad del equipo no es suficiente o incluso empeora la situación, la solución pasa por renegociar con el Product Owner, con el área usuaria o el cliente (en general) el alcance de la entrega.

Esto no es fácil, nada fácil. El usuario lo querrá todo (y más allá) y por supuesto, en plazos, independientemente de todo lo que haya ocurrido desde que se inició el proyecto, incluso siendo consciente de que el retraso no es imputable al equipo de desarrollo.

Si el usuario no quiere reducir el alcance o no lo hace de manera suficiente sí que hay que plantear un retraso en la entrega. No creo en el overtime impuesto directa o indirectamente en los desarrolladores, sí creo en la responsabilidad de los mismos y en su capacidad de administrarse el tiempo (son muchos los desarrolladores que no funcionan bien así y como digo siempre, mejor trabajar con personas que se adaptan a tu forma de entender el trabajo), por ese motivo no puedo ser partidario de soluciones que supongan overtime. Sí es admisible un pico de trabajo, pero por supuesto compensado de alguna forma (siempre equivalente a los resultados y esfuerzo realizado) y no puede ser prolongado en el tiempo.

¿Qué tampoco puede haber retraso? No hemos nacido para hacer imposibles y mi recomendación es que si se sabe de manera cierta que no se va a llegar, se escale el problema. Mejor ahora que dar sorpresas desagradables más adelante.

Ahora bien, si existen posibilidades de llegar en plazos hay que intentarlo, advirtiendo siempre al Product Owner de lo ajustado que vamos a estar y levantando la mano en el momento en que veamos que no vamos a llegar. Si el Product Owner no ha sido flexible a la hora de acotar el alcance, tampoco debemos serlo nosotros a la hora de realizar cambios que supongan una desviación sensible de los objetivos.

Reconozco que eso es antiágil y anti todo lo que entiendo que debe ser el desarrollo de software pero no puedo borrar la realidad y el contexto del proyecto es ese. El contexto manda, se será ágil en lo que se pueda, pero esas son las condiciones, esas son las variables que manejamos.

Cuando el usuario quiera cambiar cosas deberá negociar y en esa negociación suelen quedar tocados tanto desarrolladores como usuarios, los primeros porque el esfuerzo a realizar tras el cambio será mayor, ya que el cumplimiento de la agenda recaerá sobre sus espaldas y los segundos porque no podrán llevar al producto todos los cambios que entienden que son necesarios (el valor del producto está fuertemente limitado por el valor teórico del producto en su especificación) y tendrán, probablemente, un producto de mayor deuda técnica (se descuidará la calidad del desarrollo como consecuencia de incrementar el ritmo de trabajo y del más que probable overtime que tengan dedicar) y con una peor ejecución funcional porque se habrá dedicado menos tiempo (si es que se ha dedicado alguno) a la detección y corrección de incidencias y deficiencias funcionales.

Pero, ¿dónde comienza la gestión de agenda?, ¿antes o después de tener el catálogo de requisitos?. La respuesta natural a la pregunta es que poca agenda puedes gestionar si no sabes lo que vas a hacer y en base a ellos se ha definido un presupuesto y unos plazos equilibrados.

Sin embargo, nos encontramos con dos escenarios:

1) Definición de agenda, una vez definido el alcance inicial del proyecto.

2) Definición de agenda, sin tener una versión inicial del catálogo de requisitos y por tanto, con una estimación del presupuesto y plazos un tanto irreal.

El primer escenario es en el que realmente tendría sentido la gestión de la agenda ya que se da por conocido el sistema que hay que desarrollar y para ello se ha dedicado un presupuesto y previsto unos plazos. Sin embargo, al final, el problema sigue siendo el mismo, porque cuándo surjan modificaciones en los requisitos tocará negociar para mantener la agenda y en caso de desacuerdo el perjudicado en primera instancia será el producto final, en segunda instancia todo el resto de implicados.

En el artículo de mañana analizaremos el segundo escenario que, por desgracia, suele ser el más habitual.