00:02 Introducción
01:43 Mecanización
07:34 Más allá de la paradoja
12:14 La historia hasta ahora
14:32 Submódulos de hoy
16:24 Requisitos (mainstream 1/5)
20:12 Diseño (mainstream 2/5)
25:37 Construcción (mainstream 3/5)
30:29 Pruebas (mainstream 4/5)
34:09 Mantenimiento (mainstream 5/5)
41:12 Identidad (trenches 1/8)
46:35 Resumen (trenches 2/8)
51:43 Prácticas (trenches 3/8)
56:47 Bastiones (trenches 4/8)
01:02:00 Escritores de código (trenches 5/8)
01:06:23 Tolerancia al dolor (trenches 6/8)
01:14:55 Productividad (trenches 7/8)
01:21:37 Lo desconocido (trenches 8/8)
01:27:00 Conclusión
01:29:55 4.6 Ingeniería de software para supply chain - ¿Preguntas?
Descripción
Domar la complejidad y el caos es la piedra angular de la ingeniería de software. Teniendo en cuenta que los supply chains son tanto complejos como caóticos, no debería sorprender que la mayoría de los problemas del software empresarial que enfrentan los supply chains se reduzcan a una mala ingeniería de software. Las recetas numéricas usadas para optimizar los supply chains son software y, por lo tanto, están sujetas al mismo problema. Estos problemas aumentan en intensidad junto con la sofisticación de las propias recetas numéricas. La ingeniería de software adecuada es para los supply chains lo que la asepsia es para los hospitales: por sí sola no hace nada – como tratar a los pacientes – pero sin ella, todo se desmorona.
Transcripción completa
Bienvenidos a esta serie de conferencias sobre supply chain. Soy Joannes Vermorel, y hoy presentaré “Software Engineering for Supply Chain.” El software es la base de una práctica de supply chain, sin embargo, la mayoría de los libros de texto sobre supply chain subestiman enormemente el papel del software en el supply chain. El software para supply chain no es un mero requisito como el acceso a medios de transporte; es mucho más que eso. Desde la perspectiva de los profesionales del supply chain, la mayor parte del trabajo es impulsado por el software, impulsado por errores de software o por las limitaciones del software, y motivado por inquietudes relacionadas con el software.
La ingeniería de software es la disciplina que tiene la ambición de ayudar a las personas a crear un mejor software, a obtener más del software, a desarrollar este software más rápidamente y a gastar menos para lograr más. El objetivo de esta conferencia es entender de qué se trata la ingeniería de software y comprender su relevancia primordial para el supply chain. El objetivo de esta conferencia también es entender qué, como profesional del supply chain, puedes hacer para evitar mermar tu supply chain, ya sea a través de la acción o la inacción que, desafortunadamente, ha antagonizado tus emprendimientos de software.
El siglo XX ha sido el siglo de la mecanización de la fuerza laboral. Las grandes empresas y los grandes supply chains, tal como los conocemos, surgieron en el siglo XX, y el progreso conseguido mediante la mecanización de la fuerza laboral ha sido increíble. Durante el transcurso del siglo pasado, para casi cada tarea intensiva en mano de obra relevante para el supply chain, como la producción o la distribución, la productividad ha aumentado cien veces.
Por el contrario, creo que el siglo XXI es y será el siglo de la mecanización del trabajo intelectual, y esta transición es muy difícil de comprender. La intuición que se aplica cuando pasamos de la mecanización de la fuerza laboral física no se traduce en absoluto en la intuición que se aplica al pasar a la mecanización del trabajo intelectual. No estoy diciendo que la transición sea menos dramática, pero la realidad es que, en este momento, la transición hacia la eliminación de la fuerza laboral que se encargaba de tareas muy intensivas en mano de obra ya ha quedado atrás.
En 2020, en Francia, había 27 millones de personas con empleos de cuello blanco – esencialmente empleados de oficina – mientras que quedaban menos de un millón de personas que eran trabajadores de fábrica. La proporción es de 27 a 1. Cuando empezamos a observar lo que implica la mecanización del trabajo intelectual, resulta muy sorprendente y está también muy relacionado con una paradoja conocida como la paradoja de Moravec.
Hans Moravec, un científico de la computación, comentó en 1980 que, en lo que respecta a la informática, las tareas que parecían las más difíciles para la mente humana, como convertirse en gran maestro de ajedrez, eran en realidad el tipo de tareas que resultaban más fáciles de abordar con computadoras. Por el contrario, si observamos tareas que parecen extremadamente fáciles para los humanos, como mantenerse erguido sobre dos piernas, esas tareas resultan ser increíblemente desafiantes para las computadoras. Esa es la esencia de la paradoja de Moravec: nuestra intuición sobre lo que es difícil de lograr en términos de tareas intelectuales con computadoras es muy engañosa.
Una cosa que complica aún más el problema es que, de repente, cuando hablamos de la automatización de los empleados de cuello blanco, es realizada por los propios empleados de cuello blanco. Esto no fue el caso de los trabajadores de fábrica de cuello azul; ellos no fueron quienes decidieron que la fábrica se mecanizaría aún más y que sus empleos serían eliminados. Sin embargo, esto es lo que está sucediendo con los empleos de cuello blanco. Así, tenemos un desafío en el que no solo el proceso de mecanización resulta profundamente contraintuitivo debido a la paradoja de Moravec, sino que la gestión de las personas que están a cargo de implementar esta mecanización, es decir, los ingenieros de software, es en sí misma muy contraintuitiva. Este es probablemente uno de los mayores desafíos para el supply chain: la gestión de las personas que estarán encargadas, de una forma u otra, de enfrentarse a esta mecanización.
Aquí, no puedo dejar de señalar que muchos supply chains y las empresas asociadas aún están firmemente anclados en una mentalidad del siglo XX, donde se aborda el mundo corporativo como si tuvieras personas de cuello blanco realizando el trabajo intelectual, y luego ellos presentan la solución o el plan, que se entrega a los trabajadores de cuello azul para su ejecución. Sin embargo, con una proporción de 27 personas por cada uno cuando se trata de empleos de oficina frente a empleos en fábricas en Francia, y probablemente estadísticas similares en la mayoría de los países desarrollados, esta no es la forma en que sucede ahora. Se trata literalmente de automatizar tu propio trabajo, y esto significa que, en este mundo del siglo XXI, los mejores empleados de cuello blanco son aquellos que constantemente logran automatizarse a sí mismos, volverse obsoletos y luego pasar a otra cosa. Esto es muy desafiante para muchas empresas que aún están muy arraigadas en la mentalidad del siglo XX.
Las opiniones divergen ampliamente sobre la noción misma de la ingeniería de software. Una de las críticas más contundentes provino de Edsger Dijkstra, uno de los padres fundadores de la informática. Según su punto de vista, la ingeniería de software ni siquiera es posible como disciplina o campo de investigación, y dijo que se reduce o se devalúa a una especie de receta de “cómo programar si no puedes”. La crítica de Dijkstra, que es muy interesante, es que la ingeniería de software se reduce a una especie de ficción de autoayuda que no puede tener éxito. De hecho, si proponemos que el objetivo de la ingeniería de software es asegurar el éxito en la creación de un software útil y superior, entonces la ingeniería de software está destinada, en su mayoría, al fracaso. El éxito en el software es increíblemente difícil; es tan difícil como el éxito en la ciencia. Se necesita una chispa de genialidad, bastante suerte, y no existe una receta para ello. Además, cada éxito tiende a consumir la misma oportunidad que se necesitó para lograrlo, y así todo se vuelve no replicable.
Sin embargo, no estoy de acuerdo con la visión de que la ingeniería de software está condenada al fracaso. Creo que el principal problema es definir la ambición de la ingeniería de software. Si decidimos que la ambición de la ingeniería de software es lograr el éxito en la creación de software, entonces en efecto está condenada. Sin embargo, si decidimos abordar la ingeniería de software como una rama estrecha de la psicología experimental, creo que podemos obtener, desde esta perspectiva, conocimientos muy valiosos y accionables, y esta es la perspectiva que adoptaré hoy en esta conferencia. Así, la ingeniería de software se trata de los mismos ingenieros de software y sus interacciones. Centrarse en los ingenieros de software es un buen punto de partida porque la naturaleza humana es estable a lo largo del tiempo, a diferencia de la tecnología del software, que está cambiando constantemente. La naturaleza de las personas que luchan con esta tecnología no lo es; la naturaleza humana ha sido muy estable durante mucho tiempo.
Si observamos otros campos, como la ciencia, podemos ver que abordar un campo a través de la inspección de lo que hacen sus profesionales puede ser muy fructífero. Por ejemplo, en la ciencia, es ampliamente conocido que un conflicto de intereses conduce a una mala ciencia y a la corrupción del conocimiento. Este punto se trató previamente en la conferencia titulada “Adversarial Market Research for Enterprise Software.” Desde esta perspectiva, vemos que es posible obtener conocimientos de amplia aplicabilidad y relevancia si nos centramos en los propios profesionales. Así, la ingeniería de software se trata de las personas que se ocupan de la tecnología del software, sus luchas y sus procesos, y no tanto de la tecnología en sí misma.
Hoy es la sexta conferencia de los cuatro capítulos. Este capítulo está dedicado a las ciencias auxiliares del supply chain. Estas ciencias auxiliares representan elementos que creo que son de importancia fundamental para una práctica de supply chain moderna, pero que no son estrictamente elementos de supply chain. Son más bien elementos de apoyo para tu práctica de supply chain.
Hasta ahora, en este cuarto capítulo, comenzamos con la física de la computación, tratando con computadoras modernas, y luego ascendimos por una escalera de abstracciones. Pasamos de las computadoras a los algoritmos, que representan los bits más pequeños e interesantes en el software. Luego pasamos a la optimización matemática, que es de interés para el supply chain pero también para muchas otras empresas de software relevantes, tales como machine learning. Hemos visto que la optimización matemática es directamente interesante para el supply chain, pero también es directamente interesante para el machine learning, que a su vez es también de interés para el supply chain.
En lo que respecta a la optimización matemática y el machine learning, la mayoría de los conceptos y paradigmas interesantes en la actualidad son de carácter programático. No se trata solo de algoritmos simples; es algo increíblemente expresivo y que debe abordarse a través del prisma de los lenguajes de programación. Por eso, la última conferencia fue sobre lenguajes y compiladores.
Hoy, seguimos ascendiendo por esta escalera de abstracción, y nos centramos en las personas en lugar de enfocarnos en lo que están haciendo. Vamos a centrarnos en los propios ingenieros de software, y ese es el núcleo de este análisis de ingeniería de software.
Hoy, presentaré específicamente dos conjuntos de perspectivas sobre la ingeniería de software. Primero, presentaré la visión mainstream, que creo que domina el campo. Desafortunadamente, esta visión mainstream ha generado críticas, como se mencionó anteriormente, con personas que presentan enfoques de autoayuda que algunos, incluido yo mismo, tienen razones para oponerse porque no presentan una ambición realista para la disciplina de la ingeniería de software. No obstante, haré un repaso de esta visión mainstream, aunque sea solo porque algunas ideas equivocadas siguen siendo increíblemente populares. Conocer estos conceptos erróneos es de primordial importancia, aunque sea para eliminar a personas incompetentes que puedan poner en peligro tu supply chain a través de su incompetencia.
Luego, me moveré hacia una visión desde las trincheras, que es una colección de elementos basados en mi experiencia personal como CEO de una empresa de software que resulta operar precisamente en el campo del software empresarial para supply chain. Como veremos, los conocimientos se centran mucho en las personas y no tanto en la tecnología en sí.
La visión mainstream de la ingeniería de software sostiene que una iniciativa de software comienza con la recopilación de requisitos para el software de interés. La mayoría de las iniciativas de software en grandes empresas adoptan esta perspectiva a través de un proceso que típicamente comienza con una Request for Proposal (RFP), Request for Quote (RFQ) o Request for Information (RFI). Este enfoque se hereda de prácticas del siglo XX que han tenido mucho éxito en la ingeniería mecánica y en obras de construcción. Sin embargo, creo que, en lo que respecta al software, estos enfoques para recopilar requisitos están profundamente equivocados.
En el software, no sabes lo que quieres; simplemente no lo sabes. Saber lo que quieres es, invariablemente, la parte más difícil del software. Por ejemplo, si consideramos un problema sencillo como el reabastecimiento de existencias, la formulación del problema es increíblemente directa: en cualquier momento, quiero saber la cantidad que debo reabastecer o reordenar para cada SKU. El problema en sí es sencillo, pero definir qué cantidad es buena se vuelve increíblemente complejo y difícil. Como regla general, clarificar los requisitos es mucho más difícil que escribir la pieza de software en sí.
Solo es al confrontar tu intuición con la retroalimentación que ofrece el mundo real que gradualmente puedes dejar emerger los requisitos. Los requisitos no caen del cielo; sólo se pueden obtener a través de un proceso bastante experimental, y necesitas tener esta interacción con el mundo real. Sin embargo, la única manera de tener esta interacción es contar con el producto de software, ya que recopilar requisitos es fundamentalmente un proceso muy empírico y en evolución. El problema es que, para cuando terminas con los requisitos, disponer de ellos se vuelve irrelevante porque, si los tienes, significa que ya cuentas con el producto correspondiente que implementa esos requisitos. Así que, para cuando tienes acceso a los requisitos adecuados, ya tienes el producto en producción, en funcionamiento, y el hecho de contar con esos requisitos es algo irrelevante.
Así, el punto es que comenzar el proceso desde la perspectiva de los requisitos es, creo, una locura. Probablemente los requisitos deberían venir al final, como documentación de última etapa, en la que se documentan todas las razones fundamentales que te llevaron a implementar el producto tal como lo hiciste, y no al revés.
Una vez que se han establecido los requisitos, el enfoque clásico indica que se debe proceder con la fase de diseño. Estoy de acuerdo en que, en algún momento, puede haber algo de diseño. Sin embargo, el tipo de pensamiento que se invierte en esta fase de diseño es frecuentemente erróneo. El problema se reduce a controlar el costo del cambio. La perspectiva clásica no orientada al software sobre el costo del cambio es que éste aumenta exponencialmente con el tiempo. Por ejemplo, si cambias el diseño de un automóvil muy temprano, cuando sólo manejas un plano, el costo del cambio es mínimo. En contraste, si esperas hasta que millones de esos coches estén en las calles, el costo del cambio es increíblemente alto, ya que implica una retirada, lo cual puede resultar extremadamente costoso.
Sin embargo, a diferencia del ámbito físico, en el ámbito del software, el costo del cambio no aumenta de forma exponencial de manera natural. El incremento de costos no se puede mitigar por completo; no obstante, en gran medida, se puede gestionar. De hecho, el costo del cambio aumenta con el tiempo, principalmente porque las bases de código tienden a crecer conforme pasa el tiempo. Nunca he visto que la base de código de un software empresarial se reduzca significativamente de un año a otro; tiende a seguir creciendo. Sin embargo, es posible gestionar el costo del cambio hasta cierto punto.
Hoy en día, este aspecto está siendo reconocido de forma más general, incluso en círculos de software. Por cierto, esta es la esencia de la metodología Agile. Es posible que hayas oído estos términos cuando la gente dice, “Oh, tenemos esta metodología Agile de software.” Una de las mayores intenciones de la metodología Agile es controlar el costo del cambio. No entraré en detalles hoy acerca de la metodología Agile, pero basta decir que creo que este enfoque es algo equivocado en lo que respecta a cómo exactamente se controla este costo del cambio.
He observado que el costo del cambio se origina principalmente en las decisiones que se toman respecto al software y, más concretamente, en el hecho de que es muy difícil resistir la urgencia de tomar decisiones. Imagina que estás contemplando un posible producto de software futuro, y hay muchas decisiones por tomar. El primer intento sería tomar esas decisiones simplemente para aclarar lo que tienes delante. Por el contrario, una fase de diseño muy buena, más que un buen diseño, es la capacidad de posponer todas las decisiones que no sean absolutamente necesarias, donde el producto no requiere que se tomen esas decisiones de inmediato. De hecho, si no tomas la decisión, mientras ésta no se haya tomado y no hayas establecido que necesitas adoptar este enfoque de diseño o tecnológico específico, sigue en el aire, lista para ser cambiada, ya que nada se ha decidido aún.
Uno de los aspectos para mantener bajo control el costo del cambio es aprender a posponer todas las decisiones en la mayor medida práctica posible. Desde una perspectiva de supply chain, esto se ve muy extraño, ya que significa que para todas las personas en el equipo de software y para todas las que observan el producto y al equipo, parece como si se mantuvieran en la oscuridad. Es incluso peor, porque se les mantiene en la oscuridad a propósito, lo cual resulta muy desconcertante. Sin embargo, es precisamente lo que tiene que suceder, y debe hacerse a propósito. Por eso, es, por decir lo menos, desconcertante.
Ahora, si las decisiones de diseño prematuras se originan en la a veces equivocada necesidad de control, los problemas asociados con dicha necesidad no terminan ahí. Una vez que la fase de diseño ha quedado atrás, la visión predominante sobre la ingeniería de software establece que se debe proceder con la construcción del software, también llamada frecuentemente fase de implementación. La manera típica de hacerlo es presentar algún tipo de proyección en cascada, también conocida como diagramas de Gantt. Esto es lo que puedes ver en la pantalla. Creo que este enfoque, los diagramas de Gantt y las cascadas, es increíblemente tóxico, y la toxicidad de este método no debe subestimarse en lo que respecta al software. Enfocar el problema de esta manera es literalmente poner a tu supply chain destinado al fracaso, al menos en lo que concierne a sus iniciativas de software.
Una manera mucho mejor de entender el problema y abordar la construcción del software es considerarla como un proceso de aprendizaje. La construcción del software consiste en aprender todo lo necesario para obtener un buen producto. Este es un proceso de aprendizaje, y todas esas partes aprendidas son un subproducto de permitir que el mundo interactúe con el software que emerge del proceso de construcción. El problema clave con una predicción en cascada es que estás proyectando lo que estás a punto de descubrir. Simplemente, eso no es posible por definición. Lo que estás a punto de descubrir era desconocido hasta que lo descubres. No puedes proyectar tus descubrimientos. Puedes esperarlos, pero no puedes planificar al detalle lo que vas a descubrir. Puedes tener corazonadas, pero eso es lo mejor que puedes alcanzar. La idea de que puedes convertir esas vagas intuiciones en una predicción precisa en cascada es, una vez más, una completa locura.
Por cierto, esta pequeña aparente paradoja sobre la construcción del software como proceso de aprendizaje también explica por qué, a veces, replicar un producto de software puede ser increíblemente fácil o increíblemente difícil. Si un equipo intenta replicar un producto de software que ya está en el mercado, y dicho equipo tiene acceso al entendimiento o a las lecciones que llevaron a la producción del software que intentan copiar, entonces, normalmente, replicar el producto de software — reimplementar o recodificar — puede realizarse con solo una diminuta fracción del tiempo y presupuesto que se necesitó para crear el software en primer lugar. Por el contrario, si el equipo no tiene acceso a estos conocimientos de alto nivel, y, por ejemplo, lo único a lo que pueden acceder es el código fuente, muy frecuentemente terminarán con un producto de muy baja calidad, porque, esencialmente, se han perdido todas las partes de aprendizaje o los fragmentos de conocimiento. Simplemente has replicado la apariencia superficial del producto.
Desde una perspectiva de supply chain, el mayor desafío aquí es renunciar de forma voluntaria y domar tu necesidad de control. El proceso en cascada es una expresión de una empresa que quiere controlar el proceso. Por ejemplo, si digo, “pongamos este proyecto bajo control”, se percibiría como algo muy razonable. ¿Por qué harías lo contrario? ¿Por qué dirías, por ejemplo, “tengamos este proyecto completamente fuera de control?” Pero la realidad es que este grado de control es una completa ilusión en lo que respecta al software, y perjudica totalmente tu capacidad para entregar un producto de alta calidad en el final. Domar tu deseo de control es, desde una perspectiva de supply chain, probablemente el mayor desafío cuando se trata de la construcción del software.
Desde la aparición de los programas de ordenador, estos han estado plagados de errores y defectos. Para abordar esos problemas evidentes, la visión predominante es que deben realizarse pruebas. Las pruebas adoptan muchas formas. En cuanto a la necesidad de probar, estoy de acuerdo, aunque en este punto resulta muy vago. Algunas herramientas enfatizan que las pruebas deben hacerse después de la construcción, otras que deben hacerse durante la construcción, y otras especifican que deben realizarse antes de la construcción. Algunos enfoques indican que las pruebas deben realizarse antes, durante y después de la construcción del software.
Mi opinión general sobre el problema es que deberías hacer lo que sea necesario para mantener el ciclo de retroalimentación lo más corto posible. Discutimos este punto en la clase anterior: mantener el ciclo de retroalimentación tan corto como sea posible es de importancia crítica para conseguir algo que funcione en el mundo real. Por lo tanto, normalmente recomendaría prestar atención a si lo que haces en términos de pruebas está realmente acortando este ciclo de retroalimentación o no. Por ejemplo, en la mayoría de las situaciones, no recomendaría de forma natural el desarrollo orientado por pruebas (una metodología que dice que las pruebas vienen primero), simplemente porque, en la mayoría de los casos, poner las pruebas de primero solo retrasará el tiempo que se tarda en obtener retroalimentación sobre tu software del mundo en general.
Sin embargo, mi mayor preocupación respecto a las pruebas es una limitación no contada, algo que parece ser generalmente ignorado. Las pruebas, en última instancia, solo pueden evaluar el cumplimiento de las reglas mismas que tú has establecido. El problema es que en el software no existen restricciones estrictas. No hay una manera química de abordar la adecuación de tu producto con respecto al problema que intentas resolver. Esto es muy diferente al ámbito físico. Por ejemplo, en ingeniería mecánica existe un criterio canónico: la tolerancia dimensional de una pieza. Sea lo que sea que estés diseñando en términos de ingeniería mecánica, la tolerancia dimensional será de primera importancia. Es un candidato obvio y natural. Sin embargo, en el software no existen candidatos naturales y obvios.
El problema aquí se convierte en uno de adecuación. Si queremos tomar un ejemplo de supply chain, como existencias de seguridad, es completamente sencillo diseñar una suite de pruebas automatizadas para validar los cálculos de existencias de seguridad. Es muy sencillo implementar este tipo de lógica de pruebas. Sin embargo, esto no puede decirte que las existencias de seguridad son una mala idea en primer lugar. Solo estás probando lo que ya conoces.
Cuando se trata de una máquina física, esperamos desgaste y, por lo tanto, algún tipo de mantenimiento para mantener la máquina en condiciones de funcionamiento. Sin embargo, ¿por qué necesitaría el software algún tipo de mantenimiento para seguir operando? Ciertamente, necesitamos reemplazar computadoras, ya que se averían de vez en cuando con el tiempo. Sin embargo, este aspecto es muy marginal, y en el software empresarial, las averías físicas de las máquinas ni siquiera representan el 10% de los costos reales de mantenimiento. Esto existe, pero el impacto de este tipo de mantenimiento es increíblemente reducido.
Sin embargo, el mantenimiento en el software empresarial es de importancia primordial. Los costos de mantenimiento son enormes. Para muchos proveedores de software empresarial, el mantenimiento representa literalmente el 80% o más del costo de ingeniería. Resulta que los factores que generan esta necesidad de mantenimiento tienen muy poco que ver con la física. El primer factor es la willingness to pay de los propios clientes. Si un proveedor puede salirse con una tarifa anual de mantenimiento del 20% en relación a lo pagado por la instalación del software durante el primer año, entonces el proveedor de software cobrará eso. Esencialmente, desde la perspectiva de costos, el costo del mantenimiento está impulsado por la willingness to pay de los clientes empresariales.
El segundo factor es el tipo de mantenimiento que debe realizarse simplemente para mantener el software operando. De hecho, por cada día que pasa, el entorno que rodea al producto de interés se desvía del producto. El sistema operativo sigue evolucionando, el sistema de bases de datos continúa evolucionando, y lo mismo ocurre con todas las bibliotecas de terceros que utiliza el software. Ningún producto de software es una isla. Cada producto depende de una miríada de otros productos de software, y esos otros productos evolucionan por sí solos. Las personas que desarrollan esos productos siguen trabajando en ellos, y conforme trabajan, continúan cambiándolos. Así, llega un momento en que el producto deja de funcionar debido a una incompatibilidad. No has hecho nada, salvo no mantenerte al día con el resto del mercado. El segundo factor es todo el mantenimiento que se debe realizar únicamente para mantener el software en funcionamiento y compatible con el resto del mercado.
El tercer factor es la cantidad de trabajo que se requiere para mantener el producto útil. De hecho, el software fue diseñado e ingenierizado en un momento determinado, y cada día que pasa, el mundo se desvía de lo que se contempló en el momento en que se diseñó el producto inicialmente. Así, incluso si nada se rompe en términos de compatibilidad de hardware, resulta que a medida que el mundo cambia, invariablemente la utilidad del producto disminuye, ya que el mundo se está alejando de las expectativas que se integraron en el producto. Si deseas mantener el software útil, necesitas mantenerlo actualizado constantemente.
Desde una perspectiva de supply chain, el mantenimiento es un gran desafío, y abordamos este aspecto en la clase anterior, que trataba sobre la entrega orientada al producto para supply chain. El costo del mantenimiento impacta significativamente los beneficios capitalistas que puedes obtener de tu iniciativa de software. Idealmente, deseas que tu iniciativa de software tenga un retorno de inversión muy alto, pero para lograrlo, necesitas asegurarte de no terminar con costos de mantenimiento masivos. Estos costos anularán por completo el beneficio capitalista y el retorno que podrías obtener de tu inversión en software.
El mayor desafío aquí, nuevamente desde una perspectiva de supply chain, es que la forma más simple de minimizar el costo de mantenimiento es enfocarse en lo que no cambia. Como mencioné anteriormente, la mayor parte de los costos están relacionados con las cosas que cambian, ya sea en el ecosistema del software o en el mundo en general. Sin embargo, si te concentras en lo que no cambia, entonces lo que obtienes es esencialmente la mayor parte de tu software que solo se deteriorará lentamente porque, precisamente, la mayoría de lo que aborda tu software son las cosas que no cambian.
El problema es que enfocarse en lo que no cambia es más fácil decirlo que hacerlo, porque existe una fuerza muy humana que antagoniza esta intención: el miedo a quedarse fuera. Cuando miras la prensa, los medios, tus colegas, etc., habrá un flujo constante de novedades, buzzwords, y cada buzzword tiene ese impulso, debido al miedo a quedarse fuera, a simplemente hacer la cosa y no quedarse atrás. Por ejemplo, todas esas buzzwords serían AI, blockchain, IoT, y todas esas cosas que están muy presentes. Creo que en supply chain, estas buzzwords son realmente una distracción y contribuyen significativamente a los problemas de mantenimiento porque distraen de lo que no cambia. Por el contrario, cuando empiezas a fijarte en esas buzzwords, estás surfeando una ola, y estás cabalgando precisamente en el tipo de cosas que es muy probable que cambien con el tiempo, lo que incrementa el costo de mantenimiento a lo largo del tiempo.
Ahora que hemos concluido la visión convencional de la ingeniería de software, adentrémonos en una serie de aspectos personales que, con suerte, resultarán útiles para llevar a cabo iniciativas de software teniendo en cuenta el supply chain. Uno de los problemas más frecuentes al tratar con personas del software es la concepción errónea sobre su propia identidad, y estoy tomando prestada esta idea de un empresario llamado Paul Graham. Un ingeniero dirá, por ejemplo, “Soy un Python engineer.” Aunque puede no ser tan extremo, es muy frecuente que los ingenieros de software perciban su propia identidad a través de la breve serie de tecnologías que han dominado, las cuales conforman su conjunto de habilidades. Esta confusión entre su identidad y su conjunto de habilidades actuales tiende a reforzarse por las prácticas de contratación que predominan en el mundo de IT y del software en general. Desde el punto de vista de la contratación, hay muchas empresas que indican en sus anuncios de trabajo, “Necesito un programador Python.” De este modo, por un lado, hay alguien pensando, “Soy un programador Python,” y por el otro, una empresa que va a publicar una vacante donde básicamente se escribe, “Necesito un programador Python.” Así, de repente tener la identidad correcta no es solo cuestión de percepción; existen recompensas financieras asociadas a tener la identidad correcta, la etiqueta correcta, el distintivo correcto que puedes atribuirte, haciéndote más atractivo en el mercado.
Sin embargo, esta percepción guiada por la identidad, en la que las tecnologías se asocian a uno mismo como ingeniero de software, conduce a numerosos problemas que afectan prácticamente a cada proyecto de software, y en particular a los proyectos de software de supply chain. Al interactuar con una persona, típicamente un ingeniero de software, que tiene su identidad fuertemente ligada a la tecnología que se utiliza en tu empresa, el problema radica en que cada crítica a la tecnología tiende a tomarse de forma personal. Si dices que soy un programador Python y criticas mi software, lo tomo de manera personal. El problema es que tan pronto como la gente toma la crítica de la tecnología como crítica hacia la persona, se vuelve muy difícil razonar sobre esos problemas. Estos ingenieros de software, desafortunadamente, tenderán a desviar todo el feedback, solo porque lo ven parcialmente como una crítica personal.
Por el contrario, si la empresa resulta estar utilizando una tecnología que no es la percibida como identidad principal por el ingeniero de software, por ejemplo, si tu empresa tiene algunos sistemas implementados en Java y tienes un ingeniero de software que dice, “Soy un programador Python,” entonces todos los problemas se percibirán desde la perspectiva de que esa pieza de tecnología es inferior. Nuevamente, ese es otro problema en el que la crítica y el feedback se desvían con una actitud de “no es mi problema; esto se debe simplemente a esta tecnología tan pobre que se decidió usar aquí y ahora en esta empresa.” En ambas situaciones, ya sea que el ingeniero de software tenga una identidad ligada a la tecnología que estás usando o tenga una identidad ligada a una tecnología que no estás usando, se crea toda una serie de problemas, y el feedback se desvía en lugar de aprovecharse para mejorar la tecnología.
Ahora, desde una perspectiva de supply chain, debemos tener en cuenta que el entorno de supply chain es increíblemente caótico, y por ello los problemas ocurrirán todo el tiempo. Precisamente debido a este caos ambiental, es muy importante contar con equipos de ingenieros de software que puedan enfrentar de frente estos problemas y hacer algo al respecto, y no simplemente desviar el feedback cuando ocurra. Es crucial formar equipos que no fomenten el drama sobre el caos del supply chain debido a su percepción sobre su identidad.
Esta idea se extiende a los ingenieros de software, quienes a menudo eligen tecnologías que se ajustan a su identidad o a la identidad que desean adquirir. Ellos seleccionan tecnología para adquirir habilidades, de modo que puedan agregar otra keyword a su currículum. Sin embargo, este enfoque conduce a elegir tecnologías por razones ajenas a resolver los problemas que enfrenta la empresa. Esta es la perspectiva equivocada para decidir si una tecnología es relevante o adecuada para abordar los problemas específicos que enfrenta la organización.
Construir un currículum puede ser un poderoso motivador para los ingenieros de software, ya que existen beneficios financieros reales asociados con tener una lista de keywords en él. Las mejores empresas de software a menudo desestiman los currículums con una larga lista de keywords. Como CEO de Lokad, si veo un currículum con media página de keywords, es descartado de inmediato. Sin embargo, muchas empresas, especialmente las mediocres, buscan activamente personas con muchas keywords, pensando que estos individuos serán increíblemente versátiles y ágiles dentro de la organización. Según mi experiencia, a menudo es todo lo contrario.
Continuando con el tema de la identidad y la construcción del currículum, es vital prestar atención al hecho de que los arquitectos de software no deberían estar demasiado apegados a ninguna tecnología en particular. Ya es difícil contratar ingenieros de software, por lo que a veces hay que hacer compromisos. Sin embargo, cuando se trata de arquitectos de software, comprometerse seleccionando individuos con un apego emocional a cierta tecnología puede ser desastroso. Estos individuos tendrán un impacto a gran escala en tu empresa.
Este problema del sesgo en la construcción del currículum no se limita a los ingenieros de software o profesionales del software. También ocurre entre el personal de IT. Por ejemplo, he conocido a varios directores de IT en grandes empresas que querían hacer la transición a SAP mientras que su legacy ERP existente estaba perfectamente bien. Los costos masivos asociados con la transición a SAP nunca se compensarían con los beneficios esperados de un ERP más moderno. En estos casos, se manifestaba un comportamiento irracional, donde el interés personal del director de IT por desplegar SAP en su currículum superaba el interés de la propia empresa.
Desde una perspectiva de supply chain, es esencial prestar atención a estos conflictos de interés. No hace falta tener muchas habilidades o competencias en software para detectar conflictos de interés. En otros campos, como la ciencia médica, incluso los médicos pueden prescribir los medicamentos equivocados debido a conflictos de interés, incluso cuando hay vidas en juego. Esto demuestra que los conflictos de interés son increíblemente tóxicos. Imagínate cómo se desarrollan estos problemas en la gestión de supply chain, donde no hay vidas en juego y la principal preocupación es el dinero. Hay aún menos reticencia a dejar que los conflictos de interés se desenvuelvan en este contexto.
A diferencia del ámbito físico, el ámbito del software ofrece muy pocas restricciones sobre cómo proceder con iniciativas de software y abordar el trabajo. La naturaleza humana no gusta de un vacío, y las personas pueden inquietarse por la falta de estructura. Como resultado, han aparecido numerosas prácticas a lo largo de los años y continúan surgiendo. Con cada práctica viene una noción de ortodoxia. Algunos ejemplos de estas prácticas incluyen extreme programming, domain-driven design, test-driven design, microservices, Scrum y agile programming. Hay muchas prácticas, y cada año surgen nuevas.
Con cada práctica viene una noción de ortodoxia. En cuanto las personas comienzan a seguir una práctica, pueden cuestionar si están adhiriéndose a los principios básicos. Los ingenieros de software son solo personas, y a la gente le encantan los rituales y las tribus. Una práctica proporciona un sentido de pertenencia a una tribu con creencias compartidas. Por eso también encontrarás meetups asociados con estas prácticas, satisfaciendo una necesidad muy humana.
Puede ser difícil e incluso deprimente enfrentar un problema, sin estar seguro de nada y teniendo casi a nadie con quien relacionarse al abordarlo. Lo interesante es que, aunque una práctica pueda ser cuestionable o ligeramente irracional, los beneficios pueden ser reales. Publicitar una práctica dentro y fuera de tu empresa puede aumentar la moral y ayudar a contratar a potenciales candidatos.
En una entrevista de trabajo, cuando la gente pregunta cómo trabajas, no resulta precisamente convincente decir que improvisas y no tienes reglas. Es más eficiente inspirar confianza presentando una práctica como si fuera a resolver problemas dentro de la empresa. El punto clave es que, a corto plazo, estas prácticas no son todas malas, incluso si en su mayoría son irracionales. Generar un sentido de pertenencia puede ser beneficioso. Sin embargo, se vuelve venenoso si se toman las prácticas demasiado en serio o durante demasiado tiempo. Una práctica puede ser de interés solo porque te obliga a ver el problema desde un ángulo diferente. Pero una vez que has visto el problema desde un ángulo diferente, deberías intentar encontrar otro ángulo. No deberías quedarte con un solo ángulo por demasiado tiempo. Desde una perspectiva de supply chain, esto ilustra la radical extrañeza del ámbito del software.
En el piso de fábrica, la excelencia significa hacer siempre exactamente lo mismo. En el mundo del software, es todo lo contrario. Si haces lo mismo, entonces es una receta para el estancamiento y el fracaso con el tiempo.
El software es complejo, y el software empresarial aún más. Con frecuencia, varios ingenieros terminan trabajando en una iniciativa determinada, lo que conduce a una tendencia natural hacia la especialización. Cuando un ingeniero trabaja en una determinada parte del codebase, existe una inclinación natural a asignar a la misma persona cuando nuevas tareas requieren tocar esa misma parte del codebase. Los beneficios son reales, ya que esta persona ya está familiarizada con el código y puede ser más productiva.
El problema principal de la especialización es que puede conducir a un sentido de propiedad sobre partes del codebase, creando diversos problemas. Existen dos clases de problemas asociados a esta propiedad: el “truck factor” y los juegos de poder. El factor truck se refiere al riesgo de perder a un empleado que posee conocimientos o habilidades únicas. Esto podría deberse a que el empleado se vaya a otra empresa o no pueda trabajar por cualquier otra razón. Los juegos de poder pueden ocurrir si un empleado se da cuenta de que su contribución es vital para la empresa y utiliza este poder para exigir un salario más alto u otros beneficios.
En mi experiencia, los ingenieros de software típicamente no tienen una fuerte propensión a jugar juegos de poder, pero estos problemas pueden volverse cada vez más frecuentes en empresas más grandes. Existen muchas prácticas de ingeniería de software que intentan abordar este problema de frente, como el pair programming. Sin embargo, la idea clave es que demasiado de algo bueno puede ser venenoso para la empresa. Lo mejor es estar consciente de esta clase de problema, en lugar de limitarse a una práctica en particular que se supone debe solucionar el problema. Esto se debe a que tales prácticas pueden crear otros problemas, distraerte o restringir tu capacidad para prestar atención a otras cosas que aún no has visto. Desde una perspectiva de software, la lección clave aquí es que la cultura es el antídoto para esta clase de problemas, no el proceso.
Nos enfrentamos a una situación en la que existe una compensación muy sutil entre las ganancias de productividad logradas al hacer que las personas se especialicen en partes del codebase y los riesgos asociados con que esas personas sean dueñas de esas partes del codebase. Lo que se desea es cultivar una situación en la que siempre haya cierto grado de redundancia en cuanto al conocimiento del codebase por parte de todo el equipo, de modo que cada ingeniero tenga algún tipo de superposición de competencias. Esta es una compensación muy sutil que necesitas lograr si deseas mantener cualquier grado de productividad. La única forma de lograrlo en el mundo real es a través de una cultura bien entendida sobre la ingeniería de software. No hay ningún proceso que pueda garantizar que las personas sientan curiosidad por el trabajo de sus colegas. No puedes tener un proceso sobre la curiosidad; debe ser parte de la cultura.
Evaluar las habilidades y competencias de los ingenieros de software es difícil, y esta cuestión es clave porque, aunque el software es claramente un esfuerzo en equipo y el equipo es más que la suma de sus miembros, el nivel base de los miembros del equipo tiene un gran impacto en el desempeño del equipo en su conjunto.
Un aspecto que he observado ser ampliamente subestimado por personas fuera de la industria del software, y a veces también por personas dentro de la industria, es la importancia de las habilidades de escritura. Si estás creando software, estás atendiendo a dos audiencias distintas. Por un lado, tienes la audiencia de la máquina: tu compilador. Escribes código, y tu compilador lo aceptará o lo rechazará. Esta es la parte fácil. Tu compilador es tu compañero infatigable que te dirá si tu código es correcto o incorrecto. El compilador es completamente predecible y tiene una cantidad infinita de paciencia.
Por otro lado, tienes a la audiencia de tus colegas, que probablemente te incluirá a ti mismo dentro de seis meses. Escribes código y, eventualmente, lo olvidarás. Seis meses después, mirarás el código que escribiste, pensando que lo escribió otra persona porque te resulta tan desconocido. Cuando escribes código para tus colegas, el beneficio es que, a diferencia de los compiladores, tus colegas intentarán entender lo que estás tratando de lograr. El compilador no intenta comprender tus intenciones; aplica un conjunto de reglas de forma mecánica.
Tus colegas intentarán comprender, pero desafortunadamente, no son como los compiladores. No tienen una cantidad infinita de paciencia y pueden confundirse y ser mal guiados fácilmente por tu código. Por eso, por ejemplo, elegir nombres memorables, perspicaces y apropiados es de suma importancia. Un buen programa no se trata solo de tener algo correcto; incluso elegir los nombres de las variables, funciones y módulos es de importancia crítica si deseas tener código que funcione bien con tus colegas, y, nuevamente, tus colegas te incluirán a ti mismo dentro de seis meses. Desde una perspectiva de supply chain, la conclusión clave es que las habilidades de escritura son de suma importancia, y me atrevería a decir que las habilidades de escritura son frecuentemente más importantes que las habilidades técnicas puras. Las buenas habilidades de escritura son la habilidad número uno que necesitarás para domar la complejidad presente en tu supply chain. Domar la complejidad de tu panorama aplicativo no es un gran reto técnico; es un reto de organizar ideas y elementos, y de mantener una historia coherente en todos los aspectos. Estas son, en gran medida, habilidades de escritura, y ya tratamos este aspecto en una lección anterior titulada “Writing for Supply Chain.”
Si la habilidad de escritura es de suma importancia para ser un buen ingeniero de software, hay otra habilidad que es de suma importancia para ser ingeniero de software en absoluto: la tolerancia al dolor. Creo que esa es la habilidad número uno en cuanto a lo que se requiere para ser realmente un ingeniero de software, no uno grandioso, simplemente serlo. Más específicamente, cuando hablo de dolor, me refiero a la resistencia al aburrimiento y a la frustración que acompaña el proceso de desarrollar software al enfrentarse a sistemas que son increíblemente frágiles, mal diseñados y trampa en todo tipo de formas, a veces por personas que ya ni siquiera están. Cuando tratas con software, tienes cuatro décadas de problemas acumulados bajo tus pies, y estás lidiando con eso todo el tiempo. Esto puede ser un ejercicio increíblemente frustrante en ocasiones.
Solo para darte una ilustración, como ingeniero de software, necesitarás tener la paciencia de pasar cuatro horas escarbando en conversaciones aleatorias, medio basura, en un foro web que mencionen un código de error similar al que estás enfrentando. Tendrás que pasar horas revisando este tipo de tonterías para llegar al fondo del asunto, y a veces se requieren semanas para resolver un bug aparentemente trivial. Así, la consecuencia es que tenemos un proceso de selección adversa muy intenso en toda la industria del software, que selecciona a las personas que tienen una alta tolerancia al dolor. Este proceso de selección tiene dos consecuencias principales.
Primero, las personas que permanecen como ingenieros de software tienden a ser increíblemente tolerantes al dolor. Cuando digo tolerantes al dolor, me refiero a la resistencia a la frustración derivada de los constantes problemas de software a los que se enfrentan. Al seleccionar a personas con una tolerancia increíble al dolor, puede que ni siquiera reconozcan cuando sus acciones están empeorando la situación. Pueden añadir peculiaridades extra en los productos de software, incrementando el nivel de dolor de interactuar con el software para todos, incluyéndose a sí mismos. Sin embargo, si resultan ser increíblemente tolerantes al dolor, no prestan atención. Este proceso de selección adversa excluye a las personas comunes que prestarían atención pero que no se convirtieron en ingenieros de software porque no podían soportar el dolor. Este problema es particularmente intenso para el software de supply chain porque hay muchas partes que no son súper emocionantes. Algunos aspectos pueden ser necesarios pero mundanos, lo que significa que las personas con alta tolerancia al dolor operando en este campo pueden empeorar la situación debido a la abundancia de tareas potencialmente aburridas.
El segundo aspecto de este proceso de selección adversa es que, cuando las personas pueden permitirse el lujo de optar por un salario menor para evitar problemas que generan un dolor intenso, lo hacen. Si alguien ya está bien remunerado, puede decidir optar por un trabajo que no pague tan bien, pero que venga con el beneficio de un dolor menos intenso. La mayoría probablemente haría esto, y en la práctica, muchas lo hacen. Esto significa que las personas que permanecen en esta industria, donde hay una intensidad muy alta de dolor ambiental, son a menudo aquellas que no pueden permitirse renunciar a la oportunidad de un salario más alto. Esto explica, en gran medida, por qué hay un número significativo de ingenieros de software provenientes de India y del Norte de África. Estos países tienen sistemas educativos bastante buenos que producen individuos bien educados, pero los países siguen siendo relativamente pobres. Las personas en estas posiciones no tienen el lujo de renunciar a empleos de ingeniería de software mejor pagados debido a la alta demanda y a los salarios más altos en comparación con sus salarios base. No tienen el lujo de optar por otra cosa, y así terminan siendo muy predominantes en la industria.
No hay nada malo en estos países; es meramente una aplicación mecánica de las fuerzas del mercado. Esto no es un juicio, solo una observación. La cuestión es que la tolerancia al dolor no es todo lo que se necesita para ser un gran ingeniero de software. Es solo una condición, pero si no la tienes, entonces no eres un ingeniero de software en absoluto. Sin embargo, si la tolerancia al dolor es lo único que posees, te convertirá en un ingeniero de software bastante pobre. Desde una perspectiva de supply chain, la lección aquí es prestar mucha atención al tipo de equipos que tu empresa está reuniendo, ya sea internamente o a través de proveedores de software. Asegúrate de que los ingenieros que se reúnan no tengan la tolerancia al dolor como su única habilidad, porque eso significa que tendrás un resultado muy pobre en términos de calidad del software y valor agregado del mismo. De nuevo, la tolerancia al dolor es requerida, pero simplemente no es suficiente.
En 1975, Frederick Brooks ya señalaba que los hombre-meses no eran representativos del valor creado por el software ni del valor generado por los ingenieros de software en general. Casi cinco décadas después, las empresas de IT están entre los mayores empleadores del mundo. En 2020, en Estados Unidos, había 3 millones de empleados en la industria de IT, pero menos de 1 millón de personas en toda la industria automotriz. La industria de IT ahora cuenta al menos con tres veces más gente que la industria automotriz. La mayoría de esas empresas de IT, algunas siendo absolutamente gigantes con varios cientos o miles de empleados, ya no cobran por hombre-mes. Eso era en los años 70. Ahora cobramos por kilo-días, que básicamente equivalen a mil días de mano de obra. La situación, probablemente, se ha vuelto mucho peor en comparación con el problema que Frederick Brooks describía hace casi cinco décadas, principalmente debido al increíble incremento en términos de escala y magnitud del problema. Sin embargo, la mayoría de las lecciones iniciales siguen siendo válidas. “The Mythical Man-Month” sigue siendo un libro muy interesante sobre ingeniería de software.
En el software, la productividad varía enormemente. En un extremo del espectro, no solo hay gente con baja productividad; hay personas con productividad negativa. Eso significa que, cuando comienzan a trabajar en un producto de software, simplemente lo empeoran. Ya ni siquiera se puede establecer una proporción entre la productividad de las personas. Es mucho peor que eso; hay gente que activamente deteriora tu producto. Eso es un problema masivo. En el otro extremo del espectro, están los llamados ingenieros 10x, personas que tienen diez veces la productividad de tu ingeniero promedio, que, con suerte, tiene productividad positiva. Estos ingenieros 10x existen, pero esa productividad masiva es increíblemente dependiente del contexto. No puedes simplemente trasladar a un ingeniero 10x de software de una empresa a otra o incluso de un puesto a otro y esperar que esa persona mantenga su increíble productividad. Generalmente, es una combinación de habilidades únicas y una situación específica lo que genera esa productividad. No obstante, es importante tener en cuenta que unas pocas personas pueden impulsar la mayor parte del valor generado por un producto de software. A veces, se reduce a una sola persona que está creando la mayor parte de todos los elementos inteligentes del software y el verdadero valor agregado, mientras el resto se ocupa de cuestiones que, en el mejor de los casos, tienen un valor agregado dudoso. La lección clave aquí, identificada hace cinco décadas, es que, cuando estás contra un plazo en supply chain, la única opción razonable a tu disposición es reducir el alcance de la iniciativa de software. Todas las otras opciones son peores.
Añadir mano de obra empeora las cosas, ya que se dice a menudo que agregar más personal a un proyecto de software retrasado lo hace aún más tardío. Esta afirmación de Brooks era válida hace cinco décadas y sigue siéndolo hoy en día. Las otras opciones tampoco funcionan. Si comienzas a tener gente haciendo horas extra, saldrá contraproducente porque se cansarán y cometerán más errores, retrasando aún más el producto. Si intentas bajar la calidad, terminarás con algo que ya no funciona. Estas cosas se saldrán de control y explotarán en tus manos, por lo que no puedes comprometer la calidad.
Desde una perspectiva de supply chain, la lección clave aquí es que, si abordas cualquier iniciativa que parezca requerir más de diez ingenieros de software a tiempo completo, procede con sumo cuidado. Usualmente, es una señal de que se trata de un problema muy mal planteado. Se necesita un trabajo en equipo increíble para que diez personas trabajen en el mismo producto simultáneamente sin perder productividad. En supply chain, he observado que la gente suele ser demasiado ambiciosa en términos de escala y cantidad de personas involucradas. He visto proyectos de migración de ERP con 50, 100 o 200 personas trabajando en ellos simultáneamente. Esto es absolutamente absurdo. Lograr cualquier grado de cooperación requiere jugadores de equipo increíblemente capaces para evitar que se pierda todo a causa de la fricción. Si estás teniendo dificultades, mantén tu iniciativa de software enfocada, breve y restringida.
Mi observación final es acerca de un malentendido frecuente respecto a las grandes empresas. La mayoría diría que las grandes empresas son adversas al riesgo, pero esa no es mi experiencia. Mi experiencia es que las grandes empresas son reacias a la incertidumbre, no al riesgo, aunque desde lejos ambos pueden confundirse. Desde lejos, la explicación racional que se da es que las grandes empresas son adversas al riesgo, pero en realidad, he observado una y otra vez que las grandes empresas, cuando se enfrentan a la oportunidad de optar por un fracaso seguro frente a un éxito incierto, invariablemente favorecerán la certeza del fracaso sobre el éxito incierto.
Las grandes empresas invariablemente favorecerán la certeza del fracaso sobre el éxito incierto, una y otra vez. Esto puede parecer desconcertante e irracional en la superficie, pero no lo es. Las grandes empresas no son una entidad única; son bestias políticas compuestas por muchas personas. La política y las apariencias son primordiales, especialmente en estructuras muy grandes.
Considera la perspectiva de quien esté a cargo de una iniciativa de software. Por un lado, tienes una iniciativa cuyo resultado es seguro: fracasará. Sin embargo, estás siguiendo las reglas al pie de la letra, y todo el mundo sabe que fracasará. Nadie te culpará por jugar a lo seguro y fracasar, porque eso es lo que esperan. Por el contrario, el éxito incierto resulta extraño. Seguir este camino significa hacer cosas que son inusuales y potencialmente dañinas para la carrera, mucho más que simplemente seguir las reglas.
Desde una perspectiva de supply chain, la lección aquí es que, en el mundo del software, es de vital importancia no prepararse para el fracaso solo por seguir las reglas, especialmente cuando esas reglas son completamente falsas. Por ejemplo, he visto empresas fracasar durante décadas usando métodos como el análisis ABC y los safety stocks, métodos que pueden demostrarse como incorrectos y que garantizan el fracaso de las iniciativas correspondientes. Estos métodos son erróneos por razones matemáticas y estadísticas básicas, por lo que no debería sorprender que no logren entregar valor agregado en supply chain. Sin embargo, se consideraron preferibles porque no parecían tan disparatados, al ser material de libro de texto.
Cuidado con la comodidad que se puede obtener al prepararse para el fracaso solo para eliminar la incertidumbre. Eliminar la incertidumbre no es el objetivo; el objetivo es maximizar la probabilidad de éxito, no reducir la incertidumbre.
En conclusión, la ingeniería de software es demasiado importante como para dejarla únicamente en manos de ingenieros de software. El software está por todos lados en supply chain y está impulsando la mecanización del trabajo intelectual. Todavía estamos en una etapa temprana del proceso, pero ya se puede decir, sin lugar a dudas, que las empresas que no se mantengan extremadamente competitivas en este frente serán eliminadas del mercado por las fuerzas regulares del mercado. Para supply chain, el mayor desafío es de naturaleza cultural. Esto no es un problema técnico, sino un problema cultural. La ingeniería de software desafía la forma en que miramos y abordamos los problemas. La mayoría de las soluciones intuitivas tienden a ser incorrectas, espectacularmente así.
De alguna manera, la ingeniería de software en supply chain se trata de domesticar el caos, de domar toda la complejidad e incertidumbre que acontece en supply chain. Para domar este caos, que será el trabajo de los ingenieros de software, si el proceso en sí está demasiado pulido u ordenado, y si el proceso en sí no tiene un elemento de caos en su núcleo, entonces no queda espacio para el cambio, la casualidad o la creatividad. Lo que se percibe como excelencia se degrada rápidamente en estancamiento y, luego, en fracaso. Para las empresas más tradicionales, el mayor desafío de este enfoque cultural, además del choque cultural, es dejar ir la ilusión de control. Tu plan de migración de ERP a cinco años es una ilusión; no tienes control sobre un proyecto tan masivo. De igual manera, tu business case que describe las ganancias esperadas de tu iniciativa actual también es una ilusión.
Al abordar la mecanización del trabajo intelectual, el mayor peligro no es hacer cosas que no puedes racionalizar completamente. El mayor peligro es hacer cosas que son completamente irracionales bajo el disfraz de la racionalidad.
Veamos la pregunta. La siguiente conferencia se realizará el miércoles 15 de diciembre, a la misma hora, 3 p.m., hora de París, y será sobre ciberseguridad. Ahora, voy a revisar la pregunta.
Pregunta: ¿Cómo mides el retorno capitalista en tus inversiones en software?
Mayormente, no lo haces. La medición es un subproducto de la realización en sí. Es algo que resulta desconcertante si quieres medir el retorno de la inversión. Se asume que puedes idear una medición de antemano, lo cual es lo que típicamente se insinúa con este tipo de pregunta. Se presupone que puedes elaborar esta medición antes de construir tu caso de negocio con escenarios, y luego puedes tomar una decisión y proceder o no con tu inversión en software. Lo que estoy diciendo es que no funciona así con el software. Literalmente, primero haces la cosa, luego aprendes lo que hay que aprender, y a lo largo del camino incluso descubrirás qué tipo de beneficios existen. Para guiar tu acción, necesitas una comprensión a alto nivel. La lección no es hacer las cosas al azar, sino evitar hacer cosas que sean profundamente irracionales bajo el disfraz de la racionalidad. La intuición a alto nivel, si estás absolutamente convencido de algo y tu instinto te dice que es el camino correcto, puede ser un argumento mucho más racional en comparación con cálculos sofisticados que solo tienen la pretensión de racionalidad pero están basados en números basura. La realidad es que, a medida que avanzas en tu proyecto de software, las mediciones se vuelven más claras porque comienzas a aprender sobre lo que intentas lograr, y luego aprendes cómo medir la adecuación de lo que haces frente a lo que deberías hacer. La medición viene como un subproducto si lo haces bien. Sin embargo, como consecuencia de esto, en lo que respecta al software, es mucho mejor simplemente probar cosas y fallar rápido. No quieres comprometerte con un compromiso masivo; es mejor hacerlo de maneras increíblemente incrementales, con menos personas y alta productividad. Aprendes en el camino cómo proceder.
Pero luego surge otro problema: tan pronto como comienzas a hacer eso, la dirección en las empresas necesita poder manejar muchas iniciativas al mismo tiempo. Esto es muy desconcertante, especialmente para las empresas más tradicionales, porque la dirección no espera tener tantas iniciativas yendo en diferentes direcciones. Sin embargo, esto es exactamente lo que ya ha estado ocurriendo en las grandes empresas de software durante décadas, y es una de las esencias de las conclusiones de la ingeniería de software desde una perspectiva humana.
Pregunta: ¿No es una contradicción decir que aquellos con muchas palabras clave no se asocian con una tecnología en particular?
Bueno, no digo que tener muchas palabras clave te proteja de asociarte a una tecnología en particular. Hay dos problemas diferentes. Uno es el problema de tener a una persona que posee una fuerte asociación entre su identidad personal, su identidad percibida y su conjunto de habilidades. Ese es el problema número uno. El problema número dos es que construir tu currículum conlleva un fuerte conflicto de intereses latente. Mi mensaje es, por un lado, tener cuidado con esa política de identidades; son increíblemente tóxicas. Mi segundo mensaje es tener cuidado con los conflictos de intereses en todas sus formas; también son increíblemente tóxicos.
Pregunta: La ingeniería de software se considera una ciencia auxiliar para supply chain. ¿Cuáles serían las ciencias auxiliares para la ingeniería de software?
Probablemente la psicología, la sociología y la etnología sean campos relevantes cuando se trata de la ingeniería de software. Si comienzas a abordarla como, esencialmente, la interacción de las personas, entonces estas ciencias auxiliares son cruciales. Para realizar un trabajo serio en la ingeniería de software, no se trata únicamente de la tecnología del software, aunque necesitas comprender el contexto para que las interacciones entre las personas tengan sentido. No es necesario que entiendas qué entra en el código, pero sí necesitas comprender conceptos como una base de código o las herramientas que existen y los problemas que intentan resolver. Sin embargo, para el propósito de esta serie de conferencias de supply chain, necesito marcar una línea, decidiendo lo que incluyo y lo que no, ya que obviamente no puedo abarcar cada campo de investigación.
Pregunta: Pregunta a diez personas inteligentes por una solución, y ellas encontrarán más de diez formas. Estar de acuerdo en una de las cinco mejores y utilizarla de manera consistente es mejor. ¿Cómo equilibras esos dos enfoques y beneficios conflictivos? Esa es una pregunta muy amplia, pero si intento enmarcarla en el caso específico de la ingeniería de software, puedes tener muchas propuestas, pero no todas deben ser consideradas con el mismo peso. Existe la habilidad de tener una visión a largo plazo del software. Cuando digo que debes enfocarte en lo que no cambia, resulta que algunas personas son muy buenas en este trabajo y otras no. La experiencia entra en juego cuando quieres evaluar quién tiene las habilidades para esa visión a largo plazo y lo que permanece constante. En mi humilde experiencia, generalmente se necesita que alguien tenga al menos 35 años para empezar a volverse muy bueno en eso, y las mejores personas superan los 60. Se requieren años de experiencia para ver el movimiento y los patrones.
Cuando dices que cuentas con tantas personas, una ilusión es que todas esas soluciones se ven bien, pero eso es solo apariencia. No sabes cuánto esfuerzo requerirá probarlas. ¿Puedes simplemente hacer un prototipo o testearlas? Entre esas diez personas, ¿hay algunas con habilidades únicas para identificar soluciones que a largo plazo serán perjudiciales? Recuerda que tus costos de mantenimiento están esencialmente determinados por las decisiones que has tomado. ¿Existe alguna decisión importante que pueda afectarte negativamente a largo plazo?
Pregunta: ¿Cómo miden las empresas el aumento en la eficiencia operacional por cada dólar invertido en la implementación de software para supply chain?
Esta es una pregunta increíblemente difícil. El problema es literalmente la inconmensurabilidad de paradigmas. Proviene de la epistemología; la idea es que cuando pasas de una forma de operar a otra, y esos paradigmas son radicalmente diferentes, la mayoría de las mediciones resultan inútiles. Miremos, por ejemplo, el telemarketing versus ecommerce. Las empresas de venta por correo habían existido desde mediados del siglo XIX. Si comienzas a considerar el ecommerce como una mejora respecto a las empresas de venta por correo, podrías intentar medir la mejora, pero la realidad es que prácticamente todas las empresas de venta por correo quebraron. Las empresas de ecommerce que dominan hoy en día son varias órdenes de magnitud mayores que la mayor empresa histórica de venta por correo, y la comparación es muy difusa.
La mecanización del trabajo intelectual es increíblemente inquietante y desconcertante porque no es como el ámbito físico. Con la producción física, puedes medir la eficiencia usando métodos canónicos. Sin embargo, cuando comienzas a mecanizar tu trabajo intelectual, ¿qué significa siquiera la eficiencia? Para una empresa como Amazon, toda su supply chain está completamente impulsada por software. Si las personas simplemente se quedaran en casa sin hacer nada, sospecho que toda la supply chain funcionaría perfectamente, incluso si todos esos ingenieros no hicieran nada durante uno o dos días. Entonces, ¿por qué Amazon sigue manteniendo a esos ingenieros? Bueno, porque invierten en sus mejoras.
Por cierto, algo interesante acerca de Jeff Bezos es su proceso de gestión llamado “disagree but commit.” Él dice que hay proyectos en los que su instinto como CEO le indica que están equivocados, y no está de acuerdo con el proyecto. Sin embargo, se compromete a respaldar el presupuesto del proyecto porque ha contratado y confía en las personas que trabajan en él. Es una especie de enfoque esquizofrénico: como CEO, se supone que es la máxima autoridad en la empresa, pero renuncia a esa autoridad y dice, “No estoy de acuerdo, pero pueden contar con el presupuesto y continuar.”
La razón de este enfoque es que los proyectos de software suelen ser bastante económicos. Si alguien propone una idea aparentemente loca que no es muy costosa y no arruinará a la empresa, ¿por qué no intentarlo? Si funciona, podría ser una idea brillante. Esto representa un choque cultural al hacer la transición desde las empresas tradicionales de supply chain, donde se supone que la dirección tiene la visión y motiva a los equipos. En el ámbito del software, el liderazgo se centra principalmente en resolver problemas que surgen entre los ingenieros de software.
En Lokad, al invertir en software, la preocupación principal no son los retornos en dólares. En su lugar, el enfoque está en si la inversión aborda un aspecto fundamental de la gestión de supply chain. Si es central para una amplia variedad de situaciones de supply chain, entonces vale la pena perseguirla.
Por ejemplo, en el mercado de repuestos automotrices, abordar el problema de la compatibilidad mecánica es de suma importancia. No estás vendiendo piezas de automóvil para atender a las personas; estás vendiendo piezas para atender a los automóviles. Una sola pieza puede ser compatible con múltiples vehículos, y algunas piezas pueden tener solapamientos mecánicos. Este problema debe abordarse; es fundamental para el negocio. Si no lo enfrentas, alguien más lo hará, y eventualmente serás expulsado del mercado.
En Lokad, al invertir en software, la preocupación principal no son los retornos en dólares. En su lugar, el enfoque está en si la inversión aborda un aspecto fundamental de la gestión de supply chain. Si es central para una amplia variedad de situaciones de supply chain, entonces vale la pena perseguirla.
Por ejemplo, en el mercado de repuestos automotrices, abordar el problema de la compatibilidad mecánica es de suma importancia. No estás vendiendo piezas de automóvil para atender a las personas; estás vendiendo piezas para atender a los automóviles. Una sola pieza puede ser compatible con múltiples vehículos, y algunas piezas pueden tener solapamientos mecánicos. Este problema debe abordarse; es fundamental para el negocio. Si no lo enfrentas, alguien más lo hará, y eventualmente serás expulsado del mercado.
En cuanto a las inversiones en software, es importante asumir riesgos y abrazar la innovación, siempre y cuando no amenacen la estabilidad financiera de la empresa.
Pregunta: Es engañoso decir que los grandes equipos de proyecto son ridículos. En los sistemas ERP, un equipo de 10 personas podría ser bueno para el desarrollo, pero los proyectos más grandes requieren más personas. Una torre requiere más personas para construirse que una casa. ¿Podrías aclarar tus comentarios?
Voy a tomar una posición que puede antagonizar a mucha gente. Los medios de vida de millones dependen de empresas de TI increíblemente grandes. En Estados Unidos, en 2020, las empresas de TI representaron a tres millones de empleados estadounidenses. Así que, cuando digo que no hay absolutamente ninguna razón para tener un ERP que requiera a tantas personas, obviamente, todas las personas que ganan su vida ya sea vendiendo grandes equipos o formando parte de uno de ellos estarán en vehemente desacuerdo conmigo.
Mi argumento es: ¿proviene tu desacuerdo de razones científicas fundamentales que expliquen por qué el trabajo no puede realizarse con menos personas, o es en tu propio interés financiero mantener el status quo y contar con un ejército de personas para hacer el trabajo? Si observamos toda la innovación que tuvo lugar –la destrucción creativa esbozada por el economista Schumpeter–, cada vez que hubo una innovación económica importante, generalmente se produjo una mejora masiva en la productividad. Pero aquellos rezagados lucharon ferozmente para evitar que estas innovaciones se llevaran a cabo.
Los ERPs no son nada nuevos; han existido esencialmente durante cuatro décadas. La mayoría de los ERPs que veo hoy en día no aportan mucho valor en comparación con los que las empresas tenían hace una o dos décadas. He visto muchos ERPs antiguos que están bien, y los nuevos ERPs a menudo no son sustancialmente mejores, especialmente considerando los millones invertidos en proyectos de migración ERP. En estos proyectos masivos, veo una productividad abismal por parte de las empresas de TI. Mi argumento es mirar a empresas como JD.com, Amazon o Rakuten. ¿Cuántas personas necesitan estas empresas para realizar tareas similares? Usualmente, terminas con proporciones insanas. Por ejemplo, Zalando, una gran empresa europea de ecommerce con sede en Berlín, Alemania, construyó su propio ERP con un equipo que es más pequeño que la mayoría de los equipos que he visto en empresas de tamaño similar que necesitan migrar su ERP. Así que, ya ves, por un lado, tienes una empresa como Zalando, capaz de desarrollar su propio ERP, completamente hecho a la medida de sus necesidades. Hace un muy buen trabajo al ser un ERP adecuado para ellos, y el costo y el número de personas involucradas son solo una fracción de lo que otras empresas de tamaño similar necesitan simplemente para realizar una actualización de versión. El costo es, de nuevo, solo una fracción. Planteo el desafío de si es necesario tener a tantas personas involucradas, y ese es el problema con el trabajo de cuello blanco en el siglo XXI. Para ser un empleado muy bueno, significa que necesitas tener el coraje de automatizarte, de volverte obsoleto.
Esto es algo muy peculiar. Cuando los trabajadores de cuello azul estaban siendo hechos obsoletos, lo hacían otros. Pero hoy en día, casi no quedan trabajadores de cuello azul. Se requiere una mentalidad diferente, y por eso existe una lucha para adaptarse a este nuevo paradigma, proveniente en su mayoría de la industria del software. Está bien automatizarte hasta el punto de volverte obsoleto, porque en realidad no te estás volviendo obsoleto; no hay límite para la ingeniosidad humana. Solo estás automatizando algunas tareas, liberándote para abordar el siguiente desafío, que es incluso más interesante que el anterior. Empresas como Amazon no despiden a sus ingenieros de software tan pronto como resuelven un problema. Los recompensan y los promocionan para enfrentar el siguiente problema, más difícil.
En respuesta a una pregunta sobre practicantes de supply chain atrapados en un pensamiento analítico de la posguerra, estoy de acuerdo en que, para muchas empresas, no para todas, la ingeniería de software ha evolucionado. Se define a sí misma como un proceso centrado en las personas, o un proceso interpretativo. Estoy de acuerdo. La industria del software no se limita a tecnologías duras y fundamentales. Aunque algunos puestos requieren habilidades técnicas cuantitativas increíbles, la mayor parte de la industria del software se percibe como poseedora de un enfoque centrado en las personas, una cultura compartida.
En gran medida, creo que el dominio que Estados Unidos y Silicon Valley tienen sobre el software en todo el mundo se debe a la dificultad de replicar su cultura. La cultura tiende a ser muy intangible y difícil de documentar. Cuando la documentas, domas el ingrediente caótico necesario para la innovación. Si documentas la cultura, la organizas y la procesas, de repente pierdes ese aspecto de surgimiento crudo y caótico de ideas e innovaciones.
Existen lugares como Silicon Valley donde esta cultura es prevalente, y están adelantados a su tiempo en este sentido. Para concluir sobre este tema, me gustaría citar a William Gibson, quien dijo, “El futuro ya está aquí; simplemente no está distribuido de manera uniforme.” Veo que esta cultura ahora se replica a escalas mucho más pequeñas en muchos otros lugares, y el proceso continuará y crecerá con el tiempo.
Eso es todo por hoy. Nos vemos la próxima vez. En nuestra próxima sesión, estaremos discutiendo un tema que puede ser bastante deprimente pero es muy importante: ciberseguridad. ¡Nos vemos la próxima vez!
