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

Paradigmas de organización y estrategias de rentabilidad

Hace un par de días estuve consultando (en papel) el “Manual de la sociología del trabajo y de las relaciones laborales” (H.-D.Köhler y A. Martín Artiles) donde me topé con un capítulo titulado “Paradigmas de la organización del trabajo” que llamó especialmente mi atención.

En el capítulo se habla de diferentes paradigmas, entre ellos “taylorismo” y “lean”, muy relacionado con el mundo de la fabricación industrial y las cadenas de montaje pero también con el desarrollo ágil de software.

El libro es descriptivo, no prescriptivo, es decir: solo enumera, describe y comenta contexto, ventajas y críticas de los diferentes paradigmas y sus implementaciones. Pero aun así me ofreció una visión diferente de la que solemos ver en talleres y charlas de desarrollo ágil. Una visión más coherente con la realidad de los equipos que he conocido.

Algunas de las cosas que se comentan son:

  1. Que “ninguno de estos modelos ha funcionado según ‘el libro de texto’ de las escuelas de negocio, ni siquiera los casos de Ford, GM o Toyota”. Esto cuadra con la discusión sobre si hay que adaptar Scrum a la organización/equipo o si no funciona porque “no se está haciendo Scrum de verdad”. En la realidad ningún paradigma se ha seguido de forma “pura”, sino en formas híbridas para adaptarse al contexto.
  2. Las metodologías “lean” derivaron en un ultra-taylorismo. Aun peor que el taylorismo al que pretendía sustituir, debido al control absoluto que establece a base de visibilidad y transparencia. Este control generó diversas críticas en los entornos industriales de los ’90 por el estrés que provocaba en los trabajadores. Cuadra con el sobre nombre de “Hacienda Scrum” que he llegado a oír: Scrum vista como esclavos recogiendo algodón de sol a sol, día tras día.
  3. Existe otro paradigma (el último que comenta) denominado “sistema de producción reflexivo”, también llamado Volvoismo o Kalmarismo por la empresa (Volvo) y lugar (Kalmar) en que nació: la planta Volvo-Udevalla. Al parecer quedó solo en un experimento por diferentes motivos, entre los que están las operaciones contables en que se le imputaban costes ajenos (un clásico de muchas empresas). Al parecer los equipos eran muy autónomos, permitían una flexibilidad enorme en la producción y se asemejaban más a talleres “neoartesanos” que a naves industriales. Un modelo no exento de críticas en cualquier caso.
  4. Se pueden distinguir paradigmas de organización en función de sus “estrategias de rentabilidad”, es decir: según como buscas ganar dinero tiendes a organizar las cosas de una u otra forma. Una empresa que gana dinero por volumen (paradigma fordista) o por reducción de costes (paradigma toyotista), harán cosas diferentes y le irá mal aplicando cualquier otro paradigma. Esto cuadra muy bien con mi experiencia y sé que sin entender esto es fácil aplicar cosas que dañarán a la empresa.
  5. Parece claro que el éxito o fracaso de cualquier organización depende de muchos factores y el paradigma que emplee puede ser tanto una consecuencia como una razón de éxito o fracaso. Los contextos en que se mueven las organizaciones cambian constantemente. La política, el mercado laboral y el estado de la economía influyen y condicionan completamente los resultados y la evolución de las empresas.

Un libro interesante. Como mínimo para consultar algún que otro capítulo.

Para terminar, he generado una hoja de cálculo para tener a mano la matriz de comparación que contiene, sobre paradigmas y estrategias. Porque espero poder darle uso tarde o temprano, pero igual alguien más quiere echarle un ojo:

Paradigmas de organización y estrategias de rentabilidad

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.

Pensando: Problemas y modelos mentales

WP_20150403_045

Es interesante pensar sobre los problemas de los proyectos y posibles soluciones cuando se tiene tiempo, como ahora en Semana Santa, de forma relajada. Este artículo contiene algunas opiniones e ideas al respecto que tengo en la cabeza a día de hoy.

Partir una nuez con una piedra es fácil si cuentas con una roca de cierto tamaño. Pero si divides la roca en trozos que sean de forma y tamaño similar y que sumen el peso total de la piedra (por ejemplo un puñado de arena), no podrás partir la nuez. O al menos la técnica directa (golpear) no funcionará. Se necesita una técnica diferente, por ejemplo usar la arena como material abrasivo para desgastar la cáscara, o compactar la arena en un saco antes de golpear para que actúe como un cuerpo sólido. Es interesante que un único cambio cualitativo en el recurso (fragmento grande de roca VS fragmentos de roca) aun manteniendo el resto de cualidades y su cantidad, inhabilita la solución más obvia y añade nuevas necesidades (tiempo, un saco…).

Otros problemas tales como lanzar una nave espacial necesitan tener ciertos umbrales de trabajo o recursos asegurados para un periodo: independientemente de como lances un cohete (hora, lugar, tipo, carga, ángulo…), necesitarás aplicar energía suficiente durante un periodo determinado si deseas tener éxito. Si no concentras la energía necesaria en forma y tiempo (cohete, toberas y tiempo de encendido), lo más que conseguirás será un cráter humeante.

En el Mythical Man Month de Fred Brookes, clásico entre los clásicos de la gestión de proyectos, se comentaba que añadir recursos a un proyecto no hace más que retrasarlo, y se añadía que “9 mujeres no pueden tener un bebé en 1 mes” como forma de indicar que ciertos problemas necesitan cierto tiempo y dedicación, independientemente del número de personas implicadas.

Con estas analogías quiero recordar la importancia que tiene la dedicación y la concentración de los integrantes de un proyecto en el resultado de este. Concretamente quiere recordar que:

  1. La rotación de la gente dentro de una empresa ya es mala, pero la rotación dentro de un proyecto o empresa es devastadora.
  2. Aunque no haya rotación en el sentido de gente nueva o gente que es reemplazada, el que un proyecto tenga gente entrando y saliendo debido a prioridades cambiantes (y legítimas, como vacaciones, emergencias u otros proyectos), es siempre algo negativo y un hándicap a manejar.
  3. El dedicar a una misma persona a múltiples proyectos (con los problemas de cambio de contexto asociados) provoca una dedicación y atención dividida entre N temas y puede llegar a provocar que un recurso, sobre el papel, esté asignado y trabajando en una serie de proyectos, pero en la práctica puede no estar aportando absolutamente nada a ninguno de esos proyectos.

En mi opinión hay una relación entre estos cada uno de estos problemas, un modelo mental común que los provoca: la idea de que un proyecto informático es un proyecto de construcción. Con esa idea en mente es normal pensar así: un albañil pone X ladrillos por hora, dos albañiles deberían poner el doble y acabar la obra por tanto en la mitad de tiempo. Es fácil también pensar que lo que hace un albañil o un fontanero, lo puede hacer otro en un tiempo similar. Es fácil pensar que cambiar al albañil de planta en el edificio no tiene ningún impacto, avanzará a la misma velocidad poniendo ladrillos en la primera planta que en la cuarta.

Y el desarrollo de software no funciona así.

Ese modelo mental del desarrollo de software que lo considera una actividad de “construcción” podría llegar a ser válido quizá montando un CPD, o plataformando equipos, actividades también informáticas. Sin embargo el desarrollo de software es un proceso de diseño, y los procesos de diseño requieren sobre todo de tiempo, toneladas de comunicación y mucha investigación para responder al “por qué” del proyecto con una implementación. Un proceso de diseño es conversación, experimentación, preguntas y respuestas. Por eso Agile siempre me ha parecido no solo una buena idea, sino la única que puede funcionar: porque está orientado a la comunicación, a hacer preguntas y obtener respuestas.

Agile, el desarrollo ágil de software, articula esa comunicación mediante ciclos cortos, sprints, reuniones mínimas, TDD, simplicidad… Todo está orientado a tratar de obtener feedback de todas las partes (Pair Programming, entrega continua…). Todas esas técnicas y conceptos empleados: stand up meeting, lean, kaizen, kanban… Todo es un reconocimiento de la misma idea: estamos diseñando algo y reconocemos que no sabemos realmente como debe ser, así que tenemos que experimentar, dialogar y descubrir.

Agile es un reconocimiento tácito de ese modelo de mental del desarrollo de software como proceso de diseño. Pero eso no evita que se use como herramienta de márquetin, vaciándose de contenido y manteniendo la forma, lo “barato” y “visible” para poder vender certificaciones, proyectos “con las mejores metodologías” y “mejores procesos” que no son más que cosméticos. Ante esa pérdida de sentido, ante ese deterioro del término, hay poco que hacer sin mucho trabajo, pero este es doblemente complicado cuando estamos frente a personas que piden “agilidad” mediante la adición de recursos extra a proyectos iniciados. Personas que piden “agilidad” en proyectos llave en mano de precio cerrado. Personas que piden “agilidad” dedicando lo mínimo posible de su tiempo al proyecto. Ante esas persona está claro que no se está haciendo ni pidiendo Agile, sino solo la apariencia del mismo, bien porque no se quiera (por diferentes interese) o bien porque se haya malentendido Agile como un producto a seguir ciegamente (metodologías fijas, certificaciones y márquetin), en lugar de como una serie de medidas de sentido común cuando el modelo mental es el de desarrollo de software como proceso de diseño.

Y aquí lo dejo. El tema de los modelos mentales, las metodologías y la comunicación son temas complejo y hay cientos de libros sobre esos temas, eventos y experiencias reales comentadas en multitud de sitios. Con este artículo solo me he limitado a pensar sobre varios temas relacionados y espero que animado a otros a pensar sobre ello. Quizá pensando entre todos, podamos hacer más felices a equipos y clientes. Y serlo nosotros mismos claro.

Libro: Confessions of an IT Manager

itmanager

Título: Confessions of an IT Manager

Autor: Phil Factor

Editorial: Simple-Talk Publishing

Este libro es un simple ejercicio humorístico orientado especialmente a administradores de bases de datos, pero supongo que el resto de profesionales del mundillo informático también podemos disfrutar sus historias, como ya hacemos con Wardog.

Escrito bajo pseudónimo (Phil Factor), el narrador compila una serie de historias cortas que jura han sucedido de verdad. Aunque en algunos casos podría pensarse que es así, obviamente todas están deformadas y exageradas, bien por ganar en gracia, bien por proteger la identidad de los confesos. El resultado es una compilación de cuentos cortos para informáticos que entiendan la lengua de Shakespeare y tengan ganas de leer algo del sector, pero no técnico.

Poco más se puede decir sin reventar las historias, solo que más de uno se verá reflejado en alguno de los personajes y situaciones narradas, porque ¿para qué vamos a engañarnos? La realidad siempre supera a la ficción

PD: Este libro está disponible de forma gratuita en la web de Red Gate, una empresa que se dedica a vender productos de software y formación y parece que también consultoría, orientada sobre todo a la administración de bases de datos.