Tabla de contenidos
Hola @TheGoodKnowmad ¿quién eres y cuál es tu rol actual?
@TheGoodKnowmad es Israel López. Actualmente llevo a cabo actividades de muy diversa índole. Por un lado, mantengo mi trayectoria “tradicional” como consultor (palabra que me gusta muy poco por la forma en la que ha degenerado) y formador en materia de estrategia, organización, formas de trabajo y relación IT-Negocio (cuestiones que actualmente caen dentro de ese cajón desastre llamado “Transformación Digital”). Por otro lado, tengo una actividad sobre divulgación y análisis de mercados financieros que comenzó como un side project y que en 2018 acabó dando lugar a Bitácora BEST 21 (@BitacoraBolsa), desde donde contribuyo a ayudar a entender los fuertes fenómenos de cambio político, tecnológico y social que vivimos, y su impacto en personas, empresas, economía y mercados.
¿Qué estudios te han llevado a ser formador de IT – Negocio?
Estudié Ingeniería Superior de Telecomunicaciones. En aquel momento, comienzo de los 90, lo hice más por cuestiones de que “me daba la nota” y “tenía las mejores salidas”. Durante la carrera perfilé mi orientación hacia la telemática, la arquitectura de ordenadores y sistemas operativos y la organización del trabajo tecnológico. Con el tiempo, la formación recibida en la carrera en materia de estadística y economía, también me acabaron siendo muy útiles en lo que ahora es Bitácora BEST 21.
¿Por qué o cómo te decidiste por tu especialidad actual ?
Acabada la carrera, esas salidas tan abundantes de las que todo el mundo hablaba, se daban principalmente en el mundo del software. La carga de actividad de desarrollo de software que tuve durante la carrera fue importante, así que no me costó incorporarme al mercado laboral en este aspecto concreto, si bien mis intereses profesionales eran otros y la consultora en la que comencé trabajando me ofreció la posibilidad de realizar labores de desarrollo de SW en proyectos relacionados con telemática y comunicaciones. Fue muy bonito empezar a trabajar en proyectos tan emblemáticos como el SERA y el IMAGENIO de Telefónica. Ya desde muy pronto observé que había grandes disfunciones en la forma en que las empresas trataban el concepto de desarrollo de software, comenzando por un mal entendimiento de la palabra ”proyecto”, y siguiendo por un uso abusivo del outsourcing y del taylorismo a la hora de organizar equipos y actividades: se estaban aplicando al desarrollo de software paradigmas de organización de actividades industriales (estandarizables y deterministas), obviando la realidad de que el software es una actividad creativa y empírica. Así que pronto busqué la forma de tener influencia sobre estos aspectos.
¿Puedes contarnos brevemente tu trayectoria hasta llegar a tu posición actual?
Como ya dije, muy pronto fui consciente de que existía, a comienzos de este siglo, una gran inmadurez en las organizaciones respecto de la gestión de “proyectos tecnológicos”, especialmente los relacionados con el software . Habiendo comenzado en una consultora, una cosa que me llamaba mucho la atención era la preponderancia que este tipo de empresas daba a las actividades comerciales y la poca consideración que tenían por las actividades técnicas (quizás porque en esos momentos, y debido a cuestiones demográficas, se estaba produciendo la mayor incorporación al mercado laboral jamás vista y las empresas se veían con abundancia de mano de obra técnica con talento y ganas de dejarse la piel). Esto llevaba a que lo importante para las consultoras fuese cerrar contratos, cada vez más agresivos en tiempo y coste, ignorando los criterios técnicos, lo cual acaba conllevando resultados desastrosos no ya sólo en tiempo y coste, sino sobre todo en calidad (tanto del software como de vida de los desarrolladores).
Pero es que además, si uno tiraba del hilo, se daba cuenta de que la causa raíz del problema estaba en los clientes: en qué pedían, en cómo pedían, en por qué perdían. Si uno se paraba a entender el contexto, el negocio y la realidad política interna del cliente, pronto descubría que ningún “proyecto” de los que pedían tenía sentido por sí mismo, sino que había una agenda oculta que casi siempre consistía en utilizar la tecnología como palanca para que un departamento pudiera sobrevivir o ganar preponderancia sobre el resto, (efecto derivado del taylorismo empresarial), basándose en el consabido “la información es poder”. Es decir, los clientes, en concreto los directores de cada departamento, querían desarrollos de software para gestionar su propia información de manera independiente al resto de departamentos. Pero como la actividad de negocio es transversal y no encapsulada en un departamento concreto, esto acabó forzando, por un lado, complicadas integraciones ( “proyectos”) entre los distintos sistemas así creados derivados de la entropía organizacional y, por otro, siguiendo una vez más el enfoque taylorista, la necesidad de un “departamento de calidad” que pusiese cierto orden en ese caos.
Esto, que para mí fue una observación empírica, luego descubrí que tenía nombre: Ley de Conway (que establece que hay una relación directa entre la comunicación que ocurre dentro de una organización y el diseño de la arquitectura de sus sistemas). Influir en los clientes para cambiar un sistema de comunicación y organización del trabajo con una dinámica tan compleja, enraizada en las culturas corporativas desde muchas décadas atrás, y con una componente de juego político tan grande, era algo impensable en aquellos años (donde nadie hablaba de “transformación” de ningún tipo) y más aún para un perfil junior. Para lograrlo, había que establecer una trayectoria y eso suponía tener que trabajar “con” esos sistemas desde dentro, para conocerlos al detalle y entender bien la dinámica de sistemas complejos que son en realidad las organizaciones que piden “proyectos” de software. De esa forma, durante varios años estuve trabajando en posiciones de gestión en grandes clientes de diversos sectores (Telco, Farma, Construcción…) a la vez que estudiando en profundidad los distintos marcos y estándares teóricos de organización del trabajo (mal llamados metodologías) que usaba cada cliente. Así es como acabé certificado en PMP, CoBIT, ITIL, Lean, Six Sigma, DevOps, Scrum o SAFe entre otras (el valor del conocimiento obtenido en esas certificaciones da para otra entrevista aparte, ya que tras lo rimbombante de estos nombres, suele haber una gran deficiencia de profundidad y enfoque práctico en casi todas ellas, incluso en sus niveles más avanzados, algo que puedo decir alto y claro tanto por haber sido alumno como instructor de muchas de ellas).
Pero si de algo me ha servido la transversalidad de esa formación y experiencia en materia de organización, es para saber que no se puede abordar un problema complejo como es la dinámica de grandes organizaciones, con recetas “a medida” ni metodologías de moda. Tras cada marco de trabajo que se presentaba al mercado en forma de moda y solución a los problemas de los marcos anteriores, me preocupé por confrontarlo con la realidad de las organizaciones, encontrando que casi ninguno de esos marcos trataba con la realidad de la Ley de Conway antes expuesta (incluso aunque en esos marcos de trabajo se mencione dicha ley como una realidad inapelable, las propuestas teóricas que realizan obvian su verdadero impacto e inercias).
Toda esa trayectoria es la que finalmente me ha llevado a colaborar en actividades de mejora continua en las organizaciones (a diferencia de hace unos años, hoy ya me niego a llamarlo “transformación”) desde la estrategia (en lugar de proyectos tácticos concretos), con pensamiento sistémico (transversal a toda la organización, en lugar de un determinado departamento o sistema aislado), con enfoque Complex Problem Solving (en lugar de aplicar el recetario simple de la metodología de moda en cada momento) y Kaizen (cambios pequeños de forma continuada en lugar de grandes y costosos programas de transformación).
Todo esto me ha permitido obtener un profundo conocimiento de cómo trabajan las organizaciones y sus negocios en diversos sectores, lo cual me sirvió para establecer una relación directa entre cómo funciona una empresa y su evolución futura más probable, y que junto con el análisis OSINT para entender la evolución de los contextos sociales y geopolíticos en los que se encuadran las empresas, fue de mucha utilidad a la hora de analizar la evolución de empresas cotizadas en bolsa, algo que, como ya dije, nació como un hobby pero que dado el nivel de acierto en los resultados ofrecidos, se ha acabado convirtiendo en otra actividad profesional más.
¿Cuál crees que es la habilidad más importante para ser un buen desarrollador de software?
El software hoy día no es como hace 20 años. A finales de los 90, las consultoras buscaban programadores, es decir, gente que sabiendo un determinado lenguaje, convirtiesen los requerimientos funcionales que les daba un analista o un jefe de proyecto, en código ejecutable. Debido a que el desarrollo de software sufrió la invasión de los enfoques de organización tayloristas, surgieron las SW factories y con ellas la especialización front/back-end/data/testing. Pero eso está cambiando. Cada vez más, muchas empresas se están dando cuenta de que un desarrollo de software no tiene sentido para justificar la existencia de un departamento (para lo cual hay que hacer cosas, las que sean) o el uso de la tecnología de moda, sino que un desarrollo de software debe ser la solución a un problema o necesidad de negocio real.
Esto hace que los desarrolladores de software deban realizar un “shift-left” en el desarrollo de sus habilidades, conocimiento y formación, que han de estar cada vez más orientados a entender el negocio y su realidad, y menos a una tecnología concreta. Hoy día es más importante dominar aspectos como DDD, BDD y TDD, que, aún siendo técnicos, tratan con el dominio del problema a resolver, que especializarse en un determinado framework de programación o una parte aislada del stack tecnológico.
Esta evolución supone un cambio radical en el concepto de evolución de carrera, ya que supone equilibrar la especialización técnica con otras componentes laterales como puedan ser la calidad, la experiencia de usuario final, el diseño e incluso la actividad del negocio, áreas que tradicionalmente no se asociaban al concepto de programador, pero que son cada vez más necesarias para ser desarrollador de software , un perfil que cubre mucha más actividad que la mera programación.
¿Crees que en España se dan las condiciones para desarrollar una carrera de DevOps, o piensas que estamos por detrás de otros países?
Hablar de países no es tan importante como hablar de sectores y tipos de empresa. Con la tan manida Transformación Digital, son muchas las voces que repiten el mantra de que “hoy día, toda empresa, del sector que sea, es una empresa de software” (software is eating the world). Hace 6 ó 7 años, la mayoría de empresas no tecnológicas no dieron seriedad a esto, pero hoy día son muchas las empresas que entienden que esto es así o acabará siéndolo a corto plazo, si bien no son muchas todavía las que en realidad entienden las fuertes implicaciones organizacionales que eso conlleva (empezando por el hecho de que los “Departamentos de IT” y la subcontrataciones dejan de tener sentido, al ser ya el software una actividad core de cualquier empresa).
Se suponía que Agile y DevOps iban a ayudar a las empresas a entender la transformación necesaria, pero en muchos sitios aún estamos muy lejos de ello. Por ejemplo, las consultoras tienen un problema, y es que si las empresas cliente logran de verdad entender los nuevos paradigmas organizacionales, el desarrollo de software acabará teniendo un enfoque de producto realizado por esas empresas (y que será un activo estratégico), y no de proyecto o servicio como hasta ahora. No es de extrañar que sean precisamente las consultoras quienes van por detrás en materia Agile / DevOps (más allá de presentarse a ofertas respondiendo que sí, que harán Agile y DevOps aunque en realidad es waterfall disfrazado). Esa evolución del software como proyecto/servicio a SW como producto, marca la verdadera diferencia a la hora de que una empresa o sector decida abrazar de verdad los enfoques Agile/DevOps o se queden en la mera superficie de dinámicas, post.its y herramientas que lejos de aportar valor, aumentan la entropía derivada de la Ley de Conway al mantener esquemas de organización tradicional (tayloristas,orientadas a proyectos por departamentos) sobre los que se superponen técnicas y herramientas pensadas para funcionar en estructuras orientadas a flujo de valor transversal dentro de la organización.
Respecto de España, mi experiencia es que, a diferencia de hace 10 años donde las consultoras monopolizaban el sector del desarrollo de software, cada vez hay más empresas que deciden adoptar esa mentalidad de producto, si bien sigue sin ser lo habitual y gran parte de los profesionales del sector siguen en bodyshopping de consultoría. Aunque como digo, la tendencia está ahí y es posible que en 5 años el peso de las consultoras se haya reducido a la mitad del que tiene hoy día y muchos profesionales estén trabajando en desarrollo de software orientado a producto, donde los equipos habrán logrado, cada uno en su contexto, encontrar las formas de trabajo que mejor les ayude a entregar valor al negocio. En ese sentido, el futuro es más “tipo DevOps” que “Scrum”, una forma de trabajo cuya tremenda arbitrariedad a la hora de ser adoptada, ha acabado generando bastante rechazo en gran parte de la comunidad de desarrolladores.
Y que el futuro sea “DevOps” implica que el profesional del desarrollo de Software debe evolucionar en el sentido expuesto en la pregunta anterior, lo cual nos lleva de lleno a la siguiente cuestión…
¿Qué puedes decirnos de los métodos de QA en el sector del software?
Contacté con el departamento de comunicación de Talent Hackers por Twitter. Lo primero que debo decir es que me sorprendió muy gratamente la reacción de Talent Hackers a mi rant sobre vuestra publicación en Twitter. Estoy acostumbrado a que cuestionar algo o señalar un error de forma vehemente (y yo lo soy, y mucho) genere una animadversión muy violenta (que yo siempre interpreto como una falta de seguridad en sí mismo/a de la persona que así reacciona). Sin embargo, enseguida se supo ver que una reacción como la mía no se debía a un simple trolleo (hay mucha tendencia a confundir mi actividad en redes con trolleo) sino que estaba apuntando a algo con fundamento y sentido, desde la base del conocimiento y la experiencia. De alguna manera, se supo intuir que mi rant era una llamada de atención en plan “si queréis saber dónde está el error sólo tenéis que preguntar” y no un vulgar desprecio.
En una afirmación como “El Departamento de calidad es propietario del código generado por los desarrolladores”, había varios errores conceptuales. En lugar de querer tener razón, se quiso saber más, y se quiso entender por qué yo cuestionaba su afirmación. Y en los tiempos que corren, tener un agente de comunicación en redes sociales con esa actitud es un verdadero tesoro. No sólo por la evidente buena gestión de un error de comunicación, sino por demostrar verdaderas ganas de mejora continua y querer saber.
La afirmación del tuit que cuestioné, estaba hecha desde un enfoque taylorista de la división funcional del trabajo, que impone tener especialistas en cada fase productiva. Esto, llevado al software, es lo que acabó generando la división entre analistas / front / back / testing, una división que al mundo de la consultoría le vino muy bien porque así podían vender X consultores por cada perfil especialista. Y así han venido trabajando muchas empresas durante mucho tiempo. Y así siguen trabajando aún hoy muchas. Sin embargo, los enfoques Agile / DevOps suponen un “shift-left” de la calidad, es decir, calidad en la fuente frente a calidad observada. Esto hace que la calidad se integre en el desarrollo y recaiga sobre el equipo que está desarrollando, y no sobre un equipo separado de testers (mal llamados QA, ya que en realidad son QC, Quality Control).
Yo he llegado a ver, en la época de mayor auge de las software factories, la fase de testing subcontratada por entero a proveedores “de testing” diferentes de los que realizaron el desarrollo. En una situación así, ¿qué incentivos tienen los miembros de cada proveedor para colaborar si cada uno tiene objetivos diferentes y contrapuestos (desarrollar rápido vs encontrar errores). En Agile/DevOps, y esta es una de las cosas que más les cuesta entender a los “clásicos”, el testing no es una fase separada del desarrollo, sino que es una actividad más del desarrollo, para la cual el equipo ha de elegir la forma más conveniente de llevarla a cabo pero siempre dentro de la unidad que es ese equipo de producto. Sin embargo, he llegado a ver empresas que implementan un peligrosísimo fake agile donde tienen Sprints de desarrollo realizados por programadores y luego Sprints de testing ejecutados por testers, en una clara demostración de que no han entendido nada aún a pesar de haber obtenido prestigiosas certificaciones.
Agile/DevOps no sólo cambia la forma en que se organiza la calidad alrededor del equipo (ojo, así, no al revés), sino que además propone técnicas de desarrollo que incorporan de forma orgánica la calidad, como TDD (Test Driven Development) que, al contrario de lo que muchos creen, no es una técnica de testing, sino de desarrollo. A estas formas de organizar la calidad, se las denomina Built-in Quality, Quality at the Source o Quality First, en referencia a que la calidad está integrada desde el primer momento en el desarrollo, en contraposición con las formas clásicas de testing (Quality Control, Quality at the end).
También es cierto que el esquema tradicional de pruebas unitarias / sistema / integración sigue siendo válido, si bien las formas de trabajo Agile/DevOps modifican su fisionomía con un denominador común: el propietario de la calidad es el equipo de desarrollo y este debe buscar la forma más conveniente para llevarlas a cabo en su contexto de tecnología/producto/negocio (en consonancia con el Agile Manifesto: we are uncovering better ways of developing software…).
Dicho esto, sigue siendo bastante habitual encontrarse en el mercado con contextos software factory waterfall de inspiración taylorista, en donde existen testers especializados únicamente en hacer pruebas y son propietarios de los tests a realizar. Incluso como ya comenté antes, esto ocurre en escenarios que dicen “ser Agile” pero que únicamente hacen uso de sus etiquetas, sin llevarlas realmente a cabo más allá de la mera apariencia de un waterfall acelerado al que llaman “híbrido”.
La coexistencia en el mercado de esta tríada de ambientes de trabajo (Agile/DevOps, Waterfall/taylorista e Híbrido/Fake), es la que hace que el profesional del desarrollo de software sufra no pocas veces de una severa disonancia cognitiva entre lo que le enseñan en ciertos cursos, lo que lee en ciertos libros, lo que escucha en ciertos eventos, lo que piden en ciertas ofertas y lo que finalmente se encuentran en sus entornos laborales. Y aunque el futuro pinte poco a poco cada vez más “DevOps like”, no parece claro que esta tríada sea simplemente un estado intermedio o de transición. Al contrario, es muy posible que dicha tríada se mantenga en el mercado al menos durante una década.
¿Qué principales diferencias nos puedes mencionar con QA en otros sectores?
Primero de todo habría que dar una definición de lo que es Quality Assurrance, Mientras respondía a esta cuestión, en mi TL de Twitter apareció esta buena reflexión de @pavazomor (Patricia Vázquez): “El tener un lenguaje común es muy importante para entender que es lo que estamos haciendo, si yo digo que estoy haciendo una API, tiene que significar lo mismo para ti. Parece tonto, pero más de una vez las ideas que se proponen son las mismas, pero no se entienden porque no comparten el mismo significado”. Pues esto aplica a todo, porque es muy habitual utilizar un término en la creencia de que significa una cosa cuando realmente significa otra muy diferente. Un ejemplo lo tenemos en los términos Agile o DevOps, pero también, como comenté antes, se tiende a confundir QA con testing o pruebas, aspectos estos pertenecientes al QC (Quality Control).
QA puede definirse como “el conjunto de actividades planificadas y sistemáticas aplicadas en un sistema de gestión de la calidad para que los requisitos de calidad de un producto o servicio sean satisfechos”. La palabra clave es “sistema de gestión de la calidad”, que en sus versiones modernas (derivadas del TQM y que han dado lugar a normalizaciones como p.ej. las ISO) adoptan un enfoque de “calidad integrada”, es decir, son sistemas que buscan asegurar la calidad en todo el proceso productivo (en ese sentido, el QC es una parte del QA).
En los sectores industriales, farmacia o construcción, donde la actividad sigue un conjunto de actividades bien conocidas y secuenciadas, se puede sistematizar la calidad mediante un conjunto de planes. Este tipo de sectores trabajan con estructuras organizacionales fuertemente tayloristas, donde cada departamento es sólo “responsable de su parte” y adolecen de una visión sistémica de la calidad. Por eso se hizo necesaria la creación de un departamento específico que asegurase (de ahí el assurrance) la calidad de manera integrada en todo el proceso productivo y no sólo en cada una de sus partes por separado, creando así sistemas de gestión que son propiedad de los propios departamentos de QA. Además, como el producto final suele ser bien conocido de antemano antes de ser producido, se adoptan enfoques de calidad deterministas (Quality at the end), donde se inspecciona el producto una vez terminado.
Todo esto fue llevado tal cual al mundo del software, replicando estos sistemas de gestión, departamentos incluidos, naciendo así la figura (y el negocio) del testing. Sin embargo, en software, el producto final muy rara vez es bien conocido de antemano (la falacia de la toma de requisitos en software para cerrar especificaciones y alcance, es otro tema que da para una entrevista entera) y en ese sentido surgió Agile como respuesta a la necesidad de una aproximación empírica al desarrollo de software (en vez de la determinista industrial) basada en entregas frecuentes (días o pocas semanas) que habiliten la inspección y adaptación frecuentes del producto, en vez de realizar una inspección final tras una entrega completa al cabo de muchos meses. Ya he comentado antes que en este enfoque empírico (agile) la calidad está integrada en el desarrollo (Built-in quality) en vez de ser una fase separada, y es responsabilidad del equipo en su conjunto, no de una parte específica del mismo.
Sin embargo, y como ya he comentado antes, no son pocas las organizaciones que aún emplean estos sistemas de calidad industrial en sus desarrollos de software. Y ojo, que hay ciertos contextos en el desarrollo de software donde estos sistemas de calidad industrial son no sólo aplicables, sino también deseables, como pueden ser entornos sujetos a fuertes normas de regulación o seguridad, que además se ven obligados a definir requisitos estables en el tiempo.
En definitiva, no hay una respuesta única que cubra todo el espectro de calidad en el desarrollo de software, si bien hay que entender las grandes diferencias de cada enfoque, su utilidad y las necesidades de organización, perfiles, técnicas y herramientas que necesita cada uno de ellos. Y es que, por ejemplo, no es buena idea ”transformar” una software factory tradicional en Agile si la “transformación” consiste en seguir teniendo testers separados de los equipos de desarrollo pero que “son Agile” porque realizan las pruebas en “Sprints de testing”. Eso, lejos de ser Agile, puede suponer un aumento de la fricción entre equipos. Si por la razón que sea necesitas seguir manteniendo una estructura de ese tipo, mejor ceñirse a los esquemas clásicos de los que deriva y desde ellos buscar su mejora continua, en vez de modificarlo todo hasta lograr que parezca lo que no es y nunca será.
Háblanos de Knowmad y cómo se adapta al perfil del software
Comentada ya mi trayectoria, es momento de hablar de Knowmad. Ya he expuesto el camino profesional que he seguido, el cual, en un determinado momento del tiempo, se vio implicado en lograr hacer entender Agile y DevOps a organizaciones donde estas propuestas tienen difícil encaje y entendimiento. Sin embargo, he podido ver cómo al calor de la moda Agile, muchos personas han simplificado «agile» hasta convertirlo en algo que nada tiene que ver con sus verdaderos objetivos (ayudar a los equipos a entregar software de valor de manera frecuente y adaptativa). The Good Knowmad nace como una reacción al fake agile y al hype de actividades orientadas “a la felicidad y al sentirse bien” que muchos han confundido con Agile. Si bien es cierto que Agile es un movimiento con un cierto carácter humanista, ya que pone el foco en las relaciones entre personas por encima de procesos o herramientas.
