Las hechos perduran, las palabras no

Los hechos deben suceder a las palabras. Las palabras tienen caducidad si detrás de las mismas no hay hechos consecuentes con las mismas. El problema no es solo que las palabras dejen de tener valor sino que también lo pierde el que las pronuncia.

Las palabras son muy fáciles de ser pronunciadas o escritas, los hechos requieren el valor de la acción. Las palabras son solo teoría, los hechos son la práctica.

Esto no quiere decir que no podamos rectificar, al contrario, si nos hemos equivocado rectifiquemos cuanto antes, pero expliquemos antes por qué lo hemos hecho, después el tiempo dirá si la primera intención era la acertada o no, tal vez el tiempo también dicte si las sucesivas rectificaciones también lo eran.

No se trata tanto de acertar como de ser consecuente con el discurso y con los cambios que se hagan en el mismo. Acertar tiene su valor pero como persona, como gestor o como compañero pierdes valor si tu voz y tus actos siguen caminos divergentes.

Desarrollo de software. Kent Beck. El fracaso es el comienzo

El fracaso no es el fin sino que perfectamente se puede considerar, si se aprende de él, como el principio de todo.

Hay muchos que consideran que pensar de esta manera es de perdedores. Para mi es precisamente todo lo contrario. Tener presente que el error y el fracaso es parte de la vida y tener el coraje de levantarte tras la caída, es de ganadores.

Claro que hay ejemplos de personas que han alcanzado el éxito sin apenas mancharse las manos pero también los hay y muchos más que lo han logrado cimentándolo desde las cicatrices de los fracasos.

Me gusta mucho la siguiente cita de Kent Beck que refleja perfectamente este sentimiento: “Si tienes problemas para alcanzar el éxito, fracasa”.

Desarrollo de software. El otro compromiso

El otro compromiso, tal vez el más importante es el que tiene uno consigo mismo. Este compromiso varía en cada persona en función de su escala de valores.

En el ámbito laboral mi compromiso personal es sacar adelante de la mejor manera posible los proyectos en los que participo, eso no quiere decir que todos vayan a tener éxito sino que lo voy a intentar, que voy a tratar de poner lo mejor de mi, sea mucho o poco, para que el objetivo se cumpla.

Ese compromiso, está por encima de mi contexto laboral. ¿Eso quiere decir que me hago inmune a él? No y muchas veces afecta a mi rendimiento y me genera en demasiadas ocasiones frustración e ira, sin embargo, no recuerdo ninguna situación en la que haya terminando bajando los brazos, incluso cuando la consecución de los objetivos en el proyecto ya no eran posibles.

No soy mejor que tu por esto, quiero que lo tengas claro, es solo mi forma de entenderlo.

Mi compromiso está por encima de lo que puede ofrecerme mi organización porque me niego a estar limitado por la misma, sería un doble castigo, no sentirme valorado y autolimitarme como consecuencia de lo anterior. No obstante, respeto, muy mucho a quien decide que hasta aquí hemos llegado, siempre y cuando sea objetiva la falta de compensación entre lo que compromete la organización y lo que compromete la persona, si bien, y desde mi punto de vista, cuando eso ocurra, el camino no debería ser la autolimitación, sino la búsqueda de otras alternativas profesionales, ya que tu libertad para reducir tu nivel de compromiso debe mantenerse en equilibrio con tu entorno y no es justo que tus compañeros carguen con tus problemas.

Desarrollo de software. Jim Horning. Fracaso, error, experiencia, conocimiento, toma de decisiones

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

Desarrollo de software. Acción contra frustración

Cuando las cosas no salen o no van como uno quiere pese a que se pone todo el empeño posible crea frustración. También se produce ese estado y con frecuencia cuando tus tareas dependen de tantas personas que se eternizan y te impiden dar una respuesta rápida ante un problema.

La frustración paraliza, disminuye tu motivación y agota tu energía.

No tengo pastillas que curen la frustración, si las tuviera probablemente no tendría esa sensación tan a menudo. Lo único que he visto que funciona contra la frustración es la acción, actuar con el objetivo de ir venciendo esas barreras y esa resistencia que te impide conseguir tus objetivos.

Es posible que en esa lucha de la acción contra la frustración gane muchas batalla la segunda pero tenemos mucho que decir en esa guerra, que podremos perder, pero no sin luchar y no con los brazos caídos.

Desarrollo de software. Las cicatrices son un buen framework

¿No has participado nunca en un proyecto que haya fracasado?, ¿no has sentido que actuaciones o decisiones tuyas han contribuido a ese fracaso (aunque haya sido en una proporción pequeña)?, ¿no has conseguido darle la vuelta a un proyecto que estaba abocado al fracaso?, ¿nunca un error tuyo ha tenido consecuencias negativas sobre otros?.

Si la respuesta a todo es que no, es que hasta ahora has tenido mucha suerte o también puede darse el caso de que no quieras verte como responsable de nada de lo ocurrido (en este caso no habrás aprendido nada).

Si todavía no has participado en un fracaso será cuestión de tiempo que alguna de las respuestas a las preguntas del primer párrafo será afirmativa y si asumes tu responsabilidad y analizas tus errores serás un profesional mucho mejor.

No digo que sea una buena noticia un fracaso, no lo es, lo que quiero decir es que las posibilidades de fracasar están ahí y que no somos infalibles (nadie lo es). No por ignorar el fracaso lo vamos a evitar, lo que tenemos que hacer es entender que el éxito y el fracaso forman parte de nuestra actividad profesional (y en general de nuestra vida).

Desarrollo de software. Craig Barrett. Asumir riesgos

El que fuera CEO de Inter Craig Barret comentó poco tiempo después de asumir ese cargo que: “Vamos por una carretera a 150 millas por hora y sabemos que en algún lugar hay un muro de ladrillos, sin embargo lo peor que podemos hacer es parar demasiado pronto y dejar que alguien nos pueda adelantar”.

Para conseguir determinados objetivos hay que asumir riesgos, en ocasiones riesgos que pueden poner en juego la viabilidad de un proyecto o incluso de la viabilidad económica de una organización.

No siempre se está dispuesto a realizar esa apuesta, dar ese paso al frente, se vive bien en nuestra zona de seguridad y se tienen menos preocupaciones cuando los riesgos están controlados o su materialización produce unos daños asumibles y reparables.

Ahora bien, hay veces donde se te presentarán verdaderas oportunidades (en forma de posibles negocios, soluciones o productos), las cuales no están siempre están llamando a tu puerta y si la dejas pasar habrá otro que ocupe tu lugar, que te la arrebate, siempre habrá otro, no lo olvides.

Otras veces no será cuestión de oportunidad sino de supervivencia o se apuesta por una solución o por una estrategia concreta y ponemos nuestro máximo empeño por llevarla a cabo o veremos como la situación se convierte en irreversible.

En estos casos, quedarte quieto supone perder, tal vez asumiendo determinados riesgos perderás más si la cosa no sale bien, pero al final en una situación y en otra el resultado será el mismo.

Desarrollo de software. Pasado, ese pasado

En este negocio todos lo tenemos, cosas que hemos hecho de las cuales nos arrepentimos y proyectos que han fracasado. Realmente el problema no es equivocarse sino no aprender nada de ello.

Es cierto que a veces cuesta mirar atrás, sobre todo si dirigimos la mirada a lo que hemos hecho mal. Esto es así hasta que te das cuenta de que realmente no has hecho nada especial al resto, te has equivocado, como todo el mundo. Tu en unas cosas, otros en otras, pero el resultado es el mismo.

Para aprender de los errores hay que reconocer nuestra culpa en los mismos. Si pensamos que la culpa ha sido de otros o si hemos tenido mala suerte no se aprende nada porque no terminamos de reconocer que hemos hecho algo o muchas cosas mal.

En nuestra profesión convivimos con el error y con el fracaso, no somos infalibles, a veces tendremos más parte de culpa en un fracaso, otras veces menos, lo mismo sucederá con los éxitos.

Desarrollo de software. Antipatrón. Mil proyectos

Este antipatrón trata sobre no tener en cuenta los límites que tiene una persona, tanto si es otro el que no lo hace como si eres tu mismo.

No somos infalibles, no lo somos, no podemos con todo, no podemos.

Podemos optimizar al máximo nuestro trabajo, ser muy productivos, minimizar nuestros errores, poner todo el empeño posible por intentar llevar todo para adelante, pero pasado un umbral la realidad nos dejará en nuestro sitio, ya que una vez superado ese momento se hace tan pronunciada que nuestra productividad cae (cansancio, frustración), nuestros errores aumentan y donde todo parece escaparse de nuestras manos.

Podría pensarse que el estado ideal es aquel en el que nos encontremos lo más cerca posible de ese límite, sin superarlo, pero tampoco es así. Realmente lo ideal es estar cerca de ese límite cuando realmente es necesario estarlo, cuando realmente podemos optimizar el beneficio (un atleta que quiere competir por ganar una maratón tiene que estar al límite de su capacidad el día de la prueba, probablemente si está al límite un entrenamiento tras otro, falle cuando realmente lo necesite).

Ritmo constante, alcanzando el límite cuando las circunstancias lo requieran, ese es el objetivo.

Desarrollo de software. Nadie es lo suficientemente bueno como para dejar de escuchar

La prepotencia no te permite crecer, la humildad sí. La prepotencia te aísla, la humildad te une al grupo. La prepotencia es una muestra de debilidad, tras tu ego no hay nada, la humildad es un síntoma de fortaleza, tras tu ego está todo.

He tenido la oportunidad de conocer a muchísimos desarrolladores de diferentes organizaciones y perfiles y entre ellos a personas muy brillantes. Ahora bien, ninguno es infalible, ninguno lo sabe todo y ninguno es lo suficientemente bueno como para mirar a nadie por encima del hombro.

Cuando uno trabaja en equipo hay que escuchar a todos sus integrantes, a todos, incluso al que ha llegado hace dos días al proyecto. Todos pueden aportar una idea o hacerte reflexionar y mejorar tu planteamiento inicial a través de su confrontación con otro enfoque.

El conocimiento del conjunto es mayor que el individual, ese de por sí debería bastar para que la comunicación sea fluida en el equipo, si a eso le sumas que el personal que se siente integrado en un proyecto está más motivado y a que la comunicación es esencial en cualquier trabajo en equipo, debería ser más suficiente para que te plantees un cambio de actitud y sientas que el grupo, el equipo, hace más fuerte un proyecto, si efectivamente consigues que funcione como un grupo o un equipo, algo que no puedes lograr si te sientes por encima de él.