Rutina para cambiar

A veces cambiar es más difícil de lo que parece. Una y otra vez volvemos a caer en el comportamiento cotidiano.
Soy un jugador amateur de tenis y muchas veces me enfrento a rivales que tienen una técnica que considero inferior a la mía. Sin embargo, en muchos casos el resultado me es adverso.
Aprovecho los cambios de lado para mirar objetivamente qué debo cambiar. Algunas veces logro detectarlo, en otras no.
El principal ingrediente para lograr un cambio es encontrar qué es lo que se debe cambiar. Pensar solamente: "esto la estoy haciendo mal" no resuelve la situación. Es más, muchas veces pensarlo desde una óptica negativa es contraproducente (siempre es mucho más mejor enfocarse en lo que debe hacerse en lugar de lo que no).
Saber qué debemos cambiar no siempre es evidente. A veces requiere de pruebas y error para detectarlo. Otras es contraintuitivo. Sin embargo, una vez que lo sabemos gran parte del trabajo está hecho.
Empezamos a aplicar los cambios y percibimos los resultados. Acá es donde empieza la segunda parte del problema, que es en la que me quería enfocar: ¿cómo hacer para mantener el ritmo del cambio?
Vuelvo al tenis: Ya encontré lo que tengo que cambiar, lo estoy aplicando y veo los resultados, vuelvo a sentirme conforme con mi desempeño. Entonces me relajo y poco a poco dejo de prestarle atención al cambio.
Cuando me quiero dar cuenta, volví a caer en la conducta anterior, la que tengo por defecto y que quiero erradicar. Este punto a veces, especialmente en tenis, puede ser muy difícil de mantener. Es como si tuviese una superficie por donde fluyen las ideas, donde hay un surco grande y pronunciado: si no tengo cuidado, todas terminan cayendo ahí, no pudiendo escapar.
¿Cómo hago? Exagerar el cambio hasta volverlo costumbre. Repetirlo hasta en los casos en que no es necesario. Es acostumbrar a la cabeza al nuevo surco, pronunciarlo, volverlo el más relevante.

¿Para qué quiero tener razón?

¿Cuántas veces participamos en discusiones donde parece ser más importante tener razón que resolver los problemas?
Ejemplos:

• no te lo voy a repetir, ya te lo dije: ¿No sería más importante responder la pregunta y destrabar a la otra persona?
• sabía que esto iba a pasar: nada como predisponerse para el fracaso, esperarlo secretamente para tener razón…

Creo que siempre es más importante sumar, agregar valor. La razón no suma, si el producto no se entrega a tiempo, si el problema no se resuelve, tener razón es secundario, salvo para deslindar responsabilidades, que en definitiva, también es secundario. Ahora, si se llega a tiempo, si los problemas se resuelven, tener razón no tiene ninguna importancia. En cualquiera de los casos, tener razón no define el éxito de nuestros proyectos, solamente alimenta nuestro ego.

Un método básico para encontrar la razón de los problemas

Muchas veces, especialmente cuando escribo código, me encuentro con problemas que no puedo explicar, y por lo tanto, no puedo corregir.

Como todo el mundo, tengo mi propio método para abordarlos, porque muchas veces encontrar la razón puede consumir horas de frustración.

A continuación algunas de las ideas que aplico:

1. Puedo explicar por qué falla? Si la respuesta es afirmativa, ya no necesito continuar :)
2. Puedo repetir el problema u ocurre erraticamente. En el segundo caso, muy posiblemente se deba a problemas de hilos de ejecución, o datos externos, por ejemplo una base de datos que está siendo actualizada constantemente. Si es el primer caso, puedo continuar con la lista. Si es el segundo, tengo que poner logs por todos lados para capturar el problema la siguiente vez que ocurra.
3. Aislar el problema: si hay varios componente, intentar probarlos por separado para encontrar si el problema está en uno de ellos o en la interacción de dos o más (estos últimos suelen ser los más complejos de resolver)
4. Encontré el lugar donde está el problema, pero no puedo explicarlo. Es un problema que cabo de introducir ¿Funciona una versión anterior? ¿Funciona en otras circunstancias, como puede ser cambiando el navegador, versiones de componentes externos, parámetros de compilación: por ejemplo entre versiones de debugging y productivas?
5. Estoy asumiendo que algo en particular no es la causa del problema y la busco en otro lado? No hacerlo: demostrarme que no estoy equivocado probando eso que asumo que no falla pasa un test.
6. ¿Encontré la razón del problema? ¡Documentarlo! Ayudar a mi futuro yo a no tener que pasar por el mismo proceso exploratorio si me encuentro con el mismo problema dentro de un tiempo.

Oh vosotros los que entráis, abandonad toda esperanza

Esto es lo que reza la puerta del infierno en La Divina Comedia de Dante Alighieri.

Más allá de la poesía de la expresión, la frase encierra una sentencia terrible: perder toda esperanza.

¿Cuántas veces nos sentimos en una situación así, que ya nada puede hacerse, con una relación afectiva o con una profesional?

Asumir una postura así, no solamente nos predispone a sufrir, sino a que cada evento nuevo lo veamos como una oportunidad de confirmar nuestra sentencia.

Lo paradógico de todo esto, es que afirmar una cosa así, tan absoluta, nos va a "ayudar" a que se vuelva verdad. Es sabido que uno no ve a la realidad de forma objetiva, sino a través de unos ojos que están cargados de subjetividad e historia. Al margen de esto, está la tendencia del ser humano a buscar confirmar lo que pensamos. Esto es conocido como el sesgo de confirmación.

Ahora, qué pasa si lo vemos al revés: sino que en lugar de perder esperanza, no solo la tenemos, sino que la potenciamos? En este caso, nuestros ojos van a estar pendientes de que aparezcan indicios de que el cambio empieza a darse.  

Las mentiras más tontas también son peligrosas

Creo que si uno pregunta a los demás si mienten, la respuesta siempre es que no. 

Todos mentimos en algún momento, a veces por vergüenza, oteas simplemente porque es la respuesta más fácil para dar. 

El problema es cuando somos agarrados en una mentira. Hay mentiras que son importantes y otras que no, pero todas dejan una imagen nuestra cuando nos descubren. 

Me quiero enfocar en aquellas a las que no le damos importancia, que son tan tontas y parecen inocentes, pero que terminan transmitiendo un mensaje inconscientemente. 

Voy a poner un ejemplo: delante de otros colegas estoy hablando por teléfono con otra persona, donde para finalizar la conversación comento: "te dejo que tengo una reunión". Luego corto y sigo con mis cosas. La reunión nunca existió. Es una forma educada de finalizar la conversación telefónica. Pero que pueden pensar mis colegas si prestan atención: "le mintió a la otra persona solo para finalizar la llamada" y... acá viene la parte peligrosa: "¿cuantás veces me hará lo mismo a mi".

Resolver el problema a resolver

Muchas veces recibo propuestas, también órdenes de mis superiores, para solucionar algo. Suelen ser "optimizaciones" en los procesos y circuitos de una empresa. 

Ahora, lo que ocurre, muchas veces también, es que lo que queremos arreglar no está fallando. No siempre se cumplen las siguientes validaciones:

• ¿Es algo que está fallando o potencialmente puede hacerlo?
• ¿Hay algo que yo no estoy viendo?

Si no puedo encontrar una respuesta a esas preguntas, posiblemente se trate de una razón subyacente. En estos casos, el cambio puede no ser la mejor solución a este problema. Alguna vez he probado de utilizar el diagrama de Ishikawa  pero lo que me resultó más efectivo siempre es el preguntar por qué cinco veces (a cada respuesta que recibo, le repregunto por qué). 

Por último nunca está de más no perder de foco de la siguiente pregunta: ¿cuál es el problema que debería estar resolviendo ahora? Siempre que esté haciendo algo, voluntariamente o no, voy a estar decidiendo postergar otras cosas. Entonces: este nuevo problema, ¿es el problema a resolver, o debería enfocar mi atención en otra cosa. 

¿Qué hace especial a nuestros productos?

Muchas veces concebimos nuestros productos en base a una serie de características analizada, consensuada, profundamente discutida y verificada. Pensamos cuáles son las principales funcionalidades que lo van a hacer único. 

Después vienen las iteraciones donde nuestra creación va evolucionando, se va transformando... Esto ocurre porque recibimos feedback, porque vamos detectando mejoras principalmente por "vivir" ese producto. 

Y ahí aparece. De golpe, o a veces tímidamente, surge una característica nueva, que no vimos al definir nuestro producto, que de golpe pasa a ser lo que lo hace único, y hasta lo que le da sentido de ser. 

Leandro Panetta dio una charla en TEDxRiodelaPlata 2017 (aun sin publicar) donde explica el proceso creativo, donde a veces aparecen estas singularidades en las creaciones. Para él, es nuestra cabeza que aun está madurando el producto, no es algo que se inventa o descubre después, sino más bien, algo que se va gestando desde el momento cero. 

La enseñanza del "no"

Más veces de las que nos gustaría recibimos un no como respuesta a nuestras propuestas o planteos. Podemos enojarnos, pensar que la persona no entendió nuestra propuesta, que no tiene nuestra visión. En definitiva, transferirle la responsabilidad de la negativa. 

También podemos aprender y sacar algún provecho de la situación intentando indagar un poco más a fondo:

• ¿Por qué nos que no?
• ¿Explicamos bien la idea?
• ¿Hay alguna alternativa mejor?
• ¿Hay un factor que no estamos considerando?

Siempre que recibimos un no es una oportunidad para crecer, en lugar de caer en la fácil de tener pensamientos negativos sobre la persona que no aceptó la propuesta