Este es el comienzo de un nuevo proyecto. 

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

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

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

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

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

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

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

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

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

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

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

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

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

¿Cómo se publicará el trabajo?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¿Resultado?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A lo largo de esta web así como de El Libro Negro del Programador, se insiste mucho acerca de la necesidad de que una solución software sea mantenible. Es más, si no es mantenible fácilmente, el proyecto puede ser todo un fracaso y traerá consigo un cliente muy cabreado y enojado (que seguramente nunca volverá a confiar en ti) o una compañía que tiene un agujero económico que cubrir.

No se hace software para que funcione ahora, sino para que pueda ser evolucionado y matenido fácilmente con el tiempo. Esto para mí es un mantra que repito y un principio irrenunciable.

Mantener un proyecto software en producción es en definitiva conocer cómo se comporta, tener identificadas claramente las actividades de mantenimiento, poder detectar con sencillez dónde ocurren los problemas pero, sobre todo, tener la capacidad de hacer todo eso de manera eficiente y en poco tiempo.

Administrar, por su parte, está relacionado con lo anterior y es igualmente importante: si la administración de cualquier producto software es ineficiente, estaremos poniendo en peligro su viabilidad en producción.

Por muy bien que funcione aparentemente nuestro proyecto, si este no se puede ni mantener ni administrar correcta y eficientemente, habremos realizado en realidad un proyecto más bien pobre. Para que un software sea mantenible y administrable tiene que desarrollarse desde el principio pensando en su sencillez de mantenimiento y administración.

Realizando recientemente algunas actividades de mantenimiento de la web de la compañía en la que dirijo proyectos software, volví a tener presente este carácter intrínseco tan importante del desarrollo. La web está montada en Drupal y se tenían que actualizar algunos módulos desde hacía algún tiempo. A los que me conocen no les extraña en absoluto que dirija la realización de proyectos software al mismo tiempo que me meto de lleno es aspectos de desarrollo de bajo nivel, ¿acaso se puede dirigir algo sin conocerlo suficientemente?

Existe un proyecto que el mundo drupalero conoce muy bien y que permite realizar las actividades de mantenimiento, supervisión y administración de una web basada en Drupal muy fácilmente y, sobre todo, de manera muy eficaz; se trata, claro está, de drush.

Por poner un ejemplo, si tenemos que actualizar el Core de Drupal de un 7.xx a la última versión (en el momento de escribir esto la 7.32) podríamos implementar los pasos oficiales sobre una instancia stage, que, más o menos, son estos:

  • Realizar un backup de nuestro sistema (ficheros y base de datos).
  • Descargar la última versión de Drupal.
  • Copiarla correctamente manteniendo nuestra carpeta "/sites".
  • Ejecutar el script "/update.php".
  • Por último comprobar que todo ha ido bien...

Esto es algo habitual y, en mi opinión, que existan tantas revisiones de Drupal 7 para mí es bueno, puesto que cada revisión mejora aspectos del Core o realiza actualizaciones de seguridad.

No obstante, lo anterior puede ser tedioso incluso si se tiene que realizar cada dos o tres meses. En cambio con drush todo lo anterior se puede hacer con:

$ drush up drupal

En una simple línea de comandos realizamos todos los pasos anteriores, por lo que de ser una actividad pesada se convierte con drush en la ejecución de una única orden.

Del mismo modo, con:

$ drush status

, obtenemos una visión general de la instancia de Drupal.

Comento esto como un maravilloso ejemplo de facilidad de manteniemiento: con el primer enfoque podemos tardar 10/30 minutos, con el segundo menos de un minuto. ¿No es esto productividad? Me pregunto si no llenamos nuestro día con actividades similares que podríamos optimizar.

Salvo que estemos haciendo proyectos de prueba o de evaluación y no profesionales que en ningún momento se pasarán a producción, personalmente me preocupo mucho de que lo que se haga ofrezca suficientes posbilidades, información y herramientas para un fácil y ágil mantenimiento y administración. En este punto está la clave del éxito de muchos proyectos software.

¿De qué sirve un producto que ha costado desarrollar X € si el mantenimiento del mismo cuesta el triple? ¿Tiene sentido proyectos en los que existen hasta varias personas dedicadas íntegramente al mantenimiento del mismo? ¿No es esto una evidencia de que las cosas no se han hecho del todo bien durante su desarrollo? Recuerdo hace algunos años cuando dedicaba parte de mi jornada laboral a mantener un sistema de telegestión en un cliente y se me iban las horas buceando en la base de datos con consultas muy tediosas para descubrir y resolver ciertos problemas.

Me pregunto cuántas veces en este tipo de situaciones no tiene efecto esa frase tan española y castiza de "preocuparse por la peseta pero no por el duro" (un duro equivalía en la era pre-euro a cinco pesetas), expresión que en versión tecnológica vendría a ser algo así como "intentar que el desarrollo a corto plazo sea muy barato y no ver que su mantenimiento será muy caro".

En cualquier producto software, se desarrolla una vez pero se mantiene continuamente (al menos hasta que nos quedemos sin clientes).

Del mismo modo, cualquier cliente en su sano juicio antes de comprar algo debería preocuparse por lo que le va a costar el mantenerlo y si su administración es eficiente y ágil.

Es más, podríamos convertir esta misma capacidad en un atractivo más de valor para nuestro producto: su sencillez (y poco costoso) mantenimiento.

Idea Concetp Development ProductDurante mis primeros años como desarrollador de software tuve la enorme suerte de participar en un equipo que estaba dedicado íntegramente al desarrollo de un producto. Incluso teníamos quienes se dedicaban exclusivamente a escribir pruebas (lo que era un auténtico lujo). Hace tiempo de eso y aunque usábamos tecnologías ahora obsoletas o de menos uso (Visual C++, ActiveX, COM, DCOM, etc), la dinámica para la creación de un producto software no ha cambiado en absoluto, aunque desde entonces he abrazado el desarrollo ágil como mejor forma de realizar software.

Estos dos últimos años, sin ir más lejos, me he dedicado íntegramente a dirigir un equipo de desarrollo para la creación de un producto software muy específico para compañías del sector eléctrico. Han sido dos años muy duros en los que hemos escrito muchísimo código, hemos sacado unas cuatro versiones comerciales del producto con éxito (con clientes consolidados) y hemos tenido siempre presente la necesidad de refactorizar, de esforzarnos por mejorar y ampliar las pruebas, de escribir una documentación de despliegue correcta y mantener una gestión de la configuración eficiente. Nada es perfecto, pero el resultado, en mi opinión, me indica que hemos hecho las cosas aceptablemente bien.

Programar algo que funcione es relativamente fácil, crear un proyecto muy particular para un cliente requiere de algunas habilidades más, hacer un proyecto similar pero de mayor tamaño con un equipo de varias personas añade un nuevo nivel de dificultad pero, sobre todo, realizar un producto software que sea válido no para uno sino para cientos de clientes distintos, es otro nivel completamente distinto que requiere de una dinámica muy diferente a la del trabajo en un proyecto particular.

Hay muchas diferencias técnicas y de gestión entre uno y otro escenario y no siempre se distinguen claramente.

¿En qué consiste la diferencia?

La dinámica es tan diferente hasta el punto de que en ocasiones se intenta afrontar el desarrollo de un producto con la presión al mismo tiempo de entregar proyectos con ese mismo producto (haciéndolo todo el mismo equipo). Lo he visto, lo he vivido y es un absoluto desastre.

Aunque cada producto y cada proyecto tienen su propia idiosincrasia, en mi opinión es mucho más fácil entregar un proyecto para un cliente que te indica lo mejor posible qué necesita. Otra cosa distinta es saber productivizar algo a partir de las necesidades de un conjunto de clientes: esto es ni más ni menos que el desarrollo de un producto software.

Muy resumidamente, en un proyecto:

  • Hay un trato directo con un cliente que puede ser más o menos difícil de llevar (especificaciones que cambian sobre la marcha, exigencia de tiempos de entrega, etc).
  • La funcionalidad a implementar está perfectamente acotada (sí, ya sé, al menos debería estarlo).
  • La gestión de la configuración, o sea, la definición de flujos de trabajo, la gestión de versiones de desarrollo y la de producción final, etc., es relativamente más sencilla. No digo que sea trivial, sino que es más sencilla que la gestión de configuración para un producto.
  • La gestión del grupo de trabajo se orienta a la entrega del proyecto al cliente en fechas determinadas.
  • Las reuniones con el cliente absorben mucho tiempo, sobre todo si se le van haciendo entregas tempranas para su evaluación y corrección.
  • El equipo de desarrollo o quien lo dirige no necesita conocer con todo detalle el universo en el que trabaja el cliente y su propio negocio.
  • No hay necesidad de hacer partes del sistema flexibles y adaptables a gustos y diferentes exigencias de posibles clientes, ya que sólo hay uno.
  • En cuanto al mantenimiento, nos podemos permitir que no sea lo más fácil de mantener (ya que va a haber un sólo cliente), aunque lo deseable es que sea extremadamente sencillo de mantener sin acumular deuda técnica que luego nos pase factura en el tiempo dedicado al cliente, tanto si éste paga ese mantenimiento como si no. Un proyecto difícil y costoso en tiempo de mantener en producción, es un fracaso.
  • No hay tantas restricciones en la elección de las tecnologías a usar, sobre todo el proyecto no va a evolucionar demasiado con el tiempo.
  • Puesto que existe un único cliente, se puede conocer con antelación el entorno en el que se va a desplegar el proyecto (sistema operativo, tipo de base de datos, hardware, etc.), al menos se puede acordar con el cliente.

En cambio, el desarrollo de un producto es otro nivel distinto y mucho más exigente en el desarrollo de software, porque:

  • Hay que conocer profundamente el universo de los clientes potenciales hacia los que te diriges. El producto tiene que resolver algo y aportar funcionalidad para el negocio de los clientes, por tanto, tienes que conocer ese negocio muy bien. No es necesario que todo equipo conozca esto, pero quien lo dirige o determina la funcionalidad sí.
  • De este conocimiento del negocio de los clientes potenciales hay que extraer la funcionalidad a implementar: especificar es algo muy pero que muy difícil, especificar bien para extraer historias de usuario o requerimientos técnicos lo es todavía más.
  • La gestión de la configuración tiene que ser más exhaustiva, sobre todo si con el tiempo terminas teniendo en el mercado distintas versiones del mismo producto.
  • Puesto que la vida del producto puede ser muy larga, hay que hacer mucho más énfasis en la testeabilidad del software y todo o casi todo tiene que estar cubierto por pruebas automáticas. De no ser así, el probar el sistema puede suponer tal agujero de tiempo que puede incluso poner en peligro la viabilidad económica del producto.
  • Es mucho más difícil elegir las tecnologías a usar más adecuadas, sobre todo si se estima que el producto software tenga una vida de muchos años, que es lo deseable para rentabilizar la inversión en su desarrollo, claro.
  • Hay que ponerse en el lugar de los posibles clientes y adivinar o averiguar cuáles pueden ser sus necesidades específicas y particulares para incorporarlas al producto en forma de capacidades de integración, funcionalidad de particularización, etc.
  • Hay que definir el entorno ideal de despliegue del producto, lo que puede ser muy delicado porque esto afectará al coste que tenga el mismo. Cuantos más entornos distintos que tengan que ser compatibles con el producto, mucho más esfuerzo por nuestra parte para probar y probar. Un error fundamental es ignorar el tipo de entorno de despliegue hasta el final.
  • Si queremos mejorar el producto para ganar cuota de mercado, es imprescindible recibir mucho, muchísimo feedback desde el momento en que tenemos un primer cliente usándolo. Es más, si podemos liberar un MVP (minimum viable product) cuanto antes, mejor, corregiremos así deficiencias lo antes posible y enfocaremos mejor el desarrollo del producto.

Aunque estas diferencias las debe considerar el responsable del desarrollo del proyecto o del producto, también afectan al día a día de los desarrolladores del equipo de trabajo.

Me pregunto por qué nunca he visto en un currículum una mención del tipo "Desarrollador de productos software" o "Desarrollador de proyectos para clientes finales"; para mí la diferencia es enorme. 

Sin duda, el desarrollar un producto software (o dirigir su desarrollo) requiere de mucha más experiencia y de controlar muchos más parámetros que el desarrollo de proyectos específicos, bastante más cómodos de gestionar (aunque el trato con el cliente siempre es difícil de llevar).

Han pasado varios meses desde que se publicó oficialmente El Libro Negro del Programador después de año y medio trabajando en este proyecto. Desde entonces he recibido muchos comentarios, la mayoría afortunadamente positivos (algunos también no tan positivos); en general, todo me hace pensar que los desarrolladores de software nos quejamos casi siempre por las mismas razones independientemente de dónde realicemos nuestra actividad (Chile, Venezuela, Brasil, España, USA, etc.) y que la manera de entender el desarrollo de software desde el mundo corporativo viene a ser muy similar en casi cualquier parte. Cuanto más grande sea la empresa y su nombre se parezca más a "Consultoría de servicios IT", más se pierde el carácter de artesanía (craftmanship) en el trabajo que se realiza, lamentablemente.

En cualquier proyecto siempre se aprende algo, en ocasiones muchísimo, todo depende de la actitud que afrontemos durante el mismo. Incluso si repetimos el mismo tipo de proyecto, siempre podemos encontrar mejores formas de hacer las cosas, por tanto, el que sepamos aprender y mejorar más o menos depende directamente de nuestra actitud.

Sólo mejoramos si tenemos una motivación interna para ello, nadie, ni nuestro jefe, ni nuestros compañeros, ni nuestra empresa, etc. nos va a hacer mejorar profesionalmente si antes no tenemos esa predisposición. 

Creo que el mejor valor que podemos aportar a nuestra organización es el de mantener siempre una actitud de aprendizaje y adaptacíon continuos y esto se debería apreciar y tener en cuenta en los departamentos de recursos humanos.

Mientras le daba forma al libro fui poniendo por escrito muchas gemas de sabiduría que quería compartir; al mismo tiempo, se asentaban en mí ciertas ideas al tiempo que profundizaba en otras. Escribir un libro es ya en sí mismo toda una lección de humildad y cada capítulo te pone a prueba.

Siempre intenté mantener una actitud activa y de escucha cuando publicaba el adelanto de cada capítulo en la web. Nada peor que pensar que uno tiene la última palabra y la razón absoluta, esta actitud un poco egoica (que no egoísta), actúa como un bloqueo que nos impide descubrir nuevas posibilidades pero sobre todo, nos impide darnos cuenta de nuestros propios errores. Los comentarios de ánimo por el trabajo, sobre erratas y también a veces las críticas anónimas mordaces, me hicieron mejorar mucho el contenido y calidad de la mayoría de los capítulos del libro.

Del mismo modo, uno descubre pronto que hablar sobre ciertos temas como aquel que trata el capítulo titulado Cuando el gestor del proyecto es su mayor enemigo, puede causar cierta incomodidad e incluso incompresión por parte de antiguos conocidos, por lo que se aprende muy rápido eso de que no podemos agradar a todo el mundo (gran lección, por si aún no la conocías). Si precisamente el libro propone mejorar ciertos aspectos negativos y recurrentes de nuestra profesión, obviamente ¡tengo que señalarlos para indicar el remedio!, y que conste que soy el primero en haber cometido casi todos los errores típicos que se mencionan en el libro, de modo que soy un ejemplo fantástico y de primer orden...

En ocasiones el hecho de no hacer incomodar a ciertas personas supone un freno para poner en marcha proyectos, mejorar el funcionamiento del departamento en el que trabajamos, etc. Irónicamente también a veces esas personas que suponen un obstáculo ni siquiera nos caen bien... Lección: ignorar que parte de tu trabajo pueda sentar mal o remover malos sentimientos entre ciertos individuos. Afortunadamente, esto es algo muy puntual.

No es lo mismo pensar que sabes algo y que tienes cierta idea sobre algunos temas que intentar ponerlos por escrito para transmitíselo a otros de una manera clara, sencilla y atractiva; son dos ámbitos de pensamiento completamente distintos, de modo que si realmente queremos alcanzar la maestría en algo, nada mejor que dedicar parte de nuestro tiempo a enseñarlo.

Escribir un libro sobre cualquier tema te obliga a poner en cuestión todo aquello en lo que creías, por la sencilla razón de que lo tienes que justificar y argumentar. Del mismo modo tienes que ganarte credibilidad desde la primera línea, indicando referencias, experiencia, no incurriendo en contradicciones y manteniendo siempre una línea coherente con todo. Nada peor que esos libros de desarrollo de software sobre la tecnología X en los que se intuye que el autor ha realizado más bien pocos proyectos con esa misma tecnología.

De aquí la siguiente lección: si quieres escribir con credibilidad sobre algo para ganar cierta atención, tienes que tener autoridad demostrable en la materia y ser lo más experto posible en ello. Cuanto más experto seas, más atención y seguidores obtendrás. No sólo es bueno sino buenísimo que tengamos nuestro propio blog donde de vez en cuando vamos publicando tutoriales, articulillos, etc. sobre los temas que más nos interesan. Es más, debería ser una práctica habitual y casi obligada entre los empleados de las empresas para mantener siempre un espíritu de progreso en aquello en lo que estamos trabajando.

Escribir sobre algo en un proyecto de más de un año require de mucha disciplina (de muchísima tenacidad) y de aguantar periodos en los que el resto de tus actividades te mantienen exhausto y otros en los que sientes un bloqueo absoluto para avanzar el desarrollo de ciertos temas. Si eres incapaz de mantener cierta rutina para una tarea de duración larga, olvídate ya de intentar escribir un libro.

El Libro Negro del Programador es un proyecto que se ha gestado de noche (a partir de la hora en la que mis dos hijas están ya en la cama...), en fines de semana con huecos suficientes como para poder concentrarme en un tema más de dos horas seguidas y, por supuesto, en vacaciones, quitándole tiempo a tu familia y resto de actividades que realizas fuera de tu trabajo full-time. Por esta razón digo que más que trabajo duro se require de disciplina, el saber aguantar mes a mes aún viendo cómo llevas bloqueado en cierto tema algún tiempo. 

Otra cuestión bien distinta es considerar si merece la pena este sobresfuerzo y esto sí que tiene muchas caras y ángulos distintos.

También es una cuestión de metodología: cualquier trabajo que hagamos, sea del tipo que sea, si nos paramos un momento, damos un paso atrás y lo intentamos planificar y ordenar aunque sea mínimamente, entonces obtendremos mejores resultados y lo haremos en menos tiempo; la productividad es eso, ni más ni menos. 

En el caso del libro me planteé una metodolodía de escritura y revisión de cada capítulo más o menos así:

  • Planteamiento de las ideas generales del capítulo.
  • Desarrollo del primer borrador.
  • Revisión a fondo del borrador.
  • Publicación parcial en la web como adelanto.
  • Digestión y análisis de los comentarios (curiosamente muchos me llegaban por correo a través del formulario de contacto y no directamente como comentarios en la web).
  • Desarrollo de un segundo borrador.
  • Revisión de nuevo y etiquetado como finalizado.
  • Enésima lectura y si algo no seguía quedando a mi gusto, de nuevo a revisar.

Desde el primero punto hasta el último podían pasar varias semanas, de modo que era habitual que fuera superponiendo el trabajar en varios capítulos al mismo tiempo. De este modo, la lección sobre este punto a mí me parece muy importante: si pretendemos trabajar en un proyecto al que no nos dedicamos al 100% y que se va a alargar mucho en el tiempo, necesariamente tenemos que organizarlo de alguna forma, planteando cómo y qué pasos dar en cada momento (esto es, hay que trabajar con algún tipo de planificación y metodología).

Inicialmente hice un esquema básico de los temas en los que quería trabajar, rescatando muchos escritos personales que llevaba varios años realizando; después de hacer una lista de unos cincuenta temas que quería desarrollar, muchos de ellos fueron finalmente cubiertos en varios capítulos, otros fueron descartados y otros, a pesar de haber escrito sobre ellos, fueron capítulos que bien por extensión, bien por no alcanzar la calidad mínima que yo mismo me exigía o bien por coherencia con el resto del libro, no fueron incluidos en el trabajo final. 

Otra lección para mí muy importante: saber desprenderse de aquello en lo que uno ha trabajado, aunque se hayan dedicado muchas horas en ello. Esto me recuerda al enorme esfuerzo que nos cuesta a veces eliminar parte de una solución software que se ha quedado obsoleta, que nunca se ejecuta o bien que queremos sobrescribir por haber encontrado una forma mejor de resolver un problema.

Para cualquier proyecto personal es importante plantearse una fecha máxima de realización. Establecer una fecha no tiene ningún sentido si no nos comprometemos con ella. Este compromiso con uno mismo actúa como resorte que te obligará a sacar fuerzas en los momentos bajos y te hará pisar el acelerador cuando se acerca el mes en el que te habías propuesto terminar el trabajo. Nada peor que decepcionarse a uno mismo, aunque suene raro.

Páginas

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

El libro negro del programador.com
Now available in english!

Archivo

Trabajo en...

Mis novelas...