Pienso que debemos dedicar parte de nuestro tiempo a ayudar a los demás y que esto lo podemos hacer de muy diversas formas. Es más, cuanto más sepamos ayudar a otros, en el sentido que sea, seguramente mejor nos irán las cosas y hasta puede que mejor nos sintamos con nosotros mismos. Por lo menos yo pienso así.

Para ello, hay muchas formas, tantas como se te ocurran: colaborando, escribiendo posts en tu propio blog, participando en proyectos colaborativos y desinteresados en GitHub, realizando mentorías o incluso escribiendo libros cuando crees que tienes algo que aportar a tu comunidad.

También pienso lo siguiente: Si algo me ha funcionado a mí, ¿por qué no contarlo para que otros se beneficien?

Por esa razón fundé Hub de Libros, para que todos esos autores que escriben tengan fácil acceso al mundo de la publicación y que puedan difundir su trabajo por casi todo el planeta y no tengan los obstáculos que yo tuve (y que superé dolorosamente con mucha prueba y error) desde el año 2012, porque sé que muchos se quedan por el camino provocando que, quizá, información o conocimiento muy valisosos queden olvidados en el fondo de un cajón, o porque creen aún que para contar algo y empaquetarlo en un formato libro se necesita del permiso de una editorial de toda la vida (como diría Julia Cameron), en el siglo de la tecnología y de modelos disruptivos como Uber, Etsy, Airbnb y muchos otros.

Del mismo modo, describir a nivel técnico cómo he enfocado un proyecto software tan ambicioso como complejo como Hub de Libros, me ha llevado a trabajar en los últimos meses en El Arte del Emprendedor Digital, mi nuevo libro con el que espero ayudar y animar a toda esa comunidad relacionada con la tecnología y con ganas e inquietud de emprender o de lanzar nuevos proyectos.

Parece ser que vivimos con una dinámica en la que todo el mundo está demasiado ocupado, desde que nos levantamos hasta que nos acostamos.

Pero yo me pregunto lo siguiente: ¿Ocupados en qué?

Para mí la primera medida del éxito consiste en permanecer ocupados, al menos la mayor parte del tiempo, en aquello que nos interesa y en la dirección de nuestras metas a largo plazo y, por supuesto, mantener una vida equilibrada en todas sus áreas.

Sin embargo, he descubierto todos estos años, cruzándome con CEOs, CTOs, gerentes y muchos otros desarrolladores, que se confunde demasiado el estar ocupado con trabajar productivamente y, de ahí, a un paso tenemos una vida llena de estrés y sin saber cómo mejorar.

Esto es, no se trata de trabajar más horas sino de trabajar mejor.

Desarrollar un proyecto como Hub de Libros (y otros anteriores junto con aquellos en los que participo actualmente), consiste también en cierta forma de enfocar el trabajo y de hasta mantener ciertas habilidades de desarrollo personal.

Por esa razón, en El Arte del Emprendedor Digital no solo describo los aspectos técnicos más relevantes de algunos de mis proyectos en marcha, sino también de todas esas técnicas y habilidades que a mí me han servido para poder concentrarme en un trabajo tantas horas y durante muchos meses compatibilizándolo con el resto de mis responsabilidades: desde kaizen hasta las microtareas, la importancia de conseguir concentración, fluir y hasta cómo gestionar las dudas, y un largo etcétera.

Inevitablemente, este nuevo libro tiene, por tanto, un carácter algo personal e intimista, que no me importa compartir puesto que pienso que su contenido puede ser de mucha utilidad a tantas personas que quieren avanzar en sus proyectos o que quieren emprender con la mayor probabilidad de éxito, y del mismo modo, me he tomado la libertad de describir en el mismo libro aspectos técnicos (muy técnicos, de hecho) junto con herramientas de desarrollo personal, porque, en definitiva, por muy buen técnico que se sea, por muy buena la idea que quieres implementar, si no dominas estas últimas estrategias de carácter personal, el camino será mucho más difícil, si es que no se abandona nada más dar los primeros pasos.

Yo abandoné en algunas ocasiones, fracasé en otras, pero también he tenido éxito en muchos otros proyectos, aunque ahora comprendo que lo primero no es más que una fuente de aprendizaje para seguir avanzando.

El Arte del Emprendedor Digital me lo prologa nada más y nada menos que José Murillo, compañero durante algunos años en mi primera etapa laboral y quien después trabajó para Microsoft durante más de quince y que desde hace dos años es el CEO de su propia compañía (Smart IoT Labs).

No sé si el movimiento startup y todo lo relacionado con el emprendimiento (tan de moda últimamente) serán o no el corazón de la nueva economía a la que nos dirigimos, pero de lo que sí estoy seguro es de que aquellos que trabajamos con la tecnología lo tenemos más sencillo para lanzar proyectos que aquellos que trabajan en otros sectores.

En El Arte del Emprendedor Digital describo cómo he afrontado Hub de Libros y cómo se plantea la evolución de un proyecto con metodología lean, junto con los elementos más importantes y paradigmáticos que debe cumplir un proyecto software que va a cambiar continuamente y que desde su comienzo, ni siquiera tenemos claro cómo será esa evolución, entre otros muchos temas.

Confío en que este nuevo trabajo que he realizado con tanta ilusión (y esfuerzo), y que es de los primeros títulos editados por mi propia plataforma editorial, sea de utilidad tanto o más como mis anteriores libros.

Recientemente he publicado en un único ebook los tres libros técnicos que he escrito hasta el momento, dándole el nombre de La Trilogía del Programador Profesional.

En cierto modo, tanto El Libro Negro del Programador, El Libro Práctico del Programador Ágil y The Coder Habits, forman una unidad en su conjunto aportando tanto esa meta visión acerca de nuestra profesión como desarrolladores de software, pasando por las buenas prácticas técnicas y hábitos como programadores profesionales.

Es difícil encontrar gran parte de ese conocimiento, menos aún en castellano, extraído de mi propia experiencia, reunido en un único trabajo.

Me ha parecido práctico reunir los tres libros en uno solo para así facilitar su lectura y adquisición.

He añadido, además, una introducción a este nuevo pack después de lanzar uno de mis proyectos más ambiciosos.

La Trilogía del Programador Profesional

 

 

Hub de Libros

Un artículo de Rafa G. Blanes

Desde hace unas semanas ya lancé oficialmente un proyecto en el que he trabajado con mucha ilusión y que en algunos aspectos ha sido todo un reto técnico. Toca aquí más hablar de estas cuestiones técnicas que del proyecto en sí. Pero antes, un poco de historia personal...

En 2014 publiqué mi primer libro (El Libro Negro del Programador) y desde entonces no he parado de tener siempre un proyecto literario en marcha, de tipo técnico, novela o relatos cortos. ¿El resultado? Seis libros, cuatro relacionados con el desarrollo de software profesional y dos novelas (éstas bajo el seudónimo de G. Blanes), perto también conocer con detalle todo lo relacionado con la publicación independiente (o indie) y hasta considerar mi trabajo como escritor como un área más de mi profesión.

Para los que aún no lo sepan, ya no hace falta que una editorial "de toda la vida" te elija para que puedas publicar tu libro, y mucho menos venderlo en cualquier parte del mundo. Internet ha permitido explorar miles de nuevos modelos de negocio y el mundo editorial no puede quedarse al margen de ello. Esto es, en cierto modo, se ha democratizado la posibilidad de publicar (ya no se necesita el permiso de nadie para hacerlo).

Me sorprende (y digo esto a modo de reflexión personal), esa extraña áurea que rodea la imagen de un "escritor", y que algunos se sientan bendecidos y pontificados por una mano mágica que los diferencia del resto de los mortales, algo que no ocurre en otras profesiones. Es cierto que siempre habrá buenos pintores y malos, buenos programadores y peores, y por lo tanto, también excelentes escritores que ganan El Nobel y muchos otros aficionados. Sin embargo, hay espacio para todo el mundo que tenga inquietudes creativas, en cualquier área. No en vano, cuántos artistas consagrados hoy en día fueron rechazados en su época, como pareciendo que hace falta morir para que valoren tu trabajo...

Autores cuyas obras nunca habrían visto la luz por no encajar quizá en los intereses comerciales o de nicho de las editoriales tradicionales, pueden ahora dar a conocer su trabajo gracias a la tecnología. Otros, ya consagrados, se pasan a la publicación independiente porque genera más libertad y mayores royalties, qué duda cabe.

No hablo solo de autores de "literatura", sino de cualquier tipo y  género: de desarrollo personal, técnicos, etc. Es más, me atrevo a decir que en nuestra profesión, se echa en falta más y mejor literatura técnica en castellano, quizá porque muchos desarrolladores no exploran ese camino.

No me gusta la expresión publicación independiente, que es tanto como decir, si existiera alguna similitud con otras actividades, escultor independiente, pintor independiente o hasta programador independiente. Suena raro, ¿verdad? ¿Acaso hay que etiquetar de algún modo el hecho de que tú seas el responsable de tu publicación a diferencia de que exista cierta entidad que te "da permiso" para dar a conocer tu trabajo?

Si bien hace diez años quien no conseguía que le publicaran terminaba "autopublicándose", y el término "independiente" se asociaba más a aquellos materiales que no encajaban en las tendencias más clásicas y comerciales de las editoriales, hoy día todo esto ha cambiado radicalmente.

Es más, hoy día la tendencia comienza a ser ésta, incluso autores que vienen "del otro lado", como Matilde Asensi y Raimón Samsó, pasan parte o todo su trabajo a este modelo. ¿Por qué? Por la misma razón por la que Airbnb le permite a los dueños de apartamentos rentabilizarlos mejor o aquel proveedor de suministros decide abrir una tienda en Amazon y llegar a más clientes: porque la tecnología lo permite a un coste mínimo y de escala y porque así tienes el control total de tu activo (sean productos o servicios).

¿Y qué pasa con la labor insustituible que es necesaria para generar un libro de calidad? Estoy hablando de revisar, corregir, diseñar la portada, maquetar el contenido, la promoción, el markenting, etc. Todo eso, qué duda cabe, un trabajo duro que hacen las editoriales, ahora se puede subcontratar, si quieres, a quien quieras y cuando quieras. De esto hablaremos un poco más adelante.

Esto es, publicar de forma independiente consiste básicamente en que tú haces tu trabajo de escribir, pero también te encargas de obtener la portada, maquetar tu libro, revisarlo hasta la saciedad y publicarlo directamente en plataformas como Amazon, Google Play, Kobo, etc. O bien le encargas a otros profesionales ese trabajo por un precio razonable. En cualquier caso, tú tienes la libertad y el control (y los derechos de autor) sobre tu obra, y que sean los lectores únicamente los que tengan la capacidad de juzgarla.

Porque esto es lo que yo pienso y creo: Igual que leer es un Derecho, opino que Escribir también lo es (como dirían Julia Cameron en su libro El Camino del Escritor o Natalie Goldberg), de modo que nadie te puede impedir hacerlo, tanto si consigues rentabilizarlo como si no, de ahí que haya creado Hub de Libros como Plataforma Editorial de Publicación Abierta.

Leí recientemente que más de un ochenta por cierto de la población estadounidense ha deseado en algún momento de su vida escribir un libro. La mayoría no lo hace. 

La diferencia es que ahora es posible a menos que te lo propongas.

¿Y qué pasa con la calidad? Sí, así también cualquiera puede publicar un bodrio (que no va a ser leido por casi nadie, por cierto) o bien una auténtica joya. Pero también puedes mejorar tu texto en cualquier momento (como hago yo cada vez regularmente sobre mis libros), cambiarles el precio, etc.

En cualquier caso, la última palabra la tienen los lectores, solo ellos van a indicar la valoración sobre tu trabajo. 

Pues bien, detrás de toda esta historia y de cierta inquietud personal al afirmar que Escribir es un Derecho que tenemos, está Hub de Libros y la Plataforma Editorial de Publicación Abierta. Es un site donde los lectores pueden encontrar nuevos contenidos pero, sobre todo, nuevos autores y los escritores pueden crearse su propio perfil y publicitar sus trabajos. 

He creado Hub de Libros para que los autores que quieran publicar, lo puedan hacer sin los problemas técnicos que yo tuve en su momento y que fui superando con mucho esfuerzo, prueba y error.

También creo en la economía gig, en la que cada vez más y más profesionales pueden ofrecer sus servicios a cualquier cliente de cualquier parte del mundo, como se hace a través de Fiverr y muchos otros portales. Para ello Hub de Libros dispone de una serie de gigs o servicios que cualquiera puede contratar relacionados con todo lo necesario en el proceso de creación de un libro.

Hub de Libros también es un reto técnico, y me propongo hablar de todas las estrategias que he empleado en él y que permiten que sea una plataforma diseñada para crecer y ser evolucionada fácilmente mediante Mantra Framework, otro proyecto propio en NodeJS en el que comencé a trabajar hace ya dos años en base a mi experiencia de haber lanzado proyectos muy escalables (que soportan un gran número de usuarios y manejan un volumen de datos muy alto), para lo cual hacen falta estrategias de diseño y arquitectura que nada tienen que ver con una aplicación de tamaño pequeño o mediano.

Es cierto que existen otros frameworks muy maduros y con una buena acogida, como NestJS, pero ciertas consideraciones técnicas a largo plazo me llevaron a concretar el desarrollo de Hub de Libros en un framework propio fácilmente evolucionable. En los siguientes puntos entendrás por qué.

Estas son varias de las claves técnicas sobre las que se asienta a nivel de software Hub de Libros:

Ahora que en mi país y muchos otros se imponen medidas drásticas para frenar el COVID-19, muchos empleados están obligados a trabajar desde sus casas por primera vez en sus vidas. Algunos estarán aterrados (no por el virus, sino por trabajar en sus casas), y otros sentirán que están ante una gran oportunidad.

Lejos de lo que pueda parecer, teletrabajar puede suponer todo un reto no solo por cuestiones de conciliar la vida familiar y profesional: teletrabajar es algo que va mucho más allá que cambiar el lugar donde realizas las tareas para tu compañía.

Llevo trabajando en remoto varios días a la semana desde hace años, desde el momento que concebí que mis responsabilidades laborales eran compatibles perfectamente sin necesidad de estar presencialmente en una oficina. Hasta ahora, puedo decir que ha sido una de las mejores decisiones de mi vida. Sin embargo, tengo que reconocer los cambios profundos que esta forma de encarar el trabajo, impactan en la forma de organizarlo (para mí y para el resto de mis compañeros).

Puedo afirmar que en mi caso soy más productivo, me siento tanto o más a gusto en mi despacho y el hecho de no estar atado necesariamente a un horario, me permite emplazar las tareas de un modo más ágil y eficiente en el día a día, pero para ello, es todo un reto saber desconectar, al tiempo que hace falta una gran autodisciplina.

Puede que ahora muchas empresas descubran que ofrecer a sus empleados esta opción, supone un ahorro de costes. Por su parte, puede que los trabajadores también descubran que pueden ahorrar en desplazamientos, trabajar mejor y hasta ser más productivos, etc. Pero también puede ocurrir todo lo contrario.

Teletrabajar no es sencillo, no es para todo el mundo (ni para todas las compañías, obviamente, aunque el trabajo se realice a través de un ordenador).

Trabajar remotamente supone utilizar un paradigma laboral (y mental) diferente, así como de una autodisciplina que hace falta desarrollar y que no todo el mundo está dispuesto a pagar el precio para adquirir.

Teletrabajar supone, además, organizar el trabajo de un modo diferente, de modo que implica cambios en la forma de actuar de los managers y responsables y también de los equipos de trabajo.

Esta forma de afrontar el trabajo es incompatible con aquellos perfiles que necesitan que se les diga qué hacer en todo momento o que trabajan y se implican más cuando "el jefe" está presente, es decir, el teletrabajo no funciona con aquellas personas que:

  • No saben organizarse a sí mismas su jornada laboral, preguntándose continuamente eso de ¿y ahora qué hago?
  • No se sienten implicadas en la organización para la que trabajan.
  • Hacen lo mínimo para salir adelante (y, curiosamente, hacen más cuando hay más presión sobre ellas).

Del mismo modo, si una compañía (y hablo de las tecnológicas) cree que su actividad se puede descomponer en una serie de tareas que alguien las realiza, una tras la otra, puede que se lleve una gran decepción.

El teletrabajo es para compañías que confían en personas autoresponsables y empleados que fomentan la buena realización de las tareas. Trabajar en remoto no tiene nada que ver con el esquema tradicional de "jefe dice qué hacer, y empleado lo hace y punto".

Cada vez más, las empresas que tienen más éxito son aquellas que confían en sus empleados: para crear nuevos productos, para proponer mejoras en cualquier ámbito de la organización, para hacer siempre lo que hay que hacer en el momento adecuado. Y desde el otro lado también: empleados autoresponsables y proactivos, implicados en el proyecto que supone la organización para la que trabajan.

Esto es, trabajar en remoto exige un paradigma laboral para el que la mayoría de la gente (y empresas) no está preparada (aún).

No hablo de tener en casa las condiciones adecuadas para poder trabajar, sino de una actitud mental difícil de encontrar en una cultura laboral en donde muchos miran la hora deseando salir de la oficina por falta de motivación (o porque consideran el trabajo un simple medio de ganarse la vida, lo que se suele llamar un "trabajo nutricional").

Mandar a la gente a casa con tanta precipitación (como ha pasado estos días) sin haberles preparado para teletrabajar y sin haber incluso puesto en marcha la metodología necesaria para afrontar tareas en grupo no presencialmente, puede que les lleve a muchos una gran sorpresa.

Otros, como yo hace unos años, descubrirán encantados que esta opción supone una serie de ventajas difíciles de imaginar.

Si tú gestionas tu tiempo..., gestionas tu vida. De eso va el teletrabajo en realidad, pero para ello, tu grado de implicación en tu compañía tiene que ser muy alto.

Muchas de las tareas laborales que realizamos los profesionales de IT, pueden ser realizadas en cualquier momento del día, entonces... ¿por qué ceñirse a un horario estricto? Esto ocurre así porque hasta hace bien poco la única manera de estructurar el trabajo era (y sigue siendo), de ese modo.

Las tareas que exigen creatividad y un alto grado de concentración, como desarrollar software, diseñar, escribir, etc., no pueden estar ligadas a un horario estricto; esto va en contra de su naturaleza. Se podrían hacer mejor, y con mejores resultados, si las realizamos en el momento del día que sea más adecuado para nosotros. Esto no es hacerlas cuando nos dé la gana, sino ser autoresponsables y hacerlas en cualquier caso, pero no necesariamente cuando otra persona nos lo impone.

Yo sostengo que hasta ahora no se ha teletrabajado más por una falta de confianza entre los responsables y sus equipos, y también sostengo que las compañías que superan esa barrera, son las de más éxito, porque supone que integran a personas más motivadas y autoresponsables con su actividad. Esta autoresponsabilidad consiste en que el manager saber que el equipo se responsabiliza de su trabajo y no necesita ejercer de supervisor: los resultados hablan por sí mismos.

Recuerdo la ley de parkinson: una tarea se expande tanto como el tiempo del que dispones de su realización, de ahí la necesidad de que un teletrabajador sea responsable, ya que el trabajo del manager no consiste en vigilar el patio de un colegio, sino en comprobar que las cosas se hacen bien, con calidad y en tiempo.

Es una cuestión de actitud y motivacioń: no tienen nada que ver las actitudes de una persona que "trabaja por dinero" (totalmente legítimo), que aquella que siente un significado por las horas que pasa prestando sus servicios a su organización. La primera mirará el reloj, se implicará lo mínimo, la segunda será proactiva y su trabajo será de mayor calidad.

Nunca he sido responsable de recursos humanos, pero sí he visto que los mejores profesionales con los que me he cruzado hablan de sus empresas con orgullo, los mismo para los que si hay que trabajar puntualmente un fin de semana no ponen pega porque saben que están apoyando no un trabajo, sino una causa de la que se sienten comprometidos y orgullosos.

El reto, por tanto, no es para el empleado que de un día para otro tiene que aprender a teletrabajar, sino para la empresa que tiene que crear un proyecto motivador a largo plazo que haga que la gente dé lo mejor de sí.

Y lo mejor no son eternas horas de trabajo, al contrario, sino su imaginación, ideas y creatividad. El esfuerzo sin un ideal detrás, sin una motivación, es... eso, esfuerzo; por el contrario, con una gran motivación personal y profesional, las horas trabajando dejan de ser esfuerzo.

En cualquier caso, después de estas reflexiones, con las que ya te habrás dado cuenta de que teletrabajar es más que desplazar tu oficina a tu casa y tiene más que ver con otra forma de entender el trabajo, indico a continuación algunos consejos prácticos:

  • Encuentra un lugar de la casa donde te sientas realmente a gusto.
  • Habla con la familia, indícales que mientras estés en él, que intenten interrumpirte lo mínimo posible.
  • Vístete con ropa de trabajo: parece una estupidez, pero hemos acostumbrado a la mente de que en pijama... dormimos, con esa otra ropa, entramos en modo de trabajo.
  • Sigue manteniendo un horario estructurado, sea el que sea, pero estructurado a fin de al cabo.
  • Empieza cada día con las tareas organizadas el día anterior y planifica su realización según los momentos de mejor conciliación con la familia.
  • Evita el exceso de llamadas con el resto de compañeros; para ello, emplázalos a reuniones cortas en horas concretas para tratar exactamente los asuntos en cuestión.
  • Utiliza herramientas ágiles de comunicación, pero no permitas que estén siempre activas de modo que te interrumpan continuamente.
  • Mientras trabajes, pues eso, trabaja, olvida las redes sociales y cualquier tipo de distracción.
  • Aunque esto también vale para trabajar en la oficina, trabaja lo más concentrado posible, y descubrirás mágicamente que las tareas se terminan antes.
  • Ve al grano y no pierdas el tiempo. Varios minutos en esto y aquello, hoy y mañana y pasado mañana, se convierten en muchas horas a lo largo del mes (tiempo que le quitas a otras actividades de tu vida).

No es algo difícil de alcanzar, compañías como Hotjar tienen trabajadores en remoto en treinta países diferentes y siguen adelante, publicando además su experiencia al respecto, y, quizá, ojalá, este sea el futuro de las empresas de tecnología y startups.

Kaizen es un concepto japonés que viene a traducirse por “pequeño cambio” o “pequeña mejora” que en ese país es toda una filosofía de trabajo que explica cómo una nación próspera devastada por la Segunda Guerra Mundial, volvió a emerger a partir de los años sesenta hasta convertirse de nuevo en otra potencia económica y tecnológica.

Kaizen es también una filosofía de vida y una técnica maravillosa y sencilla de vencer la procrastinación, reducir lo complejo en pequeños pasos sencillos y de mejorar en cualquier aspecto que te propongas. 

En ingeniería del software se habla del concepto de mejora continua (continuous improvement), que puede ser nuestra particular aplicación práctica de Kaizen; pero, ¿mejorar en qué? ¿para qué?, y sobre todo, ¿cómo?

Puedo decir que practico Kaizen desde hace años; sin ir más lejos, cada capítulo o sección de los libros que publico los encaro en ocasiones a ratos de veinte minutos, en otras, reviso y corrijo aquel texto que escribí hace ya un mes, y vuelvo a revisar y mejorar y ampliar el contenido en un sinfín de tareas e iteraciones que suelo anotar en aplicaciones como Wunderlist o Evernote.

Aunque considero que escribo y comparto experiencia en mis libros y artículos como parte de mi trabajo profesional, raro es el día o la semana en que puedo dedicarme a ello durante varias horas seguidas, sin interrupciones, de ahí que me obligo a mí mismo a identificar esas tareas de modo que sean cortas de realizar. Precisamente por su tamaño y poca complejidad, las hago con facilidad y sin demasiado esfuerzo, y las realizo, quiero decir, que termino haciéndolas antes que tarde. Así es como encaro la mayor parte del trabajo de redacción de un nuevo libro para compaginarlo con el resto de mis responsabilidades profesionales.

¿Y por qué termino realizando esas minitareas? No es porque trabaje más que nadie, de ningún modo, sino que sé que la mayoría me van a suponer poco tiempo y casi siempre son más o menos sencillas de implementar, esto es, son pequeñas mejoras y pequeños avances en un proyecto como escribir este artículo: Kaizen en estado puro.

Si llevas años sin correr, no te atrevas a tratar de salir a hacer cuatro kilómetros el primer día. Mejor hoy camina un rato, mañana otro, la semana que viene camina pero a un ritmo algo mayor, en dos semanas ya puedes trotar y en un mes, tan solo introduciendo pequeños cambios en esa nueva rutina básica y simple que te estás construyendo, corre por fin unos cuantos cientos de metros. Pequeños cambios y mejoras para abordar algo más complejo (como poder correr cinco kilómetros seguidos sin morirte en el intento).

Te preguntarás qué tiene esto que ver con desarrollar software...

Kaizen funciona porque nos permite evitar el boicot de nuestra propia mente cuando la enfrentamos a trabajos complejos, pesados y que requieren un gran esfuerzo (o que tampoco nos estimulan y motivan especialmente). Recuerda, nuestro cerebro está diseñado para mantenermos en una cálida zona de confort (seguridad) y le asusta cualquier cosa que nos saque de ella, aunque sabemos que de un modo u otro, aquello que queremos conseguir (esa tarea compleja) requerirá salir de esa zona de confort en forma de esfuerzo y quebraderos de cabeza.

Con Kaizen evitamos ese mecanismo primitivo de autoprotección que nos impide en muchas ocasiones mejorar (o avanzar en nuestros proyectos), y me atrevo a decir que también en nuestros propósitos vitales.

¿Acaso tiene que ver Kaizen con programar o modernizar esa aplicación heredada monolítica, fea y mal desarrollada, o avanzar en un proyecto personal para el que apenas tienes tiempo o escribir esos tests que se resisten?

Pues sí, y mucho, porque si afrontamos nuestro trabajo de ese modo, aunque parezcan tareas pequeñas, llegaremos más lejos, y lo podemos hacer practicando Kaizen: paso a paso, pequeña tarea más pequeña tarea, una minúscula mejora aquí y otra allá y, cuando nos demos cuenta, después de acumular cientos de pequeñas mejoras (o miles), nuestra aplicación comienza a brillar, a contar con un mejor diseño y a estar mejor estructurada.

Además, si trabajas en una aplicación compleja y frágil, introducir pequeños cambios nos dará la seguridad de que en caso de efectos secundarios, los detectaremos con rapidez y también será más sencillo resolverlos.

No es trabajar menos horas, sino hacerlo de manera más descansada y avanzando con más seguridad. Tan pronto como tengas que realizar algo que parece "grande", complicado y hasta pesado, tan solo tienes que descomponerlo en pequeñas tareas, cuanto más pequeñas mejor, darte una fecha e ir terminándolas una detrás de la otra.

Desarrollar buen software requiere de cuidar de muchos detalles: dos o tres pequeñas mejoras hoy, suponen decenas a lo largo tan solo de un mes y quizá miles a lo largo de un proyecto cualquiera.

Con el tiempo, me atrevo a decir que hasta desarrollas cierta "mente Kaizen", y comienzas a tirar de tu Wunderlist continuamente porque ves oportunidades de pulir esto y lo otro por todos lados.

Por último, sospecho que se es mucho más productivo afrontar el trabajo mediante periodos cortos de concentración (tal y como sugiere la técnica del pomodoro) que sentarte una mañana entera y no despegar los ojos de la pantalla, más aún cuando tienes que atender, como es mi caso, tareas de muy distinta naturaleza.

Un libro que me gustó mucho sobre Kaizen: "El método Kaizen", de Robert Maurer.

Este podría ser uno de los capítulos extra de El Libro Negro del Programador. En demasiadas ocasiones veo la siguiente dinámica de trabajo (en la que yo también, por supuesto, he caído muchas veces, aunque ya menos): trabajamos en un proyecto y nuestra principal obsesión consiste en añadir funcionalidad, nuevas características, ahora esto, ahora aquello, y así durante meses cuando creemos que estamos avanzando.

Puesto que ese es seguramente el aspecto más atractivo como desarrolladores de software, eso mismo es entonces lo que hacemos, y disfrutamos viendo crecer la aplicación con nuevas características, para nuestro gozo, disfrute y satisfacción. Por el momento, los desarrolladores contentos, el negocio y el cliente, también.

Todo "parece" ir sobre ruedas, como esas relaciones que aparentan ser la pareja perfecta pero que luego en la intimidad se tiran los trastos a la cabeza, esto es, algo hay podrido en alguna parte que terminará por estallar el momento menos pensado.

Volviendo al proyecto software, puede que no te hayas dado cuenta de lo que se está gestando y que hasta veas esa situación como normal, porque para eso nos pagan, ¿no?, para hacer que algo funcione y le dé utilidad a alguien, añadiendo más funcionalidad e implementado los requisitos.

Pero del mismo modo, sin darte cuenta, estás plantando la semilla del caos en tu proyecto, sobre todo si éste tiene una vida de muchos años e infinidad de cambios que soportar, o incluso ni sospechas el tipo de cambios que se van a exigir a medio plazo, que suele ser lo habitual. 

¿Hay algún negocio acaso que sepa de dónde va a venir su crecimiento en unos años? Son muy pocos los que pueden tener una idea de ello. Esto es, si la aplicación que construyes va a soportar a dicho negocio, no tenemos ni idea de la forma en la que va a evolucionar.

Pasa el tiempo, la aplicación o sistema crece desorbitadamente y nos encontramos viviendo en un caos constante. El crecimiento orgánico descontrolado del sistema ha creado un monstruo inmanejable.

Este caos puede venir de diferentes formas: un sistema cada vez más frágil (tocas aquí y algo se estropea allí), funcionalidad añadida con demasiada celeridad sin respetar la forma de hacer las cosas en ese proyecto (esto es, sin seguir el diseño, si es que lo hay claramente), necesidad de pasar demasiado tiempo para cambiar cualquier detalle (el tiempo es dinero, coste para el proyecto que alguien tiene que pagar), y, como por arte de birlibirloque, llega un momento en que añadir / poner / quitar algo en el proyecto se convierte en una auténtica pesadilla, y echamos de menos entonces el momento aquel en que lo comenzamos con tanta ilusión, cuando el bebé aún no se había convertido en ese adolescente rebelde e insufrible...

Al cabo del tiempo, tienes que mantener un sistema frágil, muy acoplado y con un diseño más monolítico que flexible.

Esto es: el crecimiento orgánico de un proyecto de forma descontrolada conduce a un proyecto espagueti y costoso de mantener y evolucionar. ¿El resultado? Desarrolladores frustrados y responsables que en algún momento tienen que defender ante la dirección volver a hacerlo todo desde el principio, pero "mejor". En ocasiones, hasta se defiende una nueva "versión" cuando en realidad se trata de tirarlo todo a la basura y volver a construir el sistema desde el principio.

La cuestión que quiero plantear aquí es por qué se produce esta situación insostenible, situación que he vivido trabajando con algunos de mis clientes y reconozco que no es para nada agradable.

La dinámica es bien conocida: añadir más y más funcionalidad de forma casi descontrolada porque el tiempo apremia y el negocio necesita ya toda esa funcionalidad que exige, aumentando la bola de nieve hasta que llega un momento en que ésta nos aplasta.

La forma de evitarlo es también bien conocida.

Este es un principio universal en software: el coste de actuar al final (cuando ya es demasiado tarde) es mucho mayor que actuar repetidamente a lo largo de la vida del proyecto para evitar la situación anterior.

Pero, actuar... ¿en qué exactamente?

Es lo que yo llamo realizar "paradas técnicas", sobre todo, insisto, en proyectos o productos que deben tener una vida de años.

No hay más, esta es la receta: parte de nuestro tiempo de trabajo debe enfocarse en mejorar el diseño y arquitectura de la solución.

No hablo de hacer pequeñas mejoras en el día a día limpiando esto y aquello, refactorizando aquí y allá. Hablo de pasar un tiempo dedicado exclusivamente a analizar integralmente la solución para encontrar y sintetizar mejoras que permitan su crecimiento de modo mejor y más ordenado.

Estimo que a esta actividad hay que dedicar aproximadamente un cuarto del tiempo disponible al trabajar en un proyecto de largo recorrido.

Así es, puede parecer mucho tiempo, pero mi experiencia me demuestra que este paso atrás aparente, permite después avanzar mucho más rápido consiguiendo una solución mantenible y de mejor calidad (y con menos coste).

Lo he visto: si te dedicas a añadir funcionalidad continuamente, sin pararte a reflexionar si el diseño y la arquitectura se van ajustando a ese crecimiento funcional, tarde o temprano tendrás una patata caliente sobre la que alguien tendrá que responder.

Dedica uno de cada cuatro o cinco sprints o ciclos de trabajo a asentar la funcionar ya existente (parada técnica), mejorando cualquier aspecto que creas conveniente, refactorizando aún más el diseño, mejorando la arquitectura y los procedimientos de gestión de la configuración y despliegue. Puede parecer que ese esfuerzo es un gasto (ya que no añade nada nuevo al sistema), pero el tiempo te demostrará que ese esfuerzo reducirá drásticamente los problemas en el futuro y permitirá añadir más características más adelante con menos dificultad.

Igual que la regla de pareto 80/20 (que viene a decir algo así como que el 80% de los resultados vienen de un 20% del esfuerzo), en software afirmo que el 25% del tiempo de trabajo debe dedicarse a mejorar el sistema actual para permitir su crecimiento futuro, al menos en los proyectos que deben durar años de desarrollo con una gran cantidad de cambios.

Un paso atrás (en apariencia) pero que nos permitirá dar varios adelante con mayor certeza, seguridad y calidad.

 

Comparto uno de los capítulos de The Coder Habits y cuya píldora de sabiduría, entre otras, es de las que más me gustan del libro.

Si crees que: 

  • Ser el único en tu empresa o departamento que domina o hace algo te da alguna ventaja...
  • Sentirte imprescindible te da un valor que permite mantenerte en tu puesto...
  • No compartir conocimiento entre tus compañeros te hará ser más valorado...

En definitiva, si crees que fomentar las islas de conocimiento en tu propia empresa es bueno para ti, entonces tengo que decirte que estás equivocado. Esto es como el refrán aquel que dice "pan para hoy y hambre para mañana".

Y al revés, para una empresa, nada peor que depender de algunos empleados que son los únicos que dominan tal o cual tema.

Esto es lo que creo: como profesional no te interesa ser el único que domina algo imprescindible para tu compañía (salvo que quieras dedicarte a ello el resto de tu vida...). Y al revés, para una compañía, nada peor que depender de estas personas que poseen esas islas de conocimiento.

¿Eres bueno innovando y aportando soluciones únicas? Perfecto, pero entonces haz tu trabajo, prepáralo para que lo asuman otros (delegar) y sigue desarrollando tus mejores virtudes en otras áreas y otras soluciones, puesto que es ahí donde aportas valor (y así seguirás creciendo profesionalmente).

Hasta el día de hoy, todavía no me he encontrado ninguna situación o área de conocimiento en ningún proyecto que no pueda asumir un buen profesional avispado en unas semanas. Por tanto, la sensación de imprescindibilidad (si es que existe esa palabra), es eso, no es más que una sensación.

Yo he tenido alguna experiencia dolorosa al respecto (y creo que aprendí la lección), y me temo que esta actitud personal no puede hacer más que ponerte piedras en tu desarrollo profesional, al margen de que una compañía nunca debería depender de individuos con esa concepción personal.

Por esa razón, uno de los hábitos que más me gustan (por el valor que creo que aporta) de The Coder Habits, es el 32, cuyo título es, precisamente, "No fomentes islas de conocimiento", y que quiero compartir en esta entrada.

Creer que ser el único en saber hacer algo extraordinariamente complejo o técnico te da alguna ventaja, es de profesionales ingenuos y principiantes: lo que crees que es una ventaja a corto plazo, se convierte en una pesada losa a medio y largo plazo (impidiendo que progreses en otras áreas de tu carrera al estancarte en ese algo concreto en lo que eres tan bueno...).

Aquí va el capítulo, que, como todos los del libro, es breve y va al grano.

{ #32 - No fomentes islas de conocimiento }

Este es un patrón que, lamentablemente, he encontrado a menudo y que creo que hace muchísimo daño en nuestro sector, por eso lo incluyo como un hábito (más bien un anti-hábito).


Hay quienes tienen la tentación de pensar que si son ellos las únicas personas que dominan algo en concreto en la empresa o en el departamento, los únicos que entienden sobre ese tema esencial o los únicos a los que la empresa puede recurrir para resolver tal problema, entonces tienen asegurado un puesto de trabajo (se han parapetado en él y, sin darse cuenta, están cavando su propia tumba profesional).


Estas personas están lejos de conocer lo más mínimo todas esas «habilidades suaves» («soft skills») de las que he hablado anteriormente.


Y también son personas inseguras y con muy baja autoestima, me temo.


La seguridad de un buen profesional no está en apropiarte para ti solo algo que nadie más en tu organización puede hacer, creyendo que así vas a conservar tu puesto, tu estatus o lo que sea de por vida. La auténtica seguridad consiste en saber que puedes resolver problemas porque tus habilidades y actitudes te lo permiten, nada más, de modo que el buen profesional no huye de nuevos retos (que vienen siempre disfrazados de problemas) sino que los afrontan con la energía de la superación personal.
Apropiarte de una isla de conocimiento, además de mezquino, te hace débil, porque te está impidiendo que puedas crecer profesionalmente y, créeme, cualquiera terminará dominando aquello que quieres proteger a menos que se lo proponga.


Yo caí una vez en este error (hace mucho, ¡eh!), y de hecho hablo de este episodio en «El Libro Negro del Programador». ¿Resultado? Me di cuenta de que «ser el único que sabía hacer aquello» me estaba bloqueando en la escalera corporativa y limitando mi crecimiento. Tomé nota y reaccioné a tiempo.


Visto desde otro ángulo, si tienes responsabilidades sobre un equipo, impide que existan islas de conocimiento, es un riesgo que te puede pasar factura, a ti y a tu

Este y otros hábitos que permiten mejorar como profesional, están descritos en mi último libro The Coder Habits: Los 39 hábitos del programador profesional.

 

No hace mucho, publiqué "The Coder Habits: Los #39# Hábitos del Programador Profesional", libro que he hecho con mucha ilusión y siguiendo más o menos mi propio flujo de trabajo para escribirlo.

Este flujo de trabajo propio, consiste básicamente en:

 

  • Microtareas añadidas a Wunderlist.
  • Selección de temas.
  • Creación de los contenidos.
  • Revisión de éstos.
  • Buscar y leer documentación.
  • Comprobar qué opinan otros profesionales.
  • etc.

 

Y, cómo no, varias pasadas de revisión y corrección, todo ello durante varios meses en los quizá tenía libre media horilla una tarde para el nuevo libro, dos horas un sábado, etc.

Lo curioso es que en cada una de esas pasadas de revisión, siempre encontraba algún detalle que mejorar, un párrafo demasiado denso que mejoro aligerándolo con expresiones más ágiles y sencillas, algún error de puntuación que me lleva a usar la RAE más de lo que me gustaría, una nueva matización o la corrección de la repetición de un mismo concepto en una sección.

No hace mucho, precisamente comentaba con un compañero que es difícil determinar cuándo consideras que el libro está "listo" y cuándo puedes dar por terminado el trabajo para su publicación, porque con cada revisión, siempre encuentras algo que te gustaría mejorar, o algo que antes te sonaba muy bien pero que ya no.

Por cierto, recomiendo hacer una lectura en voz alta como parte del proceso de revisión, así se encuentran expresiones con una sonoridad extraña.

Por tanto, llegamos a la conclusión de que un libro "nunca está terminado del todo", esto es, puede que alcance un punto de madurez en el que crees que ya está listo para darlo a conocer con profesionalidad y calidad, pero da que pensar que si lo revisas diez veces más, quince o veinte veces más, el libro va a cambiar necesariamente en muchos aspectos. No en vano, es común que los autores revisen sus propias obras muchos años más tarde después de publicación (más aún si han tenido cierto éxito).

Difícil dar por acabado un libro. Y exactamente lo mismo ocurre en un proyecto software.

Cada vez que reviso alguno de los proyectos en los que he intervenido, siempre encuentro algún pequeño detalle que quiero mejorar, quizá una mejora en el diseño, o encuentras en algún sitio recóndito la posibilidad de aplicar un pequeño refactoring, o se te ocurre externalizar esas clases de ayudar como librería independiente, o quieres aprovechar una nueva característica de la última actualización del framework que utilizas.

Dejando al margen que al proyecto se le puedan pedir nuevos requisitos y funcionalidades, yo no sería capaz de afirmar categóricamente que un proyecto software ya está terminado "completamente"; funciona, sus tests pasan, cumple las necesidades del cliente a la perfección, pues maravilloso, está listo para ponerlo en producción, pero siempre vamos a encontrar qué mejorar, no me cabe la menor duda, tanto en la calidad de su código, su diseño y la calidad también de sus tests.

Por tanto, es difícil afirmar que exista un software "perfecto", podrá ser perfecto desde el punto de vista de su funcionamiento, pero siempre va a haber algo que mejorar en un proyecto con miles o cientos de miles de líneas de código.

Ahora bien, mejorar y cambiar porque sí, tampoco tiene sentido. Yo siempre me pregunto qué aporta este nuevo cambio que veo necesario: si simplifica, hace el código más elegante, legible, fácil de mantener y reutilizable, entonces es un cambio necesario, pero si no hace nada de eso sino todo lo contrario, mejor dejarlo todo como estaba. Recuerdo que hace muchos años, cambiaba cosas sin preguntarme si hacía más complejo el diseño o si ofuscaba un poco la solución; ahora siempre cambio algo pensando en simplificar. Punto.

Cambiar por cambiar, además, puede resultar peligroso si el proyecto no está suficientemente respaldado por pruebas; si no lo está, mejor dedicarnos a tener un conjunto de tests de calidad y después ya nos podremos dedicar a mejorar lo que queramos.

Antes de comenzar un nuevo ciclo de desarrollo, siempre intento dedicar algo de tiempo a mejorar aspectos del ciclo anterior que, quizá, no quedaron demasiado bien o a resolver aquella deuda técnica pendiente; esto es también un modo de preparar el terreno para la nueva funcionalidad que se va a incorporar.

Siendo así las cosas, no entiendo que un desarrollador se pueda aburrir en algún momento, porque aunque todo funcione perfectamnete, siempre hay algo que optimizar y mejorar.

Yo creo en la mejora continua e iterativa, creo más en construir algo de calidad poco a poco, y no a impulsos (mucho hoy y nada en la próxima semana). Prueba a hacer cinco micromejoras que te consumen diez minutos de tu tiempo en lo que sea durante un mes seguido. ¿Qué pasará cuando hayas acumulado cientos de micromejoras en tu proyecto?

No en vano, uno de los proyectos más longevos de los que soy reponsable ahora mismo (una plataforma de telegestión de contadores digitales), incluso después de siete años y de varias versiones y de haberse desplegado para muchos clientes, de vez en cuando nos encontramos con un pequeño bug.

Yo creo en la mejora continua en lo profesional, en lo personal y me atrevo a decir que también hasta en lo espiritual, y además creo que no es posible alcanzar ninguna perfección utópica, pero que ésta sirve precisamente para indicarnos la dirección que debemos seguir en cada momento, aunque el camino no sea nunca en línea recta.

Hay una definición de mejorar que consiste en poner el foco en reconocer los errores y aprender de ellos para que no se vuelvan a repetir. Cuando una persona comete el mismo error varias veces, es síntoma de testarudez. De ese modo, los defectos cometidos en el primer proyecto no se repetirán en el segundo, aquellos, junto con los del segundo, limpiarán el camino del tercero, etc, de modo que con el tiempo vas acumulando una experiencia de un valor difícil de calcular. Desconfío de la gente que aparenta no equivocarse nunca.

El problema está en la actitud: muchos entornos castigan el error, de modo que, si se produce, se trata de ocultar de la forma que sea; muchas personas personalizan en sí mismas cuando cometen un error, en lugar de verlo como una magnífica oportunidad para aprender algo nuevo y ganar valor como profesional. Tampoco vamos a dar saltos de alegría cuando la fastidiamos, vaya; lo que quiero decir es que siempre hay algo que aprender.

Para mí hay una verdad irrefutable: el que nunca se equivoca, es que siempre está haciendo lo mismo, y ya sabemos que para progresar siempre hay que estar más bien situado fuera de tu zona de confort que permanentemente dentro.

Realizar retrospectivas es una de las herramientas que conozco más útiles para mejorar y aprender, en todas las áreas, pero sobre todo en aquellos asuntos que no han ido tan bien como se esperaba. Hacerlas, constituye una oportunidad maravillosa que nos regala la vida para mejorar (a coste cero).

Desde Solid Stack, hemos cerrado hace unos meses un importante proyecto que costó muchísimo tiempo y esfuerzo terminar por diversas razones. Esta misma semana hemos hecho una retrospectiva para evitar repetir aquello que no hicimos bien (y evitar de paso que los errores y problemas de terceras compañías nos arrastren con ellos).

Es más, yo hago retrospectivas cada vez que termino algo de cierta importancia, por eso creo que este trabajo, que no deja de ser instrospectivo en el que hay que ser muy sincero, me sirvió para que mi segundo libro técnico (El Libro Práctico del Programador Ágil) lo desarrollara de una forma más fluida y eficiente que el primero (El Libro Negro del Programador, número 1 en Amazon en su categoría), y el último mejor que el segundo (El Método Lean MP).

En una retrospectiva, tanto si la haces tú mismo cuando te tomas en un café sentado en la terraza de tu cafetería preferida con tan solo un cuaderno y un bolígrafo, como si la haces en un contexto más amplio con compañeros, debería:

  • Permitir que todas las personas involucradas hablen abiertamente de lo que han percibido que se ha hecho mal.
  • Nunca culpabilizar a nadie (esto solo sirve para ocultar futuros errores).
  • Identificar claramente qué no funcionó del todo bien.
  • Plantear soluciones claras y nuevas estrategias para evitar los mismos problemas en el futuro.
  • Ser sinceros y humildes, lo que permitirá sacar los temas claramente y analizarlos mejor.
  • Aprender sobre cómo establecer anticipadamente las bases para evitar que surjan.
  • También, describir lo que sí funcionó muy bien para reforzarlo en otras ocasiones.

Volviendo al proyecto del que hablaba antes, hemos estado todos de acuerdo en que dejamos que el cliente abusara muchísimo del teléfono y tirara de él en cualquier momento (creando innumerables interrupciones enervantes), algunos elementos se especificaban por correo (abunsando también de esa herramienta y sin cultura de documento consensuado entre las partes), nos implicamos en responsabilidades que, claramente, no eran las del equipo, etc. 

Una reunión de un par de horas donde salen a relucir todos estos temas tiene también algo de catarsis, sobre todo para las personas que hemos podido sentir un pico de estrés en algunos momentos. Identificando con claridad lo que no funcionó bien, ganamos una base de experiencia importante que nos impedirá entrar en las mismas dinámicas en el futuro.

Pero no todo va del mal rollo de recordar lo que nos estuvo fastidiando un tiempo: en la retrospectiva también se puede reconocer lo que sí ha funcionado muy bien, para así fortalecerlo y tenerlo aún más presente en el futuro. Por poner en un ejemplo, en mi último libro, he respetado completamente la fase de redacción hasta terminar los contenidos de un primer borrador (sin echarle demasiada cuenta a la corrección y hasta la expresividad), de modo que en fases posteriores sí he entrado de lleno en el proceso de corregir y revisar (hace años, confundía las fases de redacción y revisión, y mientras escribía contenido nuevo, también corregía y revisaba, lo que es un error).

Al menos en mi país, hay cierta cultura de ocultar el error (y de personalizarlo), cuando éste no es más que el indicativo de que hay algo que aún no hemos aprendido, punto. Aunque tampoco creo que sea bueno ensalzarlo, sí puedo decir que los mejores profesionales no son solo aquellos que se han permitido la libertad de equivocarse más (cuando te has equivocado mucho, significa también que has trabajado en temas más diversos y amplios), sino también que han tenido la humildad de reconocer los problemas y aprender de ellos.

Detrás de un éxito, pequeño o grande, siempre hay muchos errores superados.

En alguna ocasión he hablado en mi web acerca de la diferencia entre crear productos y desarrollar proyectos, a nivel de implementación software. Del mismo modo, encuentro muchas similitudes entre crear un producto software y escribir un libro, aunque pueda sonar extraño en un principio, sobre todo ahora que acabo de lanzar un tercer trabajo de no ficción (El Método Lean MP).

Por alguna razón, se cree que escribir un libro es un trabajo cuya naturaleza escapa a la dinámica habitual de desarrollar cualquier otro tipo de actividades creativas (y de productos). Sea de ficción o no, hay quien le asigna a esa actividad de escribir un carácter especial sacado de la inspiración y la habilidad del autor con el manejo del lenguaje, recursos estilísticos y literarios o la capacidad de contar de forma simple y sencilla conceptos más bien complejos. Y sí, algo de esto debe haber, pero es del todo insuficiente, aunque siempre podemos encontrar ejemplos de libros con contenido muy interesante pero extraordinariamente mal escritos y también podemos encontrar lo contrario. Hay mucho más alrededor del desarrollo de un libro hasta llegar a su publicación final.

Cuando decimos que "he escrito un libro", a uno se le viene a la mente que te has sentado más o menos horas, y te has puesto a eso... escribir, con tu bolígrafro favorito y un cuaderno (a mí me gusta mucho seguir escribiendo a mano) o bien con el portátil. Escribir, por tanto, parece que es la actividad principal cuando dices que estás trabajando en un nuevo libro. Del mismo modo, cuando decimos que programamos un nuevo producto, pensamos que pasamos la mayor parte del tiempo... escribiendo código.

Y nada más lejos de la realidad.

Escribir, al igual que al desarrollar un producto de cualquier tipo, tiene también un proceso, en el que las ideas y la creatividad que terminan plasmando algo por escrito, es tan solo una parte. Esto es, un libro no se escribe, sino que es un proyecto que se desarrolla en el que una parte de él, solo una parte, sí consiste en escribir las páginas necesarias para transmitir la idea, el mensaje, el conocimiento o la historia que quieres introducir en la mente del lector.

¿Y cuánto ocupa esa parte de escribir? Yo no lo he medido con exactitud cuando he trabajado en alguno de los cinco libros que tengo hasta ahora publicados, pero sí puedo afirmar sin equivocarme, que menos de la mitad del tiempo que he dedicado a ellos, lo he dedicado a escribir el contenido.

Si lo miramos detenidamente, lejos de esa idea algo bohemia de un escritor encerrado en una buhardilla una tarde lluviosa de otoño esperando que le llegue la inspiración, el crear un libro tiene más parecido a construir un producto que a cualquier otra cosa, con la diferencia de que se le da cierto respeto cultural a quien lo publica.

Puede haber más creatividad (y arte) en un producto cualquiera que en muchos libros, y también pasa al revés, aunque esa pátina de respeto siempre la tiene ganada de antemano el escritor y su obra, y lo que digo es que producir un anuncio televisivo puede ser un trabajo mucho más creativo que lanzar muchos de los libros de consumo que inundan las estanterías de las librerías (y de Amazon, por poner un ejemplo). Pero vale, ya sabemos que no se paga por la creatividad, sino por el valor que el consumidor percibe en lo que compra.

Al igual que cualquier producto, el libro tiene como única finalidad aportar algún tipo de valor al que lo lee (nuevos conocimientos, asentar y consolidar los que ya se tienen, obtener nuevos puntos de vista o puro y sencillo entretenimiento).

Del mismo modo, un buen producto avala y confirma la profesionalidad de su creador (o del equipo que lo ha desarrollado); un libro también sirve para posicionarte mejor profesionalmente; de hecho, si quieres destacar como profesional, escribir un bueno libro sobre tu sector puede ser una gran palanca en tu carrera.

Cuando comienzas a trabajar en el proyecto de un libro, tienes unos objetivos en mente: económicos, de reputación, mejorar la rentabilidad de los anteriores complementándolos o cualquier otra cosa que se te ocurra (como también incrementar la vanidad del autor, que hay de todo). Se lanza un producto al mercado para venderlo, no hay más, ¿y cómo? Solucionando un problema de los consumidores y aportándoles algún valor. En el caso de un libro, el valor que aporta son nuevos conocimientos, entretenimiento o profundización cultural.

Un producto no se hace en dos días, ni siquiera todas las fases de trabajo que terminan produciéndolo suponen trabajar "en" él. Es decir, un producto se desarrolla siguiendo algún tipo de metodología. Lo mismo ocurre cuando trabajas creando un libro: parte del tiempo lo pasas escribriendo pero la mayor parte del tiempo la vas a pasar en otro tipo de actividades ordenadas en algún tipo de metodología (aunque habrá quien lo haga sin ésta y sin un orden claro en las tareas), como por ejemplo: plantear la estructura del libro, investigar escenarios, documentarse sobre hechos históricos, caracterizar los personajes, sus contenidos, desarrollarlos, encargar una portada, maquetar el libro, publicarlo, etc.

Pero es que todavía hay más paralelismos: nunca se lanza la primera versión de un producto tal y como esté, siempre se le da algunas vueltas hasta conseguir la madurez necesaria hasta que esté listo para su lanzamiento en el mercado.

Del mismo modo, cuando terminas una primera versión a modo de borrador del libro, es cuando comienza el trabajo más duro, que es el de corregir y revisar. En esta fase, se produce una auténtica lucha sicológica porque, como autor, quieres ver terminado el trabajo cuanto antes, y seguramente disfrutes más escribiendo que corrigiendo y revisando. Un autor con más experiencia, sabe que esa fase tiene que durar lo que tenga que durar, pero es una fase fundamental para generar algo de mejor calidad.

En todos los libros en los que he trabajado, esta fase me ha llevado más tiempo que escribir ese primer borrador. Sin ir más lejos, en El Método Lean MP, he corregido y revisado el texto hasta en cinco ocasiones, aportando un nuevo detalle, mejorando un párrafo, corrigiendo un typo, etc. 

Un producto se prueba exhaustivamente antes de salir al mercado (eso es lo ideal y característica de lo más profesional), igualmente, un libro es leído por varios beta-readers o por un editor que se encarga de supervisarlo, es decir, están "probando" ni más ni menos que el texto que has escrito tiene la calidad suficiente como para que pueda atraer la atención de los lectores, que la estructura del libro es consistente, que no hay erratas argumentales, etc.

Por último, cuando ya se lanza el producto al mercado (sea un libro o no), comienza otra fase igual de importante que las anteriores, que es la de promoción y márketing (aunque esta actividad puede comenzar incluso antes de terminar el producto). Por si aún no lo sabes, sin promocionar y sin hacer campañas del tipo que sea, difícilmente tu producto funcionará.

Disfruto mucho escribiendo sobre temas que me gustan y sobre todo cuando les doy esa estructura (en forma de libro) pensando que puede ser de valor a muchas otras personas en cualquier parte del globo, pero no me gusta en absoluto esa imagen algo elitista y soberbia que se dan algunos autores que quizá por pensar que "son escritores", creen que pueden tener algo interesante que decir. Esta actitud me parece un poco infantil.

Para mí, escribir es devolver a la sociedad parte de lo que me da, pero también es desarrollar un activo que, si todo va bien, trabajará para mí hasta cuando esté durmiendo. Por tanto, huyo de esa imagen ingenua del escritor con cara seria, la cabeza llena de ideas y el ceño fruncido por su peso intelectual..., y cuando me comentan algo al respecto, siempre digo que no escribo libros, sino que desarrollo productos con forma de libro, algo que, además, me permite aprender, profundizar y reflexionar en auquellos temas sobre los que escribo.

Páginas

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

Trabajo en...

Archivo

Mis novelas...