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.

Mini proyecto D3: Calendario laboral 2016

calendariojbr

Como parte de mi plan para tratar de hacer de 2016 un año mejor que los anteriores y basándome en la experiencia del año pasado he pensado que debería contar con un calendario completo, algo fácil de visualizar, fácil de tener a mano, con posibilidad de usarse a nivel de múltiples proyectos cortos y largos, que incluya información a nivel de mes y semana, etc.

Tras pensarlo, decidí que los calendarios tradicionales no eran adecuados, por lo que decidí buscar uno mejor. Al no encontrarlo, pero sabiendo que D3.js permite hacer uno a medida, decidí implementarlo basándome en algunos parecidos ya existentes. En realidad podría haberlo hecho en Excel, pero tengo otros planes en marcha que hacen deseable la opción de usar D3.js.

La forma en que estoy empezando a usar este calendario es en formato impreso para tener a mano y marcar hitos. De esta forma tengo facilidad para tenerlos a la vista, junto con días no laborables y otros eventos (jornada intensiva, etc.). También puedo llevar mejor control de a qué altura del año estamos dado el formato de fila con 7 columnas que tiene.

El usar la semana basada en lunes en la parte inferior facilita visualizar los fines de semana y los colores oscuros indican festivos, siendo los claros usados para marcar mi jornada intensiva o para resaltar los fines de semana.

En resumen creo que este calendario impreso puede resultar de ayuda para mantener a la vista el año completo y los diferentes hitos tanto a nivel de proyectos como de actividades recurrentes.

Para quien esté interesado en el código puede obtenerlo de mi repositorio de GitHub: Noradrex/D3Calendar

Para quien solo necesite una imagen que imprimir puede usar la que encabeza el artículo, aunque dada la personalización que tiene, recomendaría modificar los datos embebidos en el código y usar el calendario resultante. Es sencillo.

Por ultimo, si alguien tiene curiosidad por como lo estoy usando, este sería el aspecto de mi planificación en 4 categorías de todo el año, desenfocado para preservar cierta información. Haré más, pero es interesante lo mucho que me recuerda a una partitura.

WP_20160110_001

 

 

 

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.

 

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.

Citas interesantes sobre el desarrollo de software

Nota: esto es también una prueba de publicación en WordPress desde Windows Phone.

Planning every last detail can give you a false sense of security. Coding out of the gate can give you a false sense of progress. Guessing is guessing, whether you have 1000 pages of specs and high fidelity model or a whiteboard with a sketch and a functional prototype.
-Steven Sinofsky

While a tool like PowerPoint can communicate the gist of the plans, the details will be too open to interpretation. So write down the plan in long form—writing is thinking.
-Steven Sinofsky

Closed allocation doesn’t work. What do I mean by “doesn’t work”? I mean that, as things currently go in the software industry, most projects fail. Either they don’t deliver any business value, or they deliver too little, or they deliver some value but exert long-term costs as legacy vampires. Most people also dislike their assigned projects and put minimal or even negative productivity into them. Good software is exceedingly rare, and not because software engineers are incompetent, but because when they’re micromanaged, they stop caring. Closed allocation and micromanagement provide an excuse for failure: I was on a shitty project with no upside. I was set up to fail. Open allocation blows that away: a person who has a low impact because he works on bad projects is making bad choices and has only himself to blame.
-Michael O Church

Psychologists have spent decades trying to answer the question, “Why does work suck?” The answer might be surprising. People aren’t lazy, and they like to work. Most people do not dislike the activity of working, but dislike the subordinate context (and closed allocation is all about subordination). For example, peoples’ minute-by-minute self-reported happiness tends to drop precipitously when they arrive at the office, and rise when they leave it, but it improves once they start actually working.
-Michael O Church

People complain about the politics at their closed-allocation jobs, but they shouldn’t, because it’s inevitable that politics will eclipse the matter of actually getting work done. It happens every time, like clockwork. The metagame becomes a million times more important than actually sharpening pencils or writing code. If you have closed allocation, you’ll have a political rat’s nest. There’s no way to avoid it.
-Michael O Church

Concentración

En las actividades intelectuales, el ruido y las interrupciones aniquilan la productividad y la calidad del resultado. Si realizas una actividad que requiere un mínimo de concentración sabrás esto por experiencia propia, pero me temo que no es algo de dominio público, o al menos no es algo en lo que la gente repare, debido a que a diario tenemos tanto ruido alrededor que ya no nos fijamos en él.

Pero el desarrollo de software es uno de los procesos intelectuales más exigentes de la historia, puesto que se construyen elementos abstractos, complejos y que no admiten apenas error. Sistemas que lo abarcan todo y que no existen en el mundo real. Y como actividad intelectual, requiere de un contexto para ser realizado. Un contexto que se viene abajo con cada interrupción entre las que se incluye el ruido.

Así que cuando alguien cuenta historias de que se puede desarrollar de manera decente en entornos con gente charlando, teléfonos sonando y correos urgentes llegando constantemente, miente como un bellaco. O peor aun, no lo sabe. Y eso, la ignorancia en cargos de responsabilidad, resulta desastroso a medio y largo plazo.

Habrá quien comente que se puede uno poner los auriculares y en efecto, todos los que podemos (a veces los responsables, absurdamente, no lo permiten), lo hacemos, pero no es suficiente. Los auriculares, aun siendo de gran tamaño y con reducción de ruido, solo reducen las señales externas, no las eliminan por completo. Y generan una sensación extraña de aislamiento que tampoco ayuda a estar mentalmente cómodo: en los peores casos se está aislado pero alerta a las mínimas señales externas (visuales y sonoras) por si te llaman los compañeros o suena el teléfono así que el efecto beneficioso se diluye.

En cuanto al tipo de música que poner en los auriculares, algunos preferimos ciertos estilos, pero otros difieren. En mi opinión, el que mejor cubre el ruido externo son la música de baile (chunda chunda) o el rock duro, que no son precisamente lo mejor para realizar tareas mentales complejas. La clásica u orquestal sin embargo, que podría ser menos problemática y suele recomendarse para estudiantes, no cubre bien el ruido ambiente (conversaciones, teléfono), que es lo que queríamos evitar en primer lugar, por lo que su elección aporta menos ventajas de lo que me gustaría.

Así que la mayoría seguimos peleando por encontrar un lugar tranquilo para poder trabajar, como el tren, o la oficina a primera y a última hora cuando la gente aun no ha llegado o ya se ha ido. O en casa… donde puedes ser mucho (MUCHO) más productivo que en la oficina.

En fin, que mi única esperanza de aumentar mi productividad (y la de mi departamento, y por tanto mi empresa) es convencer a la dirección de que el trabajo geográficamente distribuido (teletrabajo) es lo mejor para todos… Y ahí es donde tengo mis ojos puestos en Windows 8, Windows Phone 8, Windows Intune, Office 2013, SharePoint Online, SkyDrive y Lync. Y por eso estoy encantado de estar donde estoy, en este mismo momento. Todas estas herramientas tienen en común que se dirigen al trabajo en grupo y a los grupos distribuidos con especial atención. Y por el momento parece que dan lo que prometen: asistencia y gestión remota, integración, funcionamiento distribuido… todo lo que un teletrabajador o autónomo ha soñado alguna vez, Microsoft lo ha construido. Y yo puedo usarlo.

Así que con un poco de suerte, 2013 va a ser un año genial.

PD: Ya había escrito con anterioridad sobre el ruido y las interrupciones en el desarrollo de software, pero por alguna razón he sentido la necesidad de volver a hacerlo.

El abismo

Como desarrollador con unos cuantos proyectos a mis espaldas, he llegado a identificar como uno de los problemas más importantes a resolver lo que llamamos “gap” tecnológico del usuario. ¿Qué este gap tecnológico? Pues se trata de la falta de determinados conocimientos tecnológicos (del usuario o cliente), que imposibilitan la comprensión y uso de un sistema.

Esta tierra de nadie, esta zanja en el camino a la solución tecnológica, puede ser de distintos tamaños, yendo desde la simple ignorancia de un pequeño truco o utilidad como puede ser el usar el TeclaControl+Fpara buscar palabras en un documento, o el TeclaWindows+escribirpara encontrar una aplicación en sistemas Windows 7/8, a algo mucho más profundo y peligroso como puede ser la total falta de conocimientos no ya en informática (que al fin y al cabo solo existe masivamente desde hace unos 50 años) sino la más completa ignorancia sobre qué es un automatismo, ordenador o máquina.

Con esto quiero decir que en casos leves es solución suficiente señalar al usuario dónde está un menú, o hacerle una demo de una funcionalidad nueva, pero en demasiadas ocasiones nos encontramos ante la ausencia del marco necesario para entender un carajo.

Este caso sería el del típico empleado que guarda toda su información en su ordenador local, y desconoce lo que es un fallo de hardware, una copia de seguridad, la naturaleza electromagnética de la información de su disco o RAM (volátil), las soluciones gratuitas de backup local y online, el valor de su información, etc…

Este tipo de usuarios puede ser un auténtico problema en entornos informatizados (cualquier oficina de más de 2 personas a día de hoy) por varias razones:

1.      Por un lado su falta de conocimientos hace que use mal las herramientas, en general infrautilizándolas y perdiendo un montón de tiempo al cabo de día por ello.

2.      Por otro lado, todo ese tiempo malgastando es tiempo que alguien tiene que pasar esperando o se transforma en trabajo extra para otros compañeros (por baja productividad o control de daños).

3.      La frustración que produce usar mal las herramientas lleva al usuario a estar descontento con las herramientas y eso genera una carga negativa a día a día que puede sumarse a otras cosas para generar un mal ambiente de trabajo.

4.      La lentitud y complejidad extra añadida al trabajo por un mal uso de la herramienta, suele  pasar factura a la concentración del trabajador, empeorando sus resultados.

5.      La imagen de la tecnología y los cambios, se ve empañada a ojos del usuario por todo lo anterior, generando una animadversión a la tecnología y el cambio. Algo que a la larga puede matar a una empresa o industria al completo.

Por si todo esto no fuera ya bastante malo, resulta que la llamada brecha digital solo se amplía con el tiempo y llega un punto en que se hace tan grande que tratar de superarla uno mismo cuesta mucho más de lo que podemos asumir, en particular en condiciones de estrés y negatividad como las que enumeraba antes. Y en cuanto a confiar en terceros…  reconozcámoslo: la mayoría de los cursos de formación tecnológica tienen mucho de estafa (ofertas de pocas horas concentradas, malos docentes, programas rígidos…) o un desastre por falta de tiempo (RRHH contratando basurilla y presionando para abaratar algo con que llenar el expediente).

Es por todo esto que el gap tecnológico, la brecha no tanto digital como tecnológica, es tan peligrosa: provoca problemas reales, reduce la productividad, aumenta con el tiempo, se contagia a su alrededor y no existe una solución definitiva para ella.

Así que ahora que sabemos qué es y cómo nos afecta, preguntareis “¿cómo arreglamos este gap, este abismo de conocimientos que está cargándose la viabilidad de mi empresa?” La respuesta es, en mi opinión, que no se puede resolver, solo podemos tratar de minimizar el problema. Y para minimizarlo, al margen de reconocerlo en nosotros (sí, todos lo tenemos, no se libra ni Dios) y en los demás, debemos tratar de atacarlo a la mínima oportunidad: si vemos que nuestros compañeros desconocen algo o realizan tareas que debería estar realizando una máquina, debemos acercarnos y ayudar con ello. Se requieren también paciencia, curiosidad y humildad para reconocer nuestra propia ignorancia y ocasional estupidez. Y se requiere una voluntad de equipo para tratarla entre todos en el día a día, a pesar del estrés, los roces y los humos de cada uno de nosotros. Pero sobre todo, creo que se requiere valor y asertividad para cuestionarlo todo (independientemente de la jerarquía) y disentir públicamente.

¿Difícil? Sí. ¿Incómodo y desagradable en muchos casos? Desde luego. Pero la alternativa dada la velocidad de los acontecimientos, es el fracaso a medio y largo plazo. Y si no, que se lo digan a la industria musical (barrida por iTunes y el P2P), la industria del cine (barrida por Megaupload y los torrents) o la industria editorial (barrida por Amazon y los ebooks) entre otras afectadas por no tener un marco de conocimientos adecuado sobre la tecnología y las herramientas.

Lecturas relacionadas MUY recomendables: Philip Zimbardo, Gerd Gigerenzer, Usuarios del siglo XXI, Robert J. Stenberg.