archivo

Archivo de la etiqueta: Lao-Tsé

Tener a tu equipo trabajando, recorriendo cientos de millas extras y pidiéndo esfuerzos cuando ya no quedan fuerzas, mientras no te involucras no es la mejor forma de que tu equipo crea en ti. Es más tu credibilidad se reducirá exponencialmente conforme tus actos se vayan alejando de tus palabras.

Que sí, que tu trabajo es uno y el de tu equipo puede ser otro. No se trata de roles, sino de implicación, de empatía y compromiso. Es cierto que esto requiere un esfuerzo extra para el gestor pero, ¿no es eso lo que pides en determinados momentos a tu equipo?.

Tu equipo no es una expendedora de servicios, son personas y tienen que sentirse arropadas. Si no lo están, solo quedará que entre ellos se autogestionen, algo que no es ni mucho menos malo, es más lo considero positivo, siempre y cuando tengan una visión que vaya más allá del día a día del proyecto, ya que pueden existir decisiones que requieran tener una visión de un mayor alcance y se les permita llevarlas a la práctica, algo que el gestor puede obstaculizar si lo interpreta como una intromisión en su trabajo en lugar de un apoyo.

Un equipo no se extralimita si existe un respeto entre los roles, existe un consenso entre los límites de cada parte y existe un diálogo fluido y confianza como para que todas las partes se escuchen entre sí.

La clave es que el gestor se sienta parte del equipo y el equipo lo sienta como parte integrante de él. Esto se gana, no se obtiene por tener unos simples galones.

Decía Lao-Tse que: “El sabio no enseña con palabras, sino con actos”.

Me parece muy interesante la siguiente cita de Lao-Tsé: “Un líder es mejor cuando la gente apenas sabe que existe. Cuando su trabajo esté hecho, su objetivo cumplido, ellos dirán: nosotros mismos lo hicimos”.

No se trata de que el líder se dedique exclusivamente a servir, no es eso, se trata de que un líder hace un trabajo y toma unas decisiones que no necesariamente tienen que ser visibles para tratar que el proyecto o los trabajos salgan hacia adelante.

Un líder no tiene por qué exhibirse. Quienes conocen al líder valorarán el trabajo que hace y poco a poco asimilarán esas prácticas y las harán suyas, a su modo, a su forma, pero con la inspiración que les ha hecho llegar una persona que se ha preocupado por hacer, por actuar y menos por hablar y aparentar.

En toda organización, en todo departamento hay líderes silenciosos, que son los que realmente hacen que la maquinaria ande. Ellos son más importantes que la marca o los procedimientos porque el resultado final es consecuencia de su trabajo.

Algo que deben mejorar muchísimas organizaciones es valorar como se merece a quienes hacen que las tareas salgan hacia adelante. Un líder lo puede ser cualquiera, aunque sea el que menos cobre, aunque sea quien desempeñe el rol de menor responsabilidad porque su actitud ante el trabajo servirá de inspiración a todos los que interactúan con él.

Lao-Tsé refleja en un par de citas, un aspecto esencial que tenemos que tener en cuenta a la hora de abordar un proyecto de desarrollo de software y en general para cualquier tarea de un cierto tamaño que queramos afrontar:

“Proyecta lo difícil partiendo de donde aún es fácil”.

“Realiza lo grande partiendo de donde aún es pequeño”.

Precisamente uno de los grandes problemas del ciclo de vida en clásico o en cascada es ese, construir un producto demasiado grande que después resulta complicado de reajustar.

Cuanto más grande sea, más dinero nos habremos gastado, por lo que menos disponibilidad presupuestaria tendremos para hacer modificaciones (a la par de la presión por amortizar la inversión) y la deuda técnica hará más costosas las modificaciones, y eso casi en el mejor de los casos, porque si hay que cambiar arquitectura o estrategias de diseño, los costes se disparan.

Si encima el producto cubre un proceso de negocio estratégico el impacto será aún más fuerte.

Precisamente quienes conocen este problema tratan de dividir el sistema en diferentes versiones, siguiendo un enfoque incremental. Eso es un primer paso para hacerlo también iterativo, en el sentido de que en cada versión se subsanen deficiencias de las anteriores, que no solo llegan a nivel correctivo, sino también perfectivo y evolutivo.

Se mejora de esta forma, pero si la duración de las iteraciones es demasiado prolongada, seguiremos teniendo en esencia el problema inicial, atenuado, pero seguirá ahí.

Por ese motivo, el siguiente paso es la realización de ciclos más cortos. Si son fijos o variables en tiempo, es otro tema de debate.

He leído una cita de Lao-Tsé que viene a sumarse a otras tantas que os he ido comentando en el blog y se basa en la necesidad de reaccionar si se va en la dirección equivocada.

“Si no cambias de dirección, puedes terminar a donde te estás dirigiendo”.

Ese problema ha dado lugar al fracaso de innumerables proyectos de desarrollo de software y el trasfondo real, en la mayoría de los casos es económico. Es decir, unos porque no están dispuestos a pagar más (y lo mismo tienen razón) y otros porque no están dispuestos a perder (más) dinero (y lo mismo también tienen razón).

Por tanto, se tira de contrato o se tira de requisitos y se trata de llegar a una solución que probablemente no sea satisfactoria porque ya se ha detectado que el sentido que ha tomado el proyecto no era el correcto. Parcheando y parcheando se tratará de conseguir algo. Lamentablemente ese algo en muchos casos será un fracaso que terminará costando más dinero que si se hubieran tomado las decisiones en el momento adecuado.

Es mejor reaccionar en el momento adecuado y tratar de buscar una solución real al problema, no una que se sabe de antemano que no va a llevar a ningún sitio.

La efectividad de la reacción será mayor cuanto más nos hayamos anticipado a la ocurrencia del problema, sin embargo, lo importante siempre será la intención de adaptarse al cambio, ya que de esa manera, podremos afrontar el trabajo que se requiere para poner todo en el camino correcto.

Los proyectos de desarrollo de software son un caldo de cultivo fantástico para estar permanentemente enfadado.

Saber gestionar esa sensación, ese sentimiento, así como tratar de que tu equipo se mantenga en equilibrio proporciona un ingrediente importante para que el proyecto se pueda llevar a cabo.

La ira es un combustible muy poderoso pero no podemos basar nuestro funcionamiento en base a ella. Puede ser motivante, pero también desgasta mucho y como toda elección que no guarda un equilibrio, al final puede resultar más negativa que positiva.

Lao-Tsé dijo: "El mejor guerrero nunca está enfadado". Conseguir eso puede resultar quimérico, pero sí que podemos tratar de controlarlo y encauzarlo de manera adecuada. Teniendo en cuenta que somos humanos y que no siempre podremos mantener la calma.

Es muy difícil que un proyecto salga bien con partes enfrentadas, ya sea entre stakeholders o dentro de un propio equipo de trabajo. Dado que los objetivos colectivos e individuales suelen ser diferentes (se encuentren o no enmarcados dentro de otros más generales determinados por la organización o el proyecto), las circunstancias que pueden provocar roces se multiplican.

Un gestor de proyectos debe tener esto presente y sin embargo es algo en los que muchos fallan.

Para tratar de obtener los mejores resultados posibles nuestra capacidad de empatizar con los demás, de entender su comportamiento, de conocer su forma de ser, de entender el contexto de la organización y/o del departamento puede marcar la diferencia. Determinadas reacciones pueden provocar enfado pero si se entiende el contexto, a la persona (porque el desarrollo de software es cosa de personas), la cosa puede cambiar.

Si algo no te gusta siempre te queda la posibilidad de dialogar, eligiendo para ello el momento más adecuado. Mi experiencia me dice que una solución dialogada suele ser más fructífera que una solución impuesta. Siendo cierto que para ello, las partes implicadas tienen que estar abiertas a escuchar.

Es difícil delegar. Resulta complicado tomar la decisión de perder control a cambio de que tu equipo sea más autónomo. Pero más complicado resulta que tu equipo crezca si lo tienes maniatado.

Tienes que definir líneas de actuación, establecer un marco, consensuar métodos de trabajo y tomar decisiones, pero también debes dejar que tu equipo aplique todo su potencial.

Proporcionarán puntos de vista diferentes que enriquecerán, las decisiones y actuaciones que se realicen en el proyecto, ¿qué crece el margen de error? Es posible, como es posible que no. En cualquier caso, sabemos que equivocarse es un paso necesario para adquirir experiencia. No se trata de poner en riesgo el proyecto, para eso estás tú, para tratar de detectar los fallos a tiempo o intentar que su impacto sea el menor posible, se trata de que tu equipo vaya ganando en conocimiento, en iniciativa y en entender de primera mano que no es tan fácil tomar decisiones.

Recordemos que un líder entre otras funciones debe crear el caldo de cultivo necesario para que aparezcan nuevos líderes que permitan repartir entre todos ellos, la carga y complejidad que tiene cualquier proyecto de desarrollo de software.

Ya lo dijo Lao-Tsé: “Gobierna mejor quien gobierna menos”.