La pandemia ha dejado a un lado la discusión, pues la necesidad y el sentido común se han impuesto a las dudas. Tal vez una de las pocas cosas que podemos agradecer a la pandemia. Las empresas están empezando a vislumbrar las ventajas de esta forma de trabajo. El número de bajas por enfermedad se ha reducido considerablemente, la productividad se ha mantenido e incluso en algunos casos ha aumentado. También podríamos hablar de las ventajas sobre la calidad de vida y sobre el impacto medioambiental, pero eso daría para otro artículo.

En este queremos centrarnos en un aspecto más material: ¿qué es lo mínimo que un empleado necesita para ejercer el trabajo desde casa? ¿Qué gastos deberían cubrir las empresas? ¿Cómo se tributan las compensaciones o reembolsos por esos gastos?

El ámbito jurídico al que nos ceñimos es la legislación española, sobre todo a partir de la entrada en vigor del Real Decreto-Ley 28/2020 que regula (entre otras cosas) los costes del teletrabajo.

Empecemos por lo fundamental: Internet y un portátil

Lo más importante que un empleado necesita para trabajar en remoto es, por supuesto, una conexión a Internet de alta velocidad y un portátil. La preferencia por el portátil frente a la estación de sobremesa es obvia: permite conmutar fácilmente entre la casa y la oficina. 

Veamos cómo se ha comportado la popularidad mundial de la palabra laptop desde el comienzo de la pandemia:

En cuanto a la conexión a Internet, lo ideal es un punto de acceso Wi-Fi con una conexión de fibra óptica que nos garantice el ancho de banda necesario para hacer videollamadas y acceder a los recursos remotos de la empresa. Por suerte casi todo el mundo tiene una buena conexión en casa.

¿Pero quién debe pagar por ella? El uso que se haga será tanto privado como para desarrollar la actividad laboral. ¿No debería ser parcialmente pagada por el empleador? Más tarde llegaremos a ese punto.

Entretanto sigamos con los elementos necesarios para un home office satisfactorio:

Un paquete básico de Home Office

Al comienzo de la pandemia, la empresa para la que trabajo nos mandó a casa y a los pocos días recibimos un paquete de “trabajo en remoto”. Este kit contenía, además del portátil, los siguientes elementos:

• Bolígrafo, libreta y taza personalizada con el branding de la empresa: en especial la taza fue todo un detalle, pues la “hora del café” es un elemento cultural muy importante en el ámbito laboral. Que el logo de tu empresa aparezca de alguna forma en tu escritorio de trabajo, envía un mensaje claro al trabajador: Donde tú trabajes, ahí está la empresa. Es la metáfora de la deslocalización del empleo. Hay empresas especialistas en branding como Maxilia España que ofrecen este servicio.
• Headset: un set de auriculares y micrófono para las videoconferencias. Éste puede ser junto al portátil y la conexión a Internet el elemento más importante, pues la comunicación es el principal problema en el trabajo remoto. Además evita que el resto de inquilinos escuchen conversaciones sensibles.
• Teléfono móvil y tarjeta SIM: aunque ya muchas empresas utilizan VoIP para hacer llamadas al exterior, este es uno de los gastos de explotación que las empresas deberían asumir. Una de las principales ventajas de una tarjeta SIM de empresa es que sirve de backup para la conexión a Internet en caso de que nuestra conexión de casa deje de funcionar: ¡la red 4G te puede salvar un día de mala conexión!
• Mascarillas FFP2: para las ocasiones en que tengamos que ir a la oficina para alguna reunión importante. En la web de Maxilia.es también podréis encontrar diferentes modelos de mascarillas personalizadas para vuestros empleados.

Para mucha gente, este es el paquete básico, pues contiene los mínimos elementos que se necesitan para emular el trabajo en la oficina. 

Volviendo a mi situación particular, la empresa nos permitió traernos los monitores, las sillas ergonómicas o cualquier cosa que pudiéramos necesitar. En cuestión de dos días, desmantelamos las oficinas y nos las llevamos a casa. Sé de muchas empresas que ofrecieron un “paquete básico” de Home Office en los mismo términos.

Pero también me consta que muchas empresas, sobretodo las más pequeñas, no pueden permitirse una inversión para remotizar a sus trabajadores. Tengamos en cuenta que en España el 97,23% del total de empresas son PYMES con menos de 10 empleados. Quizás sean estas PYMES las que saldrían más perjudicadas de la inversión a la que la nueva ley del teletrabajo les podría obligar.

Otros elementos opcionales

• USB-drive o Disco duro externo: por seguridad muchas empresas recomendarán a sus empleados almacenar los datos sensibles en un disco duro externo que después de la sesión ha de ser guardado bajo llave. Esto forma parte de las políticas de seguridad contempladas por la RGPD. Si esta medida forma parte de la política de seguridad de datos, deberán proveer el disco duro y los elementos de seguridad adicionales. De igual forma, puedes crear USB personalizados en la web de Maxilia.
• Docking station: este dispositivo permite conectar el ordenador portátil a nuestros periféricos (monitores, teclados, cables de Internet, etc) de forma que podamos organizar mejor nuestra estación de trabajo en casa y trabajar con mayor comodidad, como si se tratara de una estación de sobremesa. 
• Conexión VPN: aunque este es un elemento “software”, algunas empresas requerirán el uso de VPN para trabajar desde casa, lo cual también podría suponer un gasto adicional para aquellas empresas que no estén preparadas.
• Licencias de Zoom, Slack o similares: las aplicaciones de videoconferencia y mensajería profesional se están haciendo de oro en esta época. Las opciones premium incluyen una mejor calidad de videollamada, número de usuarios, sin límites de tiempo (con Zoom, por ejemplo, cada sesión gratuita está limitada a 40 minutos), etc.

De todo esto, ¿qué están las empresas obligadas a proveer o pagar?

Hasta hace unas semanas, en España no había leyes que regularan la actividad del teletrabajo. Sólo existía una mención muy por encima en un artículo del Estatuto de Trabajadores. Básicamente decía que el trabajo en remoto tiene la misma consideración que el trabajo ejecutado físicamente en la empresa.

Por suerte para los trabajadores (y quizás por desgracia para muchas empresas pequeñas ) el Ministerio de Trabajo ha puesto en marcha la llamada ‘Ley de Trabajo a Distancia’ del 29 de septiembre, que regulará las nuevas condiciones del teletrabajo. En esta nueva ley se contempla un “mecanismo de compensación de todos los gastos, directos e indirectos, que pudiera tener la persona trabajadora por el hecho de prestar servicios a distancia“.

En concreto, los artículos 11 y 12 de la Ley del Teletrabajo determinan por un lado que el “derecho a la dotación suficiente y mantenimiento de medios, equipos y herramientas” y “el derecho al abono y compensación de gastos”.

Lo que esta ley viene a decir es que la empresa debe hacer frente a los gastos de material, equipo y servicios para que el trabajador pueda desarrollar su actividad laboral. 

¿Se consideran gastos de empresa los suministros del hogar como Internet o electricidad?

Sí, según la nueva ley estos formarían parte de los servicios para desarrollar la actividad laboral. La cuestión es que los suministros del hogar también son de uso privado, por lo que todavía se debe concretar (quizás a través de convenio) si:

• a) se hace un ingreso al trabajador total, o
• b) sólo por la proporción destinada a uso laboral como reembolso libre de impuestos.

Queda por ver la forma en la que la empresa abonará ese gasto, si en rendimientos del trabajo o en especie; por adelantado o a posteriori, etc. Si opta por hacer un ingreso al trabajador, se podría entender como un reembolso, pero esto plantea otra pregunta:

¿Cómo tributar las compensaciones económicas por trabajo remoto en el IRPF?

Según los expertos, la respuesta todavía no está clara. Pero salvo que el uso sea exclusivamente laboral (que no suele ser el caso), habrá que pagar impuestos sólo por la parte proporcional al uso privado o particular que se hace. Es decir, si la empresa te reembolsa la factura completa de la luz o de Internet, sólo la parte dedicada a la actividad laboral estaría libre de impuestos.

Sin embargo, no hay certidumbre en torno al significado de “exclusividad” en el uso de Internet, luz o calefacción. ¿Cómo se mide el uso privado o uso laboral? ¿Cómo se calcula esta exclusividad cuando varios inquilinos de una vivienda hacen uso simultáneo de esos suministros cuando trabajan desde casa para diferentes empresas?

La nueva ley de teletrabajo se ha puesto en marcha en tiempo récord y a trompicones. Ahora queda ver cómo se resuelven estas incógnitas y los problemas particulares de su implementación. 

Lo único que sí está claro es que las empresas tendrán que tomarse en serio estas medidas. Y como consecuencia, hacer un cálculo de coste-beneficio que podría llevar al cierre de muchas oficinas.

La entrada Home Office: ¿qué gastos mínimos deberán cubrir las empresas? se publicó primero en BorrowBits.

El código y el negocio.

El barro y… el otro tipo de barro.

En esta guía rápida comparto los principios más efectivos y que más me han ayudado como Product Owner a la hora de trabajar con Desarrolladores en equipos pequeños y grandes.

No me quedo corto si digo que el 90% de los problemas entre ingenieros y managers suelen ser de Comunicación. Por eso, la mayor parte de mis principios para comunicarme con los ingenieros se apoyan en un compendio de los siguientes:

• transparencia,
• respeto y
• humildad.

El rol del PO suele acotarse como un “representante del negocio”. Pero tu éxito como PO depende mucho más de lo bien que seas capaz de relacionarte con tu equipo.

Esta breve guía está escrita para Product Owners, IT Managers y Project Managers, pero se la dedico de corazón a mi equipo actual de Ströer. Ellos me han enseñado mucho de lo que aquí comparto.

Principio #1: Los desarrolladores no trabajan para ti: tú trabajas para ellos.

Cada vez hay más empresas que se oponen a otorgar el título de “Product Owner” a sus product owners. La palabra “owner” (dueño) ya implica una jerarquía, una autoridad.

Pero nada más lejos de la realidad.

Sin el respaldo de tu equipo no eres nada.

Como PO, tu principal tarea es asegurarte de que se implementa exactamente lo que hay que desarrollar en el momento adecuado, de forma que se entregue valor lo antes posible. En última instancia, es el equipo de desarrollo quien va a implementar tu visión del producto.

Así que no confundas el mapa con el territorio.

Por muy bonitos que sean tus mockups, un PowerPoint no es el producto. El equipo es el que va a transformar tu PowerPoint en algo real.

Aunque exista un Scrum Master o un Agile Coach que proteja al equipo de tu “tiranía”, tú mismo debes tener ese mantra instalado: tú estás al servicio de tu equipo y no al revés.

Y por cierto: el hecho de que haya un Scrum Master para pararte los pies no te da permiso para ser un villano en cuanto éste se descuida. No vayas por ahí dando órdenes arbitrarias o delegando en ellos tareas que no son suyas.

Principio #2: Confía en las recomendaciones de los desarrolladores: ellos son los expertos.

Desde el punto de vista del Product Owner (incluso aunque tengas experiencia técnica) las cosas siempre parecen mucho más fáciles de lo que acaban resultando.

Tu trabajo como PO es definir “qué” y “cuándo”. El “cómo” es cosa del equipo de desarrollo. Y en cuanto a esto, el equipo técnico suele tener razón.

Sin embargo, siempre existen varias alternativas para un mismo problema. Si no crees en la solución propuesta, pide una explicación (de alto nivel) de los desafíos, pros y contras de cada alternativa. En caso de duda, tomad una decisión conjunta poniendo en equilibrio las prioridades del negocio, la estabilidad y la seguridad de la aplicación, la potencial deuda técnica, etc.

El roadmap no lo es todo. Despreciar el impacto futuro de la deuda técnica es como encerrar un cachorro de león en tu dormitorio y alimentarlo constantemente con carne cruda: en algún momento tú podrías ser parte del menú. Muchos proyectos fracasan por ignorar este fenómeno.

Si al CEO de tu empresa le urge esa funcionalidad y quiere liberarla a toda costa, explícale los riesgos a los que se expone; si es necesario exige una exención de responsabilidad para ti y para tu equipo.

A muchos managers de alto nivel les encanta decir “hazlo en plan MVP”, pero lo que en realidad quieren decir es “haz una chapuza para salir del paso”.

Una cosa que todavía me sorprende es que el equipo técnico siempre se preocupa más que el negocio por la calidad, incluso cuando tiene un impacto directo sobre los clientes.

Principio #3: Comparte la visión del negocio constantemente, aunque nadie te pregunte.

Un minuto de silencio por esas costosas features que al final nadie usa…

Es mejor resultar un pesado, a que se implemente algo que nadie necesita. Lo he comprobado un millar de veces: cuanto mejor entiende un desarrollador lo que hay detrás de una decisión de producto, más acertada será su implementación, más rápida y más libre de errores.

Invierte el tiempo que sea necesario en asegurarte que se comprende la necesidad de negocio que hay detrás, porque será justo eso: una inversión.

Comparte el roadmap de vez en cuando y tus intenciones para release a producción.

Simplifica cuando sea necesario. Algunos Product Owner tendemos a pedir más cosas de las que en realidad hacen falta. Asegúrate de que los requisitos sean desglosados en requerimientos más pequeños, y que estos a su vez sean simplificados y priorizados correctamente (técnica MoSCoW por ejemplo). El equipo de desarrollo tiende naturalmente a desarrollar todo lo que tú le pidas. A veces incluso más de lo que pides. Esto se conoce como Scope Creep, que es el terror de los PO.

Ayuda al equipo a ponerse siempre en el pellejo de los usuarios, y siempre se implementará lo correcto solo hasta donde es necesario.

Principio #4. Sé radicalmente transparente.

No necesitas entender todo lo que los devs hacen, pero ellos sí necesitan entender lo que tú haces. Sé transparente. Al tratar con desarrolladores, no les ocultes los problemas.

Soy consciente de que esto va en contra de la cultura de muchas empresas, sobretodo de las más jerárquicas. También es cierto que hay que proteger al equipo de la presión exterior…

Pero en mi experiencia, si alguna circunstancia les afecta a ellos de forma directa o indirecta, no debes ocultarla. Primero, porque merecen saber lo que se cuece; y segundo, por lo mismo que comentaba en el Principio #3. Si los desarrolladores comparten tu comprensión de la realidad, te ayudarán a solucionar cualquier problema que se ponga por delante.

Aunque eso suponga romper algunas reglas.

Y desde dentro:

Si hay conflictos internos, no los evadas.

Si hay que mantener una conversación difícil, no la postergues.

En otras ocasiones resulta útil abandonar el modo “proxy”, e invitar a los técnicos a las reuniones con ciertos Stakeholders. Asegúrate de que todas las personas involucradas asisten a todas las reuniones. Esto es especialmente importante cuando se trabaja en remoto.

Si recibes halagos de los usuarios, de los clientes o de los stakeholders, transmíteselos al equipo y procura que se sientan dueños de esos triunfos. Si recibes críticas negativas, compártelas también; pero después de que tú hayas asumido la responsabilidad absoluta.

En última instancia y de cara a los clientes/usuarios tú eres responsable del éxito o del fracaso de tu producto. 

Principio #5: Sé exigente.

Espera la excelencia para obtener resultados excelentes (efecto Pigmalión). Pero eso sólo funciona cuando tú mismo persigues la excelencia en lo que haces: es una carretera de doble sentido.

Dale a tu equipo lo mismo que esperas de ellos.

Pon las expectativas bien altas.

Sé claro también con las expectativas individuales de cada uno. Ayúdalos a dar lo mejor de sí. Por tu parte, cúrrate las historias de usuario y el backlog como si se te fuera la reputación en ello. Testea la aplicación concienzudamente y sé despiadado con los resultados.

Si una entrega no cumple tus expectativas, recházalo. No tienes por qué (y no debes) liberar nada de lo que no estés absolutamente convencido.

No se trata de herir sentimientos:

Si no has comunicado bien un requerimiento, asume la responsabilidad. Lo normal es que sea un fallo de comunicación del Product Owner o del Business Analyst. Asegúrate de que el equipo comparte tu definición de “terminado” (Definition of Done). Ése es tu mejor seguro antipatinazos.

Pero si al final algo sale mal, no le eches la culpa al DevOps, ni al Backend, ni al Frontend, ni al QA.

Es culpa tuya y punto.

La próxima vez, asegúrate de que el equipo cubra esa debilidad, y sobretodo de que todos aprendan de esos errores (para eso están las Retrospectivas). Lo único malo de los errores es no aprender de ellos.

Los errores son oportunidades de mejora que nadie debería dejar pasar.

Principio #6: No te entrometas demasiado: el micromanagement es de perdedores.

En la medida de lo posible, no asignes tareas. Permite al equipo decidir quién hace qué. Ellos están más capacitados que tú para ver quién va a ser más eficiente con cierta actividad.

Sin embargo asegúrate de que al final siempre haya un responsable: si todos son responsables, al final nadie lo es. Y la tarea se quedará sin hacer.

Aplica el micromanagement sólo en casos de emergencia extrema, en plan “se está quemando el edificio”.

Por lo demás, deja que el equipo resuelva sus propios problemas de organización, aunque algunos de ellos te lo pidan (los desarrolladores principiantes o inseguros prefieren que el PO les diga lo que tienen que hacer). Incentiva la proactividad y la autonomía.

Dale responsabilidad a tu equipo, y entonces tanto ellos como el producto empezarán a brillar.

No te olvides de que un programador es una persona, no una máquina. A menudo 2 + 2 no es igual a 4, sino a 3. Esto es tanto más cierto cuanto más complejo es el producto. Es un error clásico que cometen muchos managers cuando planifican “recursos”.

Dicho sea de paso: una vez empieza el desarrollo de una tarea, no la detengas para empezar otra más urgente. Los cambios repentinos de contexto exigen un gran esfuerzo mental.

Compréndelo: desarrollar código es un arte. Y todo arte necesita su espacio para prosperar. No presiones. No te metas en los detalles técnicos aunque te guste (especialmente si te gusta).

¡Tú a lo tuyo!

Principio #7: Las estimaciones no son más que eso: estimaciones.

He comprobado que los desarrolladores son por naturaleza optimistas.

Cuando un desarrollador te dé una estimación, aplica un buffer de contingencia del 20-30%. Si es junior puedes incluso permitirte un 50%. Nunca culpes a un desarrollador de haber tardado “más de lo estimado”. Anima en cambio a que se comunique lo antes posible una subestimación/sobrestimación.

No preguntes constantemente cuánto falta para acabar.  Si un ticket tarda más de la cuenta en salir, asegúrate de que el desarrollador no se ha topado con algún impedimento.

Un story point nunca es el mismo story point. Cada feature puede ser un mundo. Aunque muchos desarrolladores se oponen a ello (especialmente los más senior), las estimaciones de las historias de usuario son útiles para el negocio: permiten planificar la liberación de software con una mínima sensación de certeza.

A algunos desarrolladores no les gusta estimar tickets por otras razones: puede percibirse como una herramienta de control del desempeño. Pero como Product Owner, nunca deberías usar las estimaciones para medir la velocidad individual.

El desarrollo de Software es un mundo VUCA (volátil, incierto, complejo y ambiguo), y el Product Owner debería sentirse cómodo con dosis elevadas de incertidumbre: he aquí la diferencia fundamental con un Product Manager tradicional.

Tanto tú como el equipo deberías tener claro que:

Una estimación no es una promesa, sino una forma heroica de planificar lo implanificable.

Principio #8: Disfruta del refinamiento de requisitos.

Si tú no te lo pasas bien en los refinements, el equipo tampoco.

Emociónate con los problemas, participa y sigue con atención el debate. Fomenta la discusión constructiva. No te distraigas y mantén tu presencia. Asegúrate que tus requerimientos se pueden dividir en unidades que no duren más de tres a cinco días (o el equivalente en story points, talla, etc). Si son demasiado grandes, pártelo todavía más (siempre se puede partir un poco más).

No fuerces la estimación cuando los requisitos no están claros. Es mejor abortar una sesión en la mitad y decir: “Lo siento, necesito averiguar más detalles sobre esto“.

Nunca supongas: vuelve al mundo real y comprueba.

Así evitarás los infames “change requests”, sobretodo si ocurren de forma constante para una misma feature. Los cambios de requisitos constantes y al vuelo (en los ticket que ya están en progreso) son una fuente de frustración para todo el equipo.

No te aferres nunca al camino feliz (happy path).

Si algo puede salir mal, saldrá.

Murphy nunca se debería perder un refinement.

Valora y premia la detección temprana de posibles “corner cases”. Prepara el material con antelación y exige que los desarrolladores lo lean antes de la sesión: mockups, ejemplos, contexto… Cuanta más información se aporte desde un principio mejor.

Y por el amor de $deity: refinar historias de usuario consume mucha energía, ¡no pongas esas reuniones después del almuerzo!

Principio #9. Siéntete parte del equipo.

Mójate en las retros, bájate del pedestal (si es que crees que estás en alguno).

Comparte tu opinión honesta y ábrete a las críticas de mejora, especialmente si no te gustan.

Nunca te lo tomes como algo personal.

Da igual si eres el dueño del producto: en el día a día formas parte de un equipo. Unas veces serás parte de la problemática y otras veces parte de la solución.

Celebra las victorias con ellos, acompáñalos en las releases difíciles. Trabaja cerca del equipo en el día a día: no te evadas demasiado en el “business”. Intenta estar siempre disponible para el equipo para resolver dudas (sí, sé lo difícil que es esto).

Habla cara a cara siempre que puedas. No olvides tomarte un café con el equipo de vez en cuando.

Eres el puente entre el mundo de las corbatas y el mundo de las camisetas geeks. Y la programación es una actividad intelectual que se parece más al arte que a la mecánica.

Así que trata a los Artistas con el máximo respeto. 

La pregunta “cómo gestionar un equipo de desarrolladores” está mal planteada; en lugar de eso céntrate en cómo tratar con las idiosincrasias de las personas. Más allá de las apariencias y los estereotipos. He visto a otros PO hablar de su equipo con desprecio y autosuficiencia. No seas uno de esos capullos condescendientes.

Y hablando de eso:

No hay nada más condescendiente que un Product Owner regalándole a un Desarrollador un libro sobre cómo programar mejor, o más rápido, o cualquier otra cosa insultante… No hagas ese tipo de cosas. 

Los principios del buen Product Owner: cómo trabajar con desarrolladores

Reflexioné mucho antes de atreverme a publicar este post.

Después de todo, ¿con qué jeta se me ocurre dar consejos cuando yo mismo todavía no los aplico a la perfección?

Creo que no es fácil ser un buen Product Owner.

Requiere la capacidad incesante de encontrar compromisos, a menudo irreconciliables. Es un rol de malabarista solitario que sobrevive en la frontera de varios mundos y submundos. Un PO debe resistir bien la presión sin pasársela al equipo. La palabra más importante de su vocabulario es “No”.

Llegar a ser un buen Product Owner es un work in progress constante, algo así como la aspiración al Nirvana. Un reto casi imposible. Y así con todo, un deber moral.

¿Entonces por qué publico estos principios?

Pues simplemente, porque me habría gustado que alguien me contara cómo trabajar con desarrolladores en mis comienzos. Muchas de estas cosas no las aprenderás en un cursillo de Udemy ni sacándote el PSPO I.

Así que si estás empezando y tienes que quedarte con una sola enseñanza, quédate con ésta: la comunicación es tu herramienta más importante.

Un Product Owner puede llegar a ser tan bueno, como buena sea su comunicación con su equipo. 

Por último, estos principios no están grabados en mármol. Son más bien un borrador perpetuo, y lo iré afinando conforme aprenda nuevas lecciones. De hecho, si tienes otros principios útiles basados en tu experiencia (ya sea como desarrollador o como product owner) que no he tenido en cuenta, escríbeme un comentario

¡Un saludo!

La entrada 9 Principios Efectivos para Trabajar con Desarrolladores. Guía del Product Owner se publicó primero en BorrowBits.

Hace unos días superé con éxito el examen de certificación (968/1000), así que el propósito de este artículo es daros algunos datos basados en mi experiencia que os pueden servir de ayuda.

¿Cómo es el examen?

• El FAQ de la certificación de AWS
• Listado de los principales servicios que debes de conocer para esta certificación de TutorialsDojo

Cursos recomendados:

• A Cloud Guru – AWS Certified SysOps Administrator – Associate 2020
  Fue el curso que hice ya que me lo pagó mi empresa, aborda los conceptos principales y de forma básica, pero no es suficiente. Te da una buena base de conocimiento y hace muchas demos prácticas usando AWS Console, pero necesitas hacer preguntas de exámenes para completar la formación, como veremos más adelante.
• Stephane Maarek – Ultimate AWS Certified SysOps Administrator Associate 2020
  Tengo muy buenas referencias sobre este curso, es más completo que el anterior pero su precio también lo es. En Udemy suelen salir ofertas para conseguirlo mucho más barato.
• Linux Academy – AWS Certified SysOps Administrator – Associate (SOA-C01)
  Curso muy completo, extenso y tiene la particularidad de que puedes disponer de una cuenta en AWS para aplicar la teoría aprendida. Probablemente la opción más didáctica de todas.
• Vídeos de re:Invent de AWS en Youtube.
  AWS tiene una colección de vídeos muy interesantes que explican en detalle sus servicios.
• La documentación oficial de AWS para indagar en aquellos servicios en los que tengas más dudas, creo que para profundizar es la mejor fuente.
• Puedes encontar cursos gratuitos en Youtube sobre SysOps Administrator.

Apuntes de teoría:

• SkullTech – AWS Solutions Architect Associate Notes
  A pesar de ser para la certificación de SAA-C02, muchos de los contenidos se solapan.
• John Kevin Losito – AWS SysOps Administrator Review Notes
  Esquema de los conceptos que abarca la certificación.
• TutorialsDojo – AWS Cheat Sheets
  Muy buena página donde aparecen todos los servicios de AWS explicados de forma sencilla.

Exámenes para practicar

• Jon Bonso – AWS Certified SysOps Administrator Associate Practice Exams
  Son de pago. Yo no los hice, pero los recomiendan en los foros, son parecidos al examen oficial.
• ExamTopics.com – AWS SysOps
  Esto debe ser OBLIGATORIO si quieres aprobar. Muchas preguntas del examen oficial aparecen aquí. Cuidado, muchas respuestas que aparecen por defecto están mal, mira el apartado de discusiones sobre cada respuesta para saber cuál es la correcta y analiza los enlaces relacionados con la documentación de AWS donde se explica.
• VCEGuide.com – AWS SysOps
  Es un backup de ExamTopics, no tiene las respuestas con discusiones y explicaciones, pero puede valer si ExamTopics está caída.

¿Cómo prepararlo?

Depende mucho de tu experiencia previa con AWS y del tiempo que quieras dedicarle para aprender más. Te puedo comentar bajo mi punto de vista qué es lo mínimo que deberías de hacer:

• Si tienes varios años de experiencia y ya conoces muchos de los servicios que aborda el examen, probablemente con leer las notas de teoría y hacer los tests de ExamTopics es suficiente.
• Si tienes poca experiencia, mejor haz un curso, practica en la AWS Console y haz los exámenes de ExamTopics.
• Si eres nuevo en AWS, recomiendo primero hacer el curso oficial de AWS Certified Cloud Practitioner para tener una visión global de todos los servicios, luego hacer algún curso enfocado a la certificación de SysOps y finalmente hacer exámenes de ExamTopics.

A todos estos pasos añade más cursos, vídeos, lecturas de la documentación oficial, etc que complementen lo aprendido. Recuerda que lo importante es el camino que recorres hasta aprobarlo, eso es lo que realmente te enriquece.

En mi caso particular, trabajo a diario con AWS y muchos de los servicios ya los conocía. Me preparé el curso de A Cloud Gurú, usé mis propios apuntes y los complementé con los del listado y realicé (entendiendo bien) las preguntas de ExamTopics leyendo la documentación oficial de AWS relacionada con ellas.

¡Mucha suerte!, deja en los comentarios las dudas que tengas, fuentes interesantes de conocimiento relacionadas con la certificación o comentarios sobre tu propia experiencia.
Me despido con una frase:

“El placer más noble es la alegría de entender algo.” – Leonardo da Vinci

La entrada Cómo aprobar la certificación AWS SysOps Administrator Associate [SOA-C01] se publicó primero en BorrowBits.

Criterio 1: Funcionalidad

Existe cierta confusión en cuanto a las funcionalidades que puede realizar una TPV. Lo más importante a la hora de elegir un sistema es que “haga” lo que realmente necesitamos. He aquí algunas de las operaciones que puede realizar una TPV:

• Inventario de productos.
• Control básico de clientes (CRM).
• Realizar operaciones de venta.
• Pasarela de pago online.
• Impresión de tickets y facturas.
• Automatización de pedidos.
• Gestión de devoluciones.
• Integración con otros sistemas.

Por ejemplo, si lo único que necesitas es una pasarela de pago para que tus clientes puedan pagar con tarjeta de crédito, un simple datáfono de toda la vida bastará. Algunos bancos ofrecen sus propios datáfonos digitales de forma gratuita (si bien se cobrarán su costo en comisiones de venta, por supuesto).

Si además quieres gestionar pagos de forma completa, llevando contabilidad de todo tipo de cobros y además actualizando el inventario, imprimir recibos y gestionar devoluciones, necesitarás un sistema mucho más avanzado con un software adecuado.

Criterio 2: Tipo de negocio

No es lo mismo el TPV que necesitaría una panadería de barrio, que el que necesitarían unos grandes almacenes con 20 puntos de venta interconectados. Tampoco es lo mismo el TPV que necesitaría una tienda online:

• Para pequeñas empresas el TPV puede consistir en un datáfono o en un simple PC adaptado con una pantalla táctil, lector de tarjetas, impresora y periféricos. Este tipo de TPV se vende en paquetes y suele incluir un software básico de gestión de ventas que es suficiente para este perfil.
• Para grandes empresas con múltiples puntos de venta, lo más importante no es tanto el TPV físico como el software. En estos casos cabe considerar soluciones Cloud que aseguren una alta disponibilidad, seguridad y sincronización de datos. También es posible que necesites integración con otros sistemas corporativos (Salesforce, SAP, HubSpot…) por lo cual pueden llegar a necesitar un desarrollo a medida. Si necesitas asesoramiento sobre aplicaciones TPV a medida, puedes consultarnos aquí de forma gratuita.
• Para negocios o tiendas online (e-commerce) puede que no sea necesario ningún hardware en absoluto (salvo los servidores de tu proveedor), pues lo único que necesitarás es una plataforma web como WooCommerce, Prestashop y similares. Éstas se puede integrar fácilmente con PayPal, pasarelas bancarias e incluso con pasarelas de pago con bitcoins.

Criterio 3: Presupuesto

Más allá de las necesidades de tu negocio, lo que más va a determinar la compra de un TPV u otro va a ser el presupuesto. Tanto si el TPV es físico o totalmente virtual, los costes pueden ir de “cero euros” hasta “todo lo que te puedas gastar”.

La opción más económica (pero más problemática)

La opción más barata es adquirir un software TPV “open source”, que a menudo son totalmente gratuitos y están mantenidos por una amplia comunidad (si os interesa podemos hacer otro artículo sobre esta opción).

A partir de ahí puedes comprar todos los dispositivos que vayas necesitando: impresora de tickets, lector de tarjetas, lector láser, etc. Esta opción tiene el molesto inconveniente de necesitar bastante trabajo técnico, desde la instalación hasta su mantenimiento. Por tanto, en algún momento vamos a necesitar una persona con los conocimientos técnicos para que nos dé el soporte necesario.

La opción deluxe

Existen soluciones TPV que no sólo incluyen completos sistemas físicos, sino también software de gestión de inventario, clientes y ventas, con base de datos compartida en la nube, backup periódico automático y soporte 24/7. Estas soluciones suelen proveerlas empresas especializadas mediante contratos SaaS (Software as a Service) y un contrato de compra o alquiler de los equipos físicos.

Otras opciones económicas

El mejor balance en prestaciones-precio suele ser un pack TPV completo que incluya todo el hardware y el software necesario. Para un negocio que está empezando, la compra de su primer TPV puede suponer una fuerte inversión. Sin embargo, el mercado de segunda mano puede ayudar a ahorrar dinero. Los TPV por lo general sufren poco desgaste, pues sus sistemas trabajan con poca carga computacional y los periféricos físicos suelen ser bastante duraderos. Con el tiempo, las impresoras sí son más susceptibles de problemas (en general todos los dispositivos con partes móviles). Pero después de todo, estos son dispositivos económicos y fácilmente reemplazables.

A modo de conclusión

En cuanto a la elección de un TPV no hay una respuesta genérica que sea válida para todos los perfiles. Todo va a depender de las necesidades y presupuesto de cada negocio. Por suerte, existe una amplia variedad de configuraciones, modelos y opciones de compra. Además puedes comenzar con un paquete básico e ir ampliando sobre éste según vayas descubriendo tus necesidades particulares.

No dudes en contactar con nosotros o escribirnos un comentario si necesitas asesoramiento sobre la mejor opción para tu caso.

La entrada ¿Cómo montar un TPV en mi negocio ? Una guía de compra. se publicó primero en BorrowBits.

Pero, ¿acaso nunca se les ha puesto la carne de gallina la capacidad predictiva de Gmail mientras redactan un correo?

El argumento principal que sostiene el autor es que los computadores son estadistas bobos. Pueden predecir con bastante precisión lo que vas a escribir; antes incluso de que tú mismo sepas cómo vas a terminar la frase. Pero eso no significa que tengan capacidad para “escribir” como una persona lo haría.

A día de hoy la escritura automática se limita a un simple cálculo, basado a su vez en un modelo estadístico, entrenado por los emails que otros miles de seres humanos han tecleado.

Nada nuevo bajo el sol.

“Nada, que un escritor o un periodista humano deba temer… “

¿Podemos afirmar eso de forma tan categórica? En mi opinión es demasiado pronto para cantar victoria…

La automatización que subyace bajo la temida Cuarta Revolución Industrial traerá consigo desempleo y desigualdad como nunca hemos conocido. Los primeros en caer serán los trabajos repetitivos para los que una máquina está mucho mejor capacitada. Cajeros de supermercado, conductores de camiones y taxistas, servicios de atención al cliente…

Los últimos en caer serán esos trabajos que requieran habilidades para las que las máquinas todavía son torpes:

Todos aquellos que requieran, entre otras cosas, creatividad e inteligencia emocional…

Como, por ejemplo, escribir una novela.

2049: ¿El primer ordenador con demonios?

Según un reciente artículo del World Economic Forum, se espera que en 2028 una máquina sea capaz de componer un éxito de los 40 principales. Y para 2049 escribir un best-seller del New York Times.

Es cierto que el contenido de estas obras no suele estar a la altura de Brahms o Shakespeare. Pero sí es algo sobre lo que deberíamos detenernos a reflexionar. Que una máquina pueda conmover a un ser humano, intencionadamente o no, es un avance inaudito en el hasta ahora antropocéntrico terreno de la creatividad.

Con tal horizonte a la vista, es una cuestión de tiempo que una máquina desarrolle adicción al whiskey barato y demonios de escritor…

Escribir con propósito

Otro argumento que debería tranquilizar a los escritores profesionales vendría a ser el siguiente: para escribir de verdad se ha de tener algo que decir. Así lo expresa Johnson en su artículo:

Los ordenadores no tienen [nada que decir]; esperan instrucciones. Dada una entrada, proveen una salida. Tales sistemas pueden ser alimentados con un tema o con los primeros párrafos, y decirle que “escriba”. Puede que el resultado sea gramaticalmente correcto, pero esto no debe confundirse con un resultado intencional.

Johnson: Don’t fear the Writernator – The Economist (traducción libre)

Según el autor, una máquina “nunca escribirá con propósito”. Pero creo que aquí vuelve a pecar de optimista, pues el propósito de una máquina es, valga la redundancia, servir al propósito para el que ha sido construida.

Quizás esto les recuerde a aquella escena de The Matrix: Reloaded en la que Mr. Smith, un programa de inteligencia artificial, disertaba así acerca del propósito:

Propósito fue lo que nos creó… propósito lo que nos conecta, propósito lo que nos impulsa, lo que nos guía, lo que nos controla, es el propósito lo que define, propósito lo que nos une. Estamos aquí por culpa suya, señor Anderson. Estamos aquí para quitarle lo que trató de quitarnos a nosotros ¡Propósito!

Preguntas más allá de la Singularidad

Una de las claves de la Singularidad Tecnológica es precisamente ésa: todavía no sabemos cuáles serán los propósitos que las máquinas podrían desarrollar por sí mismas.

Y he aquí, por tanto, el meollo de las preguntas que un servidor quería plantearles a ustedes: ¿Qué pasará cuando no logremos diferenciar entre un ensayo publicado por un humano y uno “generado” por una máquina? ¿Qué pasará cuando dejemos de controlar los propósitos que las animan a escribir? Y aún: ¿qué pasará cuando las máquinas sí tengan algo que decir?

¿Quieres aprender sobre Inteligencia Artificial? Échale un ojo a estos libros gratuitos de la editorial Springer. 

La entrada Cuando las máquinas tengan algo que decir se publicó primero en BorrowBits.

Bienvenidos pues, al número 11 de esta sección: los 5 bits de julio.

BIT #1: ¿Qué ando viendo, leyendo y/o escuchando?

Viendo: “Rick & Morty” no es sólo otra serie irreverente americana de dibujos animados. Aunque los guiños científicos están a la altura de Futurama, los personajes son (neuróticamente) más reales, el relativismo moral más limítrofe, y por último, intercala eructos con cuestiones existencialistas que se quedan flotando en tu cerebro como publicidad subliminal…

Leyendo: Las 48 leyes del poder, de Robert Greene. Libro de cabecera de Fidel Castro, de presos estadounidenses y de raperos ex-narcotraficantes. Se trata de una guía para conseguir y mantener poder. Su contenido “maquiavélico” me pone la carne de gallina. Para que sepáis de lo que hablo, aquí algunas muestras:

• Ley nº 21- Finja candidez para atrapar a los cándidos: muéstrese más tonto que su víctima
• Ley nº 27- Juegue con la necesidad de la gente de tener fe en algo, para conseguir seguidores incondicionales
• Ley nº 38- Piense como quiera, pero compórtese como los demás

Sin embargo que estemos o no de acuerdo sobre cómo funcionan las cosas, no cambia que sean como son. Conocer esas leyes deberían ayudarte, como mínimo, a protegerte del abuso de poder.

Escuchando: Millencolin. El buen skate punk nunca pasa de moda. Y si has jugado alguna vez a los “Tony Hawk Pro Skater” en la Play Station reconocerás que es así. Estos días he escuchado mucho de este género: the Offsprings, Blink182, Greenday… y especialmente los suecos Millencolin. Después de casi 30 años siguen activos, así que no pierdo la esperanza de verlos alguna vez en directo.

BIT #2 ¿Qué truco de productividad estoy practicando? 

“Modelo de Seis Niveles” Uno de los mejores libros de productividad que se han escrito nunca es el “Get Things Done” de David Allen. El sistema GTD clasifica nuestros objetivos en “plazos”, que podemos observar desde diferentes altitudes: las acciones forman parte de proyectos, los proyectos de responsabilidades, las responsabilidades de metas, las metas de una visión, y la visión parte de un propósito vital. La revisión periódica de este modelo te permite controlar la dirección de tu vida: como si fueras el piloto de un avión.

Estos son los niveles, desde más cerca del suelo a más alto:

• Nivel 1 = Pista de aterrizaje – Acciones
  Las cosas que tienes diariamente en tu lista de quehaceres: llamadas de teléfono, reuniones, etc.
• Nivel 2 = 3.000 metros – Proyectos
  Los proyectos dentro de los cuáles las acciones se enmarcan: limpiar la casa, comprar un PC nuevo o planificar unas vacaciones, por ejemplo.
• Nivel 3 = 6.000 metros – Responsabilidades
  Las responsabilidaes dentro de la cuál se enmarcan tus proyectos: siguiendo los ejemplos anteriores, “mantenimiento de la casa”, “desarrollo de una aplicación nueva”, “hacer felices a tus hijos”, etc
• Nivel 4 = 9.000 metros – Metas (de 1 a 2 años) Metas a medio plazo: qué esperas conseguir en tus áreas de responsabilidad en los próximos 1-2 años.
• Nivel 5 = 12.000 metros – Visión (de 3 a 5 años)
  Este nivel es tu visión: transiciones en tu carrera profesional y cambios familiares y económicos a largo plazo.
• Nivel 6 = 15.000 metros o más– La Vida
  ¿Por qué estoy aquí? Esta es la pregunta más importante de todas y también la más difícil de responder. La respuesta es tu propósito.

BIT #3 ¿Qué ando imprimiendo en 3D? 

Clips para cerrar bolsas.  Hay raras ocasiones en las que consigo imprimir algo de utilidad práctica. Ésta es una de ellas: los clips para cerrar bolsas escaseaban en casa y descargué un modelo de Thingiverse que incluye clips de varias dimensiones. Este modelo es compatible con PLA (la mayoría de los modelos que hay por ahí sólo funcionan con ABS). La genialidad de esta pieza es que consta de dos partes móviles que se imprimen ya ensambladas. Para ello la impresora debe estar muy bien calibrada. Mi make lo he posteado aquí.

BIT #4 ¿Qué app me está cambiando la vida esta semana?

Anti-Adblock Killer . Descubrí este “script” el otro día en el artículo de Enrique Dans “Bloqueando al que bloquea al bloqueador“.

“Los ad-blockers nacieron para que los usuarios pudiésemos evitar la publicidad en las páginas web, y los anti-adblockers surgieron para que las páginas pudiesen reconocer que el usuario tenía un ad-blocker instalado y le conminasen a deshabilitarlo para acceder a sus contenidos, ahora aparecen los anti-adblocker-blockers o anti-adblocker killers, que permiten a los usuarios mantener sus ad-blockers activos y funcionando cuando algún sitio les exige que los deshabiliten“.

En mi opinión, las plataformas de contenido tienen tanto derecho a mostrar publicidad como los usuarios a evadirla. Lo contrario es como si estuvieras mirando la TV en tu casa y cuando llega el momento de publicidad te encadenaran al sofá y te forzaran los párpados con cinta aislante.

BIT #5 ¿Qué cita ando ponderando?

Tanto si crees que puedes como si no, tienes razón

― Henry Ford

La entrada Los 5 bits de Ángel (XI): Poder, límites y skate punk se publicó primero en BorrowBits.

Viendo: Maniacs (2018). Dos desconocidos, Annie y Owen, se ofrecen voluntarios para una prueba farmacéutica que promete curar para siempre sus problemas mentales (esquizofrenia en el caso de él, y ella borderline). El tratamiento consiste en una serie de alucinaciones inducidas y controladas por una Inteligencia Artificial. Todo va bien hasta que la computadora se deprime profundamente y empieza a comportarse de forma algo… maníaca.

Leyendo: Aprendiendo de los mejores 2. El primer volumen ya me pareció una joya de sabiduría comprimida, pero el segundo creo que ha superado al primero. Se trata de una recopilación, filtrada y masticada por Francisco Alcaide, de las reflexiones de diversas celebridades que han alcanzado algún tipo de excelencia: Michael Jordan, Muhammad Ali, Ray Kroc, Walt Disney, Onassis, Coco Channel, Eckhart Tolle… Empezar el día escuchando este audiolibro de camino al trabajo ha sido una verdadera inyección de motivación. Puedes encontrarlo aquí.

Escuchando: Retrowave / Synthwave. Creo que no es la primera vez que menciono este género musical en esta lista de bits. Sí, mi semana está muy retro-futurista… Concretamente he descubierto esta playlist de Spotify con la que he estado trabajando en beast-mode: https://open.spotify.com/playlist/37i9dQZF1DXdLEN7aqioXM?si=9RjSZv11TiGxKuXVxwyWeA

Por lo demás, este videoclip en 8-bits no tendrá desperdicio para los amantes del retrowave:

BIT #2 ¿Qué truco de productividad estoy practicando? 

Decir “no” (más a menudo). Hay una comedia de Jim Carrrey llamada “Yes man“. Su moraleja es que cuando dices que sí a todo, acaban pasándote cosas maravillosas. La película es divertida, pero en mi opinión envía un mensaje equivocado. Porque si dices que sí a todos, las prioridades de los demás acaban siendo más importantes que las propias. ¿Y qué puede ser más perjudicial para tu productividad?

Para muchas personas, decir que no puede ser más difícil de lo que parece. No sólo porque estamos condicionados para ser siempre amables, sino porque tememos ser percibidos como egoístas y perder el aprecio de los demás.

Pero hay una respuesta mucho peor que un “no” honesto: un “sí” a regañadientes.

En el largo plazo, esa clase de síes no sólo aniquilan tus propias metas, también acaban por intoxicar tus relaciones con los demás debido a frustraciones y resentimiento acumulados.

Y en mi caso, creo que aún no lo digo lo suficiente. Esta semana me gustaría compartir algunas fórmulas elegantes para declinar una petición / oferta / invitación:

• El sandwich (positivo | negativo | positivo) “Eso suena genial, pero estoy ocupado hasta [fecha]. Si te parece bien, lo hablamos a partir de ese día”.
• El semáforo
  “Gracias por tenerme en cuenta, pero no puedo hacer [petición] , mientras siga trabajando en [proyecto]” .
• El sandwich servicial  
  “Gracias, pero no puedo. ¿Puedo ayudarte a encontrar una alternativa?”
• Sin explicaciones
  “Ojalá pudiera, pero ahora mismo es imposible. Gracias por pensar en mí”.

BIT #3 ¿Qué ando imprimiendo en 3D? 

Desatascador de frigorífico.  Las neveras/refrigeradores suelen drenar el agua sobrante a través de un pequeño orificio en su parte inferior. El agua cae en un depósito, donde se va evaporando. Pero cuando dicho desagüe se atasca, el agua no consigue drenarse, e incluso puede derramarse al exterior.

Ése ha sido el caso de mi frigorífico esta semana… Así que me he puesto manos a la obra con un diseño en Fusion 360 de cosecha propia: una herramienta sin mucha ciencia que en pocos segundos permite eliminar cualquier obturación por trozo de lechuga…En el mango he impreso las palabras “fridge-tool” para 1) proporcionarle adherencia y 2) evitar que alguien lo use como palillo de dientes .

Podéis configurar el archivo STL y los parámetros de configuración en mi cuenta de Thingiverse: https://www.thingiverse.com/thing:3745190

BIT #4 ¿Qué app me está cambiando la vida esta semana?

Mi teléfono Gigaset GS270 Plus ha quedado prácticamente inservible en cuestión de un año. El problema de Gigaset, un fabricante de telecomunicaciones alemán, es que todavía no tiene mucha experiencia en fabricación de smartphones, y pagué el precio del conejillo de indias. Lo he reemplazado por un Huawei P30 nuevo. Sí, sé lo que dicen de Huawei. ¿Pero de verdad creéis que EEUU practica menos espionaje que China?

Phone Clone. Pero este Bit en realidad va de una aplicación que ha mejorado mucho mi vida esta seman: “Phone Clone“. Es una herramienta para hacer un back-up completo de tu teléfono antiguo. En su sencillez de uso, me parece una genialidad: sincronizas los teléfonos con un QR, seleccionas qué datos del teléfono antiguo quieres copiar, y en cuestión de 15 minutos está todo transferido: contactos, mensajes, registros de llamadas, calendarios, fotos, videos y ¡hasta te instala las mismas aplicaciones que tenías en el antiguo!

El único punto negativo es que no transmite los datos de estas aplicaciones: es decir, tendrás que loguearte de nuevo en todas ellas y perder datos temporales de aplicaciones.

BIT #5 ¿Qué cita ando ponderando?

El propósito del software es ayudar a la gente.

― Max Kanat-Alexander, Code Simplicity: The Fundamentals of Software

Una vez trabajé con un desarrollador de software a quien le había encargado solucionar un bug urgente en el entorno de producción. Después de unas horas me acerqué a él para averiguar si ya había conseguido resolver el problema. “Aún no“, me contestó, “pero acabo de desarrollar la mejor pieza de código que he escrito en mi vida“.

Cuando comprobé lo que había hecho, descubrí que se había alejado del problema original (parchear un bug urgente en producción) arrastrado por un interesante reto intelectual. En otras palabras: se estaba entreteniendo con una flor que había encontrado al borde del camino.

Por desgracia, esto pasa con mucha frecuencia en el mundillo dev, aunque seguro que también ocurre en otras industrias. Los puzzles de código, la metodología Scrum, las best-practices… Muchos programadores se pierden a veces en “el arte por el arte” y olvidan cuál es el verdadero valor de desarrollar una pieza de código: mejorar la vida de las personas. Pero a veces nos acercamos tanto a los árboles, que dejamos de ver el bosque.

La entrada Los 5 bits de Ángel (X): Nope, man! se publicó primero en BorrowBits.

BIT #1: ¿Qué ando viendo, leyendo y/o escuchando?

(re)Leyendo: Agile Product Management with Scrum, del legendario Roman Pichler. He aquí un libro que leo y releo de cuando en cuando. De hecho nunca abandona mi maletín de trabajo. La primera impresión cuando me llegó por Amazon fue decepcionante: esperaba algo más contundente. Pero doy fe de que sus 133 páginas contienen todo lo que un agile Product Manager necesita saber. También es útil para preparar el PSPO 1.

Viendo: Shaft (2019). Ésta ha sido una de esas semanas de trabajo que te fríen el cerebro y en las que sólo te apetece ver algo que no te haga pensar demasiado. Shaft es una de esas películas estúpidas para pasar el tiempo, con el aliciente de que sale Samuel L. Jackson. En esta peli interpreta a John Shaft, un detective privado irreverente y muy badass. Su hijo, por el contrario, es un milénial hípster que rechaza toda la incorrección política de su padre… al principio.

Escuchando: Manowar. Esta banda ha batido varias veces el récord Guinness del concierto más ruidoso (loudest performance) y también el concierto de heavy metal más largo de la historia (5 horas y un minuto). En 2017 tuve el privilegio de verlos en Múnich en su tour “The final battle”. Fue uno de los conciertos más épicos a los que he asistido jamás.

BIT #2 ¿Qué truco de productividad estoy practicando? 

¿Escuchar música afecta a la productividad? Esta vez más que un truco de productividad os traigo insights sobre cómo la música afecta a la productividad (creo que en este post estoy abusando de los anglicismos) . De varios estudios se desprende que las áreas del cerebro activadas por la música varían de persona en persona, en función de su educación musical y de las experiencias personales con la música. Por tanto, el cómo la música afecta a nuestra habilidad para concentrarnos depende de cada cuál. Pero, ¿qué dice la ciencia?

• En 1972, un estudio publicado por Applied Ergonomics sugería que la gente que hacía tareas repetitivas tenía mejor desempeño con música de fondo.
• En 1994 The Journal of the American Medical Association  concluyó que la eficiencia y precisión de los cirujanos mejoraba cuando sonaba música de fondo (esto lo he visto en alguna serie: cirujanos operando mientras escuchaban heavy metal).
• En 1999 un estudio publicado en la revista Neuroscience and behavioral physiology demostró que tocar música clásica o rock ayudaba a los participantes a identificar números de forma más rápida y precisa.
• En 2005 un estudio de la revista Psychology of Music  llegó a la conclusión de que los desarrolladores de software mostraban un mejor humor, mejor calidad en su código y mayor eficiencia cuando programaban escuchando música.

BIT #3 ¿Qué ando imprimiendo en 3D? 

Abrazadera regulable con tuercas. He disfrutado mucho imprimiendo y montando esta herramienta. Compuesta de 16 piezas en 3 colores de PLA, consiste en una abrazadera regulable con un diseño muy inteligente y del que tomo nota para algunos proyectos que tengo en mente. Tiene tanta fuerza que algunos brutos incluso la utilizan para picar cubitos de hielo. La impresión me llevó unas 8 horas en total. El diseño original aquí: https://www.thingiverse.com/thing:2403756

BIT #4 ¿Qué app me está cambiando la vida esta semana?

CodeCheck. Esta app móvil, que permite escanear el código de barras de cualquier producto (alimenticio o cosmético) para determinar su composición química y nutricional. Las sustancias aparecerán listadas y catalogadas según su impacto en la salud y en el medio ambiente. Os sorprenderá comprobar que muchos productos que se venden como “bio”, “ecológicos”, “fitness” y “light” pueden ser más dañinos para la salud que otros aparentemente menos saludables.

BIT #5 ¿Qué cita ando ponderando?

Tu estado de ánimo es tu destino.

Heródoto

¡Zasca! Vaya saco de responsabilidad personal nos echa el tío Heródoto sobre el lomo. Hay que permanecer vigilante con los estados de ánimo. Un pensamiento detrás de otro acaba definiendo quiénes somos. ¿Cómo funciona eso cuando sales de trabajar a las 7 de la tarde, te metes en un atasco y al llegar a casa no encuentras sitio donde aparcar…?

En realidad, lo que ando ponderando al leer la frase de Heródoto es lo siguiente: ¿cuál es el estado de ánimo correcto?

Un maestro Yoda en miniatura aparece levitando sobre mi hombro y responde así a mi pregunta: Eso depende, de qué destino alcanzar deseas.

Porque si no sabemos adónde queremos ir, tanto da un estado de ánimo que otro. Supongo que esa es la definición de “pusilánime”: del latín pusillus, que significa ‘pequeño’, y animus, que se traduce como ‘ánimo’ o ‘espíritu’; es decir, “pequeño de espíritu”. Así pues: una persona cuyo espíritu es pequeño jamás conseguirá lograr algo grande.

La entrada Los 5 bits de Ángel (IX): comprimiendo libros en la vida real se publicó primero en BorrowBits.

BIT #1: ¿Qué ando viendo, leyendo y/o escuchando?

Leyendo: “Pantaleón y las visitadoras“. Vargas Llosa vuelve a sorprenderme con una novela que le valió el Premio Latinoamericano de Literatura en 1975. En ella se sirve de la experimentación literaria que caracteriza su obra, saltándose desde el principio las reglas habituales del espacio, el ritmo y en general, del arte narrativo. La historia, basada en hechos reales, cuenta cómo el capitán Pantaleón Pantoja se ve obligado a ejecutar una complicada misión secreta para el Ejército: dirigir un servicio de prostitución para aliviar las necesidades de los soldados destinados a la Amazonía Peruana.

Viendo: “Ascension” (2014). Desgraciadamente, esta semana tampoco he acertado con la parte visual de este Bit. “En 1963, el gobierno de EEUU lanza una nave espacial para colonizar un planeta en Proxima Centauri. El viaje durará 100 años, por lo que solo los hijos y los nietos de los tripulantes originales llegarían a ver su destino. Sin embargo, en el año 51 desde la partida (correspondiente al presente), ocurre un asesinato a bordo de la nave que pone en tela de juicio la naturaleza de la misión“. Con un argumento con tanto potencial, ¿qué podría ir mal? Pues en mi opinión es un desastre cinematográfico: el guión parece un gazpacho de telefilmes baratos representado por actores mediocres. La historia aburre desde el principio… nunca llega a despegar (quienes la hayan visto entenderán el chiste).

Escuchando: “The last goodbye”, por Billy Boyd. Este tema forma parte de la banda sonora de “El Hobbit: La batalla de los cinco ejércitos” y es uno de los que nunca me canso de escuchar. Sí, soy muy pesado con las canciones de películas… ¿pero qué queréis que le haga? :)_

BIT #2 ¿Qué truco de productividad estoy practicando? 

TRABAJA MENOS. Voy a compartir un secreto que a muchos os dejará patidifusos: me encantan los lunes. Siempre empiezo la semana en “modo bestia”, con ganas irrefrenables de tachar cosas de mi lista. El problema es que cuando llega el miércoles ya estoy fundido… Tardé un tiempo en comprender que tenía un problema de gestión de energía: para conseguir hacer más, debía empezar a hacer menos.

He aquí un sencillo sistema que de un tiempo a esta parte vengo poniendo en práctica con éxito:

#1 Haz pausas entre sesiones de trabajo. Como comenté en la semana que presenté la técnica pomodoro, hacer descansos de 5-15 minutos cada 25 minutos de trabajo te ayudará a seguir manteniendo el foco.

#2 Dedica al menos un día a la semana para hacer cosas que te gustan. Puede ser socializar con tus amigos, construir maquetas de aviones, ver miniseries sobre viajes intergalácticos o leer autores peruanos.

#3 NUNCA JAMÁS le robes horas al sueño
A corto plazo, puede que aumentes tu productividad, pero a medio plazo mermará tu energía y tu concentración. Y lo peor de todo: a largo plazo acabará con tu salud.

#4 Reduce tus horas de trabajo
Dedica un intervalo de horas para hacer tu trabajo más importante. Fuera de esas horas, está totalmente prohibido trabajar. Si tienes demasiadas cosas que hacer, puedes priorizar con el método Eisenhower que comenté la semana pasada.

Nada de esto es complicado, pero muy difícil de cumplir: va en contra de todo cuanto nos han enseñado.

BIT #3 ¿Qué ando considerando en términos de impresión 3D? 

Impresión 3D portátil. El viaje me ha ocupado prácticamente toda la semana, así que esta vez no he podido imprimir nada Esto me ha llevado a la siguiente pregunta: ¿existirán ya mini-impresoras 3D portables que podamos llevar fácilmente en el avión? Al parecer sí que hay ya impresoras muy, muy pequeñas:

De todas las opciones que he visto, la que más me ha gustado por su peso y por su precio es la Monoprice Mini Delta. Con sólo 1.8 kg de peso, permite imprimir un volumen de 110 x 110 x 120 mm en cualquiera de los materiales habituales (ABS, PLA, PET…). Es compatible con Cura, soporta autocalibrado, WiFi y microSD. En Amazon sólo cuesta 178€. Y, lo mejor, incluye un asa

BIT #4 ¿Qué app me está cambiando la vida esta semana?

Uber para patinetes. Sí, claro que ya conocía Uber. El descubrimiento ha sido que en Málaga (y otras ciudades españolas) puedes usar la misma app para alquilar uno de estos patinetes eléctricos (scooters). Probé uno con el que recorrí media ciudad en 18 minutos por unos 3,80€. La experiencia fue muy agradable, pero debo decir que ni Málaga ni los ciudadanos están completamente preparados para este tipo de transporte: algunas aceras resbalan peligrosamente, en otras apenas hay espacio y la calzada es de adoquines… En mi opinión, todavía hace falta una inversión en infraestructura, en regulación y sobretodo en educación vial. Por lo demás, me parece una solución casi perfecta a la movilidad en ciudades donde casi siempre hace buena temperatura. Bravo por la idea de Uber de incluir este servicio dentro de su misma aplicación.

BIT #5 ¿Qué cita ando ponderando?

Te conviertes en eso a lo que prestas atención. Si no eliges tus pensamientos, otros lo harán por ti

Epicteto

Epicteto vivió en el siglo I a.C. en la Antigua Roma. En aquella época todavía no existían redes sociales infestadas de hoax, fake news, influencers y trolls. Sin embargo, la manipulación mediática ya era una herramienta de poder usada con total impunidad. Si el filósofo viajara al 2019, probablemente se mesaría las barbas y concluiría que nuestra sociedad sigue siendo muy similar a la de hace 2000 años. Más letrada, sí. Pero igualmente susceptible de ser manipulada. Puede que incluso más, pues la exposición a la información -verdadera o no- es infinitamente superior a la de aquella Roma de gladiadores y togas.

Hagamos caso a Epicteto: sopesemos todo lo que escuchamos y leemos por ahí (incluso este artículo). De lo contrario, otros acabarán dictando cómo debemos pensar… sin que nos demos cuenta.

La entrada Los 5 bits de Ángel (VIII): Pantaleón, patinetes y fake-news se publicó primero en BorrowBits.

Leyendo: “Sapiens. De animales a dioses: Breve historia de la humanidad“. Un libro sobre antropología “para todos los públicos” (es decir, sin mucho rigor académico) y con un ligero tufo neoludita. Pese a ello, ofrece una interesante retrospectiva (y prospectiva) de la historia del ser humano.

Viendo: King Arthur. Dos horas de mi vida a la basura. Hay una serie de cosas que nunca debes mezclar: lejía y amoníaco, agua y electricidad, lentejas y chocolate, churros y meninas… y en este caso, gangsters malhablados y fantasía épica para niños. Estimado Guy Ritchie: veo lo que pretendías… pero no ha dado resultado.

Escuchando: Banda sonora de King Arthur. Y aunque la peli me pareció un coñazo, la banda sonora me gustó bastante. La he tenido sonando toda la semana en mis auriculares y en el coche.

BIT #2 ¿Qué truco de productividad estoy practicando? 

Método de Eisenhower. Es una herramienta usada en gestión de proyectos. La hizo popular el comandante supremo de los Aliados en la Segunda Guerra Mundial, Dwight D. Eisenhower, que además posteriormente se convertiría en presidente de EEUU. Consiste en mapear tus tareas pendientes en la cuadrícula de abajo: todo lo que es importante y urgente, debe ser hecho al instante; lo que es urgente pero no importante, debe ser delegado; lo que es importante pero no urgente, deberá ser planificado para hacerlo en otro momento. Y lo que no es ni importante ni urgente, no lo hagas en absoluto…

Plantilla para descarga: https://www.eisenhower.me/eisenhower-matrix-canvas/

BIT #3 ¿Qué ando imprimiendo en 3D? 

Soporte de Smartphone para el auto personalizable: encontré en Thingiverse este sencillo pero funcional diseño. Lo interesante es que está completamente parametrizado en CAD: se puede adaptar con facilidad dependiendo del tamaño del smartphone y de cómo sean las rejillas de ventilación de tu coche. En menos de una hora puedes tener un smartphone holder que no tiene nada que envidiar a los que venden en Amazon.

BIT #4 ¿Qué app me está cambiando la vida esta semana?

Swiftkey. No es sólo un teclado predictivo: es un teclado predictivo que usa machine learning. Es decir, que mejora conforme lo usas. Una de las mejores funciones es que puedes instalar varios idiomas y asignarle una distribución diferente a cada uno. Hasta ahora eso era para mí un dolor de muelas… Además, esta app puede leer tus correos y aprender todo sobre ti: tu forma de teclear, tu estilo, tu tono… y en base a eso, es capaz predecir tus siguientes palabras incluso antes de que las pienses. Esto plantea preguntas bastante inquietantes… La primera: ¿hasta qué punto es seguro? En mi opinión, tan seguro o sospechoso como pueda ser cualquier otro teclado diseñado por una empresa. Pero recuerda la máxima: si el producto es gratuito, tú eres el producto.

BIT #5 ¿Qué cita ando ponderando?

 Nadie es más esclavo que quien se tiene por libre sin serlo.

Johann W. Göthe

Cuando España se liberó de Napoleón en 1814, los españoles se consideraron libres a pesar de retornar al yugo de los Borbones. Y aunque vivimos en una sociedad libre, hablar mal de los Borbones puede costarte la libertad. Y aunque vivamos en libertad, debemos levantarnos temprano para ir a trabajar. Y si de todas formas no tuviéramos que trabajar, probablemente seguiríamos siendo esclavos de nuestra mente…

El ser humano ha acordado muchas definiciones para conceptos que no son sino alucinaciones colectivas: “dinero”, “patria”, “Dios”,… Pero la palabra “Libertad” no se deja atrapar tan fácilmente. La libertad es como una matrioshka, esas muñecas rusas que se encierran unas dentro de otras: cuando llegues a la última probablemente lo único que encontrarás es… la Vacuidad.

La entrada Los 5 bits de Ángel (VII): la Libertad en una Matrioshka se publicó primero en BorrowBits.