archivo

Archivo de la etiqueta: presión

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 presión permite alcanzar y mantener la concentración durante un tiempo, pero más pronto que tarde termina desgastando de tal manera que la curva de rendimiento de la persona o del equipo termina bajando de manera considerable, así como la efectividad de los trabajos, que tendrán por termino medio, un mayor número de errores.

Cuando estudiábamos, esos días previos al examen eran muchos más productivos que los anteriores, y esto era así mientras nos quedasen fuerzas, una vez superada nuestra capacidad de aguante, más nos valía haber estudiado lo suficiente con anterioridad.

Como la presión, siempre y cuando no se venga de un período continuado de la misma y no sea desmedida, consigue resultados, tiende a ser considerada como una vitamina por parte de los gestores y la empiezan a aplicar no cuando puede ser necesario, sino prácticamente en cualquier circunstancia, perdiendo ese efecto cortoplacista que puede obtener objetivos y convirtiéndolo en un problema, porque no olvidemos que trabajamos con personas y que éstas no son un pozo sin fondo, capaces de estar siempre por encima del 100% y con miedo o temor a lo que pueda pasar si no se cumplen los objetivos.

Como en todo, hay momentos y momentos. Momentos en los que hay que darlo todo para sacar un proyecto adelante y también debe haber momentos en los que la carga de trabajo se compense. Un compañero mío utiliza una analogía muy acertada con los barbechos en la agricultura.

La falta de tensión no es buena, tampoco el exceso de presión. La presión en un momento dado puede ayudar a mantener o recuperar el enfoque en el proyecto, incluso a dar ese 110% que puede ser necesario, siempre y cuando sea durante un período de tiempo soportable.

Pero más allá de eso, es nefasta. También lo es en períodos cortos cuando se trata de conseguir un sobreesfuerzo que está por encima de la capacidad de los desarrolladores y/o del problema en cuestión que existe en ese momento.

Yo también he dicho más de un vez que bajo presión funciono mejor, pero no es así realmente. Bajo presión estás más concentrado y tienes tus sentidos dedicados al objetivo, pero eso es así porque es una presión controlada, no te obligas o no te obligan más allá las de lo que puedes admitir, en el momento en que te exiges o te exigen más, empieza el bloqueo, los nervios y las contramedidas para quitarte de encima esa presión que pasa por tratar de terminar cuanto antes y como sea, con la consiguiente merma de calidad del producto final.

Resulta complicado no trasladar presión a tu equipo si a su vez estás sometido a una gran presión. Es importante que ellos vean y sientan lo que está en juego pero no ir más allá. Tener la capacidad de absorber esa presión y no saturar con ella al equipo es una gran virtud y en contraprestación conseguirás mejores resultados gracias a un trabajo más productivo.

La siguiente cita de Tom DeMarco me ha hecho reflexionar: “La razón real para el uso de la presión y trabajar más horas puede que sea para que cada uno se sienta mejor cuando el proyecto está fallando”.

Puede que una razón sea esa pero ni mucho menos es lo que ocurre en todos los casos en los que se trabaja bajo presión o hay overtime incluso en períodos largos de tiempo (sobre todo en Death March Projects).

¿Por qué me ha hecho reflexionar? Pues porque cuando todo va mal un mecanismo de autodefensa que se suele utilizar es precisamente dar la apariencia de cumplir: “el proyecto va mal, pero no será por mi porque no paro de echar horas al proyecto”.

¿Dónde está la frontera entre la apariencia de cumplir y la necesidad real de un proyecto?

Es complicado, lo mismo estás echando más horas al proyecto no por el mero hecho cumplir sino porque tienes alguna motivación para hacerlo pero, ¿cuándo deja ser una motivación real y pasa a ser otra cosa? A veces será fácil diferenciar una cosa de la otra, en otras ocasiones la frontera será más difusa.

Mantener software es complejo: es más difícil leer código que escribirlo, por regla general la situación de partida tendrá una elevada deuda técnica, te tienes que buscar la vida para entender el funcionamiento del sistema y para comprender determinadas decisiones de diseño, estás sometido a restricciones tecnológicas y presupuestarias, trabajas con gente que estará impaciente (por decirlo suavemente) porque tiene problemas, como consecuencia tendrás presión tanto del cliente como de tu propia organización…

Este tipo de situaciones curte, la experiencia y bagaje que se gana es superior a la media de los desarrollos que se realizan desde cero, por eso considero que la participación en el mantenimiento de sistemas de información es una fase por la que debemos pasar todos los que nos dedicamos a esta profesión porque se ve todo desde otra perspectiva.

Es cierto también que hay mantenimientos donde el ritmo es distinto, generalmente se trata de proyectos de larga duración sobre un único sistema o sobre una constelación de sistemas orientados a un mismo fin, bien dotados presupuestariamente, que no suelen tener problemas de gran calado (lo que se hace es contratar básicamente su continuidad) y, en consecuencia sin tanta presión. Como es lógico, este tipo de trabajos (generalizando) curte menos aparte de por el contexto, por el hecho de que generalmente se tiende a tirar por el camino más corto: parchear.

Volviendo a una visión más general de los mantenimientos, queramos o no, como decía en otro artículo, tendremos que pasar por esto teniendo en cuenta el contexto económico actual y también el sentido común ya que el ciclo de vida de los sistemas no puede ser tan efímero como viene sucediendo como consecuencia de malas ejecuciones de los trabajos, independientemente de que la causa sea provocada por el desarrollador, por los usuarios o por ambos, y/o por no pensar las cosas dos veces antes de encargar el desarrollo de un sistema (¿existen problemas organizativos que haya que solucionar antes de empezar un desarrollo?, ¿existe una estabilidad o visos de estabilidad en el proceso o procesos que vamos a informatizar?).

Por tanto eludir proyectos de mantenimiento se convertirá en algo cada vez más complicado y si se evitan habrá que analizar si el que lo hace está cambiando un beneficio a corto plazo por otro más a largo plazo y persistente (una experiencia que le hará mejor profesional).

Vamos a ponerle un contexto (en el que se pueden producir algunas o todas de las siguientes situaciones):

– Proyectos de larga duración en la que se somete al equipo de personas que trabajan en él a una gran presión y en el que de manera habitual se produce overtime.

– El equipo de proyecto mantiene una cierta estabilidad (poca rotación).

– El equipo de proyecto se aisla en una sala de la organización, en un edificio independiente o en la sede del cliente (en ocasiones y por largas temporadas, incluso fuera de la localidad habitual de trabajo de la mayoría de los miembros del equipo).

En este tipo de contextos, salvo en aquellas situaciones en las que existe una división en el seno del equipo, se crea un vínculo fuerte entre la mayor parte de las personas que pertenecen a él. Se sabe que se está en un marrón y que todos colaboran para sacarlo adelante o el proyecto terminará por devorarles.

Este vínculo, hace que la relación entre las personas se extiende habitualmente fuera de la jornada laboral.

Ahí es donde surge este antipatrón, cuando en esos encuentros fuera del trabajo y con mucho alcohol consumido, se tratan aspectos del proyecto (de su gestión, de su desarrollo, del cliente, de los jefes, etc…) que terminan por crear una tendencia en el trabajo habitual:

– Reforzar la situación de aislamiento (nosotros contra todo el mundo).

– El enfoque adecuado del proyecto es el que podemos darle nosotros y no el que nos venga impuesto por el cliente o por nuestros superiores.

Desde mi punto de vista no tiene por qué haber necesariamente una causa/efecto entre hablar de aspectos laborales con muchas copas de balón (o vasos de tubo) por delante y lo que acabo de describir, incluso en el contexto inicialmente descrito. Se trata de un antipatrón sobre el que había leído y lo mejor es que cada uno saque sus propias conclusiones.

En este caso nos encontramos con que resulta muy complicado adquirir un ritmo de trabajo aceptable ya que estaremos condicionados a la visión cortoplacista de estar continuamente apagando fuegos o atendiendo a caprichos que desvían el enfoque de nuestro trabajo a otras tareas.

Estamos trabajando en nuestro proyecto cuando de pronto, nuestro superior, el superior del superior (o en general, a alguien que manda) necesita para ya, que hagamos una tarea, dentro o fuera del ámbito de nuestro proyecto y que rompe con nuestra planificación.

Es posible que en ocasiones exista una justificación, sin embargo el problema no es ese, el problema es que se cae en la dinámica de interrumpir periódicamente el núcleo central de trabajo de un equipo, sometiéndolo a picos de trabajo con alta presión, muy exigentes y que probablemente requieran overtime, de manera que a la pérdida de productividad por los cambios de contexto hay que sumar la propia del desgaste y cansancio.