Generalistas, Especialistas y Cynefin Framework

IMG_20180422_160246218

Barbie™ es especialista-general. Es (entre otras cosas) astronauta, informática, médico y cocinera. Es especialista en todo, pero desafortunadamente no es real: los seres humanos tenemos que conformarnos con ser, o bien especialista en un conjunto muy reducido de áreas, o bien generalistas en varias.

Dando vueltas a las dinámicas de trabajo de personas con diferentes experiencias, esperaba poder escribir un post que me ayudase a identificar cuándo es mejor ser un generalista o un especialista, o cuando conviene contar con más o menos de unos y otros en un equipo.

El tema podría estirarse mucho y existe una gran cantidad de información sobre muchos de los temas relacionados, pero creo que lo que he escrito en este post es suficiente para mi propósito.

Empleo el término “especialista” en lugar de “experto“, como he visto hacer en otros artículos, porque creo que la diferencia fundamental entre “generalista” y “especialista” es cómo distribuyen su experiencia: el generalista tiene mucha experiencia distribuida en muchas áreas; el especialista también tiene experiencia, pero enfocada en un solo área o nicho. Es decir, no se trata de tener mucha experiencia, sino del tipo de experiencia y conocimientos que acumulamos. Es una diferencia cualitativa.

Es importante entender que no existen los generalista o especialistas puros, todos tenemos un poco de ambos. Y también hay que tener en cuenta que nuestros conocimientos varían con el tiempo en base a experiencias pasadas, situación personal, etc. Lo que impide encasillar a alguien en uno u otro perfil de manera indefinida.

Cómo son Especialista y Generalista

El especialista puede actuar sobre algo en particular en su área de conocimiento. Cree saber mucho o todo de su área y extrapola (generalmente mal) al resto. Tiende a no saber que no sabe. Tiende a intentar actuar en solitario. Tiene seguridad en lo que hace y desconfía de lo que no conoce o se sale de sus mecánicas de trabajo. Tiene una visión parcial y busca optimizaciones locales. Evita los grandes cambios.

El generalista puede dirigir y llegado el caso actuar al tener una imagen del contexto y una base de conocimientos, pero ejecuta de forma menos eficiente que un especialista. Sabe que sabe “poco” y tiende a trabajar desde hipótesis que hay que validar. Intenta actuar en equipo. Duda de todo y tiende a anteponer las pruebas a los argumentos. Tiene una visión holística y sistémica.

Cuándo ser o emplear uno u otro

El generalista será más efectivo al ver la foto completa (o al menos una foto amplia) del problema, su contexto y ramificaciones.

El especialista será más eficiente cuando actúe en su campo, resolviendo un problema concreto y definido de forma rápida y limpia aunque tenderá a ignorar el contexto, generando eficiencia local a costa de la del sistema.

Cómo funcionan los grupos de Generalista y Especialistas

1. Equipo de generalistas. Efectivo pero lento. Dales suficiente tiempo y te resolverán los problemas para siempre. Incluso puede que problemas que ni sabías que tenías. En entornos con muchos interrogantes o cambios, o entornos con mucha integración con terceros, posiblemente funcione mejor que otros.
2. Equipo de especialistas. Eficiente pero inefectivo. Dales problemas concretos y acotados a su área y te los resolverán en poco tiempo. Si no les das instrucciones detalladas de lo que quieres, probablemente te generen problemas nuevos. En entornos estables y bien conocidos y planificados (sota, caballo y rey) posiblemente funcione bastante bien.
3. Equipo con más generalistas que especialistas. Frustración de los especialistas ante la falta de velocidad o exceso de “charla”. Efectivo pero lento. Habrá fricción entre unos y otros y puede que sobrecarga de los especialistas en determinados momentos. Parálisis por análisis en según qué casos.
4. Equipo con más especialistas que generalistas. Tendencia a actuar antes de pensar. Frustración de los generalistas al disparar antes de apuntar. Fallos de coordinación e integración. Tendencia a mantener la gente ocupada y a obtener resultados técnicos en lugar de obtener resultados de negocio.

El contexto es importante

Hace tiempo que quería hablar del marco de trabajo Cynefin tras leer sobre él en los blogs de Jerónimo Palacios y Javier Garzás. El post de Garzás me parece el más claro y simple para quien quiera echarle un ojo, pero en la Wikipedia (en inglés) hay toda una entrada el respecto para profundizar.

Este framework nació en 1999 y actualmente se emplea en ejercicios de formación de Scrum para “entender y explicar por qué distintos enfoques de trabajo y de hacer las cosas, funcionan bien en un entorno y en otro no“.

En esencia es un método de toma de decisiones, y creo que puede servir para identificar cuándo es mejor tener (o comportarse) como generalistas o como especialistas.

En mi opinión, cuando estamos en los dominios Obvio o Complicado, los especialistas son necesarios (quizá en solitario, quizá liderando un grupo o quizá siendo mayoría en el grupo). Sin embargo, para los dominios Complejo, Caótico y la zona Desordenada, parece mejor contar con generalistas.

En mi caso, puedo decir que me gusta el dominio Complejo y tiendo a automatizar todo lo que esté en el Obvio para no tener que hacerlo. La zona Desordenada es algo que detesto, por lo que trato de orientar mi trabajo para salir de ella lo más rápidamente posible. Supongo que todo esto me identifica como generalista.

Conclusiones

En el mundo del software (y todo va camino de ser software), los cambios se suceden con velocidad de vértigo, y por lo tanto la mejor opción parece ser el contar con generalistas para poder adaptarse con agilidad a lo inevitable.

Sin embargo, para poder resolver los problemas más típicos de manera eficiente y que una empresa pueda funcionar en el día a día, es necesario tener al menos un especialista en la operativa o problema más común de la empresa. Por ejemplo, merece la pena tener especialistas en gestión de proyectos si tu negocio se basa en proyectos, o en contar con un especialista de bases de datos SQL si muchos de tu trabajos usan bases de datos SQL.

Todos los trabajos que encajan en el dominio de los Obvio van a ser automatizados, así que es mejor evitar esa zona como la peste.

Para terminar

Como decía al principio, no hay perfiles puros, por lo que mi apuesta es tratar de ser especialista en al menos uno de los problemas más comunes de mi empresa y emplear el resto de mi tiempo y esfuerzo en aprender y experimentar cosas diferentes de esa especialidad. O como dicen los libros de autoayuda: salir de mi zona de confort.

Esto me ha permitido realizar una transición ordenada de algo de decadencia a algo en crecimiento y consolidación. En mi caso he realizado me he ido especializando en desarrollo .NET, despues en desarrollo y adminstración de SharePoint. Desde SharePoint a desarrollo y administración en Office 365 y de Office 365 a Azure, donde el perfil de arquitecto te exige ser un generalista.

Pero eso es otra historia. Y aun me quedan más de 40 años de trabajo. Espero.

 

 

 

Anuncios

Libro: La revolución Blockchain

Título: La revolución Blockchain
Autor: Don Tapscott y Alex Tapscott
Editorial: Deusto

Hacía tiempo que llevaba oyendo sobre Blockchain y Bitcoin, y desde hace bastantes meses tenía las “cadenas de bloques” como “tecnología a analizar“, así que aproveché que es una de las novedades de 2017 de la Biblioteca de Castilla la Mancha para tratar de adquirir una idea general sobre el tema.

El libro está muy orientado a gente de negocio o personas que no estén interesadas tanto en la tecnología como en su impacto, posibles usos y panorama presente y futuro, por lo que posiblemente sea bueno para popularizarlo, aunque yo esperaba algo diferente.
Por otro lado no tiene una redacción o estructura demasiado trabajada, aunque creo que esto se debe más a que el tema es demasiado amplio y “nuevo”, como para poder hacer un libro disfrutable a nivel narrativo. Supongo que predecir los posibles futuros de una tecnología fundamental es más complejo que narrar su auge.

Al acabar esta masiva recopilación de empresas, posibles problemas y aplicaciones, ideas de negocio y opiniones, hay una cosa que me ha quedado más clara todavía que cuando lo empecé: esta tecnología, el Blockchain, va a suponer un cambio en la forma en que funcionan las cosas. No tengo ni idea de cuánto tardará, ni de que formas finales adoptará (porque no va a haber un único Blockchain), pero tiene el potencial de ponerlo todo del revés, como ya hemos visto en otras ocasiones con los PC e internet (Microsoft y Google), los smartphones y las apps (Apple o Twitter), el cloud y los servicios online (Amazon, Spotify o Netflix).

Por otro lado, sospecho (como la mayoría supongo) que estamos en una burbuja que en algún momento reventará, pero igualmente me he hecho con unos décimos de Ethereum para ir aprendiendo de esta tecnología creada por Vitalik Buterin, para servir de algo más que mera moneda para la especulación. Veremos si su creador acaba como Linus Torvalds o más bien como Markus Persson. Y por supuesto tendré que ponerme a ver qué ofrece exactamente Microsoft en su plataforma de Blockchain como servicio.

Sea como fuere creo que los próximos años van a ser interesantes y muy movidos e imagino que este libro puede preparar a la gente para prepararse para entender mejor todo lo que va a suceder.

Para acabar, en esta ocasión no voy a intentar poner citas sobre el libro para animar a su lectura o facilitar referencias futuras. Lo que cuenta es tan amplio y la información detallada sobre todo lo que cuenta es tan accesible y probablemente tan efímera que solo tiene sentido animar a leer el libro a quien quiera, como yo, saber algo más de qué es eso del blockchains, las criptomonedas y el final de la banca y las finanzas tradicionales. Pero si alguien quiere un resumen, hará bien en ver la charla Ted que dio Don Tapscott: Cómo la cadena de bloques está cambiando los negocios.

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 SwCraftersCLM GDG Toledo y los ánimos que me han dado desde esta comunidad para publicar el “timeline de desarrollo”, he terminado una versión 1.0 1.2 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 2018.

El Excel es el siguiente: Developer Timeline 1996-2017

¿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.

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.

Documental: CodeGirl

codegirl.PNG

 

Título: Codegirl
Ficha IMDB: http://imdb.com/rg/an_share/title/title/tt5086438/

Hace unas semanas estuve viendo Codegirl, un documental en Netflix acerca de un concurso mundial de desarrollo de aplicaciones donde solo pueden participar equipos formados por chicas.

Se trata de un documental irregular y que al menos a mi no me enganchó demasiado pero que aun así resulta interesante desde el punto de vista de la igualdad de género, la ausencia de mano de obra en software, los concursos de apps y las diferencias entre países desarrollados y en vías de desarrollo.

Uno de los momentos más memorables para mí se produce cuando uno de los equipos de desarrollo, chicas blancas, americanas de clase media en lo que parece un buen barrio, se da cuenta de lo mucho que contrasta su proyecto, (una app para evitar que los adolescentes borrachos tengan un accidente al coger el coche) respecto a la app de otro de los equipos en Europa del Este, que pretende facilitar el que la gente pueda localizar fuentes de agua potable. Se trata de dos mundos diferentes: uno donde el mayor problema es que los jóvenes tienen tiempo libre y dinero para obtener coches y alcohol en grandes cantidades. El otro es un mundo donde conseguir agua potable es difícil y consumirla peligroso.

La verdad es que me hay dos cosas que me dan cierta envidia tras ver el documental: la primera es ver personas altamente y motivadas llevando a cabo un proyecto que les apasiona. Ver a gente así de motivada y feliz con un proyecto es difícil hoy día, al menos en mi sector. La segunda cosa que me produce envidia es ver un equipo de personas con un montón de tiempo para llevar a cabo sus proyectos. Supongo que como adulto trabajador, padre y esposo esto será compartido por muchos otros.

Para terminar, la experiencia de ver este documental se hace interesante siendo, como yo, desarrollador de software y padre de una niña. Y me gusta ver que mi trabajo, tildado de friki en mi entorno (al menos tradicionalmente), se trata con normalidad, incluso como algo perfectamente femenino y con una dimensión social. Esto me hace pensar que quizá la próxima revolución en el mundillo del desarrollo no se deba a una nueva moda tecnológica, sino al cambio que provocará la inclusión de cada vez más mujeres en él.

 

Menos es más. Personas, problemas y herramientas

WP_20151225_001

Disclaimer: Este post no pretende ser divertido, ni entretener. Se trata de mis reflexiones más o menos estructuradas acerca de productos, gestión de proyectos, implantaciones de software, escalar procesos, mejorar organizaciones y en definitiva, cómo trabajar mejor.

Simplicidad

Cuantos más objetivos hay en un proyecto, más complicado es cumplirlos.

Cuantas más personas haya implicadas, más difícil es coordinarlas y más opiniones deben ser tenidas en cuenta.

Cuantos más largos son los periodos entre desarrollo y producción, menos feedback recibimos, menos útil resulta y por tanto más difícil es cumplir los objetivos del proyecto.

Cuanto mayor sea el presupuesto de un proyecto, mayor número de personas tendrán que implicarse en él y más objetivos necesitará para justificar su arranque.

Cuanto mayor sea el presupuesto gastado más difícil (políticamente) se hace cancelar un proyecto fallido o innecesario.

Con estas premisas, suposiciones o experiencia, podemos deducir que en los proyectos de software, menos es más, y por lo tanto tener claro estos consejos, best practices o máximas, para mejorar nuestros resultados:

  1. Focalízate en un único objetivo.
  2. Entrega un MVP lo antes posible al menor número de personas posible.
  3. Itera en base al feedback y amplía el alcance.
  4. Evita lastre, reduce la inercia: personas, presupuestos, objetivos, tiempo.

Variabilidad

Si puedes hacer algo siempre de la misma manera o buscando el mismo resultado, puedes llegar a perfeccionar tus procesos hasta el punto de acortar tiempo y coste cada vez que hagas lo mismo o busques el mismo resultado.

No importa lo complejo del proceso: siempre y cuando no varíe puedes automatizarlo, convertirlo en un hábito, en un acto reflejo. Eso significa que reducir la variabilidad conducirá a mejorar el resultado de tus procesos y por extensión de los proyectos que los requieran. También se deduce que la variabilidad afecta negativamente a los procesos y por extensión a los proyectos que los requieran.

Un proceso automático es un proceso optimizable (es repetible, medible, comparable y se puede cambiar) y uno que no necesita a nadie para realizarse por lo que además puede escalar (no importa si tienes que ejecutarlo 1 vez o 1 millón de veces). Si está completamente automatizado ni siquiera necesitas que nadie lo entienda por lo que tampoco requiere formación o esta es mínima.

Para reducir la variabilidad necesitas reducir opciones, simplificar: menos objetivos, menos personas, menos tiempo, menor coste, todo debe ser lo mínimo posible.

Para lidiar con la variabilidad restante, necesitas entender la naturaleza de esta, sus causas, y así tratar con esta en su origen, ya sea eliminándola, resolviéndola o minimizando su impacto.

Productos

Uno de los motivos por los que el software como producto dé en general mejores resultados que el software a medida (buy vs build) es que la variabilidad es menor. Se “estandariza” todo lo posible y el resto se deja fuera o se trata mediante integración, plug-ins, desarrollos, etc. Esto permite focalizarse en menos objetivos e implicar a menos gente.

Un producto de software resuelve un problema o conjunto de problemas bien definido mediante un número finito de funcionalidades que no puedes modificar a capricho y que siempre actúan de la misma forma (automatismos, estandarización). Esa limitación hace que escale mejor (por estandarización) y esté más optimizado que un desarrollo a medida (por ejemplo: se le hace más y mejor testeo).

Lo anterior deja de ser cierto cuando retorcemos un producto para adaptarlo a un problema para el que no está diseñado. Y pasa mucho, particularmente en productos complejos. Tampoco sucede en “productos” para un solo cliente, que se mire como se mire, son proyectos a medida.

Comprensión

Cuando al tratar de resolver un problema, o no tenemos éxito, o el problema reaparece, o se provoca una sucesión de efectos secundarios al “solucionarlo“, debemos darnos cuenta de que:

  1. No entendemos el problema.
  2. Hay más de un problema.

A partir de aquí tenemos dos opciones:

  1. Nos paramos a analizar los problemas.
  2. Lanzamos “soluciones” (tiempo y dinero de alguien) al problema hasta que estos desaparezcan.

La segunda opción puede no funcionar, o funcionar solo temporalmente o provocar una sucesión de problemas en cascada, así que voy a dar por hecho que continuamos por el camino de pararnos a pensar para entender el problema y elementos adicionales que no hayamos visto antes. Aquí corremos el riesgo de “parálisis por análisis” por lo que deberíamos intentar focalizarnos en objetivos que puedan producir feedback rápido.

Una vez entendido e identificado el problema y sus causas (variabilidad), deberíamos automatizarlo. Digo esto, porque la única forma de demostrar que hemos resuelto un problema es automatizarlo. De otro modo puede que solo hayamos resuelto un único caso particular de un problema. Esto no tiene nada de malo per se, pero no podemos escalar esa solución (aprovecharla en otros casos). También hay que intentar no retorcer los problemas para que nuestra solución sea válida, ni tratar de resolver todos los problemas posibles. Es complicado saber dónde parar para no generar burocracia y sobre-ingeniería.

Por todo esto, deduzco que tratar de resolver un problema (no un caso concreto) sin entender su naturaleza resultará en un fiasco, ya sea reconocido o envuelto en marketing. En el primer caso habremos aprendido algo, en el segundo solo habremos desperdiciado el tiempo y el dinero de un montón de gente.

Conclusiones

Si no entendemos el problema a resolver, tendremos que enfrentarnos a una gran variabilidad y por lo tanto emplearemos una gran cantidad de tiempo y recursos en algo que va a acabar mal, por lo que es mejor que vayamos preparando el marketing.

Esto aplica tanto a tratar de resolver nosotros el problema, como a comprar una herramienta o proceso que resuelva el problema. Este último caso es muy habitual y transcurre del siguiente modo:

  • Fulano tiene un conjunto de problemas que desconoce: X, Y, Z.
  • Mengano tiene un producto que resuelve un problema concreto X.
  • Fulano compra el producto de Mengano pero su conjunto de problemas no se resuelve.
  • A partir de aquí, pueden pasar dos cosas:
    1. Que Fulano se dé cuenta de que tiene problemas que desconocía y trate de aprender más sobre estos para resolverlos.
    2. Que se recurra al látigo, el marketing y cursos de formación para ñapear con el producto de Mengano hasta que la gente se canse o se acabe el dinero.

Si todo lo anterior es correcto, es posible que una forma de detectar cuándo no se entiende un problema en un proyecto de software sea observar lo siguiente (vago y subjetivo, pero identificable si se cuenta con experiencia):

  • Un numero amplio de objetivos.
  • Un número elevado de personas implicadas.
  • Feedback escaso y espaciado (implantación Big Bang).
  • Presupuesto elevado.

Mi última reflexión al hilo de todo esto es que me parece mucho más importante disponer de las personas adecuadas (con experiencia, buena actitud, cultura sana, curiosidad…) que cualquier tecnología. Quizá no sea una gran reflexión, pero creo que es importante recalcar de vez en cuando que la tecnología es la parte menos importante de cualquier proyecto o producto de software.