archivo

Archivo de la etiqueta: actitud

La escritora americana Madeleine L’Engle realizó la siguiente reflexión (traducción libre): “Nuestro talento por sí solo no vale nada, lo que cuenta es cómo lo utilizamos”.

Y es así, aptitud sin actitud es talento desaprovechado. De nada vale tener la capacidad de correr deprisa si no te quieres mover o correr deprisa sin tener ningún tipo de control y sin saber a dónde ir.

Además, en el mundo del desarrollo de software no se trabaja solo, por lo que tu aptitud se tiene que poner a servicio del colectivo con el objeto no solo de hacer que los demás trabajen mejor sino para que las aportaciones de tus compañeros te permitan conseguir mejores resultados.

Talentos individuales pueden conseguir grandes resultados, hay muchos ejemplos, pero todavía hay muchísimos más, sobre todo cuando centramos el enfoque en servicios de desarrollo de software, en los que el talento sin una orientación adecuada y sin un deseo de colaboración con el resto de personas que participan en el proyecto no consigue solventar los múltiples problemas de diversa índole que se presentan.

El talento es importante pero también lo es la capacidad de trabajo individual y en equipo, la capacidad de comunicación y la capacidad de poder discernir entre objetivos individuales y objetivos el colectivo, ambos compatibles pero que tiene cada uno su momento.

No lo da un cargo. No lo da una apariencia porque se construye día a día. Lo da una actitud.

El respeto se parece mucho a la confianza, si bien, es algo menos frágil. Para conseguir respeto necesitas tiempo, para perderlo mucho menos. También suelen ir de la mano ya que sueles respetar a quien confías y confiar en quien respetas.

El respeto tiene mucho que ver con la objetividad (también con la implicación), primero contigo mismo, ¿exiges a los demás lo que te exiges a ti?, ¿crees realmente que si las cosas no van bien no tiene nada que ver contigo?, ¿tratas con respeto a quiénes quieres que te respeten?, después con los demás, ¿creas situaciones de injusticia por dar un trato desigual a diferentes personas por la relación personal que mantienen contigo? (ten en cuenta que estamos hablando en el terreno profesional y no en el personal o familiar), ¿escuchas en la misma proporción que te escuchan?, ¿estás dispuesto a ir a las trincheras cuando hay problemas?…

El respeto no se compra, se gana, no se provoca, surge.

La responsabilidad y actitud (suelen ir de la mano) son dos ingredientes fundamentales para ser un buen desarrollador de software. Encuentra personas así y tendrás mucho ganado, ¿qué son técnicamente mejores o peores? Creedme, eso es secundario, esos conocimientos lo adquirirán con el tiempo pero la responsabilidad y actitud no son tan fáciles de aprender porque requieren un cambio en los esquemas mentales para aquellos que no la poseen y eso solo se consigue a través de un proceso de introspección personal que requiere bastante tiempo porque se trata de un cambio de percepción de lo que debe ser su día a día como profesional.

Como os suelo decir, no hay fórmulas mágicas, son dos virtudes importantes pero no dejan de ser dos variables más para hacerte un buen profesional y para asegurarte un equipo de personas que sabes que no te van a fallar, por lo que tampoco serán suficientes por sí mismas. Ahora bien e insistiendo en lo que indiqué en el primer párrafo, si no poseen esas cualidades, difícilmente vas a encontrar en esas personas lo que estás buscando que simplificando mucho son personas en las que puedes confiar en que van a tratar de hacer sus tareas de la mejor forma posible (independientemente de que a veces tengan mayor o menor éxito) y más si miramos sus resultados reales y comportamiento con más perspectiva, más a medio y largo plazo.

Me parece muy interesante la siguiente reflexión de Mike Beedle (traducción libre): “El coraje en Scrum no es algo visible o tangible. Tampoco es una especie de heroísmo romántico. En su lugar, consiste en tener el coraje y la determinación de hacerlo lo mejor que puedas. Es la obstinación de no darse por vencido y cumplir los compromisos. Este tipo de coraje es valiente, no glorioso”.

Beedle lo asocia a Scrum, sin embargo su cita me parece interesante porque refleja una actitud que va más allá de la utilización de una determinada estrategia de desarrollo de software y que desde mi punto de vista es absolutamente acertada: la actitud por intentar cumplir unos compromisos, por hacerlo lo mejor posible, de dar lo mejor de nosotros para conseguir esos objetivos.

Esto supone en primer lugar un compromiso con nuestro, con nuestro equipo y con nosotros mismos de lo contrario como mucho llegaremos a ser cumplidores (incluso con una cierta eficiencia) pero falta el empuje necesario para vencer determinadas resistencias que nos encontraremos en el proyecto y que requieren lo mejor de nosotros mismos, así como la capacidad de levantarse y recuperarse ante las dificultades que vayan surgiendo.

Como comenta Beedle no se trata de sacar la varita mágica y convertir en sencillo lo difícil sino de saber que nos encontramos ante un reto que exigirá lo mejor de nosotros mismos y que para superarlo requerirá mucho esfuerzo. ¿Qué después no es para tanto? Mejor, pero eso no quita que en el siguiente proyecto nos encontremos con mayores dificultades.

Limitarte en un rol puede llegar a ser cómodo, pero no es ágil. Tampoco es ágil ser en cada momento un comodín porque probablemente no termines de hacer de manera adecuada todas tus tareas ya que se puede ser un buen hombre orquesta pero es imposible tocar a la vez todos los instrumentos.

Es conveniente que los equipos ágiles estén formados por personas polivalentes pero teniendo en cuenta que si alguien es muy bueno en algo es conveniente que enfoque su esfuerzo en donde más provechoso puede ser su trabajo.

Conocer qué rol tiene cada uno es importante, encasillar a cada persona en su rol, un lastre. Para evitar eso es conveniente definir responsabilidades como elementos que trascienden al rol, de manera que personas con roles distintos podrían compartir determinadas responsabilidades.

Sin embargo para que esto funcione es fundamental la actitud de las personas ya que sin ella el rol tenderá a prevalecer sobre las responsabilidades porque siempre se podrá encontrar una buena excusa para ello.

Es cierto que es necesario medir bien qué responsabilidades se le asigna a cada persona, no vale todo porque eso va en contra de la persona, del equipo y del proyecto. Eso te obliga a conocer bien a todos los que participan en el proyecto, algo que no siempre se sabe al principio pero en donde hay que tener en cuenta que la asignación de responsabilidades tampoco tiene que realizarse al detalle o de manera completa al comienzo y que posteriormente se pueden realizar todos los ajustes que sean necesarios.

Agilidad es intensidad. Es una diferencia fundamental con otros enfoques o estrategias de desarrollo de software. La intensidad requiere proximidad (no necesariamente física), en la que los componentes de los equipos se vean entendidos, apoyados y respaldados.

No vale con dar cuatro directrices generales basadas en enfoques ágiles, seguir los trabajos desde lejos y después pedir responsabilidades o esperar resultados. Autogestión sí, por supuesto, microgestión no, también, pero sobre todo responsabilidad a la hora de gestionar proyectos y saber cuál es tu papel.

Si sigues metodologías, estrategias, enfoques o prácticas ágiles, no te debes quedar en la teoría o en hacer que tus equipos cumplan con ella, sino que debes entender cuál es el contexto del proyecto, para saber en cada momento qué es lo que más le conviene, y conocer los problemas del día a día. No se puede ser facilitador desde la distancia, no puedes hacer sugerencias, definir estrategias o pedir correcciones si no sabes qué es lo que está pasando. Tienes que comprometerte con el proyecto y con las personas que lo están sacando para adelante.

Si no actúas de esa forma serás una resistencia más que un apoyo y si quieres dar una visión agilista al proyecto, se quedará fundamentalmente en el aspecto metodológico (cuando la agilidad realmente es cuestión de actitud) y en lo que el equipo de trabajo tenga a bien sacar adelante por sus propios mérito y esfuerzo. Este antipatrón podría considerarse como un caso particular de una definición más genérica como es la de “falso agilista“.

No ayuda nada obviar el contexto en que se realiza el proyecto bien puede ser por falta de experiencia o por el contrario por pensar que se tiene la solución para derribar todas las puertas (martillo de oro) lo primero se cura con el tiempo (una vez que te recuperas de las caídas que has tenido y si realmente haces retrospección de tus actuaciones y decisiones) de lo segundo también, si bien, resulta algo más complicado ya que supone bajar de las nubes en la que estemos instalados… y es que se está tan bien allí arriba.

Jim McCarthy realizó la siguiente reflexión: “Decir que quieres algo implica que estás dispuesto a cambiar para conseguirlo. De lo contrario, realmente no lo quieres”.

Me parece interesante ya que representa el cambio de actitud necesario cuando con la actual no consigues nada (o incluso empeoras la situación) y por extensión la necesidad de adaptarte al cambio porque no siempre te va a caer todo en las manos (por mucho que pienses que sabes colocarte bien).