archivo

Archivo de la etiqueta: experiencia

Los procesos y herramientas son instrumentos que utilizados de manera adecuada pueden ayudarnos a conseguir los objetivos. El problema lo tenemos cuando se cree que los objetivos se consiguen, sobre todo, por su aplicación, lo que provoca que pasen a la categoría de fines en lugar de la de instrumentos: “si cumplo con los procesos y hago un buen uso de las herramientas que lo acompañan el proyecto saldrá bien”.

Si centras tu atención en el proceso pierdes tu enfoque en el producto y se tiende a ignorar el contexto. Todo ello por la idea de que la solución la proporciona el proceso y que eso está por encima de cualquier contingencia que se pueda producir.

Robert C. Martin realiza la siguiente reflexión: “El exceso de confianza en las herramientas y procedimientos y la falta de confianza en la inteligencia y en la experiencia son recetas para el desastre”.

A veces es la propia organización la que empuja a los desarrolladores a centrarse en el proceso, independientemente de la importancia que ellos piensen que pueda tener en el desarrollo de software. Cuando esto ocurre habrá personas que por comodidad y también por pragmatismo (hacia ellos y no hacia el proyecto y el producto) caigan en la cultura del cumplimiento: “yo he seguido los procesos de manera escrupulosa, ahí tienes todos los entregables, si el proyecto no ha salido bien no soy el responsable”.

Si el desarrollo de software fuera solo cuestión de procesos (ágiles o no) la mayoría de los proyectos no tendrían problemas y serían rentables tanto para clientes como para proveedores, ¿es esa la realidad?, se necesita algo más y eso lo ponen las personas que trabajan en ellos.

La experiencia es el resultado de enfrentarnos a situaciones y de obtener conocimiento a partir de las mismas mediante de un análisis lo más objetivo posible de lo que ha sucedido. De ahí saldrán una serie de hipótesis que iremos perfilando cuando tengamos la oportunidad.

Por tanto depende de las situaciones y no del tiempo. El tiempo (teóricamente) te puede hacer vivir más situaciones pero el peso que tiene cada una de ellas es diferente. Analizar a una persona exclusivamente por el tiempo trabajado es casi como medir el grado de avance de un programa basándonos en las líneas de código.

Por otro lado las situaciones por sí solas no te enseñan nada si no haces el esfuerzo necesario para aprender de ellas.

¿Por qué hacer retrospectivas? A veces es necesario pararse a analizar si las decisiones, estrategias y comportamientos que se han adoptado están produciendo los resultados esperados, así como para analizar qué problemáticas y riesgos tenemos en el proyecto con el objeto de establecer una serie de medidas que permitan la mejora continua.

La vorágine de los proyectos nos llevan a tener un ritmo frenético de manera que, a veces, pararnos a analizar qué está pasando, nos puede hacer pensar que estamos perdiendo el tiempo, cuando justamente es al contrario porque la pérdida de tiempo, de esfuerzo y de dinero se produce precisamente por continuar políticas, estrategias o prácticas que no producen buenos resultados.

Se trata por tanto de adquirir conocimiento a través de la experiencia y con la objetividad (y subjetividad) de los resultados que estamos obteniendo. Una idea que teóricamente es muy buena en la práctica no tiene por qué proporcionar los resultados esperados en el contexto en el que estamos trabajando y a partir de ahí, si tenemos capacidad de autocrítica y de asumir nuestros errores, llegaremos a varias conclusiones interesantes: tener siempre en cuenta el contexto a la hora de tomar una decisión y de adoptar una determinada estrategia, que la idea en cuestión puede seguir siendo válida pero no resulta adecuada en estos momentos en el proyecto (y puede que también en otros proyectos con unas variables parecidas al nuestro) y, que por tanto, es necesario buscar otras soluciones.

Decía Voltaire que: “Hay alguien tan inteligente que aprende de la experiencia de los demás”.

Aprendemos de nuestra experiencia, siendo el grado de aprendizaje proporcional no al tiempo, sino a la propia experiencia, al contexto en el que se ha desarrollado, a lo implicado que hayamos estado, a nuestra capacidad de observación, de escuchar a los demás y a la capacidad de analizar nuestros propios errores.

Pensar que siempre se tiene la razón o que nuestra opinión pesa más que ninguna, lo único que hace es limitarnos porque no debemos olvidar que hay una diferencia entre ser tu quién tiene que tomar la decisión y ser tu quién tiene que tener siempre la fórmula mágica que resuelve cualquier problema.

Cada persona puede aportar, lo único que hay que hacer es darles la oportunidad y no cerrarnos en prejuicios de si tiene más o menos experiencia, de si creo tener de base más conocimiento, de si su formación ha sido una u otra o si se encuentra o no dentro de nuestro círculo de confianza.

Hay muchos gestores de proyectos que asignan tareas (cuando no proyectos completos) a personas que en esos momentos no reúnen la capacitación necesaria para llevarlas a cabo. A veces esas personas se sobreponen a la adversidad y son capaces de sacar dignamente el trabajo adelante, pero por regla general no será así.

Si un proyecto de desarrollo de software tiene incertidumbre de manera inherente, estamos añadiendo todavía más riesgos al mismo ya que estamos asignado tareas y responsabilidades a personas que a día de hoy no tienen los conocimientos y experiencia necesarios para enfrentarse a ellas.

Esto ha hecho mucho daño al desarrollo de software presentando a personas como “el experto en…” (sin serlo) y después abandonándolas a su suerte en el proyecto.

Lo peor de todo es que cuando los gestores hacen esa asignación son conscientes de lo que están haciendo y de las consecuencias que eso traerá consigo. Al final echarán las culpas a los técnicos cuando el principal culpable es, sin dudas, el gestor. Quiero aclarar que a veces el gestor también será una víctima, cuando se le encarga un proyecto en el que no se le da margen de maniobra en la elección del personal.

El problema parte de la base de ignorar que se trabaja con personas, no con robots (o ganado), y que cada una de ellas tiene su singularidad y unas circunstancias que hacen que su rendimiento sea más efectivo en unas tareas que en otras, teniendo en cuenta, además, que van evolucionando de manera que con el paso del tiempo pueden realizar tareas más complejas o de más responsabilidad, haberse especializado en áreas concretas, etc…

También es necesario tener en cuenta cómo funciona esa persona en equipo y en qué tipos de equipos pueden rendir mejor.

Obtener el mayor rendimiento de cada persona implica conocerla bien y eso requiere trabajar con ella de cerca durante el tiempo suficiente, eso requiere que el gestor de proyectos se implique y no vea los trabajos desde la distancia (cosa que ocurre demasiado a menudo, en unos casos por tener una cartera de proyectos importante y en otros casos porque es más cómodo estar fuera de la línea de fuego).

Hay una reflexión del actor y cómico americano Steven Wright que me parece muy interesante: “La experiencia es algo que no se consigue hasta justo después de que lo necesitas”.

Y es que siempre llega tarde a la primera cita, aunque tal vez, lo más importante es que a partir de entonces siempre llegue a tiempo. Para eso es fundamental haber extraído conocimiento de la situación y eso solo se consigue con mentalidad abierta y capacidad para reconocer que las cosas se podrían haber hecho mejor, incluso en aquellos casos donde se hayan hecho bien.

La experiencia no es acumulación de años, sino como su propio nombre indica, de experiencias, de circunstancias. Por tanto no es lineal con el tiempo y sí con la intensidad y características de las situaciones que te has encontrado.

Y sobre todo es importante tener presente que por mucho que pienses que ya has pasado por todo, te seguirás encontrando con momentos en donde mires tu reloj y veas que la experiencia vuelve a llegar tarde.

Una última reflexión, si la experiencia se alcanza al enfrentarnos con el problema y analizar los resultados, y la trasladamos al desarrollo de software, ¿es el camino los enfoques predictivos o clásicos o resultan más adecuados los enfoques iterativos incrementales?.

Leonardo realizó la siguiente reflexión: “La sabiduría es la hija de la experiencia”.

Estoy totalmente de acuerdo. El conocimiento se tiene que confrontar con la realidad, con la experiencia. Antes de eso solo es teoría.

¿Acaso pensamos lo mismo del desarrollo de software ahora que cuándo estábamos en nuestro período de formación?.

Lo que sabemos es el resultado de la experiencia y, por tanto, conforme vamos avanzando en nuevos trabajos, nuevos proyectos, nuevos retos, vamos incrementamos lo que sabemos como consecuencia de esos nuevos contextos en los que hemos aplicado nuestros conocimientos.

La experiencia no es lineal con el tiempo, el tiempo por sí mismo no genera experiencia, depende de lo que nosotros hagamos en ese tiempo, por ese motivo la experiencia no debe ser medida en años sino que debe ser contrastada con las actividades realizadas en los mismos.