archivo

Archivo de la etiqueta: Séneca

Decía Séneca que: “Escucha aún a los pequeños, porque nada es despreciable en ellos”.

Me encuentro en muchas ocasiones donde no existe diálogo entre los diferentes niveles de una organización. Solo se escucha (si es que se escucha) al estrato inmediatamente inferior, confiando ciegamente en que la información que éstos transmiten es la correcta.

Eso supone un riesgo importante porque aunque no lo haga con mala intención es muy posible que su conocimiento real de lo que pasa por debajo suya no sea bueno. ¿Qué es su trabajo conocerlo? Sí, pero para llegar al detalle no te puedes quedar solo con lo que ves en primera línea, también hay que mancharse las manos y bajar a las trincheras.

Os puedo asegurar que en las trincheras se ven las cosas de otra manera y quienes están allí tienen opiniones muy valiosas que por lo menos deben ser escuchadas y analizadas. Si no lo haces te estás perdiendo una fuente de información muy importante para la toma de decisiones.

Decía Séneca: “Trata a tu inferior como quieras ser tratado por tu superior”. ¡Cuánta razón!. Para empezar porque todo da muchas vueltas y mañana quién está a tu cargo puede ser tu jefe.

Esa persona se equivocaría si aplica contigo la misma filosofía que aplicaste con él, es decir, si trata de “vengarse” una vez que sea tu jefe porque no haría más que proseguir el error que empezaste y eso no produce nada positivo. Ahora bien, lo más probable es que se deje llevar por las sensaciones que le provocaste, es un error, pero es humano equivocarse en eso, sobre todo si aún no ha descubierto que de nada vale aplicar contigo tus propios métodos.

Pero por encima de eso hay que tener en cuenta que no se puede ser impermeable hacia tu equipo y totalmente permeable hacia arriba. Es lo fácil pero este atajo se convertirá en un camino mucho más largo si tu equipo no está contigo y no lo estará si entiende que no estás con ellos.

También tratar a las personas como personas y no como recursos es una actitud positiva que produce buenos resultados porque todos nos sentimos más integrados cuando se nos trata de esa forma. La distancia crea distancia, los impersonal crea distancia y la distancia separa a las personas de sus jefes y organización.

Los proyectos de desarrollo de software se ejecutan en un contexto de incertidumbre. Hay muchísimas variables que pueden influir en el resultado final, tantas que resulta prácticamente imposible controlarlas todas.

El éxito no depende de tirar una moneda al aire, no quiero decir eso, para conseguirlo se requiere haber colaborado con tu trabajo, tus conocimientos y tu experiencia (así como la de todas las personas que participan en él), saber reponerte cuando las cosas van mal y no dejarte ir si se van consiguiendo los diferentes hitos que se van marcando.

Trabajar en esta profesión requiere tener conciencia en que todos los proyectos no van a salir bien y que no existe un martillo de oro que asegure nada. Un éxito no te asegura otro éxito y un fracaso tampoco te asegura otro. Siempre hay que evaluar los contextos en que se dieron cada uno.

Trabajar en esta profesión supone asumir que, a veces, vas a fracasar. Y muy probablemente adquieras mucho conocimiento porque poca cosas ayudan más a evolucionar que darte cuenta de cuáles han sido tus propios errores. Pero eso no viene solo, requiere que asumas tus errores y eso no es fácil, ya que la primera reacción suele ser mirar a todos lados menos a ti mismo.

Y, a veces, vas a tener éxito y tenerlo puede provocar el efecto contrario al fracaso asumido y aprovechado, porque si crees que has descubierto una receta mágica y que ya lo sabes todo, lo más probable es que termines involucionando porque en este caso te centras en mirar lo guapo que eres y no miras a tu alrededor.

Para esto, Séneca tenía la siguiente reflexión: “Una persona inteligente se repone pronto de un fracaso. Un mediocre jamás se recupera de un éxito”

Comentaba Séneca que: “Un barco que parecería grande en el río, sería muy pequeño en plena mar”.

Si te encuentras muy adaptado a un contexto es probable que tengas éxito en él porque te sabrás manejar mucho mejor que otros o que gran parte de tu competencia.

Pero todos sabemos, que los contextos varían tarde o temprano y que cuando tu mercado se encuentra con otras soluciones o ideas y/o su situación económica ha cambiado, se abre a un nuevo entorno, en el que otros tienen opciones y en el que se encontrarán más adaptados que tu organización o que tú, si no se ha sabido reaccionar a tiempo o simplemente no se ha querido reaccionar por considerar que la posición de partida era tan fuerte que la hacían inmune a cualquier cambio o movimiento que se pudiera producir.

Cuando se resquebraja la estructura y estrategias que tenías para un contexto que dominabas, es cuando descubres que efectivamente eras grande, dominante en él, y que ahora, en realidad, eres mucho más pequeño porque te has dado cuenta que en el horizonte tras tu isla, hay todo un océano.

Cuando se piensa de manera distinta sobre un tema, si no existe un espíritu por las partes implicadas de llegar a un acuerdo común, no se conseguirá y finalmente prevalecerá al opinión del más fuerte, de lo que esté pactado o documentado con anterioridad o de lo que contractualmente esté establecido, que lo mismo no es lo que más interesa en este preciso momento,

Cuanto más se defiendan una serie de argumentos, si las otras partes siguen sin ceder nada, se recurrirá a la hipérbole de los mismos, como medida de choque para tratar de conseguir lo que por otros medios no es posible, cumpliéndose lo que Séneca comentó en su momento: “Una discusión prolongada es un laberinto en el que la verdad siempre se pierde”.

En la gestión de proyectos software sucede con frecuencia este tipo de situaciones y si no hay intención de llegar a acuerdos, el primer damnificado será el proyecto. Es razonable defender las posiciones de tu organización o de tu equipo pero no olvidemos que si el proyecto sale mal, todos perdemos por mucho que se salga victorioso de batallas puntuales que solo servirán para separar a los equipos en lugar de unirlos.

Me estoy encontrando con algunos proyectos en donde el seguimiento de una determinada metodología o de un conjunto de prácticas se antepone a lo que realmente se necesita.

Sprints de dos o tres semanas por tratar de seguir las recomendaciones de Scrum, trabajando sin historias de usuario sólidas, sin tiempo para refinar la pila de producto y sin tener todavía una perspectiva del proyecto.

Después pasa lo que pasa y hay que escuchar los comentarios de siempre: “los desarrollos ágiles no mejoran nada, incluso lo empeoran”, “se ha perdido mucho dinero en proyectos desarrollados con Scrum”, etc…, sin entrar a valorar si realmente las prácticas aplicadas se adaptaban a lo que necesitaba el proyecto y si la actitud ha sido realmente ágil.

El feedback es la clave, todos lo sabemos, pero para sacar verdadero provecho es necesario que se trabaje con intención, es decir, con una cierta base, tirando a dar. Si hay que tirar todo lo desarrollador en el sprint (y parte del trabajo generado en otros previas), se tira, pero que no lo sea por probar sistemáticamente a ver qué pasa.

Ya lo decía Séneca: “A los que corren en un laberinto, su misma velocidad los confunde”.

Desde la distancia los grandes retos, los proyectos complicados, la competencia de organizaciones más poderosas casi siempre parece insalvable. Incluso cuando estamos inmersos en ellos sigue pesando la imagen que tenemos de ellos, de tal forma que supone una gran resistencia. Después cuando te das cuenta de que realmente puedes hacerle frente, lo mismo es demasiado tarde.

Decía Séneca que :”A algunos se les considera grandes porque también se cuenta el pedestal” y no olvidemos que ese pedestal es el que le ponemos nosotros, porque tendemos a hacer gigantes a los demás mientras, a la vez, nos vamos haciendo más pequeños.

No se trata de pensar que todo es fácil sino de no dar la batalla por perdida antes de empezar a librarla, mejor aprovechar tu tiempo y tu esfuerzo en tratar de que las condiciones de partida sean lo más satisfactorias posibles.

¿Qué después no se consiguen? La magia en el desarrollo de software no existe, hay mejores y peores desarrolladores, mejores o peores circunstancias, pero el proyecto no se hace solo. Una cosa es no sobreestimar nada y otra que no te den lo que necesitas para poder conseguir los objetivos, ahí si que toca pelear y si se consigue la victoria lo será a costa del buen hacer, del trabajo en equipo efectivo y de muchas, muchísimas horas de trabajo.