archivo

Archivo de la etiqueta: problemas

Decía Albert Einstein que “una persona inteligente resuelve un problema. Una persona sabia lo evita”.

Evitar problemas requiere capacidad de análisis/lectura de la situación, de control sobre nosotros mismos, de anticipación y de adaptación.

Pese a eso los problemas llegarán porque siempre existirán factores que escapan a nosotros y porque no somos infalibles. La diferencia se encuentra en evitar la mayor parte de aquellos (o mitigarlos en lo posible) en los cuales y de alguna manera podamos influir (y prever). Esa diferencia permite enfocar mejor nuestros esfuerzos y tener una mayor capacidad de respuesta ante los problemas que vayan surgiendo.

A veces, como decía antes, se tratará de no haber realizado una buena lectura del presente y de lo que se avecina pero otras muchas, tal vez la mayoría, son provocadas por nuestras propias emociones, que nos hacen tratar de correr más rápido de lo que deberíamos, de verlo todo más fácil (o difícil) de lo que es o de dejarnos llevar más por los sentimientos y las sensaciones que por criterios que pueden resultar más objetivos o apropiados.

Somos seres emocionales por eso tenemos una capacidad innata de generar (y generarnos) problemas. No se trata de renunciar a nuestra esencia sino de entenderla, eso sí, supone un largo camino porque parece que es más fácil entender a los demás que a nosotros mismos.

Cuando un proyecto entra en una espiral en la que el equipo de proyecto tiene que enfrentarse continuamente a una horda de problemas que dificulta, sin duda, su avance y el cumplimiento en los compromisos en las diferentes iteraciones es que algo se ha hecho mal o que la situación de partida no era buena o, tal vez, ambas cosas.

También es cierto que si el equipo no se deja vencer por esta situación, va respondiendo, va ganando la batalla aunque parezca que nunca termina y se cumplen buena parte de los compromisos, es que algo se está haciendo bien.

La verdadera naturaleza de un equipo de proyecto, como en la vida, sale en los momentos malos, ahí es donde no solo vale la capacidad técnica o los conocimientos, sino la intención y las ganas de luchar por tratar de cumplir unos objetivos. Cuando el desgaste, la presión y los nervios te van haciendo más pequeño, solo te quedan dos opciones, dejarte vencer o tratar de enfrentarte a la situación, ahí es donde te haces grande y en donde demostrarás que no solo puedes ganar cuando el viento sopla a favor.

Si los problemas no dejan de aparecer, llegado el momento adecuado (porque una solución aplicada en mal momento por muy buena intención que lleve, puede empeorarlo), es necesario actuar.

Muchos de esos problemas (más de lo que se piensan) son el resultado de someter a los equipos a una carga de trabajo superior a la que pueden admitir, lo que provoca que cualquier contingencia se convierta prácticamente en un obstáculo insalvable. Si a eso le sumamos otros riesgos como un entorno tecnológico inestable, un código con mala deuda técnica, la participación de diferentes equipos que tienen que sincronizar desarrollos, etc…, la aparición de problemas, uno tras otro, será inevitable, mientras pasan los días y es necesario cumplir lo pactado.

Hablo de solución y debería hacerlo en plural porque generalmente e independientemente de que haya algún problema principal hay otros secundarios que por si mismos o por alimentar a terceros, también deben ser tratados.

Si nos limitamos exclusivamente a resolver las incidencias y deficiencias que nos reportan los usuarios, la mejora del sistema de información será muy lenta y eso en determinados contextos es igual a perder mucho dinero ante la falta de productividad del usuario ante la aplicación o por los fallos que tiene el sistema (bugs, mala interpretación de funcionalidades, inestabilidad, etc…).

No se trata de no tener en cuenta ese día a día que al fin y al cabo es la que permite dotar, junto a una buena atención a usuarios, de una continuidad al sistema, sino de, en paralelo, tratar de estudiar la problemática de fondo junto al usuario.

Por tanto, se trata de ejecutar acciones a corto plazo que permitan resolver los problemas del día a día del usuario junto acciones a medio plazo que mejoren el sistema en su conjunto y la experiencia y productividad del usuario.

Los proyectos de desarrollo de software, sobre todo aquellos de gran tamaño donde se tardan muchas iteraciones en tener una parte importante del mismo en funcionamiento o más todavía, aquellos que siguen un ciclo de vida en cascada, sufren importantes contingencias que pueden provocar que el mismo se vaya de las manos, por mucho empeño que se tenga y por mucho esfuerzo que se invierta.

¿Contingencias? Pues de todo.

Entre ellas es muy típico encontrarnos con el caso de algunas, como por ejemplo: funcionalidades mal definidas o implementadas, priorización deficiente de los desarrollos, procesos que antes eran de una forma, después son de otras y más tarde se vuelven a modificar, etc… que después nadie quiere hacerse responsable y todavía más si después nos encontramos con responsables funcionales que se van y luego vienen otros con otras ideas o enfoque y a los que le ha tocado continuar con los trabajos.

Al final, cuando los plazos se echan encima y/o el presupuesto empieza a agotarse, vienen las prisas y se empiezan a pedir responsabilidades generalmente al lado equivocado, el de los desarrolladores. Llegado a este punto, sobre todo si se piden explicaciones en niveles superiores de la jerarquía, llega la crisis.

¿Esto por qué no está?, ¡me he gastado tanto y no tengo resultados!, yo pensaba que esto estaba más avanzado y todavía le queda mucho, ¡lo necesito para ya!, y todo ese largo etcétera que estamos acostumbrados a escuchar.

Las crisis no se arreglan gritando o presionando más, sino que requieren un trabajo ordenado y el mismo empieza asumiendo cada parte que existe un problema y el papel que ha desempeñado en que se produzca. Eso realmente es lo más importante y difícil para solventar la crisis, reconocer que hay un problema y que se ha sido parte de él.

No se trata de hacer tábula rasa con lo que ha pasado. Quien se ha equivocado debe asumir las decisiones que ha tomado y el trabajo que ha realizado (o si no ha sido culpa directa suya, hacer como propias las decisiones de sus antecesores en su rol) y asumir las consecuencias de la misma. No obstante, eso es algo que cuando mejor corresponda al proyecto se deberá tener en cuenta.

Una vez que se reconoce el problema, se asumen decisiones y errores, ya queda el camino despejado y el esfuerzo liberado para comenzar a realizar las acciones necesarias para reconducir el proyecto, algo que por otra parte tampoco será fácil.

Muchas veces, cuando las cosas van mal, cuando existen problemas, se tiende a ocultar la información hacia los superiores (o a dar información que no es cierta, que es todavía peor).

Eso es un gran error, puede que alguna vez resuelvas el marrón y nadie se entere, pero si no lo consigues (y no siempre podrás porque en muchas ocasiones no dependerá de ti) y el problema llega hacia arriba, te enfrentas a una situación mucho más difícil, ya que te reprocharán, y con razón, de por qué no has informado y además el problema probablemente haya engordado.

Dentro de tus funciones se encuentra la resolución de contingencias pero también está dentro de tus responsabilidades informar a tus superiores cuando detectes que un problema puede ir a más porque ellos no pueden ni deben encontrarse por sorpresa y sin margen de reacción con el problema sobre la mesa.

Si se actúa con previsión, si se levanta la vista del suelo, es posible que la mayor parte de posibles problemas que puedan existir en una organización, en un departamento o en un proyecto, puedan ser atajados a tiempo o como mínimo ver minimizados su impacto.

Sin embargo, el miedo a tomar decisiones, un mal análisis de la situación presente y una mala previsión de la futura, una mala elección de prioridades, el inmovilismo, el hacer oídos sordos a quien conoce de primera mano un problema, son responsables de que un problema termine por materializarse y lo que es peor, que termine por explotar y tenga un impacto importante.

Paul Hawken es un emprendedor, consultor, autor, conferenciante y activista medioambiental americano. Su principal materia de trabajo y estudio es la sostenibilidad mediante el cambio en las relaciones entre los negocios y el medio ambiente.

Una cita significativa de Paul Kawken es la siguiente: “Una buena gestión es el arte de hacer los problemas tan interesantes y sus soluciones tan constructivas que todo el mundo quiera trabajar y tratar con ellas”.

Y no le falta razón, sobre todo teniendo en cuenta que en el día a día laboral si hay algo que suele estar presente son los problemas y si hay algo que puede afectar a una marcha correcta y fluida de un equipo de trabajo son aquellas problemas que no se tratan y gestionan de la manera adecuada.

Convertir los problemas en retos, las soluciones en oportunidades, deben ser una de las misiones del gestor, ya que de esta forma conseguirá mejorar la motivación y la productividad de los que intervienen en los mismos.

Los problemas van a seguir viniendo, pero la clave es el enfoque y el tratamiento que se les da. Si lo único que hace el gestor es despachar los problemas y no transformarlos en un trabajo interesante (no solo para el que los realiza, sino también para el que los solicita) o, al menos, en un trabajo normal (si no es posible hacer milagros), los resultados que se obtendrán con el mismo serán negativos, tanto en el corto plazo del mismo, como en el medio y largo plazo (por el desgaste de las personas que han intervenido en el mismo y también por los más que posibles malos resultados económicos que se hayan podido obtener).