archivo

Archivo de la etiqueta: experiencia

Podemos reflexionar sobre nuestros conocimientos y a partir de ahí generar más conocimiento pero siempre tendremos un límite y tendremos que recurrir a fuentes externas (otras personas o libros) para seguir progresando.

Y es que el conocimiento está ahí fuera y prácticamente me atrevería a decir que está en cualquier sitio. Las barreras las ponemos nosotros mismos cuando creemos que no es así y pensamos que pocas personas o pocas fuentes (en general) pueden aportarnos algo.

Gran error pensar así porque estamos perdiendo la oportunidad de confrontar nuestras ideas con el conocimiento y experiencia de terceras personas solo porque tienen un punto de vista diferente o porque entendemos que no tienen el nivel suficiente como para que digan algo interesante.

He aprendido mucho de personas con más conocimiento y experiencias que yo pero no más que con personas con menos conocimientos y experiencia.

Los puntos de vista diferentes desgastan cuando se comparten áreas de trabajo pero también nos permiten crecer porque es bueno que lo que creemos consolidado sea puesto en tela de juicio ya que nos da la oportunidad de conocer otros puntos de vista y corregir, matizar o mejorar los nuestros. En un contexto donde todo el mundo piensa igual se pierde diversidad y el grupo se hace más débil.

Robert I. Sutton es profesor de ciencia de la gestión y comportamiento organizativo en la Universidad de Stanford y autor de publicaciones sobre la materia.

Me parece muy interesante su siguiente cita sobre este tema: “Decir cosas inteligentes y dar respuestas inteligentes es importante. Aprender a escuchar a otros y hacer preguntas inteligentes es más importante”.

El desarrollo de software no es solo son procesos, metodologías, arquitecturas, programación, etc… hay algo más, mucho más importante que es la relación entre las personas que intervienen en el proyecto.

Si falla esa relación, esa comunicación entre las personas, esa búsqueda de un objetivo común, esa necesidad de trabajar juntos para alcanzarlo difícilmente va a funcionar todo lo demás por muy bien que se trabaje.

También está el bagaje profesional y personal, ese background que te ayuda a intentar tomar las mejores decisiones (aunque no siempre se acierte) incluso en contextos complicados y/o que no son conocidos por nosotros.

Si se trabaja como un equipo se tendrá la capacidad de integrar el background de todos, si no es así no es ya que no se aproveche ese talento y esa experiencia sino que esas diferentes visiones tenderán a convertirse en fuerzas que empujan en distinto sentido y provoca situaciones de bloqueo en el proyecto, desgaste, etc…

Ken Schwaber considera que no todo son procesos y metodologías, sino que hay algo más: “Una metodología te dice lo que tienes que hacer, un proceso es un framework que establece algunas restricciones. Una metodología no puede decirle a la gente que hacer cuando nunca han estado allí”. Es decir, tras la metodología quedan los desarrolladores (las metodologías son generalizaciones y no pueden tener en cuenta cada situación concreta de un proyecto) que son los que al final tienen que tomar las decisiones.

Conforme vayamos adquiriendo experiencia en el desarrollo de software tendremos una visión más amplia ante cualquier situación que nos encontremos en un proyecto, también de manera paradójica tendremos más asentadas unas prácticas o enfoques que limitan nuestro margen de maniobra independientemente de que esa visión nos muestre que existen otras posibilidades o alternativas.

¿Qué hacemos si la solución más adecuada parece que se encuentra fuera de los límites de nuestras buenas prácticas y/o enfoques?

Analizar si realmente es así. Si tenemos esas prácticas es por algo, son consecuencia de nuestra experiencia en diferentes proyectos y de todo el conocimiento que hemos adquirido hasta ahora.

Volverlo a analizar.

Si realmente fuéramos infalibles, no seríamos humanos, por ese motivo siempre se debe dejar una puerta abierta a otras alternativas. Llegado el punto de tomar una decisión que nos lleve a unas acciones fuera de nuestras prácticas o enfoques, si la situación nos obliga, tendremos que hacerlo (no todo vale, hay líneas rojas, pero no puedo hablaros de ellas ya que cada uno tendrá las suyas).

Si al final tenemos que salir de nuestro camino y optar por otras soluciones podrá pasar que hayamos acertado o nos hayamos equivocado, en ambos casos habremos ganado conocimiento y experiencia y lo mismo nuestras prácticas o enfoques se han consolidado todavía más o bien abarcan ahora un mayor abanico de posibilidades, en caso de habernos equivocado tendremos que afrontar las consecuencias (en cualquier caso, eso es inherente a cualquier profesión, tenemos que convivir con el éxito y con el fracaso).

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).

Las cicatrices son el framework más valioso en nuestra profesión es algo en lo que la mayoría estamos de acuerdo. Hasta que no terminas por llenarte de barro no aprendes la lección por mucho que te hayan intentado aconsejar antes.

Estamos tan convencidos de que vamos por el camino correcto que no prestamos atención a que todos los mapas indiquen que vamos en la dirección equivocada.

A veces incluso tenemos que caer varias veces en el mismo charco para terminar de darnos cuenta de que nos estamos mojando.

Pero el conocimiento se encuentra ahí, en descubrir qué hemos hecho mal y por qué, debiéndose analizar también el contexto en el que hemos actuado. No es posible realizar un buen análisis y obtener unas conclusiones adecuadas sin analizar en qué entorno o contexto hemos realizado nuestro trabajo, tal vez el problema no se encuentra en haber actuado de una determinada forma sino en haberlas puesto en práctica en un contexto que no era el adecuado.

Jim Horning tiene una cita que resume perfectamente el papel de la experiencia y de los fracasos en nuestro desarrollo personal y profesional: “El buen juicio proviene de la experiencia. La experiencia proviene del mal juicio”.

Todos nos encontramos en una fase contínua de aprendizaje, algo absolutamente necesario ya que el contexto en el que desarrollamos nuestro trabajo cambia: la economía no es la misma, los clientes y/o los proveedores cambian (entran unos, salen otros y los que quedan también evolucionan), el mercado cada día requiere una mayor competitividad, etc…

En todo el proceso de desarrollo de una solución, ya sea un producto propio o uno que se realiza para un tercero, se aprende, también se debe aprender del éxito pero mucho más del fracaso.

El éxito embriaga de tal manera que los errores que hayan existido en el proyecto (que seguro que los hay) se minimizan o se olvidan por eso resulta complicado aprovechar el éxito para seguir evolucionando, salvo que seas capaz de mantener una actitud crítica y eso solo se consigue admitiendo que el éxito y el fracaso se van a ir sucediendo en nuestra trayectoria profesional y que nuestro objetivo será maximizar los resultados en los proyectos que han ido bien y minimizar los efectos negativos en aquellos que vayan mal, de manera que el balance sea positivo.

El usuario final del producto es el que más sufre las consecuencias de un mal trabajo (nuestra organización podrá verse resentida económicamente como consecuencia de la pérdida de confianza del cliente o por el coste final que va a tener el proyecto) y es precisamente a partir de ellos donde debe comenzar el proceso de reconstrucción del producto (¿qué muchas veces el fracaso es consecuencia de la falta de colaboración del área usuaria? Buscar culpables es otra historia, una vez superada esa fase toca buscar soluciones).

Cuando analicemos con el cliente o con el usuario las deficiencias el producto, nos daremos cuenta de todo lo que se ha hecho mal (y no solo por nuestra parte). Cuanto mayor sea el fiasco del proyecto más a la luz saldrán las vergüenzas del mismo. En la mayoría de los casos será bastante doloroso verte dentro de un trabajo que ha resultado tan nefasto que incluso sentirás vergüenza.

Tendrás que soportar que buena parte del área usuaria desconfíe de ti y tendrás que aguantar a usuarios que se pasen del límite incluso cuando intentes dialogar con ellos de buena forma (el enfrentamiento directo no es la solución, si se llega a la falta de respeto, dependiendo de la circunstancia será recomendable ignorar a quien llega a ese límite o escalar ese comportamiento a quien corresponda).

Mantener una actitud crítica con lo que has hecho es la única forma de aprender. No aprenderás nada si consideras que la culpa nunca es tuya o que tus errores son más pequeños que los de los demás.

Bill Gates no ha sido ajeno al fracaso, precisamente por ello sabe muy bien lo que dice cuando comenta que: “Tus clientes más descontentos son tu mayor fuente de aprendizaje”.

El producto software que se obtiene finalmente es consecuencia de las directrices que ha indicado el área usuaria. Nos habrá dado unos requisitos, a lo largo del proyecto, habrá cambiado el enfoque de algunos de ellos, otros se desecharán y aparecerán algunos nuevos. Esto es independiente de la metodología utilizada.

Sin embargo el equipo de proyecto no debe ser una serie de ovejitas que van detrás de un partorcito (el usuario), ¿dónde está el valor que aporta el equipo al proyecto? Traducir especificaciones a un lenguaje de programación tiene su complejidad, sobre todo si se hace bien, pero, ¿solo somos traductores?, ¿no somos capaces de proponer alternativas al usuario?, ¿no somos capaces de hacerle vez que tal vez determinadas funcionalidades que solicita en términos coste/beneficio no son ventajosas?, ¿no somos capaces de aportar al cliente toda nuestra experiencia?.

Es muy fácil lavarse las manos y echar toda la culpa al cliente o al usuario (que la tendrán y en algunos proyectos mucha o casi toda) pero, ¿seguro que no somos responsables de nada?.