Asier Marqués

De identidades, facetas y hobbies.

Thu, 16 Apr 2026 00:00:00 +0000

Hace 28 años, en 1998, hacía mis pinitos intentando componer algo que sonase medio bien con el Rebirth 338. Mi PC, con sus poderosos 16 megas de memoria RAM hacía sonar mágicamente dos míticas Roland 303 y una caja de ritmos 909, emuladas, obviamente. Al poco tiempo un compañero del colegio donde estudiaba escuchó hablar de mí y me descubrió lo que significaba pinchar música electrónica.
Nos escaqueábamos de clase para ir a escuchar vinilos en una de las escasas tiendas de discos en Vizcaya o nos pasábamos la tarde poniendo discos en la cocina de su casa, en la que montaba un equipo modesto formado por dos platos de polea y una mesa de mezclas Akiyama. Tardaría un par de años en poder comprar mi primer plato e ir a los primeros concursos de DJ.

En el 2000 me recorrí las salas Tívoli, Columbus e Itzela, en las que a veces lograba quedar como finalista en algún concurso, pero no podía presentarme a la final porque no tenía coche y mis amigos no siempre podían llevarme. Más tarde tuve mi primer programa de música con un colega en una radio que no escuchaba absolutamente nadie. Conocí a mucha gente de la que aprendí un montón, con la que compartí cabina en salas que ya no existen y muchas horas de escuchar música, pinchar en txokos de algunos de ellos y en fiestas más o menos legales.

Esa faceta no me ha abandonado. Es una de las que he tenido durante toda mi vida. Y hace unos meses tomé la decisión de darle otro lugar, un espacio muy distinto al que tenía hasta ahora.

Me he dado cuenta de que a lo largo de mi vida no he sabido separar lo que era una faceta de lo que era una identidad. Y cuando asociaba algo que me gustaba hacer a mi propia identidad, no era capaz de quedarme en la superficie. Necesitaba adquirir una maestría que estuviera a la altura de mis expectativas, mucho más lejos de la media. Y eso es agotador cuando te gusta hacer muchas cosas. Y sobre todo, cuando esas cosas han formado parte de tu vida tantos años y has sido tan feliz mientras las hacías.

He de reconocer que para mí, hacer algo simplemente como “un hobby” es aún algo que no termino de apreciar como debería y que por ello, no puedo evitar meterme demasiado en algo que me llame la atención. Estoy aprendiendo aún en este sentido, pero encontrarás trazas de esto en este texto.

Epícteto dijo que te conviertes en aquello a lo que prestas atención. En mi caso, esta faceta había llegado a ser tan fuerte para mí que se adueñó de parte de mi identidad. Era una forma de representarme, de responder a la pregunta “¿quién soy?”. Pero aunque la de deejay es una faceta que tengo y de la que me siento muy agradecido, por lo que me ha aportado en otras áreas, ya no ocupa tanto tiempo de mi atención.

Hay diferentes motivos para ello. Podría decir que soy un dj de vinilo y que ahora la tecnología le ha quitado toda la gracia al arte de pinchar. Pero sería parte de la historia. En realidad, creo que hace tiempo que esta faceta ha pasado a ser un hobby y no tengo la motivación necesaria para estar todo el día seleccionando música y pensando en mezclas como antaño. Y está bien. Puedo disfrutar de esta faceta pasada como un hobby ahora, cuando el trabajo, la vida y otras cosas con las que estoy obsesionado en este momento, me piden un descanso.

Y qué guay es poder contar con descansos de este tipo.

Nos leemos.

Reflexiones sobre aprender en un mundo de IA

Sat, 28 Mar 2026 23:00:01 +0000

El pasado fin de semana asistí por primera vez al StartUp Open Space de Zaragoza (el SOSZ).
Como ocurre en este tipo de encuentros, no hay agenda predeterminada, y cada asistente puede proponer y votar los temas que se tratarán durante el día.

Uno de los temas fue cómo aprender en un mundo de IA. Como me interesa especialmente, decidí asistir al debate. Tras el mismo, me quedé dándole vueltas a varias ideas y me apetecía compartir aquí algunas reflexiones rápidas. Y de paso, quitarle las telarañas al blog, que llevaba tiempo queriendo hacerlo.

Foto de Solen Feyissa en Unsplash

El impacto de la IA a la hora de aprender

Estamos ante un momento histórico. Nunca una tecnología se ha adoptado por tantas personas en tan poco tiempo.

La IA nos ofrece respuestas inmediatas y nos ayuda a resolver problemas de todo tipo sin necesidad de ser expertos en la materia. La utilizamos como un autoservicio de “conocimiento infinito”, aunque en realidad lo que hace es generar respuestas lo más cercanas posible a las preguntas que le hacemos. Este es un matiz que a menudo no nos parece importante, pero lo es. Y bastante.

A menudo, estas respuestas se acercan tan bien a lo que buscamos que las damos por buenas. En otras ocasiones, no son del todo correctas. O ni remotamente acertadas. Casi del “mismo” modo que cuando preguntamos a una persona que no conocemos. Sus respuestas pueden ser correctas, no del todo acertadas o totalmente incorrectas, independientemente de la intención que esta tenga al darlas.

Pero imaginemos que la IA nunca se equivocase en sus respuestas. Es más, pensemos en un escenario tan simple en el que sólo exista una única verdad. ¿Qué supondría eso para nuestro aprendizaje? ¿Cómo de cómodos nos volveríamos si tuviéramos la posibilidad de obtener rápidamente la respuesta a cada problema? ¿Cómo nos afectaría a nivel cognitivo? ¿Cómo afectaría a nuestra motivación si ya no hubiera un reto que no pudiéramos resolver de forma instantánea? ¿Dónde quedaría la creatividad si todos “resolviéramos” los problemas de la misma forma?

Es cierto, he pedido imaginar demasiado. El problema es que ya hay un riesgo de que asumamos que la IA nunca se equivoca y que tiene siempre la verdad. La única verdad.

Y es que los asistentes de IA sí que nos ayudan a solucionar problemas. A menudo, los resuelven incluso mejor de cómo los hubiéramos resuelto por nuestra cuenta. Y cuando alguien nos da varias respuestas correctas de forma consecutiva, es muy fácil asumir que su siguiente respuesta también será la correcta.

Pero no creo que estos problemas sean nuevos. Lo que sí es nuevo es el potencial para volvernos mucho más cómodos y el riesgo de pensar que somos nosotros los que estamos resolviendo los problemas cuando han sido resueltos por una IA en realidad.
Podemos dejarnos llevar sin autocrítica ni una responsabilidad en nuestro propio aprendizaje.

Las herramientas nos pueden impactar para bien o para mal. La diferencia es que, con la IA, ese impacto será mucho mayor.

¿Queremos ser resolutivos o queremos aprender?

En ocasiones, cuando se nos presenta un problema o un objetivo, lo que realmente queremos es ser resolutivos y no tanto aprender a resolverlo. Creo que debemos ser honestos con nosotros mismos en este punto.

Por ejemplo, no es lo mismo ponernos el objetivo de conseguir la certificación (o un título) al completar un curso, que el de obtener conocimiento y experiencia en el ámbito del mismo. A veces, esos objetivos van de la mano, y la certificación puede ser una estrategia perfectamente válida para adquirir conocimientos.

Si optamos por ser resolutivos, la IA puede facilitarnos superar las pruebas rápidamente e incluso proporcionarnos las respuestas de los exámenes, por sofisticados que sean, permitiéndonos conseguir el título sin el esfuerzo que conlleva realmente aprender e interiorizar los conceptos.

Sin embargo, si optamos por ganar conocimiento, la IA puede ayudarnos a complementar el temario, diseñar pruebas adicionales para autoevaluarnos, proponer dinámicas de role-play para practicar con ella y ofrecernos múltiples recursos que refuercen la formación. Pero esto exige hacernos dueños de nuestro propio aprendizaje.

Hacernos dueños de nuestro propio aprendizaje

Para mí esto es la clave a la hora de aprender en un mundo en el que vamos a usar la IA para todo. Hacernos dueños de las cosas exige mucha madurez y honestidad con nosotros mismos. Y en un mundo de la IA, va a ser muy difícil echar balones fuera. Especialmente a la hora de aprender. Y también de enseñar a otros.

Yo no veo un mundo en el que no existan humanos en un camino de aprendizaje. Pero sí empiezo a ver un mundo en el que habrá una gran diferencia entre las personas que sepan buscarse la vida para aprender algo de forma rápida, sepan evaluarse a ellas mismas y sepan pedir ayuda o referencia a un humano cuando lo necesiten, con respecto a las que simplemente se dejen llevar y se conformen con un temario diseñado por otros que se pueda adaptar, o no, a su caso concreto.

Creo que las primeras aprovecharán muchísimo más el apoyo de alguien que quiera ayudarles y estarán también más preparadas para saber orientarse en diferentes situaciones en las que el camino no esté del todo claro o, incluso, exista el riesgo de ser manipuladas.

Esto requiere un esfuerzo e interés genuino por aprender y entiendo que la mayor preocupación sea si las nuevas generaciones optarán por este camino frente a la alternativa más cómoda.

Quizás esté sesgado, pero no me gusta subestimar a las nuevas generaciones. Es evidente que muchos optarán por la vía rápida. Sobre todo si el sistems educativo actual no cambia. Pero soy optimista y pienso que muchos jóvenes van a entender la necesidad de hacerse dueños de su propia formación, probablemente más de lo que lo hemos hecho nosotros.
De hecho, últimamente estoy entrevistando a perfiles junior de ingeniería de software, y al hacerles la pregunta sobre cómo usan la IA, muchas de sus respuestas están alineadas con esta forma de entender el aprendizaje.

Si queremos realmente aprender algo, contamos con una herramienta poderosa que puede ayudarnos a evaluarnos de forma muy crítica y a diseñar nuestros propios caminos de aprendizaje. Pero sólo funcionará de esa forma si nosotros también pensamos de forma crítica.

Desarrollar un punto de vista crítico

La IA no tiene la verdad absoluta. De hecho, es bastante frecuente que se equivoque, que se quede en la superficie o que “alucine” con información completamente distinta a la que necesitamos. Exactamente igual que una persona muy venida arriba.
Todos hemos tenido malos profesores. Hemos leído artículos escritos por alguien que no tenía ni idea de lo que hablaba. Y también hemos visto servicios que parecían maravillosos, pero que, al revisar el contrato, escondían mucha letra pequeña.

La necesidad de desarrollar un pensamiento crítico no es nueva. Pero ahora es especialmente crítica gracias a la IA. Afortunadamente.

No creernos lo primero que nos dice algo o alguien es la base para no ser manipulados y aprender de forma efectiva. Hoy en día, la manipulación y los errores pueden darse a una escala aún mayor, por lo que debemos estar atentos. Tenemos buena razón para ello.

Orientarse más allá de lo que no sabes

“Es probable que ninguno de los dos sepa nada valioso; pero él cree saber algo, aunque no sabe, mientras que yo, como no sé, tampoco creo saber.”
Sócrates

Los asistentes como ChatGPT o Claude nos ayudan a entender y buscar soluciones sobre lo que no sabemos. Al hacer uso de nuestro criterio, podemos contrastar las respuestas y determinar si lo que nos dicen es útil.

Pero lo interesante (y difícil) es descubrir lo que no sabes que no sabes. La IA nos puede dar respuestas que se queden muy en la superficie. Sin un pensamiento crítico, podemos “fliparnos” y asumir rápidamente que ya lo sabemos todo sobre cualquier tema.

Hoy formas de hacer que la IA nos ayude a ver más allá. Veamos unos ejemplos de instrucciones (prompts) que podemos darles a nuestros asistentes para que nos ayuden en este sentido:

Para resolver un problema

❌ Instrucción superficial

¿Cómo soluciono esto?

✅ Versión mejorada

Estoy intentando resolver este problema: [problema].

No propongas soluciones todavía. Actúa como alguien que quiere mejorar mi comprensión del problema.

1. Hazme las 10 preguntas más importantes que debería responder antes de decidir.
2. Agrúpalas en: contexto, restricciones, riesgos, personas o aspectos afectados e incertidumbres.
3. Señala cuáles son incómodas pero críticas.
4. Dime qué pregunta probablemente estoy evitando sin darme cuenta.

Quieres detectar conocimientos que deberías repasar antes de aprender sobre un tema

❌ Instrucción superficial

Explícame esto: [tema]

✅ Versión mejorada

Quiero aprender [tema].

No me lo expliques todavía. Antes:

1. Identifica los conocimientos previos que debería tener para entenderlo bien.
2. Sepáralos en imprescindibles, recomendables y opcionales.
3. Dime cuáles suele creer la gente que domina, pero en realidad entiende mal.
4. Señala qué conceptos me bloquearían más si intento aprender esto demasiado pronto.
5. Propón una ruta de aprendizaje mínima y otra profunda.

Quieres descubrir aspectos fuera de lo básico

❌ Instrucción superficial

Hazme un plan de aprendizaje para aprender a programar con IA.

✅ Versión mejorada

Quiero aprender [tema].

No me lo expliques todavía. Primero ayúdame a descubrir lo que no sé que no sé.

1. Dime qué preguntas debería hacer alguien principiante pero normalmente no hace.
2. Dime qué preguntas haría alguien intermedio.
3. Dime qué preguntas distinguen a alguien que ya entiende el tema de verdad.
5. Qué debates, matices o enfoques suelen subestimarse.
6. Qué orden de aprendizaje me evitaría una falsa sensación de comprensión.
7. Después, propón una ruta de estudio con fases.

Estos son sólo ejemplos, pero lo realmente importante es aprender a crear nuestras propias instrucciones que nos ayuden a descubrir nuestros puntos ciegos.
Si no estamos acostumbrados a hacerlo podemos pedir a los propios asistentes de IA que generen este tipo de instrucciones y lanzárselas luego para obtener respuestas mucho más profundas.

Con estas reflexiones quería expresar que la IA puede ser una amenaza o una aliada. Pero, sea lo que sea, está ya a pie de calle y más nos vale cambiar nuestra mentalidad.

En el mejor de los casos, si nos obliga a desarrollar pensamiento crítico, habremos ganado algo mucho más valioso que una simple al-iA-da (perdón).

Nos leemos.

Repaso anual de 2025

Mon, 05 Jan 2026 21:00:01 +0000

Como cada año, paso por aquí para hacer un repaso sobre lo que ha ocupado mi atención en los últimos doce meses.

En lo personal, este pasado año fue bastante raro, con sus luces y sus sombras, muy oscuras ellas, pero en general, considero que ha sido mucho mejor que el 2024. Sobre todo porque desde hace unos meses, tengo muchas ganas de hacer más cosas y me siento con la energía correcta para hacerlas.

En lo profesional, en Bestsecret nos hemos enfrentado a varios retos de transformación tecnológica durante este año. Espero que podamos compartir algo de esta aventura en algún evento o artículo este año, porque considero que las lecciones que hemos aprendido son significativas.

Ahora que tengo el café preparado, hay cuatro cosas que me gustaría comentar por aquí.

Sobre la escritura

Este año me he quitado de encima el bloqueo que arrastraba desde hace mucho tiempo. No he puesto exclamaciones, emojis ni mayúsculas en esta frase, pero me siento eufórico. No sabes lo complicado que ha sido y lo mucho que he intentado recuperar esa parte de mi. Casi ni recordaba ya la sensación de tener la necesidad de escribir, esa que no te deja dormir por las noches hasta que sueltas, en unos cuantos párrafos, eso que tienes dentro.

Al comenzar el año me apunté a un curso de microrrelato en una escuela de escritura en pleno Barrio de las Letras en Madrid. Escuela a la que ya soy asiduo. Este taller significó un reencuentro con un yo que tenía dormido y ha ido despertando durante el año. He ido dejando relatos cortos que he escrito en explicitud.com, iré publicando más de tanto en tanto, me sirven como entrenamiento y para jugar practicando técnicas que voy descubriendo.

Tras estos talleres, me apunté a un curso de escritura creativa y en verano a un intensivo de Cuento. Pasado el verano, me apunté a un taller de novela corta al que voy cada semana. Comparto aula con compañeras y compañeros que ya han publicado varias novelas. Aprendo mucho de ellos.

La escritura me ha hecho recuperar la lectura de libros de ficción, algo que tenía abandonado desde que era muy pequeño.
Todo lo que había leído en las últimas décadas era prácticamente no ficción: libros de historia, de gestión, libros técnicos, libros de psicología, filosofía y otros temas, pero casi nunca novela. Sí que leía mucho cuento o relato corto o novelas o textos de personas de mi círculo que escriben y publican, pero eran excepciones muy esporádicas.

Creo que leer o escuchar audiolibros, cada vez es más importante. Por eso me han llamado especialmente la atención este año ciertos debates surgidos por comentarios de gente “importante” o directamente de noticias de algún medio que iban “en contra” de la lectura. La primera hacía referencia a que se había incrementado el postureo en la lectura. Que muchas personas iban a sitios con libros gordos y/o conocidos con el objetivo de mostrarse como grandes lectores. Y que luego no los leían. En otras se criticaba a las personas que hacían gala de leer doscientos mil libros al año. Y la última, más conocida, sobre la famosa frase de que “leer no nos hace mejores personas”.
Aunque se den casos en los que las personas intenten hacerse ver como grandes lectores (o lo que sea), creo que esto beneficia a la lectura. Puede que inspiren a otros a leer más aunque ellos no lo hagan. Y necesitamos que más gente adquiera el hábito de leer.
Urgentemente.

Leer, en estos tiempos que estamos viviendo de atención totalmente rota y enferma, es un acto de rebeldía. Me da igual a quién leas ni qué leas. Dedicar tiempo a leer requiere más esfuerzo de concentración (al principio) que ver decenas de vídeos repetidos mil veces de mil formas distintas con trazas desesperadas de captar la atención. Ese esfuerzo es entrenamiento, un entrenamiento muy potente que mejora nuestra atención. Si además lees en papel, reduces el tiempo que pasas frente a una pantalla, por lo que mejoras tu salud visual.

En los próximos meses y años, gozar de una buena capacidad de atención será algo tan raro como valioso. Leer es una buena forma de ejercitarla.

Siguiendo con el tema de la escritura, en 2025 me embarqué en dos proyectos de escritura que remataré este año.

Estoy escribiendo un libro sobre gestión y liderazgo de equipos de alto rendimiento, voy añadiendo detalles y recursos sobre este proyecto por aquí gestionarequipos.com. Ni la portada ni el título son definitivos, probablemente los cambie cuando tenga ya el borrador listo.
Lo tengo bastante avanzado. Hace un mes tuve un retiro de escritura para organizar el trabajo que me falta, hablé de ello por aquí. La conclusión de esta aventura está siendo que la escritura hay que tomársela como un hábito. Un entrenamiento diario.
Aunque escribas un mísero párrafo al día.

Por otra parte, en el curso de novela, me encuentro escribiendo una novela corta de ciencia ficción. Voy con mucha calma y no espero terminarla este año, pero quién sabe.

Sobre las redes sociales de atención

El año pasado comentaba sobre mi preocupación con las redes de atención y los patrones que éstas usan para atraparla, como el scroll infinito. Cada vez estoy más convencido de que son la heroína de este siglo. Pero sus efectos no son tan evidentes como otro tipo de drogas y por ello, a nivel social, lo raro es no estar enganchado a ellas.

Ya hace un año y medio que no uso X de forma activa. Algunos patrones de comportamiento que no me gustan nada los estoy empezando a ver también en Bluesky, pero al menos este no me bombardea con anuncios y contenido que no me interesa de gente que no sigo. Estoy planteándome compartir cosas puntuales por allí, como este post o artículos que publique fuera de lo personal. Pero la plataforma me echa mucho para atrás.

Este año también he reducido mi tiempo de Instagram en casi un setenta por ciento. Quería reducir mi tiempo allí porque gran cantidad de contenido que sale en mi timeline no me interesa en absoluto.

Para desconectar de X tras años de usarlo cada día, me desinstalé la aplicación del móvil y fue muy efectivo. Intenté lo mismo con Instagram, pero no fue tan efectivo. Por una parte, me gusta hacer y compartir fotos. Me gusta volver a ellas y recordar los momentos que capturan. Y con quién los capturan. Lo uso como un fotolog. Por otro lado, mi círculo social estaba tan presente allí, que algunas personas escriben directamente por instagram en lugar de en Whatsapp o Telegram.

La versión web no cuenta con la misma experiencia y terminaba por volver a instalarla para compartir ciertas fotos o historias. Luego la volvía a desinstalar. Aunque pueda sonar tedioso, este proceso me ayudó bastante. “Entrar en Instagram” se convirtió en algo que me requería esfuerzo en lugar de ser casi un acto reflejo cuando estaba “aburrido” o tenía unos minutos para descansar. Y esos minutos volaban consumiendo contenido que ni me aportaba ni me interesaba.

Y sobre esto, veo muy necesario parar, reflexionar y tener una opinión muy crítica con respecto a lo que estemos consumiendo, por muy aceptado que esté dicho mensaje y por supuesto, por muchas reacciones que este tenga.

Estamos en un momento de cambio en muchos aspectos. Debemos cuidarnos de a qué prestamos atención y practicar nuestro pensamiento crítico. Nos jugamos mucho con esto.

Sobre los eventos presenciales

Echo de menos más eventos de comunidad presenciales. En los que tomar un café con alguien que está enfrentándose a retos y contextos similares a los tuyos.

Desde la pandemia, los pequeños meetups han ido desapareciendo y sus correspondientes cañas posteventos. Creo que la degradación de sitios como Twitter junto al cambio en el mercado de contratación en los últimos años, han influido en esto.

Soy optimista y creo que hay bastantes cosas en nuestro control para darle la vuelta a la situación. La principal es ir a los eventos que ya se hacen. Esto es algo en lo que yo he fallado y pienso corregir durante este 2026.

También me estoy animando a convocar eventos, ya sean en abierto o en privado con gente de confianza con la que quiero compartir conversaciones y cafés.

Nuestra vida se completa con personas con las que conectamos. Esos pequeños momentos con ellas suman y mucho. Y las personas no están aquí para siempre. Ese café que tienes pendiente con alguien puede que nunca llegue a suceder.
Pon una fecha, y una excusa si lo necesitas, para que esos momentos sucedan. Y si no es presencial, que sea por cámara.
Merece mucho la pena.

Sobre lo que estamos viendo de IA

Seguimos viviendo una revolución relacionada con la inteligencia artificial, sobre todo en la IA generativa, pero que arrastra mucho más con ella.

A nivel profesional, en la empresa en la que trabajo, integramos agentes de IA para los procesos de desarrollo de software. Lo que estamos viendo, no sólo a nivel de números de productividad, que hemos visto que es significativa, sino también a nivel de mejora de los procesos de desarrollo en sí (en aspectos como la calidad de la documentación, la efectividad de las conversaciones del equipo y la información disponible) nos hace pensar que ya no hay vuelta atrás. Estos agentes van a formar parte del día a día de la creación de productos de software, sin ningún tipo de duda.

Fuera de mi trabajo, he concentrado mi formación primero en el desarrollo de agentes y luego en la gestión del contexto. Sobre todo con el ecosistema de LangChain.
Todo lo relativo a RAG y Context Engineering, en general, es un área que me resulta muy interesante.

Otra área que me resulta interesante es la provisión, gobernanza y fiabilidad de los sistemas basados en IA que ponemos en producción. Creo que va a ser uno de los mayores retos para 2026.

Me voy a enfocar en estas cosas también en 2026 y me gustaría coincidir con más personas que estén con objetivos similares. Por ello, me he animado a montar un pequeño meetup en Madrid, en el que hablar sobre estos temas: madai.es
La primera charla es en Febrero y ya tenemos lista de espera. Pero además de charlas, seguramente convoquemos también cafés más informales de cuando en cuando. Siguiendo lo que comentaba sobre eventos presenciales, intentaré acercarme a eventos que vaya descubriendo en España u otros lugares, en los que se comparta experiencia real.

Aunque los temas que he descrito en los puntos anteriores son los que más me interesan a nivel personal (y también profesional), se está hablando mucho también de la generación en sí de los productos, con sistemas como Lovable y demás.
Estos me resultan importantes, sobre todo desde un punto de vista de usuario. Se empieza a ver una clara tendencia de que los propios usuarios, los más técnicos o con mentalidad autodidacta, creen sus propias herramientas personales. También me parecen importantes para crear pruebas de concepto que validen la idea y luego se descarten en favor de sistemas preparados para producción. Y me resulta importante aprender a usarlos e ir habituándose a hacer herramientas propias con ellos.

Pero creo que en el futuro, las aplicaciones tal y como las conocemos, dispondrán de interfaces basada en sistemas LLM de chat y voz. Las interfaces tradicionales, basadas en patrones de navegación a los que estamos ya tan habituados, quedarán relegadas a ciertos casos específicos.

Y esto es todo por ahora. Mientras tanto, podemos encontrarnos por Bluesky.

Nos leemos pronto o quizás, nos podamos ver por algún evento durante al año.

Choque de reminiscencia

Sun, 02 Feb 2025 20:30:01 +0000

En Enero leí el libro Momentos mágicos (The Power of Moments: Why Certain Experiences Have Extraordinary Impact).
En este libro los hermanos Heath nos invitan a ser estratégicos y tomar más control de nuestras experiencias y los momentos que vivimos.
Además, presentan varios conceptos interesantes, entre ellos, el choque de reminiscencia.

Estos tres extractos del libro me parecieron clave para reflexionar sobre este concepto:

“Si preguntamos a la gente mayor sobre sus recuerdos más intensos, las investigaciones demuestran que suelen remitirse de forma desproporcionada a un mismo período, entre los quince y los treinta años.
Los psicólogos denominan este fenómeno «choque de reminiscencia». La razón por la que recordamos tan bien nuestra juventud es que es… una época de primeras veces; las primeras relaciones sexuales, los primeros trabajos, los primeros viajes sin padres, la primera vez que uno se va de casa, la primera vez con opciones reales de elegir qué hacer con nuestras vidas».
La novedad incluso cambia la percepción del tiempo.

[…]
En un experimento llevado a cabo por Vani Pariyadath y David Eagleman, del Baylor College of Medicine, se mostró a los participantes una serie de imágenes.
La mayoría de ellas eran idénticas, pero de vez en cuando aparecía una imagen nueva: zapato marrón, zapato marrón, zapato marrón, zapato marrón, zapato marrón, despertador, zapato marrón, zapato marrón, etc.
A pesar de que todas las imágenes se mostraban durante el mismo intervalo de tiempo, los participantes no lo percibieron así. Estaban convencidos de que el despertador —la imagen que rompía el patrón— se había mostrado durante más tiempo.
Este equívoco se conoce como «efecto bicho raro». Eagleman, neurólogo, argumentó que lo que causa el efecto bicho raro es, de hecho, el desinterés de nuestro cerebro por la foto del zapato marrón.
La disparidad resultante en la «densidad» de nuestra memoria —muchos apuntes para el despertador, pocos apuntes para el repetitivo zapato— lleva al equívoco de que el despertador se ha mostrado durante más tiempo.

[…]
Hay que aprender a reconocer nuestros propios guiones. Jugar con ellos, indagar, alterarlos. No siempre, sólo lo necesario para que esos zapatos marrones sigan pareciendo nuevos. Al saltarnos el guion podemos establecer un conjunto más amplio de recuerdos.
Tal como lo plantean los autores del libro Surprise, «Nos sentimos más cómodos cuando las cosas son certeras, pero nos sentimos más vivos cuando no lo son».”

Esa idea de reconocer nuestros propios guiones me parece clave. Si lo pensamos, seguimos varios guiones en nuestra vida. Algunos los hemos creado nosotros tal y como hemos establecido rutinas y hábitos, otros nos han venido dados.

Es posible que tengamos motivos de peso para seguir algunos de ellos, no podamos “alterarlos” o incluso los disfrutemos tal cual los vivimos y no nos interese cambiarlos en absoluto, pero no está de más entrenarse para detectarlos y pensar en cómo desafiarlos.

Algunos ejemplos que veo de estos guiones podrían ser:

Juntarse en Navidad/año nuevo con determinadas personas y celebrar siempre de la misma forma “especial” (zapato marrón?) esas fiestas. En general hacer algo especial por una fecha en concreta (por ejemplo, cumpleaños, aniversario…)
Escribir por WhatsApp a ciertas personas (con las que no hablamos nunca) por su cumpleaños para enviarles un mensaje más o menos prefabricado.
Planificar vacaciones en Agosto, Semana Santa, Navidad u otro periodo marcado como “especial” (zapato marrón?) en el calendario.
Delegar todo tu ocio y vida social a los fines de semana.

Al igual que nos puede parecer mejor percibir nuestros salarios en doce pagas en lugar de catorce para poder tener más control de nuestras finanzas personales, no está de más reflexionar en cómo podemos ganar más control de los guiones que seguimos en la vida y romperlos de forma estratégica cuando sea necesario.

Como conclusión, vivir en modo automático puede llevarnos a percibir que nuestra vida es más corta de lo que realmente es; además, los momentos “especiales” no siempre lo son si forman parte de un guion predefinido.

Algunas reflexiones de mis últimos doce meses

Thu, 02 Jan 2025 17:00:01 +0000

Estos días he estado reflexionando sobre algunos de los temas que ocuparon mi mente a lo largo del 2024, y me gustaría compartir algunas de esas cosas por aquí.

El pasado año fue muy duro a nivel personal, drenando mi energía y motivación en varios momentos, especialmente durante la primera mitad del mismo. Prefiero no profundizar en esto, no sólo porque es algo muy personal, sino también porque, sinceramente, sé que no soy el único que podría calificarlo como un ‘año de mierda’. Sin embargo, considero importante dejar constancia de este punto, aunque sea como una nota contextual desde la que escribo las siguientes líneas.

Escapar de las redes de atención

As William James observed, we must reflect that, when we reach the end of our days, our life experience will equal what we have paid attention to, whether by choice or default. We are at risk, without quite fully realizing it, of living lives that are less our own than we imagine.
Tim Wu, The Attention Merchants

Durante los últimos años, los servicios a los que antes llamábamos redes sociales se han transformado en redes de atención. Poco a poco, han ido ajustando sus productos para mantenernos atentos y activos en ellas. Personalmente, solía utilizarlas para descubrir y compartir contenido con personas cercanas y colegas profesionales, así como para debatir sobre temas de interés con ellos.

Hace años aprendimos que patrones de scroll como TikTok crean adicción pero cada vez más aplicaciones a las que aún llamamos “sociales” los continúan adoptando.

No estamos hablando únicamente de aplicaciones como X o Instagram. En un contexto social en el que las personas cada vez se sienten más solas, aplicaciones de citas están impactando las pautas de conexión social y la intimidad. La adicción en este contexto provoca un tipo de fatiga en el que es muy fácil perderse y olvidar el sentido de conectar con las personas.
Las personas atrapadas en este tipo de redes corren el peligro de cultivar una visión de túnel narcisista por necesidad de validación, en el que las conexiones se den de forma impulsiva por miedo al FOMO en un mercado de usar y tirar.

Incluso aplicaciones profesionales como Linkedin se empiezan a enfocar del mismo modo. Sin conocer el contexto interno de la empresa, me aventuro a pensar que las métricas de usuarios activos y objetivos ligados a ellas pueden haber pervertido la visión de producto para llevarles a tomar este tipo de decisiones.

Otras aplicaciones de aprendizaje, como Duolingo, utilizan patrones que van más allá de la persuasión y se acercan peligrosamente a la manipulación. Aunque puedan tener una buena intención al implementar ciertos patrones en su diseño, me pregunto si el fin justifica los medios.

Hace años pensaba que las apuestas eran la heroína de este siglo, pero las redes de atención están alimentando adicciones similares e impactando silenciosamente a la sociedad a una escala masiva. De una forma u otra, todos estamos intoxicados en mayor o menor medida.

La sensación de no tener tiempo para nada se intensifica cuando quedamos atrapados en las redes de atención. Nuestros hábitos nos transforman y moldean nuestro mundo, ya sea para bien o para mal.
En este contexto, gestionar nuestros hábitos de atención no sólo nos garantiza literalmente más tiempo de vida, sino también una mayor claridad a la hora de vivirla.
Me encantaron las campañas de Siroko y Opal, que están muy relacionadas con esto que menciono.

En Septiembre dejé de usar X de forma definitiva, tras 17 años usando Twitter. BlueSky está demostrando ser una opción más sana, y la verdad es que me gustaría que empecemos a contar con más servicios, alternativas a Instagram o LinkedIn, implementados sobre su protocolo. El protocolo AT está diseñado bajo un enfoque que respeta mucho más la interoperabilidad y los estándares abiertos que potenciaron la web como herramienta de conexión hace casi ya veinte años.

Deporte como inversión y un apunte sobre la constancia

En los últimos años, he estado muy preocupado por la consistencia de mi rutina de entrenamiento.
Al compararla con la de personas cercanas, sentía que no era lo ‘suficientemente buena’.
Incluso cuando varios entrenadores me aconsejaban ‘perdonarme’ por ‘fallar’, no podía evitar sentir una sensación de fracaso y falta de consistencia.

Esta sensación y otros hábitos inconscientes de mi estilo de vida, afectaban directamente a mi motivación y consistencia.
Por ejemplo, pedir determinada cena o mi consumo de alcohol (aunque fuera meramente social) perjudicaban tanto mi descanso como mi capacidad para gestionar el estrés.

Además de hacer conscientes y gestionar esos hábitos y entender mejor qué tipo de consistencia necesito en mi rutina, empecé a tomarme muy en serio mi descanso.
Ha sido interesante comenzar a medir la calidad de mi sueño para identificar de forma más clara qué aspectos de mi estilo de vida la afectan y reflexionar sobre si realmente merecen la pena.

Este año también leí el libro Dormir de Nick Littlehales, que me aportó una perspectiva valiosa.

Además, comencé a seguir las recomendaciones de predisposición a entrenar que me sugiere mi reloj Garmin, alineando mis entrenamientos con estas indicaciones, y no sólo con meras sensaciones.

Estoy bastante contento con mi rutina de deporte actual. Durante la primera mitad del año pude completar una maratón y otras dos medias de remo indoor.
Para remo indoor uso la app de remo virtual EXR. Para correr, gestiono mi entrenamiento con la app Runna.
Estos dos servicios son un claro ejemplo del buen nivel de aplicaciones con el que podemos contar hoy en día para gestionar de forma seria nuestros entrenamientos.

Aunque tengo cierta rutina de fuerza, uno de mis objetivos para este 2025 es mejorar en este sentido.
Cada año estoy más convencido de que el deporte es la mejor inversión para afrontar un futuro que parece será muy exigente para nuestra generación y las que vienen detrás de la nuestra.

La revolución de la IA generativa

The immediate results of the print revolution included witch hunts and religious wars alongside scientific discoveries, while newspapers and radio were exploited by totalitarian regimes as well as by democracies. As for the Industrial Revolution, adapting to it involved catastrophic experiments such as imperialism and Nazism.
If the AI revolution leads us to similar kinds of experiments, can we really be certain we will muddle through again?
Yuval Noah Harari, Nexus

Estoy entusiasmado con los avances que estamos viendo de IA en general y GenAI en particular en los últimos dos años.

Aunque hay mucho ruido en torno a la IA, considero que los avances que estamos presenciando nos están llevando a un cambio de paradigma, comparable al que vivimos como sociedad con la llegada del ordenador personal y, posteriormente, de internet.
Sin embargo, creo que aquellos cambios se produjeron de forma más gradual.
Herramientas que usamos en el día a día ya se benefician directamente, e incluso de manera transparente, de estos avances. Esto ha reducido significativamente la barrera de adopción, pero también ha acortado el tiempo disponible para adaptarnos.

En el mundo del desarrollo de software, en el momento en que escribo estas líneas, estamos presenciando una clara competencia entre GitHub Copilot y Cursor. Sin embargo, a pesar de lo increíble que puedan parecer estas herramientas y de cómo nos invitan a imaginar el futuro de nuestro sector, creo que estamos en un periodo de transición. Estas herramientas están diseñadas para abordar problemas desde una perspectiva que llevamos utilizando durante más de cuarenta años.

Pero, si desde hace décadas ya no necesitamos programar en ensamblador para resolver el 90% de los problemas, me pregunto cuál será el papel y el sentido de ’escribir código’ tal y como lo conocemos hoy en día en un futuro muy cercano.
Al fin y al cabo, el código es algo que escribimos para que otro ser humano entienda la intención de nuestra implementación.
Con la incorporación de actores no humanos y un mayor nivel de abstracción, las reglas del juego están cambiando.

Creo que tendencias como la de ingeniería de producto aplicada al software y áreas transversales como seguridad, auditorías y calidad adquirirán una relevancia aún mayor.

Fuera del desarrollo de software, la utilidad de estas herramientas resulta indiscutible. Considero fundamental desarrollar buena soltura al crear e iterar prompts, y, como ingenieros, mantenernos atentos a los avances y conceptos que sustentan las plataformas y soluciones de IA disponibles.

Hay barreras que no están aún claras y que incluso pueden encerrar debates complejos. Por ejemplo, en 2013 un estudio mostró que ChatGPT era capaz de dar respuestas percibidas como más empáticas por un grupo de pacientes que las de humanos profesionales en el campo de la medicina, en más de un 40% a favor de GPT-4.

Actualmente, estoy adoptando GPT y evaluando Cursor a nivel personal. Uso ChatGPT a diario para debatir ideas conmigo mismo, revisar mis textos y elaborar planes de aprendizaje con ejercicios que me ayuden a consolidar conocimientos, entre otras cosas.

Los presupuestos de formación

Soy un firme defensor de los presupuestos de formación como un beneficio valioso que las empresas pueden ofrecer para retener talento técnico y fomentar una sólida cultura de aprendizaje.

Hay empresas que aún no ofrecen este beneficio. En mi caso, por ejemplo, mi empresa actual no cuenta con un presupuesto de formación, aunque sí ofrece otros beneficios valiosos, como suscripciones a plataformas de aprendizaje y la dedicación de un viernes al mes a formación.
En estos contextos, suelo reservar un presupuesto anual propio para formación, aunque soy plenamente consciente de que las circunstancias personales varían y no todo el mundo tiene la capacidad económica para destinar recursos a su desarrollo profesional, independientemente de su salario.

En contextos donde sí he contado con este beneficio, e incluso he tenido la oportunidad de influir en su proceso de gestión, me ha sorprendido cómo las métricas reflejaban un porcentaje de uso bastante bajo a nivel general. Los managers solíamos orientar a las personas para que lo aprovecharan, a veces basándonos en planes de crecimiento particulares o proponiendo formaciones alineadas con nuestra estrategia de ingeniería.

Quizás la popularización de estos beneficios y la falta de una adecuada gestión de los mismos hayan motivado la aparición de actores que considero oportunistas, quienes promueven el uso de estos presupuestos para cubrir costes de entradas a eventos o talleres que serían inaccesibles sin una ayuda económica de este tipo por parte de la empresa.

No tengo nada en contra de que se cobre el precio que se considere adecuado para una formación o evento, pero me genera bastantes dudas que desde estos eventos o talleres se fomente explícitamente el uso del presupuesto de formación para cubrirlos. Esto me genera desconfianza y me lleva a pensar que sus precios están diseñados en función de la cobertura económica ofrecida por algunas empresas, dejando fuera a profesionales que no cuentan con este tipo de ayudas.

Creo que, como profesionales, es importante ser responsables en cómo utilizamos nuestros presupuestos de formación.
Tanto si gestionamos un presupuesto propio como si contamos con uno ofrecido por nuestra empresa, podemos evaluar si una newsletter realmente aporta valor por los cien o doscientos euros anuales que cueste, si el precio de una entrada de un evento resulta razonable y si tiene sentido que un curso online, que durante todo el año ha costado 1000 €, baje a unos 200 € durante la semana del Black Friday.
El valor, obviamente, es relativo, pero mi punto es que, al menos, evitemos actuar en piloto automático sólo porque parezca que ese dinero, “no es nuestro”.

Como consumidores, tenemos el poder de marcar el ritmo. Usar el presupuesto con responsabilidad puede generar un impacto mucho mayor del que imaginamos.

Esto es todo por ahora. Quizás durante el año comparta alguna otra cosa por aquí en lugar de esperar otros doce meses, pero quién sabe :)

Mientras tanto, podemos encontrarnos por Bluesky y nos leemos pronto.

Breve reflexión de fin de año

Sun, 31 Dec 2023 19:00:01 +0000

He sacado un rato para reflexionar sobre las cosas que he hecho y aprendido durante este año que termina; esta será una breve entrada con lo más relevante que venga a mi mente mientras la escribo.

Cambio de mochila

Tras tres años como Senior Engineering Manager en Packlink Shipping y algo más de uno como Senior Director of Engineering en Auctane tras nuestra adquisición, cambié de ciclo y como es habitual en mí, cambié también de mochila.

Actualmente estoy trabajando en el equipo de gestión de ingeniería de BestSecret, llevando equipos de Checkout y Payments.

Es una empresa que existe desde hace más de cien años como una comunidad privada de venta de artículos de moda, principalmente ropa.

En este tiempo he sido testigo de la madurez de sus equipos de ingeniería y de producto y estoy muy contento en esta etapa.

Me gusta la sensación de volver a vivir ciertas cosas otra vez pero en un contexto muy distinto. Trabajamos totalmente en remoto y esto me permite trabajar con personas de diferentes nacionalidades ubicadas en Alemania, Suiza, Grecia y España principalmente y de las que puedo aprender muchísimo; esto cada día me gusta más.

Un descanso de tres meses

Entre la salida de Auctane y el onboarding en BestSecret me tomé tres meses. Afortunadamente tenía la capacidad de tomarme medio año o incluso un año entero, pero creo que para mi es imposible estar inactivo tanto tiempo.

De hecho, mientras hacía entrevistas durante el primer mes y medio, obtuve la certificación de Sr. Product Manager en Product School y me hice el curso de product analytics avanzado en Escuela Escribano.

Escribir y escribir un libro

Uno de los objetivos que llevo arrastrando desde el 2020 es escribir un libro y no lo he logrado. Siempre he deseado la oportunidad de disponer de un mes libre para escribir un libro. He dispuesto de tres y no lo he conseguido.

Al igual que ocurre con otras cosas, creo que escribir funciona bien cuando es un hábito. Yo no he tenido éxito en conseguir afianzar un hábito de escritura y creo que es una de las razones por las que mi cadencia de escritura ha bajado notablemente en los últimos años con respecto a años anteriores.

He reflexionado mucho sobre esto. Me apetece también volver a escribir fuera del mundo de tecnología. Sin duda, este es uno de los cambios en el que trabajaré los próximos meses.

Otras cosas

Este año he cumplido con muchas de las cosas que me había propuesto. Durante el año parecía que algunas de ellas no las iba a hacer o conseguir, pero finalmente han salido bien.

Otras cosas no han ido tan bien. Este verano pasaron cosas que me afectaron a nivel personal, pero todo se afronta y se supera.

He aprendido algunas cosas. Algunas las resumo en estos puntos con cierto desorden:

A veces pensamos que deberíamos haber empezado de otra forma con otras personas y es demasiado tarde para reconducir, pero nunca es tarde para cambiar nuestro comportamiento y hablar sobre ello.
Relacionado con lo anterior. Nunca es tarde para volver a personas de las que nos fuimos. Por habernos perdido, por habernos equivocado o por la razón que sea. Todos vamos hacia adelante y cada momento es distinto. Merece la pena intentar volver. Y si la puerta está abierta, es importante poner en valor esa oportunidad.
Las personas que te importan importan más de lo que crees. Somos mejores en grupo, en comunidad.
El deporte es una herramienta de trabajo. El deporte es una herramienta para conseguir no necesitar más.
Encadena hábitos para poder vivir más.
Observar sin evaluar. Escuchar. Tomar decisiones. Desarrollarte en estas tres habilidades te hará crecer mucho en muy poco tiempo.
Los objetivos son guías, no contratos. Tus objetivos son tuyos, puedes cambiarlos, borrarlos o no cumplirlos. Olvídate de audiencias que no existen.
Saber cocinar es importante. Nuestro aparato digestivo está enlazado con la mente.
Eres el único dueño de tu crecimiento profesional y personal.
Aprende y optimiza tu respiración por la nariz.
No dejes escapar a personas con las que tengas una conexión brutal. Las conexiones brutales no son frecuentes.
Lo importante es dar pasos hacia adelante. La distancia o tamaño de los pasos, no es tan importante.
Sé consciente de lo que te quita tiempo y por qué. Sé consciente de las recompensas que buscas sin pensar.
No confundas personas que te aportan con personas que te validan.

Esto es todo por ahora, feliz año nuevo; nos leemos pronto.

Breve repaso a mis últimos cinco años

Sat, 31 Dec 2022 16:00:01 +0000

Tenía ganas de encontrar el momento de escribir tranquilamente. Aún no he recuperado el hábito de escribir en este blog por lo que no voy a ser muy original que digamos; escribiré a modo de reflexión sobre lo último que he vivido o que me ha resultado interesante desde mi última actualización personal.
Esa actualización fue sobre mi “cambio de mochila” hace ya casi cinco años.

Aquel cambio de mochila trajo un cambio personal bastante fuerte: volví a trabajar por cuenta ajena después de haber trabajado de forma autónoma y haber creado varias empresas desde cero durante los años anteriores.

¿Qué pasó desde entonces? Es imposible resumir todo lo vivido en esta entrada, pero repasaré algunos titulares que le contaría a un colega al que no veo desde hace años o a mi yo del pasado por si tuviera interés en ser spoileado.

Lo de mudarme a Madrid.

El 8 de Enero de 2019 me mudé a Madrid, ciudad en la que resido actualmente. Siempre he tenido un sesgo negativo con esta ciudad y antes de ese año hubiera apostado lo que fuese a que jamás, jamás en mi vida, acabaría viviendo en Madrid.
Málaga es una ciudad que conozco bien y me encanta. Forma parte de Andalucía, un gran paraíso del que tenemos la suerte de contar en nuestro planeta.
Cuando por trabajo tuve que decidir entre moverme a esta ciudad o ir a Madrid, ciudad concebida en mi mente como gris por su omnipresente asfalto, edificios, contaminación y abarrotada de ridículos coches SUV, me sorprendí decidiendo por la segunda. Y fue una genial decisión.

Me encanta Madrid. Es una ciudad muy cómoda y llena de gente interesante. Hay más lugares geniales en España, llenos de gente interesante también pero, lo bueno de Madrid, es que está lo suficientemente bien situada como para poder llegar de forma cómoda a prácticamente todos ellos.

No descarto moverme en un futuro, pero de momento eso lo veo a bastante más largo plazo del que me hubiera imaginado hace cuatro años.

Del remoto a presencial y vuelta al remoto.

Antes de volver a trabajar por cuenta ajena en el 2018, había estado trabajando en modo totalmente remoto durante siete años. En esa etapa fui dueño completamente de mi tiempo, cambié de residencia varias veces y viajaba frecuentemente mientras trabajaba.

No puedo explicar el cambio de trabajar de esta forma y llevar ese estilo de vida a volver a una oficina, con un horario, rodeado de cientos de personas, preparar tuppers… Mis primeras semanas fueron un reto continuo de adaptación.

Cuando me mudé a Madrid, en Packlink (la empresa para la cual trabajaba antes de ser comprada por Auctane) teníamos dos días a la semana en remoto y fuimos dando pasos hacia adelante que nos vinieron muy bien cuando nos pilló el toro del COVID. Desde entonces somos remotos totalmente con opción de ir a la oficina. Esto se ha mantenido incluso después de experimentar la adquisición de la empresa.

Soy un pleno defensor del trabajo en remoto y de la gestión de personas en remoto. Aunque hayamos experimentado un retroceso en comparación a lo ganado durante la pandemia, estoy plenamente convencido que en los trabajos en los que se pueda, los beneficios superan con creces a los inconvenientes, tanto para la empresa, como para los empleados.

Lo del inglés como idioma de trabajo.

Hace más de diez años repetía esta frase entre otras más o menos pegadizas: “el inglés es el mejor lenguaje de programación”.

Ahora mismo, se me haría muy extraño volver a trabajar en un lugar en el que no se utilizase el inglés. Desde hace tiempo estoy más cómodo escribiendo en inglés sobre temas profesionales, a pesar de no ser mi idioma nativo y a pesar de no hacerlo de forma perfecta.
He interiorizado el inglés como mi idioma por defecto para el ámbito profesional y esto se ha convertido en un principio personal bastante férreo.

Por otro lado, he desarrollado también cero tolerancia de quien desanima, se burla o critica a personas que aun no teniendo un nivel avanzado de inglés, se lanzan a hablarlo, escribir artículos o dar charlas.

Lo de perder, recuperar y crear hábitos.

“Observa tus acciones. Se transforman en hábitos. Observa tus hábitos. Se transforman en carácter. Observa tu carácter. Se transforma en tu destino.” Gandhi.

Durante 2020 estuve obsesionado con haber perdido la rutina de correr que tanto trabajo me costó recuperar años atrás. Durante ese año y el siguiente intenté sin éxito recuperar ese hábito.
En Abril de este año contraté a un entrenador personal y finalmente he tenido éxito no sólo en recuperar esa rutina, sino en hacerlo madrugando, mantenerla mientras viajo, he recuperado también mi rutina de remo indoor y he añadido rutinas adicionales de fuerza.

Como en otras cosas, tenía una perspectiva incorrecta cara a afrontar este problema. Cuando quieres conseguir crear, recuperar o eliminar un hábito, un problema frecuente suele ser obsesionarse por crear, recuperar o eliminar ese hábito en concreto. Los hábitos forman parte de un sistema formado por desencadenantes y ciclos de refuerzo.
En lugar de gestionar hábitos, debemos gestionar los sistemas en los que los hábitos encajan. Esto es algo que me ha obsesionado en el último año.

Levantarse a las 6:30 o 7 (no he sido nunca una persona especialmente madrugadora) y salir a correr me ha permitido de forma natural desencadenar un sistema de hábitos relacionados, algunos que había perdido sin ser consciente de ello y otros nuevos que a su vez, van desencadenando otros y curiosamente, haciendo menos apetecibles los que son más tóxicos. Es sorprendente la resilencia de un sistema de hábitos encadenados.

Por un lado, el libro de Hábitos Atómicos de James Clear, me proporcionó una perspectiva valiosa para ser consciente de triggers y sistemas de hábitos y Deshaciendo la ansiedad de Judson Brewer me dio un enfoque y herramientas para contrarestar los triggers de hábitos negativos.

Y para recuperar el deporte, un entrenador personal es la mejor elección que he podido hacer. Hay cosas que no puedes hacer de forma efectiva tú solo.

Aún me quedan hábitos por recuperar. El de escribir, el de escuchar más música o el de viajar en pequeñas escapadas aprovechando el remoto son algunos en los que estoy trabajado.

Hasta que no empecé a estudiar psicología no entendí bien lo importante de “hacer consciente lo inconsciente”. Esta frase se la escuché a una persona hace años con un café y ha estado muy presente en mi mente durante todo este año.

Lo del estoicismo.

“La vida es larga, si sabes cómo usarla.” Séneca.

Antes de recuperar de nuevo mis rutinas y hábitos, confiaba en exceso de mi capacidad de resilencia. A nada que hayamos leído a Taleb, especialmente su libro Antifrágil, sabemos que esa aproximación tiene un recorrido limitado en momentos de estrés o de mucho cambio.

Desde hacía años venía escuchando hablar sobre el estoicismo pero no me había detenido a leer sobre sus principios. Recuerdo una conversación con un amigo en el que me dijo “últimamente hay muchas personas fliplándose con el estoicismo”. Por mucho que hubiera querido sumarme a la crítica, me veía sin capacidad para responder ya que no había leído nada aún de Séneca, Epitecto o Marco Aurelio, por citar a los autores más conocidos.

Este año tuve la oportunidad de parar en seco unas semanas y dedicarme a entrenar, leer y recargar energía que había perdido en los últimos años. Prioricé entre otras lecturas, libros de estos autores.

Al leerles, me quedé con algunos de sus principios que los he interiorizado como míos y en algunos casos lo he llevado al plano profesional y han sido claves para afrontar situaciones complejas.

Saber detectar rápidamente lo que está fuera de mi control, lo que no me aporta pero se lleva mi energía o atención y el no esperar a que una situación mejore o sea “ideal” para conseguir avanzar y conseguir objetivos, son algunas de las ventajas que he obtenido gracias a la perspectiva que he conseguido adentrándome en este tema, totalmente desconocido para mí.

En alguna de esas lecturas invitaban a reflexionar a través de la pregunta “¿quién eres?”. Más allá de decir tu nombre y tu título profesional, ¿quién eres? Hacerse cargo de la identidad de uno mismo y saber lo que realmente forma parte de ella de forma genuina es muy interesante para priorizar y ahorrar un montón de tiempo, energía, preocupación y frustración.

Aunque no es estoicismo, pero está relacionado en cierto modo, no quería cerrar este titular sin mencionar la necesidad de gestionar nuestra atención. Vivimos en una era en la que la economía de la atención es clave y es peligroso vivir en modo automático sin gestionarla.
El libro Los comerciantes de la atención de Tim Wu te da mucha perspectiva y un repaso histórico sobre este tema.

Lo de los principios.

Una lectura que he sido reticente a leer desde hace tiempo y que creo que merece mucho la pena es Los Siete Habitos de La Gente Altamente Efectiva de Cowey.
El libro es mejor que el título o las portadas rancias que suele tener.

Esta lectura me ayudó a ser consciente de cómo nuestros principios definen nuestro paradigma y cómo nuestro paradigma, define nuestra forma de ver la vida.

Hacer conscientes buenos o malos hábitos que apoyan o desafían nuestros principios ayuda de forma drástica a tomar algo de control sobre nuestro paradigma. Según mi entendimiento, tomar control de nuestro paradigma es prácticamente equivalente a tomar control de nuestra vida.
La sensación de cambiar con éxito un principio, ser consciente de ello y saber que eso tiene un impacto directo en tu realidad, es sencillamente brutal.

Lo de gestionar personas y un departamento de ingeniería.

En los últimos trece años he asumido roles de gestión y siempre los había compaginado con el trabajo de programación o en roles de liderazgo técnico. No fue hasta hace tres años cuando dejé completamente de programar en mi trabajo y mi rol se convirtió en un rol puro de gestión de personas y de ingeniería.

No he parado de pensar en pendular en algún momento hacia un rol de líder técnico o individual contributor, por sentir envidia pura del impacto que realizan los roles de ingeniería pura. Sin embargo, este año tomé la decisión de mantenerme y seguir creciendo en roles de gestión pura.

Los retos en gestión son muy distintos a los de ingeniería y se aprende cada día. No son roles nada agradecidos pero la parte buena es que las lecciones que aprendes, te las puedes llevar a muchos otros contextos.

Como soy de la opinión (fuerte) de que los managers, directores y otros roles de gestión deben entender, ser capaces de aportar y estar al día de la tecnología, seguiré formándome y programando, pero en otro plano más personal sin esperar tener la agilidad de alguien que asume un rol puro de ingeniería de software.

He escrito y seguiré escribiendo sobre tecnología y gestión en mi espacio de Medium, algunas de las últimas cosas que he escrito:

Los libros que he leído y me han aportado en este campo son innumerables; creo que merecen una serie de artículos o entradas en este blog.

Lo de no fliparse.

Asumiendo roles de liderazgo o de gestión es muy fácil fliparse. Con fliparse me refiero a un patrón de comportamiento muy claro en el que perdemos humildad como grupo o individuos y nuestro ego no permite hacernos conscientes de partes críticas del contexto en el que actuamos.

Un ejemplo claro se da cuando tenemos éxito, especialmente en un entorno complejo. En esos casos, si no analizamos de forma objetiva nuestro contexto y los pasos que hemos dado, podemos asumir conclusiones erróneas y no entender exactamente por qué hemos conseguido algo. Esos factores pueden suponer una diferencia para replicar ese éxito en un contexto similar.

Y uno de los peligros de no analizar de forma objetiva nuestro éxito tras un reto concreto, es creernos que hemos conseguido todo nosotros solos.

Especialmente cuando tenemos que plantear una estrategia es importante no fliparnos a la hora de traernos lecciones supuestamente aprendidas; puede que recordemos haber construido cosas desde cero cuando en realidad partíamos de cimientos que estaban establecidos previamente gracias al trabajo anterior de otras personas.
Utilizar o seguir el trabajo base de otras personas no significa que no haya mérito o trabajo detrás por nuestra parte, pero seguramente al plantear la misma solución en un contexto similar, si tenemos en cuenta la necesidad de este trabajo previo, acertaremos en conseguir el éxito que esperamos de una forma más precisa.

Lo de cambiar de opinión.

Una de las premisas del libro Think again de Adam Grant, es la de estar preparados para cambiar de opinión. Recomiendo este libro sobre todo a personas que empiecen en el rol de manager y vengan de contextos en los que el liderazgo a base de “tener razón” estuviera muy presente.

Mantenerse firme en una opinión o creencia puede ser nocivo a varios niveles pero lo fundamental es que nos evita aprender de los demás.

Creo que cambiar de opinión se ve muchas veces como una falta de personalidad y líderes anclados en el pasado se mantienen con pánico en defensa de visiones que ellos consideran correctas sin retarse o dar mínima seguridad a otros para que les reten.

De nuevo, creo que he tenido suerte en los últimos años de contar con personas que me han retado y me han mostrado lo equivocada que estaba mi opinión. Gracias a todos ellas, he aprendido un montón de cosas.

Lo de leer.

Leer me da la vida. Es uno de mis vicios favoritos junto al café. Y lo mejor de todo es que ambos vicios se pueden disfrutar al mismo tiempo.

Algo que también me encanta es leer libros con más personas y debatirlos. La experiencia de lectura se hace mucho más interesante y en el caso de ensayos u otras lecturas de no ficción, creo que es uno de mis métodos de aprendizaje favoritos. Me encanta la sensación de descubrir que muy a pesar de mi tremenda seguridad por lo contrario, no había entendido realmente el punto del autor sobre algo.
Nadie es más inteligente que una comunidad y en este sentido, tengo la suerte de contar con más gente inquieta cerca para debatir lecturas.

Deberíamos disfrutar de leer sin obsesionarnos con terminar un número concreto de lecturas al año.
Sin ánimo de meterme en la forma en la que otros leen libros, observo mucha presión por terminar los libros que se empiezan; esos libros no van a desaparecer y no pasa nada por tener libros sin terminar durante años. A veces nos metemos mucha presión con las cosas equivocadas.

Me gusta mucho esta reflexión de Borges al respecto.

Básicamente estos son los titulares que tenía en mi mente ahora mismo. Mi idea es seguir escribiendo y detenerme de vez en cuando a repasar nuevos titulares que vayan surgiendo por el camino.

Nos leemos pronto.

Culturas de ingeniería: comunicación y documentación

Sun, 25 Oct 2020 16:07:01 +0000

Esta es la quinta y última entrada de una serie de artículos sobre culturas de ingeniería.

1. De qué hablamos cuando hablamos de cultura
2. Por dónde empezar
3. Madurez de nuestra cultura
4. Cultura de feedback
5. Comunicación y documentación

Cuando pensamos en las cualidades que debe tener un rol o cualquier persona para considerarse un buen profesional, la comunicación seguro que está entre las primeras.

Una buena comunicación tiene un impacto directo en la cultura de nuestra organización y puede significar una diferencia crítica a la hora de garantizar buen rendimiento y salud en los equipos.

En este artículo voy a repasar con vosotros aquellos aspectos que me parecen críticos a la hora de pensar en la comunicación como algo cultural en nuestra organización.

¿Qué consideramos comunicar bien?

Un aspecto fundamental que a menudo viene a nuestras mentes cuando pensamos en qué es comunicar bien es la oratoria. Cuidar el tono, ser elocuente y tener la capacidad de improvisar mensajes complejos con un ritmo y emoción adecuados.

La oratoria es una gran aptitud que a menudo se confunde con buena comunicación.

La oratoria brinda muchas oportunidades a la hora de influenciar a las personas ya que es un arma muy poderosa para convencer, sobre todo durante las primeras interacciones con otros.
Las personas que cuentan con una buena oratoria y buena comunicación tienen un impacto increíble en una organización y en la cultura.

Sin embargo, gozar de buena oratoria sin pulir otros aspectos comunicativos puede tener un impacto negativo en la confianza a medio y largo plazo.
En cuanto aparezcan de forma frecuente los problemas derivados de la falta de buenas prácticas en cuanto a comunicación se refiere, empezaremos a notar que las cosas no van bien.
Hablaremos de algunas de estas prácticas a lo largo de este artículo.

“Candor is the key to collaborating effectively. Lack of candor leads to dysfunctional environments.”
—Edwin Catmull

La transparencia y claridad son otros aspectos que nos vienen a la mente cuando pensamos en una buena comunicación.

Estos son aún más importantes cuando necesitamos comunicar en una situación complicada o solucionar problemas importantes dentro de nuestra organización: conflictos en los equipos, un problema de rendimiento de una persona, necesidades para que una persona crezca o transmitir feedback sobre aspectos que dificultan nuestro trabajo o que nos acarreen frustraciones que puedan derivar en plantearnos dejar la empresa por motivos que podrían haber sido fácilmente solucionables.

Hay motivos emocionales que nos pueden llevar a no ser claros en las comunicaciones, algunos pueden ser relacionados con el miedo al conflicto o por encontrarnos en una cultura en la que es más frecuente el culpar a las personas que mejorar los procesos.

Hay incluso motivos peores como el subestimar la necesidad de comunicación de algo “porque ya se entiende” o descuidar la transmisión de expectativas porque no se ven necesarias.
Hacer challenge de los procesos de comunicación periódicamente es fundamental, básicamente porque la comunicación siempre tiene margen de mejora.

Las comunicaciones que no son claras o se producen a destiempo generan desconfianza, frustraciones, falta de cumplimiento de las expectativas que no se han llegado a transmitir de forma clara e impactan en las planificaciones generando conflictos entre los equipos. A su vez, estos errores pueden también impactar en nuestra cultura generando frustraciones e incluso problemas como ansiedad, sesgos y malas decisiones a nivel estratégico.

Nos suele venir a la mente también la escucha activa como uno de los aspectos clave relacionados con la comunicación.
Escuchar antes de hablar es una práctica que nos enseña mucho de nuestro entorno, personas que apreciamos y que nos ayuda a crecer día a día.

Especialmente en roles relacionados con la gestión de personas y equipos, escuchar es clave para entender los problemas reales.
Incluso cuando la persona que nos hable no tenga razón o esté desencaminada totalmente en lo que dice, es importante escuchar todo lo que necesita decirnos porque puede darnos pistas de problemas que ni siquiera puedan estar relacionados a priori con lo que se está hablando.

“Sometimes creating a culture of listening is simply a matter of managing meetings the right way.”
—Kim Scott. Radical Candor

Una cultura sana tiene mucho de buena comunicación y sobre todo, escuchar todo lo que cada persona de la empresa tiene que decir.
Al final, hemos contratado profesionales también para escuchar sus aportaciones ¿no?

En las reuniones tomamos decisiones, vemos diferentes opciones e intentamos estar todos en la misma página. Es una oportunidad para asegurar que ciertos aspectos culturales como el de la escucha y el espacio para tener voz se produzcan.
Escribí algunas ideas sobre estos y otro temas relacionados sobre cómo mejorar nuestras reuniones en este artículo.

Hay varios aspectos importantes de comunicación que afectan directamente a nuestra cultura, vamos a ver algunos de los que he encontrado más importantes.

Comunicar decisiones con las que no estamos de acuerdo

Hay otro aspecto que creo importante en la comunicación, sobre todo en aquellos que son responsables de equipos o de transmitir la dirección a la que se va como organización: el disagree and commit.

El disagree and commit es una técnica importante para evitar que “todo sea un consenso” o que las decisiones se alarguen demasiado.
Incluso cuando una decisión se tome en consenso, puede que renunciemos a pelear eternamente algunos puntos que nos parecen importantes o tengan impacto claro bajo nuestro punto de vista en el día a día.

Aunque pueda parecer algo malo, el disagree and commit es una técnica muy positiva o al menos más positiva que la alternativa: no llegar a tomar decisiones.

El disagree and commit consta de dos partes fundamentales:

disagree: expongo las razones por las que no estoy de acuerdo con tomar una decisión e intento dar una alternativa. Dar una alternativa es muy valioso en este punto porque aunque no se tome ese otro camino, muestra que había otras posibilidades encima de la mesa y nos puede ayudar a mejorar en el futuro. Sin alternativa ese disagree sería muy difícil de diferenciar de una simple queja.
commit: me comprometo a ejecutar la decisión de forma profesional y haciendo todo lo posible para que tenga éxito.

La segunda parte es muy clave y relacionada con la comunicación. Comunicar a los equipos un camino a seguir con el que no estás de acuerdo es muy complicado y es un punto en el que es muy fácil fallar, sobre todo cuando son cosas que impactan a un equipo en el que estás participando como líder o manager.

Las consecuencias de fallar en una comunicación de este tipo son muy graves, entre ellas las que he experimentado con frecuencia son

Crear sesgo en el equipo con el foro en el que se toman las decisiones o con algunos managers en concreto, provocando inseguridades en los equipos o decisiones que van en contra de la dirección común acordada.
Crear o hacer más patente una cultura de “ellos contra nosotros”, provocando conflictos entre departamentos o equipos.

Aunque es importante el disagree and commit, cada uno de nosotros debemos valorar si las decisiones empiezan a traspasar barreras éticas o que entran en conflicto con nuestros valores e integridad.
En este punto, antes de provocar problemas como los que hemos visto, debemos plantearnos si es sano continuar en una cultura o empresa en la que no encajamos a esos niveles.

Hay mucho sobre lo que leer sobre este tema, os recomiendo especialmente este artículo de Cedric Chin sobre el tema.

Elegir bien los canales cuando necesitamos comunicar algo

Normalmente cuando necesitamos comunicar algo que afecta a varias personas o equipos, el mensaje sufre un periodo de maduración durante el cual puede sufrir cambios.

Dependiendo del contexto, naturaleza del mensaje o los propios receptores, comunicar un mensaje que está a medias o no totalmente hablado por todas las personas a las que les afecta, puede generar conflictos, desconfianza o decisiones precipitadas.

Es muy frecuente escuchar cosas como “se ha escuchado X en una conversación de pasillo”, “estamos trabajando en esta propuesta pero parece que Y ya ha tomado una decisión”.
Este tipo de rumores ocasionados por comunicaciones inexactas o no coordinadas son un problema grave que impacta en la cultura y en muchos contextos se asumen como algo “normal”.

La realidad es compleja y a veces no podemos contar con el tiempo para afinar o consensuar bien un mensaje, pero debemos aprovechar las ocasiones en las que sí podemos hacerlo de forma controlada.

Es importante definir los canales en los que se pueden dar ciertos mensajes e información y qué momento es el adecuado.

Este es un aspecto clave y hay herramientas que nos pueden ayudar a planificar bien las comunicaciones, especialmente cuando estén relacionadas con anuncios de cambios de procesos o de la ejecución de una decisión crítica.

Comunicar las expectativas

Algo muy peligroso a la hora de gestionar la comunicación es asumir que hay cosas que no son necesarias de comunicar, porque son de sentido común.
Y una de las cosas en las que podemos fallar muy fácilmente es en la comunicación de las expectativas.

Comunicar las expectativas que tenemos con las personas que entran en nuestro equipo y también con los roles que van a interactuar no sólo con equipos sino con otros departamentos es clave para asegurar un buen rendimiento y la autonomía, aspectos claves para tener una buena cultura.

A veces nos puede ocurrir que esperamos cosas muy concretas de una persona o un rol y no terminamos de comunicarlas de forma clara, esto puede generar sesgos muy fácilmente cuando la otra parte ni siguiera ha tenido la oportunidad para demostrar que es capaz de hacer lo que se le pide porque simplemente no es consciente de que lo que se le está pidiendo.

Tenemos herramientas como el Career Path y los valores de la empresa (y los del equipo) para dejar claras las expectativas pero sin duda, la herramienta más importante con la que podemos y debemos contar es el feedback.
Comentamos más en detalle sobre cómo crear una cultura de feedback en un artículo anterior.

Si hay algo en lo que no debemos relajarnos a la hora de asegurar una buena comunicación, es a la hora de dejar bien claras las expectativas que tenemos con una persona, equipo, rol o proceso.

Asegurar un lenguaje común

En su libro Domain-Driven design: tackling the complexity in the hearth of software, Eric Evans escribió:

On a project without a common language, developers have to translate for domain experts.
Domain experts translate between developers and still other domain experts.

Developers even translate for each other.
Translation muddles model concepts, which leads to destructive refactoring of code.

The indirectness of communication conceals the formation of schisms —different team members use terms differently but don’t realize it.
This leads to unreliable software that doesn’t fit together.

The effort of translation prevents the interplay of knowledge and ideas that lead to deep model insights.

DDD nos ha mostrado una parte estratégica que podemos utilizar no sólo para construir software de una forma más efectiva, sino también para detectar formas de distribuir el trabajo reduciendo los problemas de comunicación y la carga cognitiva que pueden sufrir los ingenieros de software al lidiar con la complejidad.

Uno de los principales orígenes de esa complejidad suele darse a la hora de entender los diferentes conceptos críticos en nuestro negocio. Y como la ley de Conway bien expresa, estos problemas de comunicación se unen a otros que impactan directamente en la arquitectura de nuestros sistemas y plataformas:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
—Melvin E. Conway

Como parte de la gestión de la comunicación y la organización de nuestros equipos para evitar problemas de alineamiento entre ellos, un glosario común es una herramienta fundamental cara a entender los conceptos de la misma forma.

Cuanto más común sea el ejercicio de aclarar estos conceptos y modelar basándonos en ellos, más problemas de comunicación nos ahorraremos en el día a día contribuyan a aumentar la complejidad en nuestros sistemas.

En esta línea, es importante también asegurar que las definiciones y entendimiento de conceptos que usamos en nuestro día a día estén alineados con el entendimiento de la comunidad fuera de nuestra empresa.
Por ejemplo, si empleamos el término “retrospectiva” como una dinámica que nada tiene que ver con cómo se conoce fuera de nuestra empresa estamos dificultando a que nuevos miembros que se incorporen a nuestros equipos conozcan nuestro contexto y por otro lado, vamos a tener problemas de gestión de expectativas en los equipos.

Un último punto que quería añadir tiene su origen en una conversación que tuve hace tiempo con un amigo. Comentábamos sobre la típica frase que solemos utilizar, generalmente con la intención de dejar claro que en nuestros equipos no queremos héroes: “en nuestros equipos nadie puede ser imprescindible”.
Generalmente todos conocemos el contexto y el por qué de comentar esto, pero debemos plantearnos cómo puede llegar a entenderse por alguien que no venga de una cultura similar a la nuestra: “¿significa eso que entonces todos somos prescindibles? Y si soy prescindible, ¿realmente les importo algo al resto de los compañeros que repiten ese mantra?”.

Aunque nuestra intención sea buena, a veces debemos plantearnos si estamos dejando claro qué queremos conseguir con un concepto y si todo el mundo lo entiende de la misma forma.

Cultura de documentación

“If it is not written down, it does not exist.”
—Philippe Kruchten

Cuando pensamos en documentación asumimos que nos estamos refiriendo a una parte concreta en un proceso dedicada a reflejar aspectos que consideramos importantes para otros compañeros.

Hablar de una cultura de documentación va bastante más allá, concretamente a que la documentación sea algo natural que forme parte de nuestro trabajo en todo momento y no sólo en un espacio de tiempo dedicado para ello o en un único ámbito concreto.

También es importante entender que “tener mucha documentación” no implica gozar de una buena cultura de documentación.

Una buena cultura de documentación persigue estos beneficios:

La información es fácil de encontrar y de descubrir (Findability y Discoverability)

Normalmente el primer remedio que nos encontramos cuando pensamos en cómo poder encontrar fácilmente (findability) la información que hemos ido registrando a lo largo de los años es una herramienta que conocemos bastante bien: el buscador.

Los buscadores suelen ser la bala de plata en la que confiamos para asegurar que la información va a encontrarse cuando alguien la busca.

Sin embargo, para encontrar algo, la persona debe saber qué debe buscar y también utilizar correctamente los patrones semánticos que le permitan tener un mayor éxito en su búsqueda.

Por ello, cada vez se da más importancia a cómo de fácil es descubrir el contenido (discoverability) aun sin saber exactamente lo que estás buscando. Los filtrados, índices en cada sección de nuestra documentación, asegurar un único punto de verdad, gestionar la documentación deprecada, definir convenciones y estructuras de documentación comunes entre los diferentes equipos y proyectos nos ayudarán a mejorar la experiencia de obtención de información por nuestros compañeros.

La documentación está siempre actualizada

Hace algún tiempo escribí algunas pautas sobre cómo podemos generar documentación técnica de forma automática con el objetivo de mantenerla viva.

Hay que pensar que no todo es documentación técnica, algunos otros ámbitos como los action points de reuniones, decisiones de equipo e información de procesos de personas forman parte de una documentación importante. Debemos encontrar formas de que esta información esté igualmente actualizada, idealmente de forma automática.

Rotación de las personas encargadas de documentar

El mejor mecanismo para que todas las personas del equipo sepan dónde y cómo se registra la información, es evitando que siempre sean los mismos los que documentan todo o ciertos aspectos específicos.

Conseguir que las personas de nuestro equipo busquen la información como primer impulso antes de preguntar

Este es el punto más complejo de conseguir incluso atacando de forma efectiva los puntos anteriores. Sin embargo, este comportamiento es el que podemos tomar como referencia a la hora de asegurar que tenemos una buena cultura de documentación.

Comunicación asíncrona

Aunque para muchos la comunicación asíncrona era algo muy natural, especialmente para las personas que trabajan desde hace años en remoto, está empezando a ser una herramienta indispensable en la nueva realidad en la que nos encontramos.

Es un paso adelante que conlleva mejorar nuestra gestión en las reuniones y también de la comunicación en general.

La comunicación asíncrona nos hace ganar tiempo y nos da la libertad de organizarnos mejor, pero conlleva una serie de retos:

Gestionar la atención de los canales asíncronos: cada vez serán más las conversaciones que lleguen a través de diversos canales, incluso teniendo una única herramienta de mensajería
Gestionar el impulso de contestar inmediatamente: a nivel social no todo el mundo maneja bien que no le contestes inmediatamente en una conversación como Whatsapp o Telegram, por lo que estamos condicionados a la hora de gestionar esto en un entorno profesional. Es clave acordar con nuestros compañeros las expectativas para mitigar esto.
Evitar las conversaciones en las que hay un grupo parcial de los interesados o afectados por la misma: es la versión moderna de las conversaciones de pasillo.

Conclusión

A la hora de asegurar una buena comunicación debemos asumir que siempre hay margen de mejora en un abanico amplio de prácticas y conceptos a tener en cuenta.

En este artículo he intentado recopilar algunos de esos aspectos que nos pueden impactar de forma directa cara a garantizar una buena cultura de ingeniería.

Sobre reuniones

Sat, 18 Jul 2020 16:07:01 +0000

Hay mucho escrito sobre la eficiencia y buenas prácticas a la hora de gestionar reuniones en el ámbito profesional.

Aún teniendo claras pautas importantes, las reuniones suelen ser motivo de queja y frustración para muchos profesionales. Hay ciertos personas que ven como algo normal tener su calendario copado de reuniones, con incluso varias de ellas solapadas entre sí, justificándolo con su rol, título o responsabilidad. Desde hace años es conocido el lema “busy is the new stupid” iniciado por una conversación entre Bill Gates y Warren Buffet.

En algunos contextos parece imposible reducir el número de reuniones y el mero hecho de plantearse rechazar una convocatoria puede ser un factor de estrés importante para una persona que no tiene claras las implicaciones que pueda tener el hacerlo, incluso si es imposible para ella acudir a dicha cita.

Dada nuestra naturaleza social, las reuniones son necesarias y no deberían ser algo negativo, sino todo lo contrario.

Quería escribir este artículo con algunas buenas prácticas que he ido aprendiendo con el tiempo y que creo que tienen un impacto significativo en cuanto a eficiencia, salud, cultura y respeto a las personas con las que trabajamos día a día.

Evitar reuniones y promover la comunicación asíncrona

La reuniones síncronas suponen una inversión de tiempo, atención y disponibilidad que se traduce en un alto coste económico.
La dificultad para encontrar disponibilidad a la hora de agendar una reunión puede ser exponencial si los integrantes disponen de un calendario que suele estar precisamente completo de reuniones.

Teniendo esto en cuenta, cuantas más reuniones o ceremonias síncronas podamos evitar, más efectivos seremos a la hora de encontrar huecos para aquellas reuniones que sí que merezcan esta inversión.

Algunos ejemplos de reuniones que se pueden tratar como comunicación asíncrona:

Un buen uso de la herramienta de gestión de proyectos para representar el estado y bloqueos de las tareas, en lugar de tener que hacer un “reporte” en una reunión o consumir tiempo de una daily para eso.
Las propias daily o stand up pueden ser asíncronas si utilizamos Slack y sus workflow. También podemos utilizarlos para pedir feedback de forma asíncrona, entre otras muchas cosas. Son una genial herramienta para automatizar y conducir de forma asíncrona un montón de mecánicas y rituales.
Aclarar dudas directamente en la herramienta de documentación que utilicemos o mediante documentos compartidos en Google en lugar de fijar una reunión para ello.

Prevenir que las reuniones duren exactamente una hora o media hora

Un anti-patrón de productividad ya muy conocido es el de agendar reuniones con duraciones fijas por defecto de una hora u hora y media. Antes de agendar reuniones con un duración de una hora, piensa que es muy posible que los asistentes de esa reunión tengan otra que empiece justo después, sin disponer de tiempo para descansar mentalmente entre las dos ni gestionar el cambio de contexto.

Esta falta de descanso puede ir incrementando el nivel de estrés de las personas a lo largo del día, especialmente cuando se trabaja en remoto y no hay un cambio de sala entre reuniones. Si entramos en esa dinámica podemos encontrarnos fácilmente con cuatro reuniones seguidas sin haber tenido ni cinco minutos para descansar la vista o incluso ir al baño.

Esto no quiere decir que todas las reuniones deban ser de 50 minutos. Por ejemplo, si crees que la reunión va a durar una hora, quizás sea buena idea poner la reunión con una duración de una hora y veinte minutos. Esto va a asegurar que si la reunión termina antes o a tiempo, los asistentes tendrán asegurados al menos diez minutos de paz mental entre reuniones.

Ser puntual y finalizar a tiempo

Relacionado con el punto anterior, llegar tarde a una reunión puede suponer que esa reunión termine más tarde de lo acordado y provoque que vayas generando retrasos encadenados si tienes varias reuniones ese día sin espacio entre las mismas. Además, es muy posible que ese retraso pueda ser considerado como una falta de respeto por el resto de los asistentes que han reservado su tiempo a sincronizarse contigo.

De igual forma, debemos tener presente que si no terminamos la reunión en el tiempo establecido, estamos siendo en cierto modo egoístas con el tiempo de los demás, impactando en su disponibilidad y tiempo de forma directa.

Si han quedado temas en el tintero, quizás debamos plantear otra reunión para comentarlos o buscar la resolución de los mismos mediante algún mecanismo asíncrono; alargar la reunión debe ser el último recurso ya que es posible que hay implicaciones al hacerlo de las que no seas plenamente consciente.

Al agendar la reunión, dejar claros los puntos de la agenda y el objetivo de la misma

Cuando agendas una reunión sin indicar una agenda de la misma, los asistentes no van a contar con la oportunidad para prepararse con antelación sobre los puntos que se van a discutir en la reunión. Esto impacta en la efectividad de la misma.

De forma adicional, es buena idea establecer los objetivos o la expectativa principal de esa reunión. Algunos ejemplos:

“Vamos a tomar una decisión sobre [algo]”
“Vamos a darnos feedback sobre estos puntos”
“No vamos a tomar una decisión, el objetivo es tener contexto y entendimiento común sobre [algo] y establecer siguientes pasos”

Hay múltiples herramientas como Notion, Confluence que cuentan con plantillas para establecer notas de reuniones. Si no utilizas estas herramientas, puedes utilizar documentos de Google o cualquier otro sistema en el que se pueden compartir una simple tabla o a modo de listado qué puntos se van a tratar. De esta forma se puede utilizar el mismo documento como guía y tener documentado todo al final de la reunión.

Esto también nos facilita discutir sobre esos puntos de forma asíncrona mediante comentarios, ahorrando tiempo de la reunión antes de que esta se produzca.

Si la reunión es rápida o no hay una costumbre aún adquirida de preparar este tipo de documentos, un primer paso interesante que suele tener un impacto positivo suele ser simplemente indicar una descripción en la convocatoria que siga un formato parecido a este:

Driver: Nombre Apellidos

Objetivo: Establecer siguientes pasos para el proyecto

Agenda:

* Estado actual, 10"
* Conclusiones tras la primera iteración, 20"
* Siguientes pasos, 20"

Si no eres la persona que organiza la reunión y ves que la misma no tiene agenda o una descripción, puede ser buena idea pedirle que prepare una o ayudarle a prepararla.

Decidir quién va a ser el driver de la reunión antes de la misma

Algo típico que suele ocurrir en un equipo es que siempre sea la misma persona la que modere o esté atento de cómo se desenvuelve la reunión. Muchas veces suele coincidir que esa persona es la que agenda la reunión porque tenga el rol de manager o porque ya ha dinamizado alguna otra reunión antes.
En otras ocasiones la reunión termina siendo conducida de forma improvisada por las personas con más iniciativa o facilidad de palabra del equipo.

Para evitar esa improvisación y mejorar la eficiencia de la reunión, es muy recomendable que se sepa antes de la misma quién es la persona encargada de guiar esa reunión.

Otra buena práctica es rotar esa responsabilidad entre los miembros del equipo para que no sea siempre la misma persona, dando la oportunidad a todo el mundo de poder conducir las reuniones. Esto evita dependencias y hace crecer a todos los miembros del equipo.

Asegurar que todo el mundo está conectado con lo que se está comentando en la reunión y tiene espacio para participar

Antes de nada, es importante asegurar de que el tono y el lenguaje es inclusivo en las reuniones. Esto es muy importante y creo que es algo sobre lo que debemos dar feedback cuando no se produce o hay margen de mejora.

Si hay asistentes que están trabajando desde casa, es buena idea crear una regla para dejar claro cuando alguien quiere hablar para prevenir el solapamiento entre los interlocutores o que unas personas eclipsen a las otras.
Por ejemplo, se puede pactar que cuando alguien quiera añadir algo sobre un tema sobre el que dos personas están hablando, se levante la mano para que todo el mundo sepa que hay algo que decir y que no se quiere interrumpir una discusión.
Cuando hay una discusión en la que varias personas están hablando a toda velocidad, puede haber alguien que no sepa cómo contribuir a esa conversación y deje de hacerlo si no hay un mecanismo de este tipo.

Si hay personas de diferentes culturas en la reunión o alguien se siente muy incómodo al hablar, es buena idea estructurar la reunión para que cada asistente tenga unos minutos para comentar su punto de vista sobre un punto de la agenda, siguiendo un orden o mediante round-robin, por ejemplo.
Suele ser importante también preguntar directamente sobre su punto de vista a las personas que han permanecido calladas durante una discusión o la conversación sobre algún punto concreto de la agenda.
Esto último es importante también cuando esas personas han mostrado intención de meterse en una discusión pero ha sido eclipsada continuamente durante la misma.

Además de todo esto, es importante asegurar buenas prácticas de comunicación. Estas mejorarán la eficiencia e inclusividad en las reuniones.

Algunas de las más importantes para mi son las siguientes:

Promover la escucha activa

Es importante asegurar que todas las personas puedan terminar de comunicar su mensaje sin ser interrumpidas en medio del mismo. Al margen de asegurar que las conversaciones en las reuniones sean sanas, saber escuchar es una habilidad que es muy valiosa de trabajar para dentro y fuera del aspecto profesional.

Mantener el scope o foco

Este es el punto más importante para asegurar que una reunión sea productiva. A veces es un reto mantener el foco cuando hay mucha gente en una reunión, por lo que puede ser necesario hacer un esfuerzo extra en este punto.

Prevenir que actitudes dogmáticas o posiciones de “examinador”

Este punto está muy relacionado con la escucha activa. Tiene mucho que ver con saber entender el mensaje principal sin centrarse tanto en los detalles, dejando al lado prejuicios y sobre todo estar abiertos de mente a mensajes u opiniones que puedan ser muy diferentes a lo que estemos acostumbrados.

Hay mucha oportunidad de crecimiento al evitar este tipo de posiciones y también pueden evitar frustraciones en personas que puedan traer un soplo de aire fresco al equipo.

Si no tienes webcam, debes hacer un esfuerzo extra

Cuando asistimos a una reunión en la que hay gente trabajando en otra localización y nuestra cámara no funciona, es clave hacer un esfuerzo extra para describir nuestras reacciones o ser consciente de nuestro tono al responder o hablar. En estas situaciones la información que tienen los receptores es muy limitada y puede que los mensajes se malinterpreten con mucha facilidad

Asegurar que al final de la reunión queden documentados tanto las decisiones como los puntos de acción

Es importante dejar documentado un registro de las decisiones tomadas durante la reunión y también las acciones o tareas que se han pactado realizar en la misma.

De esta forma alguien que no haya podido atender a la reunión tiene contexto del resultado de la misma y también, todo el mundo sabe dónde puede consultar estas cosas para no confiar únicamente en su memoria.

Los puntos de acción y decisiones deben ser claros, entendibles y fáciles de encontrar, además de contar con contexto para poder ser ejecutados sin ningún tipo de duda y entender las limitaciones o factores que han influido en los mismos.

Dar feedback sobre la reunión

Como hemos comentado, las reuniones son caras y por ello, todo feedback para mejorar cómo se llevan a cabo va a ser muy valioso tanto para las personas que han participado como para la cultura de la empresa a largo plazo.

Conclusión

Las reuniones pueden tener un coste muy alto en varios aspectos y no siempre podemos sustituirlas en favor de comunicación asíncrona.

Es importante hacer todo lo posible para sacar el máximo partido de las mismas, respetando el tiempo de las personas con las que trabajamos.

Culturas de ingeniería: cultura de feedback

Sat, 21 Mar 2020 16:07:01 +0000

Esta es la cuarta entrada de una serie de artículos sobre culturas de ingeniería.

1. De qué hablamos cuando hablamos de cultura
2. Por dónde empezar
3. Madurez de nuestra cultura
4. Cultura de feedback
5. Comunicación y documentación

En esencia, el feedback es información que recibimos de un entorno o de un sistema al interactuar con el mismo.

A nivel social, obtendremos feedback al interactuar con una o más personas o trabajando en un equipo que vaya en una dirección común siempre que existan mecanismos, voluntad o hábitos que nos los proporcionen.

Dotar de mecanismos mediante los cuales las personas puedan recibir feedback tanto de sus managers como de sus compañeros, tendrá como resultado que estas confirmen que van en la dirección correcta y crezcan en puntos que aporten tanto al beneficio de la empresa como al suyo personal.

Las empresas en los que el feedback sea uno de los aspectos más importantes y cuidados de su cultura, tienen muchas posibilidades de aumentar su retención de talento y detectar problemas mucho antes de que estos tengan un impacto crítico en el día a día.

Cómo es un buen feedback

Un buen feedback se centra en algo en concreto: un hecho o un comportamiento por ejemplo. Nunca se centra en una persona. Esto es un punto importante ya si el centrar el feedback se centra en una persona y no en hechos o comportamientos concretos, nuestros prejuicios y los prejuicios de la persona receptora influirán negativamente eliminando toda posibilidad de que el ejercicio sea constructivo o sirva para algo.

Otra característica de un buen feedback es el contexto y el momento. El contexto es crítico. Poner ejemplos dentro del contexto, servirá para que el mensaje se pueda aprovechar y entender completamente. Un ejemplo sin contexto puede ser fácilmente malinterpretado y tener consecuencias contraproducentes.

El momento también es importante. Cuanto más alejado sea el momento del hecho y del contexto, menos efectivo será el feedback. Se suele decir que pasadas las primeras 48 horas de un hecho concreto, el feedback ya es tardío y su eficacia ha perdido valor.

Acompañado al contexto, el impacto es algo importante a incluir en el feedback. Describir bien el impacto que ha tenido un comportamiento en el entorno o en otra persona ayuda a comprender mejor la importancia de corregir o mejorar el comportamiento.

Feedback positivo, de mejora o correctivo

El feedback puede ser positivo, de mejora o correctivo. Hago distinción entre mejora y corrección porque creo que es importante la diferencia de enfoque y objetivo deseado al darlo. Hablo de esto más adelante en esta sección.

El feedback positivo parece que es el más sencillo de dar, pero curiosamente es el que menos se cuida. Es importante dar correctamente el feedback positivo para que sea útil. Hablaremos más adelante sobre anti-patrones a la hora de dar feedback, pero es importante recalcar que el feedback positivo no es una palmada en la espalda, un elogio o reconocimiento o una herramienta para utilizar antes de dar otro feedback que es el que realmente queramos dar.
Debemos tener en cuenta que el objetivo de dar este tipo de feedback, es que la persona mejore y no solo que se sienta bien al recibirlo.

Cuando damos feedback positivo es muy importante recalcar el contexto y el impacto junto al hecho concreto sobre el cual estamos dando feedback. Es posible que la persona no le haya dado importancia a un hecho porque no comprende todo lo que ha desencadenado porque no tiene visión o simplemente porque no ha podido hacer seguimiento. En estos casos el contexto es importante también para que esa persona entienda las circunstancias concretas en las que ese comportamiento ha tenido ese impacto positivo. De esta forma podrá seguir adoptándolo y reforzándolo en futuras ocasiones en las que el contexto sea similar.

Cuando damos feedback de mejora, la idea es que la persona lo tenga presente para que reflexione y aplique libremente los cambios que vea necesarios con nuestra ayuda si fuese necesario. Este feedback va orientado a que la persona crezca.

Cuando damos feedback correctivo, estamos especificando también qué comportamientos y cambios esperamos que esta persona aplique. Este feedback suele darse cuando hay banderas rojas en la actitud o comportamiento y se precisa una corrección de cosas concretas antes de que provoquen problemas mayores que afecten al equipo o lleguen incluso a conllevar la necesidad de despidos.

El feedback como cultura

El feedback es una herramienta fundamental alineada con una cultura basada en la mejora continua.

Cuando el feedback no es solo un hábito de ciertos managers o personas concretas que se preocupan por darlo o pedirlo, sino que es algo asumido por todas las personas de los equipos, podemos decir que el feedback en nuestra empresa, es cultural.

Al disponer de feedback como cultura, podemos desarrollar y gozar de cosas tan importantes como:

Dar y recibir feedback es asumido como algo habitual y no se recibe como un ataque, sino como un regalo
Surge la necesidad de tener una dirección clara porque se demanda feedback al respecto para poder conducir el feedback
Las personas están más abiertas a escuchar y cuestionar si podrían aplicar mejoras a todo lo que hacen
Las personas no se cortan a la hora de expresar si creen que algo se puede hacer mejor y disponen de espacio y mecanismos para hacerlo
La comunicación se hace más eficiente y no se centra en lo negativo
Los prejuicios se reducen
Lo que se expone termina por generar cambio

Para que el feedback sea efectivo y se interiorice en nuestra cultura, es muy importante hacer seguimiento del estado de las acciones de mejora propuestas tras conversar acerca del feedback.

Mecanismos y herramientas

Reuniones one on one

La reunión de 1-1 es una herramienta ya conocida y muy asentada en muchas culturas, que es utilizada por managers y personas del equipo para construir una relación de confianza, dar feedback, establecer objetivos y hacer seguimiento de una persona.

Para mí, estas reuniones no son opcionales y de hecho, creo que son las más importantes que se puedan tener como manager. Dependiendo del número de personas a las que estoy haciendo seguimiento en un determinado momento, me gusta tener 1-1 con cada persona cada dos o tres semanas, como máximo.

Si hay que trabajar más directamente con una persona o corregir comportamientos, entonces veo imprescindible tener 1-1 semanales con la misma.

Hay mucho escrito sobre cómo abordar 1-1 pero en mi opinión, lo importante es que se hagan sin forzar un guion ni una duración específicos. Tampoco han de ser necesariamente entre un manager y un miembro de un equipo; cualquiera debería poder convocar un 1-1 a cualquier miembro de la empresa cuando necesite comentar algo.

Conozco entornos en los que poder reservar un tiempo periódico para hablar con las personas con las que trabajas es una odisea o incluso puede suponer un problema para la persona o para ti como manager. En estos contextos donde no es amigable tener este tipo de reuniones y por tu circunstancia personal no puedas cambiar de trabajo, mi sugerencia es aprovechar descansos o huecos de café, comidas, viajes a clientes o incluso, llevar a la persona de cañas o coca colas después del trabajo si fuese necesario. No es una solución ideal ya que no favorece la desconexión, pero conseguir establecer este tipo de espacios y mecánicas de forma oficial puede requerir convencer de ello en determinados foros, siendo una batalla a largo plazo. Mientras se persiguen estos cambios culturales, necesitaremos tomar tradeoffs.

Mediante tradeoffs o no, siempre buscando la privacidad con la persona, creando un entorno seguro favorable a dar o recibir feedback para ambas partes. En estas reuniones debemos dejar prejuicios fuera de ese espacio, agudizar nuestra escucha activa y ser precisos a la hora de dar feedback y receptivos a la hora de recibirlo.

Los objetivos y expectativas de estas reuniones los deben consensuar las dos personas que van a participar en las mismas. Como en todas las reuniones y siempre que sea posible, lo ideal es poder dejar escritos los temas más importantes que se quieran tratar antes de la reunión, para que la otra persona recopilase información o esté en contexto antes de la misma.

Disponer de herramientas como un Career Path cuidado pueden ayudar a que el feedback pueda ser conducido también al crecimiento dentro de la empresa.

Feedback 360

Esta mecánica consiste en recopilar feedback por parte de personas que han interactuado con la persona a la que se va a dar feedback. Es una mecánica valiosa, sobretodo para que dicha persona disponga de feedback por parte de personas de diferentes áreas y con diferentes perspectivas que han trabajado con ella directamente.

Performance reviews

Las performance reviews son las reuniones en las que se hace una recopilación de cómo ha sido la evolución de una persona a la hora de alcanzar sus objetivos.

Me pareció interesante mencionar esta mecánica porque esta reunión debe ser un resumen final de todo lo que se haya visto durante las 1-1 periódicas y otras mecánicas como los Feedback 360.

En muchas ocasiones he visto que estas reuniones existen al final del año sin haber dedicado tiempo durante el año a hacer seguimiento de la persona y por lo tanto, sin haber dado feedback previo que pudiese ayudar a la persona a alcanzar sus objetivos. Para mí, esta reunión no tiene sentido sin un trabajo constante durante todo el año, que considero imprescindible en el rol de manager.

Os dejo aquí un artículo del MIT con recursos muy útiles sobre estas reuniones.

De nuevo, disponer de un buen Career Path en la empresa, puede aumentar la eficacia de estas reuniones.

Retrospectivas

Las retrospectivas son una buena herramienta para dar y recibir feedback ya no a nivel personal, sino como equipo.

Hay muchas mecánicas para conducir retrospectivas pero lo principal es recoger feedback tanto de lo que se ha hecho bien como de lo que se ha de mejorar como equipo. Es importante que se haga seguimiento de los action point que se establezcan en las retrospectivas para que estas no caigan en saco roto, lo cual puede desmotivar al equipo y conseguir que el feedback más valioso vaya desapareciendo.

Postmortems

Los postmortem son un tipo de retrospectiva que se centra en un problema o catástrofe que hemos tenido y de la que queremos aprender para que no vuelva a ocurrir.

Lo importante de los postmortem es que deben buscar lecciones aprendidas y no culpables. Al involucrar diferentes áreas o incluso empresas, esta debe ser la base principal y puede ser un reto al involucrar diferentes culturas en las que esta premisa no siempre se cumpla.

Antipatrones

Feedback sandwich

Este anti patrón es bastante conocido por lo altamente utilizado que es por algunos managers. Básicamente consiste en sacar un tema que introduce la conversación hacia algo en el que creamos que la persona pueda estar confortable o directamente dar un feedback positivo para después llegar a nuestro objetivo, que es dar un feedback de mejora o correctivo.

Hay algunos libros de gestión que aconsejan el uso de esta práctica pero yo lo considero un anti patrón. La razón es básicamente que las personas con la que trabajamos no son estúpidas y al no serlo, no les va a gustar que les trates como tal.

Por mi personalidad, me gustan las cosas directas y a la cara cuanto antes mejor, por lo que este tipo de prácticas no las considero para nada acertadas.

Feedback tardío

Esperar más de 48 horas para dar feedback es un error típico también. Hay mil razones que nos impidan dar feedback en este rango de tiempo, pero debemos tener presente que cuánto más tiempo pase, el feedback será más inefectivo o incluso contraproducente.

Feedback sin ejemplos concretos

Dar feedback sin ejemplos puede llegar a malinterpretarse o generar confusión a la persona. Si el feedback es basándonos en algo que se haya escrito, debemos mostrárselo a la persona para que nos dé más información o comprenda a qué nos referimos.

Si ha sido un comportamiento de otro tipo, es crítico dar el feedback cuanto antes para que no se olviden detalles importantes del objeto del feedback.

Feedback para culpabilizar

El patrón más importante a evitar es el feedback que realidad busca culpables en lugar de exponer un hecho o comportamiento concreto mediante ejemplos objetivos con los que poder trabajar.

Conclusión

En este artículo hemos visto a qué nos referimos con dar feedback y qué mecánicas existen para que forme parte de nuestra cultura.

El feedback es una herramienta muy importante para crecer tanto a nivel personal como a nivel profesional.

Culturas de ingeniería: madurez de nuestra cultura

Thu, 05 Dec 2019 19:07:01 +0000

Esta es la tercera entrada de una serie de artículos sobre culturas de ingeniería.

1. De qué hablamos cuando hablamos de cultura
2. Por dónde empezar
3. Madurez de nuestra cultura
4. Cultura de feedback
5. Comunicación y documentación

En este artículo vamos a ver diferentes estados de madurez en los que puede estar una cultura de tecnología.

Esta escala de tres niveles está inspirada en la que se plantea en el libro Elastic Leadership de Roy Osherove.
Me he tomado la libertad de adaptarlos un poco en base a mi experiencia y he añadido, en cada uno de ellos, algunos puntos que me resultan importantes.

Hay que tener en cuenta que, aunque hablaremos de tres niveles, en la vida real no sólo hay blancos o negros y es posible que una misma empresa tenga estos diferentes niveles repartidos entre diferentes áreas, oficinas o equipos.

Supervivencia

El peor escenario posible es una cultura de supervivencia. Cuando trabajamos en una cultura de este tipo, la sensación de caos es muy alta y tanto el estrés como el sobre-esfuerzo se vuelven algo implícito dentro de nuestro día a día.

En este tipo de entornos la rotación de personal suele ser muy alta y la ausencia de documentación unida a la presión de fechas, hace que surjan ciertos perfiles que hagan el papel de héroes, los llamados desarrolladores 10x o el perfil paracetamol del que ya escribí por aquí.
El mentoring básicamente se basa en un “quita que ya lo hago yo”.

Suele ser habitual que los equipos tengan cambios constantes de foco. Los proyectos se retrasan pero no se frena la nueva entrada de trabajo. La presión se hace muy fuerte y la sensación que los equipos perciben es la de estar en un constante periodo en el que todas las entregas sufren retrasos.

En los entornos en los que esto se hace más latente, los stakeholders realizan sus peticiones directamente a los desarrolladores. No se priorizan las peticiones e incluso se hacen invisibles a los project managers, lo que impacta directamente en los proyectos en curso.
Los retrasos constantes generan subidas a producción sin la calidad mínima necesaria lo que obliga a hacer rollbacks que saturan a los equipos con soporte a problemas urgentes en producción. Muchos de estos equipos ya han empezado otros proyectos nuevos que deben pararse de forma no oficial para atender peticiones sin ningún tipo de control ni prioridad.

La comunicación se hace complicada y nunca hay tiempo para documentar. La documentación se deja para el final de los proyectos que queda como un mero entregable y destinada a quedarse obsoleta al no contemplar correcciones después de la entrega o incluso cuando se desarrollan evolutivos.

Al haber problemas de comunicación, se sobrecargan las agendas de los project manager con reuniones para clarificar dudas o malentendidos pero no se cuenta con los desarrolladores para “no quitarles tiempo”.
Los problemas de comunicación se hacen más graves y los desarrolladores terminan por entrar a reuniones cuando ya es demasiado tarde y tienen poco margen para actuar.

Todo este panorama unido al estrés al que todas las personas del equipo están sometidas, hace que los errores de una persona terminen por adquirir su Nombre y Apellidos.
Si esta persona no soluciona el problema de forma urgente, se la apartará con toda seguridad para que el paracetamol o héroe de turno solucione la papeleta sin tener tiempo de explicar o documentar lo que ha hecho para arreglar el problema.
Esto hará que la persona no tenga la oportunidad de aprender de sus errores y simplemente cargue con la culpa sin que nadie aprenda nada valioso en el proceso.

En un contexto así, nadie quiere arriesgarse a cometer un error o liderar un cambio que le pueda “enmarronar” a él o a un compañero.

En algunas empresas tienen muy interiorizada esta forma de trabajar y normalmente acabaremos cansados de escuchar la siguiente frase para rechazar cualquier tipo de cambio:

Es que en esta empresa trabajamos así ™

Cómo salir de esta situación

Esta es sin duda la peor situación de partida. El esfuerzo de cambiar una cultura de este tipo puede llegar a ser titánico y probablemente no dependa únicamente de nosotros solos.
Aquí hay un requisito importante: la dirección de la empresa debe estar alineada con el cambio y asumir ciertas inversiones que hacen falta para poder cambiar las cosas.

Los siguientes puntos son temas por los que empezar a trabajar. No pretendo que esto sirva de lección ya que cada contexto es un mundo muy particular.
Este estado es el peor en el que puedes trabajar como manager y cualquiera que haya pasado por este tipo de cambio debería contar con nuestro más profundo respeto.

Introducir control y métricas
Si existe un contexto en el que tenga sentido la micro-gestión, es este. La introducción de decisiones y control del estado/progreso es fundamental pero tenemos que tener claro que esto es una medida a corto plazo mientras introducimos procesos que nos vayan permitiendo delegar ese control.

En estas situaciones suele ser increible la cantidad de cosas que no funcionan bien sólo porque nadie se atreve a tomar una decisión, por muy obvio que sea el camino.

Además de control, es clave introducir métricas. Si no tenemos métricas no sabremos realmente si los cambios que hacemos tienen un impacto positivo o negativo y guiaremos nuestras decisiones mediante meras sensaciones.

Priorizar
Tenemos que renunciar a ejecutar cosas de forma inmediata y sin criterio, a aprender a jugar bien con el tiempo. Si todo es urgente nada lo es.
Debemos empezar a documentar por escrito las prioridades y hacerlas visibles a todo el equipo. Es crítico gestionar la entrada de trabajo para limitar el work in progress de los equipos. Es la mejor medida para poder entregar trabajo con cierto orden.

Esto no depende de metodología, tanto waterfall como Kanban pueden funcionar si hay orden.

Conseguir tiempo para los equipos
En estos contextos, lo más importante que creo que debemos hacer es conseguir tiempo.
Debemos detectar qué es lo que más roba tiempo a los equipos y reducirlo en la medida de lo posible. Seguramente nos demos cuenta de que lo que más roba tiempo a los equipos son las reuniones innecesarias y las consultas por cosas que no están documentadas.

Al introducir micro-gestión, los project manager necesitarán en todo momento conocer el estado de las tareas y de los proyectos. Podemos ganar tiempo si utilizamos correctamente nuestro gestor de tareas con un board de Kanban, en el que se puede ver y medir el trabajo en progreso.
Por lo tanto, si hacemos daily meetings, estas pueden reducirse considerablemente si en lugar de comentar en lo que estamos trabajando, comentamos qué bloqueos tenemos (si hay alguno) y qué vamos a hacer en los próximos días, para que el resto de los integrantes de un equipo puedan detectar necesidades o cosas que les impacten.
Incluso podríamos ahorrarnos esta daily, si cada miembro del equipo sube su resumen a un gestor de documentación. Los interesados podrán recibir una notificación cuando se añada ese resumen escrito.
De esta forma nos ahorramos una reunión y ganamos en visibilidad que puede consultarse en asíncrono no sólo por los integrantes de un equipo, sino por otras personas de la empresa.

Al igual que en este ejemplo, podemos poner normas estrictas del tipo “si no hay agenda en una reunión, con todos los topics que se van a hablar y un pequeño resumen de los mismos” de antemano, la reunión se cancela.

Si conseguimos reducir una daily que se suele ir a 30 minutos a tan sólo 12 minutos, hemos ganado una hora y media a la semana para cada uno de los involucrados en esa reunión.
Este tiempo lo pueden dedicar a aprender, dar charlas sobre tecnologías que se usen en la empresa, a que un compañero les explique cómo configura un entorno de desarrollo que a la vez puede hacerle ganar tiempo, a automatizar cosas que se hacen de forma manual, etc.
Cuanto más tiempo ganemos y lo invirtamos en que los equipos se formen y automaticen procesos, más tiempo se ganará a medio y largo plazo.

Debemos velar por que ese tiempo se dedique a aprendizaje y no a asumir más tareas de clientes o relacionadas con milestones de proyectos. Esto es de vital importancia. Por ello, esta estrategia debe ir acompañada de una buena priorización, mencionada en el punto anterior.

Evitar los silos de conocimiento
En este escenario, los silos de conocimiento son muy habituales y nos impactan mucho. Cuando personas que han adquirido el conocimiento a través de trabajar en ciertos proyectos o resolviendo problemas relacionados con deuda técnica sin documentar se van de la empresa, tenemos un problema.

En este contexto, lo ideal es detectar quiénes son los que tienen el conocimiento y establecer dinámicas para que distribuyan su conocimiento al resto de equipos.
Una técnica importante y que podemos establecer de forma inmediata es introducir Pair-Programming en los proyectos.

Otra cosa que deberíamos hacer es introducir documentación activa, es decir, documentación que se mantenga actualizada de forma automática. Escribí sobre documentación activa en este artículo.
En este estado crear mucha documentación de forma manual sin disponer de tiempo para mantenerla actualizada, además de ser muy costoso, es sin duda contraproducente.

Elegir las batallas
Si tienes el rol de actor de cambio en un contexto similar a este, debes armarte de paciencia y elegir las batallas una a una, asumiendo que cada paso va a ser como caminar en un río con una corriente colosal que va a estar continuamente desafiando tus decisiones.

Aprendizaje

En esta etapa los equipos empiezan a disponer de buenos mecanismos de organización y priorización del trabajo. Se ha conseguido tiempo para que los equipos puedan aprender y compartir de conocimiento.

Se puede decir que se está en un estado en el que los equipos dejan de preocuparse por sobrevivir; están centrados en mejorar y crecer de forma eficiente.

Es importante tener en cuenta que es muy difícil llegar a este estado pero es muy fácil volver a un estado de supervivencia.
Junto a la contratación de los perfiles correctos y alineados con este estado de madurez, los siguientes puntos son críticos para fortalecer los pilares que se han construido.

Empezar a delegar la organización en el equipo y soltar control

Poco a poco los manager empiezan a delegar la toma de ciertas decisiones en el equipo. Si se viene de un estado de supervivencia, los miembros de los equipos estarán esperando que les digas exactamente qué deben hacer, cómo y en qué orden.

Aunque probablemente siga siendo necesario un rol que priorice el trabajo, los equipos empiezan a tomar la responsabilidad de organizarse. Dependiendo de los perfiles con los que cuentan los equipos, este cambio no va a ser de la noche a la mañana y es responsabilidad del manager guiar y hacer un seguimiento pero sin estar tan encima con en una cultura de supervivencia.

El objetivo es reducir la dependencia para que los equipos vayan auto-organizándose por sí mismos.

Cultura blameless y error-friendly

En este punto los equipos empiezan a asumir riesgos controlados y no se centran en echar la culpa al responsable cuando dicha persona ha cometido un error.

Cuando nos centramos en culpar, simplificamos en exceso y esto nos impide ver el origen real de un problema o un error lo que terminará por hacer que, con toda seguridad, se vuelva a repetir.

Es un momento de probar cosas nuevas y se cometerán errores. Cuando estos se producen, se afrontan, se aprende de ellos y se introducen nuevos mecanismos o mejoras en los existentes para evitar que se produzcan de nuevo.

Técnicas como postmortems, retrospectivas y otras formas de analizar el origen real de los errores, son fundamentales y no serán del todo efectivos si no son blameless.

Lenguaje de commitment

Los equipos y no sólo los manager hablan con un lenguaje de compromiso, es decir, en lugar de comunicar un mensaje como “necesitaríamos hacer esto antes del año que viene” el mensaje suena más a un plan “nuestro objetivo es tener esto para principios de Diciembre”.

Pero no se llega al otro extremo tampoco. Por ejemplo, en lugar de decir que algo se subirá a producción el 6 de Diciembre a las 12:00, se dirá que se subirá a principios de Diciembre.

En lugar de deadlines se habla de milestones y de retos.

Siempre hay excepciones en las que se requiera un nivel alto de precisión, pero deberíamos cuestionarnos si la necesidad de esta no está fundada por otro tipo de problemas más profundos a nivel de comunicación y de organización.

El objetivo es que el equipo piense en adquirir compromisos por ellos mismos, sin miedo a errar en la precisión ni en comunicar una fecha que puede no gustar a stakeholders que no tengan en cuenta la dificultad o recursos a la hora de haber creado una estimación o expectativa errónea.

Los equipos disponen de capacidad para solucionar sus problemas

En este estado los manager facilitan las herramientas para que los equipos empiecen a encontrar soluciones a los problemas por sí mismos.

Esta fase es un reto para aquellos manager que han estado en modo supervivencia muchos años y al igual que otros miembros del equipos, seguramente requieran de cierto mentoring para adaptarse.

Idealmente, cuando los equipos aprender a auto-organizarse, es interesante dar la capacidad de establecer retos en los 1:1 que puedan cumplirse en un tiempo dedicado a ello, fuera de los objetivos del día a día, para que las personas refuercen esas capacidades en un espacio seguro en el que el fallo no impacte en otros.

Este tipo de iniciativas son importantes para llegar al estado óptimo en una cultura, que es una auto-organización real de los equipos.

Auto-organización

En este estado los equipos son capaces de auto-organizarse, no tienen problemas para adquirir compromisos ni para ponerse retos, detectan los problemas que existen en su día a día y toman decisiones en equipo, sin requerir instrucciones externas ni una monitorización de estado continua por parte de una persona externa.

Los miembros del equipo diseñan sus propias métricas y el compromiso es tanto exigido como compartido por todos ellos.

El estado de los proyectos es visible de forma centralizada y todo el mundo tiene el contexto y sabe lo que está haciendo el otro.

También se conoce lo que va a llegar con suficiente antelación para haber madurado soluciones y detectado problemas antes de empezar.

El trabajo de los managers se centra en aportar herramientas para que los equipos cada vez sean más independientes, haya procesos claros en los que el trabajo se reparta óptimamente, las personas crezcan en la empresa y dispongan de todo lo necesario para entregar trabajo de la forma más eficiente y saludable.

Sigue habiendo retos y problemas a solucionar —nunca se llega a la perfección— pero la mejora continua es el pilar central en este estado.

Conclusión

En este artículo hemos visto tres niveles de madurez en los que puede encontrarse una cultura. Como hemos comentado al principio, hay muchos grises y una misma empresa puede llegar a tener equipos o areas en diferentes estados de madurez.

Lo interesante es saber reconocerlos y poner los medios para ir creciendo todos juntos como equipo en cada contexto.

Culturas de ingeniería: por dónde empezar

Sun, 03 Nov 2019 22:07:01 +0000

Esta es la segunda entrada de una serie de artículos sobre culturas de ingeniería.

1. De qué hablamos cuando hablamos de cultura
2. Por dónde empezar
3. Madurez de nuestra cultura
4. Cultura de feedback
5. Comunicación y documentación

Valores

“When your values are clear to you, making decisions becomes easier.”
— Roy E. Disney

He de reconocer que a lo largo de mi carrera, he sido bastante escéptico con la utilidad los valores y visión de la empresa.
Me dejé llevar por los prejuicios alimentados por experiencias en determinados contextos, en los que los valores quedaban estáticos en una pared a modo de buenas intenciones o deseos, muy alejados de la realidad del día a día de los equipos.

Con el tiempo, aprendiendo en otros contextos de trabajo distintos e intercambiando experiencias con otros colegas de profesión, me he convencido de que los valores son una herramienta clave para afianzar una buena cultura.

Los valores deben estar documentados y deben ser actualizados cada cierto tiempo en base a la realidad de los equipos. Con valores alineados con esa realidad, podemos empezar a construir procesos, políticas y otras herramientas que hacen más fácil mantener nuestra cultura.

Si no se ha hecho antes, documentar los valores comunes interiorizados por todos los equipos es una práctica muy sana para descubrir aquello que todos esperan del resto y hace que no sea tan importante que estén escritos en una pared para que todo el mundo los siga y demande seguirlos en cada decisión o proceso.

Con los valores ya definidos, podemos empezar a construir nuestra cultura desde el principio: la contratación de las personas adecuadas.

Contratar

“Shaping your culture is more than half done when you hire your team.”
— Jessica Herrin, Stella & Dot founder

La base de todas cultura de empresa empieza por contratar a las personas correctas.

El cultural fit es un factor crítico para determinar si es buena idea que la empresa y el candidato empiecen juntos una relación profesional.

Es importante conocer qué expectativas tiene el candidato, a qué tipo de culturas está acostumbrado y si aceptaría un posible cambio. Evaluar el choque cultural en el caso de que un candidato proceda de otras culturas es algo clave cuando estás contratando.
Hace unas semanas escribí sobre qué preguntas me gustaría que me hiciese un candidato, precisamente por este motivo.

En nuestro sector, los buenos profesionales pueden elegir dónde quieren trabajar entre muchas opciones. El salario es un factor, pero no es el único.
Podemos encontrar fácilmente análisis que nos muestran cómo una buena cultura es decisiva tanto para conseguir captar talento como para retenerlo. Teniendo en cuenta esto, necesitamos cuidar algunas cosas de nuestro proceso.

Es importante que en las ofertas que publiquemos, se perciban nuestra cultura y valores, además de las expectativas que tenemos al buscar a esa persona para nuestro equipo.

La UX del proceso de selección

“We thought about our culture truly as a product”
— Katie Burke, chief people officer at HubSpot.

Algunas empresas tratan su cultura como un producto en sí mismo, podemos ver ejemplos en Hubspot y en Asana. Si seguimos el ejemplo, el proceso de contratación debe ser medible, iterable, guiado por feedback y con una UX cuidada al máximo.
Hay que tener en cuenta que en nuestro un mercado, el coste de oportunidad a la hora de contratar talento es tremendamente alto.

Idealmente, la persona que pase por nuestro proceso de selección debería percibir cómo sería el día a día en base a las pruebas y preguntas que le hagamos y percibir en todo momento si tiene un cultural fit adecuado y los skills que estamos buscando.

Las entrevistas son una oportunidad para aprender mucho de uno mismo, el mejor feedback que un candidato puede darnos es que su tiempo ha sido productivo y ha aprendido durante el camino.

El proceso de selección como publicidad de la cultura de tu empresa

Todo contacto con un candidato es una oportunidad para dar a conocer nuestra cultura. Por ello, en los procesos de selección hay que tener especial cuidado de la imagen que estamos dando.

Ten por seguro que si a una persona le ha gustado tu proceso va a contarlo a su gente de confianza y esa gente puede que forme parte del talento que estás buscando. Si la impresión es negativa, la voz se va a correr como la pólvora.

Cuidar el feedback

Si un candidato pide feedback, en mi opinión debemos dárselo lo mejor que podamos. Esta persona ha invertido su tiempo y si recordamos el punto anterior, ganamos más dándoselo que omitiéndolo.

Como candidato, si te dan feedback, recíbelo con generosidad. No hay nada peor para un entrevistador que confirmar su decisión de no seleccionar a una persona, cuando esta le demuestra que no encaja bien la crítica.

Evitar héroes x10

La época de los rock star del software ya ha pasado, o al menos en culturas de empresas que quieran ser escalables y no tener un ambiente tóxico.
Se ha escrito mucho sobre perfiles que trabajan mejor solos y que son capaces de arreglar lo que el resto de los equipos no pueden y subir código a producción mucho más rápido que el resto.
La realidad es que estos perfiles generan silos de conocimiento, dependencia y son los únicos que se atreven a lidiar con la deuda técnica que a menudo ellos mismos generan.

Si pensamos a largo plazo y sobretodo en una cultura de trabajo en equipo, los soft skills, en especial la comunicación, aceptación de la crítica, capacidad de aprendizaje, son más valiosos en las personas que se incorporen. Si nos fijamos en estas cosas, llegaremos más lejos que con perfiles 10x.

El On-Boarding

Tras cerrar el proceso de contratación, comienza el proceso de onboarding.

El onboarding es una pieza clave de la cultura de una empresa ya que es el momento en el que la persona que entre va a evaluar si ha tomado una buena decisión o no a la hora de decantarse por nuestra empresa y también es un momento en el que debe aprenderlo todo sobre nuestra forma de trabajar.

Al formar parte de la cultura, debe estar documentado por varios motivos:

No recaiga siempre en la misma persona y cualquier persona del equip,o independientemente de su rol, pueda saber gestionarlo y mejorarlo
Todos los procesos de onboarding se hagan de la misma forma
Que el primer día la persona tenga todo listo para empezar a trabajar
Se puedan anticipar necesidades y la reserva de huecos en el calendario de los involucrados
Dar mayor seguridad a la persona que se incorpora

En un buen onboarding toda persona que entre debería tener todo lo necesario para poder hacer su trabajo el primer día, conocer los valores de la empresa, saber qué se espera de ella en su primer mes y tener espacio de tiempo para conocer los procesos de la empresa, otros departamentos y aprender las dinámicas del día a día.

Cómo documentar nuestro On Boarding

Independientemente de qué herramienta utilicemos para documentarlo, el onboarding debe tener en cuenta lo que se necesita hacer antes de que la persona entre y lo que esta va a hacer desde el primer día hasta que el on-boarding haya finalizado. Idealmente, cualquiera del equipo debería poder acceder y actualizar esa documentación, de tal forma que cualquiera del equipo, podría asumir el preparar el on-boarding y tener claro todo lo que se necesita dejar listo antes del día en el que esa persona se incorpore.

El primer día en una empresa nueva siempre es un día especial pero también es un día en el que estás muy perdido con todo, tienes la sensación de no ser capaz de recordar ninguno de los nombres de tus compañeros y en muchos casos, el síndrome del impostor te puede hacer pasar una mala jugada. Cuanto mejor cuidemos la parte del onboarding de una persona, mejor será su experiencia y antes se integrará en el día a día.

Por otro lado, debemos pensar que durante sus primeros días, la persona va a saber si su elección ha sido buena o mala. En este sentido, no hay nada peor para una persona nueva que estar esperando días a tener su equipo de trabajo, que la metan en un proyecto directamente sin tener contexto ni interiorizados los procesos de trabajo, que no le presenten a nadie de otros departamentos ni le expliquen lo que estos hacen, que nadie le diga qué esperan de ella o de su rol en la empresa…

Lo ideal es que la persona tenga un sitio en el que poder consultar sus primeros pasos a modo checklist, un listado de los recursos más importantes a consultar en cuanto a nuestra cultura y vaya conociendo el funcionamiento no sólo de su departamento, sino el del resto de la empresa. Todo ello debe suceder en un espacio de tiempo seguro en el que el resto de equipos de la organización sepan que esa persona está en su tiempo de onboarding y no esperen que sea productivo hasta que este tiempo finalice.

Buddies

El buddy es un rol ya conocido en diferentes culturas que cuidan de su onboarding y tiene como objetivo acompañar a las personas que llegan en sus primeros días o en lo que dure el onboarding.

El objetivo de los buddies es el de dar contexto y ayudar en todo lo que la nueva persona necesite, pero hay que tener en cuenta su carga de trabajo antes de asignarles este rol. Si no se tiene en cuenta esto, habra un impacto directo en el equipo en el que el buddy forme parte y la experiencia del onboarding para la persona que entre no será la misma.

El Off-Boarding

Tarde o temprano, llega el momento en el que alguien del equipo decide dejar la empresa y buscar nuevos retos. Al igual que hemos hecho con el onboarding, debemos cuidar cómo decir adiós a ese profesional que ha aportado a la empresa y gestionar todo lo relativo a su baja digital en la misma.

En el offboarding, es importante cuidar todo lo que consideremos importante en los últimos días de esa persona: recoger feedback, asegurar el traspaso de conocimiento, informar a clientes y proveedores, organizar una despedida en condiciones… todo depende de cómo nos gustaría que esa persona recuerde el cierre de su etapa trabajando con nosotros.

Por último, una vez que esa persona se haya ido, es importante dar de baja los accesos pertinentes y gestionar los recursos a los que dicha persona tiene acceso.

Al igual que hemos documentado el onboarding, es necesario documentar también este proceso para que cualquiera en la empresa sepa cómo gestionarlo y siempre se haga de la misma forma, sin que nos dejemos ningún paso importante.

Conclusión

El primer paso a la hora de construir una cultura pasa por conocer cuáles son los valores de todo el equipo y contratar a las personas adecuadas.

Para ello, debemos comunicar muy bien qué buscamos en esas personas y destacar aspectos importantes de nuestra cultura.

Una vez que alguien ha tomado la decisión de unirse, debemos cuidar la experiencia de sus primeros días para que se pueda adaptar y sepa qué es lo que esperamos de ella.

Por último, no debemos descuidar cómo es la experiencia cuando una persona decide irse de la empresa.

Referencias y recursos relacionados

Lo que he comentado en este artículo está inspirado en mi experiencia de los últimos años y en especial en lo que aplicamos en Packlink (estamos contratando por cierto).
Existen muchos más recursos que hablan sobre este tema, aquí he recopilado unos cuantos. Iré actualizando esta lista a medida que vaya encontrando más:

Culturas de ingeniería: de qué hablamos cuando hablamos de cultura

Tue, 22 Oct 2019 22:07:01 +0000

Esta es la primera entrada de una serie de artículos sobre culturas de ingeniería.

1. De qué hablamos cuando hablamos de cultura
2. Por dónde empezar
3. Madurez de nuestra cultura
4. Cultura de feedback
5. Comunicación y documentación

En Julio de 2018, Linkedin publicó este artículo en su blog en el que se mostraban datos interesantes que exponían cómo una buena cultura ayuda a un candidato a decidirse por entrar en una empresa, sobre otros factores como la cantidad económica o un cargo/título que supuestamente le posicione mejor en el mercado.
Por si esto no fuese suficiente, también se mostraban qué factores de una buena cultura impactaban directamente en la retención del talento.

En varias ocasiones, he visto debatir sobre el término cultura como algo que sólo pueden alcanzar ciertas empresas, refiriéndose exclusivamente a lo que idealmente sería una buena cultura de empresa, siempre bajo el criterio subjetivo de los interlocutores.
Sin embargo, todas las empresas tienen su propia cultura. Quizás podamos considerar que en una empresa no se tenga una “buena” cultura o una cultura “madura” o podamos definirla como una cultura “tóxica” pero indudablemente, se tiene una sobre la cual se puede trabajar.

Hay multitud de frases que pueden definir a qué llamamos cultura, pero mi favorita es sin esta de Courtney Chapman, actual Administrative Business Partner de Google:

“Company Culture is the product of a company’s values, expectations and environment.”

En 2006, Mark Fields -presidente de Ford por entonces- atribuyó la frase “culture eats strategy for breakfast” a Peter Drucker.
Aunque no está probado que fuese realmente de Drucker, esta frase ha ganado mucho protagonismo en los últimos años y viene a decir que además de una buena estrategia, es importante crear culturas en las que los equipos tomen la responsabilidad por ellos mismos de alcanzar los objetivos de negocio ya que son los que más cercanos están a la realidad del día a día.

Algunos términos y buzzwords

En la actualidad, existen una serie de buzzwords que a menudo se asocian con una buena cultura, o al menos, con una cultura alineada con las preocupaciones y formas de trabajar que buscan actualmente los ingenieros de software y de sistemas.

Agile

“Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.”
Manifesto for Agile Software Development

Agile es algo que está en la mente de todos en nuestro sector desde hace años. Aunque normalmente el término se asocia a metodologías concretas, ser una empresa agile es una cultura en sí mismo.
Esta frase implica muchas cosas pero lo principal es llegar a diseñar mecánicas que nos permitan mejorar de forma continua.

Aunque normalmente se da el protagonismo a las metodologías agile y a sus dinámicas, estas no son más que propuestas de formas de trabajo. Ninguna metodología agile va a ser eficaz si nuestra cultura no está alineada con los principios del Manifiesto Agile.

Cultura agile de Spotify

Spotify publicó una serie de videos sobre su cultura en el 2014 que se hicieron virales en la comunidad de desarrollo.
Estos vídeos consiguieron que términos que se utilizaban internamente en la compañía, se adoptasen en los departamentos de ingeniería de otras empresas como términos casi de facto a la hora de organizar equipos.

Squads
Los squads son equipos independientes, autosuficientes y auto-organizados que son capaces de entregar valor a producción por ellos mismos.
Cada squad decide cómo trabaja y qué metodología aplica.

Chapters
Los chapters son áreas de especialidad: frontend, backend, QA, infraestructura…

Tribes
Las tribus son agrupaciones de squads por contexto de negocio. Dentro de una tribu, los miembros del equipo pueden cambiar de squad sin necesidad de cambiar de manager.

Guilds/Gremios
Los gremios son grupos abiertos de estudio e investigación, cross squads y cross tribus. De esta forma, independientemente de en qué squad estén, las personas en la empresa disponen del tiempo y de la posibilidad de investigar sobre temas que les interesen y que estén alineados con los objetivos de la empresa. Esto fomenta la innovación, el trabajar con otras personas fuera de tu equipo y la posibilidad de aprender aportando valor.

Lo importante del ejemplo de Spotify no son estos términos y forma de distribuir los equipos, sino la iniciativa que tomaron para ir más allá de metodologías a la hora de forjar su cultura.

Holocracia

La holocracia u holacracia, se hizo famosa gracias a empresas como Netflix, Medium o Zappos. Basándose en conceptos de sociocracia, se busca que los equipos sean auto-organizados en lugar de buscar un modelo jerárquico tradicional.

A menudo se confunde la holocracia con un modelo “ausente de jefes”, sin embargo, los líderes si que existen pero sus equipos no son tan dependientes de ellos como lo serían en una estructura jerárquica clásica.

En la holocracia se busca que las personas asuman roles en lugar de tener “cargos” o “títulos” concretos.
Cada persona puede asumir diferentes roles dependiendo del contexto o de los objetivos de la empresa en cada momento. Para poder hacerlo, los roles deben estar muy bien definidos y se deben conocer muy bien las aptitudes de cada persona en el equipo.

Podemos encontrar un ejemplo de holocracia en Zappos, que incluso ha creado una plataforma dedicada a ofrecer servicios de formación a otras empresas que deseen llegar con con éxito a una cultura de Holocracia.

Culturas de trabajo en remoto

Una cultura preparada para ofrecer full remote ofrece muchas ventajas y flexibilidad tanto a la empresa como a sus trabajadores. También elimina barreras -que son cada vez más altas- a la hora de contratar y retener talento.

Llegar a una cultura en remoto no es fácil ya que supone muchos retos a la hora de gestionar equipos distribuídos, especialmente si estos se encuentran en zonas horarias distintas, además de tener muy interiorizados procesos de entrega continua, documentación y comunicación.

Sin embargo, llegar a una cultura de este tipo, mejorará nuestros procesos, facilitará el crecimiento de nuestro equipo de ingeniería y dotará de madurez en muchos aspectos a los procesos de negocio.

Pablo Carranza, Head of Engineering en Cabify, explica muy bien qué conlleva gestionar una cultura full remote.

Es interesante también echar un vistazo al canal de YouTube de Gitlab, donde los equipos hacen públicas sus reuniones y hasta disponen de un mini curso para Managers.

DevOps

DevOps es otro término que encontramos en culturas de trabajo actuales y también trae consigo un montón de retos a la hora de aplicarlo.

En una cultura alineada con el concepto DevOps, los equipos de desarrollo y de sistemas comparten una actitud de responsabilidad común hacia el mantenimiento de la plataforma y del software que corre en ella, facilitando la colaboración entre las personas con roles en esos diferentes áreas.

En estas culturas:

Las personas en operaciones son involucradas lo antes posible en el proyecto de desarrollo.
Ambas partes, desarollo y sistemas, son conscientes de las necesidades mutuas para alcanzar los objetivos de negocio.
Se eliminan barreras a la hora de entregar el código a producción o aportar mejoras tanto en procesos como en la plataforma.
Como consecuencia, algunos aspectos como la observabilidad y monitorización de la plataforma mejoran notablemente.

Conclusión

Toda empresa tiene una cultura, que es el resultado de los valores, formas de trabajo y visión que los equipos han interiorizado durante los años.

En la actualidad, existen varios movimientos y conceptos que bien aplicados, pueden hacen mejorar la cultura de nuestra empresa y hacer de la misma, el mejor lugar posible para trabajar.

Qué preguntar en tu próxima entrevista de trabajo

Wed, 16 Oct 2019 19:47:01 +0000

Las entrevistas de trabajo son bidireccionales, es decir, los entrevistadores están a ambos lados de la mesa. Esto es especialmente cierto en el sector tecnológico.

Una de las partes más importantes de una entrevista es el turno de preguntas del entrevistado.

Para el candidato, es una oportunidad única para obtener información sobre el día a día que va a disfrutar –o sufrir– en su futuro puesto de trabajo.
Para los entrevistadores, se trata de una oportunidad para conocer mejor las inquietudes e intereses del candidato. Es muy raro que un candidato no haga preguntas, sobretodo en perfiles senior.

Siempre que he hecho entrevistas, independientemente del lado de la mesa en el que me encuentre, me vienen a la mente de forma recurrente una serie de preguntas que me gustaría hacer o que me hicieran.

Las siguientes, son una selección de las mismas.

¿Qué pasa si cometo un error?

Todos cometemos errores y probablemente, acaben en producción.

Es importante asegurarse de que la empresa cuente con mecanismos que eviten que un gran número de los mismos puedan llegar a producción y en el caso de que lo hagan, los sistemas y plataforma puedan recuperarse sin mayor problema.

Por otro lado, es importante detectar si en la empresa a la que aplicas, los errores son castigados sin ningún tipo de piedad.
En una cultura donde no se pueda fallar de forma segura, las personas se lo van a pensar dos veces antes de proponer iniciativas o soluciones que no les hayan pedido y el crecimiento e innovación están condenados al fracaso.

¿Qué se espera de mí y de mi rol si entro en el equipo?

Aunque los roles suelen seguir unas pautas generales a la hora de definirse, hay matices importantes que pueden variar su significado entre diferentes culturas de empresa.
Es importante saber si lo que nosotros entendemos que vamos a hacer coincide con lo que la empresa espera que hagas.

¿Cómo podría ser mi progresión en la empresa?

Es importante conocer qué opciones vas a tener cara a crecer en la empresa y con qué medios vas a poder contar para conseguir llegar a tus objetivos.

Esta pregunta debería darte información muy valiosa sobre cómo vas a poder recibir feedback para conocer si vas por el buen camino a la hora de crecer en la empresa.

¿Cómo es el proceso desde que se crea una tarea hasta que esta se encuentra disponible en producción?

Es muy importante conocer cómo de pulidos están los mecanismos que nos van a permitir trabajar en equipo, con la calidad y normalización que el equipo espera y también, poder entregar el trabajo que hacemos a los usuarios finales de nuestro software.

Plantear cuestiones del tipo “¿cómo se gestionan los rollbacks y se hace seguimiento de los mismos?”, “¿cómo se analiza el impacto de lo que se entrega?”, entre otras, demuestra madurez y preocupación por los procesos de trabajo.

¿Cuál es vuestro proceso de definición de las tareas?

La definición de las tareas es de las cosas más peleadas por equipos de software de todo el mundo.

Una empresa que cuente con una buena definición de tareas, tiene mucho ganado y puede ser un lugar muy interesante en el que trabajar.

¿Cuál es vuestro stack tecnológico?

Al margen de lo que ponga en la oferta de trabajo, preguntar por el stack tecnológico nunca está de más.

Como entrevistado, siempre he agradecido que me hablasen no sólo de lo más interesante del stack, sino también de la parte legacy que todas las empresas que tengan un mínimo recorrido, deben gestionar.

¿Cómo se afronta la documentación en la empresa?

La documentación es importante a muchos niveles en una empresa pero en concreto en una empresa de software, es clave.

Sin documentación, los silos de conocimiento se fortalecen, la definición de las tareas se hace más complicada de conseguir y la barrera de entrada a los productos en desarrollo se puede convertir en un handicap muy complicado de gestionar.

En culturas de trabajo en remoto o empresas en las que hay equipos ubicados en diferentes zonas geográficas, la documentación es uno de los factores clave para poder trabajar y comunicar de forma asíncrona.

Además de generar documentación, es importante que esté bien estructurada y haya mecanismos que permitan encontrarla y mantenerla viva.

Conocer cómo de madura es la empresa en este sentido puede ser muy valioso en una entrevista.

¿Existen iniciativas de formación en la empresa?

Toda cultura de ingeniería debería dar importancia a la formación de sus equipos y es significativo si esta se facilita en horario de trabajo.

¿Hay posibilidad de trabajar en remoto?

Esta es una de las preguntas que más se hacen actualmente.

El trabajo en remoto es un símbolo de confianza y madurez de los procesos de trabajo y comunicación en la empresa.
Además, una buena cultura de remoto proporciona una mejor calidad de vida gracias a la flexibilidad que aporta por lo que se ha convertido en la primera e incluso única opción para muchos candidatos.

Tanto si estás interesado como si no en trabajar en remoto, esta pregunta es importante para conocer la opinión de la empresa en este sentido, cómo de maduros puedan llegar estar sus procesos y qué pasos se han dado para avanzar en este sentido.

Perks

Si la empresa ofrece perks es de recibo preguntar por ellos y cómo se puede disfrutar de los mismos.

Encontrar reticencia a la hora de explicarlos puede ser un bad smell y que esa empresa no pueda ser todo lo buena opción que pueda parecer a priori.

¿Cómo es el ambiente de trabajo?

Al final, en el trabajo es donde más tiempo vamos a invertir en el día a día.
El ambiente de trabajo es clave para una buena cultura de empresa y facilita enormemente que el trabajo salga adelante.

Conclusión

Como candidato, hacer preguntas en una entrevista es importante, te permite conocer mucho más en detalle aspectos importantes de tu futuro trabajo más allá de lo que hayas podido investigar por tu cuenta.
Como entrevistador, es muy interesante recibir preguntas cara a conocer mejor los intereses y preocupaciones de la persona que va a entrar en tu equipo.

Al final, una entrevista es en ambas direcciones y cuanto más conozca una parte de la otra, más seguro va a ser el éxito de la contratación para ambas partes.

Documentación activa

Sun, 14 Apr 2019 19:34:01 +0000

Durante los últimos años he tenido varias experiencias tratando de implantar una cultura de documentación en distintas empresas y equipos con los que he trabajado.

Este artículo es un resumen de las charlas que he impartido en los últimos dos años basadas en dichas experiencias con el fin de explicar qué es la documentación activa y por qué puede ser clave para implantar una cultura de documentación de forma efectiva en una empresa o un equipo de desarrollo de software.

Nuestro concepto clásico de documentación

Una de las razones principales por las que documentar es una tarea que se percibe como “cara” en tiempo y esfuerzo radica en nuestro concepto de generación de la misma. Esto se une a malas experiencias que hayamos podido sufrir al crearla o consumirla.

Cuando pensamos en documentación, asociamos en nuestra mente la necesidad de recibir o crear un documento. Este documento será un “entregable” en formato docx, pdf o similar.

Si dicho documento está escrito con mimo, es decir sin una prisa evidente por terminarlo tras haberlo dejado para la fase final del proyecto, nos quedará asegurarnos de que dicho documento se mantenga actualizado en el tiempo. Con este fin, se suele incluir una tabla al principio del mismo, para registrar los cambios que se vayan produciendo en el.

Una vez entregado y concluido el proyecto (al menos en principio) en nuestra mente únicamente quedará la esperanza disfrazada de expectativa de que dicho documento se mantenga actualizado cada vez que se realice un cambio o actualización en nuestro producto. Pero esto rara vez ocurre y lo sabemos.

Tenemos varios problemas con esta forma de trabajar:

La documentación está en un formato final que puede ser copiado, alterado y editado en una de sus copias. Esto nos provoca inseguridad al no saber con certeza que disponemos de la versión más actualizada del documento.
El formato a veces nos obliga a consumir información crítica con una herramienta de software concreta. Y también a duplicar la información si debemos entregar la documentación a diferentes destinatarios en diferentes formatos, haciendo más compleja la gestión y control de las versiones.
La documentación está ligada a un entregable. Si la persona que gestiona el proyecto no tiene suficiente experiencia o la cultura tecnológica de la empresa no da pie a incluir requisitos de documentación en el definition of done de una tarea, es posible que en el mejor de los casos, este trabajo quede en la fase final en el Gantt (o en un falso “agile sprint”) del proyecto. Esta fase de “documentación y pruebas” suele coincidir con retrasos en funcionalidad comprometida en fechas haciendo que sea el peor momento para redactar algo con un mínimo de cariño.
Otra posibilidad es que nuestra documentación sea el resultado de un análisis realizado en una fase previa al inicio del proyecto. Este documento puede darnos cierto contexto del origen pero nunca nos podrá dar ningún tipo de fiabilidad de que nos sirva para algo tras finalizar el desarrollo por la propia naturaleza del desarrollo del software. Nunca vamos a estar a salvo de cambios, redefiniciones y descubrimientos continuos.
Esta documentación estará alejada del código de nuestro proyecto, por lo que con el tiempo, el punto único de verdad será el código que tenemos en producción. Perderemos contexto del por qué de la implementación realizada y del impacto real en el negocio y otros componentes de la arquitectura o productos de software con los que nuestro desarrollo se comunique o integre.

Es muy fácil que nuestra documentación se enfríe

Pongamos un ejemplo típico en el que nos llega una especificación en formato docx para construir un servicio que va a estar disponible mediante una API REST.

A partir de dicho documento, creamos la especificación en Open Api y mediante la misma, comenzamos a desarrollar el servicio.

Nuestros compañeros de front utilizan esa especificación para generar mocks automáticamente y no tener que esperar a que terminemos el servicio para poder empezar a construir su aplicación web progresiva.

Resulta que nos damos cuenta de que no se había contemplado una necesidad en el comportamiento de nuestra API.

Aplicamos el cambio en el código y en la especificación para que nuestros compañeros de front puedan volver a generar sus mocks y puedan trabajar teniendo en cuenta este cambio.

Al hacer esto, nuestra especificación inicial se vuelve automáticamente obsoleta.

En este momento, nuestro punto único de información reside en la especificación del Open API y no en el documento. Sin embargo, el Open API recoge cierta información, pero no toda, perdiendo información sobre el comportamiento y requisitos de negocio.
La situación se vuelve mucho peor si ni siquiera contásemos con la especificación del Open API.

Cuando pasen los años y otro equipo de desarrollo que no disponga de toda la información que se ha ido omitiendo durante ese tiempo asuma el desarrollo del mismo, no les quedará más remedio que volverse arqueólos del software.

Arqueología de software

Software archaeology or software archeology is the study of poorly documented or undocumented legacy software implementations, as part of software maintenance.
Software archaeology, named by analogy with archaeology, includes the reverse engineering of software modules, and the application of a variety of tools and processes for extracting and understanding program structure and recovering design information.
— Wikipedia

La anterior cita, además de en la Wikipedia, forma parte de este interesante paper de Gregorio Robles, Jesus M. Gonzalez-Barahona e Israel Herraiz además de hablarse sobre ello en el libro Eating the IT Elephant: Moving from Greenfield Development to Brownfield de Richard Hopkins y Kevin Jenkins

Si llevamos un tiempo en el desarrollo de software, seguramente hayamos heredado más de una vez un proyecto sin documentación o peor aún, con documentación poco fiable. En otras situaciones, debemos migrar un desarrollo existente para poder actualizarlo, mejorar su mantenimiento o quizás poder a llegar a incluir alguna funcionalidad nueva sin que impacte en el resto de funcionalidades o el sistema del que esa pieza forma parte.

La única solución para conocer con seguridad qué hace ese software y cual es su impacto a nivel global, es estudiar sus entrañas y empezar a cubrir con tests de caja negra para ir ganando control y entendimiento compartido del equipo sobre el mismo.

Sobra decir que esto es un proceso caro. Incluso con la idea de crear una estrategia de refactoring o en el caso más extremo, la re-escritura total del proyecto, ese tiempo de análisis puede llegar a ser más caro en tiempo o recursos que la propia ejecución del proyecto. A pesar de todo, esta inversión será necesaria para no encontrarnos con la misma situación en el futuro.

En estas situaciones es donde se ve claro el valor de tener una documentación bien actualizada y eliminar toda “isla de conocimiento”. Pero esto no es fácil e implica cambios de cultura en el trabajo del equipo.

Cómo empezar

En todo momento estoy haciendo referencia en un cambio de cultura. Cambiar una cultura no es nada sencillo.

Un cambio de cultura implica pensar a largo plazo, estar alineados como equipo y tener margen de acción. No todos los entornos son favorables.

Incluso en entornos ágiles de verdad, es complicado añadir una cultura de documentación de entrada y sin preparación. Por esto considero clave el introducir documentación activa en los procesos de Integración continua.

Una vez conseguido esto, podemos ir mejorando e introduciendo más mecanismos, roles y protocolos para mejorar nuestra documentación y la cultura de equipo.

Introduciendo pipelines de documentación activa

La documentación activa nos permite conseguir varias cosas:

Generar documentación automáticamente a partir de especificaciones o contratos que ya tenemos que definir obligatoriamente para que nuestro software funcione o se integre con otros sistemas
Tener un único punto de verdad que se actualice constantemente
No depender de formatos entregables finales
Que nuestra documentación forme parte de nuestro ciclo de integración y entrega continuos

Markdown como formato central

Markdown nos ofrece muchas ventajas para ser utilizado como documentación:

Es independiente de formato, es un lenguaje simple de marcado basado en texto plano
Hay muchísimas utilidades para generar entregables en PDF, Docx, HTML
Hay opciones de CMS maduras que nos permiten generar portales de documentación a partir de archivos Markdown

En varias ocasiones hemos seguido la estrategia de generar portales de documentación con herramientas como VuePress a partir de archivos de markdown que se organizaban dentro de una carpeta /docs que la raíz del proyecto.

Esos archivos podían ser escritos a mano, pero también podían incluir transformaciones de otros formatos como Swagger, JSON Schema e incluso Gherkin a formato Markdown.

Tanto la documentación escrita como la documentación activa pasan por el mismo pipeline que entraría en un ciclo de Integración Continua.

De esta forma conseguimos regenerar de forma automática tanto el portal de documentación como los formatos entregables en cada actualización del código y de documentación que se mergee en la rama master (o de desarrollo, según nuestra estrategia).

Podemos complicar el pipeline tanto como nos apetezca, por ejemplo incluyendo la indexación de toda la documentación en un servicio de búsqueda centralizada para poder encontrar cualquier información de forma más sencilla.

Cada pipeline dependerá de las necesidades concretas de cada equipo.

Como nota curiosa, otros sectores están empezando a crear sus propios pipelines con una idea similar. En el artículo La edición como edición continua de Ramiro Santa Ana Anguiano, podemos ver cómo se puede aplicar esto a la edición tradicional.

¿Qué podemos utilizar como documentación activa?

Seguramente como equipo ya estaremos escribiendo documentación sin ser conscientes de ello.

Para hacer viable nuestro trabajo escribimos tests unitarios y de integración, especificaciones, contratos, recetas de despliegue u orquestación de infraestructura… todo ello puede hacernos comprender en detalle los requisitos, finalidad y objetivos de negocio de los mismos.

Algunas de estas herramientas pueden ser las siguientes:

Open API/Swagger

Open API es una evolución de Swagger para especificar APIs REST, WebHooks y posiblemente Websockets en el futuro.

Esta herramienta nos permite generar documentación en varios formatos e incluso código de clientes para consumir nuestro API y mocks partiendo de una especificación escrita en formato YAML.

Open API es muy maduro gracias a la adopción que ha tenido Swagger en los últimos años y podemos gozar de compatibilidad con diferentes frameworks y tecnologías disponibles.

También contamos con la posibilidad de transformar directamente el archivo YAML a formato Markdown gracias a esta herramienta de Rubens Mariuzzo

AsyncAPI

AsyncAPI es una iniciativa similar a Open API pero que desarrolla una especificación para APIs de mensajería o comunicación asíncrona.

Documentar los payloads de los eventos de nuestro sistema es algo fundamental sobretodo en arquitecturas orientadas a eventos como las que se basan en Microservicios.

JSON Schema

JSON Schema es una herramienta muy útil para especificar y validar documentos JSON que van a ser integrados o almacenamos en un sistema.

Algunos servicios de mensajería y bases de datos documentales soportan JSON Schema para validar lo que se envía a ellos antes de aceptarlos. En servicios que no los soporten suele ser buena práctica validarlos desde el lado del consumidor o productor del mensaje en nuestra aplicación.

Existe una herramienta de Adobe que nos permite convertir archivos JSON Schema complejos a archivos Markdown.

Gherkin

Gherkin es un lenguaje creado para escribir especificaciones que además nos sirvan como tests automáticos de aceptación.
Aunque se creó bajo el paraguas de la herramienta Cucumber del ecosistema Ruby, Gherkin es independiente de tecnología y frameworks, lo cual lo hace muy versátil y aceptado de forma general en la comunidad de desarrollo.

Al ser una herramienta para probar nuestro software, tenemos la oportunidad perfecta para usarlo como documentación que debe estar continuamente actualizada.

Para aprovechar todo su potencial, lo ideal es seguir la metodología Specification by example.
Esta metodología aplicada a Gherkin considero que es la mejor práctica para disponer de documentación de negocio siempre viva.

Uno de los mejores libros que he leído sobre la misma es Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing de Gojko Adzic.

Un ejemplo de feature de Gherkin sería este:

Feature: Free shipping

 We want to offer free shipping in orders sent within our country at this moment.
 The minimun quantity for a free shipping must be 100€

 Scenario Outline: Orders over $100 should be shipped for free

 Given items worth <purchase> in John's cart
 And shipment to <country>
 When John proceeds to checkout
 Then he should be offered <shipping>

 Examples: Restrict free shipping to Spain
 | country | purchase | shipping |
 | ES | 99€ | 5€ shipping |
 | ES | 100€ | free shipping |

 Examples: Other countries don't have free shipping
 | country | purchase | shipping |
 | Canada | 99€ | 5€ shipping |
 | Canada | 100€ | 5€ shipping |
 | Poland | 99€ | 5€ shipping |
 | Poland | 100€ | 5€ shipping |
 | Egypt | 99€ | 5€ shipping |
 | Egypt | 100€ | 5€ shipping |
 | Japan | 99€ | 5€ shipping |
 | Japan | 100€ | 5€ shipping |

Como vemos, además de dejar claro en los ejemplos el comportamiento que queremos conseguir y asegurar en nuestro software, tenemos la posibilidad de añadir todo el contexto que queramos.

He trabajado mucho con Gherkin en los últimos años y es una de mis herramientas favoritas. Existen muchas técnicas que se pueden utilizar para escribir un buen Gherkin que sirva como guía de usuario y documentación de negocio, además de servir como tests de aceptación.
El libro Writing Great Specifications: Using Specification By Example and Gherkin de Kamil Nicieja es un gran recurso para aprenderlas.

Hay herramientas como Pickles que permite generar diferentes formatos a partir de Gherkin con Markdown embebido.
También podemos transformar Gherkin en Markdown cada archivo feature gracias a gherkin2markdown

Otras herramientas que pueden servir como documentación activa

Archivos .env
Archivos de herramientas de gestión de dependencias, requisitos y mantenimiento como package.json, pom.xml o composer.json
docker-compose.yaml
JavaDoc/PHPDoc

Nos puede interesar o no llegar a incluirlas en nuestra documentación, pero todas estas y otras similares nos pueden ayudar a dejar visible y de forma centralizada información relevante acerca de nuestro proyecto.

Otro tipo de documentación no activa

Archivos Readme

Los archivos README de los repositorios son una oportunidad para dar información relevante de un sólo vistazo en cada repositorio de código. Cuidarlos es esencial, y no sólo en proyectos Open Source.

Dependiendo de nuestras necesidades y del proyecto puede ser interesante incluirlos en nuestro pipeline.

ADR: Architectural decision records

Los ADR son una potente herramienta para anotar las decisiones que tomamos a nivel técnico. Se basan en archivos Markdown con la siguiente estructura:

# ID-1. Markdown format

Date: 2016-02-12

## Status

Accepted

## Context

The decision records must be stored in a plain text format:

- This works well with version control systems.

- It allows the tool to modify the status of records and insert
 hyperlinks when one decision supercedes another.

- Decisions can be read in the terminal, IDE, version control
 browser, etc.

People will want to use some formatting: lists, code examples,
and so on.

People will want to view the decision records in a more readable
format than plain text, and maybe print them out.

## Decision

Record architecture decisions in [Markdown format](https://daringfireball.net/projects/markdown/).

## Consequences

Decisions can be read in the terminal.

Decisions will be formatted nicely and hyperlinked by the
browsers of project hosting sites like GitHub and Bitbucket.

Tools like [Pandoc](http://pandoc.org/) can be used to convert
the decision records into HTML or PDF.

Los ADR son clave para anotar también la deuda técnica que vamos asumiendo en nuestro proyecto y sus consecuencias.

Existen herramientas como adr-tools que nos facilitan la creación de estos archivos.

Glosarios

Los glosarios surgen de la necesidad de documentar términos no sólo para tener un entendimiento compartido por nuestro equipo y otros equipos de otras áreas de la empresa, sino también para modelar y nombrar aspectos de dominio de nuestro software.

Gestionar glosarios no es una tarea sencilla ya que además de exponer de qué se trata cada término, hay que detallar en qué contextos se utiliza y cuáles son los términos a los que equivale en otros.

Si partimos de cero, es posible que nuestro glosario sea más sencillo de componer en el caso de tener una disciplina o procedimiento para ir documentándolo y consensuándolo a medida que surgen las dudas.

En contextos en los que se parta de un software en producción en el que no ha habido un ejercicio de documentar el glosario, nos tocará recopilar términos a los que nuestro software ya esté acoplado, documentarlos y asociarlos a los términos que finalmente acordemos en el equipo.

Convenciones y nomenclatura

Unas de las mejores prácticas que he visto aplicar es la de elaborar convenciones a la hora de nombrar diferentes aspectos de nuestro software, documentar dichas decisiones y comunicarlas a otros equipos para que también las sigan.

Por ejemplo, si todos los topics de Kafka o colecciones de Mongo siguen la misma estructura de nombres, incluyendo información útil (dependiendo de nuestros intereses) como la versión y nombre de entorno, el impacto en el día a día a medio y largo plazo es muy importante tanto para nuestro equipo como para otros equipos con los que colaboremos.

Retos adicionales

Hemos hablado de muchas cosas en este artículo y las mismas no están libres de retos.

Versionado

El principal reto de utilizar contratos y especificaciones es el gestionar el versionado de los mismos.

El versionado nos implica bastante trabajo y en algunas ocasiones complejidad extra ya que por norma general debemos mantener compatibilidad con clientes u otros componentes que utilicen versiones anteriores y que no siempre puedan tener el ritmo de actualización que nosotros tenemos.
Sin embargo, también nos da mucho más control y nos reduce los problemas de escalado a largo plazo.

Implicaciones al compartir el repositorio de la documentación con el del código

Tenemos que tener en cuenta que quizás nuestra documentación sufre cambios pero nuestro código no.
En algunos contextos, tenemos que gestionar este tipo de cosas para que no se nos dispare el ciclo de generación de un artefacto con una versión nueva por cada cambio de documentación integrado en nuestro repositorio.

Hay aproximaciones como separar la documentación en una rama aparte o utilizar los sistema de wiki que incluyen servicios como Github o Gitlab.

Asegurar el mantenimiento de la documentación no activa

Tarde o temprano tenemos que asegurar que la documentación no activa esté actualizada.

Este es uno de los grandes retos que tenemos al documentar y por lo que la mejor estrategia debe ser aprovechar al máximo posible todo recurso que pueda servirnos como documentación activa.

Tarde o temprano tendremos que evaluar si necesitamos incluir roles en nuestro equipo que se encarguen de este trabajo e incluso dispongan de dedicación total para mantener la documentación.

Esto dependerá mucho de nuestra empresa, proyectos y necesidades.

Conclusión

En este artículo he tratado de transmitir de forma resumida gran parte de los puntos críticos que he visto en mi experiencia en los últimos años introduciendo culturas de documentación en diferentes equipos con los que he trabajado.

La documentación activa puede ser un gran recurso para tener una buena base de partida y complementaria a una documentación que implique más inversión de recursos.

El perfil paracetamol

Wed, 20 Jun 2018 11:37:01 +0000

Hace algunos años, compartía con un gran amigo y colega del sector varios botellines casi congelados de 1906 en una de las geniales terrazas que hay por Alameda de Hércules en Sevilla. En una de las conversaciones surgió que en su equipo había dos personas que cuando no estaban, el trabajo parecía no salir adelante.

Cuando había algún bloqueo o problema, por mínimo que fuese, el resto de sus compañeros tenían la costumbre de esperar a que llegasen esas personas que, lejos de sentirse “honrados” con su gran medalla de héroes, estaban hasta los mismísimos de que todo aparentemente dependiese de ellos.

Esta fue la primera ocasión en la que utilicé el término paracetamol para describir perfiles que “gozaban” de este rol.

Un perfil paracetamol oculta el dolor del equipo cuando hay problemas, por lo que muy pocas personas en la empresa son conscientes de que estos problemas existen hasta que estas personas no están o se van de la empresa.

El perfil paracetamol es muy distinto a otros perfiles heroicos que se sienten cómodos generando dependencias. Estas personas normalmente suelen ser gente extraordinariamente generosa, autodidacta y disponen de alta capacidad resolutiva. Precisamente por estas capacidades y su actitud de ayuda directa ante los problemas, si no se ponen los medios para detectar su sobrecarga de trabajo y limitarla, las consecuencias podrán ser problemáticas para ellos pero especialmente críticas para la empresa.

Existen formas para evitar que se pueda crear una cultura paracetamol-first en una empresa, las siguientes son algunas que he visto funcionar a lo largo de mi carrera profesional.

Cultura de documentación

Una empresa, sobretodo una empresa que crea productos de software, no se puede permitir centralizar el conocimiento en islas humanas.

Crear una cultura de documentación en la empresa es algo vital para evitar dependencias a nivel de conocimiento.

Esta documentación debe ser fácilmente accesible y actualizada. Y debe cubrir desde aspectos organizativos y de procedimientos de la organización hasta las especificaciones técnicas de cada proyecto.

Metodologías y herramientas de documentación activa a nivel de código o producto de software como BDD (Aplicando StoryBDD y cuidando las narrativas), SBE e incluso Swagger (o Blueprint) son muy útiles para exponer la funcionalidad de los productos de forma automatizada.

A nivel de repositorios, todos los proyectos deberían contar con:

Un buen Readme con un índice que recoja los siguientes puntos
Cómo arrancar el proyecto
Cómo probar el proyecto
Qué dependencias tiene el proyecto
Qué versión y requisitos tiene este proyecto

En una empresa dedicada 100% a producto, debería haber una persona dedicada a asegurar esta cultura y gestionar esta labor.

La cultura de documentación no implica sólo documentar los proyectos o formas de trabajo, sino también el consultar la documentación antes de coger el teléfono o levantarse de la silla para interrumpir al compañero.

Este punto es especialmente importante si se trabaja de forma remota, con equipos distribuidos o en proyectos open source.

Medir los cambios de foco y limitar el WIP

En metodologías como Kanban y Scrum el WIP, work in progress, es uno de los conceptos más importantes y que permiten mejorar la eficiencia de un equipo.

Normalmente en los entornos paracetamol-first el WIP no se limita en absoluto, de hecho puede tender al infinito. Es clave que el foco no se diluya en varias tareas simultáneas. Limitar por ejemplo a una o dos tareas concurrentes por cada miembro del equipo suele ser una buena práctica para conseguirlo.

Otra medida útil es medir las interrupciones que tiene cada miembro del equipo. Cuando se hace y se presentan los datos en las retrospectivas al final de cada sprint, muchas veces sobran las palabras.

Hacer partícipe al equipo en las decisiones y diseño de soluciones

En mi opinión, todo desarrollador de software debería tener el skill o rol de arquitectura de software. Hacer partícipe de la visión global a todos los equipos es algo fundamental para que las personas no se queden limitadas o “cómodas” en su nicho.

En SCRUM existe el rol de Scrum Master. Cuando surge algún problema o necesidad de toma de decisión, el Scrum Master no debe lanzarse a solucionar el problema directamente; en su lugar debe guiar al equipo para que entre todos, encuentren la mejor solución, aunque ella o él la tengan clara. Hagamos SCRUM o no, me parece muy interesante esto y creo que es muy valioso para evitar estos perfiles.

Evitar ser líderes paracetamoles

El peor paracetamol es un dueño de la empresa al que le cuesta delegar o un líder que se carga peso de ejecución, ocultándolo al equipo y a las métricas.

Cuando eres el dueño de tu negocio y te apasiona lo que haces puedes caer muy fácilmente en esto y hacer que tu empresa dependa enteramente de ti.

Es importante desconectar y medir la productividad a nivel de entrega de valor cuando tú no estás en tu negocio.

Muchas personas creen que su equipo no es productivo cuando ellos no están físicamente en la oficina, pero la realidad es que no han puesto los medios para que estas personas puedan serlo o no disponen de la suficiente información para poder hacer su trabajo.

Exigir y respetar el tiempo fuera del trabajo

Los perfiles paracetamoles son propensos al workaholismo y por ello es importante que no se extienda una cultura en la empresa en la que se promuevan invertir horas extras o trabajo fuera de un rango horario.

Se suele decir que el máximo productivo de un desarrollador es de seis horas al día. Debería ser un objetivo que durante esas seis horas ese profesional tenga el foco puesto en entregar valor y optimizar la gestión de los proyectos para que esto sea la norma principal.

Todas las herramientas e información deberían ser fácilmente accesibles

Si hay impedimentos para poder disponer de la información o herramientas para realizar el trabajo, por ejemplo si se necesitan utilizar desde una aplicación móvil o fuera de la red local de la oficina, es muy posible que ese trabajo se delegue en otras personas y por lo general, en una cultura paracetamol-first, siempre serán las mismas.

Cultura de trabajo en remoto

No todas las empresas ni personas tienen por qué trabajar con una cultura de remote-first, pero establecer los mecanismos para hacerlo puede asegurar que todos los puntos anteriores se cumplan.

En una cultura remota es clave el medir y gestionar la comunicación de forma asíncrona, cada miembro del equipo debe poder realizar su trabajo de forma autosuficiente y contar con toda la información para poder hacerlo, por lo que no es un buen entorno en el que puedan crearse perfiles paracetamoles.

Apuntes interesantes

Dejo por aquí algunas opiniones y apuntes interesantes que he recibido por Twitter sobre este artículo.

Principios SOLID

Sun, 29 Apr 2018 15:49:13 +0000

A pesar de que existe mucho material escrito sobre este tema, en mi día a día me encuentro con software diseñado desde cero sin tener en cuenta algunos o ninguno de los principios SOLID.

Los principios SOLID son la base para diseñar software que sea flexible, testeable y fácil de mantener.

Algunos están ya bastante asumidos por la comunidad de desarrollo, otros no tanto.

En este artículo explicaré cada uno de estos principios con simples ejemplos que representan escenarios típicos de nuestro día a día.

Single responsability

Una clase debería tener una única responsabilidad.

Este principio quizás sea aparentemente el más sencillo de entender. Aun así, son frecuentes las implementaciones que se lo saltan, incluso de forma intencionada.

Un ejemplo de implementación que se lo salta es la de Active Record que se implementa en el ORM de RubyOnRails, cuyos modelos suelen ser propensos a atraer responsabilidades ajenas a las que deberían tener.

Un ejemplo parecido de esto sería este código

class Message {

 public function setFrom( Person $person ) {}

 public function setTo( Person $person ) {}

 public function send() {}

}

En este código, vemos que una clase mensaje implementa el método “send” para enviarse a sí mismo. Sin embargo, esta responsabilidad debería ser delegada en un objeto cuya labor sea enviar.


$user1 = new Person( "Asier" );

$user2 = new Person("Thor");

// componemos el mensaje
$message = new Message();

$message->from( $user1 );

$message->to( $user2 );

// enviamos el mensaje mediante un Sender
$sender = new SMSSender();

$sender->send( $message );

$sender = new EmailSender();

$sender->send( $message );

Como vemos en el código anterior, la primera ventaja de separar en responsabilidades nuestro código reside en que podemos tener flexibilidad a la hora de trabajar con nuestros mensajes sin cambiar el código de las clases que los representan.

En un principio quizás hayamos definido que nuestros mensajes se enviasen por email, pero si quisiéramos enviar por otros medios, deberíamos hacer cambios en nuestra clase Mensaje para poder implementar cambios en este sentido.

En muchas ocasiones, el aplicar estas modificaciones a las clases para poder mantener responsabilidades que no son las suyas las hacen magnéticas a más responsabilidades.

Por ejemplo si seguimos la estrategia de mantener responsabilidades en la clase Mensaje, esta podría también ser susceptible de implementar el método “save”, para guardar el mensaje en base de datos. O el método “print” para imprimirlo. Sin embargo, el otorgar de estas responsabilidades a la clase Message, conllevaría saltarse este patrón corriendo el peligro de limitar la flexibilidad, propiciar la aparición de código redundante a futuro (por ejemplo: necesidad de implementar métodos “save” o “send” en diferentes clases que no tienen ninguna base común entre ellas, utilizando la herencia de forma incorrecta con clases abstractas) y aumentar el coste de mantenimiento de nuestro software.

Open-close

El principio abierto-cerrado es para mí una de las lecciones más importantes que he aprendido como desarrollador de software.

El objetivo a conseguir es hacer extensible tu código sin tener que modificarlo.

Pongamos el siguiente ejemplo que no respeta este principio:


class SenderFactory {

 public function createFromProtocol( $protocol ) {

 switch ( $protocol ) {

 case 'sms':

 return new SmsSender();

 case 'email':

 return new EmailSender();

 }

 }

}

$factory = new SenderFactory();
$sender = $factory->createFromProtocol('sms');

$sender->send( $message );

En esta típica clase de Factoría, tenemos un Switch/Case para crear cada uno de los Sender a los que dará soporte. Si quisiéramos añadir un nuevo tipo de Sender, deberíamos añadir otro case más para el mismo, teniendo que modificar la clase por cada extensión.

Para conseguir respetar el principio Abierto-Cerrado, deberíamos seguir los siguientes pasos:

Crear una interfaz para los objeto Sender

interface SenderInterface {

 public function send();

}

Crear un sistema para poder añadir de forma externa las diferentes implementaciones de Senders en la factoría. Un ejemplo simplificado (no utilizar en producción):


class SenderFactory {

 private $_senders = [];

 public function createFromProtocol( $protocol ) {

 if( isset ($this->_senders[ $protocol ] )  )

 return new $this->_senders[ $protocol ];

 thrown new Exception("there is any sender for " . $protocol);

 }

 public function addSender( $protocol,
 $senderClass ) {

 $this->_senders[ $protocol ] = $sender;

 }

}

De esta forma podríamos añadir de forma externa sin preocuparnos de tener que tocar el código de la factoría:


$senderFactory = new SenderFactory();

$senderFactory->addSender( 'sms', SmsSender::class );

$senderFactory->addSender( 'email', EmailSender::class );

$sender = $senderFactory->createFromProtocol( 'sms' );

$sender->send( $message );

Liscov sustitution

Bárbara Liskov

El principio de sustitución de Liscov es uno de los que más frecuentemente se suelen saltar.

Básicamente lo que dicta es que si una clase hereda de otra, el funcionamiento de la aplicación no debería verse afectado si esta es sustituida por su clase padre.

Esto también relativo a las interfaces. Si una clase que implementa una interfaz es sustituida por otra que implementa esa interfaz, el comportamiento no debería verse afectado.

Esto conlleva varias cosas:

Los métodos públicos de la clase hija y padre deberían ser exactamente los mismos
Los métodos deberían devolver los mismos tipos de datos
Lo que se exprese en un método abstracto o no, en la clase padre o la interfaz, debería ser lo que este método realice, sin sorpresas extrañas.

Un ejemplo sobre este último punto: si tenemos esta interfaz


interface SenderFactoryInterface {

 public function createFromProtocol( $protocol );

 public function addSender( $protocol,
 SenderInterface $sender );

}

Esperamos que las clases que implementen la SenderFactoryInterface puedan crear un Sender que hayamos cargado en la misma.


class SenderFactory implements SenderFactoryInterface {

 public function createFromProtocol( $protocol ) {

 if ( !$this->checkIfMeetsSomeCondition( $protocol ) )

 thrown new Exception ( 'Protocol not supported' );
 ....

 }

}

En este ejemplo vemos que hay una condición interna en el método createFromProtocol que decide si funcionar o no con un tipo de protocolo. Esto viola el principio de sustitución de Liscov ya que otra clase que implemente SenderFactoryInterface no tiene por qué contemplar esa condición y esto puede derivar en inestabilidad del sistema al cambiar de SenderFactory.

La idea como conclusión es que debe respetarse lo que define una interfaz o una clase padre, sin añadir ni exponer funcionalidad adicional que esté fuera esa definición.

Interface segregation

Robert Martin

Al seguir el principio de Segregación de interfaces debemos asegurarnos de que una dependencia que inyectemos en una clase no muestre métodos que no se necesiten o no tengan sentido para lo que pretendemos hacer.

Por ejemplo, si tenemos una interfaz que define cómo podemos extraer y guardar datos de un sistema de almacenamiento:


interface StorageManagerInterface {

 public function getItems();

 public function save( EntityInterface $item );

}

Y tenemos una clase que necesite leer datos de ese sistema para imprimirlos:


class PrintService {

 public function printLines( StorageManagerInterface $storage ) { }

}

Dentro del método printLines no nos interesa guardar nada en el sistema de almacenamiento. De hecho, sería peligroso hacerlo en ese método, ya que se supone que no vamos a hacer ninguna manipulación, sólo deberíamos imprimir los datos que nos traigamos del sistema de almacenamiento.

Para no saltarnos el principio de Segregación de interfaces, deberíamos separar las operaciones de lectura y escritura en dos interfaces distintas. Si por alguna razón necesitásemos ambas operaciones en alguna clase, podríamos tener otra interfaz que implemente dichas interfaces.

Nuestro PrintService ahora ya tiene únicamente los métodos que necesita como vemos en el siguiente ejemplo.


interface StorageReaderInterface {

 public function getItems();

}

interface StorageeWriterInterface {

 public function save( EntityInterface $entity );
}

interface StorageManagerInterface
 implements StorageReaderInterface, StorageWriterInterface {
}

class PrintService {

 public function printLines( StorageReaderInterface $storage ) { }

}

Dependency inversion

La idea de la inversión de dependencias es que nuestro código dependa siempre de abstracciones, no de clases concretas.


// incorrecto
class NotificationService {

 public function __construct( EmailSender $sender ) {
 ...
 }

}

// correcto
class NotificationService {

 public function __construct( SenderInterface $sender ) {
 ...
 }

}

En el ejemplo superior vemos cómo respetar este principio y que al inyectar la interfaz SenderInterface, le damos más flexibilidad pudiendo cambiar en un futuro el tipo de Sender sin tener que modificar el código.

Sin embargo, pasar una interfaz no es lo único recomendable. Suele ser habitual que utilicemos interfaces de un framework que utilicemos para desarrollar nuestro código.

Esto nos genera una dependencia con el framework, lo cual puede ser un problema si luego queremos reutilizar código separándolo en un paquete independiente.


class LoggerService {

 public function __construct( Framework\EventDispatcherInterface $dispatcher ) {}

}

Lo ideal sería crear nuestra propia interfaz e implementarla en una clase que haga uso de la interfaz que nos provee el framework. Esto nos permite cambiar en un futuro de framework sin que nuestro código se vea afectado.


class FrameworkEventDispatcher
 implements EventDispatcherInterface {

 public function __construct(Framework\EventDispatcherInterface $dispatcher) {}
}

class LoggerService {

 public function __construct( EventDispatcherInterface $dispatcher ) {}

}

$logger = new LoggerService( new FrameworkEventDispatcher() );

Conclusión

Los principios SOLID nos permiten diseñar nuestro software para que después de evolucionarlo y mantenerlo durante años no se convierta en una mala partida de Tetris.

Si tenemos la mente abierta incluso podemos aplicarlos fuera del código o incluso del mundo del software, en otras disciplinas y artes creativas.

Cambio de mochila

Sun, 22 Apr 2018 16:08:31 +0000

Tengo una especie de ritual cada vez que cambio de etapa profesional y consiste en cambiar también de mochila. No se trata de algo metafórico, literalmente cambio la mochila en la que suelo llevar el portátil.

Este año he elegido cambiar de mochila. Es la tercera vez que lo hago. Después de diez años como autónomo, tres empresas creadas y siete años trabajando en remoto, desde Febrero he comenzado una nueva etapa profesional.

A final del verano del año pasado tomé la decisión de apostar por el cambio y ha sido interesante el participar en procesos de selección de varias empresas, algunas no españolas.

Vivimos en un momento increíble en el que trabajar como desarrolladores de software. Las empresas están cambiando hacia modelos más eficientes, distanciándose de formas de trabajar obsoletas que van radicalmente en contra de modelos actuales como el trabajo en remoto con equipos distribuidos y la mejora continua.

Buscaba ser partícipe aportando a este cambio y también, afrontar retos tecnológicos realmente ambiciosos. Y actualmente los estoy encontrando en Versia, como responsable del área de arquitectura de software.

No puedo decir que este cambio sea sencillo, pero tampoco es que estuviese acostumbrado a cosas sencillas. Pasar de trabajar desde un pueblo en mitad de viñedos en La Rioja a una oficina con doscientas personas desarrollando software está siendo un reto de adaptación bastante interesante.

Este año he empezado también a mentorizar tanto a nivel de desarrollo como a nivel de gestión de producto. No lo había hecho en serio hasta la fecha, pero es muy enriquecedor.

Debo mencionar que también he cambiado en la forma en la que veo a la comunidad de desarrollo de software en España.

Cada vez conozco a más desarrolladores con ganas de trabajar mejor y preocupados no sólo por adquirir conocimiento en herramientas tecnológicas sino también en mejorar de forma sincera sus soft-skills a nivel emocional. Y al margen de sueldos, estos perfiles no aceptan trabajar de cualquier forma.

Esto fuerza a que las empresas españolas deban espabilar para conseguir y retener talento. Otras empresas de fuera de España que se están afincando en Barcelona y el sur de España están viendo una oportunidad en esto y se empieza a notar en la comunidad, lo cual creo que es algo positivo.

Sin embargo también veo más postureo de buenrollismo y charlas orientadas a currículum. Me faltan charlas fuera de palabras clave actuales, más relacionadas con producto desde la experiencia real, refactoring de proyectos legacy críticos… y también me falta escuchar a más personas que normalmente no suelen estar tanto en el radar.

Y en este sentido, esperamos también aportar desde elComité nuestro granito de arena. Desde hace un año estamos trabajando en este sentido y nos gusta también hacerlo en compañía de otras comunidades, fuera incluso de Euskadi.

De momento, esto es todo. Llevaba tiempo sin escribir en el blog, en parte por la duda de si este tipo de entradas aportan valor.

Todo feedback es bienvenido :)

Cosas que he aprendido en 2016

Mon, 19 Dec 2016 14:50:33 +0000

**El equilibrio lo es todo. **

Es el verdadero éxito. Pero no quiero sonar como un abraza-árboles, creo que se puede tener los pies en la tierra, buena economía y satisfacer tus necesidades creativas. Esta misma semana Derek Sivers ha escrito sobre el tema.

Con salud y conocimiento, tú pones las reglas de cómo vas vivir.

Y relacionado…

Si algo es demasiado difícil puede ser un síntoma de que lo estás haciendo mal.

Que algo te resulte demasiado difícil durante un periodo largo de tiempo, es un síntoma de que posiblemente estés obcecado en hacerlo de una forma enrevesada y haya un camino más fácil o puede que otro momento más adecuado.

**Actualmente, para hacer funcionar un negocio SaaS (Software como servicio) necesitas un canal de venta. **

Sin un canal de venta, vas a tener únicamente un producto SaaS difícil de vender.

No obstante, aunque vendas poco, puede ser factible alcanzar tu objetivo si este es simplemente conseguir una vía adicional de ingresos recurrentes en lugar de buscar crecer exponencialmente como quien buscó El Dorado.

Pero hay que saber qué es lo que quieres y si quieres un negocio que crezca, necesitas un canal de venta sí o si.

Las personas que viven, cambian.

Y hay momentos en los que puedes encontrarte (de verdad) con personas que ya estaban a tu lado.

Todo el que hace, merece respeto.

Nada más que añadir.

La constancia es la mejor aptitud.

La constancia hace que las cosas se hagan y crezcan. Y que las personas que la aplican, crezcan también.

Twitter mola, si eliminas todo el input negativo.

Mi relación amor odio con Twitter ha llegado a su fin. He aceptado que ya no se puede usar como lo usábamos en el 2007 y he tomado la decisión de hacer unfollow a toda persona que era constante en expresar negatividad.

No me malinterpretéis, no me gusta la falsa positividad, de hecho la aborrezco y creo que es la raíz del odioso postureo actual. Sin embargo, creo que entrar a Twitter a aportar negatividad, quejas o cosas similares exclusivamente es lo fácil, sobre todo si no van acompañados de autocrítica.

En ese sentido me gusta más instagram y me resulta curioso ver que personas que se quejaban continuamente de todo en Twitter, en instagram parecen felices. Que sea real o no, es su problema, pero no me apetece estar en un canal para consumir mal rollo.

Yo he pecado de esto también e intento no caer en ello. Obviamente esta es simplemente mi opinión.

El feminismo es lo más importante que debes respetar como ser humano en estos momentos.

Sobre todo si no estás a gusto cuando ves actitudes claramente machistas o crees que el feminismo es una palabra mal elegida, es importante (y enriquecedor) abrir la mente y leer sobre el tema.

Probablemente te hayas encontrado con postureo (en Twitter), con quien escribe barbaridades (sin poner su nombre real) para provocar a quien no está en su misma línea de pensamiento, con quien se fustiga (en Twitter) por ser hombre, con quien lo mezcla con otros temas como política, veganismo etc. y con quien sube vídeos diciendo gilipolleces como que los “feministas follan mejor” o “tienen más sexo”. Yo he visto las cosas de forma distinta cuando he empezado a ignorar todo esto.

Existe literatura escrita sobre el tema, pero para mí lo más interesante ha sido el conocer e investigar figuras femeninas que han hecho cosas relevantes a lo largo de la historia(relacionadas o no con el feminismo) y fueron obviadas totalmente e incluso asesinadas miserablemente.

También hablar con mujeres de todo tipo sobre su visión de este tema te va a aportar cosas que igual todavía no ves de forma clara. Poco a poco vas a entender realmente que nos han educado según una cultura con base fuertemente católica que no respetaba la igualdad y empezarás a ver más cosas sutiles en tu día a día que no te van a gustar, con las que no estás cómodo, al igual que no te gusta ni estás cómodo con el machismo más evidente.

Aunque hay quien es agresivo a la hora de hablar este tema, en mi opinión no tienes por qué estar de acuerdo con todas las opiniones sobre el mismo, pero el que abras los ojos es importante para que el mundo sea mejor y seamos mejores como sociedad.

YouTube es un canal muy potente e interesante.

La verdad es que una cosa que este año he investigado y me resulta bastante interesante, hay contenido muy bueno si lo sabes buscar y tengo previsto hacer pruebas con este canal durante el año que viene.

Trabajar en remoto

Mon, 20 Jun 2016 00:28:16 +0000

Hace unas semanas leí un genial artículo de Jurgen Appelo que llevaba el título “Stop remote working”.

En dicho artículo el autor defiende la idea de que a veces se dice que decimos que trabajamos en remoto, como si estuviésemos trabajando en un sitio diferente al que deberíamos trabajar. Y es que si podemos trabajar desde cualquier lugar con conexión a Internet y visado, el mundo entero debería ser nuestra oficina.

Estamos hartos de escuchar el término “nómada digital” como si fuese una doctrina a seguir, pero realmente esto es solo una elección en la forma en la que trabajas. No necesitas ser un nómada, ni trabajar en remoto pero si quieres, puedes hacerlo.

De hecho hay personas que no quieren trabajar en remoto. Muchas personas valoran el ir a una oficina y ver cada día a las personas con las que trabaja en equipo. Esto es muy respetable y de hecho comprensible, es muy importante ver físicamente a las personas con las que trabajas. Comentaré más adelante en detalle sobre esto.

También hay personas que no están preparadas para hacerlo. Yo mismo no lo estaba la primera vez que estuve trabajando como empleado en remoto y también como autónomo. Tuve que aprender con el tiempo, sufriendo las consecuencias de malas prácticas en cuanto horarios, elección de clientes/proyectos y comunicación.

Valoro mucho haber pasado por la experiencia ya que con la misma he conseguido finalmente tener control sobre mi vida mejorando como profesional y también como persona.

Esta experiencia también me ha hecho fijarme en otras aptitudes distintas a las técnicas y más cercanas a las personales cuando elijo con quién quiero trabajar, ya sean clientes, proveedores, socios o colaboradores.

En los últimos años he trabajado con muchos clientes, incluso con reticentes a trabajar en remoto. Es cierto que aún queda mucho para que sea lo normal no solo en España, sino en todo el mundo. Creo que esta reticencia es algo cultural y de hecho, la cultura de la propia empresa ha de adaptarse poco a poco a este cambio.

Cuando trabajamos de esta forma, desde fuera muchas veces pareciese que estemos totalmente solos. Que estuviésemos inmersos en una clase de burbuja-locura que de un momento a otro nos vaya a provocar una especie de “fiebre de la cabaña”, como a Jack Torrance en El Resplandor.

Pero la realidad es que lejos de trabajar solos, tenemos un ecosistema virtual montado en el que pasan muchas cosas cada día. Estamos en constante comunicación con profesionales de diferentes culturas y países, resolvemos varios problemas a lo largo de la jornada y todo ello sin dejar enfriar el café.

Voy a centrarme en explicar mi punto de vista sobre algunas de las cosas que más me suelen preguntar sobre este tema y después os presentaré un proyecto en el que hemos estado trabajando Diego Rodriguez y yo en las últimas semanas con el objetivo de que si quieres, puedas trabajar en una ciudad distinta cada día.

Herramientas

Creo que nunca hemos tenido tantas opciones y herramientas que faciliten la comunicación entre los miembros de un equipo. Tenemos Slack, Trello, Evernote, Basecamp, Telegram y un largo etcétera de opciones con app móvil multiplataforma y mensajería IM. Incluso tenemos teléfono.

Pero el problema no está en la herramienta, sino en la comunicación. Existiendo comunicación, puede servir perfectamente un archivo de texto plano compartido por dropbox.

Dicho esto, personalmente prefiero Evernote o Slack junto a Skype o appear.in, pero hay miles de opciones más.

Comunicación

Es clave que la gente con la que trabajes sepa comunicar bien, tanto por escrito como por audio. Esto también incluye clientes y proveedores.

La comunicación es algo caro en dinero, en tiempo y a veces, también en salud.

Para mí comunicar bien se puede resumir en lo siguientes:

No mentir
Si hay algún problema, necesitas ayuda o hay algo que no sabes hacer, decirlo cuanto antes.
Si utilizas la ironía o eres “gracioso”, tener en cuenta la cultura del receptor, que puede no estar acostumbrado a tus bromas. Especialmente si no le estás viendo la cara.
Si no se entiende algo, preguntar, aunque sea quinientas veces.
No divagar e ir al grano cuando se está discutiendo algo en concreto.
Y lo más importante, no guardar silencio durante días por verse saturado.

Sensación de avance

Este es el punto en el que más insisto cuando trabajo con más gente en remoto, y va muy unido al tema de la comunicación.

Lejos de buscar tener un control obsesivo de cada parte del proyecto, considero importante compartir y actualizar todas las tareas en las que el equipo está trabajando, indicando quién está encargándose de cada una. También es importante ver cuáles se han completado.

Que cada miembro del equipo vea que se están haciendo cosas y quién está haciendo qué, creo que es lo más importante para tener motivación y la sensación de que el barco está realmente en ruta avanzando hacia algún sitio .

En metodologías ágiles existe el concepto de “daily”, una reunión breve en la que el grupo se reúne diez minutos cada día para ver lo que se ha hecho, lo que se va a hacer y si hay algún problema a solucionar.

En algunas ocasiones, no es posible reunirse cada día, pero sí que veo crítico hablar cada semana al menos.

Aunque trabajemos en remoto, también es importante verse en persona cada cierto tiempo. Por muy acostumbrado que estés trabajando solo, nada te carga más las pilas y te da la sensación de estar realmente en un equipo que el ver físicamente a las personas con las que trabajas día a día. No solo para firmar en una notaría cosas o discutir sobre cómo implementar una funcionalidad, sino también para recordar batallitas compartiendo unas cervezas.

Horarios

Realmente esto es lo que menos me preocupa cuando trabajo con más gente en remoto.

Aunque viene siempre bien una ventana de al menos una hora en la que coincidamos, tampoco es algo relevante para mí si hay buena comunicación por escrito.

Como nota personal y aunque sea tentador, si que recomiendo no trabajar de noche. Es genial no tener interrupciones telefónicas o de otro tipo, pero también tu vida social puede verse tocada, siendo muy fácil caer en una rutina en la que pasen días sin que hables con otras personas.

Cuando tengo que realizar labores que me exijan foco o creatividad como por ejemplo programar o diseñar, he aprendido que es mejor tener horarios para responder mensajes de email, llamadas o de mensajería y respetarlos rigurosamente antes que quedarse toda una noche programando.

Lugares y personas

Yo no soy nómada. Aunque me suelo mover bastante, por lo general suelo estar trabajando y viviendo de continuo en una ciudad determinada y luego cambio al cabo de un par de años. Me gusta esta libertad y seguramente en algún punto de mi vida decida quedarme en una ciudad ya “para siempre”.

Normalmente si no vivo con nadie más, suelo acondicionar parte de mi casa como si fuese una oficina y trabajar allí en los horarios que me haya puesto ese día. Quizás vaya a alguna cafetería alguna mañana, aprovecho para quedar con alguien y matar alguna tarea desde allí antes de que llegue.

Si vivo con alguien más, entonces suelo buscar con quien compartir oficina o algún coworking en el que haya un mínimo de vida, aunque prefiero lo primero. Si vivo con más gente me resulta muy complicado trabajar en casa, a menos que esa persona no esté en casa durante mi horario de trabajo.

Independientemente del lugar en el que trabaje en mi ciudad/pueblo “base”, sí que me gusta viajar puntualmente y moverme a otras localidades, trabajando durante unos cuantos días o incluso una semana desde las mismos.

Personalmente este cambio de contexto me carga mucho las pilas, ya que no solo conozco ciudades o pueblos que de otra forma igual no visitaría en modo turista, sino que puedo conocer a nivel profesional personas que están trabajando día a día en ellas, organizando comunidades y otro tipo de iniciativas interesantes.

Esta experiencia es un tipo de workation forzada y fiel a la definición del término, suele ser muy productiva tanto a nivel de trabajo como a nivel personal.

Por qué hemos creado rentmydesk.com

Tanto Diego como yo creemos que herramientas tipo linkedin cojean en la parte de conectar realmente a las personas en el mundo real y esto es algo muy importante en RentMyDesk.

Para las empresas cada vez es más importante conseguir captar talento para sus equipos, buenos proveedores (diseñadores, traductores, programadores, escritores…) y también obviamente, clientes. Con una herramienta así pueden recibir visitas de personas que cumplen con sus criterios viéndolas trabajar desde su misma oficina y compartir puntos de vistas profesionales.

Por otro lado, los freelances y otros profesionales acostumbrados a trabajar en remoto, pueden organizarse viajes a ciudades que quieran visitar, conociendo, trabajando y compartiendo cafés con personas y empresas que están haciendo cosas en esos lugares. También es una buena alternativa a trabajar en el aeropuerto mientras esperas a tu vuelo con un café de discutible calidad.

Ya tenemos un MVP desarrollado en beta privada. Si tienes un hueco en tu oficina y te apetece rentabilizarlo o atraer talento, ponte en contacto con nosotros. El servicio es totalmente gratuito.

El buen desarrollador de software

Sun, 05 Jun 2016 21:56:19 +0000

Llevo un tiempo pensando en lo que es para mí ser un buen desarrollador de software y los puntos que nos pueden hacer ser justo lo contrario.

Desde hace bastantes años trabajo y comparto proyectos con un número variado de profesionales, bien personas o agencias a las que delego trabajo o bien que me lo delegan ellos a mí. Este texto se basa en esta experiencia.

Por otro lado debo decir que, algunas de las cosas “malas” que destaco en este texto no solo las he visto en otros profesionales, sino que también las he visto en mí mismo cuando empezaba bastantes años atrás o al cometer errores a lo largo de mi carrera profesional.

Por lo tanto es una visión muy personal de nuestro mundo y no pretendo tener la razón absoluta. Los comentarios siempre se agradecen.

No tener una actitud de gilipollas

Somos unos privilegiados al dedicarnos a desarrollar software en estos momentos. Podemos asegurar que no hay paro en nuestro sector y que siendo inquietos, actualizándonos y currándonoslo un poco podemos trabajar desde prácticamente cualquier sitio del planeta (siempre que tengamos visado y conexión a Internet).

Es posible que en un futuro esto cambie y que mucho del trabajo o tipo de proyectos que estamos realizando en estos momentos se podrán sustituir por APIs o servicios cloud. Pero el presente es el que es y se puede vivir genial desarrollando software.

Pero este privilegio no nos da derecho a comportarnos como cretinos. Chantajeando a quien nos contrata o criticando en público a quien oferta porque en Londres cobrarías en triple y te irían a buscar a casa en un taxi de esos negros molones. Hablaré de este tema más en detalle más adelante en esta misma entrada.

Dominar el framework javascript de moda no te da derecho a ir por la vida con la actitud de un House desarrollador de software. House era un payaso pero al menos salvaba vidas (en la ficción).

Mejor un trabajador responsable que un ninja

Puedes cambiar el término “ninja” por lo que desees, incluidas siglas de certificaciones oficiales.

Al final de lo que se trata es de sacar trabajo adelante. Y de poco sirven las charlas que hayas dado, los tags que uses en Twitter o las pegatinas que tengas en tu Mac.

Tener capacidad de respuesta es algo muy valioso en un desarrollador para mí, mucho más importante que sus títulos o marca personal.

Es muy habitual la decepción que puedes llevarte al comprobar como una persona que es rockstar en Twitter u otros escenarios, desaparece en mitad de un proyecto para finalmente salir del mismo porque se ha visto saturado o simplemente no le gusta que se use una tecnología o herramienta X. Me parecen actitudes de chavales de catorce años. Sin ánimo de ofender a los chavales de catorce años.

Al final lo que se desea es tener en tu equipo gente con la que puedas contar. Puede que no controlen a un nivel brutal la última versión de Angular o hayan participado en un proyecto de gran tráfico o que hayan escrito libros sobre la última librería javascript de moda que dentro de dos años no utilizará nadie, pero es que la mayoría de las ocasiones tampoco hace falta.

Lo que sí hace falta son profesionales responsables que acaben el trabajo de forma correcta y sin tonterías.

Comunicación

La comunicación es otro valor clave.

A todos nos surgen imprevistos, nos equivocamos o puede que pase algo fuera de nuestro control que nos impida hacer nuestro trabajo. Comunicar cuanto antes cualquier imprevisto ayuda a poder resolver la situación, callarse siempre es una mala opción.

Lo mismo que si una frase o acto de otra persona en el equipo te sienta mal o no estás motivado por algún problema.

Personalmente valoro mucho quien sabe comunicarse cuando las cosas van mal o hay presión en un proyecto. El coste de comunicación es un precio muy alto que se puede pagar al trabajar con un equipo o una persona equivocados.

Saber comunicar correctamente tus ideas cuando trabajas en equipo, escribir bien y expresarte bien es una habilidad que en mi opinión nos hace mejores desarrolladores.

Esto me parece especialmente importante cuando se trabaja en remoto. Cuando no ves la cara del otro ni escuchar su voz, el texto lo es todo. Es crítico en estos contextos cuidar mucho cómo escribimos.

Comunicar también es escuchar.

Algunos podemos tener carácter, prejuicios por falta de perspectiva o simple cabezonería, somos humanos. Muchas veces incluso teniendo experiencia caemos en estas cosas. Y muchas veces, debatimos con ímpetu aun estando equivocados.

Creo que tanto si eres el que argumenta estando o no equivocado como si eres el receptor, debes escuchar lo que esa persona te está diciendo, sobre todo si tiene experiencia. Las lecciones más valiosas las aprendemos cuando estamos equivocados y cuando nos argumentan el por qué. Y son doblemente valiosas cuando el/la que nos alecciona tiene menos experiencia que nosotros.

Y aunque en ese momento no lo veamos, sin duda quedará en nuestra mente y será un recurso muy valioso cuando toque darse cuenta de nuestro error.

Pragmatismo VS curriculum oriented development

No es “sexy” (y madre mía con lo de “sexy” para hablar de frameworks y lenguajes…) desarrollar una API REST en php y mysql, teniendo Go, lenguajes como Erlang y OTP que existen desde los 80 pero que las hemos descubierto hace cuatro años o bases de datos como MongoDB que “escalan”, “son rápidas” (porque sí y ya está) y que las usan en esa empresa que tiene un “CEOfounder” de 24 años.

Estás desarrollando un producto y lo que importa es el valor. Entregar el máximo valor, con la calidad mínima necesaria consumiendo la menor cantidad de recursos de tiempo y dinero.

La tecnología es algo crítico pero no es lo más importante. Son nuestras herramientas, pero ya está. Nuestro recurso más valioso es la capacidad de crear con ellas usando nuestro criterio. El dominio de las mismas es importante, entrenar con ellas es importante, pero no tan importante como el entregar y entender lo que estamos desarrollando.

Creo que un desarrollador orientado a la herramienta no es un buen desarrollador, es mi opinión personal y mi opinión como cliente.

Por otro lado valoro también mucho el pragmatismo.

Está muy bien que la plataforma web tenga una arquitectura basada en servicios con una implementación de Inyección de dependencias muy currada y que también, se haya tenido en cuenta la separación de orígenes de datos para poder distribuir la carga entre varios frontales web, varios servidores de lectura y escritura a nivel de base de datos y las operaciones pesadas gestionadas por sistemas de colas asíncronas. Todo esto está muy bien. Pero al final si el proyecto es nuevo y va a tener un crecimiento natural, es posible que no se vaya a necesitar orquestar una arquitectura de ese tipo en seis máquinas o instancias virtuales en la nube de turno y puede que con un servidor en un hosting tradicional vayamos sobrados.

No necesitamos añadir coste al cliente de mantenimiento de sistemas o coste extra de servicios cloud porque a nosotros nos ponga cachondos tener una arquitectura de las que salen en blogs como High Scalability.

Y por último: el pasar de frameworks, ORMs y complicar el mantenimiento por trucos de rendimiento cuando no tienes este tipo de problemas, personalmente me parece condenar al proyecto a tener que reescribirse en un futuro por la cantidad de esfuerzo que puede suponer hacer cambios mínimos y el terror también de subirlos a producción.

Trabajando por cuenta ajena y las ofertas de trabajo

Muchas veces me quedo atónito al escuchar las experiencias que han tenido empresarios con su equipo técnico en ciudades como Madrid, Londres o San Francisco.

Cretinos sin ningún tipo de escrúpulos que hacen chantaje a sus empleadores amenazando con irse de la empresa porque han recibido en el último mes un montón de peticiones de amistad de recluiters en linkedin.

Chantajes que van desde imponer el uso de una tecnología/frameworks “o se van”, irse sin avisar ni decir nada una tarde de la oficina porque tenían un partido de fútbol o simplemente porque había un evento en la oficina molona de turno de Madrid.

La verdad me sorprende el aguante de sus jefes por miedo a perder “talento” o capacidad de ejecución, reteniendo un equipo tóxico a ese nivel.

“Que cierre su empresa si no sabe llevarla” He llegado a leer esto cuando un empleador anuncia una oferta de trabajo por debajo de los 32000 euros anuales a un desarrollador, sin entrar a valorar su nivel.

“En Londres me pagarían X” Pues ve a Londres y disfruta de este sueldo. Es posible que al irte, la gente que contrata a programadores en este país se de cuenta del vacío que has dejado, la gente que organiza eventos deje de hacerlo porque ya no merece la pena y el mercado del desarrollo y de Internet en España se colapse. Que se jodan, por no valorar el talento que alguien que va a comisión ha visto en tus aptitudes de Linkedin.

Pero desde luego yo no quiero trabajar con gente así. De hecho no quiero personas así a mi lado.

Montar un negocio se ha convertido en un espectáculo en el que cualquiera puede opinar sin vivir la experiencia de hacerlo. Pero la realidad es que los ataques a empresarios que están empezando y ofrecen sueldos humildes, no mejora el mercado.

Me parece muy respetable buscar el mayor sueldo posible, pero la mayoría de los lugares en los que te van a ofrecer trabajar no van a poder competir con otras empresas en eso. Y es respetable que no quieras trabajar por menos de lo que vales o creas que vales, pero montar un espectáculo en Twitter o en foros me parece bastante infantil y tóxico.

Al mundo real le dan igual las pataletas y la gente realmente competente habla poco y hace más.

Los programadores que realmente pueden elegir dónde trabajar lo hacen sin montar espectáculos. Si no les interesa lo que se oferta, se van a otro sitio sin montar un drama.

Todo lo demás

Y en último lugar es importante todo lo demás. Escribir buen software, mejorar como desarrollador día a día, mejorar nuestro nivel de inglés para comunicarnos y aprender de otros desarrolladores, aplicar calidad y entrega continua, autoformarnos en nuevas herramientas para que con criterio, las podamos utilizar cuando sea el momento y contexto adecuado.

Personalmente, algo que últimamente me parece importante es volver a repasar conceptos y mejorar mi nivel de matemáticas. Al margen de todo el postureo relacionado con algoritmos (otra moda-pesadilla), mejorar en esto viene muy bien para comprender cómo funcionan algunos sistemas y tras años de experiencia programando se ven de otra forma los conceptos que cuando los estudiábamos no los veíamos para nada útiles. También es útil para delegar trabajo en matemáticos que se encarguen de idear los algoritmos que implementemos en nuestras aplicaciones o software.

Considero también importante dominar otros campos y tener hobbies. Nos dan perspectiva, conocemos a gente distinta y salimos de nuestra zona de confort.

De hecho veo importante conocer otras personas muy distintas del mundo del software, creo que nos pueden dar puntos de vista e inspiración que nos hacen mejores desarrolladores aunque no seamos plenamente conscientes de ello.

Reactivando El Comité para mejorar el mercado de Internet en Bilbao

Tue, 05 Nov 2013 20:10:19 +0000

Para los que no lo sepáis, el comité (antes llamado webdevbilbao) es uno de los proyectos en los que he estado activo en los últimos dos años.

Fue en el 2011 cuando empezamos a organizar un evento periódico llamado webdevbilbao el último jueves de cada mes que tras un año de actividad decidimos cambiar el nombre a El Comité, con el objetivo de que sonase menos a programación y más a hablar de tecnología en general y crear cosas en torno a Internet.

Hemos probado muchas fórmulas para ofrecer un punto de reunión profesional para profesionales del sector. A diferencia de otros eventos, no incluíamos marcas de empresas y el objetivo principal era crear mercado real, de empresas, autónomos y profesionales que se dedicasen a desarrollar proyectos para Internet, que los hay y de gran nivel en Bilbao.

Dentro de El Comité, junto a otras empresas y marcas han salido otras iniciativas como Bilbostack, El Hackmité y algún techday en otras ciudades de España.

Ha sido muy enriquecedor y como nos negamos a parar de hacer estas cosas, estamos unificando todas las iniciativas que hemos liderado, junto a las iniciativas de otros que se han unido a nuestra causa para crear una propuesta de valor para el mercado de desarrollo de software entorno en Internet.

Nos hemos enfrentado a varios problemas interesantes durante este tiempo, algunos de los cuales puedo recoger en estos puntos:

Encontrar profesionales activos fuera de sus ocho horas de trabajo entre semana

Esto era el punto más difícil sin duda. Aunque no buscábamos cantidad, sino calidad en nuestra comunidad, nos ha sido muy difícil conseguir reunir un grupo de personas que se interesasen por iniciativas de este tipo.

Afortunadamente, hemos reunido dentro de la comunidad a un montón de cracks que nos apoyan siempre que pueden y a veces contribuyen con sus conocimientos y buen hacer.

Encontrar líderes que nos ayudasen con propuestas y a organizar eventos

No cobramos ni un euro por organizar los eventos y el hecho de obligarnos a organizar un evento mensual era muy agotador.

Nuestra idea al principio fue que la iniciativa fuese abierta, pero a la hora de organizar era complicado exigir el compromiso de otras personas. Acabamos por conformarnos con que viniesen.

Escaseaban las propuestas de charlas y a menudo, también por miedo a que no viniese una cantidad de publico aceptable cuando invitábamos a un ponente de fuera de la comunidad, teníamos que recurrir a nosotros mismos como ponentes.

Teníamos que tener en cuenta si había fútbol, si llovía, etc.

Salirnos de la imagen de evento para “frikis”

Muchos profesionales de marketing o directores de empresas incluso consideradas tecnológicas se alejaban del evento pensando que era sobre temas de programación demasiado avanzada y que no iban a entender nada.

Es cierto que algunas charlas eran completamente técnicas, pero el valor muchas veces estaba en las cervezas.

Sin embargo, esta imagen nos ayudó también a ahuyentar vendedores de humo y a animadoras de emprendedores.

La mayoría de los miembros de nuestra comunidad lideran equipos técnicos en grandes empresas tecnológicas o tienen su propio negocio. Lejos de colgarse la etiqueta de emprendedores se enfocan en crear valor y abrirse camino desafiando la crisis más dura que hemos conocido en la historia de nuestro país.

Encontrar un lugar en Bilbao para los eventos

Aunque no hemos tenido ningún problema en encontrar un sitio en otras ciudades para organizar nuestros eventos, en Bilbao no hemos tenido esa suerte.

La única ayuda recibida fue desde Eutokia, un centro de innovación bastante alejado de la ciudad que hacía que muchos asistentes no viniesen por no coger el metro. Esa zona tampoco daba mucho juego para quedarse a las cervezas de después, dispersando en grupos a los asistentes del evento y perdiendo la oportunidad de conocer a profesionales con los que poder hacer negocios o entablar una relación comercial.

Para eventos puntuales también hemos recibido la ayuda de la Universidad de Deusto o las oficinas de empresas dentro de la comunidad.

Parece que es muy difícil para el ayuntamiento Bilbao facilitar sitio para este tipo de iniciativas sin pasar por caja de 19:00 a 22:00 entre semana o los sábados de 9:00 a 15:00.

Viraje

Los problemas anteriores resultaron ser a veces muy cansinos, se sumaban a otros problemas con los que tenia que lidiar día a día más prioritarios de aquellos que tienen un negocio o un trabajo en una empresa que trabaja para clientes en varias zonas horarias.

No era muy sostenible y de forma natural nos llevo a

Parar y reflexionar

Paramos en varias ocasiones durante estos dos años. Personalmente creo que parar es importante cuando necesitas conseguir cosas y no estás dispuesto a esperar mucho para conseguirlas.

No buscar la cantidad

Nos obsesionamos con la cantidad, y eso fue un error. En el momento que pasamos de ese objetivo todo ha ido genial y hemos disfrutado más de los eventos que hemos hecho.

Contar con nuestros propios recursos

No hemos contado con dinero público ni lo hemos pedido. Todos los eventos que hemos montado han sido con presupuesto cero, sin ayuda de la diputación o del ayuntamiento de Bilbao.

La única ayuda que hemos necesitado ha sido y es el tema del sitio, para el resto de adversidades contamos con la ventaja de ser profesionales y agencias activas que colaboramos para hacer cosas reales de valor y con los recursos de tiempo/dinero justos.

No buscar la organización perfecta

Para la mayoría de los eventos que hemos organizado, nos hemos reunido en un bar con un boli, papel (a menudo de servilleta) y cervezas o café.

Ponemos una fecha, posibles invitados, posibles lugares, necesidades y obligaciones de cada uno. Normalmente en dos semanas está todo montado, incluido sitio web.

No forzar el hacer eventos periódicos

Funcionan mejor los eventos surgidos de forma puntual y natural, sin crearlos sólo por el hecho de mantener una frecuencia mensual. A nosotros por lo menos nos ha resultado mejor esta fórmula.

Irónicamente, gracias a todas las iniciativas que hacemos conseguimos más oferta y variada que la que ofreceríamos con un único evento mensual.

Iniciativas activas que hemos creado

Bilbostack Evento anual de una mañana de sábado en Bilbao que reúne las temáticas más punteras y a los programadores de más alto nivel en torno al desarrollo para Internet en Bilbao. Lo hacemos en la universidad de Deusto, con un aforo limitado normalmente a 250 personas, normalmente acuden sobre 200.

Techdays Son eventos de una mañana con cuatro charlas en una ciudad que no es Bilbao. De momento hemos hecho en Valladolid y La Rioja. Estamos pensando en Sevilla, Barcelona y Londres como posibles nuevos destinos.

Nunca vamos con pretensiones de reunir a un montón de gente, nuestro objetivo es dar charlas y compartir experiencias con los profesionales y estudiantes de esas ciudades.

Hackmité Eventos de 24horas o 48horas en entorno rural en el que varios programadores de la comunidad se reunen para pasar unas horas desarrollando proyectos reales desde cero.

A diferencia de un hackathon, en los hackmités el único premio es ver finalizado el proyecto y compartir buenos momentos con el resto de los asistentes.

Hemos hecho una edición en Febrero y estamos intentando cerrar otra este mes.

#Beermité Eventos esporádicos que se organizan vía Twitter para pasar tardes haciendo networking o charlando sobre tecnología acompañados de unas buenas cervezas. Podemos quedar dos o veinte como nos ha pasado en alguna ocasión y siempre resultan interesantes.

Conclusiones

Mi conclusión siempre es positiva, aunque finalmente sólo acudamos cuatro personas a estos eventos siempre sirven para algo si la gente que va es interesante y realmente lo es.

Descubrir que tu vecino está trabajando en proyectos grandes y que necesita ayuda de justo lo que tú dominas y tienes experiencia. Encontrar proveedores que antes buscabas fuera del País Vasco porque pensabas que aquí no había. Estas cosas son de gran valor.

Gracias a El Comité he conseguido encontrar buenos clientes y proveedores con los que sacar proyectos adelante con calidad y seriedad. Dichos proveedores trabajaban en mi misma ciudad y nunca los hubiese conocido de otra forma ya que los eventos de emprendedores, blogs o twitter no terminan de cumplir un objetivo profesional de crear mercado.

Animamos en serio a que la gente nos conozca y venga a cualquiera de nuestros eventos en cualquiera de nuestras iniciativas. Tenemos hambre de conocer a otros cracks que sabemos que sin dejarse ver tanto trabajan y crean valor en Bilbao.

Por favor, pásame la factura de este café

Sun, 21 Jul 2013 12:02:12 +0000

Hace unos meses, quedé con un cliente para tomar un café. No era una reunión de trabajo, simplemente era un café, para hablar y compartir un respiro en nuestras agendas.

Me encanta compartir puntos de vista y experiencias con otras personas que luchan por su negocio cada día. Lo considero algo muy importante, no sólo para cuidar tu red de contactos, sino para aprender de gente que hace cosas de verdad en lugar de sumarse a la fiesta publicitaria de emprender.

Lo que me dejó descolocado fue algo que ocurrió cuando nos íbamos a despedir: mi cliente me pidió que le hiciese factura por ese tiempo que habíamos compartido. “Asier, he aprendido mucho de este café y me has descubierto nuevos puntos de vista de mi negocio que ni me había planteado, por favor pásame factura por esto.”.

Puede que otras personas de perfil consultor más senior hubiesen visto esto como algo normal, pero a mí me chocó rotundamente.

Después de todas las actitudes y aptitudes que te encuentras al montar un negocio en España por parte de personas que buscan liderar un proyecto, sobre todo en Internet, este tipo de anécdotas te dan seguridad en seguir trabajando y mimando la pasión que nos hace caminar a la oficina con ganas de hacer cosas.

Este hecho, que me cogió por sorpresa, me ha confirmado en la importancia de seleccionar muy bien con quien trabajamos, tanto clientes como proveedores, incluso en medio de la crisis que estamos experimentando.

No contar tus metas

Sun, 14 Jul 2013 20:39:30 +0000

Derek Sivers es una de las personas que más me inspiran en el mundo, es una pena que no haya tenido la oportunidad de desvirtualizarlo todavía.

Esta semana descubrí la siguiente charla en TED y me dio mucho en qué pensar. En ella se comenta cómo nuestro cerebro confunde lo que socialmente anunciamos que vamos a hacer o estamos haciendo, asumiéndolo como algo que realmente ya hemos hecho.

Una de las cosas de las que me suelo arrepentir es que suelo comentar demasiado pronto mis ideas cuando las veo perfectamente factibles o empiezo a ejecutarlas. No siempre termino la ejecución, o cuando lo hago, puede ser años después de cuando las he empezado.

En mi caso puede que no termine de ejecutar algo por los siguientes motivos: me he dado cuenta de que no era tan buena idea como pensaba, he priorizado otras cosas más importantes sobre la misma, la he aparcado para ejecutarla más adelante o estoy en proceso de solventar un problema clave en la misma.

La ejecución de una idea no se percibe bien cuando no se ejecuta a corto plazo, aún cuando sea imposible ejecutarla de forma adecuada en un periodo corto de tiempo. Psicológicamente y a nivel de negocio, también es un problema no ejecutar rápido, de ahí la importancia de planear buenos MVP.

Hasta ahora, sólo le había dado importancia al guardar en secreto los proyectos de mis clientes y no me preocupaba exponer abiertamente los míos a pesar de que alguien pudiese criticarme por no terminarlos. Sin embargo, la siguiente charla me ha roto un poco los esquemas y he estado pensando en que puede ser buena idea aceptar el consejo.

Conceptos sobre APIs REST

Thu, 11 Apr 2013 13:48:22 +0000

En esta entrada voy a resumir los conceptos más importantes que he tratado en mis ponencias sobre REST.

¿Qué es REST?

REST, REpresentational State Transfer, es un tipo de arquitectura de desarrollo web que se apoya totalmente en el estándar HTTP.

REST nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier dispositivo o cliente que entienda HTTP, por lo que es increíblemente más simple y convencional que otras alternativas que se han usado en los últimos diez años como SOAP y XML-RPC.

REST se definió en el 2000 por Roy Fielding, coautor principal también de la especificación HTTP. Podríamos considerar REST como un framework para construir aplicaciones web respetando HTTP.

Por lo tanto REST es el tipo de arquitectura más natural y estándar para crear APIs para servicios orientados a Internet.

Existen tres niveles de calidad a la hora de aplicar REST en el desarrollo de una aplicación web y más concretamente una API que se recogen en un modelo llamado Richardson Maturity Model en honor al tipo que lo estableció, Leonard Richardson padre de la arquitectura orientada a recursos. Estos niveles son:

Uso correcto de URIs
Uso correcto de HTTP.
Implementar Hypermedia.

Además de estas tres reglas, nunca se debe guardar estado en el servidor, toda la información que se requiere para mostrar la información que se solicita debe estar en la consulta por parte del cliente.

Al no guardar estado, REST nos da mucho juego, ya que podemos escalar mejor sin tener que preocuparnos de temas como el almacenamiento de variables de sesión e incluso, podemos jugar con distintas tecnologías para servir determinadas partes o recursos de una misma API.

Nivel 1: Uso correcto de URIs

Cuando desarrollamos una web o una aplicación web, las URLs nos permiten acceder a cada uno de las páginas, secciones o documentos del sitio web.

Cada página, información en una sección, archivo, cuando hablamos de REST, los nombramos como recursos.

El recurso por lo tanto es la información a la que queremos acceder o que queremos modificar o borrar,** independientemente de su formato**.

Las URL, Uniform Resource Locator , son un tipo de URI, Uniform Resource Identifier, que además de permitir identificar de forma única el recurso, nos permite localizarlo para poder acceder a él o compartir su ubicación.

Una URL se estructura de la siguiente forma:

{protocolo}://{dominio o hostname}[:puerto (opcional)]/{ruta del recurso}?{consulta de filtrado}

Por ejemplo, /2013/conceptos-sobre-apis-rest/, sería la URL para visualizar este artículo.

Existen varias reglas básicas para ponerle nombre a la URI de un recurso:

Los nombres de URI no deben implicar una acción, por lo tanto debe evitarse usar verbos en ellos.
Deben ser únicas, no debemos tener más de una URI para identificar un mismo recurso.
Deben ser independiente de formato.
Deben mantener una jerarquía lógica.
Los filtrados de información de un recurso no se hacen en la URI.

Las URIs no deben implicar acciones y deben ser únicas

Por ejemplo, la URI /facturas/234/editar sería incorrecta ya que tenemos el verbo editar en la misma.

Para el recurso factura con el identificador 234, la siguiente URI sería la correcta, independientemente de que vayamos a editarla, borrarla, consultarla o leer sólo uno de de sus conceptos: /facturas/234

Las URIs deben ser independientes de formato

Por ejemplo, la URI /facturas/234.pdf no sería una URI correcta, ya que estamos indicando la extensión pdf en la misma.

Para el recurso factura con el identificador 234, la siguiente URI sería la correcta, independientemente de que vayamos a consultarla en formato pdf, epub, txt, xml o json: /facturas/234

Las URIs deben mantener una jerarquía lógica

Por ejemplo, la URI **/facturas/234/cliente/007 **no sería una URI correcta, ya que no sigue una jerarquía lógica.

Para el recurso factura con el identificador 234 del cliente 007, la siguiente URI sería la correcta: /clientes/007/facturas/234

Filtrados y otras operaciones.

Para filtrar, ordenar, paginar o buscar información en un recurso, debemos hacer una consulta sobre la URI, utilizando parámetros HTTP en lugar de incluirlos en la misma.

Por ejemplo, la URI /facturas/orden/desc/fecha-desde/2007/pagina/2 sería incorrecta ya que el recurso de listado de facturas sería el mismo pero utilizaríamos una URI distinta para filtrarlo, ordenarlo o paginarlo.

La URI correcta en este caso sería:

/facturas?fecha-desde=2007&orden=DESC&pagina=2

Nivel 2: HTTP

Conocer bien HTTP no es opcional para un desarrollador web al que le importe su trabajo. Aunque el RFC es sencillo de leer, si estás interesado en aprender bien las bases de este protocolo es muy recomendable la guía de O’Reilly sobre el mismo.

Para desarrollar APIs REST los aspectos claves que hay que dominar y tener claros son:

Métodos HTTP
Códigos de estado
Aceptación de tipos de contenido

Métodos.

Como hemos visto en el anterior nivel, a la hora de crear URIs no debemos poner verbos que impliquen acción, aunque queramos manipular el recurso.

Para manipular los recursos, HTTP nos dota de los siguientes métodos con los cuales debemos operar:

GET: Para consultar y leer recursos
POST: Para crear recursos
PUT: Para editar recursos
DELETE: Para eliminar recursos.
PATCH: Para editar partes concretas de un recurso.

Por ejemplo para un recurso de facturas.

GET /facturas Nos permite acceder al listado de facturas

POST /facturas Nos permite crear una factura nueva

GET /facturas/123 Nos permite acceder al detalle de una factura

PUT /facturas/123 Nos permite editar la factura, sustituyendo la totalidad de la información anterior por la nueva.

DELETE /facturas/123 Nos permite eliminar la factura

PATCH /facturas/123 Nos permite modificar cierta información de la factura, como el número o la fecha de la misma.

Quizá debido al desconocimiento o el soporte de ciertos navegadores, los desarrolladores web han usado, durante los últimos años, únicamente los métodos GET Y POST para realizar todas estas acciones. Si trabajamos con REST, esto sería un error de base y puede darnos problemas incluso a la hora de nombrar nuestros recursos, obligándonos a poner verbos en las URLs.

Códigos de estado.

Uno de los errores más frecuentes a la hora de construir una API suele ser el reinventar la rueda creando nuestras propias herramientas en lugar de utilizar las que ya han sido creadas, pensadas y testadas. La rueda más reinventada en el desarrollo de APIs son los códigos de error y códigos de estado.

Cuando realizamos una operación, es vitar saber si dicha operación se ha realizado con éxito o en caso contrario, por qué ha fallado.

Un error común sería por ejemplo:

Petición
========
PUT /facturas/123

Respuesta
=========
Status Code 200
Content:
{
 success: false,
 code: 734,
 error: "datos insuficientes"
}

En este ejemplo se devuelve un código de estado 200, que significa que la petición se ha realizado correctamente, sin embargo, estamos devolviendo en el cuerpo de la respuesta un error y no el recurso solicitado en la URL.

Este es un error común que tiene varios inconvenientes:

No es REST ni es estándar.
El cliente que acceda a este API debe conocer el funcionamiento especial y cómo tratar los errores de la misma, por lo que requiere un esfuerzo adicional importante para trabajar con nosotros.
Tenemos que preocuparnos por mantener nuestros propios códigos o mensajes de error, con todo lo que eso supone.

HTTP tiene un abanico muy amplio que cubre todas las posibles indicaciones que vamos a tener que añadir en nuestras respuestas cuando las operaciones han ido bien o mal.

Es imperativo conocerlos y saber cuándo utilizarlos, independientemente de que desarrolles siguiendo REST.

El siguiente ejemplo sería correcto de la siguiente forma:

Petición
========
PUT /facturas/123

Respuesta
=========
Status Code 400
Content:
{
 message: "se debe especificar un id de cliente para la factura"
}

Tipos y formatos de contenido.

Cuando hablamos sobre URLs, vimos también que no era correcto indicar el tipo de formato de un recurso al cual queremos acceder o manipular.

HTTP nos permite especificar en qué formato queremos recibir el recurso, pudiendo indicar varios en orden de preferencia, para ello utilizamos el header Accept.

Nuestra API devolverá el recurso en el primer formato disponible y, de no poder mostrar el recurso en ninguno de los formatos indicados por el cliente mediante el header Accept, devolverá el código de estado HTTP 406.

En la respuesta, se devolverá el header Content-Type, para que el cliente sepa qué formato se devuelve, por ejemplo:

Petición
========
GET /facturas/123
Accept: application/epub+zip , application/pdf, application/json

Respuesta
=========
Status Code 200
Content-Type: application/pdf

En este caso, el cliente solicita la factura en epub comprimido con ZIP y de no tenerlo, en pdf o json por orden de preferencia. El servidor le devuelve finalmente la factura en pdf.

Nivel 3: Hypermedia.

A pesar de lo que nos pueda inducir a pensar el término retrofuturista Hypermedia, el concepto y la finalidad que busca describir es bastante sencillo:** conectar mediante vínculos las aplicaciones clientes con las APIs**, permitiendo a dichos clientes despreocuparse por conocer de antemano del cómo acceder a los recursos.

Con Hypermedia básicamente añadimos información extra al recurso sobre su conexión a otros recursos relacionados con él.

Aquí tenemos un ejemplo:

<pedido>
 <id>666</id>
 <estado>Procesado</estado>
 <links>
 <link rel="factura">
 http://example.com/api/pedido/666/factura
 </link>
 </links>
</pedido>

En este ejemplo vemos cómo indicar en un xml que representa un pedido, el enlace al recurso de la factura relacionada con el mismo.

Sin embargo, necesitamos que el cliente que accede a nuestra API entienda que esa información no es propia del recurso, sino que es información añadida que puede utilizar para enlazar el pedido con la factura.

Para ello conseguir esto, debemos utilizar las cabeceras Accept y Content-Type, para que tanto el cliente como la API, sepan que están hablando hypermedia.

Por ejemplo:

Petición
========
GET /pedido/666
Accept: application/nuestra_api+xml, text/xml

Respuesta
=========
Status Code: 200
Content-Type: application/nuestra_api+xml
Content:

<pedido>
 <id>666</id>
 <estado>Procesado</estado>
 <links>
 <link rel="factura">
 http://example.com/api/pedido/666/factura
 </link>
 </links>
</pedido>

Como vemos, el cliente solicita el formato application/nuestra_api+xml de forma preferente al formato text/xml. De esta forma, le indica al servicio web, que entiende su formato hypermedia y puede aprovecharlo.

El servicio web por lo tanto, como implementa hypermedia, le devuelve la información de recurso y la información de hypermedia que puede utilizar el cliente.

Hypermedia es útil por ejemplo para que el cliente no tenga que conocer las URLs de los recursos, evitando tener que hacer mantenimientos en cada uno de los mismos si en un futuro dichas URLs cambian (cosa que no debería pasar). También es útil para automatizar procesos entre APIs sin que haya interacción humana.

Conclusión

Como hemos visto, los principios básicos para construir APIs REST se basan en conocer sobre todo HTTP, algo que no es opcional para un desarrollador web.

Versiones en nuestra API REST

Tue, 04 Dec 2012 14:57:51 +0000

Una de las cosas que hay que tener en cuenta cuando hacemos una API es que esta, al igual que otro tipo de aplicaciones web, va a cambiar.

Si la API es pública o es consumida por una gran cantidad de clientes, es casi seguro que muchos de estos clientes queden obsoletos o no sigan al día las actualizaciones que tu equipo vaya haciendo en la misma.

La solución consiste en dar compatibilidad a las versiones anteriores y de alguna forma separar o que el cliente pueda indicar a qué versión está accediendo en cada momento.

Las opciones más habituales para hacer esto serían:

Indicar la versión de la API en la URL del recurso.

https://api.dominio.com/v1/recurso/

Este sería un ejemplo de URL en la que se indica la versión de la API en la misma.

Esta es la opción más aconsejada pero la que a mí personalmente menos me convence ya que los clientes que quisieran estar actualizados a la última versión, deberían modificar las rutas de sus llamadas al servicio constantemente.

Indicar como parámetro la versión de la API

https://api.dominio.com/recurso/?v=1

Este tipo de opción se usa por ejemplo en la API de YouTube.

Yo personalmente prefiero indicar como parámetros opciones para filtrar o tratar la información del recurso solicitado. Por ejemplo, paginaciones, órdenes, búsquedas, especificar información parcial etc.

Indicar como header la versión de la API

**https://api.dominio.com/recurso/ ** “API version”: 1

Esta opción es la que más me convence, ya que no se ensucia la URL y si la aplicación cliente tiene las llamadas centralizadas en un único punto no debería ser problema añadir un header extra indicando la versión del API.

Después en el servidor podremos separar las versiones de las APIs en distintos servidores web o aplicaciones mediante un servidor proxy HTTP como Varnish que lea el header del request y sirva la versión de la API solicitada de forma transparente.

En javascript por ejemplo tendríamos el siguiente código para añadir un header http a nuestra llamada AJAX.


var request = new XMLHttpRequest();
request.open("GET", "https://api.dominio.com/recurso/", false);
request.setRequestHeader("API version", "1");
request.send();

En jQuery se añadiría el header de la siguiente forma.


$.ajax(
 "https://api.dominio.com/recurso/",
 {"headers": {"API version": "1"}}
);

En cualquier caso, se elija la opción que se elija es importante tener en cuenta que nuestra API puede cambiar en el futuro y facilitar la vida a los desarrolladores que programen los clientes de la misma siempre es una buena práctica.

La importancia del copy, más allá del SEO

Wed, 21 Mar 2012 03:15:24 +0000

Sin duda, el texto es el elemento más importante en cualquier sitio web. Aunque en este artículo hablaré sobre sitios web y no aplicaciones web, en éstas últimas los textos son críticas para la usabilidad y experiencia de usuario.

Sin embargo en los sitios web, especialmente en los sitios web de venta de producto, el texto tiene unas funciones tan críticas con obvias: la comunicación y explicación del producto o servicio. Por descontado, si el producto es el contenido, contenido tipo texto, la importancia del propio texto debe ser priorizada ante cualquier otro elemento.

Todo esto que parece obvio, encierra todo un mundo de posibilidades que influyen directamente en el diseño del sitio web y sobre todo la base de su organización: la arquitectura de la información.

Un diseñador web a quién respeto un montón, Goio de La Personnalité, señalaba en el blog de esa agencia una reflexión que defendía cómo y por qué a un diseñador se le debe facilitar un buen trabajo de contenido y de **copy **para que pueda realizar su trabajo de forma óptima.

Hay muy buenos profesionales copy en España, pero sinceramente creo que el hacer tú los textos y pensar en cómo enfocarlos, sobre todo en algo tan crítico hoy en día como es el sitio web de tu negocio (o tu sitio web personal), es un ejercicio muy didáctico acerca del propio producto que vendes, la forma en la que lo vendes y en general la estrategia de comunicación que vas a seguir con respecto a todo esto.

Pero hay un dilema en el que personalmente siempre caigo cuando hago este ejercicio. Internet hoy en día te suministra un montón de herramientas que te permiten medir de forma objetiva lo que buscan tus clientes y usuarios día a día en Google u otros buscadores. Una de las tareas más importantes a la hora de plantear un buen SEO es conocer estas búsquedas y ofrecer un contenido que encaje para atraer a tus clientes, midiendo los resultados para asegurarse que efectivamente los resultados atraen a usuarios nuevos con un porcentaje de rebote lo más reducido posible.

Podríamos pensar que los textos que describan nuestros productos o servicios, deberían seguir a rajatabla las palabras clave que nos permitan tener un buen SEO. Yo pienso que objetivamente esto es correcto, siempre y cuando midamos los resultados ya que en muchos casos el contexto concreto de nuestro producto nos puede dar alguna sorpresa.

Sin embargo, tengo una opinión muy personal que añade una puntualización a esto. Creo que los consumidores no siempre actúan objetivamente y en ocasiones, textos que no tienen nada que ver con lo que buscan directamente, funcionan.

Creo sinceramente en la seducción como arte, un arte que se puede aplicar en este escenario. Tú puedes llevarte a una persona a la cama una noche, esto no es complicado, sobre todo si te es indiferente qué persona sea siempre que cumpla unas pautas físicas y unos límites de locura determinados en ese momento. Sin embargo la seducción funciona de forma distinta, no es a corto plazo, y cuando se produce, el usuario se engancha de forma intensa e incluso intenta contagiar esa intensidad a otros usuarios, a menudo también posiblemente seducibles. Creo que con los clientes y usuarios de un sitio web ocurre una cosa parecida.

Un sitio web puede seducir con sus detalles, pero sobre todo con sus textos. No estoy diciendo que todo el texto debe ser subjetivo, el SEO importa y se debe cuidar, pero una buena combinación entre las dos formas de expresar lo brutal que es tu producto, puede ser una mezcla increíblemente efectiva.

Por ejemplo en la página de producto de servidores VPS Nitro de Mediatemple, se ha hecho un esfuerzo notable es hacer notar al usuario el por qué debe pagar 2400$/mes por un servidor virtual. Aunque en la página aparecen los términos VPS Server en el title y en el contenido, vemos otro tipo de texto corto que nada tiene que ver con explicaciones técnicas o términos que un usuario utilizaría para buscar servidores virtuales.

Otro ejemplo es la web del nuevo Basecamp, el software para gestionar proyectos de una gran compañía como 37signals. Aunque en el título de la ventana o pestaña del navegador vemos claramente el término de búsqueda que persiguen, los textos que explican el producto emplean un lenguaje más humano y atractivo que el que podríamos encontrar en este otro sitio web que vende un software similar.

Creo que a la larga estos detalles a la hora de plantear los textos de tus productos te hacen conocer mejor a tus clientes o usuarios y te hacen mejorar la comunicación del producto que vendes. Por supuesto la labor de analítica web y el feedback que se pueda recoger de usuarios reales del sitio web es muy importante para realmente saber si estos textos son efectivos o no.

Evidentemente, al igual que ocurre a la hora de seducir a una persona para otros fines, lo que vendes debe ser auténtico y en consonancia con lo que describes, es decir, debe haber una buena experiencia de usuario, de otra forma nunca se sostendría.

Sobre la longitud del texto, existe una técnica denominada long sales letter que hace mucho hincapié en presentar los beneficios de un buen producto de forma concreta. Esta técnica ha demostrado de forma objetiva que puede generar resultados increíbles.

En cualquier caso mi punto es que probablemente tus usuarios agradecerán que no les trates como a estúpidos usuarios sin personalidad que únicamente están hambrientos de información objetiva sin personalidad acompañados del menor precio posible, hay excepciones claro, pero tú decides a quién quieres seducir.

Simettric

Mon, 21 Nov 2011 20:06:45 +0000

Como muchos ya sabéis, desde hace un mes dejé de formar parte del equipo de Blackslot, empresa que cofundé en el 2009 y que va en el mejor camino para convertirse en la mejor opción de servicios de hosting de calidad/precio en España.

El principal motivo de arrancar una nueva aventura es que necesitaba un cambio, tanto personal como de concepto sobre lo que entendía como trabajo, objetivos y sentido a la hora de crear una empresa en internet, algo que casase más con la visión que andaba buscando a nivel personal y profesional. Visión que trato de afianzar con Simettric.

En una frase, Simettric es una agencia de desarrollo web enfocada en el desarrollo de productos SAAS, especialmente de innovación en internet.

Creo sinceramente que no tiene sentido entender el futuro del desarrollo de software en el escritorio, ni en que la gestión técnica del mismo dependa del usuario.

La misión de Simettric es desarrollar productos útiles para las personas o empresas que buscan ser ágiles, de verdadero valor para las mismas, buscando siempre la comodidad y facilidad de uso para solucionar problemas en lugar de crearlos.

Con esta línea hemos empezado a trabajar y, a pesar del poco tiempo de vida que tiene el proyecto, ya contamos con partners y clientes, algunos de ellos fuera de España, con proyectos bastante interesantes a la vez que motivantes.

Os animo a ojear nuestro Magazine, a que nos sigáis en Twitter y en Facebook, en los que vamos hablando sobre proyectos y tendencias innovadoras que nos parecen muy interesantes en el sector de internet.

Esto es en lo que llevo volcado las últimas semanas y en lo que estaré trabajando en los próximos meses. Sobra decir que es muy duro volver a empezar, pero apasionante.

Artesanio

Thu, 07 Apr 2011 15:32:11 +0000

Jose ha anunciado hoy la apertura oficial de Artesanio que será este próximo Lunes 11 de Abril.

Después de desglosar la idea en fases, abrimos el blog hace casi un año y desde entonces, hemos conocido a más de 300 artesanos y hemos hecho más de 2.500 amigos en facebook.

Desde el primer día, recibimos día a día valioso feedback de gente que hace cosas realmente increíbles.

Todo el feedback se asimila, desglosa e implementa en el que tenemos como objetivo que sea, el mejor mercado online y sitio web social creado para artesanos a nivel internacional.

Un objetivo ambicioso, sobre todo teniendo en cuenta a sitios como Etsy que cuenta con un excelente equipo técnico en el que podemos encontrar a gente como John Allspaw.

Nos espera bastante trabajo por delante, trabajo muy motivador por cierto, y también muchas obras de arte que esperamos que no os canséis de curiosear ni comprar.

Artesanio es un proyecto conjunto de Blackslot y Jose Luis Moreno, en el que estamos haciendo una labor de coworking autofinanciada con nuestros propios recursos.

Esperamos que os guste.

Cierra los ojos

Sat, 05 Mar 2011 00:45:52 +0000

¿Qué opinas de todo lo que te rodea? ¿Tiene el mismo sentido o importancia que hace unos segundos, cuando podías ver cada cosa o persona que está a tu lado?

¿Cambiarías alguna de esas cosas o personas por otras si no pudieses verlas nunca más?

Como algunos ya sabéis, he estado algo así como un mes y una semana fuera de toda actividad relacionada con un ordenador y por lo tanto, con mi trabajo y prácticamente mi vida. Me he recuperado de una enfermedad bastante grave en la córnea del ojo derecho que me llegó incluso a impedir encender la luz de cualquier habitación en la que me encontrase.

Varias semanas a oscuras, sin poder casi dormir por el dolor, sin poder leer nada, ni acercarme a un ordenador y por lo tanto hacer prácticamente nada de lo que estaba acostumbrado y “necesitaba” hacer. Un parón en la dinámica asumida mucho más didáctico que unas vacaciones.

Desde hacía tiempo sentía que algo estaba mal en mi vida y no podía dejar pasar una oportunidad tan buena de recapitular acerca de lo que era, de los errores o no que había cometido, de si lo que había hecho era lo correcto o no, de si lo que me obsesionaba era importante o no, de si era lo que realmente quería o lo que realmente me conduciría a lo que realmente quería y de si todo eso finalmente importaba en absoluto.

Mi forma de pensar, mi forma de vivir, mi forma de no vivir, mi forma de trabajar, mis relaciones, mis intentos de relaciones y de todo eso, todo lo que me fastidiaría poder no hacer ni ver, todo lo que cambiaría y haría que me plantease si mi vida era digna de vivir sin poder ver.

Siempre me ha resultado curiosa la forma tan fácil que tenemos de obsesionamos con la tecnología que usamos, la gente técnica a la que ésta nos apasiona. Hacer que todo esté perfecto, si eres programador que todo este aislado, sea abstracto con elegancia, que tenga toda la funcionalidad que nadie va a usar, que aguante un trabajo que nunca va a realizar y que esté preparado para ser reutilizado en proyectos que nunca vas a llevar a cabo o poder terminar. Nos importa el código, la herramienta, no lo que intentamos hacer, para quién lo estamos haciendo, lo que intentamos cambiar y la finalidad real pasa a ser tan irrelevante como nuestra vista. No es muy distinto a vivir sin poder ver o sin que nadie pueda vernos, dos cosas que parecen distintas pero que en algún modo se parecen mucho.

No necesitamos ver las cosas que carecen de importancia al igual modo que no necesitamos que ellas estén continuamente observando cada detalle de nuestra vida, pero reconozco que mirarlas en ocasiones es bastante entretenido. Pero a pesar de su entretenimiento es insuficiente, sobretodo para ser feliz.

Lo imperfecto, lo que consideramos imperfecto a veces, pero que está a nuestro lado y funciona o nos comprende o no nos comprende pero escucha y está a nuestro lado, es lo que muchas veces más importancia tiene y es lo primero que echamos en falta cuando buscamos lo que necesitamos ver. Necesitamos hacer y coleccionar más cosas imperfectas que no carezcan de importancia, cosas dignas de ver y difíciles de olvidar, con estilo, personalidad y que nos digan por sí mismas de una forma tremendamente rabiosa por qué son tan importantes.

Todo lo que tenga oportunidad de ver en cada momento de mí vida debe ser difícil de olvidar y debe decir por sí mismo lo rabiosamente importante de ver que es. Y si en algún momento no encuentro algo así, tendré que crearlo o provocarlo. En el caso que no lo haga he aprendido que sería irrelevante ver nada o a nadie, al igual que nadie me vea. Podría decirse incluso que en esencia, daría igual existir.

PD: He vuelto.

Cosas que he aprendido trabajando como autónomo desde casa (parte 2 de 2)

Sat, 20 Sep 2008 00:10:14 +0000

Esta es la continuación de algo que empecé escribiendo a modo de reflexión personal de las lecciones que he aprendido o he puesto en práctica trabajando como autónomo desde casa.

En la primera parte analicé una serie de puntos que he aprendido al trabajar desde casa, en esta segunda parte analizaré cosas que he aprendido trabajando como autónomo.

****Trabajar como autónomo

Antes de nada hay que ser consciente de que, al menos en el campo informático, si quieres ser autónomo para ganar más dinero vas por el peor camino que podías escoger.

Ser autónomo sale caro, requiere mucho más tiempo de trabajo que un puesto de trabajo normal, más responsabilidad y ser tolerante tanto al estrés como a la incertidumbre (y más en la situación en la que nos encontramos)

Lo normal (al menos lo que conozco) es que des el paso generalmente por dos motivos:

1- Porque dominas o te apasiona un área concreta o varias dentro de tu campo y, tras haber trabajado en alguna empresa has detectado una serie de cosas que se hacen mal y crees poder hacerlas mejor, o dar un servicio mejor o por lo menos diferente al que te permiten ofrecer o desarrollar.

2- Porque tienes un proyecto en mente que has desarrollado o que tienes planteado, que requiere una dedicación en tiempo exclusiva para poder ejecutarse o continuar desarrollándose de una forma óptima, además de requerir estas regularizado como actividad económica.

Mi caso es el primero y, aunque conozco a bastante gente que está en el segundo punto, lo que voy a escribir se basa en lo que he visto trabajando en el punto 1 como desarrollador web.

Antes de nada, una lectura recomendada es El libro negro del emprendedor de Fernando Trías de Bes. Con ese libro se te quitarán las ganas seguro de lanzarte a la aventura si no estás preparado para hacerlo.

Dinero

Necesitas dinero para empezar, durante los primeros meses no vas a ver ni un duro real por lo que es mejor tener un buen colchón de dinero para cubrir al menos los 6 primeros meses.

¿Qué es dinero real? El dinero real básicamente es el que te pertenece totalmente y no tienes que devolver.

Hay que tener en cuenta que muchas empresas pagan a 60 o 90 días e incluso a 6 meses. Para una empresa que esté en funcionamiento eso no es nada traumático, pero para alguien que empieza eso puede ser un problema muy serio.

Los bancos te ofrecen soluciones como líneas de descuento, pero además de asumir una pérdida del porcentaje total del cobro, debemos ser conscientes de que si el cliente no paga.. ese dinero se lo debemos devolver nosotros al banco.

Un ejemplo similar son los préstamos, aunque sean de bajo o nulo interés, hay que terminar pagándolos.

Tengas la filosofía, ética, visión, valores o demás cualidades que tengas, el dinero va a ser tu arma principal, debes aprender a manejarlo y gestionarlo lo antes posible.

Contrata un buen asesor y aprende de él. Te ahorrará tiempo en gestiones que tu no estás acostumbrado a hacer y aprenderás bastante sobre temas que hasta ahora no has tenido que dominar de una forma tan directa.

No es nada nuevo decir que toda factura ocasionada directa o indirectamente por nuestro trabajo o situación como autónomo debe declararse para desgravar el iva, dinero que teórica y prácticamente te cuenta el estar trabajando como autónomo.

Pero nunca debe ser una escusa para empezar a comprar o gastar dinero en cosas innecesarias que no compraríamos de no ser autónomo. Todo lo que compres tienes que pagarlo después.

Si necesitas oficina, no la compres.. alquila. Y si puedes alquilarla con otros profesionales de tu campo o de campos próximos al tuyo, mejor.

**Define tus servicios y elige a tus clientes **

**Debes fijar desde un principio los servicios que ofreces y los servicios que ****NO ofreces**.

Aprender a decir que no, es algo fundamental y requisito imprescindible para poder ofrecer un servicio de calidad.

Es importantísimo saber con que clientes NO debemos trabajar nunca. Te vas a encontrar a personas que no van a respetar el valor de tu tiempo, que te piden con insistencia servicios que no ofreces, aunque los sepas hacer, y que están convencidas por alguna razón de que trabajas gratis.

Aunque te aporten beneficios a corto plazo, los que te paguen evidentemente, te puede salir mucho más rentable a la larga, tanto económicamente como en tiempo, no trabajar con ellos.

Ese tipo de clientes puede acaparar todo tu tiempo sin aportar beneficios, evitando que puedas dedicarte a otros clientes o a tu vida personal.

Ofrece y especialízate/fórmate en los servicios que más te gusten y apasionen. Siempre vas a ser mejor y tener más dedicación en algo que te interese y guste, por lo tanto invierte en ello.

Si quieres ofrecer servicios en los que no crees que eres tan bueno, tardas demasiado tiempo o no te motivan, externalízalos y trabaja con gente a la que si le resulten interesantes y les motiven.

Elige clientes y proyectos que te gusten y apasionen. Vamos a estar mucho más involucrados y motivados en proyectos con clientes con los que estemos agusto y proyectos que nos resulten interesantes. Quizá ganemos algo menos de dinero, pero si tenemos la oportunidad de investigar y estar más desahogados / cómodos, nos va a merecer la pena.

Tiempo

Todo tiempo que no estés trabajando debe ser tiempo bien invertido …ya que si no trabajas, no estás generando beneficios.

Si necesitas unas vacaciones o desconectar, hazlo. No hay mejor forma de invertir el tiempo que en disfrutar de la vida cuando el cuerpo necesite hacerlo.

Si no tienes trabajo fórmate o investiga. Formarse es fundamental y luego desarrollar algún proyecto por nuestra cuenta, aunque no se termine o vaya a servir para “convertirnos en un google”, es genial para asimilar los conocimientos aprendidos. Esos proyectos nos pueden servir para mejorar nuestro “how-to” y poder ofrecer un servicio de más calidad a nuestros clientes.

Estima bien los tiempos, no subestimes el tiempo de dedicación para un proyecto. A la gente técnica nos suele pasar que nos cuesta estimar de una forma real lo que nos puede llevar en tiempo desarrollar algo que tomamos por sencillo.

Elige bien los eventos a los asistes. En el campo del desarrollo web desafortunadamente encontramos eventos que aportan poco o nada a nuestra profesión. Te ahorras tiempo, hotel, avión y vuelo si no acudes a los mismos.

**Otros temas **

Tu eres tu propia marca, no sigas modas absurdas ni intentes ser algo que entre en un concepto inventado por gente que necesita una etiqueta para sentirse importante o demostrar algo a los demás.

Aprende de la gente, rodéate y relaciónate siempre con gente de la que puedas aprender algo.

No te cierres en tu campo profesional a la hora de aprender nuevas cosas, es bueno conocer más colores para construir con ellos un punto de vista único.

Escribe un blog, es muy valioso conocer las opiniones, sobre temas que te interesan, de personas ajenas a tu círculo social más cercano. Además te ayuda a conocer a gente con tus mismos intereses y hacer muy buenos contactos y amigos.

Y vosotros… ¿qué añadiríais?

Cosas que he aprendido trabajando como autónomo desde casa (parte 1 de 2)

Fri, 12 Sep 2008 17:07:14 +0000

Llevo poco tiempo como autónomo (desde Abril de este año) y trabajando desde casa (desde Enero de este año) aún así, he aprendido algunas cosas y me he animado a escribir sobre las mismas.

En esta primera parte me centraré en cosas que he aprendido trabajando desde casa.

En la segunda parte hablaré de las cosas que he aprendido estando como autónomo.

Los consejos que doy, están dirigidos para mí mismo el primero.

Trabajar desde casa

Para empezar hay que ser consciente de que trabajar en casa no es ningún chollo y dependiendo de cómo seas, pueden ser mayores los inconvenientes que las ventajas que conlleva.

**Es bueno disponer de un espacio acondicionado para trabajar **

Debes tener sensación de espacio. Disponer de una mesa ordenada y únicamente con lo que necesites para realizar tu trabajo, es fundamental.

Si vives con más gente, hazles entender que sólo deben entrar a tu espacio de trabajo para decirte algo súmamente importante o cuando te vean alejado de tu portátil.

No dudes en comprar un buen ventilador, una buena silla y un segundo monitor (o los que necesites) si usas portátil.

Con respecto a lo del segundo monitor, a algunas personas que programamos nos resulta muy difícil concentrarnos en un editor de código extendido en una pantalla de más de 19 pulgadas. La mejor combinación que he probado es mantener el portátil a la altura de la mesa y el monitor más grande situado justo encima de la pantalla del mismo. Esto nos permite concentrarnos mejor en el código, y dejar en el monitor más grande las ventanas del navegador con el resultado (que suelen ocuparnos más espacio debido a extensiones imprescindibles como firebug), la documentación y otras cosas secundarias.

Usando la combinación anterior junto a escritorios múltiples (también llamados virtuales), puede incrementar nuestra productividad considerablemente. En MacOSX Leopard los escritorios virtuales vienen por defecto con el sistema, al igual que en la mayoría de escritorios para Linux/Unix. En Windows podemos tener esta funcionalidad en Windows Vista/Xp gracias a la herramienta Open Source Vista/XP Virtual Desktop Manager.

**Fijarse un horario y vestirse para trabajar **

Una de las ventajas de trabajar desde casa es el poder gestionar el tiempo de la forma que creas conveniente. No hay que asumir esta ventaja como algo que nos evite la necesidad de tener un horario.

Tener un horario puede ayudarnos a conseguir concentración, evitar procrastinación y necesitar menos tiempo para realizar el trabajo. Si asumes la recesidad de respetar un horario, vas a dejar las cosas que no están relacionadas de lleno con tu trabajo para otro momento que no entre dentro de dicho horario.

Si algún día necesitas modificar dicho horario, que sea por algo realmente necesario y tomarlo como un hecho puntual. Si no somos serios en ese aspecto no sirve de nada el planear un horario, sólo para engañarnos a nosotros mismos.

Probablemente pienses que respetar un horario limíta la libertad que tienes para gestionar tu tiempo al trabajar desde casa. Precisamente esa libertad es la que te permite planificar un horario adaptado a tí, sin que nadie lo haga por tí ni te ate a unas horas en las que no estas agusto trabajando.

Tener libertad no debe llevar a no ser responsables ni ordenados con nuestro tiempo. Piensa en la responsabilidad que Hiro Nakamura debe asumir ;)

Cuando trabajamos en casa podemos tener una mala costumbre de ponernos a trabajar nada más levantarnos de la cama.

Lo ideal es levantarnos, hacer algo de ejercicio, ducharnos, vestirnos con ropa cómoda, desayunar y ponernos a trabajar.

**Evita programas de gestión de tiempo que supuestamente te ayuden a ser productivo, usa el papel/una pizarra y escucha música nueva **

Al igual que en tu mesa de trabajo, en tu ordenador no debería estar ejecutándose lo necesario para realizar tu trabajo y ayudarte a concentrarte.

Muchos programas del tipo GTD “Getting Things Done”, si no se usan bien, pueden hacernos perder el tiempo precisamente en gestionar las tareas que nos quedan pendientes y nos abruman con alertas por todas partes.

Para gestionar tus tareas y horarios hazte con un calendario (mejor si es el que viene con tu sistema operativo) y un gestor de proyectos deslocalizado y lo más minimalista posible (yo uso BaseCamp). Procura hacer más caso a tu calendario que a las tareas pendientes para respetar tus horarios, y pasa las tareas más inmediatas a papel.

Cuando las completes, abre el gestor de tareas y táchalas, pasa las siguientes a papel y cierralo hasta que completes las nuevas.

Mantener el gestor de tareas abierto puede agobiarnos, y nos dificulta el visualizar los “arboles” que debemos talar dentro del “inmenso bosque” que tenemos en frente.

Dibuja mapas mentales, para separar problemas, tomar decisiones, planificarte o para buscar la forma de desarrollar cierta funcionalidad de un proyecto que tengas entre manos, y prototipa las interfaces asociadas a una funcionalidad que debas desarrollar. Hazlos sobre papel o sobre una pizarra, es más rápido y nos aleja de toda distracción concentrándonos en lo verdaderamente importante.

Para muchas personas la música ayuda a concentrarse, yo por ejemplo uso el cliente de escritorio, evita entrar en la web mientras trabajas, de last.fm que me permite escuchar música del estilo que más que gusta ofreciéndome variedad, esto último es muy importante para hacernos más ameno el trabajo.

Programas de mensajería instantánea

Los programas de mensajería instantánea son un gran avance para mantenernos en contacto con clientes, amigos y familiares.. pero a la hora de trabajar suponen un gran peligro que afecta directamente a nuestra productividad.

Quita bots de servicios tipo twitter, pownce, jaiku y demás. Estos servicios disponen de clientes de escritorio que nos permiten seguirlos de una forma más asincrona y con menos intrusividad.

Desconéctate de MSN/Live en horario de trabajo. MSN/Live de Microsoft es la red de mensajería instantánea que tiene más usuarios conectados en todo momento,y la mayoría no son profesionales. Por el contrario, servicios como GTalk de Google, tienen un número de usuarios más bajo que lo usan, y en la mayoría de casos son usuarios más avanzados que disponen menos tiempo para perderlo.

Recuerda que tus amigos y familiares tienen tu teléfono, si es algo urgente te van a llamar.** **

Haz ejercicio, no pierdas relación con la gente que te importa, conoce a gente nueva relacionada con tu trabajo, practica sexo (si puedes) y sal de casa

Debes ser consciente de que trabajar en casa, además de psicológicamente, te va a afectar físicamente.

El ejercicio es fundamental para soportar cargas de trabajo, crear nuevas neuronas y mejorar el ritmo cardiaco entre otras muchas cosas. Dentro de tu horario de trabajo, fíjate una hora al día para cuidarte físicamente.

Trabajando en casa no tienes compañeros de trabajo. **Esto es una desventaja muy grande, sino colosal. **

Trata de sacar tiempo para hablar con tu familia, padres, amigos etc. Trabajar en casa y empezar con un negocio que debes sacar adelante si o si, va a limitar mucho el tiempo del que dispones para compartir con otra gente, especialmente si están fuera del ámbito de tu trabajo. Debes relacionarte con más gente, es importantísimo para ampliar tu cartera de contactos, forjar más amistades, aprender cosas sobre más temas que no sean tu trabajo pero que te puedan venir bien en un futuro, mejorar tu carisma, tu forma de expresarte, tu sentido del humor y tu vida en general.

Practicar sexo además de proporcionaros a tí y a tu pareja placer, mejora tu autoestima, la circulación de la sangre, te libera de estrés y te hace estar de buen humor.

Sal de casa aunque sea solo, busca cualquier excusa para hacerlo. A mí personalmente me resulta imprescindible escaparme a algún sitio donde pueda ver el mar y estar tranquilo.

Correo, RSS y Twitter

El correo electónico es imprescindible para realizar nuestro trabajo hoy en día. Muchos de nosotros disponemos de varias cuentas a las que acceder y que debemos revisar todos los días.

Centralizar todas nuestras cuentas en un sólo cliente nos va a evitar perder tiempo y olvidar leer algún correo importante.

Para muchos, el estar al día en tecnologías, técnicas y metodología que aun no están documentadas y son imprescindibles para mejorar como profesionales, es gracias al seguimiento de cientos de sitios web que comparten experiencia y conocimiento.

Los lectores rss nos permiten asimilar de forma cómoda cantidades colosales de información que nos llega cada día.

Sin embargo son de sobra conocidas las desventajas de no tener un control del tiempo invertido en la lectura de toda esta información. Planifica dentro de tu horario, un tiempo para tu lectura diaría de rss y síguelo a rajatabla.

Servicios de mensajería asincrona como twitter nos permite recibir información filtrada y recomendada por gente que hemos decidido seguir, además de conseguir nuevos y valiosos contactos. Elegir bien a tus contactos en este tipo de servicios es clave.

**Evita horarios nocturnos, descansa y desconecta **

Muchos trabajamos de noche bastante mejor que de día, sobre todo cuando trabajamos en casa. Por la noche nuestro vecino no se va a poner a taladrar una pared, hay menos gente conectada en los programas de mensajería instantánea, hay menos tráfico en la calle, nadie normal nos va a llamar o abrir ventana en nuestro cliente de mensajería por alguna estupidez a media noche y seguramente el resto de habitantes de tu casa, estarán durmiendo.

Sin embargo, ese tipo de horarios pueden evitar que tomemos en serio nuestras horas dedicadas al sueño y no nos permitan ser todo lo sociales que deberíamos.

Es imprescindible estar lúcidos y descansados cuando hablamos con nuestros clientes u otras empresas/profesionales con las que trabajemos.

Descansar es fundamental para ser más productivos. Piensa que si tienes que restar horas de sueño porque no estás consiguiendo todos los objetivos que deberías, es que algo has planteado mal.

Debes desconectar: vete a cenar/tomar copas con tus amigos, juega a la consola, alquila películas/ve al cine, ve a conciertos, escápate a una casa rural.. y vete a eventos que organize gente como tú.

Continúa leyendo la segunda parte.

About me

Mon, 01 Jan 0001 00:00:00 +0000

My name is Asier; I’m from Barakaldo, but I live in Madrid, Spain.

Currently, I’m working as Sr. Engineering Director at Auctane, and I’m studying psychology at UOC University.

You can find me at:

Sobre mí

Mon, 01 Jan 0001 00:00:00 +0000

Mi nombre es Asier, soy de Barakaldo (País Vasco, España), y resido de forma habitual en Madrid.

Actualmente formo parte del equipo de gestión de ingeniería de Bestsecret Group liderando los equipos de desarrollo de software en el dominio de payments.
Anteriormente trabajé en Auctane asumiendo el rol de Senior Engineering Director para el brand de Packlink Shipping y el hub de ingeniería de España.

Empecé mi carrera tecnológica trabajando en el área de sistemas IT en empresas como Softec, Ibermática, Batz Coop. (Grupo Mondragón), Altran (en proyectos para Panda Security y BP Solar) para después pasar al campo de desarrollo web trabajando en nvivo Internet, como autónomo en diversos proyectos web y finalmente como director técnico en Ideateca Factory.

En Mayo de 2009 fundé Blackslot SL, una empresa que se dedica a ofrecer soluciones avanzadas de sistemas y de desarrollo web para empresas que crean proyectos en internet.

En Abril de 2011, desde Blackslot lanzamos Artesanio.com, una red social y plataforma de ecommerce saas para el mundo de la artesanía.

En Octubre de 2011 fundo Simettric, una agencia de desarrollo de proyectos de innovación para Internet.

En Febrero de 2012 me uno al equipo de dirección de 4Visions Gestió de Projectes, SL, empresa en la que desarrollamos soluciones de software online para freelances y agencias del sector de la traducción, 4visionshq.com.

En 2018 trabajé como responsable en el área de arquitectura de software en el Grupo Versia.

Me apasiona también la música, además de buscar continuamente grupos, artistas y temas, practico el arte de la mezcla de música electrónica desde 1997.

Puedes leer mi currículum en este enlace.

Y puedes encontrarme por:

Email: asiermarques@gmail.com
Twitter: twitter.com/asiermarques
Linkedin: linkedin.com/in/asier
Instagram: instagram.com/asiermarques
Artículos en inglés en Medium: asiermarques.medium.com