Question woman

Este es un tema tan manido en nuestra profesión, tan pesado, pero al mismo tiempo tan importante, que seguimos años y años hablando de lo mismo y sufriendo las mismas consecuencias una y otra vez.

¿Están bien especificados los proyectos? ¿Se parte de un grupo de requisitos suficientemente amplio? Es cierto que en software ágil ya se da por sentando que los requisitos pueden cambiar, porque de hecho cambian, es lo natural, pero lo hacen a partir de entregas, y esto es bueno y es precisamente lo que resuelven de manera magnífica todas las prácticas y principios de lo ágil.

Sin embargo, el peor vicio de nuestra profesión consiste en no saber o no querer esforzarse lo suficiente en establecer correctamente un documento con el catálogo de requisitos o especificaciones que indiquen qué es lo que hay que hacer. Es de sentido común dejar claro lo que el cliente quiere, ¿no?, sin embargo...

Muchas veces, el que tiene que tomar los requisitos, no sabe cómo hacer ese trabajo, me temo, pero en otras ocasiones, es la pura pereza de hablar con el cliente lo suficiente lo que impide que el equipo del proyecto sepa con más exactitud lo que hay que desarrollar.

Existe una ley universal que deberíamos tener siempre presente:

Cuanto más esfuerzo se dedica a especificar, menos tiempo se emplea en el desarrollo del proyecto.

Esto es una obviedad, una sandez decirlo, pero en el día a día, metidos en la vorágine del trabajo, reuniones, visitas, etc. se nos suele olvidar este principio.

Así de sencillo, así de simple. 

No me me deja de sorprender que compañías 100% de desarrollo e implantación de soluciones software, este trabajo previo e indispensable para crear una cotización aproximada y correcta, sencillamente no se tenga en cuenta con la seriedad que debería. Sí, me temo que puedo contar casos que harían palidecer a más de uno.

Hace un tiempo lanzé una encuesta con el siguiente lema: "El tiempo que se establece para los proyectos, ¿es correcto?"

El 81% de las respuestas seleccionaron la opción "No, se suelen hacer estimaciones cortas y muy ajustadas". Genial, como para recomendar a tus hijos esa profesión...

¿Cómo podemos estimar tiempos si no llegamos a especificar correctamente un porcentaje alto de lo que el cliente necesita?

Es cierto que nos podemos guiar un poco por la intuición después de llevar muchos años trabajando en el desarrollo de productos y proyectos, pero ningún negocio puede sobrevivir basado únicamente en este olfato, ni sería serio para ningún cliente determinar el precio de una manera no profesional: "pues a este, le vamos a cobrar X, más o menos", no, de ningún modo es serio, y sin embargo en muchas ocasiones se hace así, o ojo y con prisas, me temo.

La consecuencia natural de esta forma de hacer las cosas la he comentado mucho en este blog y en El Libro Negro del Programador: desarrolladores sin tiempo de hacer bien su trabajo y presionados, clientes enojados porque no se cumplen las fechas o porque se les entrega algo que no es exactamente lo que han pedido, compañías que pierden dinero, etc. También digo que con frecuencia es el mismo cliente el que te impide hacer el trabajo correctamente y te pone impedimentos.

La solución es bien sencilla, pero como todo lo fácil, requiere de disciplina y no dejarte llevar por la comocidad: no se pasa a la fase de ejecución de un proyecto hasta que no esté en su mayor parte especificado en un documento; pero, lo más importante, ese documento debe estar consensuado con el cliente. No es necesario que ese documento sea el que contenga los requisitos software, sino que la especificación puede estar en el mismo lenguaje con el que el cliente habla y entiende su negocio; de ahí, se extraerán después los requisitos software pero es suficiente para hacer una valoración de tiempos más acertada.

Pensándolo bien, en una compañía es vital gestionar los riesgos, ¿no es un riesgo ejecutar un proyecto por debajo del precio que se va a cobrar por él?

Esta falta de seriedad en la especificación la puedo comprobar continuamente y si de otras muchas cosas dudo, de hecho, suelo dudar de casi todo, en esto no hay nadie que me pueda rebatir. La buena ejecución de un proyecto depende enormemente de lo bien especificado que esté. Parece una perogrullada decir esto, pero como sabemos del día a día, a veces es difícil ponerlo en práctica. Otra cosa es que aplicando correctamente buenos principios de desarrollo, el proyecto sea mantenible y evolucionable cuando se planteen nuevos requisitos.

Otras veces es el mismo responsable comercial de la compañía el que quiere cerrar el tema (lanzándole la pelota o el marrón a otros), y a otro asunto.

Así son las cosas. Sin embargo, un buen responsable de equipo o de proyecto, no debe aceptar la puesta en marcha de un nuevo proyecto si no tiene claro en su mayor parte lo que hay que hacer. Es como si le pidiéramos a un constructor que nos levante una casa: ¿y cómo la hago?, pues mira, más o menos...

"...no vaya a ser que cambie tu modo de pensar". Leí una vez en un libro de esos de desarrollo personal.

Comienza el año y después de tanto Rosco de Reyes (dulce típico en España y que pone fin a las navidades), te das cuenta de que ya es enero, vuelves al trabajo y esa enorme lista de propósitos y proyectos que alegremente hacías en diciembre, ahora la tienes delante y es hora de empezar a hacer cosas.

O sea, lo de siempre, comienza el camino para que al final del año, si nos seguimos acordando de esa lista, nos demos cuenta de que no hemos conseguido ni la mitad de la mitad. Es más, yo creo que esas promesas de mejora para el nuevo año entrante son más bien un tirar hacia delante y una excusa para justificar lo difícil que nos resulta actuar y hacer lo que debemos y queremos hacer. ¿O no?

Vale, sí, yo soy el primero que uso esas listas, las uso desde hace mucho con mayor o menor éxito. Uno de mis propósitos para este año se seguir leyendo más y mejores libros de todos los temas que me interesan, muchos de ellos de tecnología, otros de desarrollo personal, etc. 

¿Es que puede ser de otro modo? ¿Puede existir cualquier negocio o profesión que no avance sin seguir aprendiendo? Todo evoluciona, si no lo hacemos al mismo ritmo que todo lo demás, podemos terminar intentando vender algo a clientes de un mercado que desapareció o se transformó hace mucho.

Discrepo cuando oigo hablar de que estamos en la sociedad del conocimiento; puede que sí, que la economía sea cada vez más del conocimiento, pero las personas, en general, estamos lejos de darnos cuenta del impacto que esto supone en nuestra forma de aprender y evolucionar profesionalmente. Si los negocios cambian, lógicamente sus profesionales también. 

Es verdad que ahora disponemos de enormes recursos de aprendizaje a un coste ridículo en forma de blogs, webinars, podcasts, seminarios, videocursos, maravillosos libros en Kindle o de Google Play desde 0.99€ y que leemos desde el móvil; puede que ahora tendamos a leer más que antes y que leamos y nos informamos de otro modo. Pero paradójicamente, acumulamos tal cantidad de información que comienza a ser un problema esa misma sobreinformación porque somos incapaces de extraer conocimiento de todo ello. La hiperinformación (y la adicción a ella) comienza a considerarse algo patológico.

Lo importante no es llenar la cabeza de datos, sino saber qué hacer con ellos, a no ser que tengas complejo de loro y te guste repetir la información que lees, claro.

O sea, que no es lo mismo, en mi opinión, leerte todos los feeds de tu agregador cada día o cada dos horas, que empaparte un sesudo libro de Jeremy Rifkin analizando un tema en concreto en profundidad. Sin embargo, para la mayoría de la gente estar más informado es hacer justamente lo primero, y sólo lo primero.

No puedes avanzar en ningún tema si no lees en profundidad sobre él, y para ello hace falta la organización estructurada de un buen libro que analice el contexto, el planteamiento, las diversas experiencias sobre ese campo y que incluso se atreva a realizar algún tipo de prospección al respecto. El libro no ha muerto, de ningún modo, puede estar en la unidad de cuidados intensivos el formato papel, pero lo que es estructurar el conocimiento en forma de libro, eso va a pervivir, espero, muchísimos años. El saltar de titular en titular es para mí frivolizar y no llegar a nada.

En software ocurre exactamente lo mismo. No es igual aprender una nueva tecnología leyendo tutoriales por aquí y por allá que sólo tocan la punta del iceberg; puede servir para jugar un poco, para resolver problemas puntuales cuando ya conoces bien esa tecnología, yo lo hago muchísimo y lo voy a seguir haciendo, claro; también hay posts y tutoriales extraordinariamente buenos.

No obstante, si quieres realmente profundizar en esa tecnología, coge un buen libro y empápatelo de arriba abajo; es más, recomiendo no usar sólo un libro de referencia para ello, sino varios, ya que rara vez un único libro cubre todo lo relevante (por mucho que en el título ponga "La biblia de...").

Yo, al menos, eso es lo que hago cada vez que siento la necesidad de llegar al fondo de algo: quizá husmeo un poco por aquí y por allá en blogs de gente que sepa más que yo sobre ese tema en particular, pero siempre buscando una buena referencia bibliográfica con la que comenzar. Después asedio mi cabeza durante el tiempo que sea necesario con información sobre ese tema, libros incluídos, hasta que me siento suficientemente maduro como para seguir adelante. No es saber por saber, es aprender para hacer algo con todo ello.

Con un primer libro vas a conocer globalmente esa tecnología y seguro que encontrarás multitud de referencias para avanzar por caminos paralelos llegado el caso.

No se puede aprender seriamente algo únicamente picoteando en tutoriales de quinientas palabras; lo siento, pero no funciona así, el libro sigue siendo necesario porque te da esa visión global tan necesaria para saber usar bien lo que sea que necesitas aprender. Para mí, en un libro el autor te viene más o menos a decir "hey!, he trabajado mucho este tema y todo esto que te cuento aquí es mi experiencia sobre ello".

Así que esta es la paradoja: creemos que vivimos en una sociedad de la información cuando en realidad lo que queremos decir es que ahora estamos sobreinformados de muchas cosas pero seguimos con la misma falta de conocimiento que hace veinte años, y eso ocurre en todo, en tecnología, gestión de negocios, marketing, etc. Tenemos a nuestra disposición el conocimiento de forma inmediata y a coste muy pequeño, sin embargo el ciudadano medio, por lo general, no lo usa y se queda sólo en los titulares. Es una pena.

Por favor, ¡escribidme para decirme que estoy equivocado!

Acabo de comenzar el año con dos autoregalos, dos libros que prometen muchísimo.

La nueva fórmula del trabajoEl mundo que viene

Uno de ellos es el libro de Lazlo Bock sobre cómo están cambiando en algunas compañías la forma de organización del trabajo. El otro se llama El Mundo que Viene, de Juan Martínez-Barea, en donde se habla sobre cómo la meritocracia será un valor fundamental en el futuro (vaya, por fin).

No podemos progresar en un mundo que cambia continuamente sabiendo lo mismo que sabemos hasta ahora.

Lo siento, hay leer, pero incluso leyendo mucho te puedes encontrar abrumado y sin llegar a un conocimiento apropiado de nada e insuficiente para actuar y conseguir nuevos resultados, de ahí que leer libros bien estructurados y con la suficiente profundidad sea imprescindible, nada que ver con la inmediatez de los titulares de blogs de tecnología a la que somos tan aficionados (yo el primero, eh!), que son necesarios, claro, pero no suficientes para profundizar en nada.

El libro no está muerto, de ningún modo, el que sí lo está es quien piensa que va a obtener mejores resultados sin aprender nada nuevo.

Joer, qué serio me ha quedado esto.

Green Kiwi GamesGreen Kiwi Games © es un proyecto en el que he ido trabajando muy poco a poco en los últimos meses y que constituye lo que se llama un producto mínimo viable (MVP), esto es, un producto o proyecto que muestra la esencia de algo y que se expone para validar su propuesta de valor (o sea, si a la gente le resulta útil o no).

Si una cosa he aprendido en los últimos diez años, y no exagero, es que tu día a día como profesional termina reduciendo tus habilidades a un conjunto de tecnologías, las que usas lógicamente en la compañía para la que trabajas. Y esto no es bueno más aún cuando el cambio en nuestra profesión es vertiginoso. No obstante, en tecnología en general y en software en particular, las posibilidades son tremendas y la cantidad de tecnologías consolidadas y stacks maduros que existen te obligan a tener que estar al día si en unos años no quieres estar más obsoleto que el T-800 de Terminator.

Pues bien, Green Kiwi Games ha sido para mí la forma de profundizar en el stack MySql+Express+AngularJS+Nodejs (lo que se suele llamar MEAN, pero en esta ocasión sin MongoDB...).

Ya he hablado en alguna ocasión brevemente sobre cómo enfocar proyectos de emprendimiento desde el punto de vista del software, campo en el que he tenido mis éxitos pero también mis fracasos. Es un tema muy amplio y lamentablemente muchos proyectos fallan no por falta de una idea que pueda funcionar, sino por la ejecución del mismo proyecto y falta de disciplina para llevarlo a cabo en el tiempo. Buena ejecución, tenacidad y disciplina en el trabajo, esta es la receta en mi opinión.

En cualquier caso, todo parte de una idea que termina siendo lo que nos anima a seguir adelante porque de algún modo creemos en ella. Ahora bien, ¿cómo saber si los demás también la ven útil? Desde luego no es contándola, sino creando algo que lo muestre, algo que se pueda tocar y evaluar. De ahí lo del producto mínimo.

Pero, ¿cómo surgió la idea y qué es Green Kiwi Games? Pues bien, hace un tiempo me encontré con ciertas personas que hacían por su cuenta juegos de cartas, pero con un esfuerzo tremendo al no dominar ninguna herramienta informática y de forma totalmente manual. ¿Por qué no habilitar una web en donde el usuario subiera las imágenes y que la aplicación web se encargara de generar un pdf con las cartas listo para impresión? Sencillo, nada de otro mundo. Una idea, para ser buena, se tiene que poder explicar con muy pocas palabras. La innovación no trata de generar productos cercanos a la ciencia ficción, en cosas sencillas y banales se puede innovar también; es más, la mayor parte de la innovación pertenece a este último grupo. Tendemos a mitificar la innovación.

Eso es Green Kiwi Games, un sencillo portal que le permite a un usuario crear juegos de cartas de manera muy fácil, casi a golpe de clic. En un mundo en el que va dominando el do-it-yourself, descubrí auténticas comunidades dedicadas a hacer juegos de cartas personales y de distribución fuera de los canales habituales comerciales.

Si embargo, no hay dos sin tres, de modo que aproveché este mini proyecto para meterme de lleno en tecnologías que me apasionan, de modo que puedo decir que he pasado por todos los elementos que debe dominar un full-stack-developer y que describo a continuación.

Muy brevemente resumo todas las piezas que he ido utilizando, al menos las más relevantes:

  • Por supuesto NodeJS. He sufrido en el camino el cambio producido con la integración por fin de io.js y la creación de la Node.js Foundation, magnífica noticia para quienes amamos este entorno.
  • Express para la construcción de la infraestructura de la web con infinidad de módulos relacionados y bien integrados.
  • AngularJS para el front-end.
  • Muchísimas pruebas unitarias con Mocha para su ejecución y Chai como librería de aserciones.
  • Lodash que me ha salvado la vida para construir código más legible. Impresionante el trabajo de la gente de esta librería.
  • FabricJS tanto en el front-end como en el back-end para la construcción de las cartas.
  • ImageMagick para el tratamiento de imágenes.
  • Redis para el mantenimiento de las sesiones de usuario así como para almacenar ahí información útil y relevante y no abusar de la base de datos.
  • S3 de Amazon para el almacenamiento masivo de las imágenes y pdfs finales.
  • wkhtmltopdf para la construcción de los pdfs con las cartas construidas.
  • Grunt como gestor de tareas para la construcción del proyecto de cara a su despliegue.
  • Despliegue en DigitalOcean con nginx con un certificado adquirido desde Namecheap.
  • Y muchíisimos más paquetes y librerías.

Del mismo modo, este proyecto me ha permitido adentrarme en todo lo relacionado sobre rendimiento y seguridad web, tema fascinante y que dejan muy de lado muchos desarrolladores de aplicaciones web y con un enorme campo comercial por delante: optimización de todos los assets del proyecto, carga retrasada de imágenes sólo si se muestran en el navegador, minificación de ficheros, optimizaciones en javascript, reducción del número de requests, seguridad frente a los ataques más comunes, etc. Este tema me gusta muchísimo y de hecho estoy escribiendo unos cuadernos prácticos de cara a su publicación en 2016.

¿Y ahora qué? Realmente es después de crear el producto mínimo viable cuando se abren todas las posibilidades: el MVP es un primer paso con el que validas cualquier idea, después hay que recibir todo el feedback posible para mejorarla, pivotar sobre algunos conceptos o bien tirar la idea a la basura y a otra cosa. Esto es así, aunque lo bueno es que podemos probar ideas con una metodología sin reinventar la rueda continuamente y sin dedicar demasiado esfuerzo en ello.

Mi interés fundamental con Green Kiwi Games es ayudar a esa comunidad de creadores de juegos de cartas a realizardos y fomentar esa actividad. También conocer desde dentro la construcción de un proyecto real con esas tecnologías y no quedarme en sencillos artículos que te muestran sólo la punta del iceberg. Sobre todo, conocer de primera mano cómo se debe construir un proyecto de esta naturaleza para su escalabilidad futura en caso de tener miles de usuarios.

Si quieres conocer una tecnología, la mejor forma es construir un proyecto real con ella.

Para la idea esencial me he centrado en lo que considerado importante, no obstante, los próximos pasos serán:

  • Hacer la web responsiva. Ya sé que existe el enfoque mobile-first pero para avanzar hacia el MVP lo descarté en un principio.
  • Añadir características muy poco a poco según el feedback recibido. Me gusta en enfoque de Accuradio: si usas a menudo su servicio para escuchar las maravillosas compilaciones de música que hacen, te darás cuenta de que poco a poco van agregando pequeños detalles y mejoras, muy sutilmente.
  • Si el proyecto despega, lógicamente habrá que prepararlo para su explotación comercial con un modelo de negocio que lo haga sostenible, para lo que contaré sin duda con la empresa para la que trabajo. Para esto hay gurús que opinan que el proyecto debería generar ingresos desde un primer momento, aunque este es un proyecto personal con el que sencillamente me relajo trabajando en cosas que me gustan. Si el proyecto o su futura evolución funciona, los ingresos llegarán de un modo u otro.

Si una cosa importante he aprendido con Green Kiwi Games, es el poder de las pequeñas tareas mantenidas en el tiempo: pequeños ratos, unas horas los fines de semana, lecturas en el baño de artículos relacionados (...), en fin, cualquier momento es bueno, al cabo del tiempo, has acumulado cientos de minitareas que terminan generando un proyecto con cierta madurez y listo para su publicación. La satisfacción de hacer un despliegue final a disposición de todo el mundo es casi adictiva.

Yo insisto siempre en lo siguiente: si trabajas para una empresa, la mejora forma de mejorar tu trabajo y convertirte en intraemprendedor es crear proyectos personales en areas que no tocas frecuentemente. Las habilidades que aprendes en estos últimos terminan volcándose en tu día a día en la compañía para la que trabajas, así que todos ganan.

Uno o dos proyectos personales al año al margen de los que ocupan tu dedicación profesional si es que trabajas para una compañía: ese es siempre mi objetivo y paradójicamente, eso me ha permitido mejorar mi trabajo en la empresa sustancialmente.

Software security

Hace unos meses leíamos sorprendidos la noticia de que un grupo de estudiantes francés había descubierto miles de bases de datos MongoDB con acceso público y abiertas, no por alguna vulnerabilidad en ese engine de base de datos, sino por malas prácticas de quienes las habían implantado. Terrorífico si se piensa por un momento; puede parecer anecdótico pero el fondo de la cuestión es que la información de esas bases de datos podrían poner en situación de vulnerabilidad a personas, instituciones e incluso países. Sin llegar a exagerar, ese caso probablemente no sea más que un gota en el océano.

Admitámoslo: cuando se trabaja desarrollando proyectos, casi siempre terminan entregándose con presión de tiempo y dejando una larga estela de TO-DOs y de elementos que se podrían mejorar. Es más, pocos clientes, sobre todo si son de ese tipo que no entienden demasiado de tecnología porque su negocio o actividad es otro, ignoran cómo evaluar la calidad de lo que se les entrega: mientras funcione y lo que ven les guste, no habrá problemas, todos contentos, nosotros hemos entregado un proyecto, la compañía lo habrá cobrado y a otra cosa.

Cuando hablamos de software, hablamos de un medio que permite que otras actividades funcionen: la gestión documental de una compañía, el blog de un freelance, al firmware de una lavadora o un sistema Scada que gestiona una central térmica.

Sin embargo, ¿existe realmente interés por encarar la seguridad en el contexto de cualquier proyecto software sea del tipo que sea? No estoy hablando de software para aeronaves, plantas nucleares, etc., sino aplicaciones de cualquier tipo realizado por cualquier empresa para clientes no excepcionales (que, por otra parte, intentan pagar lo menos posible).

Esto es lo que quiero decir: la seguridad informática apenas es un aspecto relevante para la mayoría de desarolladores de software, y es así no porque ignoremos técnicamente cómo afrontar esos temas, sino porque en general no existe una cultura tecnológica extraordinariamente preocupada por exigir consumir software con todos los estándares de seguridad. La ciberseguridad sigue siendo más un término de películas de ficción que una auténtica preocupación masiva en toda nuestra industria.

Tanto si se trata de un simple proyecto que de ser vulnerado puede tener poca o ninguna repercusión, hay muchos otros proyectos para los que cualquier incidencia de seguridad puede ser un auténtico problema: desde la pérdida de horas de trabajo y una enorme frustración para la gente afectada hasta la seguridad física de personas e instalaciones. Y no exagero, en absoluto: por poner un ejemplo, uno de los productos que comercializamos en la compañía para la que trabajo puede dejar literalmente sin luz a miles de abonados de compañías eléctricas. ¿Y si alguno depende de un soporte vital? Es un tema bastante serio que conviene no frivolizar.

La seguridad es importante, extraordinariamente importante, sobre todo en un momento en que toda nuestra economía no sólo es adicta al petróleo sino que también depende de la tecnología para seguir funcionando. Para muchas plataformas, una hora sin funcionar puede significar mucho dinero (aparte de dar una imagen poco profesional), pero también para una pequeña web de una empresa familiar puede suponer muchas horas perdidas para resolver el problema.

Digo yo que para tratar mejor el tema de la seguridad en nuestros trabajos debemos tener también cierta faceta de hackers y actuar como pentesters.

Mr RobotNo hace falta pensar en la seguridad como se plantea en series como MrRobot, no es un tema que vaya de super-hackers con problemas de socialización y de una subcultura de frikies. La seguridad en software está también en nuestro día a día, sea cual sea el tipo de software al que nos dediquemos, no importa las plataformas que usemos: debe formar parte del roadmap de cualquier desarrollo en el que trabajamos.

Pero, ¿cómo? Es cierto que los mismos responsables de proyectos pueden frivolizar sobre este tipo de cuestiones, lo pueden ver más como un coste que como un elemento de calidad diferenciador. Del mismo modo, en cualquier actividad profesional hay que minimizar los riesgos, por tanto, como tareas de desarrollo hay que incluir algún tipo de aseguramiento de la seguridad, tanto a nivel de diseño, configuración de la plataforma en la que nos basemos y también a nivel de despliegue, y, lógicamente, el cliente debe ver ese trabajo como una aportación positiva al proyecto (y por tanto estar de acuerdo y pagar por él).

¿Será un buen momento para diferenciarse profesionalmente como desarrollador experto en seguridad? Desde luego el tema da para mucho.

Lejos de declaraciones grandilocuentes, algunos sencillos ejemplos que podemos tener en cuenta con relativamente poco esfuerzo:

  • Se si usa cualquier repositorio de datos con información sensible, ésta se debe guardar encriptada.
  • Las contraseñas para acceder a middlewares o servicios externos deben ser fuertes, como las security keys que se usan en Amazon o Azure para acceder a servicios en la nube.
  • Si se usa un fichero con contraseñas de acceso de algún tipo, tenemos que garantizar que este no esté accesible una vez desplegado el proyecto (cosa obvia) y, por qué no, pensar también en encriptar el mismo fichero.
  • Si se tiene un cliente web, las validaciones de datos se deben hacer tanto en cliente como en servidor.
  • Cualquier infraestructura software IT que se utilice (servidores web, protocolos, sistemas operativos, bases de datos), se debe revisar en producción y garantizar que estén correctamente configuradas.
  • Y un larguísimo etc...

Por otra parte, habrá clientes a los que les gustará muchísimo ver un anexo sobre seguridad en la propuesta del proyecto. En mi opinión, una empresa que provee software y hace hincapié especialmente en la seguridad de sus desarrollos, además de necesario, se debe percibir como de mayor calidad, por lo que puede ser un argumento diferenciador con respecto a los competidores.

La seguridad en software tiene muchas vertientes; es un tema tremendamente extenso. Como simple perla, para cualquier aplicación web:

  • ¿Aguantaría un ataque DDoS (ataque por denegación de servicio)?
  • ¿Incorpora filtros XSS (cross-site scripting) y evita Sql Injection?
  • ¿Tiene en cuenta el servidor web, sea el que sea, la vulnerabilidad http pollution?
  • ¿Está el servidor web configurado correctamente para ocultar la cabecera "X-Powered-By" o tiene implantado el mecanismo HPKP (http public key pinning)?
  • ¿Implementa la táctica frameguard?
  • ¿Los formularios incorporan el token CSRF (cross site request forgery)?
  • Y aquí también otro larguísimo etc...

¿Ejjj, cómo? Yo no me considero experto en seguridad, ni mucho menos, pero es un tema que cada vez me interesa muchísimo más; si desarrollas aplicaciones web y los conceptos anteriores (cogidos al azar de entre muchos otros) te suenan literalmente a chino, ve pidiendo formación a los Reyes Magos del 2016 o un buen lote de libros para mejorar en ese aspecto.

Es cierto que ser absolutamente exhaustivos con todas las cosas a securizar será una labor extraordinaria, pero, al menos, se podría incluir un checklist en cada proyecto que asegure que se cumplen los elementos de seguridad imprescindibles.

Por cierto, y hablando de seguridad ¿por qué los hackers, al menos ciertos hackers mediáticos, aparecen siempre con un aire desaliñado, gorritas, camisetas y con barba de varios días? Curioso... :-)

Project Planning PictureEsta es la realidad: la mayoría de los desarrolladores y gestores trabajamos en proyectos para un cliente específico final. Es decir, hay un cliente que genera unas especificaciones y un equipo que las desarrolla (en el mejor caso esos requisitos están claros al principio aunque lo habitual es que no lo estén).

¿Pero es que puede haber otra cosa? Claro que sí, no tiene absolutamente nada que ver la dinámica de trabajo en un proyecto que la dinámica de desarrollo de un producto software.

Ya he hablado en alguna ocasión sobre esta cuestión, pero ahora quiero enfatizar qué aspectos en el desarrollo de proyectos se deben cuidar mucho para evitar que tanto los equipos de trabajo como la misma compañía caigan abrumados bajo el peso de multitud de proyectos mal gestionados y mal cotizados.

El desarrollo de un proyecto está lleno de detalles y todos cuentan: el resultado final es un conjunto de aspectos que se han ido haciendo suficientemente bien, como en cualquier otra actividad profesional. Si descuidamos algunos, se notará en el resultado final. Sencillo de entender, ¿no?

Recientemente he visitado una empresa en la que he visto que se dan algunas de estas circunstancias: gente con ganas de hacer las cosas mejor pero agotadas de las guerras del día a día en que no hay tiempo de pararse un momento y ver qué no funciona o qué se puede mejorar. No hay que ser muy listo para evidenciar qué se está haciendo mal o qué impide que las cosas avancen mejor, el problema es que tú puedes pensar algo pero tiene que ser el gestor del equipo, sus jefes o el responsable de la compañía el que ponga los medios para que la gente trabaje correctamente y decida también cambiar cómo se hacen las cosas. Esto también es algo típico: la incapacidad de ver que los resultados dependen de eso...

Y no sólo se trata de disponer de la infraestructura mínima necesaria, también de mantener una disciplina metodológica en la forma en que se decidan hacer las cosas. Yo creo que no hay más, lo difícil realmente es seguir esa disciplina y los procedimientos establecidos.

Surver Monkey Logo

He creado esta pequeña encuesta sobre los puntos que vamos a ver a continuación.

Si te sientes identificado con algo de lo siguiente, enhorabuena, perteneces a una cultura de trabajo muy extendida en nuestro sector (con poca productividad y resultados pobres que se pueden mejorar). Todo lo que indico a continuación es demasiado obvio y a muchos les sonará a principios básicos, no obstante, ¿se cumplen en la mayoría de compañias de software?

#1 Un proyecto bien estimado en tiempo nos permite trabajar mejor

Cosa obvia aunque lo habitual es que los proyectos se consigan reduciendo los tiempos al máximo y cotizando las horas por lo bajo..., ¿resultado?, proyectos que tienen que salir sí o sí con poco tiempo y, por tanto, en su desarrollo deberemos ir abandonando las buenas prácticas de trabajo (las conozcamos o no, que esa es otra).

Básicamente, los proyectos se cotizan por horas y éstas por los perfiles de la gente que va a participar en ellos (dentro de la misma compañía suele haber perfiles más caros que otros).

Por tanto, si ese trabajo de estimación de horas no se hace bien, habrá dos posibles consecuencias: o vamos a reventar al equipo con mucha presión (cosa no mala sino malísima) o bien la compañía va a perder dinero (que tampoco es nada bueno, vaya).

¿La solución? La estimación se debe hacer por lo alto y contando con la opinión de las personas más relevantes que van a participar en el proyecto, añadiendo también alguna desviación. Esto es fácil de decir y difícil de llevar a la práctica, de ahí que las habilidades comerciales permitan conseguir esto. Seguramente de este modo va a salir un precio mayor que el cliente va a intentar regatear, que ese es otro tema, no menos importante.

Comercialmente no se puede disparar a todo lo que se mueve sin darnos cuenta de que igual que hay compañías que trabajan mal, también hay clientes que conviene no tener. Difícil decisión en épocas de crisis, claro.

#2 La especificación tiene que ser lo más completa posible

Este es el gran caballo de batalla de nuestra profesión en la que lo normal es que los clientes no tengan claro al 100% lo que realmente quieren o necesitan. No obstante, un buen comercial debe ser capaz de ayudar al cliente y extraer de él lo que quiere.

Lo importante de esto es que se debe adquirir el compromiso de que una vez establecida la especificación, ésta no debe cambiar (al menos demasiado) a lo largo de la ejecución del proyecto, y, si cambia, si nos obligan a cambiarla, entonces tenemos que repercutir en el cliente los excesos de tiempo que supongan. Claro, esto tampoco será sencillo, pero el cliente debe entender que no trabajamos por amor al arte y si los números no salen, pues no salen.

Para ello es necesario un trabajo comercial que sea capaz de llevar al cliente al terreno que nos interesa.

#3 Evitar la dispersión de tecnologías

A menos que la compañía cuente con muchísimas personas con perfiles muy distintos, lo normal es que sólo se dominen algunas tecnologías y se sepa algo de otras.

Al cotizar un proyecto hay que tener en cuenta el grado de conocimiento que tiene el equipo en las tecnologías que se van a usar. Si el equipo no conoce bien, por poner un ejemplo, JSF, entonces estamos obviando la curva de aprendizaje (igual a tiempo) en que se va a incurrir durante la ejecución del proyecto. Es, digamos, un coste oculto que hay que tener en cuenta.

No nos engañemos: si bien hay gente que en sus horas no laborales pasan gran parte del tiempo empapándose de manuales o haciendo proyectos por su cuenta, mucha gente no toca esos temas fuera de la oficina.

¿La solución? Intentar contratar proyectos en cuya ejecución se utilicen las tecnologías que mejor se conocen: esto es garantía de productividad (y rentabilidad).

En mi opinión nada peor que un equipo que le da a muchos palos (para mis lectores latinos, "darle a muchos palos" = hacer cosas muy distintas). Sólo podemos ser expertos en pocas cosas y, por tanto, la rentabilidad y productividad va a venir de la mano de esas tecnologías que conocemos mejor. Estamos hablando de hacer un proyecto rentable, no de querer jugar con MongoDB porque mola y voy a forzar a usarlo en el proyecto X sencillamente porque me gusta, no porque realmente encaje en él.

#4 Hay que usar algún tipo de gestión de la configuración

El día a día en el trabajo está lleno de pequeños momentos y detalles que podemos hacer bien, ejecutar en segundos o hacerlos rematadamente mal. Todo detalle cuenta, de modo que la falta de fluidez en el trabajo se debe a ejecutar mal parte o todos esos detalles del día a día.

No hay nada que afecte más a la productividad de un desarrollador que una mala gestión de la configuración: aunque sea simple, se debe establecer. 

¿Cuánto tiempo hemos perdido a veces porque se ha roto la compilación o porque hemos querido volver atrás en el código y esto ha sido imposible?

No es sólo usar un repositorio de código (me da vergüenza hasta escribir esto, pero es que hay quien trabaja sin usar ninguno), también establecer unos mínimos procedimientos sobre cómo usarlo para un equipo de varias personas.

En cuanto a la gestión de la configuración está todo inventado, no hay que innovar, sólo céntrate en las buenas prácticas buceando mínimamente en Internet.

#5 Hay que crear cierta documentación

Vale, sí, esto es obvio pero ¿hay alguien en la organización que exija que se cierre el proyecto con una mínima documentación? No estoy hablando sólo de la guía de usuario para el cliente final (si es que este la exige), sino de todo aquello que debamos documentar mínimamente para poder retomar el proyecto de manera rápida en el futuro. 

Yo siempre insisto en hacer una guía de diseño con todos aquellos aspectos sobre el diseño y la arquitectura que se deban explicar y que no sean evidentes; también una guía de despliegue exhaustiva que nos garantice que podemos instalar y hacer funcionar el proyecto en un nuevo entorno. Esto es tremendamente productivo y generalmente consume sólo unas pocas horas (muy pocas en comparación con cualquier proyecto). Ese tiempo meses más tarde, a la hora de asumir el proyecto de nuevo, pueden ahorrar mucho más y la frustración de hacer ingeniería inversa para ver cómo se han hecho las cosas.

No se puede dar por cerrado un proyecto si no se crea la documentación exigida; es más, se debe ver si ésta se puede realizar a lo largo de la ejecución del proyecto.

Al cotizar el proyecto se deben incluir unas horas dedicadas a la documentación. No es exagerado incluir un 5% de tiempo dedicado a este trabajo.

#6 En lo posible, hay que practicar el enfoque ágil en los proyectos

En la mayoría de proyectos podemos poner en práctica todas aquellas características del desarrollo ágil que nos permite avanzar con productividad. Puesto que un proyecto será rentable si está bien cotizado y si se realiza en tiempo, entonces hay que cuidar mucho todo aquello que suponga ahorrar horas de trabajo.

South Summit 2015 logo

El pasado 7 y 8 de octubre estuve en uno de los mayores eventos sobre start-ups del sur de Europa, el South Summit, en un auditorio un poco peculiar (la Plaza de Toros de Las Ventas de Madrid). Vinieron muchísimos asistentes de todas partes del mundo y la agenda estaba cargada de interesantísimas charlas con actores de primer nivel, tanto de empresas muy conocidas como inversores de capital riesgo y business angels.

Si bien había empresas ya consolidadas y starts-ups de muchos tipos distintos, la mayoría tenían una base tecnológica que, de una manera u otra, incorporan el software como pieza fundamental. Todavía me preguntan si las ciencias de la computación tienen futuro o no.

Me llamó mucho la atención algunas colas que vi en algún momento de gente que iba a presentar sus proyectos a inversores con el típico pitch que no puede durar más de unos pocos minutos.

Estuvieron desde la deslumbrante Gwynne Shotwell de SpaceX hasta Adeyemi Ajao, actualmente en Workaday y que fue uno de los fundadores de Tuenti (el Facebook español), pasando por Paul Ford de Sendgrid y Jeroen Merchiers de Airbnb, que dio una interensantísima charla de título "Disrupting Markets: The Sharing Economy" junto con muchísimos otros de areas y mercados distintos. 

Gente inspiradora que sin duda tienen muchos fracasos detrás para conseguir cualquier éxito.

Quería hablar un poco de mi experiencia asistiendo al South Summit, pero también reflexionar por qué debemos incorporar en nuestra agenda el salir de la oficina de vez de en cuando para asistir a charlas o reuniones profesionales.

Siempre intento estar un poco al tanto de seminarios y eventos interesantes a los que pueda asistir. Cuesta muchísimo trabajo sacar tiempo de tu día a día y organizarte para asistir a cualquier tipo de charla o sesión. En muchas ocasiones tienes la sensación de que has perdido el tiempo y en otras vuelves encantado por la gente interesante que has conocido o por las inciativas fantásticas que has visto.

Viendo lo que hacen otros, aprendes a encaminar mejor todos tus nuevos proyectos e iniciativas, tanto si te consideras un llanero solitario o un auténtico intraemprendedor que propone mejorar continuamente el camino de la empresa en la que trabajas.

No voy a repetir eso tan manido de que vivimos en un mundo interconectado, aunque no siempre entendemos que esta interconexión no consiste en enviar invitaciones masivas a cuentas de LinkedIn a tipos que crees que te pueden aportar algo. En mi opinión, trabajes desde donde trabajes, forma parte de nuestra profesión asistir a eventos relacionados con tu día a día y puntualmente también a eventos que crees que están un poco fuera de la órbita de tu sector. Terminas conociendo a gente que tiene los mismos problemas que tú pero también a quienes ya han llegado adonde tú quieres llegar (si es que tienes algún tipo de meta profesional, claro) y que todos, absolutamente todos, han avanzando resolviendo problemas, aportando valor a sus clientes y viendo las cosas de otro modo.

¿Habrá alguna relación entre aquellos que consiguen mejores resultados y su asistencia continua a foros, seminarios, eventos, encuentros profesionales, etc.? Estoy seguro de que sí.

Por mi parte intento asistir a todos las citas que veo más o menos interesantes, a veces me resulta imposible por motivos de agenda. En muchas de las que asisto suelo salir de ellas con información interesante y valiosa que mejora la actividad de tu compañía; lo considero también un tipo de formación.

Lean Pricing book coverNo en vano, también estuve recientemente en Madrid en un seminario impartido por Microsoft para ISVs (independent software vendors) de donde salimos encantados entre otras cosas por la charla que nos dio Omar Mahout, autor del libro Lean Pricing (que por cierto, nos regalaron) y por la apuesta total de esa compañía por Azure y la oportunidad para empresas desarrolladores de software de estar presentes en el Azure Marketplace.

Y es que no es sólo información lo que te traes, también los contactos de compañías y personas con las que puede que en algún momento puedas colaborar; también te traes deberes en forma de muchísima información que después tienes que digerir e investigar más por tu cuenta si es que piensas que le puedes sacar algún provecho.

Productivity

Me encanta prototipar, probar conceptos, ideas y ponerlas en marcha sencillamente para validarlas o por profundizar en tecnologías que me gustan. Esto creo que es uno de los vicios de muchos desarrolladores, la necesidad sana de aprender cómo funciona tal framework, cómo desplegar con Heroku o cómo funciona el mecanismo de plugins de cualquier software, por poner algunos ejemplos.

Ahora bien, si queremos probar una idea no podemos perdernos en los detalles y desviarnos así del asunto relevante que queremos conseguir. No obstante, veo lo fácil que es perderse en esos detalles y no centrarse en lo importante realmente, lo que aporta valor al proyecto, producto o idea que estamos probando.

De ahí el conocido mantra en nuestra profesión de poner el foco completamente en la funcionalidad particular de un proyecto de modo que la general debe ser cubierta por el entorno a usar en forma de librerías reutilizables, plugins, extensiones, plantillas, etc, cualquier cosa, en definitiva, reutilizable.

Es como si se nos planteara realizar una plataforma para la gestión empresarial y decidiéramos hacerlo todo desde cero y no contar con algunos de los productos que ya existen como base en el mercado. Sería, cuanto menos, inviable en términos de tiempo y esfuerzo.

Sin embargo no siempre pensamos en adquirir alguna solución de tipo comercial ya existente y comenzar a partir de ella y, de nuevo, caemos en el error de reinvertar la rueda una y otra vez, sin evaluar realmente el coste de esto. Una cosa es investigar e implementar por simple gusto o curiosidad en tu tiempo libre y otra muy distinta justificar decisiones en tu compañía que supongan costes extra que se pueden evitar.

Vicio, mala práctica o pura ignorancia, este es uno de los déficits habituales de muchos desarrolladores que, además, es de camino inverso: no saber seleccionar componentes del mercado o de código abierto y también no saber desacoplar lo suficiente lo que se hace para reutilizarlo en un futuro.

No sólo estoy pensando en grandes productos comerciales que hay que configurar y adaptar a necesidades específicas, sino en pequeños componentes desde plugins gráficos, templates, engines de búsqueda, etc.

Hoy día existe un auténtico mercado en el que se pueden adquirir a un precio que resulta irrelevante para el esfuerzo que tendríamos que dedicar a hacer algo similar (y seguramente, no con la misma calidad por no ser tan expertos en ese tema en concreto).

Sí, para casi todo existe algo open source y de excelente calidad, por lo que también es una alternativa a considerar aunque no podemos cerrar puertas y usar algo libre (y gratuito) porque sí, cuando podemos encontrar cosas por pocos euros de mejor calidad. ¿Qué son unos cuantos euros cuando te pueden ahorrar decenas de horas de trabajo?

Recientemente hemos adquirido un tema para un landing page de un nuevo producto que hemos lanzado: necesitábamos una página de inicio muy atractiva, sencilla, con pocos contenidos y que resultara moderna, así que decidimos usar parallax que tanto se ve en los últimos dos años. Algunos buenos ejemplos de este tipo efectos aquí.

Moda o no, la realidad es que implementar una página de inicio así y que además sea responsiva tiene muchísimo trabajo y hay que ser un buen experto en HTML5 y CSS3 para realizar una buena implementación, sin hablar de los aspectos estéticos y de diseño. Además, no me quiero ni imaginar el esfuerzo de asegurar que la implementación se lleva bien con todos (o la mayoría) de navegadores y dispositivos... Imposible de asegurar a no ser que dispongas de muchísimo tiempo para probarlo.

¿Por qué centrarte en ese desarrollo (que no es el core de tu sistema) cuando puedes adquirir por poco dinero una solución profesional y ya implementada, usada por cientos de usuarios y extraordinariamente depurada? ¿No es como contratar a alguien muy bueno en su nicho por poco dinero y tenerlo a tu disposición? Muchos fracasamos en algunos proyectos por no poder vencer esa necesidad (un poco egocéntrica) de querer hacerlo todo uno mismo, no saber delegar (adquirir componentes externos es una forma de delegación) y no saber centrarnos realmente en lo importante del proyecto.

Decidimos usar un paquete desde Envato Market que nos costó.....8 dólares, cantidad de dinero que además te da la oportunidad de preguntar al mismo autor y ver multitud de ejemplos. Es decir, unos cuantos cafés por algo que al menos yo tardaría en implementar semanas y de lejos tan bien como un experto en esas técnicas.

¿No es eso una muestra de productividad? Otra cosa es personalizar el componente lo suficiente para que todos tus trabajos no parezcan iguales.

Por 8 dólares tienes a tu disposición un desarrollador que ha trabajado mucho en ese paquete que estás comprando y que precisamente por estar más especializado en esa área lo va a realizar seguramente mejor que tú. El desarrollador gana porque su componente se vende cientos o miles de veces.

El concepto de reutilización está en las entrañas y en la esencia del software, pero no siempre lo tenemos 100% presente.

A ver, es que me he encontrado con ciertas actitudes de desprecio cuando uno comenta que recurre a Bootstrap o cualquier otra cosa como si eso fuese poco profesional: lo profesional es aprovechar tus recursos (tiempo) lo más productivamente posible. La última palabra la tiene siempre el cliente, que es el que dice si le gusta o no y realmente lo no profesional es suponer un coste de un mes de trabajo a tu empresa cuando ese mes se puede reducir a unas pocas horas por invertir unos cuantos euros en un componente ya existente.

Ahora mismo existe un gran ecosistema de componentes de modo que muchos desarrolladores que trabajan en proyectos, más que desarrollar software, pasan la mayor parte de su tiempo integrando distintas piezas de software reutilizables para conseguir la funcionalidad particular que le pide el cliente, lo cual no deja de ser un aspecto interesante de nuestra profesión.

Yo no veo que esto sea malo ni muchísimo menos, sino que es una forma maravillosa de no realizar trabajo doble y además puedes participar sin ningún problema en todo ese mercado de venta de componentes y librerías ofreciendo tus propios desarrollos: plugins, themes, etc., lo cual, además, te puede dar cierto prestigio como profesional.

La pregunta de este post es algo típica pero no menos importante; recientemente leía que en un 70% de los casos de gente que abandona su empleo, en realidad están huyendo de sus jefes. Lamentable, sobre todo porque un buen profesional se puede echar a perder si no se rodea del equipo adecuado, pero, en especial, de un jefe (manager o coordinador) que haga bien su trabajo. También oí una vez decir a Sergio Fernández que uno tiene que poder elegir a su jefe. Sea así o no, la realidad es que un mal gestor puede hacerte la vida imposible y uno bueno puede hacer que vayamos a la oficina con una motivación extraordinaria.

Entre otras cosas, dirijo equipos de desarrollo desde hace mucho tiempo y llevo años con la convicción de que un buen proyecto tiene éxito no sólo por la profesionalidad con la que se encara, también por el buen hacer de quien tiene ese trabajo de coordinar el de los demás.

Nunca me ha gustado la palabra jefe, ni manager (¿pero por qué en LinkedIn todo el mundo se etiqueta como manager de algo?), por sonarme demasiado a jerarquía o como si dentro de cualquier organización unas personas fuesen más importantes que otras. Cada uno tiene su papel y para que todo funcione, cada uno, individualmente, tiene que hacer el suyo de manera profesional. Sí, esto suena muy democrático y guay decirlo, no lo es tanto aplicarlo en el día a día. Esa idea de "todo vamos en el mismo barco", "el equipo es lo primero", etc. que tanto les gusta a los managers de medio pelo repetir, no siempre se traduce en acciones reales. Vamos, que una cosa es lo que se dice y otra muy distinta lo que se hace.

Pero, ¿en qué consiste en realidad ser un buen gestor?, ¿puede un proyecto con éxito considerarse como tal si el equipo de trabajo está quemado y el gestor es el que se lleva todas las medallas ($)?, esto último es tanto como decir que las empresas y compañías existen sólo para hacer dinero y generar beneficios. No, no sólo deben existir para eso, los beneficios deben ser una consecuencia de hacer las cosas bien y proveer de un trabajo de calidad a todas las personas que forman parte de esa organización. 

En cierta forma, un proyecto software tiene una naturaleza un poco especial a diferencia de otro tipo de trabajos, de modo que hay que conocer bien esos detalles diferenciadores para que todo vaya bien. 

¿Quieres mejorar como gestor? ¿Quieres evaluar a tu jefe y a lo mejor ponerlo a caldo? Pues sigue leyendo.

A continuación indico lo puntos claves y básicos que en mi opinión hacen de un gestor un buen responsable de proyectos software:

  • Conoce en todo momento lo que hacen los miembros de equipo que dirige.
  • Nunca ordena sin más: planifica y organiza para que se sepa en cada momento lo que tiene que hacer cada uno y todo el mundo conoce la coherencia y el contexto de las tareas encargadas.
  • Para golpes: puesto que tu jefe tiene seguramente sus propios jefes, es fundamental que actúe en ocasiones como paraguas. En otras palabras, los miembros del equipo tienen que aislarse del ruido de fondo, ansiedades o guerras internas de otras partes de la compañía. La creatividad no puede surgir en un entorno envenenado y donde la presión y el estrés se pueden palpar.
  • Estimula y motiva, esto es, aplaude las mejoras y los logros y siempre realiza críticas constructivas con ánimo de mejorar. 
  • No sabe lo que es un error: llama "resultado mejorable" al error fracaso.
  • Comparte conocimientos: si el gestor lo es porque cuenta con más años de experiencia y está curtido en muchas batallas profesionales, su función es trasladar ese conocimiento al equipo.
  • Nunca se fija en lo personal, siempre en los resultados aportados de cada uno.
  • Delega: es muy típica la desconfianza de muchos gestores que creen que como ellos nadie puede hacer esa tarea en apariencia complicada o de responsabilidad. Esto es un error, he visto infinidad de veces cómo cuando a los miembros del equipo se les da responsabilidad y sobre todo, confianza, pueden llegar a hacerlo mucho mejor que tú y, por tanto, todos salen ganando: el primero porque delega, el equipo porque así gana experiencia.
  • Asume los fallos: esto puede parecer un poco heavy de decir, pero si un miembro del equipo mete la pata, y la mete hasta el fondo, el responsable es su jefe o manager. No hay más. La cara al resto de la organización la tiene que dar él. Cuántas veces gestores (que yo llamo barriobajeros,  chanchulleros o trepadores) acusan firmemente con el dedo a la gente del equipo para esquivar los golpes. Como en todo, si una persona no es honesta fuera del trabajo, ¿por qué lo va a seguir siendo dentro? Quiero decir, somos las personas que somos en todo lo que hacemos.
  • Promociona los buenos resultados siempre que puede entre el equipo. Los equipos tienen el derecho de progresar, en lo económico y en lo profesional. En muchas ocasiones, el gestor es el interlocutor con el resto de la organización para hacer eso posible. Si no mejoras es que empeoras. 
  • Busca equipos coherentes. En el equipo todos tienen que aportar y se tiene que respirar un buen clima de trabajo, proactivo y estimulante. No se puede transmitir al equipo tus propias ansiedades, incertidumbres e inseguridades. ¿Quién no ha tenido alguna vez un jefe alicaído, negativo, protestón y que contagia estrés a los demás? ¿Se puede promover la creatividad y la innovación en un ambiente así?
  • Un jefe quizá necesite más formación que nadie, de modo que debe ser una persona que se recicla continuamente. ¿Por qué? Un gestor de equipos debe dominar ciertas habilidades no necesariamente técnicas: debe comunicar bien y eficazmente, debe organizarse de manera extraordinariamente productiva para cumplir con sus obligaciones, debe saber gestionar y motivar a las personas, entre otras cosas. Al final anoto una serie de libros que me gustan en este sentido.
  • Trabajar con gente tiene a veces sus sinsabores: el gestor debe identificar cuándo un miembro del equipo no funciona y por qué, por la razón que sea, y apartarlo del mismo. En alguna ocasión he provocado que algunas personas salgan de la compañía donde he estado trabajando en ese momento (por falta de compromiso y de competencias de esas personas, claro), os aseguro que es muy duro, te quita el sueño (literalmente), pero es necesario para que el trabajo salga adelante. Irónicamente, con el tiempo los equipos involucrados me agradecieron esa actitud de firmeza.
  • Un buen responable no puede nunca tener favoritismos hacia nadie, esto crea una sensación de injusticia entre la gente.
  • Pero, sobre todo, un buen gestor pone los medios para que el equipo trabaje tranquilo, centrado en las tareas de cada momento y con los medios adecuados.

Seguramente este tema dé para escribir un libro entero y más de uno esté calificando del uno al diez a su propio jefe según los puntos anteriores.

Siempre lo digo y no me cansaré de repetirlo: el éxito de un proyecto software es el éxito colectivo de todos los miembros del equipo, desde el diseñador, los desarrolladores, el gestor y el empresario que ha apostado por ese proyecto.

Si quieres saber más, aquí te recomiendo muy brevemente algunos libros que leí hace tiempo y sus enlaces directos a Amazon, una selección un poco heterogénea entre académica y de desarrollo personal, porque un buen gestor debe dominar muchas facetas de su desarrollo como profesional (buen orador, comunicador eficaz, buena organización del trabajo, etc.)

Behind Closed Doors: Secrets of Great Management, magnífico libro sobre gestión.

Aprendiendo de los mejores: Tu desarrollo personal es tu destino, de Francisco Alcaide. He descubierto a este autor este verano y he leído varios libros suyos. Un buen libro de motivación para mejorar en todos los aspectos de tu vida, también el profesional.

Organízate con eficacia: Llega más lejos de lo que nunca hubieras imaginado, básico para poder afrontar una buena organización del trabajo.

Cómo hablar bien en público e influir en los hombres de negocios (Elipse), libro de cabecera para aprender a transmitir tus ideas y comunicar bien.

Avanza el verano y en breve me tomaré unas semanas de vacaciones. Es como una especie de parón en tu día a día, en el trabajo, en la rutina familiar.

¿Cómo ha ido en un sentido general esta primera parte del año? No puedo evitar hacerme preguntas de este tipo. Así que aunque no soy muy dado a compartir reflexiones introspectivas en mi web, haré un resumen de este agitado año, al menos desde el punto de vista profesional y técnico, de todas las cosas y temas con los que he tratado.

Durante esta primera parte del año hemos cerrado proyectos importantes y abiertos otros nuevos, trabajamos en la realización de un prototipo software con el que vamos a preguntarle al mercado el interés que puede haber en él y planteamos ya una revisión profunda de uno de los productos que comercializamos.

Del mismo modo he avanzado en varios proyectos personales (he registrado mi primera marca) y por fin hemos puesto la primera piedra, como se suele decir, en otro proyecto después de tres años de planos, arquitecto, licencias, etc.

Lo que me pregunto es cuánto hay de mi forma de gestionar los proyectos software que dirijo en todos esos proyectos que, digamos, se gestan fuera de mi horario laboral, y al revés. En definitiva, creo que para cualquier actividad valen los conceptos de definición de roles y en todas es mucho mejor la colaboración que la imposición. Es liberador saber que no tienes que llevar siempre la razón y que el mundo se modela a medida que haces cosas y resuelves problemas.

Lo que sí sé es que en todos esos proyectos, sean del tipo de que sean, se avanza resolviendo problemas. No hay más. Emprender en algo consiste en resolver los problemas que van surgiendo de la forma más ágil posible. En realidad, cualquier problema es algo que tienes que aprender y sólo la carga emocional negativa que le quieras dar es lo que lo convierte en un problema. En fin, que divago.

A continuación escribo sobre lo mas significativo para mí de esta primera parte del año.

Javascript y librerías relacionadas

Parece ser que estamos viviendo un gran auge de un lenguaje que tiene muchos años: puesto que se está imponiendo la web en casi todo lo que hacemos y afortunadamente vamos convergiendo hacia estándares, Javascript tenía que jugar un papel muy importante.

En mi opinión esto será aún mejor cuando se popularice la revisión del lenguaje ECMAScript 6, revisión con la que se le dota de una mayor madurez y que contiene características que los desarrolladores acostumbrados a otros entornos siempre hemos echado en falta. ES6 es como el hermano mayor de Javascript con el que irán convergiendo todos los entornos (NodeJS), liberías (AngularJS) y frameworks que usan este lenguaje.

No obstante, me sorprende que exista cierta cultura de clean code y de refactorings continuos pero por alguna razón ésta siempre se aplica a lenguajes como C# y Java y no siempre a los desarrollos de Javascript, de modo que es muy fácil encontrar código en este lenguaje por todas partes verdaderamente sucio, no hay más que husmear desde Firebug o la DevTools de Chrome con cualquier web y descubrir cosas realmente significativas y curiosas en webs que reciben miles de usuarios diarios. Hay mucho por hacer...

AngularJS

Comencé con AngularJS en 2014 y desde entonces lo he usado en todos los proyectos que he dirigido con interfaces web. 

Aunque es más apropiado para SPA (single page applications) se puede sacar provecho de esta librería en cualquier aplicación web. Sin ninguna duda, una solución intensiva en código Javascript es más rápida de escribir y si se cuida bien la organización de los assets, queda muchísimo mejor estructurada de cara a su mantenimiento y evolución.

Como todo: un buen uso de AngularJS da lugar a una solución clara, limpia y bien estructurada, un mal uso puede generar una solución realmente sucia y difícil de seguir.

Me encantan las directivas de AngularJS; recientemente estoy viendo más y más publicaciones sobre Polymer, librería para crear componentes webs que aún no conozco del todo y similar a las directivas de AngularJS.

Flujos de trabajo para casi todo

Cualquier trabajo no es sólo una cuestión de realizar una tarea concreta con un comienzo y un final, ésta tiene que estar enmarcada en un procedimiento o flujo de trabajo que ordene cómo realizar las tareas.

Del mismo modo, cualquier trabajo que se tiene que repetir y que puede ser más o menos complejo se tiene que organizar para que cuando se repita, se haga correcta y eficientemente. Esta primera parte del año me ha tocado definir flujos de trabajo en distintos contextos. Lo más relevante de esto es que veo que casi nadie se preocupa por formalizar este tipo de procedimientos para que no haya que re-pensar una y otra vez cómo hacer las mismas cosas (perdiendo un tiempo precioso en el camino).

A nivel técnico, he usado intensamente grunt para una aplicación web en la que trabajo desde hace un tiempo y he escrito varios procedimientos acerca de su despliegue ordenado, validación, etc.

Igualmente, hemos comenzado un proyecto (ajeno totalmentae al software) que consiste en la construcción de unos alojamientos rurales, después de varios años de proyecto, planos, permisos, etc. Puesto que somos varias las personas implicadas, tanto los dueños como el arquitecto, el aparejador, el constructor, etc., he definido lo mejor posible el rol de cada uno para que a cada paso que haya que dar no tengamos que hablar todos-con-todos, bloqueando la toma de decisiones del día a día y suponiendo una carga de trabajo adicional (e innecesaria). Esta es la única forma de avanzar en los distintos proyectos que tienes en tu vida profesional y personal, o eso espero, ¿?

GIT no sólo para código

Me encanta GIT, ¿a quién no? Este año he comenzado a usarlo no sólo como herramienta de control de versiones y repositorio para código, también para otro tipo de documentos como los dos libros en los que estoy ya trabajando.

Aunque existen herramientas visuales para GIT y viniendo del mundo de Microsoft, llega un momento en que aprecias la comodidad de usar la consola para muchas tareas, sencillamente termina siendo más eficiente. Escribiendo esto se me viene a la cabeza ese magnífico y clásico libro de Neal Stephenson titulado En el principio... fue la línea de comandos. Genial y de obligada relectura cada ciertos años.

Optimización y rendimiento web

Al haber trabajado muchos años en el backend, he dedicado mucho tiempo a la optimización de código (a veces por necesidad y otras por puro placer, esa es la verdad). Esta primera parte del año he profundizado muchísimo en la optimización ya no sólo de los flujos de trabajo de una aplicación web profesional, sino en la optimización de todos los assets necesarios para la navegación con el frontend: ficheros html, css, imágenes, fuentes, minificación, técnicas de caché avanzadas, análisis en profundidad de los requests que realiza el navegador, buen uso de los selectores css, he aprendido que hay frameworks para el layout más eficientes que otros, el overhead que puede suponer obsesionarte por que tu aplicación sea responsiva, retraso intencionado en la carga de recursos y un larguíiiisimo etcétera.

Curiosamente apenas hay literatura en español sobre este tema tan importante, dado que el mundo web está creciendo exponencialmente y pocos desarrolladores conocen al menos las técnicas más relevantes. 

La clave está en ejecutar todas estas técnicas de optimización sin ofuscar la solución.

Sobre desarrollo web he mantenido muchas conversaciones interesantes acerca de lo poliédrico que puede ser el desarrollo de un portal web: además de la elección de las tecnologías correctas, no se pueden obviar las técnicas de optimización, tampoco ignorar estrategias SEO / SEM, integrar analítica web, etc. De modo que cuando leo un currículum en donde se pone "desarrollador web", la verdad es que no sé qué pensar...

Nginx y Redis

Para el proyecto que estoy a punto de publicar he usado por primera vez Nginx y Redis, dos proyectos que me parecen fantásticos. Nginx juega un papel muy importante para la arquitectura de despliegue para un sistema muy escalable (muchos usuarios concurrentes accediendo a un portal web) al tiempo que con Redis se puede jugar muchísimo para conseguir enormes mejoras de rendimiento en distinto tipos de aplicaciones.

Visual Studio 2015

Hemos comenzado a usar Visual Studio 2015 estos meses atrás y adentrarnos de lleno con ASP.NET 5 y NDX, la nueva revisión del Entity Framework, etc. Sorprende cómo se han ido adoptando las formas de trabajar con proyectos open-source en este nuevo tipo de proyectos con Visual Studio 2015 y esta nueva revisión de ASP.NET.

Desarrollo para la nube

Performance GaugeUno de los aspectos que siempre me han gustado más sobre el desarrollo de software ha sido optimizar y mejorar el rendimiento, sobre todo de aquellas partes de un proyecto que pertenecen más al core y de lo que depende todo lo demás.

Con el desarrollo masivo de aplicaciones web y teniendo en cuenta que la economía se está moviendo a lo digital, trabajar en el buen rendimiento de un sistema puede suponer una gran ventaja competitiva y generar mejores resultados económicos.

Por alguna razón siempre he visto cómo todo lo relacionado con el perfomance sólo nos ha preocupado como desarrolladores cuando esto suponía un error en el sistema, de modo que si algo funcionaba (aun con una latencia de algunos segundillos) pues a casi nadie le importaba. Ahora no, ahora hay que arañar hasta el último milisegundo y por supuesto ganamos la batalla si la percepción del usuario final es la de que algo va a golpe de clic. También he visto cómo se ha intentado solucionar problemas graves de rendimiento con más hardware...

El rendimiento de un sistema no consiste sólo en que funcione con la velocidad adecuada, sino también en que el usuario que lo usa perciba que responde ágilmente y de manera instantánea.

Lo que defiendo en este post, sobre todo en desarrollo web, es que trabajar con el rendimiento en mente se debe hacer desde el principio hasta el final del proyecto.

No hace mucho leí que un usuario percibe algo como instantáneo si obtiene una respuesta en menos de 100ms, entre 100 y 300ms percibe un ligero retraso, entre los 300ms y el segundo ya nota un retraso apreciable, después de un segundo se produce lo que se llama un cambio mental de contexto (mental context switch, o sea, que empieza a pensar en otra cosa) y a partir de los diez segundos (!!#***xxxx)  ha abandonado lo que intentaba hacer... En estos dos últimos casos las posibilidades de que abandone la web son muy altas. Una web lenta echa a los visitantes como moscas en una fábrica de insecticida.

Esto tiene un impacto brutal en webs en donde una tasa de rebote alta significa menos usuarios y por tanto menos posibilidades de materializar algún tipo de resultado en el site (en forma de nuevas inscripciones, ventas, descargas, etc.). Por tanto, trabajar en mejorar el rendimiento no es que sea algo secundario, sino que sin él todo lo demás que hagamos seguramente no tenga tan buen resultado como esperábamos.

Tradicionalmente los equipos de desarrollo se han preocupado del rendimiento de lo que hace al final del proyecto, cuando ya se da casi por cerrado y cuando posiblemente apenas se tenga ya tiempo parar mejorarlo y todo el esfuerzo pendiente se deba dedicar a detectar y corregir errores de validación. Esto es un error en el que yo he caído mil y una veces..., no obstante, como se suele decir, nada mejor que señalar los errores ajenos cuando uno mismo ya los ha cometido previamente, de modo que más que considerarme presuntuosamente experto, tendría que decir que la experiencia me ha dado muchas (y dolorosas) lecciones.

Desde el primer momento en que se comienzan a generar assets en el proyecto, del tipo que sea, hay que comenzar a trabajar desde el punto de vista de su rendimiento; en otras palabras, tenemos que integrar en el día a día el mejorar esos assets como una parte más del trabajo, sobre todo si el éxito o fracaso del proyecto dependen de la buena o mala percepción de los usuarios en cuanto a usabilidad y tiempos de respuesta del sistema. Me pregunto, ¿pero es que existe algún sistema software que se pueda permitir que un usuario esté varios segundos esperando para hacer cualquier cosa trivial? Claro, los hay, y muchos, me temo, y seguramente esos productos estén en la línea roja con posibilidad de ser sustituidos por la competencia.

El trabajar desde el principio en mejorar el rendimiento no es inocuo ya que de alguna manera, escribir con la optimización en mente implica:

  • Crear estructuras de código optimizadas en donde ahorrar tan sólo unos cuantos ciclos de CPU es importante. Es difícil a veces encontrar el equilibro para seguir manteniendo código legible sin ofuscarlo al optimizarlo.
  • Trabajar con el rendimiento en mente impacta también en el diseño del sistema: no sirve de nada plantear una arquitectura de la información fantástica si detrás no está respaldada con saltos ágiles y rápidos cuando un usuario navega por una web.

El mejorar el rendimiento implica a todos lo que trabajan en el proyecto: desarrolladores, diseñadores, arquitectos de información, etc.

El rendimiento no es sólo que un trozo de código funcione lo más rápido posible, es un concepto poliédrico, con muchas caras, sobre todo en una aplicación web donde hay muchísimos elementos involucrados:

  • Conseguir un buen performance depende de la infraestructura software que usemos (servidores HTTP intermedios, SSL, etc.)
  • Hay que establecer una buena estrategia de caché para los distintos elementos de la web.
  • Hay que analizar si es conveniente o no usar CDNs.
  • Hay que validar y optimizar (minificando y contatenando) los ficheros CSS y js. Sí, los estilos se pueden optimizar para que el navegador tarde menos en procesarlos y renderizar los resultados.
  • Si se hace un uso intensivo de imágenes, estas deberían estar optimizadas y habría que ver en qué casos se podría emplear la técnica de uso de sprites.
  • No hablemos ya si plateamos una web con estrategias de RWD o RESS, ahí se complica un poco más las optimizaciones según el dispositivo del usuario.
  • Hay que tener mucho cuidado de las librerías externas o de terceros a usar y detectar cuales de ellas pueden constituir un SPOF y dejar K.O. el site.
  • Lo que entendamos por buen o mal rendimiento depende del tipo de proyecto.

No podemos dejar todo ese trabajo de auditoría y análisis de rendimiento (de calidad, en definitiva) para el final, sino que hay integrar esas tareas en el workflow habitual de trabajo o en los procesos de entregas o integración continuas si se tienen establecidas.

Lo más importante de todo (y quizá lo más difícil): el trabajo sobre el rendimiento de algún aspecto concreto se debe poder medir de manera automática para poder ver el progreso o retroceso a medida que avanza el proyecto.

Estamos comenzando un nuevo proyecto para el mercado eléctrico, en esta ocasión 100% web (con un backend que extrae información de un enorme repositorio de información alojada en cloud); estamos integrando en el primer prototipo todas las métricas de rendimiento que nos permita analizarlas a medida que el proyecto avance en los próximos meses además de integrar en el flujo de trabajo habitual la generación automática de todos los assets optimizados. Espero así que este trabajo, que al principio parece extra, consiga que los usuarios finales del site perciban un sistema ágil y por tanto consigamos generar una percepción positiva del mismo.

Me gusta Etsy, no sólo porque implementa en la realidad una economía colaborativa hacia la que, en mi opinión, todo debería converger, también porque cuenta con un equipo de desarrollo supermotivado que además publican sus insights. En su blog hablan mucho de rendimiento web.

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