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

Iberian SharePoint Conference 2013

Conocí la iniciativa de la Iberian SharePoint Conference, de boca de Edin Kapic en el Dev Camp (Madrid) que organizó Microsoft en Marzo de este año para desarrollo de Apps para SharePoint. En aquel momento Edin estaba preguntándose cómo sacar adelante un evento de estas características y me pareció una buena idea: al fin y al cabo SharePoint es una plataforma tan enorme, compleja y con una evolución tan rápida, que todos los implicados en la plataforma necesitamos salir de muestras cuevas de vez en cuando para ver qué hacen los demás, cómo y por qué, a fin de mejorar nuestras técnicas y formas de trabajo.

Así que cuando vi la oportunidad de ir, no fue muy difícil defenderlo en mi empresa que, como Partner Cloud de Microsoft en 2013 que es, desea mantenerse en la cresta la ola de todo lo que Microsoft tenga en “La Nube”.

Finalmente, y un tanto in extremis por la cantidad de trabajo que tenemos en marcha, pudimos apuntarnos dos desarrolladores a la conferencia, quizá la parte más interesante si ya has acudido a los Dev Camps y te falta tiempo (como en mi caso) para acudir a los talleres.

Planificando el tiempo disponible

Aunque me hubiese gustado acudir a todas las conferencias, especialmente a las de negocio dónde se sorteaban dispositivos caros (*guiño*), tuve que elegir entre las que se realizaban en cada momento en las 3 salas disponibles y dejar alguna de lado para poder hablar con algunos asistentes o ponentes como Mary de la European SharePoint Conferente, Raúl de VSAnywhere, Paul de K2 o Juan Antonio un SharePoint Developer afincado en Murcia, por lo que terminé asistiendo a las siguientes:

Calidad y cantidad

Al ser la primera convocatoria de este evento, me pareció normal que empezase más como una introducción que intentando ser algo súper técnico y profundo. Más aun teniendo en cuenta que SharePoint 2013 lleva muy poco con nosotros y muchos de los asistentes quizá no hayan tenido la suerte de usarlo en producción (mi experiencia es que es una gozada frente a las versiones anteriores). Aun así mi interés fue creciendo conforme pasaban las sesiones tocando una amplia variedad de temas. En particular, el último tercio, con Luis Ruiz, David Martos y Adrián Díaz, fue el que más me gustó. En parte porque era menos “introductorio” y la gente parecía más centrada pero sobre todo porque los oradores son particularmente divertidos en sus exposiciones. En particular, me sorprendió gratamente David que, hablando de un tema como la gestión de vida de las aplicaciones (ALM, un tema realmente serio), arrancaba más risas que un monólogo del club de la comedia.

Conclusiones

La primera conclusión que saco es que me gustaría acudir a la próxima conferencia. Una que será más técnica una vez superado este buen arranque y donde habrá caras familiares por lo que empezaremos a formar más una comunidad real.

La segunda es más personal e introspectiva: ver todo ese trabajo, escuchar a todos esos profesionales, ver ideas y demos… hace que me reafirme una vez más en la idea de que trabajo rodeado de gente muy capaz, y de que el trabajo que hago, aunque a veces se vea o entienda poco, está hecho como debe hacerse. A menudo mejor de lo que cabría esperar dado el nivel de recursos y la complejidad de algunas soluciones (no solo en el plano técnico).
Por esto, acudir a este tipo de eventos me ayuda a mantener la conciencia tranquila frente a la multitud de decisiones de arquitectura y diseño tomadas en diversos problemas durante estos años. Además es reconfortante oír a un buen puñado de profesionales mejores que yo, decir casi palabra por palabra lo mismo que he dicho durante años basándose únicamente en mi conocimiento, experiencia y fuero interno. Solo lo puedo apreciar yo, pero se agradece.

Y por último, dado el número de asistentes, parece que SharePoint es una plataforma con mucho uso y que dada la velocidad de evolución que tiene y las tecnologías que van apareciendo, va a seguir dando guerra durante bastante tiempo. Va a ser una época interesante para estar en SharePoint y en particular en Online.

Pegasus vuelve al servicio

La semana pasada, Pegasus, mi servidor doméstico, dejó de iniciarse. Todo apuntaba a fallo de disco duro, y efectivamente la partición de arranque estaba más corrupta (por causas físicas o lógicas, aun no he intentado determinarlo) que el gobierno de Camerún.

Pegasus había cumplido diariamente y durante años fielmente como servidor de archivos, impresión, escaneo centralizado, servidor web, servidor de FTP y emule centralizado. Todo ello bajo un sistema operativo Windows 2000 completamente parcheado, pero el tiempo no perdona, y la única opción viable (dado que no tenía tiempo ni herramientas para analizar en profundidad el disco… se admiten sugerencias) para volver a poner en marcha el servidor, era reinstalar sobre un disco duro nuevo (que extraje de Galactica), lo que nos lleva al motivo de este post, ya que el sistema operativo, dadas mis experiencias pasadas, necesidades actuales y recursos limitados, era obvia: Ubuntu.

En esta ocasión descargué el ISO del DVD de instalación (y LiveCD) Ubuntu, y el proceso de montar el sistema, al igual que en otras ocasiones, fue rápido comprendiendo alrededor de una hora y media para tener el sistema base completo (ofimática, diversas utilidades, navegador, etc) y otra media hora para descargar e instalar todas las actualizaciones. Todo ello sin apenas intervención humana y con unos asistentes la mar de sencillos. Hasta aquí nada reseñable en esta versión del sistema Open Source, ya que siempre se ha comportado así, sin embargo lo que si se nota al iniciar el sistema y usarlo es un evidente cambio de aspecto (a mejor), una mejora de rendimiento (aunque creo que es solo una percepción mía) y lo que parece una mejor distribución de los elementos del menú. También parece, por lo poco que he instalado (Ddclient, Amule, y todo vía Synaptic claro) que el sistema es estable y rinde bien. El único problema que aun no he solucionado es como aumentar la resolución del escritorio o el tamaño del mismo, que parece estar limitado por el monitor (que no necesito ya que lo uso por VNC).

Así que Pegasus vuelve a servir en la flota, y ya que está con Linux pero yo trabajo con .NET, dejo pendiente la instalación de XSP2 para correr aplicaciones ASP.NET 2.0 que me servirá para jugar un poco y seguramente para escribir otro post.