coaching

"...no vaya a ser que cambie tu modo de pensar". Leí una vez en un libro de esos de desarrollo personal.

Comienza el año y después de tanto Rosco de Reyes (dulce típico en España y que pone fin a las navidades), te das cuenta de que ya es enero, vuelves al trabajo y esa enorme lista de propósitos y proyectos que alegremente hacías en diciembre, ahora la tienes delante y es hora de empezar a hacer cosas.

O sea, lo de siempre, comienza el camino para que al final del año, si nos seguimos acordando de esa lista, nos demos cuenta de que no hemos conseguido ni la mitad de la mitad. Es más, yo creo que esas promesas de mejora para el nuevo año entrante son más bien un tirar hacia delante y una excusa para justificar lo difícil que nos resulta actuar y hacer lo que debemos y queremos hacer. ¿O no?

Vale, sí, yo soy el primero que uso esas listas, las uso desde hace mucho con mayor o menor éxito. Uno de mis propósitos para este año se seguir leyendo más y mejores libros de todos los temas que me interesan, muchos de ellos de tecnología, otros de desarrollo personal, etc. 

¿Es que puede ser de otro modo? ¿Puede existir cualquier negocio o profesión que no avance sin seguir aprendiendo? Todo evoluciona, si no lo hacemos al mismo ritmo que todo lo demás, podemos terminar intentando vender algo a clientes de un mercado que desapareció o se transformó hace mucho.

Discrepo cuando oigo hablar de que estamos en la sociedad del conocimiento; puede que sí, que la economía sea cada vez más del conocimiento, pero las personas, en general, estamos lejos de darnos cuenta del impacto que esto supone en nuestra forma de aprender y evolucionar profesionalmente. Si los negocios cambian, lógicamente sus profesionales también. 

Es verdad que ahora disponemos de enormes recursos de aprendizaje a un coste ridículo en forma de blogs, webinars, podcasts, seminarios, videocursos, maravillosos libros en Kindle o de Google Play desde 0.99€ y que leemos desde el móvil; puede que ahora tendamos a leer más que antes y que leamos y nos informamos de otro modo. Pero paradójicamente, acumulamos tal cantidad de información que comienza a ser un problema esa misma sobreinformación porque somos incapaces de extraer conocimiento de todo ello. La hiperinformación (y la adicción a ella) comienza a considerarse algo patológico.

Lo importante no es llenar la cabeza de datos, sino saber qué hacer con ellos, a no ser que tengas complejo de loro y te guste repetir la información que lees, claro.

O sea, que no es lo mismo, en mi opinión, leerte todos los feeds de tu agregador cada día o cada dos horas, que empaparte un sesudo libro de Jeremy Rifkin analizando un tema en concreto en profundidad. Sin embargo, para la mayoría de la gente estar más informado es hacer justamente lo primero, y sólo lo primero.

No puedes avanzar en ningún tema si no lees en profundidad sobre él, y para ello hace falta la organización estructurada de un buen libro que analice el contexto, el planteamiento, las diversas experiencias sobre ese campo y que incluso se atreva a realizar algún tipo de prospección al respecto. El libro no ha muerto, de ningún modo, puede estar en la unidad de cuidados intensivos el formato papel, pero lo que es estructurar el conocimiento en forma de libro, eso va a pervivir, espero, muchísimos años. El saltar de titular en titular es para mí frivolizar y no llegar a nada.

En software ocurre exactamente lo mismo. No es igual aprender una nueva tecnología leyendo tutoriales por aquí y por allá que sólo tocan la punta del iceberg; puede servir para jugar un poco, para resolver problemas puntuales cuando ya conoces bien esa tecnología, yo lo hago muchísimo y lo voy a seguir haciendo, claro; también hay posts y tutoriales extraordinariamente buenos.

No obstante, si quieres realmente profundizar en esa tecnología, coge un buen libro y empápatelo de arriba abajo; es más, recomiendo no usar sólo un libro de referencia para ello, sino varios, ya que rara vez un único libro cubre todo lo relevante (por mucho que en el título ponga "La biblia de...").

Yo, al menos, eso es lo que hago cada vez que siento la necesidad de llegar al fondo de algo: quizá husmeo un poco por aquí y por allá en blogs de gente que sepa más que yo sobre ese tema en particular, pero siempre buscando una buena referencia bibliográfica con la que comenzar. Después asedio mi cabeza durante el tiempo que sea necesario con información sobre ese tema, libros incluídos, hasta que me siento suficientemente maduro como para seguir adelante. No es saber por saber, es aprender para hacer algo con todo ello.

Con un primer libro vas a conocer globalmente esa tecnología y seguro que encontrarás multitud de referencias para avanzar por caminos paralelos llegado el caso.

No se puede aprender seriamente algo únicamente picoteando en tutoriales de quinientas palabras; lo siento, pero no funciona así, el libro sigue siendo necesario porque te da esa visión global tan necesaria para saber usar bien lo que sea que necesitas aprender. Para mí, en un libro el autor te viene más o menos a decir "hey!, he trabajado mucho este tema y todo esto que te cuento aquí es mi experiencia sobre ello".

Así que esta es la paradoja: creemos que vivimos en una sociedad de la información cuando en realidad lo que queremos decir es que ahora estamos sobreinformados de muchas cosas pero seguimos con la misma falta de conocimiento que hace veinte años, y eso ocurre en todo, en tecnología, gestión de negocios, marketing, etc. Tenemos a nuestra disposición el conocimiento de forma inmediata y a coste muy pequeño, sin embargo el ciudadano medio, por lo general, no lo usa y se queda sólo en los titulares. Es una pena.

Por favor, ¡escribidme para decirme que estoy equivocado!

Acabo de comenzar el año con dos autoregalos, dos libros que prometen muchísimo.

Uno de ellos es el libro de Lazlo Bock sobre cómo están cambiando en algunas compañías la forma de organización del trabajo. El otro se llama El Mundo que Viene, de Juan Martínez-Barea, en donde se habla sobre cómo la meritocracia será un valor fundamental en el futuro (vaya, por fin).

No podemos progresar en un mundo que cambia continuamente sabiendo lo mismo que sabemos hasta ahora.

Lo siento, hay leer, pero incluso leyendo mucho te puedes encontrar abrumado y sin llegar a un conocimiento apropiado de nada e insuficiente para actuar y conseguir nuevos resultados, de ahí que leer libros bien estructurados y con la suficiente profundidad sea imprescindible, nada que ver con la inmediatez de los titulares de blogs de tecnología a la que somos tan aficionados (yo el primero, eh!), que son necesarios, claro, pero no suficientes para profundizar en nada.

El libro no está muerto, de ningún modo, el que sí lo está es quien piensa que va a obtener mejores resultados sin aprender nada nuevo.

Joer, qué serio me ha quedado esto.

La pregunta de este post es algo típica pero no menos importante; recientemente leía que en un 70% de los casos de gente que abandona su empleo, en realidad están huyendo de sus jefes. Lamentable, sobre todo porque un buen profesional se puede echar a perder si no se rodea del equipo adecuado, pero, en especial, de un jefe (manager o coordinador) que haga bien su trabajo. También oí una vez decir a Sergio Fernández que uno tiene que poder elegir a su jefe. Sea así o no, la realidad es que un mal gestor puede hacerte la vida imposible y uno bueno puede hacer que vayamos a la oficina con una motivación extraordinaria.

Entre otras cosas, dirijo equipos de desarrollo desde hace mucho tiempo y llevo años con la convicción de que un buen proyecto tiene éxito no sólo por la profesionalidad con la que se encara, también por el buen hacer de quien tiene ese trabajo de coordinar el de los demás.

Nunca me ha gustado la palabra jefe, ni manager (¿pero por qué en LinkedIn todo el mundo se etiqueta como manager de algo?), por sonarme demasiado a jerarquía o como si dentro de cualquier organización unas personas fuesen más importantes que otras. Cada uno tiene su papel y para que todo funcione, cada uno, individualmente, tiene que hacer el suyo de manera profesional. Sí, esto suena muy democrático y guay decirlo, no lo es tanto aplicarlo en el día a día. Esa idea de "todo vamos en el mismo barco", "el equipo es lo primero", etc. que tanto les gusta a los managers de medio pelo repetir, no siempre se traduce en acciones reales. Vamos, que una cosa es lo que se dice y otra muy distinta lo que se hace.

Pero, ¿en qué consiste en realidad ser un buen gestor?, ¿puede un proyecto con éxito considerarse como tal si el equipo de trabajo está quemado y el gestor es el que se lleva todas las medallas ($)?, esto último es tanto como decir que las empresas y compañías existen sólo para hacer dinero y generar beneficios. No, no sólo deben existir para eso, los beneficios deben ser una consecuencia de hacer las cosas bien y proveer de un trabajo de calidad a todas las personas que forman parte de esa organización. 

En cierta forma, un proyecto software tiene una naturaleza un poco especial a diferencia de otro tipo de trabajos, de modo que hay que conocer bien esos detalles diferenciadores para que todo vaya bien. 

¿Quieres mejorar como gestor? ¿Quieres evaluar a tu jefe y a lo mejor ponerlo a caldo? Pues sigue leyendo.

A continuación indico lo puntos claves y básicos que en mi opinión hacen de un gestor un buen responsable de proyectos software:

• Conoce en todo momento lo que hacen los miembros de equipo que dirige.
• Nunca ordena sin más: planifica y organiza para que se sepa en cada momento lo que tiene que hacer cada uno y todo el mundo conoce la coherencia y el contexto de las tareas encargadas.
• Para golpes: puesto que tu jefe tiene seguramente sus propios jefes, es fundamental que actúe en ocasiones como paraguas. En otras palabras, los miembros del equipo tienen que aislarse del ruido de fondo, ansiedades o guerras internas de otras partes de la compañía. La creatividad no puede surgir en un entorno envenenado y donde la presión y el estrés se pueden palpar.
• Estimula y motiva, esto es, aplaude las mejoras y los logros y siempre realiza críticas constructivas con ánimo de mejorar. 
• No sabe lo que es un error: llama "resultado mejorable" al error o fracaso.
• Comparte conocimientos: si el gestor lo es porque cuenta con más años de experiencia y está curtido en muchas batallas profesionales, su función es trasladar ese conocimiento al equipo.
• Nunca se fija en lo personal, siempre en los resultados aportados de cada uno.
• Delega: es muy típica la desconfianza de muchos gestores que creen que como ellos nadie puede hacer esa tarea en apariencia complicada o de responsabilidad. Esto es un error, he visto infinidad de veces cómo cuando a los miembros del equipo se les da responsabilidad y sobre todo, confianza, pueden llegar a hacerlo mucho mejor que tú y, por tanto, todos salen ganando: el primero porque delega, el equipo porque así gana experiencia.
• Asume los fallos: esto puede parecer un poco heavy de decir, pero si un miembro del equipo mete la pata, y la mete hasta el fondo, el responsable es su jefe o manager. No hay más. La cara al resto de la organización la tiene que dar él. Cuántas veces gestores (que yo llamo barriobajeros,  chanchulleros o trepadores) acusan firmemente con el dedo a la gente del equipo para esquivar los golpes. Como en todo, si una persona no es honesta fuera del trabajo, ¿por qué lo va a seguir siendo dentro? Quiero decir, somos las personas que somos en todo lo que hacemos.
• Promociona los buenos resultados siempre que puede entre el equipo. Los equipos tienen el derecho de progresar, en lo económico y en lo profesional. En muchas ocasiones, el gestor es el interlocutor con el resto de la organización para hacer eso posible. Si no mejoras es que empeoras. 
• Busca equipos coherentes. En el equipo todos tienen que aportar y se tiene que respirar un buen clima de trabajo, proactivo y estimulante. No se puede transmitir al equipo tus propias ansiedades, incertidumbres e inseguridades. ¿Quién no ha tenido alguna vez un jefe alicaído, negativo, protestón y que contagia estrés a los demás? ¿Se puede promover la creatividad y la innovación en un ambiente así?
• Un jefe quizá necesite más formación que nadie, de modo que debe ser una persona que se recicla continuamente. ¿Por qué? Un gestor de equipos debe dominar ciertas habilidades no necesariamente técnicas: debe comunicar bien y eficazmente, debe organizarse de manera extraordinariamente productiva para cumplir con sus obligaciones, debe saber gestionar y motivar a las personas, entre otras cosas. Al final anoto una serie de libros que me gustan en este sentido.
• Trabajar con gente tiene a veces sus sinsabores: el gestor debe identificar cuándo un miembro del equipo no funciona y por qué, por la razón que sea, y apartarlo del mismo. En alguna ocasión he provocado que algunas personas salgan de la compañía donde he estado trabajando en ese momento (por falta de compromiso y de competencias de esas personas, claro), os aseguro que es muy duro, te quita el sueño (literalmente), pero es necesario para que el trabajo salga adelante. Irónicamente, con el tiempo los equipos involucrados me agradecieron esa actitud de firmeza.
• Un buen responable no puede nunca tener favoritismos hacia nadie, esto crea una sensación de injusticia entre la gente.
• Pero, sobre todo, un buen gestor pone los medios para que el equipo trabaje tranquilo, centrado en las tareas de cada momento y con los medios adecuados.

Seguramente este tema dé para escribir un libro entero y más de uno esté calificando del uno al diez a su propio jefe según los puntos anteriores.

Siempre lo digo y no me cansaré de repetirlo: el éxito de un proyecto software es el éxito colectivo de todos los miembros del equipo, desde el diseñador, los desarrolladores, el gestor y el empresario que ha apostado por ese proyecto.

Si quieres saber más, aquí te recomiendo muy brevemente algunos libros que leí hace tiempo y sus enlaces directos a Amazon, una selección un poco heterogénea entre académica y de desarrollo personal, porque un buen gestor debe dominar muchas facetas de su desarrollo como profesional (buen orador, comunicador eficaz, buena organización del trabajo, etc.)

Behind Closed Doors: Secrets of Great Management, magnífico libro sobre gestión.

Aprendiendo de los mejores: Tu desarrollo personal es tu destino, de Francisco Alcaide. He descubierto a este autor este verano y he leído varios libros suyos. Un buen libro de motivación para mejorar en todos los aspectos de tu vida, también el profesional.

Organízate con eficacia: Llega más lejos de lo que nunca hubieras imaginado, básico para poder afrontar una buena organización del trabajo.

Cómo hablar bien en público e influir en los hombres de negocios (Elipse), libro de cabecera para aprender a transmitir tus ideas y comunicar bien.

Me gusta aplicar conceptos de desarrollo personal y coaching a mi trabajo como desarrollador de software y director del departamento que dirijo.

O pasamos tiempo teorizando, divagando y leyendo sobre esto y aquello (y seguramente llenando la cabeza de mucha información), o bien intentamos integrar en la acción todo eso, en el día a día, en las cosas que realizamos; si no lo hacemos así, en mi opinión perdemos el tiempo a no ser que te tomes esa avalancha de información como simple ocio: puedes leer un libro magnífico de lo que sea, no sé, como este en el que estoy ahora enfrascado sobre metodología lean en experiencias de usuario, pero si no aplicas lo que lees, no llegarás nunca a ningún tipo de conocimiento.

El conocimiento surje de aplicar lo que has aprendido. Generalmente confundimos verdadero conocimiento (experiencia) con una saturación total de información que nos impide realmente centrarnos y profundizar en nada.

Me temo que pasamos demasiado tiempo llenando la taza de información inútil y muy poco tiempo consiguiendo ese verdadero conocimiento que es el que nos resulta útil y práctico para hacer cosas. Yo siempre lo digo, no nos pagan para aprender cosas, tarea, por otra parte, infinita, sino por hacer cosas. Hay que leer, asistir a cursos y seminarios, claro, pero eso no basta; hay que aplicar en proyectos, sean profesionales o personales, todo eso para realmente adquirir ese conocimiento y experiencia.

Me encanta la teoría de la última milla: alguien que practica jogging y que quiere superarse cada vez más, conseguir mayores distancias, no lo consigue de un día para otro, sino paulatinamente; una vez has alcanzado la distancia que te has propuesto, no pares ahí, sigue, continúa aunque sean quinientos metros más o un kilómetro. En otras palabras, cuando ya has conseguido el objetivo que te has propuesto, continúa un poco más.

Ese poco más es el que te diferencia del resto, de los demás, de la competencia, y es lo que te permitirá superar tus limitaciones personales.

La excelencia o el trabajo bien hecho no consiste en un único aspecto que hay que cuidar, sino en todo lo que conlleva ese trabajo, desde la documentación, la calidad de las pruebas, incluso la calidad de las noticias en la web que hablan de ese proyecto. Como leí una vez, "como haces algo, así lo haces todo".

¿Cómo podemos aplicar la teoría de la última milla en nuestro trabajo como desarrolladores o en nuestro día a día laboral?

A continuación sugiero algunas de las cosas que yo hago, que no es que las haya leído y ahora me sirva para escribir esto o quedar bien con mis amigos o los clientes a los que intentamos vender algo, no, es lo que practico casi a diario desde hace años.

Puedes aplicar la teoría de la última milla cuando:

• Terminas de escribir un sencillo correo y antes de enviar te paras un momento a repasarlo; seguramente encuentres alguna expresión a mejorar y alguna falta de ortografía. Para mí esos detalles son importantes porque el destinatario se va a sentir importante si lee un contenido bien desarrollado o ninguneado si percibe que has escrito deprisa sin ninguna atención a los detalles. Hacer esa revisión te puede llevar menos de un minuto. Odio esos correos rápidos, llenos de faltas y que hay que leer dos veces para enterarte qué quiere decir.
• Has terminado el conjunto de pruebas que tenías previsto para comprobar cierta funcionalidad; antes de hacer el commit, el check-in o lo que sea, seguro que puedes dedicar treinta segundos a buscar un nuevo caso de prueba o ese pequeño refactoring que mejora la calidad de esas pruebas.
• Estás incluyendo las historias de usuario que se van a implementar en un próximo sprint de trabajo. Antes de darlas por concluidas, seguro que al repasarlas se podrán describir algo mejor, aunque sólo sea un poco.
• No hace mucho tuve que realizar una nota informativa de uno de nuestros productos para nuestros clientes; después de darla por finalizada, la llegué a leer hasta tres veces. En cada pasada siempre encontraba alguna expresión que mejorar o alguna pequeña errata. Estas revisiones no me llavaron toda una mañana, ni mucho menos, sino unos escasos quince minutos.

Este tipo de detalles que en sí mismos parecen insignificates por que por lo general te llevan muy poco tiempo, al cabo de la semana o del mes son muchos, cientos, de modo que se terminan acumulando y marcando realmente una diferencia en todo lo que haces. 

¿Alguna vez has pensado en algo que no sabes muy bien por qué pero parece como más profesional? Seguramente sus creadores hayan incorporado la teoría de la última milla como un hábito en su día a día, de modo que de manera casi imperceptible, su trabajo alcanza un nivel mayor de calidad.

Ese hábito de llegar un poco más allá no te va a proteger de cometer errores o de entregar algo cutre en alguna ocasión, pero desde luego nos sirve para cometer menos pifias y mejorar la calidad de todo lo que hacemos.

La resiliencia es un concepto que me encanta; aunque tiene muchas acepciones distintas, yo me quedo con aquella sobre la capacidad que tenemos de afrontar situaciones complicadas y resolverlas, aprendiendo de ellas y saliendo airosos y fortalecidos. La experiencia nos puede destruir, pero también nos puede fortalecer, todo depende de la actitud con la que la afrontemos.

Este concepto de corte más bien psicológico, lo aplico desde hace años de manera natural a los proyectos software en los que participo. En definitiva, lo que intento es aprender de los errores y mejorar todo aquello que pueda ser mejorable, ni más ni menos. El efecto de esto es que con el tiempo vamos acumulando mejores conocimientos, mejores formas de hacer las cosas y de encarar los proyectos. Lo peor en cualquier proyecto es que en algún momento podamos sentir eso de tropezar con la misma piedra de nuevo.

Pero, ¿hay algo que mejorar? Es imposible aprender de las situaciones si antes ni siquiera nos planteamos la duda de si existe algo por mejorar. Me temo que en nuestro sector hay a veces demasiada soberbia que impide reconocer los errores. 

Siempre hay algo que mejorar; si tenemos la valentía y humildad de reconocerlo, nos convertiremos poco a poco en mejores profesionales.

Se mejora continuamente cuando tenemos instaurada esta capacidad de mejora como un hábito en el día a día. Para ello, cada vez que termino un nuevo proyecto o un sprint de desarrollo, me gusta evaluar todo aquello mejorable y en ocasiones plantear una sesión de tipo que yo mismo llamo de "Lecciones aprendidas" en la que todos los miembros del equipo, incluido yo mismo, reconocemos en qué nos hemos podido equivocar e identificamos todo aquello que podríamos mejorar para el siguiente proyecto.

En estas sesiones vale comentar de todo: problemas técnicos, de falta de recursos, falta de buena comunicación con el cliente, todo aquello que haya podido afectar negativamente a la marcha de un proyecto. 

Puesto que estamos hablando de software, las siguientes preguntas son recurrentes en cualquier sesión de lecciones aprendidas independientemente de la naturaleza del proyecto en particular:

• Si se han producido desviaciones signitivativas en las fechas de entrega, ¿a qué se ha debido? ¿Qué medidas podríamos tomar para evitarlo en el siguiente proyecto?
• ¿Se ha ajustado el desarrollo en su mayor parte a lo especificado? No es extraño que el cliente corrija o intente añadir funcionalidad no indicada incialmente; aunque esto es normal y habitual, sí es un peligro cuando se intenta incluir todo ese paquete de requerimientos no cotizados en el mismo proyecto sin cambiar fechas ni estimaciones económicas. Para esto, el interlocutor con el cliente debe ser muy diplomático y firme de manera que no se afecte perjudicialmente al equipo de trabajo.
• ¿Se han generado correctamente todos los artefactos esperados del proyecto? Según el proyecto, documentación de despliegue, guía de usuario, de mantenimiento, etc.
• Una vez en producción o entregado el proyecto al cliente, ¿se han encontrado errores graves? Si es así, es que algo no se ha hecho bien en las pruebas del proyecto.
• ¿Se ha hecho el suficiente trabajo de refactorings y de código limpio para que el proyecto quede prístino, claro, sencillo y abordable para retomarlo en el futuro?

Cada proyecto indicará el tipo de evaluación que se pueda hacer. Lo importante es salir de un proyecto terminado con conocimientos más sólidos y una experiencia más amplia para que el siguiente proyecto no presente, al menos, el mismo tipo de problemas, y, lógicamente, mantener un cliente muy satisfecho con el trabajo realizado y que continúe confiando en ti o en tu empresa para nuevos proyectos.

La solvencia técnica y el buen saber hacer no se demuestra al final de un proyecto, sino en todo momento durante el mismo y el cliente es eso lo que tiene que percibir.

El problema fundamental de querer y poder enfrentarte a este tipo de sesiones positivas en cualquier entorno laboral es la falta de cultura de reconocimiento del error: ¿cómo vamos a reconocer que algo no se ha hecho del todo bien cuando creemos que nuestro jefe sólo nos va a tener en cuenta si piensa que todo lo hacemos a la perfección? ¿Cómo nos vamos a diferenciar de otros compañeros / competidores que quieren de mostrar igual que tú lo buenos que son? Nuestro jefe pronto se va a dar cuenta de que nadie lo hace todo bien siempre. 

Para mí, reconocer el error es el primer paso a la excelencia, la única actitud que nos puede hacer mejorar, y más aún en software, donde hay tantos elementos distintos en cualquier proyecto donde meter la pata.

Si no aprendemos de la experiencia, mal vamos. Como digo siempre (y parafraseando al gran Raimón Samsó), "si no mejoramos, es que empeoramos".

Hace unos años hice un ejercicio muy sencillo que recomiendo a todo el mundo que haga en algún momento del año: era viernes y anoté todas las llamadas telefónicas que había recibido durante la semana, tanto al fijo como al móvil.

Después fui analizando una a una (al menos aquellas de las que me acordaba) descubriendo algo que me hizo pensar bastante:

• La mayoría de las llamadas me interrumpieron en algo que estaba haciendo en ese momento muy concentrado.
• Muchas de ellas no me aportaron nada para resolver alguna tarea bajo mi responsabilidad, sino que me reclamaban para resolver las tareas bajo responsabilidad de otros.
• Otro grupo de ellas se podían haber sustituido con un sencillo correo electrónico que yo habría elegido leer en el momento mas adeacuado en el mismo día.
• Solo unas pocas eran verdaderamente importantes (para mí).
• Ninguna era absolutamente trascendente y urgente para que tuviera que atenderla en ese preciso momento.

Me pregunto si es esto productividad o simple pérdida de tiempo. En cierta medida, desde todas aquellas conclusiones he llegado hasta el día de hoy mejorando en muchos aspectos de mi día a día.

En esa época no era raro para mí el llegar a la tarde con esa sensación de no saber en qué se me había ido el día y por tanto decidí atajar el asunto de raíz evitando al máximo cualquier tipo de llamada o mails intrascendentes, aunque con ello me colgaran la etiqueta de maniático, soso o aburrido. Mi objetivo era cumplir con mi trabajo, sacar el mayor provecho personal y profesional de mi compañía y volver a casa temprano...

Trabajar bien y con calidad equivale a trabajar productivamente, por eso considero que el mal uso que se hace del móvil es un time killer de primera magnitud. Desde aquella semana en que analicé cómo otros abusaban de mi tiempo en el momento que a ellos les interesaba y no a mí y que la mayoría de las llamadas eran para asuntos que estaban fuera de mi responsabilidad, tomé medidas que he logrado mantener más o menos hasta ahora.

Lo siento por quien se dé por aludido, pero el centrar tu cabeza en una tarea que requiere de mucha concentración, tomar decisiones que te pueden pasar factura en el futuro (acumulando deudas técnicas o bien hacer una infraestimación de esfuerzo en un nuevo proyecto,  por ejemplo) y hacer algo lo mejor que uno pueda con los recursos y habilidades que tenemos, requiere al menos reducir al mínimo este tipo de interrupciones. Una interrupción es normal, varias en una ahora revela descontrol total en la forma de trabajar. Si no tenemos el control de evitar estas continuas interrupciones podemos incluso sufrir una ansiedad y estrés tremendos. El tener un entorno adecuado de trabajo no es sólo una cuestión de higiene, buenos equipos, etc., también es cuestión de contar con la suficiente tranquilidad para poder concentrarte en tus tareas.

No es lo mismo hacer una tarea muy concreta durante dos horas con una mente completamente absorbida en el trabajo que con una mente que se distrae cada quince minutos por un nuevo mensaje entrante, algunas ventanas de chat emergentes o varias llamadas al móvil. Absurdo. De ningún modo puede ser lo mismo: todas esas interrupciones y falta de concentración, si se producen de manera habitual, al final nos están arrastrando a trabajar mal y poco productivamente.

No creo en al multitarea, más que un mito es una forma de mostrar lo ocupados que estamos (produzcamos resultados o no). Si intentamos hacer dos tareas a la vez vamos a tardar más del doble que si lo hiciéramos primero una y a continuación la otra.

Detrás del fracaso de muchos proyectos de software está una malísima gestión del tiempo. Esto empeora aún más las cosas cuando el proyecto se ha estimado económicamente en base a unos tiempos de trabajo, que es lo habitual.

Los efectos de trabajar dispersos mientras desarrollamos código pueden ser desastrosos: la calidad del mismo depende directamente de la capacidad que tengamos de centrar toda nuestra capacidad creativa en él. Si estas interrupciones o forma no productiva de trabajar la pagamos al final con tiempo, lo primero que vamos a sacrificar son esos ratos de veinte o treinta minutos para hacer refactorings o mejorar algún aspecto de la solución.

Las empresas más productivas no son aquellas en las que sus empleados pasan más horas al día en ella, sino:

• Las que más y mejor planifican.
• Las que tienen roles claramente identificados (sobre el papel y en la práctica).
• Las que aprecian el tiempo y su buena organización como herramienta para obtener resultados.
• Las que consiguen que la gente tenga claro qué tiene que hacer en las próximas semanas.

Recuerdo varias ocasiones en las que ante un problema que se había presentado, un compañero mío me decía eso de "no te preocupes que ahora mismo lo arreglo", y a continuación y después de quedar como el héroe del momento, sacaba su teléfono móvil y llamaba a alguien para preguntarle sobre el asunto... En este sentido, quienes abusan del uso del móvil seguramente sean los que menos aportan en una compañía, ya que parece ser que son los que más dependen de los demás para resolver sus propios problemas. Hay quienes llenan su agenda laboral con reuniones eternas como forma de trabajo habitual (sin comentarios) , el resto del tiempo lo pasan colgados al móvil... 

Si trabajas de freelance entonces ya te habrás dado cuenta de que en cierta medida, lo que vendes son horas de trabajo: si consigues hacer más en el mismo tiempo, aumentarás tus honorarios.

Quizá se me pueda tachar de maniático, aunque lo que persigo siempre es fomentar tanto en mí como en el equipo que dirijo que la mayor parte de las tareas se hagan en un ambiente de calma con el menor número de interrupciones. Esto maximiza la productividad.

No hace mucho mi mujer se pasó por la oficina donde trabajo y me dijo algo así como "si esto parece un convento", a lo que le respondí "gracias, eso es lo que intento"...

Quizá a gestores ignorantes de medio pelo les guste ver a la gente muy atareada, con los teléfonos sonando todo el tiempo, las bandejas de correo saturadas de asuntos y, si es posible, que se queden en la oficina hasta las ocho de la tarde. Me temo que este presentismo caduco tiene los días contados.

Los gestores profesionales intentan que el equipo que gestionan terminen su jornada laboral con el trabajo hecho en tiempo, sin estrés y con la máxima calidad. Sí, es posible y hasta deseable. La diferencia sutil, difícil de ver, no es ni más ni menos que una correcta planificación y gestión del tiempo.

Si a la gente no se les hiciera contratos por tiempo sino por resultados, ¿no saldrían muchos antes de la oficina? Ojalá llegue un día en que esto sea así, en que no se valore por encima de todo el tiempo que se pasa en una oficina sino los resultados medibles de lo que hacemos en ella.

Lo del exceso en el uso del móvil es sólo un detalle: el día está cargado de detalles y momentos similares que poco a poco van socavando sutilmente nuestra productividad, es decir, van tirando a la basura el tiempo de que disponemos, lo cual es lo mismo que tirar a la basura parte de nuestra vida, lo que es aún más deprimente (¿que tenemos sino tiempo?).

Si lo miramos bien, el tiempo es el único recurso que tenemos realmente: si lo usamos correctamente, conseguiremos más y mejores resultados.

Hay que evitar los vampiros de tiempo, hay que evitar que en cualquier momento pueda sonar tu teléfono móvil y sacarte de ese instante de concentración en el que estás trabajando a fondo. Si no consigues concentrate en tu jornada laboral, entonces tú y tu compañía tenéis un grave problema.

Siempre, siempre, absolutamente siempre, quienes más éxito tienen en sus proyectos son los que mejor gestionan su tiempo, así de sencillo.

Tanto es así que hay quienes incluso han hecho de la correcta gestión del tiempo una profesión, como la maravillosa web de Berto Pena. En este ebook gratuito que generosamente cuelga el autor, menciona, cómo no, los siete ladrones de tiempo, entre los que se cuentra nuestro maravilloso smartphone.

Quizá estamos pasando una época en la que el mismo concepto de éxito se está redefiniendo de una manera totalmente distinta. Hasta hace bien poco, se consideraba una persona de éxito aquella que económicamente ha conseguido reunir una gran fortuna o patrimonio (sin importar la forma), una empresa de éxito aquella que ha crecido con dos dígitos porcentuales de año en año (sin importar la satisfacción laboral de sus ejecutivos, empleados y clientes), una familia de éxito aquella que vive rodeada de comodidades y maravillosas vacaciones en hoteles con todo incluido (sin importar tampoco la falta de conexión entre sus miembros), por poner algunos ejemplos. Al mismo tiempo el downshifting laboral comienza a ser un fenómeno cada vez más común.

¿Y qué demonios tiene esto que ver con el desarrollo de software?

Como en cualquier otra actividad profesional proyectamos en ella muchos defectos y virtudes que heredamos de nuestra vida diaria, aunque la relación no la veamos directamente.

Recientemente El Libro Negro del Programador ha recibido un comentario bastante elogioso desde Amazon.com y que, con permiso de su autor (al que agradezco profundamente), copio y pego a continuación:

"Lectura indispensable para los que nos dedicamos a la programación porque trata temas esenciales en cuanto a la productividad, la eficiencia, la calidad del software y el manejo del tiempo. La gran ventaja de este libro es que no es un libro mas sobre teoría de la ingeniería de software, sino que el autor aporta la gran experiencia que tiene y acierta en la solución los problemas a los que nos enfrentamos los desarrolladores a la hora de afrontar proyectos de desarrollo, explica con detalle cuáles son las malas prácticas que llevan al fracaso de los proyectos y plantea soluciones efectivas. Un punto clave que platea el autor es la importancia de nuestra profesión en el contexto actual mostrando las ventajas de ser un buen profesional del desarrollo, estas ventajas las muestra presentando un panorama muy positivo con grandes expectativas en el entorno productivo."

Para mí que el éxito se tiende erróneamente a asociar más al efecto que a la causa que lo provoca y de ahí que cometamos recurrentemente el error de embarcarnos en un proyecto sólo por su remuneración económica (vale, vale, ya sé que la pasta es importante, pero ni mucho menos es lo único), o ser amable con alguien para conseguir algo de esa persona, o apuntarnos a un intenso programa de ejercicio para adelgazar esos kilos de más, etc.

La cosa no funciona así, en absoluto: primero hay que ser (pero qué místico me está quedando esto), después hay que hacer y como resultado de todo eso, viene el tener: ser - hacer - tener. Ese es el orden ineluctable y que no falla nunca. 

Sólo cuando un proyecto resulta de utilidad a otras personas redundará en éxito económico, sólo cuando alguien nos cae sinceramente bien y le tratamos con respeto esa amabilidad se volverá a nuestro favor y sólo cuando nos gusta y hacemos ejercicio con regularidad y como algo integrado en nuestra vida, entonces conseguiremos estar en forma de manera perdurable.

Se suele hablar de éxito sólo desde un punto de vista económico, pero eso es una visión demasiado estrecha y simplista de la realidad. Nada me satisface más que uno de mis trabajos, como El Libro Negro del Programador, sea considerado de utilidad para otras personas: si con este proyecto he conseguido mejorar la vida y perspectivas profesionales de algunas personas, si les he ayudado a mejorar un poco, aunque sólo haya sido un poco, sus trayectorias laborales, si les ha servido para no cometer alguno de los errores más típicos y recurrentes en software, sólo entonces, consideraré El Libro Negro del Programador como un trabajo de éxito, y sólo si esto es así será cuando algo me llegue en forma de royalties...

El comentario anterior me llena de satisfacción y ánimo por la sencilla razón de que me muestra que el libro resulta de utilidad: esta es en realidad la esencia de cualquier proyecto con el que queramos conseguir algo. Cualquier trabajo, del tipo que sea, enfila hacia el éxito si sabe identificar necesidades no cubiertas y si al final resulta de utilidad a un grupo de gente que estará dispuesta a pagar por él. Así de sencillo, pero al mismo tiempo tan difícil de tenerlo en cuenta en todas nuestras decisiones.

En software a veces se nos olvida que lo que hacemos, el código que escribrimos, las interfaces de usuario que diseñamos no las hacemos para nosotros mismos sino para el cliente final. También se nos olvida que debemos escribir código de forma que cualquier persona que retome el proyecto en el futuro lo pueda asumir sin tener que desentrañar una aplicación con un diseño críptico e imposible de entender.

Me temo que me encuentro con personas que alardean de trabajar para una gran compañía, de ámbito internacional, pero que al mismo tiempo se quejan de tener que viajar tan frecuentemente que no pueden estar todo el tiempo que les gustaría con sus familias. Quizá tienen un saldo bancario excelente, pero ¿qué tipo de éxito es aquel que nos impide lo esencial, como es el estar con nuestros hijos, a cambio de una remuneración alta? Desde fuera pueden ser vistas como personas de éxito, pero desde dentro la cosa será muy distinta. Es sólo un ejemplo de cómo ese mismo éxito tiene muchas caras, luces y sombras.

Las personas que llegan a nuestra profesión exclusivamente como salida laboral tienen pocas probabilidades de encontrar un hueco a largo plazo en esta actividad tan exigente; claro que es legítimo buscarte la vida lo mejor que uno pueda, pero esta exigencia que es consustancial a nuestra profesión sólo se puede superar si realmente te gusta.

Los mejores profesionales que conozco son aquellos que realmente disfrutan con lo que hacen, que adoran su trabajo y a veces lo confunden con su mejor hobby. Un síntoma inequívoco que nos indica si lo que hacemos nos apasiona es si llegamos a ese estado de flujo en el que el tiempo, sencillamente, deja de existir y el cansancio no es más quen una simple anécdota. Si este estado del que hablo te suena a chino, entonces es que nunca has estado tan inmerso en una tarea que no te ha importado nada más.

Sólo estas personas pueden aguantar los momentos de crisis, las tensiones que se producen cuando se acercan las fechas de entrega peligrosamente, porque saben que en el fondo, están esperando esa maravillosa sensación adictiva que es entregrar un buen trabajo e irte a casa con la sensación de que te mereces el dinero que cobras por él.

¿Utópico?, de ningún modo, conozco personas así y son las que al estar con ellas irradian energía de arriba abajo, que hablan de lo que hacen con un entusiamo visceral y que lo proyectan en todo lo que hacen. Eso sí que es para mí éxito, la enorme suerte de poder vivir de aquello que te apasiona y no trabajar para otros mercenariamente por una nómina. Ni que decir tiene que tenemos que vivir de algo, pero ¿qué sería del mundo si asumiéramos un concepto de éxito más en relación a la calidad de vida, bienestar y sosiego mental, satisfacción con lo que uno tiene y es, relaciones armoniosas, ausencia de estrés y, por supuesto, la satisfacción de aportar y dar por sí misma? Seguro que el PIB sería entonces muy distinto...

¿Somos los mejores profesionales que podríamos llegar a ser?

¿Aportamos valor realmente a la compañía para la que trabajamos o a los clientes que nos pagan los honorarios? ¿o nos limitamos a hacer lo que nos dicen y nada más y no sabemos tomar la iniciativa en ningún asunto?

Se usa a menudo la expresión aportar valor pero en la mayoría de las ocasiones sólo queda como un simple titular de promoción interna en los departamentos de recursos humanos. Queda muy bien, pero realmente no se cambia absolutamente nada para que exista una cultura corporativa que promueva el valor, el talento y la proactividad. Veo demasiada gente hablando de proactividad pero actuando muy poco proactivamente: decimos una cosa pero después hacemos otra totalmente distinta. A mí esto me suena al principo de la locura.

No sabremos aportar valor en nuestro entorno si no invertimos en nosotros mismos. Es, de hecho, la mejor inversión que podemos hacer.

Quizá nos han educado para buscar un empleo del que vivir, trabajar en algo con lo que ganarnos la vida y pagar las facturas a final de mes. Quizá, digo, no pusieron durante nuestra educación el énfasis necesario para que siempre busquemos trabajar en algo que no sólo nos guste, sino que nos apasione. Otra cosa distinta es que eso mismo lo busquemos como empleado o como empleador, aunque lo que aquí quiero recalcar es que la excelencia, la calidad, siempre surge cuando amamos lo que hacemos con una intensidad superior al resto de nuestras obligaciones.

No existe ningún trabajo en el que todas las tareas que tienes que realizar sean siempre gratas; para conseguir un objetivo final, un proyecto con resultados, hay que hacer muchas cosas diferentes, unas nos pueden gustar más, otras menos, pero si cuando terminamos el proyecto, dando paso a una nueva fase en él o comenzando otro completamente nuevo, no sentimos cierta satisfacción, orgullo personal o una sencilla alegría por haber terminado algo con calidad y lo mejor posible dadas las circunstancias, entonces es que no estamos dedicando nuestra vida laboral a lo que realmente nos apasiona.

En software esto tiene un impacto enorme, aunque no siempre nos damos cuenta de las consecuencias desastrosas que esto tiene para la ejecución con éxito de un proyecto.

De acuerdo, hay quienes son capaces de dedicar ocho o más horas a una actividad que ni les va ni les viene, lo cual no deja de ser una virtud, necesaria además en aquellos países donde la crisis financiera todavía tiene un impacto grande. No obstante, quienes nos planteamos nuestra carrera laboral como algo ascendente, con pasos positivos y progresivos hacia el éxito, lo que sea que cada uno entienda por éxito, no podríamos trabajar en algo por lo que realmente no sentimos pasión.

Nunca vas a ser bueno, un profesional altamente cualificado, si has elegido hacer algo que no te llena, que no te gusta. Es así de sencillo pero así de contundente.

Del mismo modo, en una profesión donde la excelencia tiene una relación tan directa en la vida de los productos software que construimos, esta característica de los desarrolladores es más relevante que en cualquier otra profesión.

Me gusta mi profesión, a veces tan poliédrica, me gusta realizar productos que le resulta a un usuario final de enorme utilidad. Hay ocasiones en las que un sencillo pero elegante refactoring que hago y que mejora de algún modo la calidad del código que escribo, me hace sentir muy bien.

Igualmente me siento bien cuando me resulta fácil detectar cualquier problema en la instalación de un cliente donde tenemos desplegados algunos de nuestros productos (se ha hecho el suficiente esfuerzo para que el software se pueda depurar), cuando nos plantean una nueva necesidad y vemos que perfectamente se puede encajar en las capacidades de integración del producto, cuando un cliente te felicita porque le resulta fácil utilizar la interfaz de usuario sin recurrir a la guía de usuario (interfaces amigables) o cuando te felicita también porque lo que antes tardaba en hacer varias horas, ahora lo puede realizar a golpe de clic ahorrando costes a su compañía (valor para el cliente final), y un largo etcétera.

Para conseguir eso, hacen falta muchísimas horas de trabajo, disciplina, perseverancia en la creación de pruebas unitarias y de integración, refactorización continua de código y de diseños en cada nueva funcionalidad, clase, librería, etc. implementada y todo eso, desde luego, no se podría hacer si no te has vuelto adicto a ese momento mágico en que etiquetas una nueva versión de tu producto o creas un nuevo branch sabiendo que la versión que cierras en ese momento está bien conseguida, tanto en funcionalidad como en calidad interna de código. Si a esto lo llamamos excelencia, entonces no puedes llegar a ella si pasas ocho horas o más al día trabajando esperando que te ingresen una nómina a final de mes.

Uno de estos momentos, que yo llamo de epifanía, fue cuando colgué mi primera web allá por el 2008 (bueno, no es que ahora esté realmente orgulloso de ese trabajo, pero esa era mi primera incursión en entornos web después de años dedicado a aplicaciones y entornos de backend muy escalables y optimizados).

Una persona que no encaja en lo que hace y en lo que pasa muchas horas de su vida, necesariamente no se va a esforzar por realizar el mejor trabajo posible: la pregunta que los desarrolladores de software profesionales se deben hacer cuando terminan una tarea, es ¿puedo mejorar esto en algo?, ¿puedo abstraer de aquí algo para mejorar el diseño de la solución?, ¿podría simplificarlo aún más?.

Un desarrollador puede terminar su trabajo y ya está, un desarrollador bueno se plantea algunas o todas esas preguntas de vez en cuando o puntualmente, pero un desarrollador excelente se hace esas preguntas continuamente.

Como responsable de grupo de trabajo, una de mis funciones es crear un equipo con personas que se sienten a gusto haciendo lo que hacen, que les guste realmente la mayor parte de las tareas de desarrollo que desempeñan, pero, sobre todo, que se sienten felices cuando se termina algo con una calidad magnífica.

No podemos innovar en áreas de trabajo que no nos gustan del mismo modo que no podemos ser lo más productivos posibles en aquellos trabajos que odiamos.

La primera vez que leí sobre este aspecto del desarrollo de software fue en The Passionate Programmer, de Chad Fowler, uno de los libros que descubrí hace años y que me convencieron de que programar era mucho más que escribir líneas de código.

Sólo podemos programar bien si realmente nos gusta este trabajo y esta profesión tan exigentes.

Esto es exactamente de lo que habla Ken Robinson en el TED en la charla antológica y su libro El Elemento, de cómo la pasión por lo que uno hace lo cambia todo:

https://www.ted.com/talks/ken_robinson_says_schools_kill_creativity