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.

La que he liado – Un contexto y una disculpa

William-Adolphe Bouguereau (1825-1905) - Two Sisters (1901)

Hace unos días uno de mis tuits generó bastante actividad, entre el debate y el enfado, dependiendo del momento y del participante (no me excluyo).

No es la primera vez que esto sucede en Twitter. Ni soy el primero en provocar o sufrir esto, ni es algo raro o especial como pueden atestiguar Edin Kapić, MVP de Microsoft y una de mis referencias favoritas de esa comunidad, o Roberto Luis Bisbé al que también sigo al resultarme interesantes sus contenidos. Trato de tomarlo como uno de los gajes de la exposición pública y la tendencia al malentendido del medio escrito, inmediato y limitado a los 140 caracteres que es Twitter.

Que Edin (por partida doble), Roberto y yo compartamos este dudoso honor, no significa que seamos equiparables, amigos, ni nada por el estilo, simplemente son tres ejemplos recientes de “la-que-he-liado” en la comunidad Microsoft, en Twitter. De hecho solo he hablado en persona con Edin en un DevCamp de Apps para SharePoint 2013 de Microsoft en 2013 y con Roberto en la Iberian SharePoint Conference de 2013. Para mi, ese fue un buen año de asistencia a eventos en horario laboral.

Los que me conocen saben que vivo en Toledo, por lo que mi participación física en eventos en Madrid, donde suelen darse estos, es complicada sin una aprobación de mi empresa para hacerlo en horario laboral. Máxime cuando tengo una pequeña de 6 años a la que idolatro. Eso convierte el texto de este blog y mi perfil de Twitter en los únicos medios desde los que puedo “hablar” o al menos expresarme en público con otros desarrolladores (y otras personas con intereses similares a los míos), en particular de Microsoft, fuera de mi oficina. Fuera del mundo Microsoft lo tengo más sencillo con los Meetups de Software Craftsmanship CLM.

Entiendo que otras personas tienen otros entornos, medios y motivaciones: cada uno tiene su contexto. Y en ese contexto se enmarcan las opiniones que vertemos. De nuevo Twitter no es el mejor modo de conocer este contexto, siendo lo óptimo las relaciones cara a cara durante años, pero eso requiere de unas circunstancias laborales y personales que no tengo.

Iba a usar este texto como inicio para hablar de Eventos técnicos, Ferias, Comunidades Técnicas, Meetups, Open Spaces y demás elementos que parece que mezclamos en algunos eventos como el pasado Techsummit. Es algo en lo que me apetecía pensar (y por lo tanto escribir) tras la discusión desencadenada, pero parece que este prólogo me ha quedado demasiado largo y no estoy seguro de cuando podré terminar de escribir mis opiniones al respecto debido a mis circunstancias personales y profesionales.

En cualquier caso, me gustaría terminar este post ofreciendo mis disculpas a quien quiera que haya podido sentirse ofendido con mis palabras en esa discusión en particular y en las futuras. Al fin y al cabo todos formamos parte de la misma comunidad, y por lo tanto todos queremos lo mejor para esta. De eso no tengo duda.

¿Continuará?…

Igualdad y desarrollo de software. ¿A quién le conviene?

wp_20150201_001

Hace unos días asistía en Twitter a la conversación de varios desarrolladores, MVP, técnicos, etc. acerca de la visibilidad de las mujeres en el evento para desarrolladores Codemotion. Espoleados por nuestro particular Pepito Grillo de la comunidad Microsoft en España Edin Kápic, los comentarios no se hicieron esperar por parte de desarrolladores, MVP o evangelistas de Microsoft como Isabel Cabezas cuya opinión como representante femenina tiene especial valor.

Al final, entre tanto hilo y con la limitación de espacio que caracteriza a Twitter parece que teníamos muchas preguntas e interés en el tema de mujeres y desarrollo de software pero pocas respuestas.
Como parte doblemente interesada por ser desarrollador y padre de una hija a la que me gustaría ver en “ciencias” (STEM), quiero hablar solo un poco (el tema es extremadamente complejo por lo que parece absurdo intentar ir más allá en solitario) de mis opiniones y dudas acerca de si es necesario o siquiera buena idea esforzarse en aumentar la presencia femenina en el sector.

Empezaré diciendo que la vez que más abiertamente he escrito sobre el feminismo fue comentando en junio el documental CodeGirl  y que cobra mayor relevancia con cada evento que persigue la igualdad estadística entre sexos. Y no lo he hecho más a menudo porque es un tema “caliente” que podría volver fácilmente un texto en un problema para el autor, pero con una hija estos temas cobran cada vez más importancia. También, quizá por haber leído Universidad y Ciencia en España, de Clara Eugenia Nuñez  y La Tabla Rasa de Steven Pinker, me surgen serias dudas sobre si es buena idea lanzarse a movilizar mujeres y hombres a la búsqueda de la igualdad estadística, en parte por si estamos resolviendo un problema equivocado y en parte por si provocaremos efectos secundarios no deseados.

En cuanto a mi opinión sobre las mujeres en el software, aunque muchos comentan que todas las desarrolladoras de software con las que han trabajado eran estupendas, yo diré que también las he encontrado muy malas, pero parecen trabajar mejor en equipo en general. De todos modos no he tenido ocasión de trabajar con tantas como hombres ni de lejos así que aquí tengo un sesgo clarísimo, y eso señala un problema o una característica social o del sector que valdría la pena explorar.
Sobre mujeres dando charlas, la única vez que he insistido en que alguien nos diese una charla técnica fue de una compañera de front-end. Ella pensaba que “no era tan buena” pero yo veía evidente que sí y creo que el tiempo acabó dándome la razón. En ningún caso quería incluir mujeres (era interna) sino aprender de los más competentes y en este caso era ella.

Por último, pongamos algunas cosas sobre la mesa:

  1. Hay un interés económico claro y reconocido de aumentar el pool de desarrolladores disponibles para la industria (lean algunos comentarios, son interesantes).
  2. Hay un interés claro de determinadas empresas en aumentar la diversidad de desarrolladores (más allá del sexo) en sus plantillas en pro de la “innovación”. Sea lo que sea eso.
  3. Como sociedad, parece que España es una de las mejores del mundo, muy lejos de la estadounidense.
  4. Desarrollar software no es fácil, y requiere de una dedicación seria con una necesidad de renovación constante que no todo el mundo (sea del sexo que sea) está dispuesto a asumir y mucho menos a disfrutar. Recordemos que los jóvenes quieren ser funcionarios.
  5. Los Estados Unidos son una sociedad diferente, con problemas diferentes a la Española, de los cuales no deberíamos importar soluciones sin más, sin un poco de espíritu crítico, a riesgo de generar nuevos problemas o romper cosas que funcionan, como la sanidad pública.
  6. Hay despidos en empresas técnicas como Microsoft a nivel mundial o HP localmente.

Por tanto, mi opinión actual es que tenemos varias economías nacionales con intereses claros en aumentar y diversificar el pool de desarrolladores. Tenemos también una oleada de problemas “del primer mundo” y soluciones extraídas de la sociedad estadounidense que están siendo importadas prácticamente sin espíritu crítico por colectivos interesados como son políticos (votadme mujeres de 18 a 35 años), empresas de eventos (mujeres, venid a mi evento de pago) y empresas/profesionales de formación (hágase rica programando con mi curso). Sobre la formación además parece que estamos ante una burbuja.
Y por último tenemos a los desarrolladores sin distinción de sexo o edad, que parece que tenemos un incentivo económico para NO aumentar el pool de desarrolladores. Con ello algunos esperan conseguir sueldos un poco más altos (acordes a lo que esperaríamos en otras economías del entorno) o al menos evitar despidos como los de HP por poner un ejemplo. Este último caso deja claro que no hay escasez real de mano de obra técnica, sino de mano de obra barata.

Todo esto debería dar bastante que pensar y hace que me plantee decenas de preguntas. Tantas que he desistido de intentar articularlas o mencionarlas aquí con idea de centrarme en la más importante.

¿Qué problema queremos resolver realmente?

O a nivel más personal y concreto ¿cómo va a hacer más felices a mi mujer y a mi hija el aumento de mujeres desarrollando software?

A la primera pregunta la única respuesta evidente es que queremos abaratar costes a empresas (no a autónomos, ojo). Por favor, si alguien tiene otra, que me la diga, porque yo no soy capaz de dar una alternativa.

A la segunda pregunta no parece que aumentar el número de mujeres desarrollando vaya a tener un efecto beneficioso sobre el futuro de mi hija. A priori, siendo mujer te puede ir mejor si está dispuesta a aprovecharte del sistema y de los sesgos (leyes, micromachismos) aunque imagino (que no veo) que puede tener sus ventajas aumentar el número. Pensando en efectos secundarios lo que veo es un escenario de sueldos peores y mayor competencia, por lo que estaríamos ante la típica carrera hacia el abismo.

Así que, aunque me parece normal y deseable que grandes empresas se envuelvan en la bandera de la inclusión para mejorar ingresos, yo no veo ningún incentivo para que los trabajadores apoyen iniciativas de este tipo, fuera de los sectores de formación, organización de eventos y política (que no es poco). E incluso yendo más allá y reconectando con el tema que abría este post, me pregunto si tienen sentido los eventos técnicos presenciales a día de hoy o si deberían cambiarse a un formato más inclusivo para todos como es el remoto vía Hangouts y similares. Quizá las hololens y otras tecnologías puedan aliviar a eso y permitir que las minorías que no pueden o no quieren viajar a los eventos, formen parte de estos.

Para terminar este artículo, me gustaría dar algo de visibilidad a la iniciativa de Codemotion y a Isabel Cabezas para que aquellas mujeres que quieran dar una charla sepan que son bienvenidas en el Codemotion 2017. Yo por mi parte intentaré organizar una mesa redonda en el Meetup que hacemos regularmente en Toledo, acerca de la inclusión de niños (tenemos padres y tíos) y mujeres (no se animan a venir) en el mundo de desarrollo software.

PD: he tenido que reescribir este artículo tantas veces, para evitar problemas, no dispersarme demasiado y hacerlo digerible, que casi voy a tener que coger unas vacaciones en cuanto lo publique.

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.

Responsabilidades y Cambios

Tras unos cuantos años de trabajo en diversas empresas y para hordas de usuarios, grupos de trabajo, y departamentos, he llegado a formarme una opinión sobre algunas cosas, entre ellas sobre la importancia de la definición de responsabilidades en la empresa (o proyecto o sociedad).

Directivos, mandos, jefes

Pienso que cuando no hay responsabilidades (tareas, límites, autoridad) claramente definidas en un grupo*, suele ser porque no hay nadie responsable** al mando.

Quizá esta idea tenga que ver con lo que pienso sobre la cultura empresarial: que una empresa se comporta como se comportan sus directivos, que son quienes recompensan o penalizan el comportamiento y resultados de sus subordinados, realizando así una suerte de selección artificial de la actitud que debe existir en la empresa.

O puede que tenga más que ver con la imitación de los roles “superiores”, que hacen que tendamos a actuar como el sujeto alfa del grupo. En cuyo caso, si el sujeto alfa es un corrupto y un cretino, la gente tenderá a comportarse como corruptos y cretinos (sí, es una referencia a la España actual). Y si el sujeto alfa tiende a no concretar las cosas y “delega” responsabilidades solo a nivel teórico (no delegando la autoridad real para tomar decisiones, los recursos, etc.) entonces tendremos un montón de subordinados que ni concretan, ni toman decisiones.

Sea como fuere, pienso que para que una empresa funcione, es necesario que existan responsables claros (es decir únicos, y ojo que no he mencionado jerarquía ni rol), en todos los niveles de la empresa. Que no existan zonas grises, o al menos que sean muy pequeñas, donde los vacíos de poder y responsabilidad no permitan (o al menos dificulten mucho) decir “ese no es mi problema”. Porque a mi entender, cualquier problema de la empresa (o proyecto, o comunidad), es un problema de todos, y si al menos una persona no levanta la mano y dice “yo me encargo” cuando aparece un problema, entonces esa empresa tiene un problema gordo.

Toxicidad

El problema gordo es que se trata de un entorno donde la gente no considera los problemas de la organización como problemas suyos, donde se prefiere dejar el “marrón” a otro, donde un cambio siempre es percibido como un peligro… en definitiva, se tratar de un lugar donde se ha generado una dinámica tóxica que daña a todos. Una en la que la gente no se hace cargo de nada porque “no es mi trabajo”, ni considera que tenga que hacer nada al respecto de ningún problema porque “no me pagan para eso”, donde una actualización y mejora de las herramientas genera dramas y tragedias, etc. Una dinámica que se extiende poco a poco por la organización convirtiendo a todo el mundo en personas quemadas, personas desinteresadas por su trabajo, incapaces de adaptarse a los cambios o aportar algo nuevo a su entorno. Una empresa, comunidad o proyecto muertos, que solo aspiran a mantener cerrado su frasco de formol.

Y no es eso lo que yo quiero para la empresa (o sociedad) en la que trabajo (pasada, presente o futura). Y por eso trato de hacer lo posible para que ese tipo de actitud irresponsable** tenga el menor efecto posible en lugar de extenderse como un cáncer. A quien no desea asumir responsabilidades y solucionar problemas lo acabo saltando (sin drama ni a escondidas), y solo le pido que no se interponga en el camino de quien trate de dar soluciones, independientemente de si soy yo quien da las soluciones o cualquier otra persona. En ocasiones he tenido que tomar la solución de una persona que no se decidía a saltar sobre determinados cargos-obstáculo, para desbloquear alguna situación, pero en lo posible prefiero que sea la propia persona la que lo haga, dándole respaldo público, como manera de tratar de cambiar la cultura tóxica por una responsable. Vamos, que si la empresa va convertirse en un nido de indolentes, va a ser a pesar de mí o sin mí.

Personas que obstaculizan

Al hilo del perfil “cargo-obstáculo” (quizá “carga” sea un buen nombre) que no asume responsabilidad y que se interpone en las soluciones, he de decir suelo entenderlo como un perfil circunstancial: cada persona es un mundo y hay multitud de razones personales y profesionales, al margen de las dinámicas aprendidas del entorno (siempre se ha hecho así), por las que una persona se puede comportar así: Desde la necesidad de estabilidad (no quieren cambios ni líos), a la incompetencia percibida (baja autoestima), sin olvidar la existencia de perfiles tóxicos (psicópatas funcionales) que se encargan de dinamitar iniciativas y personas, y que son un tema tan interesante, pero que da para tratarse aparte.

Conclusiones

El mundo es un lugar complicado… porque está lleno de gente. Una empresa es parte de ese mundo y a la vez una representación en miniatura de ese mundo, y por ello el impacto de una sola persona es mucho más acusado de lo que podemos creer en una empresa o comunidad pequeña.

Si somos conscientes de esta relación entre el mundo y la comunidad, y nos fijamos en que es necesario un Lutero, Colón, o Mandela para cambiar el mundo, podemos inferir que en un mundo pequeño como nuestra organización o comunidad, no necesitamos tanto trabajo o audacia para cambiar las cosas y simplemente actuando con responsabilidad y exigiéndola a los demás, simplemente arreglando lo que esté roto o encauzando lo que se desmadre cuando nos sea posible, estaremos cambiando las cosas para mejor. Aunque solo sea un poco.

 

* Entendiendo grupo como: grupo de trabajo, departamento, área, o la empres al completo.

**Entendiendo responsable como: persona que adquiere compromisos que tiene intención de cumplir, trabajando en ellos.

Postdata

Llevaba algún tiempo escribiendo este artículo, pero hasta que no he leído la última entrada de Steven Sinofsky, no he podido terminarlo satisfactoriamente. Creo que me hubiese gustado tenerlo de jefe, aunque nunca se sabe.

Libro: El arte de convencer

DSC00659

Título: El arte de convencer

Autor: Philippe  Breton

Editorial: Paidós

Este libro lo elegí para tratar de realizar mejores presentaciones de SharePoint, una herramienta vasta y compleja que permite solucionar multitud de problemas y mejorar la colaboración entre personas.

Como es de esperar, algo que trata acerca de colaborar (como es SharePoint) y cubre un extenso número tecnologías y problemas, necesita (entre otras muchas cosas) de una gran labor pedagógica y buenos argumentos, no solo venderse o para vencer la resistencia al cambio de los usuarios corporativos, sino para hacerlo funcionar bien.

Así que movido por esta inquietud me terminé el libro, pero me temo que no ha resultado tan útil para mis responsabilidades con SharePoint como esperaba. Pero no es un mal libro.

Genérico y teórico

Sí, se trata de un manual sencillo para argumentar. Y sí, puede usarse para mejorar las presentaciones y las discusiones, pero… es genérico y bastante teórico. Y por esta razón es interesante a nivel conceptual, pero su utilidad inmediata es muy reducida.

Esencialmente podemos extraer de él algo de historia de la dialéctica, un mapa o guion de cómo empezar a plantear una argumentación y algunas indicaciones generales de lo que puede funcionar o no. Por ello puedo recomendarlo para replantear las bases de presentaciones y discusiones, pero no para ponerse a argumentar inmediatamente.

A mí al menos me ha resultado útil para descubrir que planteo la argumentación de una manera bastante adecuada (con algunos errores por supuesto) pero que la he llevado mal a la práctica en multitud de ocasiones sin darme cuenta, y solo por saber eso, merece la pena leerlo.

Ética y manipulación

Quizá lo más reseñable del libro, fuera de su utilidad, sea que habla de la dialéctica y de su ética. Y es que parece que Breton está tan interesado como yo en evitar la manipulación. Tanto es así que deja en muy mal lugar a la PNL (con la que tampoco comulgaba yo antes) y comenta una y otra vez las diferencias entre argumentar y manipular. Un tema que muchos no tienen claro, en ocasiones por puro interés egoísta (vende motos, comerciales sin escrúpulos…) y en otras por lo que creo que es miedo y desconocimiento.

Citas

Para terminar esta breve reseña, añado unas cuantas citas que me gustaría recordar en el futuro:

Entonces ¿todo el mundo debe pensar lo mismo? Por supuesto que no, pero cuando debe tomarse una decisión en común, y la vida proporciona infinidad de ocasiones para ello, resulta necesario discutir, confrontar los puntos de vista. No se trata de alcanzar un consenso, pues el consenso suele ser una decisión desacertada con la que todos están de acuerdo. Se trata, por el contrario, de defender una opinión no solo porque creemos que será la más adecuada, sino porque los demás o al menos la mayor parte de ellos, podrán sumarse a la misma aunque sea de forma provisional. En democracia toda decisión, sea política, conyugal o familiar, es susceptible de ser criticada y posteriormente modificada.

-o-

[Acerca de la regla de la simetría y la igualdad entre el que argumenta y su interlocutor]

Este principio e igualdad tiene una consecuencia específica importantísima en lo que al plano técnico de la argumentación se refiere. Puedo dirigirme a cualquier persona, tratar de convencerla, proponerle múltiples argumentos, siempre y cuando esté claro, explícita o implícitamente hablando, que mantengo un debate con ella. En tal caso, la probabilidad de que yo mismo cambie de opinión debe estar integral y visiblemente abierta.

En esto radica la gran paradoja de la argumentación. Movilizo todo mi vigor, toda mi energía, toda mi influencia para convencer a alguien, pero mi interlocutor es efectivamente libre de abrazar o rechazar lo que les propongo, y además sus argumentos pueden hacerme cambiar de opinión.

-o-

En demasiadas ocasiones queremos convencer a los demás considerando que estamos en posesión de la verdad y que el otro simplemente ha de someterse a ella. La argumentación como competencia democrática implica el autocuestionamiento, así como la apertura a los argumentos ajenos.

-o-

[Acerca de la manipulación como la que ofrece la PNL o la mímica corporal]

Entonces ¿el manipulador oculta lo que está haciendo?

Sí, este punto es esencial […] Lo importante es aquí que Smith no sabe por qué ha sido convencido. En cierto modo está hipnotizado. Dice que sí porque se siente bien, relajado, y porque a lo largo de la conversación quienes querían convencerle fueron muy simpáticos con él. Puede firmar el contrato de inmediato, ¿pero mañana? Una vez concluida la influencia directa, una vez liberado de la fuerza de atracción que ejercen sobre él sus interlocutores, es capaz de reponerse y cuestionar la certeza del día anterior.

¿No ocurre lo mismo con la argumentación?

No, pues quien argumenta proporciona buenas razones. Si al día siguiente el interlocutor se pregunta por qué cambió de opinión, estas buenas razones, aceptadas e integradas el día anterior, le servirán de referencia. La cuestión es, en efecto, el día siguiente. Es en ese momento cuando se analiza la eficacia de la argumentación. Por esta razón algunos aconsejan siempre “consultar con la almohada toda decisión que se va a tomar” es decir, tomarse un tiempo para la reflexión alejados de toda influencia.

-o-

El gran éxito de los manipuladores es hacer creer que sus técnicas, que generalmente están al servicio de un objetivo comercial, son eficaces. A corto plazo incluso logran vender libros o programas de formación. Pero las personas formadas en dichas técnicas suelen sembrar la discordia y son responsables de una pérdida real de productividad en las empresas donde ejercen sus talentos.

Un día habrá que sopesar el coste que supone para las empresas en pérdidas reales formar a parte de su personal en técnicas que deterioran considerablemente el ambiente y la calidad de trabajo. [Esto me recuerda a Vodafone]

-o-

[Sobre un caso típico de persona que  va a hacer una presentación]

Robert conoce el expediente de memoria, lo tiene en mente, pero también en pequeñas fichas perfectamente ordenadas que recogen parte de los hechos que a su juicio ilustran la necesidad de crear un nuevo servicio. Por tanto, Robert no cree necesario preparar su intervención. Todo está listo en su mente. Por otra parte, es consciente de que, incluso conociendo el expediente a la perfección, por lo general tiene dificultades para convencer a los demás. Abrumado por esta situación, prefiere no pensar en ella de antemano. Además un exceso de preparación equivaldría para él a una manipulación, y Robert pretende ante todo ser honrado, convencer sin artificios o trucos. Bastará con los datos técnicos, en torno a los cuales mañana improvisará.

Robert es, sin lugar a dudas, un buen profesional, pero se equivoca sobre este punto concreto y esencial. Cree que conocer el expediente y, eventualmente, los elementos que en su momento le convencieron a él, será suficiente para que el grupo y el director adopten su idea.

-o-

[Acerca de las diversas etapas de la argumentación]

Dicho protocolo se desarrolla en cuatro etapas:

  • La invención
  • La elocución
  • La disposición
  • La acción

La primera etapa, la invención, consiste en plantearse a quién nos dirigimos con el fin de encontrar un ángulo de acercamiento y los puntos de apoyo adecuados. […]

Pasemos ahora a la segunda etapa [elocución], reflexionar sobre el tipo de argumentos que se van a utilizar. Aquí se trata de determinar las palabras exactas, las expresiones y las metáforas que vamos a utilizar. Es el momento de especificar y preparar el contenido de la exposición. Tengo que saber de antemano lo que voy a decir. […]

La tercera etapa [disposición] consiste en organizar en el tiempo la toma de la palabra. ¿Por dónde debo empezar, qué argumentos deben colocarse al principio y cuales al final? ¿Qué orden adoptaré para lo que voy a decir? Esta pregunta es trascendental porque condiciona la eficacia de las palabras, ya que presentarlas en desorden sería una incongruencia.

La cuarta etapa corresponde al momento de anticipar la acción, es decir, el momento a partir del cual hablaremos de manera específica. Las preguntas que se plantearán entonces serán tanto de orden material (¿funciona bien el micro?, ¿está la audiencia cómodamente instalada?) como referentes a la elocución (¿Cuál es el tono más apropiado?) o la presentación de uno mismo.

-o-

[Acerca de las pelotas de goma antidisturbios y el eufemismo con que nos referimos a ellas para reajustar la percepción de estas como elemento peligroso]

La denominación se inventó, evidentemente, para convencer al público de que este tipo de municiones son, al fin y al cabo, bastante inofensivas. La asociación de la pelota y la goma nos remite en cierto modo a nuestra infancia, recordándonos los juegos de aquellos días felices. Sin embargo, en realidad estamos hablando de canicas de acero recubiertas con una delgada capa de plástico duro y disparadas con un fusil. Ya son innumerables en el mundo entero las víctimas de semejantes proyectiles fallecidas o gravemente heridas. En este ejemplo, el reajuste atenúa hasta tal punto el aspecto mencionado que ni siquiera aparece. Ya no se trata de un argumento, sino de una expresión manipuladora.

-o-

¿Por qué no puede utilizarse en la argumentación la estructura de la disertación?

Se trata sin duda de una buena estructura para sopesar los pros y los contras, para explorar un asunto de letras o de filosofía. Consiste simplemente en demostrar que se sabe todo sobre un asunto, con independencia del público al que nos dirigimos. Pero no es en modo alguno una estructura que permita defender una opinión, compartirla con los demás y por consiguiente convencer a una audiencia.[…]

Utilizar la secuencia “introducción – tesis – antítesis, síntesis – conclusión” al tomar la palabra […] se trata de uno de los mayores errores que se deben evitar en este campo.

-o-

En la cultura clásica de la argumentación, la toma de la palabra se compone de cuatro partes:

  • Se inicia con el exordio, momento en que se intenta captar la atención de la audiencia y obtener su benevolencia.

  • Prosigue con una frase denominada “exposición de la opinión” (narratio) ¿De qué se está hablando? ¿Qué está en juego en el debate? Y sobre todo, ¿Cuál es la opinión que defiendo?

  • Viene luego el momento de la argumentación propiamente dicha (que en retórica se denomina confirmatio). Es este el corazón del proceso, en el que se exponen las razones en que se asienta la opinión propia.

  • Y finalmente se acaba con la peroración que intenta recoger sintéticamente todo lo dicho, […]

-o-

[Acerca de la gestión del tiempo en la toma de la palabra]

En este campo la eficacia implica con frecuencia la adopción de un método sencillo, aunque siempre apreciado: anunciar la estructura. […]

Algunos oradores utilizan un subterfugio benigno para propiciar que se escuche su palabra. Por ejemplo, tras anunciar en una presentación oral tres partes de igual importancia en cuanto al contenido, calibran cada una de estas partes de forma que la primera sea más extensa que la segunda, y la segunda a su vez más extensa que la última. Se obtiene así una secuencia temporal de tipo AAA-AA-A. Dicha estrategia toma en cuenta el fenómeno natural de la escucha: el progresivo debilitamiento de la concentración.

-o-

Anunciarlo [la estructura] genera un efecto espectacular y garantizado, además de mostrar algunas cosas esenciales: en primer lugar, que la exposición se ha preparado con esmero, ganando con ello los argumentos en credibilidad; en segundo lugar, que la toma de la palabra no será incontrolable […] y finalmente, que se respeta a la audiencia al no abusar de su tiempo.

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.