Rafa G. Blanes Blog

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.

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.

Nada es más gratificante que a medida que pasa el tiempo voy publicando nuevos trabajos en los que comparto conocimientos y, sobre todo, mis propias experiencias y que sean de valor para otros profesionales.

Son varios años ya escribiendo de forma consistente (con tres libros técnicos, dos novelas y muchos posts, entre otros contenidos), de modo que desde esta misma semana, he lanzado dos modalidades que faciliten dar un salto de nivel leyendo (y estudiando) El Libro Negro del Programadora, El Libro Práctico del Programador Ágil y El Método Lean MP, tres libros que, de un modo u otro, no dejan de estar relacionados.

Puedes adquirir los tres libros a la vez con lo que he denominado "Pack Pro", con un importante descuento al comprarlos juntos.   Desde Payhip, podrás obtener los tres libros en epub y pdf y después enviártelos a tu dispositivo de lectura preferido.

Comprar Ahora

También tienes a tu disposición el pack que incluye El Método Lean MP, junto con un catálogo de procedimientos y dos horas se asesoramiento por Skype o cualquier otro medio. También lo puedes adquirir desde Payhip (compañía de Paypal).

Comprar Ahora

Aunque mis responsabilidades actuales no me permiten pasarme toda mi jornada laboral programando, escribiendo código, sí puedo decir (sin ocultar algunas de mis canas) que llevo en esta profesión desde que era joven, primero como hobby, después profesionalmente, claro, y hasta el día de hoy.

Aunque paso mucho tiempo realizando actividades comerciales y de desarrollo de negocio, y también gestionando el equipo de desarrollo de Solid Stack, raro es el año que no participo activamente en dos o más desarrollos de productos o proyectos, aparte de mis repositorios de código personales y mis proyectos emprendedores.

Es sorprendente cómo ciertas habilidades, después de repetirlas muchísimas veces, terminan incorporándose a tu forma de hacer las cosas de manera natural: lo que antes te costaba cierto esfuerzo, a base de repetición y aprendizaje, se termina incorporando y resultan fáciles, hasta automáticas.

Leí hace tiempo que el 40% de lo que hacemos en el día a día está regido por los hábitos. Por tanto, lo único que tenemos que hacer es delegar en ellos aquello que más importancia tiene en nuestra vida y procurar tener buenos hábitos, y si no que se lo digan a los autores de Rich Habits Poor Habits, libro que he leído recientemente y que me ha gustado muchísimo (lamentablemente, a pesar de ser un bestseller, todavía no hay traducción al castellano).

Si quieres salud, créate hábitos de vida saludables, si quieres prosperidad, créate mejores hábitos económicos, y si quieres programar cada día mejor... pues eso, incorpora con trabajo y algo de esfuerzo los siguientes hábitos que, en mi opinión, caracterizan a un buen programador:

#1 Escribe código testeable.

Fácil de decir pero no tan sencillo de practicar. En mi penúltimo trabajo, El Libro Práctico del Programador Ágil, te describo las técnicas más importantes para desarrollar código que se pueda cubrir con tests (código limpio, refactorings, principios de diseño, etc.).

#2 Cuida de los detalles.

Escribir código es como escribir una novela, y ya sabemos que la metáfora del periódico nos dice que el código se debe leer de arriba abajo. Cuidar de todos y cada uno de los detalles del código que escribes (una indentación correcta y coherente, ausencia de comentarios innecesarios, etc.), es un síntoma de calidad.

#3 No tiene inconveniente en eliminar parte del código si es necesario.

Lo tenemos que asumir, a medida que evoluciona un proyecto software, y a medida que se hacen mejoras en el diseño, necesariamente partes del código quedará obsoleto y tiene que ser eliminado o modificado profundamente. Nada peor que intentar mantener a toda costa esto y lo otro sencillamente porque piensas que te costó horas desarrollarlo, ensuciando así la solución.

#4 Trabaja en las tareas planificadas y no otras y entrega a tiempo.

Programar bien (en el contexto de un proyecto con un equipo de trabajo), require ceñirse a algún tipo de metodología que imponta el ritmo de desarrollo, los tiempos, los ciclos y fases. Si se ha acordado hacer cierta funcionalidad, un buen profesional se ciñe y se compromete a su finalización en tiempo.

#5 Revisa continuamente qué mejorar.

Ya no solo hablamos de refactorización: muchos aspectos de una solución son susceptibles de mejoras. La acumulación de mejoras pequeñas e incrementales, hará que el proyecto alcance el nivel de calidad que deseas.

#6 Lee proyectos realizado por otros.

Nada mejor que aprender de programadores más experimentados. En GitHub dispones de miles de repositorios de código que puedes usar de ejemplo. 

#7 No reinventa la rueda.

Ya sé que nos gusta inventarnos un nuevo mecanimos para escribir entradas de log..., pero acostúmbrate a utilizar soluciones que ya existen para los aspectos del proyecto donde encajen. 

#8 Piensa que trabaja en equipo.

Esto quiere decir que tu trabajo, es muy posible que lo retome otro compañero en algún momento. Piensa en dejarlo lo mejor posible para facilitar las cosas a quien venga detrás.

#9 Evita las islas de conocimiento.

La seguridad laboral no existe, convertirte en un profesional destacado y demandado, sí. Es muy triste ver cómo ciertas actitudes hacen que haya quien oculte información al resto de compañeros para que así sea la única persona que sabe llevar este u otro tema. Sin saberlo, esta actitud le converte en esclavo de un mismo proyecto que terminará odiando. El antídoto a esto es ganar experiencia participando en diferentes proyectos con el tiempo.  

#10 Colabora con el resto del equipo.

El desarrollo de software es una actividad profundamente colaborativa, si no sabes o no quieres colaborar con tus compañeros, tarde o temprano que tendrás que buscar otro trabajo.

Y podría decir un último hábito igual de importante que los anteriores: deja las cosas mejor que como te las encontraste.

Podría enumerar muchos más, pero te aseguro que en estos hábitos (toda una declaración de principios) resumen lo que caracteriza a un buen profesional.

A comienzos del próximo mes de junio, estará disponible un nuevo trabajo que confío sirva de utilidad para todos aquellos que lanzan proyectos emprendedores y que luego no saben bien cómo darles seguimiento, evolucionarlo, mejorarlo, etc.

(Update: libro publicado y en funcionamiento. Más información aquí).

En este breve trabajo, te muestro cómo gestionar un proyecto desde el momento en que se lanza una primera versión mediante lo que denomino el método Lean MP y su Matriz de Procedimientos. Es un libro práctico, basado en mi propia experiencia.

En menos de dos horas de lectura, te voy a contar cómo implantar un método sencillo y eficaz para responder a las siguientes preguntas:

¿Cómo gestiono y hago progresar el proyecto después de sacarlo a la luz?

¿Hay un modo de automatizar y sistematizar ese trabajo?

¿Cómo puedo conseguir que avance sin tener que dedicarle todo mi tiempo y poder delegar?

¿Se puede sistematizar la gestión de un negocio y, por tanto, sus resultados?

¿Cómo aplico la metodología lean para avanzar y progresar en mi proyecto emprendedor?

Este es el mismo método que aplicamos en la gestión de Picly.io y que yo mismo llevo a cabo en otro tipo de actividades.

A continuación, indico la lista de capítulos:

> Introducción <

> Cómo surge este libro <

> Para quién es este libro <

> Punto de partida <

> Qué es un procedimiento <

> Cuándo sabemos que un proyecto funciona <

> Matriz de procedimientos <

> Repositorio de resultados <

> Procedimientos básicos: <

> 1) Procedimientos Comunicación al mercado (PCM) <

> 2) Procedimientos Métricas e informes (PMI) <

> 3) Procedimientos técnicos (PT) <

> 4) Procedimientos de seguimiento (PS) <

> 5) Procedimientos económicos (PE) <

> Planificar la Matriz de Procedimientos <

> Revisión <

> Sistematizar y delegar <

> Conclusiones <

> Tooling para emprendedores <

> Bibliografía <

A estas alturas de mi carrera profesional, después de haber pasado por experiencias de varios tipos, no tengo la menor duda de que gestionar correctamente un proyecto es fundamental para su éxito. Parace una perogrullada que tenga que decir esto, pero es que me temo que muy malos gestores salvan la cara por tener a su disposición un equipo de trabajo extraordinario, sin darse cuenta de que entorpecen el trabajo en lugar de facilitarlo.

Si crees que gestionar consiste en ordenar, emplear el látigo y exprimir al equipo de diriges al máximo sin importarte las condiciones de trabajo, estás muy mal encaminado: la gente huirá de ti y los proyectos... saldrán mal y a cuentagotas. Sin embargo, esta actitud es común en ciertos entornos corporativos y hasta se fomenta.

Pero aquí hablo de gestionar para conseguir resultados excelentes y buenos productos software.

¿Qué hace en esencia un gestor? No hay más, facilitar el trabajo del equipo que dirige, y también dirigirlo con las actitudes y responsabilidades adecuadas y necesarias.

Y no es fácil, para nada.

Como digo, un mal gestor con muy buen equipo puede arruinar un proyecto, pero lo contrario también es cierto: por muy buen gestor que sea, por muy alta nota que haya sacado en una certificación tipo PMP o algo por el estilo, si tiene a su disposición un equipo con miembros técnicamente deficientes, con implicación y motivación nulas y con problemas de trabajo en equipo... ya sabemos también el resultado.

En mi opinión, gestionar para que un proyecto software sea un éxito consiste en más habilidades personales que técnicas: viene a ser un puzzle en el que tienes que encajar correctamente todas las piezas para que todo funcione aceptablemente. Hablo de proyectos de desarrollo de software, aunque lo siguiente es aplicable también a cualquier otro tipo.

En el trabajo de gestionar, hay algunos elmentos imprescindibles y todos juntos hacen que prácticamente el éxito esté asegurado. Un buen gestor posee y trabaja bien las siguientes habilidades.

Planificación

Un gestor tiene que planificar con los pies en la tierra, asegurando el frágil equilibrio entre cumplir aceptablemente con las fechas comprometidas con el cliente sin forzar a que el equipo trabaje bajo una excesiva presión y mal (cuyo resultado es el desarrollo de código de peor calidad).

Parte del tiempo del gestor lo debe dedicar a planificar. Hay una regla en el desarrollo personal que me llama poderosamente la atención que no esté presente en nuestro día a día: cuanto más y mejor se planifica, menos tiempo se tarda en hacer las tareas.

No se debe realizar nada que no esté planificado previamente, lo contrario es trabajar sin orden e improvisadamente, sin saber distinguir lo urgente de lo importante.

Organización

El gestor organiza, como es obvio, pero organizar no consiste en ordenar hacer esto o lo otro, sino en saber encajar las tareas a realizar con la natureleza del equipo que las va a ejecutar. Para ello hay que conocer bien a las personas con las que se trabaja, su debilidades y fortalezas, sus gustos e inclinaciones técnicas, y me atrevo a decir que hasta cierto punto intimo, para detectar los momentos personales de cada uno y saber si ciertas tareas conviene que las haga uno u otro mejor.

La organización es tanto de arriba-abajo como de abajo-arriba, quiero decir, también hay que organizar con el cliente el resultado del trabajo, las entregas, gestionar los problemas e incidencias, etc.

La buena organización depende de que el equipo trabaje correctamente con los medios adecuados y sin impedimentos. También, una buena organización hace que se trabaje productivamente.

Dotación de personal

Hacer equipo es algo realmente complicado, cuando no a veces te encuentras con que este ha sido ya asignado de antemano por otras personas en la organización. Es fundamental contar con un equipo cohesionado e implicado en el proyecto a realizar.

Un buen gestor sabe detectar las dinámicas de equipo negativas, y también sabe atajarlas de raíz, aunque haya que tomar decisiones difíciles.

Delegación

Si, como yo, has pasado mucho años en el lado técnico del trabajo y con el tiempo has ido asumiendo responsabilidades de gestión, entonces sabrás que delegar cuesta mucho trabajo, sobre todo si creemos saber hacer las tareas que hay que poner en marcha. Sin embargo, delegar es fundamental para que puedas centrarte correctamente en el resto de tareas de... gestión. Un proyecto puede fracasar porque su responsable no sabe o no está dispuesto a delegar. 

Esta es mi opinión al respecto: un gestor que trabaja doce horas al día, que vive estresado y que tiene demasiadas cosas que dependen de él, sencillamente es que no está delegando.

Lo ideal es contar con gente que sabes que va a hacer las cosas mucho mejor que tú.

Mantener un equilibrio entre lo técnico y los asuntos de gestión es a veces delicado; personalmente, trato de compatiblizar algo y siempre me mantego muy activo en los nuevos desarrollos, decisiones de diseño, etc.

Supervisión

No me gusta la palabra controlar, entiendo que si cuentas con un equipo en el que la confianza es el factor de trabajo más importante, entonces no hace falta controlar, la gente debe ser responsable y debe saber lo que tiene que hacer en su día a día. No obstante, sí hay que supervisar y estar al tanto del nivel de ejecución de las tareas, y esta es una actividad que se debe hacer continuamente. Si hay desviaciones, el gestor debe tomar las decisiones adecuadas para no comprometer el proyecto.

Transparencia

El buen gestor sabe comunicar correctamente, y debe dar una información clara del estado del proyecto tanto al resto de la organización (directorivos, directores, etc.) así como al mismo cliente final. Del mismo modo, debe mantener informado el equipo que dirige correctamente de ciertas decisiones y del porqué hacer esto o lo otro de la manera en que se decida.

Por último, lo bueno de todo lo anterior es que son habilidades que se pueden aprender.

Me atrevo a decir que un buen gestor, que trabaja en una organización en crecimiento, también dedica parte de su tiempo a enseñar esas mismas habilidades ya adquiridas a los miembros de la organización que tengan una actitud que les vaya a dirigir hacia actividades de gestión en el futuro.

Me propongo aclarar algunos términos.

Cuando comenzamos un nuevo proyecto software, cualquier tipo de aplicación, raramente sabemos con exactitud cómo lo vamos a implementar; quiero decir, qué estructura de clases habrá, cómo será la mejor forma de organizar los assets del proyecto, qué interfaces surgirán y hasta qué decisiones de diseño y arquitectura deberemos tomar. Como digo, tendremos si acaso una aproximación mental pero no la forma completa y exacta que tomará la solución. 

Es cierto que con el tiempo y la experiencia, ya vas teniendo una idea clara antes de comenzar según el tipo de proyecto y de aplicación.

Por tanto, en realidad hasta que no se va implementando funcionalidad, no sabremos la mejor forma de hacer las cosas, lo que no es más que una versión de aquello de "caminando no hay camino: se hace camino al andar".

Puedo asegurar esta ley universal: la primera aproximación nunca es la mejor.

Lo peor que le puede ocurrir a una aplicación es dejarla exactamente tal y como surgió en su implementación inicial, sin refinar ni mejorar absolutamente nada de su estructura y diseño. Cuando hablo de aplicación, podemos bajar de nivel a librería, módulos, clases, métodos, etc. que el principio se sigue cumpliendo.

La construcción de una aplicación de calidad es un proceso de mejora incremental y continuo y, en realidad, siempre quedará algo por mejorar.

Todo se complica cuando vamos añadiendo más y más funcionalidad, alguna que ni siquiera esperábamos ni imaginábamos, algo totalmente natural en el desarrollo de software, de modo que el peor error que podemos cometer es añadir esa funcionalidad en el esqueleto anterior ya realizado, de cualquier modo. De ahí, con el tiempo, tendremos el terreno abonado de una aplicación inmatenible y difícil de entener y evolucionar.

Refactorizar es esencial para evitar la situación anterior, y cuando hablamos de refactorizar nos refererimos exclusivamente a la aplicación de ciertas técnicas que permiten mejorar el microdiseño del código que hemos escrito. Son pequeños pasos en los que cada uno mejora un diminuto aspecto de la solución.

Por extensión, también hablamos de refactorizar como sinónimo de mejorar cualquier elemento de la aplicación, y está bien que extendamos ese concepto aunque en origen se refiere exclusivamente a la aplicación de técnicas muy concretas y bien documentadas para mejorar el código. De ahí que aunque no sea demasiado correcto, se pueda entender también qué se quiere decir con refactorizar el diseño de una base de datos, un script para esto o lo otro, etc.

Ahora bien, ¿para qué refactorizar si un trozo de codigo o la misma solución en conjunto "ya funciona"?

Toda solución software debe ser diseñada para admitir cambios con facilidad, algo que le va a ocurrir con el 99% de probabilidad. Por tanto, refactorizar nos permite tener una aplicación con mejor diseño y mejor estructura, más entendible y más mantenible.

Pero también hay aspectos sutiles que solo se aprenden con la experiencia: refactorizando, conseguimos que nuestro código sea más testeable, pero también al revés: nuestro interés por hacer tests nos lleva a la obligación de refactorizar (consciente o inconscientemente). Este es uno de los aspectos del desarrollo de software que más me gustan, porque muchos elementos de la naturaleza del código son sutiles de asumir.

Refactorizar va de la mano de dos conceptos y está tan intrincados en ellos que es imposible hablar de una cosa sin la otra: la orientación a objetos y el testing.

Una aplicación programada en un lenguaje orientado a objetos permite una mejor estructura y una mejor solución porque nos permite abstraer un problema en entidades mentales más comprensibles a nuestro modo de pensar (objetos), mientras que el testing es un requisito ineludible para garantizar la calidad y el correcto funcionamiento de la misma.

Si cambiamos algo, por mínimo que sea en el código, ¿cómo sabemos que todo sigue funcionando? Exacto, con tests.

Por tanto, es imposible o incluso peligroso aplicar técnicas de refactoring si la aplicación no está suficientemente cubierta y respaldada por tests.

En software no es una buena práctica mejorar lo que sea al final, sino que es más productivo insertar toda mejora en el día a día, como parte misma de la actividad de desarrollo. Esto lo dice la teoría, pero es que lo he comprobado yo mismo a lo largo de todos estos años. Mejorar el código continuamente permite alcanzar más velocidad de desarrollo sin ninguna duda.

Esto es, las técnicas de refactoring se aplican continuamente y de forma incremental. Es sorprendente cómo pequeñísimos cambios en una aplicación pueden tener un efecto enorme y acumulativo en la aplicación final.

Existen muchas técnicas bien documentadas desde que apareció este concepto en el libro de Martin Fowler y Kent Beck, y muchas otras que diferentes autores han propuesto desde que en nuestra industria se asumió que el código se debe mejorar continuamente a pequeños pasos incrementales.

Incluso una aplicación que no ha sido refactorizada en este sentido nunca y que incluso no tiene buena cobertura de tests, se puede enriquecer aunque haya que comenzar desde cero su refactorización, aunque sea poco a poco.

Si quieres saber más sobre refactoring, detallo las técnicas más comunes en mi último trabajo El Libro Práctico del Programador Ágil, junto con infinidad de prácticas esenciales para crear código de calidad.