Ahora mismo se está viviendo una auténtica ola sobre el emprendimiento en mi país; no sé si en otros lugares está sucediento lo mismo. Lo que debería ser una actitud que se les enseña a los niños desde parvulario, ahora parece que lo estamos aprendiendo a marchas forzadas (por la urgencia de la crisis económica y financiera que llevamos arrastrando desde hace tiempo).

Revistas y publicaciones, programas de radio y televisión, másters y mucho libro de autoayuda para el desarrollo personal y coaching así como programas de apoyo al emprendedor están ahora por todos sitios.

Para mí todo esto es bueno porque supone que dejamos de pensar que los demás nos van a dar un trabajo y tomamos la responsabilidad de pensar por nosotros mismos, lo que en algunos círculos llaman el empoderamiento personal. Esta misma actitud es también muy positiva como empleado de una compañía, lo que se llama intraemprendedor, es decir, aquella persona que trabajando en una empresa innova o aporta ideas desde su ámbito de responsabilidad manteniendo una actitud proactiva continuamente, con él mismo y con todo lo que le rodea.

Los desarrolladores de software quizá tengamos más facilidades que otros profesionales para emprender en un momento en que todo el mundo mira a Internet y el paradigma económico impulsa la eficiencia y el uso masivo de dispositivos siempre conectados. De ahí que muchos desarrolladores tengan continuamente ideas que poner en marcha con las que intentar emprender un proyecto empresarial.

Programar bien y dominar tecnológicamente ciertas plataformas, no tiene nada que ver con emprender un buen proyecto que funcione comercialmente. Para esto hacen falta muchas otras habilidades que, por supuesto, se pueden aprender.

Lo que no es nada bueno es que se ignoren todas esas habilidades y conocimientos necesarios para montar comercialmente un proyecto. Me preguntaron no hace mucho qué pensaba yo al respecto y cuáles podrían ser los primeros pasos para pasar de la idea al producto, de modo que en esta ocasión me voy a extender un poco más de lo habitual y aportar mi granito de arena para al menos indicar todo lo que hay que tener en cuenta.

Hay cientos de libros, seminarios, cursos y hasta másters que cubren este tema, que, además, evoluciona igual que las tecnologías software. Por tanto, este post viene a ser algo así como una introducción acelerada al emprendimiento con proyectos software.

Por su extensión, he dividido este trabajo en las siguientes secciones.

De la idea al proyecto

En cierta medida, emprender es probar si lo que tienes en mente puede funcionar o no y encontrar un mercado para esa idea o producto. Si de lo que se trata es de probar algo y según los resultados obtenidos, evolucionarlo tantas veces como sea necesario, entonces todo esto huele un poco a ágil y a lean, a iterar sobre algo hasta conseguir un buen resultado.

Muchas veces los errores son grandes maestros. Allá por el 2008 tuve mi primer contacto con un proyecto y una idea emprendedora que fue un auténtico desastre a los pocos meses; la razón es que confundimos la idea con su realización, la amistad con un relación de compromiso en un proyecto común y, por supuesto, una ignorancia total sobre cómo darle cuerpo empresarial a lo que queríamos desarrollar, entre otros muchos errores... Ese primer proyecto fracasado lo recuerdo con cariño por todo lo que me enseñó; también es cierto que ahora se hace mucha apología del fracaso como herramienta de aprendizaje. Digo yo que en un punto intermedio entre la indolencia y el no fustigarnos al tropezar estará la virtud.

En cualquier caso, desde entonces han pasado muy cerca mía multitud de proyectos de conocidos, charlas en eventos sobre modelos de innovación y muchas, muchísimas lecturas al respecto. Igualmente proyectos personales con mayor o menor éxito.

Si estás pensando en poner en marcha una idea que implica el desarrollo de cualquier tipo de software me gustaría decirte que el desarrollo del mismo es tan sólo el centro de un universo de variables y tareas que hay que hacer bien, relacionadas o no con el software pero que sin ese universo tu idea no llegará a ninguna parte, me temo.

Como desarrolladores nos gusta dedicar gran parte de nuestro tiempo programando, creando artefactos que hacen algo, pero si desarrollamos un proyecto emprendedor basado en software, entonces no podemos ignorar dotarle de la estructura emprendedora correcta. Y, por supuesto, estar dispuesto a gastarte algunos eurillos... Esa coletilla de comenzaron sin nada es sólo un mito urbano que pudo funcionar para algún visionario pero de ninguna manera es lo general. No entiendo cómo alguien que dice creer en su idea después no es capaz de invertir en ella algo de dinero.

Veamos cuáles son esas piezas fundamentales en las que casi ningún emprendedor de software ilusionado apenas repara y ni le da importancia y, sobre todo, cómo algunas decisiones desde el punto de vista del software son fundamentales.

La idea, por evidente que parezca decirlo, sólo existe en la cabeza

¡Qué sorpresa! En otras palabras, lo que quiero decir es que si esa idea no sale de la cabeza cobrando vida mediante la acción, ahí quedará, como un ente mental sin valor. Para la mayoría de la gente, las ideas se quedan ahí dentro, sólo para unos pocos la idea es lo suficientemente fuerte para pasar a la acción.

En multitud de ocasiones pensamos idílicamente en un proyecto maravilloso, único, que podría funcionar, es decir, generar usuarios y clientes y por tanto, ingresos. Entonces hacemos planes de cómo hacer esto o aquello, sobre qué tecnologías usar (a menudo son siempre las que más conocemos), las posibilidades que se podrían abrir y un largo etcétera. 

En ocasiones, también, estas maravillosas ideas no son más que quimeras mentales para huir de una realidad personal o laboral que no te gusta. Esto lo he visto hasta la saciedad.

Si eres un iluso, quédate en el mundo de las ideas, pero sólo las que inducen a la acción, al trabajo y al esfuerzo, saldrán adelante.

No hace falta inventar un proyecto maravilloso y totalmente innovador: muchas veces, propuestas que parecen triviales y hasta aburridas son las que encuentran un mercado y una viabilidad.

En mi opinión existen dos momentos claves para pasar de esta fase (llamémosla de la idea al proyecto). La primera es sentarse tranquilamente a poner por escrito una descripción clara del proyecto, su misión, sus expectativas, etc. Poner por escrito todo lo que tenemos en la cabeza tiene un valor incalculable por la sencilla razón de que te obliga a definir cosas que hasta ese momento sólo eran entelequias un poco vagas. Muchas ideas no pasan de esta prueba...

Existen técnicas para pasar al papel una idea de proyecto, como la técnica del canvas (o lienzo), con herramientas online que te ayudan a su definición, como Canvanizer. Del mismo modo, los mapas mentales también ayudan en esta fase.

El segundo momento, si es que se ha superado el primero, es adquirir un compromiso con uno mismo. Ningún proyecto incipiente se va a desarrollar si antes no nos comprometemos personalmente con él, esto es, no nos comprometemos a sacar tiempo extra (quitándonos tiempo de ocio, de fines de semana, etc.). Sólo cuando hay compromiso personal es cuando se llega a algo. Lo sorprendente es que cuando crees en algo, no hay esfuerzo que valga, ya que estás deseando dedicarle tiempo.

Al menos eso funciona para mí: cuando hemos terminado una fase de un proyecto a tiempo, o realizado cualquier proyecto personal sea del tipo que sea, la mayor satisfacción me la produce el haber cumplido con un compromiso personal previo autoimpuesto.

El Arte de EmpezarSi este paso a la acción te cuesta trabajo necesitas urgentemente El Arte de Empezar de Guy Kawasaki.

Hay que validar la idea

Me gusta el enfoque lean en la realización de proyectos, sobre todo si son proyectos basados en software que viven en un mundo acelerado en donde los paradigmas cambian tan rápido. Lo que triunfa ahora es la disrupción. 

Vivir con menos (Albert Cañigueral)Hace poco he terminado de leer este maravilloso libro de Albert Cañigueral y de título Vivir Mejor con Menos, descubre las ventajas de la nueva economía colaborativa y, como me ocurre a menudo, no puedo evitar poner gran parte de las cosas que leo en relación a mi actividad como desarrollor de software y gestor de proyectos. 

Por decirlo en pocas palabras, me siento entusiasmado por toda la información que ofrece Albert en su libro y por las enormes oportunidades que se están abriendo ya en este nuevo paradigma económico que sutilmente se está abriendo paso poco a poco. 

La economía compartida (o sharing economy), por definirla brevemente, consiste en mantener una relación distinta con los objetos que consumimos y usamos: pasamos de relacionarnos con ellos en forma de propiedad a considerarlos como un servicio de intercambio, de ahí lo de consumo colaborativo.

Los paralelismos entre este concepto y Saas, Paas y Iaas (software / plataforma / infraestructura como servicio) son evidentes. De hecho, uno de los productos que comercializamos en la compañía para la que trabajo se ofrece como servicio con suscripciones periódicas y lo más sorprendente es que todos los clientes usan esta modalidad. No compran el producto, sino que pagan periódicamente por su uso.

Cuando se habla de economía compartida a uno se le viene a la cabeza Bla Bla Car o Airbnb (plataformas muy populares en mi país); no obstante, eso es sólo la punta del iceberg; lo más interesante de todo es que es una renovación de viejas formas de organización, quizá ancestrales, pero que con Internet como palanca su efecto es infinitamente mayor. Cuando hablamos de Internet, lo hacemos de software...

Gracias a infinidad de iniciativas que se están poniendo en marcha y todas a través de portales y aplicaciones móviles, se están desplegando todas las posibilidades de organizar una economía menos centrada en el hiperconsumo y más en la colaboración y la confianza entre los individuos. 

Quien piense que carreteras llenas de vehículos con un único conductor, por poner un ejemplo llamativo, es un futuro sostenible para nosotros y nuestros hijos, va por mal camino. Cambiar de un paradigma económico a otro ni sucede en dos días y además ocurre casi de manera imperceptible con tiempos en los que se solapan ambos para llegar a darnos cuenta de que en una o dos décadas hacemos las cosas de otra manera.

Para ello la economía no cambia porque sí, sino que lo hace porque antes ha cambiado la mentalidad de las personas.

Todo esto, como digo, lo están posibilitando infinidad de sitios en Internet como forma de comunicación básica, ¿cómo si no? Vemos cómo el trabajo de muchos desarrolladores, por tanto, no es sólo escribir software, también existe una responsabilidad ya que a través de esos desarrollos cambiamos la forma en que la gente se relaciona y también cómo puede evolucionar la economía. Aunque parezca grandilocuente, es así.

En ocasiones digo eso de que es un magnífico momento, quizá el mejor, para ser desarrollador profesional porque parte de la economía se está moviendo hacia lo digital. Sin embargo Albert en su libro indica que no queda ahí, sino que también la misma tecnología está modificando cómo nos movemos, relacionamos, consumimos y, en definitiva, está modificando la economía tradicional, el cambio es por tanto, recíproco. Apasionante. 

Tal y como afirma Albert, todo ello se está produciendo por la existencia de Internet, su uso masivo, la cultura digital, la omnipresencia de la tecnología y también por la crisis económica (que fomenta en las personas la necesidad de buscar alternativas que no dependan directamente de consumir con dinero).

La economía compartida es mucho más que poder compartir los gastos de coche en tus desplazamientos habituales, además:

  • Couchsurfing: conseguir alojamiento basado en la confianza entre individuos y tu reputación en la red. 
  • Carcharing y carpooling: no sólo compartes trayectos (como conductor o pasajero), también puedes ofrecer tu propio coche para que lo usen otros mientras a ti no te hace falta.
  • Alojamiento y alquiler de espacios entre particulares: ofrecer alojamiento a terceros en tu propia casa y tú mismo conseguir alojamiento gratis o de pago, siempre entre particulres y basado en la confianza. Esto incluye también el intercambio de tu propia casa con la de otro particular.
  • Coworking: ¿por qué no compartir los espacios de las oficinas entre distintas empresas o freelancers, reduciendo costes y además posibilitando el networking entre ellos?
  • Finanzas participativas como el crowdfunding (apoyo a proyectos) y el crowdlending (préstamos entre particulares), especialmente importante en aquellos países donde la crisis económica ha supuesto una enorme restricción en el acceso al crédito... Esto también incluye inciativas de ahorro colectivo.
  • Intercambio de divisas entre particulares, quitándote de enmedio al agente bancario con sus comisiones.
  • Monedas sociales virtuales, siendo el bitcoin como la más conocida aunque hay otras.
  • Bancos de tiempo: no hace falta comprar el servicio de alguien, puedes intercambiar lo que todas las personas tienen, que es ¡el tiempo!. Así le ayudas a tu vecino un día en algo y él a ti en otra ocasión, por poner un ejemplo.
  • Mercados de segunda mano: a mí por lo menos, me remuerde la conciencia cuando tengo que tirar algo que aún podría usar alguien pero que yo no necesito. Al revés también, ¿por qué no adquirir algo que necesitas y que necesariamente no tiene por qué ser nuevo? Reducimos así la fabricación continua de productos y los reutilizamos más antes de tirarlos a la basura.
  • Grupos de consumidores, compras colectivas, venta directa entre productor y consumidor y un larguísimo etcétera.

¿Ejemplos? Hay cientos y muchos con carácter local, por poner algunos en los que me he interesado especialmente: Comunitae y Lendico (para préstamos colaborativos), Home for Exchange (para el intercambio de casas entre particulares), BlaBlaCar y Carpooling (para compartir coche), Social Car (para alquier de coches entre particulares), Goteo, Verkami, Kickstarter e Indiegogo (para la búsqueda de financiación en proyectos), Puddle y TuTanda (como plataformas para el ahorro colectivo), Transferwise (para el intercambio de divisas entre particulares) y muchos más.

¿Alguien puede pensar que todas esas plataformas son sólo una prueba de concepto? Ni mucho menos, son realmente la cara visible de un nuevo paradigma con el que consumimos y compartimos de otra forma.

Yo creo que este movimiento, si es que se puede llamar así, no tiene marcha atrás y que es ahora cuando se están dando los primeros pasos. Con sus luces y sus sombras, lo que sí está claro es que una economía basada en el crecimiento ilimitado del PIB en un mundo cuyos recursos son finitos y donde el individualismo exacerbado vacía las farmacias de ansiolíticos y antidepresivos, este emergente paradigma económico no basado en el dinero exclusivamente y en la acumulación de bienes, sino en el intercambio y en el uso de esos bienes, nos acerca un poco más a esa idea de dejar el mundo algo mejor que como nos lo encontramos. No es idealista, es una realidad que poco a poco está cambiando cómo nos relacionamos y ahora cómo consumimos. Sí, estoy firmemente convencido de que el software (y nuestro trabajo) se puede poner al servicio de causas de ese tipo dándole mayor sentido a nuestro día a día.

¿Y a mí qué, si yo como desarrollador hago lo que me encargan?, podría pensar cualquiera. Sin embargo, este tipo de portales e inciativas que aspiran a cambiar la forma en nos relacionamos e intercambiamos bienes y servicios, implican conocer ciertas tecnologías para su desarrollo e igualmente introduce un componente social en los productos, por poner un ejemplo:

Trabajar en distintos ámbitos tiene algo de fascinante, terminas dándote cuenta de cómo lo que haces en uno enriquece los demás y al revés.

Ahora mismo estoy trabajando en un proyecto basado en MEAN que al mismo tiempo me está permitiendo sentar las bases de un proyecto de I+D que estamos realizando en la compañía para la que trabajo y que desarrollaremos durante 2015 y 2016; este proyecto consiste en un sistema de detección y diagnóstico de incidencias para el despliegue de cuatro millones de smart meters, de la mano de una compañía de distribución eléctrica nacional. Big-data con Hadoop, su despliegue en la nube con Azure, el análisis y explotación de esos datos más una capa de servicios que consumirán terceros sistemas serán las partes esenciales del proyecto y en cuyas tecnologías nos vamos a meter de lleno en los próximos meses.

¿Qué puede garantizar que tendremos éxito en ese nuevo proyecto reconociendo que algunas de las tecnologías que vamos a usar son relativamente nuevas para nosotros?

Si crees conocer muy bien la tecnología X, ¿qué te hace pensar que serás capaz de sacar provecho a otra totalmente distinta?, ¿te asegura acaso que vas a tener éxito con un nuevo stack que debes usar para un nuevo proyecto cuya naturaleza no tiene nada que ver con lo que has hecho hasta ahora?

Para un responsable de proyectos, ese es un riesgo que hay que considerar a fondo.

Un desarrollador de software o un equipo de trabajo sólo pueden tener éxito en cualquier proyecto si son capaces de mantener firmemente una serie de principios de desarrollo y métodos que se pueden aplicar a cualquier tipo de tecnología.

Por tanto, aún teniendo valor, me da siempre qué pensar cuando escucho afirmaciones del tipo "soy experto en C#", "nivel avanzado de administración de Sql Server", o "desarrollador front-end con AngularJS", etc, cosa que se suele ver en todos los currículums que me llegan (y por qué no, en el mío propio hasta hace pocos años). Todo eso es fantástico, pero no suficiente...

Si dominas una serie de principios serás bueno y tendrás éxito en cualquier proyecto software independientemente de las tecnologías que se usen.

Para mí, el currículum ideal de un desarrollador profesional de software estaría compuesto de afirmaciones de este tipo:

  • Participación activa en los siguientes proyectos:....
  • Experto en patrones de diseños y antipatrones.
  • Experiencia en enfoques ágiles para proyectos software.
  • Conocimiento sobre principios de diseño como inyección de dependencias, inversión de control, DRY, KISS, SoC y un largo etcétera.
  • Desarrollo con integración continua y cobertura total con pruebas unitarias y de integración.
  • Experiencia de análisis de calidad de código.
  • Habituado a refactorizar código y desarrollo de código limpio.
  • Experto en realizar código mantenimible y evolucionable.
  • Dominio de arquitecturas software escalables.
  • Conocimiento de principios de usabilidad en interfaces de usuario.
  • etc.

Aunque sólo son un ejemplo, todas esas aptitudes son mucho más importantes que dominar cualquier tecnología en particular: con cualquier lenguaje, sistema operativo, framework o entorno de desarrollo se pueden aplicar esas técnicas, principios y métodos impresindibles para generar productos software de calidad.

Cualquier desarrollador con dominio de todos esos temas va a seguir aplicándolos con cualquier nueva tecnología con la que tenga que comenzar a trabajar.

Aparte de una actitud positiva hacia el trabajo y buena disposición a trabajar en equipo, a lo anterior añadiría afirmaciones de tipo "Mis últimas lecturas técnicas han sido...", "Asistencia en el último año a eventos como...", "Participación en el blog X", etc. Aunque ya todo esto sería mucho pedir.

Es difícil, lo sé, cuando muchas compañías piden "expertos programadores en java", por poner un ejemplo, sin darse cuenta de que cualquier desarrollador mínimamente experimentado puede acercarse al mundo java con un par de semanas de estudio y dos o tres buenos manuales, aunque no por eso va a hacer un buen trabajo necesariamente. Sí va a hacer un buen trabajo si está habituado a implantar todos los conceptos anteriores con cualquier otra tecnología. Otra cosa es que los gestores de proyecto tengan claros ese tipo de consideraciones...

En cierto sentido, todo lo anterior es como la gramática y la ortografía necesarias para escribir una buena novela, en donde el saber escribir una palabra tras otra vendría a ser a conocer bien la tecnología X.

¿Sabes sencillamente escribir aunque tengas un buen vocabulario sin tener claras la gramática que nos permite generar un trabajo de calidad?

Este es el comienzo de un nuevo proyecto. 

Soy de la opinión de que si no eres capaz de explicar a otros aquello que crees que sabes y que usas en el día a día, seguramente no sepas tanto como crees. Enseñar, sea de la forma que sea, mediante posts en un blog, en artículos o en videologs, siempre te permite ahondar aún más en los temas que tratas. Tengo la impresión de que en la cultura anglosajona se fomenta más el mentoring, no es por casualidad, tanto dentro como fuera de la compañía o las empresas en las que trabajas.

Durante 2014 me he metido de lleno en ciertas tecnologías y tendencias relacionadas con conceptos como big-data, responsive design, plataformas para la economía colaborativa, el Internet de las Cosas, etc., al tiempo que me he esforzado aún más en mejorar técnicas de gestión de proyectos software (y que en gran parte consisten en tener una gran empatía con el equipo que dirijes). Como digo siempre, si no mejoras en las competencias con las que trabajas, entonces es que empeoras...

Me gusta NodeJS, lo he empleado este año pasado en un proyecto profesional para un cliente y ahora mismo lo estoy exprimiendo de lleno en uno de mis proyectos para este año. Al mismo tiempo, no encuentro en los pocos libros acerca de NodeJS escritos en castellano todo lo que me gustaría encontrar en ellos; es más, creo que existe una gran laguna que hay que cubrir.

¿Será NodeJS objeto de olvido dentro de unos años?

Aunque en software nunca se pueden hacer predicciones a medio y largo plazo porque no siempre sobreviven las mejores tecnologías, creo que NodeJS y sus derivados va a pervivir con nuestra forma de enfocar proyectos escalables mucho tiempo.

La razón, básicamente, es que es relativamente sencillo de aprender, porque se usa Javascript que es el lenguaje que cada vez está más omnipresente y porque está creciendo alrededor del core un ecosistema de módulos que lo enriquecen enormemente. Por tanto es el momento de preparar en condiciones, con rigor y calidad un buen libro sobre NodeJS.

Pero, ¿otro libro de NodeJS?, ¿será uno más o aportará algún enfoque nuevo?

Existe un gran vacío de literatura técnica en castellano sobre esta tecnología; lo que se encontrar, aún estando muy bien, no deja de ser en mi humilde opinión sencillas introducciones a lo básico de NodeJS sin dar un enfoque global a la realización de un proyecto profesional y listo para salir a un entorno de producción. O sea, que necesitarías varias publicaciones así como muchos artículos y búsquedas en foros para atar todos los cabos y terminar una aplicación mínimamente profesional con NodeJS.

Describir los rudimentos de una tecnología no te prepara para usarla a fondo en un proyecto profesional. Los libros (tanto en castellano como en inglés) que he leído, aún gustándome, carecen de lo siguiente:

  • Se presentan siempre ejemplos sencillos y de juguete. Lo cual pedagógicamente está bien pero está lejos de resolver problemas reales, de los que se presentan en cualquier proyecto con NodeJS.
  • No se indica cómo implementar técnicas básicas de clean code y refactoring con NodeJS.
  • Tampoco se hace hicapié sobre la mejor forma de estructurar un proyecto según la naturaleza de éste.
  • No hay un catálogo de buenas prácticas para que un proyecto en el que se emplea total o parcialmente NodeJS se desarrolle con lo que la comunidad acepta como lo más correcto.
  • Existe un gran vacío en relación a implementar tácticas de seguridad en un proyecto web realizado con NodeJS.
  • Tampoco se encuentran fácilmente las mejores prácticas para desplegar un proyecto con NodeJS en producción de cara a su mantenimiento.
  • No se profundiza en ninguno de todos esos módulos que han ido creciendo alrededor de NodeJS y con los que se ha creado un ecosistema realmente rico y maduro para la realización de aplicaciones profesionales (Q y promises, passport, sequelize, async, underscore, lodash, etc.)
  • Del mismo modo, no se sugiere cómo usar correctamente un framework de pruebas unitarias con NodeJS y cómo integrarlo bien en cualquier proyecto. 
  • Igualmente, tampoco se aclara correctamente cómo hacer una separación de responsabilidades (separation of concerns) en un proyecto con la especial idiosincrasia de NodeJS para su fácil testeabilidad y buen mantenimiento.
  • En relación a proyectos web, existen bastantes cosas acerca de Express, pero en pocas se incluyen los elementos necesarios para producir una aplicación web con ficheros css y js, minimizados, concatenados, etc.
  • Tampoco se aborda cómo integrar el consumo de recursos externos publicados en forma de servicios REST o cómo construir tu propia capa RESTful.

No es que quiera abarcar todos esos temas con una profundidad tremenda, pero sí con el suficiente detalle como para mostrar una visión global completa.

Así las cosas, hasta ahora si decides meterte de lleno en esta fantástica y prometedora tecnología, que sepas que tendrás que hacerte de alguno de los libros disponibles actualmente y que además tendrás que bucear en multitud de contenidos extra para ver de manera global y holística todo este Universo NodeJS.

De ahí el nombre de Universo NodeJS: no es sólo esa tecnología, su Core API y el uso más o menos avanzado de Javascript (ECMAScript versión 5), sino además multitud de módulos, técnicas y buenas prácticas para el éxito de un proyecto.

¿Cómo se publicará el trabajo?

Los capítulos, ya planteados y organizados, se irán produciendo a lo largo de los próximos meses con una dinámica similar a como fui liberando las secciones de El Libro Negro del Programador: adelantos cada varias semanas de los capítulos con el contenido fundamental hasta completar la publicación del libro con todo el material.

¡Arrrgh! Llevo elucubrando acerca de este proyecto desde hace muchos meses de modo que ahora doy el pistoletazo de salida para contribuir, modestamente, a formar más y mejor a nuestra comunidad de desarrolladores profesionales de software con esta magnífica tecnología.

Recuerda: no somos una simple acumulación de conocimientos sbre esta o aquella tecnología, sino aquello de utilidad que somos capaces de hacer para otros con ellas.

Este comienza a convertirse en uno de mis mantras favoritos: "refactorizar o morir".

Recientemente he vuelto a poner en práctica una de las mejores virtudes de realizar este tipo de trabajo continuamente. El resultado finalmente es muy satisfactorio después de muchos momentos tipo "esto está quedando fatal", "así sólo voy a llegar a una solución muy enmarañada", etc. El desánimo cunde rápido, sobre todo si se trata de un pequeño proyecto que haces a ratos por las noches o fines de semana.

No obstante, una mínima tenacidad (y seguramente tirarlo todo a la basura y volver a empezar en algún momento), te hace llegar a una buena solución que no sólo funciona, sino que además es ampliable y evolucionable con cierta facilidad.

Se habla mucho de productividad; para mí es muy sencillo describir qué es productivo y qué no en software: las soluciones fáciles son más productivas que las inextricables que sólo pueden entender sus autores, aquello que nos permite ganar velocidad de desarrollo es más productivo y con ello conseguiremos más con menos esfuerzo. Nada más. Así de contundente y simple.

Hay quienes se procupan de mejorar el código de una aplicación en alguno de sus aspectos en algún momento del trabajo: al final, cuando ya todo funciona, de vez en cuando... Sin embargo, las ventajas de incorporar estas tareas de mejora en todo momento no siempre se aprecian como productivas, mucho menos cuando nos acercamos peligrosamente a las fechas de entrega y comenzamos a dejar cabos sueltos (de los que nos acordaremos sin duda semanas o meses más tarde).

¿Por qué refactorizar cuando lo importante de una aplicación es que le funcione al cliente? Buena pregunta, y al mismo tiempo, ingenua. Quienes aún no ven claro las virtudes de invertir tiempo en este trabajo, deben saber que lo primero que se gana es velocidad de desarrollo, por tanto, productividad.

La velocidad con la que desarrollamos cualquier pieza de software viene a ser una medida de la productividad, sobre todo cuando ésta nos acerca al objetivo de entregar las funcionalidades que nos piden.

Tenemos que perseguir que el diseño o la estructura de la solución que vamos construyendo, con el tiempo nos permita avanzar más rápido y no lo contrario.

En esa aplicación en la que llevo trabajando un tiempo he ido aplicando continuamente todas las técnicas de mejora posibles: simplificaciones, abstracciones en clases de utilidad, mejora en la estructura de la solución, modularizaciones, etc, de modo que cada dos semanas he podido ver cómo el código de un commit de hace quince días no tenía nada que ver con el del último. Esto cobra especial relevancia cuando desde el principio no tenemos claro cómo vamos a implementar ciertos aspectos de la aplicación un poco complicados.

A medida que avanzamos en la solución y gracias a que aplicamos todo ese trabajo de mejora, vemos cómo poco a poco va surgiendo (emergiendo) un diseño cada vez mejor. "Mejor" es una palabra muy subjetiva y difícil de consensuar entre dos o más personas. Para mí, en software, algo es mejor si te permite desarrollar más rápido (invertir menos tiempo en la misma solución) sin perder calidad en todos los aspectos de esta.

Ese diseño elegante, sencillo, correcto, es el que nos permite a partir de un punto ganar velocidad. Llega un momento en que esto es así y es entonces cuando te das cuenta de que todo ese trabajo de mejora ha sido en realidad una buena inversión de tiempo que ahora se va a amortizar. Es como si tuviéramos una madeja de hijo que al principio cuesta mucho desenredar hasta que llega el momento en que es fácil y rápido sacar más y más hilo de ella.

En ese proyecto en concreto que estoy realizando, ha llegado un momento que he conseguido resolver todas esas partes más difíciles de manera tan sencilla y elegante que ahora lo que me queda es decorar el resto hasta finalizar la aplicación. Esto no habría sido posible si no me hubiera parado al principio con esa idea de mejorar la aplicación en todos sus aspectos.

Los comienzos de una aplicación en la que hay muchas dudas que resolver son duros, cuesta apreciar verdaderamente avances y tenemos la tentación de tirar por lo rápido y fácil, sin darnos cuenta que ese camino se volverá en nuestra contra con el tiempo.

Llega un momento en que esa mejor arquitectura y diseño para nuestro propósito es tan maduro que ya sólo nos queda seguir esa coherencia para terminar la aplicación con éxito.

Lo mejor, además, es que llegaremos al final con una solución limpia y fácil de mantener y evolucionar.

Algunas de las técnicas que he empleado hasta el momento son las siguientes:

  • A medida que el código crecía, he ido adaptando la estructura y distribución de este mucho mejor.
  • Clases largas las he ido abstrayendo en clases más concretas y sencillas con una relación lógica entre ellas (principio SRP).
  • Duplicidades las he aislado correctamente en sus servicios correspondientes (el frontend está basado en AngularJS).
  • He ido buscando continuamente todo aquello inyectable, es decir, todas aquellas dependencias que se podían sacar para implementar Inyección de Dependencias.
  • He simplificado muchos bloques de código similares con sus correspondientes funciones de utilidad.
  • Métodos de más de tres o cuatro parámetros los he ido simplificando.
  • y un largo etcétera.

Al final, todo este tipo de trabajo constituye un entrenamiento por el que terminas haciéndolo de la manera más natural y ni te planteas conscientemente el realizar esas actividades como algo separado del trabajo de desarrollo, sino como algo consustancial al mismo.

Sin clientes, ¿a quién le venderíamos nuestros productos o proyectos software?

Esto es evidentemente una obviedad, es una desfachatez siquiera comentarlo; sin embargo, no siempre tenemos a esos mismos clientes en cuenta para escucharles y que en cierta medida nos ayuden a mejorar todo aquello que hacemos y cómo lo hacemos.

Por lo general, no programamos o trabajamos en un proyecto cuyo cliente o usuario vamos a ser nosotros mismos, sino que siempre, de algún modo, vamos a realizar algo para que lo utilicen otros. No entiendo, por tanto, por qué no se trabaja intensamente con una actitud de escucha y recopilación activa de sugerencias y críticas para mejorar aquello que hacemos.

Es cierto esa frase ya clásica en software que dice que "el cliente no sabe lo que quiere" hasta que se le comienza a enseñar algo de esa nube abstracta de funcionalidad y requerimientos que pide. Pocos, muy pocos proyectos, comienzan con una definición clara y exhaustiva de requisitos. Por tanto, lo más normal (y natural) es que el cliente o nuestros usuarios comiencen a matizar y a solicitar nueva funcionalidad cuando ya por fin tiene algo entre manos que tocar y usar.

Esto no es malo, no hemos hecho nada erróneamente: sencillamente es lo habitual. Hay que vivir con ello y sabiéndolo, anticiparemos posibles problemas por desviaciones en tiempos y esfuerzos.

En realidad, esa falta de definición inicial es una gran ventaja si la sabemos usar correctamente.

Independientemente de quien esté más en contacto con tu usuario final, es imporantísimo para mejorar todo aquello que haces escuchar activamente las sugerencias, opiniones y críticas (positivas o no) de quienes en definitiva están usando el resultado de tu trabajo.

¿Y para qué? Sólo de esa manera vas a obtener una información muy valiosa:

  • Entenderás mejor las necesidades específicas del cliente.
  • Comprenderás mejor cómo este usa el producto.
  • Manteniendo una actitud abierta, podrás recibir sugerencias de mejora que nunca se te habrían ocurrido.

En definitiva, dejas que los usuarios de tu producto (que además pagan por él directa o indirectamente) lo moldeen en cierto sentido para ajustarse mejor a las necesidades que tienen.

Como desarrolladores, en ocasiones se nos olvida que no programamos un producto o proyecto para nosotros mismos, sino que lo hacemos exclusivamente para que otros lo usen para resolver algún problema en particular. El cliente o usuario, en definitiva, es quien tiene la última palabra para validar si lo que se le entrega está bien, mal o es una solución más bien mediocre. Sin usuarios contentos, no hay producto (obviedad), y tampoco nadie que pague por nuestro trabajo (otra obviedad).

No siempre es fácil reconocer que algo en lo que se ha estado trabajando mucho tiempo, al final no sirve para nada (porque ningún usuario lo utiliza). Tampoco solemos tener una actitud suficientemente abierta como para encajar críticas que nos suenan negativas.

En el último año he tenido experiencias al respecto bastante buenas. Desde hace tiempo, uno los productos que comercializamos en la compañía para la que trabajo (y cuyo desarrollo lo he liderado yo desde el primer momento) ha evolucionado y crecido, básicamente, con el feedback activo de nuestros clientes consolidados que lo utilizan.

¿Resultado?

Me gustaría pensar que hemos ganado con esta actitud activa de escucha lo siguiente:

  • Reconocemos todas aquellas mejoras que el cliente necesita en su día a día.
  • Este feedback en realidad es una información valiosísima que nos permite generar un producto más cercano aún a las necesidades de ese mercado en particular.
  • El cliente se siente valorado al tenerse en cuenta sus sugerencias.
  • El producto evoluciona, por tanto, los clientes sienten que están usando (y pagando) un producto que mejora con el tiempo.

Del mismo modo, es difícil a veces saber identificar aquello que ese cliente solicita y que es muy particular y específico de aquello que realmente se puede incorporar como nueva funcionalidad útil al producto.

Esto es realmente lo que se persigue con una aproximación lean al sacar nuestros productos, tal y como lo describe Eric Ries en su libro El Método Lean Startup.

Son muchas las experiencias que se cuentan sobre la aproximación MVP (minimum viable product) para la generación de nuevos productos y la validación de ideas. Es decir, antes de dedicar mucho esfuerzo al desarrollo de algo que crees que va a funcionar, primero sacas un simple (y barato) prototipo para que lo valide tu entorno más cercano (que perfectamente pueden ser amigos y familiares). Con la información que recabes de ellos vas a validar tu hipótesis sobre la idea inicial o no; en caso negativo, también tendrás suficiente información como para abandonar esa idea (porque a nadie le interesa) o pivotar, es decir, evolucionarla para ajustarla mejor a una base mayor de posibles usuarios o clientes.

Podemos ser magníficos desarrolladores de software y crear soluciones limpias, evolucionables y maduras, pero si nadie las usa, entonces todo quedará en un bonito e inútil ejercicio o pasatiempo de fin de semana (con muchas horas de esfuerzo derrochadas e inútiles). De ahí que me interesen tanto todos esos aspectos que rodean el éxito de un producto software, sea éste del tipo que sea, una aplicación pesada de escritorio, un portal web o una aplicación móvil.

Recientemente me he acordado mucho de esto al leer Vender es Humano (de Daniel H. Pink); este es un libro muy interesante que recomiendo y que considera la venta como algo consustancial a cualquier actividad que realizamos. Todos, en el fondo, somos vendedores de algo, es decir, necesitamos usuarios o clientes que paguen por lo que hacemos. Venderemos más y mejor si además mantenemos una actitud abierta de escucha y si alentamos y recibimos con agrado cualquier tipo de feedback.

Durante el trabajo escribiendo El Libro Negro del Programador y después de su publicación (hace ya medio año), he recibido multitud de mensajes, sugerencias y observaciones. Todos esos comentarios me ayudaron (y lo siguen haciendo) a mejorar lo que hago, pero algunos de ellos me dieron bastante que pensar.

En concreto me indicaban que por fin se escribiera afortunadamente en castellano un libro en el que se recogieran el tipo de experiencias que trato en él y se hablara explícitamente de clean code, refactorings, etc, lo que me chocó bastante con la suposición de que los desarrolladores de software, programadores, analistas, informáticos en general, tengan un dominio suficiente del inglés como idioma en el que se encuentra gran parte de la literatura técnica que abarrota nuestras estantarías.

Pues bien, esa suposición no es del todo cierta y muchas veces lo que se pretende es poner en el currículum lo que se espera poner en él. ¿Habéis visto alguna vez un currículum en el que alguien no ponga eso de "nivel medio de inglés hablado / escrito"?

Unos meses atrás tuve en la oficina donde trabajo dos becarios que durante un tiempo hicieron con nosotros sus prácticas. Reconocían que les costaba mucho leer en inglés y que además preferían mil veces leer posts o libros en español.

No estoy hablando de que se ignore que nuestra profesión esté dominada por el inglés y que si queremos ofrecer nuestros servicios en un mercado global, necesariamente, sí o sí, hay que hacerlo en ese idioma. De lo que se trata es de reconocer que existe un enorme vacío de contenidos técnicos de desarrollo de software de suficiente calidad y de prestigio en nuestro idioma materno, y precisamente por ello existe una gran oportunidad para llenarlo.

En mi opinión, la razón por las que no existe un mercado auténticamente desarrollado de literatura técnica en castellano escrito por y para hispanohablantes (y no simples traducciones que en ocasiones son muy defectuosas y caras) es que no asociamos la estrecha relación que existe entre ser bueno o muy bueno en tu profesión y dedicar parte de tu tiempo a enseñar a otros sobre lo que mejor sabes hacer.

Nos falta dedicar más tiempo a enseñar y hacerlo como algo natural y como parte de nuestra profesión.

Como se suele decir, no sabes algo hasta que no eres capaz de explicárselo a tu abuela. Esta semana sin ir más lejos, le estuve mostrando a mi hija mayor cómo hacer un sencillo programita con javascript (en NodeJS) para sumar y restar, y reconozco que me costaba mucho trabajo explicar cosas para mí tan fundamentales de la programación que casi no reparamos en ellas. Entre otras cosas, me preguntaba que si para hacer ese programa para sumar se necesita otro programa (el editor de texto más el que lo ejecuta, y a su vez estos se hacen con otros programas), entonces ¿quién hizo el primer programa?...

Desafortunadamente, me encuentro con que muchos de los que sí escriben algo en forma de posts, aparte de que no les dan una continuidad y a los pocos meses el blog está completamente abandonado, lo hacen porque se sienten un poco obligados a hacerlo o para obtener cierto tipo de prestigio..., pero no por una vocación auténtica de enseñar o compartir.

Nos falta una auténtica cultura de compartir aquello que mejor sabemos hacer, sea esto lo que sea para cada uno. El conocimiento, si se guarda tras una coraza, termina devaluándose, cuando en realidad se amplía al compartirlo con otros. Estoy convencido de que existe una relación entre tu solvencia técnica y tu capacidad de mostrar y enseñar lo que sabes hacer bien.

Ya escribí en El Libro Negro del Programador un capítulo relacionado y titulado "Esclavo de tu propia solución o cómo querer ser imprescindible", acerca de cómo en entornos laborales en donde la competencia entre tus propios compañeros es palpable, se tiende erróneamente a intentar crear tu propia parcela de dominio (y que con el tiempo termina convirtiéndose en una auténtica jaula perdiento oportunidades).

Personalmente he aprendido mucho más escribiendo y compartiendo los capítulos del libro que si sencillamente nunca me hubiera parado a escribir sobre esos temas.

Se aprende leyendo libros, claro está, viendo videos, hablando sobre los temas que te interesan, pero también escribiendo, lo que es una aproximación distinta a ese conocimiento pero que te permite profundizar en él.

La percepción que tengo es que es un buen momento para liderar proyectos y escribir en castellano textos de calidad relacionados con tecnologías software. Afortunadamente, ya no hace falta contar con el premiso de ningún grupo editorial para que la obra, si es buena, se divulgue rápida y viralmente por Internet y te permina tener éxito.

Del mismo modo, creo que existe un gran número de desarrolladores de software que no dominan el inglés suficientemente y que si contaran con mejores contenidos en español, tendrían entonces una mejor formación y motivación para ser aún mejores en su profesión. Lo que quiero decir es que si el mundo anglosajón cuenta con muchos más proyectos de éxito (y más sonados) y en el mundo hispanoparlante no, puede estar relacionado con la ausencia de contenidos formativos de calidad en nuestro idioma.

¿Oportunidad? ¿Posible fuente de nuevos proyectos? Quién sabe, pero desde luego lo que sí es cierto es que si existiera un magnífico portal en nuestro idioma como sitepoint.com, con buenos contenidos, por poner un ejemplo, muchos de sus usuarios hispanoparlantes no dudarían en usarlo.

Ningún gran proyecto avanza significativamente de un día para otro. Todo, absolutamente todo, se realiza después de finalizar cientos de tareas aparentemente pequeñas.

Me gusta ver los proyectos de esta forma: como un conjunto de tareas de pequeña dimensión que se pueden hacer en cualquier momento pero que cuando nos damos cuenta, su suma nos permite obtener un buen resultado, algo apreciable.

No en vano todas aquellas personas que aparentemente consiguen muchas cosas son las que precisamente saben cómo dividirlas en pequeñas tareas y que además mantienen la disciplina de ir realizándolas poco a poco. Dividir en tareas y tener la disciplina de realizarlas, para mí aquí está la clave para conseguir buenos resultados.

No es fácil dividir cualquier asunto en partes que se puedan realizar discontinuamente; sin embargo en eso consiste también la capacidad de afrontar en el día a día muchas responsabilidades de naturaleza distinta.

¿No es así acaso como programamos o desarrollamos un proyecto software? Quizá estamos acostumbrados a dividirlos por fases, requisitos o historias de usuario, en esencia es lo mismo. Dividimos algo grande en paquetes ordenados de modo que cuando la mayoría comienzan a estar terminados y colocados en orden, comenzamos entonces a ver un resultado tangible.

The Compound EffectHace un tiempo leí un pequeño libro que trataba precisamente de esto: en El Efecto Compuesto de Darren Hardy se afirma que todo lo obtenemos como resultado de pequeños pasos pero que se acumulan con el tiempo, desde la creación de buenos hábitos hasta cualquier proyecto personal. Esta percepción va en contra de la tendencia habitual de querer obtenerlo todo rápido y sin esfuerzo. La mayoría de las cosas no funcionan así: detrás de muchos proyectos que admiramos, sin parecerlo, existe un enorme trabajo por detrás, tanto de puesta en marcha como de planificación, organización, de marketing, etc.

A veces te sientes abrumado porque tienes en marcha muchas asuntos de naturaleza distinta: la clave para asumirlos y que terminen con éxito es saber dividirlos en pequeñas tareas y priorizar su realización con una buena organización. 

No sé si de la mejor manera posible pero así yo llevo años emprendiendo fuera de mi trabajo full-time intraemprendiendo en el mismo, sabiendo que ciertas cosas van a llevar mucho tiempo pero que si no se realizan paso a paso y poco a poco, desde luego que se quedarán por el camino y además con un buen varapalo de frustración.

Entre las muchas cosas que tengo en marcha, tengo un proyecto entre manos que seguramente vea la luz dentro de un año; la forma de realizarlo, en este punto del post ya debe ser evidente: identificando multitud de tareas que puedo escalar en el tiempo. Algunas me llevan media hora, otras un par de horas cuando sé, quizá una tarde de sábado, que tengo ganas y tiempo para meterme de lleno en ellas. Eso sí, todas las semanas termino 100% las que la semana anterior me he propuesto, aunque me quite horas de sueño (= disciplina). De este modo, desde el verano en que lo comencé, ya empiezo a tener cerca el momento de liberar un MVP (minimum viable product) que me permita contrastar en mi entorno cercano (incluida la compañía para la que trabajo) su viabilidad o utilidad.

El trabajar de este modo en cualquier entorno, en tu día a día en tu empresa o en cualquier proyecto personal, tiene además las siguientes ventajas que no son fáciles de apreciar al principio:

  • Dividir cualquier trabajo en pequeñas tareas te sirve para valorar en cierta medida el esfuerzo que se va a necesitar para terminarlo.
  • Te permite planificar y organizar mejor.
  • Saber qué tareas son más importantes en relación con otras menos relevantes: puedes priorizar.
  • Si se está poniendo en marcha alguna nueva idea, el traducirla en tareas te permite definirla, afinarla y pulirla mejor.
  • Se genera una gran satisfacción al terminar una tarea: tienes sensación de progreso.

El día sólo tiene 24 horas, de ella trabajamos durante una parte y de esa parte se suele perder demasiado el tiempo por no tener un conjunto claro de tareas en las que avanzar. En la batalla del día a día es difícil ver las cosas con una perspectiva a más largo plazo, de ahí que el progresar en las responsabilidades mediante tareas más pequeñas e individuales nos permita aumentar la productividad (que no es más que hacer más en menos tiempo).

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.

Páginas

Mis libros en todas las tiendas:

Amazon
Google Play
Apple
Kobo
Barnes and Noble
Scribd
Smashwords
Payhip
Gumroad

Rafael Gómez Blanes Rafael Gómez Blanes
¿Hablamos?

 

Trabajo en...

Archivo

Mis novelas...