Developer Timeline 1996-2016

pope-john-paul-ii-and-fidel-castro-watching-time

Hace unos meses intenté convencer a algunos desarrolladores de que necesitaban aprender Git. Algo que desde mi perspectiva parecía obvio y urgente se tornó, pese a mis esfuerzos por argumentarlo, en imposible. Desde entonces he estado dándole vueltas al tema de la obsolescencia de las herramientas, técnicas y servicios que los desarrolladores usamos a diario y a como alternamos entre lo malo conocido y el hype del momento.

Esto me llevó a pensar en cómo “de-mostrar” a determinados perfiles técnicos de la necesidad de actualizarse, lo cual me condujo a confeccionar una “línea de tiempo” o mapa de tecnologías y herramientas de desarrollo .NET para poder observar el avance en determinados ámbitos como el control de versiones de código.

Gracias al intercambio de ideas de los Meetups en SofwareCraftmanshipCLM y los ánimos que me han dado desde esta comunidad para publicar el “timeline de desarrollo”, he terminado una versión 1.0 que he colgado en Google Sheets para uso y adaptación de otros equipos de desarrollo, incluso de otros stacks tecnológicos. O aprovechando que acabamos el año, para pararse a pensar qué aprender en 2017.

El Excel es el siguiente: Developer Timeline 1996-2016

¿Para qué sirve?

La idea es poder usar la hoja como herramienta de 4 formas diferentes para varios objetivos:

  1. Para poder revisar en qué punto estamos de actualización técnica y ayudarnos a decidir si aprender o no una tecnología en concreto.
  2. En grupos de desarrollo. Para poder argumentar con datos objetivos frente a nuestros compañeros sobre la necesidad, o no, de reciclarnos tecnológicamente. Como mínimo debería facilitar el diálogo sin caer en el flame.
  3. En charlas. Para poder hacer una introducción simpática para todos los públicos sobre determinadas tecnologías como Core o SharePoint Framework añadiendo un contexto tecnológico más amplio que facilite el entendimiento de los problemas que resuelve.
  4. En organizaciones. Para poder establecer el nivel de actualización de una organización (la nuestra u otras) de una forma más o menos objetiva. En última instancia podría ayudarnos a decidir si embarcar en una empresa o desembarcar de la actual.

¿Qué contiene?

La hoja contiene varias categorías (eje vertical) y eventos relevantes para cada una de las categorías, repartidos por año (eje horizontal).

Me pareció adecuado empezar en 1996 por tener un intervalo amplio y “redondo”: 1996-2016. El año 1996 sirve además para poder establecer una línea base de “desarrollo viejuno”.

La información que contiene está orientada por mi experiencia y entornos de trabajo a lo largo de los años por lo que hay bastante de Microsoft, pero he tratado de mantenerlo flexible para poder adaptarlo a otros entornos aglutinando la mayoría de elementos específicos de Microsoft en su propia categoría.

Sobre las categorías, los datos y la selección

Hay muchos elementos que podría haber metido pero que finalmente he eliminado por claridad (versiones, irrelevancia…) y simplicidad.

Muchas fechas son aproximadas y en algunos casos discutibles. En general he tratado de tomar las más importantes como por ejemplo productos release en lugar de beta.

Hay bastante tecnología Microsoft debido a mi propio background y el público al que lo he enfocado, pero he tratado de mantenerlo flexible para otros stacks.

Este documento no pretende ser canónico, sino una herramienta ilustrativa de la evolución y periodos que vivimos los desarrolladores de software. Está pensado para ser modificado de forma sencilla por lo que he desistido (de momento) de hacer un gráfico SVG interactivo con D3 y JSON.

Las categorías en que he agrupado los eventos son las siguientes:

  1. Papas: Los papas de la Iglesia Católica Apostólica y Romana que hemos tenido desde el 96. Me parece interesante mostrar que hasta las organizaciones más antiguas y tradicionales experimentan más cambios que algunas personas o empresas.
  2. Efemérides: Evento de relevancia nacional o mundial. Permite replantearse la cantidad de tiempo que ha pasado entre tecnologías y los grandes cambios que han sucedido en la sociedad.
  3. Películas: Estrenos de cada año. Me parece un detalle simpático para tratar de poner en contexto el tiempo que ha pasado, en particular entre fans de Marvel como yo, y la cantidad de proyectos que pueden llevarse a cabo en 5 o 10 años.
  4. JavaScript: Aun hay gente que no quiere saber nada de JavaScript o quiere quedarse en la versión del ’99. Visibilizar la cantidad de hitos que ha tenido debería facilitar el NO poder ignorarlo.
  5. Autenticación y Autorización: Todavía tengo que explicar las diferencias entre autorizar y autenticar. En el panorama actual y dado que es necesario conocer estos temas para realizar cualquier aplicación moderna, me parece grave y por eso le he dado su propia categoría.
  6. Servicios web: Esta categoría trata de servicios web y trata de poner de manifiesto que la diferencia entre SOAP y REST en realidad son pequeñas y que deberíamos mirar más allá del hype al evaluarlas. También pone en el mapa los webhooks, que parece que son grandes desconocidos a pesar de su utilidad y antigüedad.
  7. Formatos de datos: Me pareció apropiado añadir esta categoría tras la de servicios web para señalar que son dos cosas independientes y que ya va siendo hora de aprender a usar JSON. O usar Markdown en lugar de HTML en según que contextos.
  8. Front End: Esta categoría podría ser una hoja aparte, pero he tratado de incluir estándares de facto y orientarme a desarrolladores back o full stack. He añadido asteriscos a temas de W3C para recordar que… “es complicado” asegurar en qué estado están.
  9. Gestión de código: Esta es la razón por la que comencé a confeccionar el Excel y por eso tiene un componente “fuerte” de productos Microsoft, pero dejando claro que el estándar a día de hoy es Git. De hecho, es importante mencionar que Microsoft lleva años migrado todo su código abierto a Github.
  10. Servicios de terceros: Incluyo una lista de servicios de terceros relevantes para perfiles técnicos. Estos deberían contrastar con la antigüedad de algunas de las herramientas de algunos técnicos. Si, por ejemplo, alguien usa Dropbox (2008) o Google Drive (2012), no podrá argumentar que Git es demasiado moderno (2005).
  11. Microsoft Stack: categoría específica para los que usan el stack de Microsoft, por lo que en adaptaciones a otras empresas debería adaptarse. El “baseline” es Outlook porque me pone nervioso ver que no se sabe usar a nivel básico (carpetas, convocatorias, respuestas automáticas…) y es una herramienta que todos usamos a diario para trabajar en empresas, en particular con el stack Microsoft.
  12. S.O.: Sistemas operativos desde el ’96. Con especial detalle en el ámbito Windows, claro. Porque todavía hay quien quiere volver a W7 por pura resistencia al cambio.
  13. Dispositivos Móviles: He tratado de sintetizar el panorama en dispositivos móviles. Al estar tan unidos hardware y software he mezclado ambos elementos. Evidentemente Windows Phone/Mobile se queda fuera.
  14. Lenguajes: Es interesante ver que los lenguajes de back-end son bastante estables, pero no inmutables.
  15. Entorno de ejecución: Parece que todo es alguna variedad de la máquina virtual de Java o el que tiene que funcionar sobre el CLR de .NET y no solo no es así, sino que el panorama parece que va a cambiar cada vez más. Estuve tentado de introducir Docker también, pero los contenedores son otra historia y aun me parece pronto para añadirlos, quizá el año que viene o quizá en otra categoría de DevOps.

Como nota curiosa no he notado nada interesante en 2003 pero si muchos eventos importantes en 2009: el embrión de Azure y Office 365 (BPOS), Android 2.0 (la primera versión buena), Windows 7 (el más querido), ECMAScript 5 (el JavaScript de la nueva web), Bitcoin (y la explosión del blockchain), GO (del que Javier nos dará una charla pronto) y Node JS (¿el nuevo Java/PHP?) del que vimos como se usaba en producción en las Lambdas del AWS de BrainSINS en el último Meetup.

En resumen

Como decía el personaje de Will McAvoy en The Newsroom: El primer paso para resolver un problema es reconocer que hay uno (minuto 5:00, pero el speech completo es impresionante).

Mi intención inicial era mostrar como Git es una herramienta indispensable para el desarrollador de .NET de hoy, comparándola con eventos relevantes del pasado reciente de forma objetiva y amigable.

Aunque parece que he conseguido construir esa herramienta, creo que he generado algo más potente, una especie de minicuadrante de Gartner del desarrollador .NET (y en general) que podría servir para animar a algunos técnicos a reciclarse, y que me ha ayudado a ampliar mi visión estratégica para 2017 así como a mejorar mi planteamiento como arquitecto de soluciones y líder técnico. O como mínimo me ha aclarado panorama bastante ahora que parece que todos andamos perdidos de stack en stack y de framework en framework especialmente en el mundo Microsoft.

Para terminar

Al revisar mis propios artículos me parece reconocer que en el universo Microsoft, 2016 es una repetición de 2012. Da para otro artículo, pero si estás más o menos al día creo que podrás ver las semejanzas entre el panorama actual (Azure, Office 365, Hololens, ARM, Open Source…) y el que describí en 2012 en: El desembarco de Normandía.

Y si te ha interesado este artículo, es muy probable que te interesen mis artículos: Breve historia del desarrollo de software de 2012 y mi predicción sobre el futuro de Blackberry, iPhone y Palm en 2007: La muerte de Blackberry.

Las dos palabras que todo profesional debería usar más

Hace unos días, Manuel de la Peña twiteó un texto que comentaba una vieja historia (más bien fábula) de monos, jaulas, preguntas y procedimientos.

Eso me trajo a la memoria pequeño artículo que leí en Hardvard Business Review sobre el arte de hacer preguntas. Un artículo que en su momento me invitó a pensar en la importancia no tanto de las técnicas de hacer preguntas, como de lo esencial que es conocer el “por qué” de las cosas (y para lo que se necesita hacer preguntas, claro).

También me recordó este otro artículo sobre qué hacen las personas que son buenas escuchando y que en mi opinión es una consecuencia de interés genuino en entender los “por qué“.

La falta de interés y esfuerzo en tratar de entender las cosas, sus objetivos y contextos (esto es, el “por qué“) es un tema que me da mucha rabia observar (incluso en mi) y del que hace tiempo que tenía pendiente quejarme un poco en público. En público, porque tiene relación directa con todos los procesos que se realizan en cualquier empresa; también con las buenas prácticas (best practices) que parece que muchas personas se emperran en recomendar o exigir sin entender que dependen del contexto. Y por supuesto porque tiene que ver con los que critican (y criticamos) decisiones de terceros a nivel personal, de negocio o político casi a diario.

Hay por supuesto profesiones en las que en general se necesita hacer preguntas básicas constantemente de forma directa o indirecta, como en medicina (¿le duele aquí?, ¿puede caminar?), donde cada prueba médica es una forma de pregunta y cada mirada o toque está orientado a obtener una respuesta (el ojo clínico). Supongo que haber tenido un padre médico ayuda a ver ciertas cosas de cierta manera.

No obstante, la mayoría, durante la mayor parte del tiempo observa, juzga y condena sin conocer el “por qué” de una decisión. Pocos se molestan en hacer preguntas la mayor parte del tiempo. Mucho menos una tan básica como “¿por qué?“. Y desde luego nunca seguida de otro “¿por qué?” como en el método Toyota-Lean-Kaizen-Six Sigma de los 5 por qué para la mejora de procesos.

Me temo que hemos cogido miedo a hacer preguntas básicas, las más importantes, por miedo a parecer ignorantes y menos valiosos en nuestro entorno personal y puesto de trabajo, e irónicamente eso nos hace más ignorantes y menos valiosos.

Pero no acaba ahí el problema: como nadie hace preguntas para entender un contexto todos acabamos dando por sentado que este no importa y/o que todos tenemos la misma idea en la cabeza, lo que provoca errores y dificultad en la comunicación. Un desastre.

En fin, que las dos palabras que creo que todos deberíamos usar más son evidentemente “¿por que?”. Aunque hay otro par de palabras que, si se usasen con sentimiento real, también deberíamos usar más y mejoraría mucho nuestras vidas: “por favor”. Porque es sorprendente lo bien que responden algunas personas a un poco de interés y educación y como redunda eso en un win-win de libro.

Así que tras quejarme un poco y habiendo dejado algunos enlaces (espero) interesantes, solo puedo cerrar este post invitando a todos a preguntar más y mejor. Con inocencia y abiertos a escuchar.

Productividad: Contexto y priorización de proyectos

Nota: tenía esto guardado desde 2013, pero por alguna razón olvidé que estaba en el cajón de “para publicar” hasta la limpieza de enero de 2016.

En mi carrera como desarrollador me he encontrado bastante a menudo, supongo que como todos, con una cantidad excesiva de proyectos sobre la mesa y por eso me gustaría comentar una estrategia para abordarlos que, sin ser mágica, me permite establecer un flujo de trabajo operativo.

Empezaré aclarando que pienso que la abundancia de proyectos es por un lado algo bueno, porque significa que voy a tener trabajo durante un tiempo (hola Crisis), pero por otro lado, resulta que me encargo de casi todas las funciones de cada proyecto por lo que soy yo quien debe organizar mi propio tiempo (al menos cuando me lo permiten) no solo entre proyectos sino entre tareas del proyecto… y rendir cuentas y plazos.

Así que ahí estoy, el equipo de un solo hombre, viviendo fuera de mi zona de confort (habilidades técnicas variadas VS sociales, de gestión, de comunicación, de diseño…), y tratando con una miríada de proyectos concurrentes. Y con todos estos cambios de sombrero, entorno, tecnología y negocio, sufro de manera crónica los cambios de contexto. Cambios que se cargan la productividad, claro.

Los cambios de contexto

Todo el que haya trabajado (de verdad) en varios proyectos a la vez, sabe que un cambio de contexto, supone “sacar” de la cabeza todo lo que tengas sobre una tarea X y llenarla con la tarea Z que quieras acometer. A mayor complejidad del proyecto, y a mayor número de elementos implicados (gente, documentación, herramientas, productos…), mayor es el tiempo empleado en cambiar de contexto, especialmente si además se trata de proyectos en áreas de negocio diferentes (cine, logística, auditoría legal, banca de inversión, marketing…). Algunos autores calculan una media de 20 minutos perdidos por cada interrupción en un trabajo intelectual que requiera concentración, pero personalmente creo que los cambios de contexto entre proyectos donde uno se encargue de casi todas las áreas, que además sean de áreas muy diferentes, y que impliquen un gran número de herramientas diversas, suelen ser mucho más pesados que una interrupción media, precisamente por las dimensiones de roles, ámbitos, conocimientos y entornos que se añaden al problema. Y todo esto sin entrar a comentar el desgaste intelectual de todo esto.

Estimemos por ejemplo 10 días para un proyecto corto, luego contemos que cambias de proyecto (por la razón que sea, no por capricho) 2 veces al día. Con esas cifras tan pequeñas es fácil calcular, siendo muy conservador y usando la media de 20 minutos, que acabaré acumulando (10 días x ((20 minutos x 2) / 60)) más de 6 horas de pérdidas. Un cálculo completamente ficticio y en bruto, pero que sirve para poner de manifiesto que los cambios de contexto tienen un coste que no se suele tener en cuenta, y que por tanto deben ser evitados en lo posible, si no queremos provocar una caída a plomo del trabajo efectivo realizado.

El método

Con esta idea en la cabeza, a lo largo de los años he desarrollado un flujo de trabajo que, si bien tiene sus propios problemas, sí me permite ser más productivo y reducir los cambios de contexto. Y lo que es más importante, lo hace sin que tenga que pensar o decidir demasiado.

El método es este:

  1. Trabajar únicamente en el proyecto que tenga la estimación de tiempo más corta e ignorar en lo posible los demás. A menos proyectos en marcha, menor es la probabilidad de tener que cambiar a uno, así que es mejor acabar los más cortos cuanto antes.
  2. Trabajo en el proyecto de los clientes que pagan. Si un cliente es de los que tardan en pagar, o de los que ponen pegas durante meses (no me meto en si con razón o no), su proyecto queda en cola. Esto se debe sobre todo a que un proyecto no cobrado, es un proyecto abierto, y el cliente que no paga tiene poder de imponer cambios no contemplados que alargan el proyecto de manera inesperada más allá del alcance inicial. Con esta regla, minimizo el impacto de los clientes/proyectos “malos”.
  3. Brown dispatching de tareas. Los proyectos más complejos (técnica u organizativamente, o en cualquier otro ámbito) suelen requerir de acción por parte del cliente o de terceros así que para evitar cambiar de tarea, ante una interrupción, trato ganar tiempo decidiendo lo más rápido posible si debo pasar la pelota a otra persona/responsable. Por ejemplo: si hay una incidencia en una aplicación, pido datos, pantallazos, etc; si me piden información, les mando al repositorio del proyecto a buscar (SharePoint es tu amigo); si me piden una reunión, les digo que mañana, que pongan ellos la hora. Y así con todo, bajo la premisa de evitar el cambio de tarea o postergarlo al mañana, cuando el cambio de contexto casa/trabajo es inevitable (hay que dormir) y el daño producido es menor, aunque no evitado.

Obviamente, estas técnicas tienen su propia problemática y en ocasiones no es factible utilizarlas, pero al menos ayudan a NO tomar decisiones y reducir los cambios de contexto, por lo que mejora la productividad y reduce el cansancio asociado a la toma de decisiones, que como sabemos, en el desarrollo de software es algo agotador.

 

Este año, sé un héroe

En 2012 no me decidí a publicar esto debido a su escasa longitud. Se trata de un texto que traduje de Philip Zimbardo acerca de las acciones heroicas en el contexto de su proyecto Heroic Imagination. De cómo podemos mejorar la sociedad.

Creo que el inicio de este año y dada la situación actual nacional y mundial, es un buen momento para recordarlo.

Una acción heróica es:

  1. Iniciada voluntariamente;
  2. Realizada en servicio de una o más personas o de la comunidad como conjunto;
  3. Involucra un riesgo al comfort físico, estatus social, o calidad de vida;
  4. Se inicia sin la expectativa de una ganancia material

Los heroes reactivos son personas que actuan en el momento, usualmente de manera espontánea. Tras lo cual, un heroe reactivo a menudo dirá algo como “no tuve tiempo de pensar, simplemente lo hice.”

Un heroe proactivo es alguien que realiza continuos esfuerzos a lo largo del tiempo para exponer operaciones de fraude, montajes, o corrupción. Tales heroes son más efectivos cuando forman redes con otros que comparten sus valores, atenuando por tanto las críticas (de defensores del sistema malvado) de que son fanáticos o están equivocados.

Texto original:

Heroic action is:

  1. Engaged in voluntarily;
  2. Conducted in service to one or more people or the community as a whole;
  3. Involving a risk to physical comfort, social stature, or quality of life; and
  4. Initiated without the expectation of material gain

Reactive heroes are people that act in the moment, usually spontaneously. Afterwards, a reactive hero will often say something like “I didn’t have time to think, I just did it.”

A proactive hero is someone that makes continual efforts over time to expose the operation of fraud, deception, or corruption. Such heroes are more effective when they form networks with others who share their values, thereby lessening the criticism (by defenders of the evil system) that they are fanatics or misguided.

Frameworks, pereza y productividad

WP_20150706_012

 

Un framework es un marco de trabajo. Un conjunto de cosas (tecnologías, estándares, prácticas, ideas…) que nos ayudan a realizar un conjunto de trabajos sin tener que pensar todo de cero. Una framework es una herramienta para acelerar el trabajo y reducir la incertidumbre del resultado. Pero esa misma reducción de la incertidumbre es a costa de reducir la flexibilidad de las soluciones que ofrece.

Diferentes framework están orientados a diferentes tipos de problemas o clientes. O enfocan los problemas de diferente manera, o aprovechan mejoras en la tecnología (memorias más rápidas, procesadores más potentes…) para tratarlos de diferente manera.

Si lo comparásemos con un viaje, el framework es el viaje en crucero, donde no podemos quedarnos más tiempo del establecido en ninguno de los puertos, ni cambiar de destino, ni cambiar de camarote o volver a casa cuando queramos… a no ser que paguemos un alto coste.

La incertidumbre del resultado es insignificante, pero estamos en cierto modo atrapados.

Un framework es cualquier metodología como Scrum, o la gestión de proyectos del PMI. También pueden considerarse frameworks plataformas o productos como Oracle (la base de datos con todo tipo de funcionalidad) o el SharePoint de Microsoft sobre el que yo mismo trabajo.

En desarrollo de software un framework es algo como .NET o Angular, pero no una librería como JQuery. De ahí que JQuery se pueda usar dentro proyectos ASP.NET por ejemplo: una librería es muy flexible y ofrece una solución especializada que completa otros frameworks.

Quizá cuando el cliente no sabe lo que quiere y no está interesado en pensarlo demasiado es cuando más nos deberíamos ceñir a los frameworks, de modo que el cliente esté “obligado” a seguir un guion predefinido, uno que al fin y al cabo alguien sí ha estado pensando. En caso contrario, si permitimos que el cliente dé “bandazos”, podemos acabar con un proyecto a la deriva con mucha facilidad y terminar agotando todos los recursos disponibles sin llegar a un resultado satisfactorio.

Algunos clientes sin embargo, están perfectamente preparados para asumir esa deriva y no tienen miedo a invertir recursos en el viaje. A estos no les hace falta el framework (incluso puede que les perjudique), porque han decidido que no tienen miedo a explorar y a salirse de las rutas establecidas.

Por último existe un peligro en usar los frameworks sin entenderlos. Cuando trabajamos dentro de estos, debemos tener claros sus límites y las ideas que los sustentan, así como el problema que pretendamos resolver. Si no lo hacemos, si nos limitamos a usar el framework porque sí, lo más probable es que terminemos retorciéndolo y mutilándolo hasta destrozarlo, quizá resolviendo el problema del cliente en el proceso, pero sin duda generando decenas de problemas adicionales en el proceso, empleando mucho más esfuerzo del necesario y con un resultado incierto (lo he visto en varias ocasiones).

En estos casos de uso sin conocimiento real del marco de trabajo, su uso genera precisamente el efecto contrario que se buscaba: resultados inciertos, esfuerzo extraordinario y problemas adicionales.

En resumen, el uso de un framework o herramientas de terceros debe estar sujeto siempre que sea posible a una comprensión de los mismos (para qué sirve, como ataca el problema, etc.) y en mi opinión hay dos usos muy claros para estos, siendo el resto discutibles: a) equipos con experiencia que usan su propio framework o uno específico bien conocido para resolver más o menos los mismos problemas de forma recurrente o b) personas con poca o nula experiencia que necesitan un entorno que les guíe para poder ofrecer cierto rendimiento de desarrollo.

Libro: The Germ Theory of Management

Creo que leí esto atraído por un twitt de @Aelena y ha resultado ser una auténtica joya. En realidad no es un libro sino un artículo de 20 páginas, pero se trata de una lectura lo suficientemente atractiva como para que la automarque como “libro” para futuras referencias.

Este artículo de Myron Tribus habla de los problemas sistémicos, lo que significa “Calidad” y como se relaciona todo con la gestión de empresas (o equipos si se desea).

No es habitual ver tan bien explicado como una empresa es un organismo, un sistema y como las variaciones de rendimiento entre diferentes personas o departamentos pueden ser perfectamente explicables por el azar. Y donde las medidas tomadas en una parte, afectan al todo de formas imprevisibles si no tenemos cuidado.

Tampoco es habitual ver el acento puesto en gestionar el sistema en que trabajan las personas y no en gestionar a las personas o realizar mejoras marginales sin una visión global del sistema. Llega a decir que ante un problema debería tomarse probable que el 85% de las veces, el origen es el sistema y el 15% de las veces el propio trabajador.

Me recuerda muchísimo a Zimbardo, pero hablando de gestión empresarial, y resulta especialmente interesante ver como anticipa los problemas que se darán al tratar de transmitir esta visión a quien no la ha desarrollado por otro camino: resistencia activa e incredulidad.

Por último una reflexión: si la variabilidad es mala para funcionamiento del sistema eso significaría que los desarrollos de software a medida o las implantaciones “adaptadas” (más allá de una mínima personalización) de productos informáticos en las empresas son en principio malas. Sin embargo la variabilidad, aunque puede ser mala, es necesaria para la evolución. Siguiendo con la metáfora biológica, los organismos necesitan variabilidad para sobrevivir y adaptarse y mejorar, cualquier otra opción lleva a la extinción.

Por último, una pequeña cita del artículo:

After a while some of the operators learn special tricks to apply when the aluminum rolls have to be changed. Because the management rates the operators individually and competitively, those who learn new tricks are not always willing to share them with their competitors. What the management then see is a large variability in the capabilities of their operators. They think they are witnessing the results of the variability of people; they aim to fire the “bottom half”. They do not know that the virus of variability is infecting their processes.

They act on what they know. They have an explanation for everything and are confident in what they do. In the process they ruin the lives of some of their workers. They are a menace to the health of their companies, but because neither they nor their workers understand about the virus of variability, they are unaware. They know not what they do. And they do not like to be told.

Contexto y degradación del trabajo (II)

Trabajando con menos recursos de los necesarios, uno se acostumbra a trabajar en cosas pequeñas

 

Siguiendo con la serie de contexto y degradación del trabajo, hoy querría centrarme en algo relacionado con el post anterior, quizá menos dañino en según qué casos pero igual de peligroso en general. Se trata de usar menos recursos de los necesarios para realizar un trabajo de forma óptima. Hablo de usar recursos por debajo de cierto umbral, uno que supone una degradación en la calidad del trabajo y en la velocidad de su ejecución pero que desde una perspectiva empresarial, suele parecer mejor que la alternativa: dedicar más recursos.

Veamos algunos ejemplos:

  • El típico caso en que se usa a una persona para realizar diversos roles porque “no podemos contratar a más personas“. La persona con varios roles termina haciendo muchas cosas mal (y que se pagan más adelante) porque su atención es una y las energías y horas del día, muy limitadas. Cualquiera que haya estado en esa situación y se haya parado a analizar su propio desempeño durante y después de la experiencia puede dar fe de ello.
  • Cuando se usa un teléfono, correo u ordenador para compartir entre varias personas porque “no lo usan tanto“. Las personas que se ven obligadas a compartir terminan pisándose unas a otras en ciertos momentos y teniendo que formar una especie de colas, o protocolos de uso (con suerte). Al coste de organización, tiempos de espera y roces, nadie le pone un coste, pero lo tiene en tiempos de espera e interrupciones. Y no es nada barato en el medio y largo plazo.
  • O incluso algo más sutil, como emplear un solo monitor en lugar de varios, cuando estamos trabajando con varios documentos o sistemas a la vez (cada vez más común) porque “puedes cambiar de ventana” o “así funciona”. Aquí nadie se da cuenta de que no tener la información en pantalla va a obligar a tenerla en papel (impreso) o en la cabeza, que tiene sus límites y va a ocasionar errores y agotamiento, en especial si hay interrupciones como las de las oficinas abiertas que se pusieron de moda hace años.

Hay muchos ejemplos que entran en estas categorías, como las oficinas abiertas, despachos compartidos, servidores centralizados saturados, etc. Seguro que el lector podrá pensar en varios casos concretos.

Al final, cada uno de los ejemplos anteriores se traduce en lo mismo: el uso de recursos limitados, usados de alguna forma en turnos, para realizar un trabajo. Y yo entiendo la necesidad de optimizarse el uso de los recursos, pero por debajo de ciertos umbrales, esta optimización, esta eficiencia en el uso de recursos se transforma en un coste que acaba cobrándose por otro lado un coste muy superior.

 

Doing right the wrong thing

 

Resulta que en 2 de los 3 de los casos anteriores, en lugar de optimizar el tiempo de las personas, estamos dedicándonos a optimizar el tiempo de las máquinas o a extender su vida útil. Estamos primando la optimización de uso de un recurso abundante y barato (hardware), mediante el uso ineficiente de un recurso más escaso y por tanto caro: el tiempo de las personas y su atención. Algo que se hace a diario en muchos hogares y negocios a lo largo y ancho del planeta, porque nadie se para a pensar realmente qué está haciendo. Un jefe que tuve lo llamaba “economía de guerra” y decía que podía tener su momento y lugar pero que de mantenerse en el tiempo era mejor cerrar el chiringuito y dedicarse a otra cosa. Y estoy de acuerdo.

Diría que llega un punto en que si no hay suficientes recursos para hacer algo bien, hay que plantearse directamente no hacerlo. Y es tan aplicable a lo laboral como a lo personal.

 

Pérdida de atención

Había dicho que estábamos haciendo un uso ineficiente del tiempo, pero también de la atención. Mientras que el concepto de perder el tiempo es algo fácil de transmitir, el de perder la atención no está suficientemente interiorizado. Al trabajar con recursos mínimos y tener que ir cambiando de rol, turnándose, el enfoque del trabajo se orienta a piezas mínimas, y eso conlleva un cambio constante de contexto si las piezas son demasiado pequeñas. Con esto me refiero por ejemplo a cuando trabajamos con conjuntos de datos más grandes de los que pueden usarse en pantalla: dos documentos con diagramas que son cada uno demasiado grandes para verse correctamente en una, dos escritorios remotos y el correo electrónico cuando tenemos un solo monitor pequeño… cosas así.

En algunos casos este “trabajar en pequeño” puede ser beneficioso, pero es raro que sea así cuando lo hacemos obligados por el contexto, debería ser una elección y debería variar con el tiempo. Esa ventaja de “enfocarse en detalles” es buena para un relojero o un joyero ocupado en una joya, pero no suele serlo para la administración de un sistema empresarial donde necesitamos tener claro el contexto y las interrelaciones de máquinas, personas, procesos…

Al final, trabajar fijándonos solo en detalles obligados por una limitación de recursos obliga a cambios de contextos y estos penalizan tu rendimiento al tener que mantener en memoria un montón de información que deberías tener a mano. Ese desgaste extra va a producir por un lado cansancio y por otro que otra información, probablemente vital, se quede fuera. A corto plazo es un problema importante pero a medio y largo plazo el efecto es devastador. Dejar de ver el bosque por tener únicamente la capacidad de ver la rama de un árbol cada vez puede traerá consecuencias y la buena voluntad, el wishfull thinking de los libros de autoayuda, no va a arreglar absolutamente nada. Es más, como mucho conseguiremos el perverso efecto de que la “victima” de esta “economía de guerra” se auto culpabilice. Y entonces ya no solo tendremos un problema de productividad, sino que podremos contar con un problema de abandono y reducción adicional de recursos, ya sea por cambio de trabajo o por “dimisión interior”.

 

Un clavo

Escribir este artículo me ha recordado un proverbio que leí hace mucho tiempo y que usaré para cerrar este artículo. Según la Wikipedia viene repitiéndose prácticamente igual desde el siglo XIV y así es más o menos como lo recuerdo:

Por falta de un clavo la herradura se perdió.

Por falta de una herradura el caballo se perdió.

Por falta de un caballo el jinete se perdió.

Por falta de un jinete el mensaje se perdió.

Por falta del mensaje la batalla se perdió.

Y así como la batalla, fue que el reino se perdió.

Y todo porque un clavo de herradura faltó.