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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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, etclo 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.

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.

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.

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.

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

Archivo

Trabajo en...

Mis novelas...