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.

Yo he pecado en muchas ocasiones con este antipatrón. Lo reconozco.

Es el resultado de la presión que terceros te meten en el proyecto y/o la misma presión que se mete uno por intentar alcanzar los objetivos temporales marcados, aunque estos sean difíciles de conseguir.

A veces también son el resultado de la falta de confianza en el equipo de proyecto.

Este antipatrón consiste en solicitar estimaciones de avance del proyecto sin dar tiempo a que quien tiene que ofrecer la estimación realice un análisis medianamente objetivo de lo que se lleva realizado y de lo que se piensa que falta, todo ello teniendo en cuenta el contexto en el que hasta ahora se ha desarrollado el proyecto y el análisis de los riesgos actuales.

En más ocasiones de las que resultaría recomendable nos encontramos con proyectos que no llevan un ritmo constante, de pronto se va deprisa que poco después se produce un parón.

Esta falta de ritmo ocasionará retrasos, probablemente importantes, en la consecución de sus diferentes hitos.

Sin embargo, en la mayoría de ellos, llegará un momento donde alguien, relacionado directamente con el proyecto o desde fuera, pero con poder suficiente, que querrá los resultados para ya y, cuando eso sucede, empiezan las prisas.

Con esas prisas, se intentará en muchas ocasiones forzar la máquina mucho más de lo que es soportable: presión, plazos imposibles, overtime, etc… y esa aceleración no mejorará los resultados, tal vez se consiga sacar más trabajo, pero la calidad del los mismos probablemente será más que discutible y es que no resulta razonable que se intente sacar en X tiempo lo que en 4X no se ha podido.

Por mucho que trates de explicar esto, salvo que tus jefes o el responsable del cliente ocupe un nivel directivo en la organización, aquellas personas que ahora piden resultados no lo entenderán (o no lo querrán entender) y por supuesto cargarán toda la responsabilidad en el equipo de desarrollo por mucho que los parones no hayan sido provocados por ellos.

Acelerar no recupera el tiempo perdido porque hay límites que no se pueden superar (las tareas llevan su tiempo, el tiempo es optimizable, pero siempre existirán límites). La sensación de generar trabajo es solo eso, una sensación que puede tener ciertas notas de realidad cuando se liberan nuevas versiones del software, sin embargo, no se trata exclusivamente de sacar trabajo ya que es importante que los resultados sirvan y que no comprometan la capacidad de mantenimiento del producto, la disponibilidad del sistema y la experiencia de usuario.

Hay momentos de crisis en los proyectos y cuando se trabaja en varios simultáneamente, se pueden producir solapamientos de momentos críticos o bien que las soluciones conflictivas se sucedan.

Lo peor que puede pasar en estas situaciones es actuar perdiendo la calma, correr como un pollo sin cabeza (que es lo que da el nombre a este antipatrón).

Es cierto que, a veces, son tus superiores los que te hacen actuar así (ocurre en ellos, este antipatrón), pero en la medida de lo posible y en el margen que tengas tienes que intentar tomar las decisiones sin precipitarte e intentando mirar más allá de los fuegos que estás sofocando (claro que no es fácil, nadie dijo que lo fuera).

Cuanto mejor aguantes la presión, mejor gestor serás, porque además sabrás administrar cómo la presión le llega a las personas que trabajan contigo, estos deben ser conscientes de la situación, hacerse también responsables de la misma, pero no ahogarles en la presión, porque bajo la misma tal vez se consiga ejecutar más trabajo o hacer las cosas antes, pero lo más probable es que el resultado no sea bueno y se haya apagado un incendio para que después aparezcan dos o uno más grande.

Tras las crisis hay que seguir trabajando a buen ritmo y si en las mismas dejas tocado al equipo o dejas tocada tu relación con respecto al mismo, será complicado mantener la motivación y una buena comunicación con el equipo.