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 (principal 1/5)
20:12 Diseño (principal 2/5)
25:37 Construcción (principal 3/5)
30:29 Pruebas (principal 4/5)
34:09 Mantenimiento (principal 5/5)
41:12 Identidad (trincheras 1/8)
46:35 Resumen (trincheras 2/8)
51:43 Prácticas (trincheras 3/8)
56:47 Bastiones (trincheras 4/8)
01:02:00 Escritores de código (trincheras 5/8)
01:06:23 Tolerancia al dolor (trincheras 6/8)
01:14:55 Productividad (trincheras 7/8)
01:21:37 Lo desconocido (trincheras 8/8)
01:27:00 Conclusión
01:29:55 4.6 Ingeniería de software para la cadena de suministro - ¿Preguntas?
Descripción
Domar la complejidad y el caos es la piedra angular de la ingeniería de software. Considerando que las cadenas de suministro son tanto complejas como caóticas, no debería sorprendernos demasiado que la mayoría de los problemas de software empresarial que enfrentan las cadenas de suministro se reduzcan a una mala ingeniería de software. Las recetas numéricas utilizadas para optimizar las cadenas de suministro son software y, por lo tanto, están sujetas al mismo problema. Estos problemas aumentan en intensidad junto con la sofisticación de las recetas numéricas en sí mismas. La ingeniería de software adecuada es para las cadenas de suministro 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 la cadena de suministro. Soy Joannes Vermorel y hoy presentaré “Ingeniería de Software para la Cadena de Suministro”. El software es la base de una práctica moderna de gestión de la cadena de suministro, sin embargo, la mayoría de los libros de texto sobre cadena de suministro subestiman enormemente el papel del software en la cadena de suministro. El software para la cadena de suministro no es un mero requisito como el acceso a los medios de transporte; es mucho más que eso. Desde la perspectiva de los profesionales de la cadena de suministro, la mayor parte del trabajo está impulsado por el software, impulsado por errores de software o limitaciones del software, y impulsado por preocupaciones relacionadas con el software.
La ingeniería de software es la disciplina que tiene como objetivo ayudar a las personas a crear un mejor software, obtener más beneficios del software, crear este software más rápido y gastar menos para lograr más. El objetivo de esta conferencia es comprender de qué se trata la ingeniería de software y comprender su relevancia principal para la cadena de suministro. El objetivo de esta conferencia también es comprender qué puede hacer usted, como profesional de la cadena de suministro, para evitar debilitar su cadena de suministro ya sea a través de acciones o inacciones que, desafortunadamente, hayan antagonizado sus proyectos de software.
El siglo XX ha sido el siglo de la mecanización de la fuerza laboral. Las grandes empresas y las grandes cadenas de suministro, tal como las conocemos, surgieron en el siglo XX y el progreso logrado mediante la mecanización de la fuerza laboral ha sido increíble. Durante el transcurso del último siglo, para casi todas las tareas intensivas en mano de obra que son relevantes para la cadena de suministro, como la producción o la distribución, la productividad se ha incrementado 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. El tipo de intuición que se aplica cuando pasamos de la mecanización de la fuerza laboral física no se traduce en absoluto en el tipo de intuición que se aplica cuando pasamos 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 ocupaba de tareas muy intensivas en mano de obra ya está detrás de nosotros.
En 2020, en Francia, había 27 millones de personas con empleos de cuello blanco, es decir, empleados de oficina, mientras que solo quedaban menos de un millón de personas que eran trabajadores de fábrica. La proporción es de 27 a 1. Cuando comenzamos a analizar en qué consiste la mecanización del trabajo intelectual, es muy sorprendente y también está muy relacionado con una paradoja conocida como la paradoja de Moravec.
Hans Moravec, un científico de la computación, señaló en 1980 que en lo que respecta a la informática, las tareas que parecían más difíciles para la mente humana, como convertirse en un gran maestro de ajedrez, eran en realidad los tipos de tareas más fáciles de abordar con computadoras. Por el contrario, si observamos tareas que parecen extremadamente fáciles para los humanos, como mantenerse de pie 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 empleados de cuello blanco, son los propios empleados de cuello blanco quienes lo hacen. Esto no fue así con los trabajadores de fábrica de cuello azul; no fueron ellos quienes decidieron que la fábrica se mecanizara aún más y que sus empleos fueran eliminados. Sin embargo, esto es lo que está sucediendo con los empleos de cuello blanco. Por lo tanto, tenemos un desafío en el que no solo el proceso de mecanización es profundamente contraintuitivo debido a la paradoja de Moravec, sino que la gestión de las personas a cargo de implementar esta mecanización, es decir, los ingenieros de software, también es muy contraintuitiva. Este es probablemente uno de los mayores desafíos para la cadena de suministro: la gestión de las personas que estarán a cargo, de una forma u otra, de lidiar con esta mecanización.
Aquí, no puedo dejar de señalar que muchas cadenas de suministro y empresas asociadas todavía están firmemente arraigadas en una mentalidad del siglo XX, donde abordas el mundo corporativo como si tuvieras personas de cuello blanco haciendo el trabajo intelectual, y luego ellos encuentran 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 puesto de trabajo de oficina en comparación con los puestos de trabajo de fábrica en Francia, y estadísticas similares en la mayoría de los países desarrollados, esto no es lo que sucede ahora. Literalmente se trata de automatizar tu propio trabajo, y significa que en este mundo del siglo XXI, los mejores empleados de cuello blanco son aquellos que constantemente logran automatizarse a sí mismos, hacerse obsoletos y luego pasar a otra cosa. Esto es muy desafiante para muchas empresas que todavía están muy arraigadas en la mentalidad del siglo XX.
Las opiniones divergen ampliamente sobre la noción misma de ingeniería de software. Una de las críticas más fuertes provino de Edsger Dijkstra, uno de los padres fundadores de la ciencia de la computación. 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 convierte en 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 convierte en 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 garantizar el éxito de la creación de software útil y superior, entonces la ingeniería de software está condenada en su mayoría. 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 hay una receta para eso. Además, cada éxito tiende a consumir la oportunidad misma que se necesitó para lograr este éxito, 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. Creo que el problema principal es definir la ambición de la ingeniería de software. Si decidimos que la ambición de la ingeniería de software es el éxito en la creación de software, entonces efectivamente está condenada. Sin embargo, si decidimos abordar la ingeniería de software como una subrama estrecha de la psicología experimental, creo que podemos reunir, a través de este enfoque, ideas valiosas y aplicables, y esta es la perspectiva que adoptaré hoy en esta conferencia. Por lo tanto, la ingeniería de software se trata de los propios 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á en constante cambio. 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 del examen de lo que hacen sus practicantes puede ser muy fructífero. Por ejemplo, en la ciencia, ahora está ampliamente establecido que un conflicto de intereses conduce a una mala ciencia y una corrupción del conocimiento. Este punto fue abordado anteriormente en la conferencia titulada “Investigación de mercado adversarial para software empresarial”. Desde esta perspectiva, vemos que es posible reunir ideas de amplia aplicabilidad y relevancia si nos enfocamos en los propios practicantes. Por lo tanto, la ingeniería de software se trata de las personas que están lidiando con la tecnología del software, sus luchas y sus procesos, y no tanto sobre la tecnología en sí.
Hoy es la sexta conferencia de los cuatro capítulos. Este capítulo está dedicado a las ciencias auxiliares de la cadena de suministro. Estas ciencias auxiliares representan elementos que considero de importancia fundamental para una práctica moderna de la cadena de suministro, pero no son estrictamente elementos de la cadena de suministro. Son más bien elementos de apoyo para su práctica de la cadena de suministro.
Hasta ahora, en este cuarto capítulo, comenzamos con la física de la computación, tratando con computadoras modernas, y luego avanzamos a través de una escalera de abstracciones. Pasamos de las computadoras a los algoritmos, que representan los fragmentos más pequeños e interesantes del software. Luego pasamos a la optimización matemática, que es de interés para la cadena de suministro pero también para muchos otros emprendimientos de software relevantes, como machine learning. Hemos visto que la optimización matemática es directamente interesante para la cadena de suministro, pero también es directamente interesante para el machine learning, que a su vez también es de interés para la cadena de suministro.
En cuanto a la optimización matemática y el machine learning, la mayoría de los conceptos y paradigmas interesantes en la actualidad son de naturaleza programática. No son solo algoritmos simples; es algo increíblemente expresivo y debe abordarse desde la perspectiva de los lenguajes de programación. Por eso, la última conferencia trató sobre lenguajes y compiladores.
Hoy, seguimos avanzando en esta escalera de abstracción y nos enfocamos en las personas en lugar de enfocarnos en lo que están haciendo. Nos vamos a centrar en los ingenieros de software mismos, y ese es todo el punto de este análisis de ingeniería de software.
Hoy, presentaré específicamente dos conjuntos de puntos de vista sobre la ingeniería de software. Primero, presentaré el punto de vista predominante, que creo que domina el campo. Desafortunadamente, este punto de vista predominante ha generado críticas, como se mencionó anteriormente, con personas que presentan enfoques de autoayuda que algunos, incluido yo mismo, tenemos motivos para oponernos porque no presentan una ambición realista para la disciplina de la ingeniería de software. Sin embargo, examinaré este punto de vista predominante, aunque sea porque algunos conceptos equivocados siguen siendo increíblemente populares. Conocer estos conceptos equivocados es de suma importancia, aunque sea para eliminar a personas incompetentes que puedan poner en peligro su cadena de suministro debido a su incompetencia.
Luego, me acercaré a una perspectiva desde las trincheras, que es una colección de elementos arraigados en mi experiencia personal como CEO de una empresa de software que opera precisamente en el campo del software de cadena de suministro empresarial. Como veremos, las ideas se refieren mucho más a las personas que a la tecnología en sí.
El punto de vista predominante de la ingeniería de software establece 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 generalmente comienza con una Solicitud de Propuesta (RFP), Solicitud de Cotización (RFQ) o Solicitud de Información (RFI). Este enfoque se hereda de prácticas del siglo XX que han tenido mucho éxito en la ingeniería mecánica y las obras de construcción. Sin embargo, creo que en lo que respecta al software, estos enfoques para la recopilación de requisitos son profundamente equivocados.
En el software, no sabes lo que quieres; simplemente no lo sabes. Saber lo que quieres es siempre la parte más difícil del software. Por ejemplo, si consideramos un problema simple como el reabastecimiento de inventario, la definición del problema es increíblemente sencilla: en cualquier momento, quiero saber la cantidad que debo reabastecer o pedir nuevamente para cada SKU. El problema en sí es simple, pero definir qué es una buena cantidad se vuelve diabólicamente complejo y difícil. Como regla general, aclarar los requisitos es mucho más difícil que escribir el software en sí.
Solo confrontando tu intuición con la retroalimentación que te da el mundo real puedes dejar que los requisitos vayan surgiendo gradualmente. Los requisitos no caen del cielo; solo 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 forma de tener esta interacción es tener el producto de software, ya que la recopilación de requisitos es fundamentalmente un proceso muy empírico y emergente. El problema es que cuando terminas con los requisitos, tener los requisitos se vuelve irrelevante porque, si tienes los requisitos, significa que ya tienes el producto correspondiente que implementa esos requisitos. Entonces, cuando tienes acceso a los requisitos adecuados, ya tienes el producto en producción, funcionando, y el hecho de que tengas esos requisitos es algo irrelevante.
Por lo tanto, el punto es que comenzar el proceso a través de la lente de los requisitos es, en mi opinión, una locura. Los requisitos probablemente deberían venir al final como una documentación en una etapa tardía, donde documentas todas las razones principales que te llevaron a implementar el producto de la manera en que lo hiciste, no al revés.
Una vez que se establecen los requisitos, el enfoque clásico establece que se debe proceder con la fase de diseño. Estoy de acuerdo en que, en algún momento, puede haber algún diseño. Sin embargo, el tipo de pensamiento que se lleva a cabo en esta fase de diseño a menudo está equivocado. El problema se reduce a controlar el costo del cambio. La perspectiva clásica no relacionada con el software sobre el costo del cambio es que el costo aumenta exponencialmente con el tiempo. Por ejemplo, si cambias el diseño de un automóvil muy temprano cuando solo estás lidiando con un plano, el costo del cambio es mínimo. En cambio, si esperas hasta que millones de esos automóviles estén en las carreteras, el costo del cambio es increíblemente alto porque implica un llamado a revisión, lo que puede ser increíblemente costoso.
Sin embargo, a diferencia del ámbito físico, en el ámbito del software, el costo del cambio no aumenta naturalmente de manera exponencial. El aumento del costo no se puede mitigar por completo; sin embargo, 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 con el tiempo. Nunca he visto que una base de código de un software empresarial disminuya significativamente de un año a otro; tienden a seguir creciendo. Sin embargo, es posible gestionar el costo del cambio hasta cierto punto.
En la actualidad, este aspecto está siendo reconocido de manera más amplia, incluso en círculos de software. Por cierto, esta es la esencia de la metodología ágil. Es posible que hayas visto estos términos flotando cuando la gente dice: “Oh, tenemos esta metodología ágil de software”. Uno de los mayores objetivos de la metodología ágil es controlar el costo del cambio. No entraré en los detalles hoy sobre la metodología ágil, pero basta decir que creo que este enfoque está ligeramente equivocado cuando se trata de cómo exactamente se controla este costo del cambio.
Observé que el costo del cambio principalmente se origina en las decisiones que se toman sobre el software y, más específicamente, en el hecho de que es muy difícil resistir la tentación de tomar decisiones. Imagina que estás viendo un posible producto de software futuro y hay muchas decisiones que tomar. El intento inicial sería tomar esas decisiones solo para aclarar lo que tienes frente a ti. Por el contrario, una muy buena fase de diseño, en lugar de un buen diseño, es la capacidad de posponer todas las decisiones que no son absolutamente necesarias, donde el producto no requiere que esas decisiones se tomen ahora. De hecho, si no tomas la decisión, mientras la decisión no se tome y no hayas establecido que necesitas adoptar este enfoque de diseño específico o enfoque tecnológico, aún está flotando en el aire, listo para ser cambiado porque aún no se ha decidido nada.
Uno de los aspectos para controlar el costo del cambio es aprender a posponer todas las decisiones en la mayor medida posible. Desde una perspectiva de la cadena de suministro, esto parece muy extraño porque significa que para todas las personas en el equipo de software y todas las personas que observan el producto y el equipo de software, parece como si se les mantuviera en la oscuridad. Es aún peor que eso porque se les mantiene en la oscuridad a propósito, lo cual es muy desconcertante. Sin embargo, es precisamente lo que debe suceder y se debe hacer a propósito. Por eso es desconcertante, por decir lo menos.
Ahora, si las decisiones prematuras de diseño se basan en la necesidad a veces equivocada de control, los problemas asociados con esta necesidad de control no se detienen ahí. Una vez que la fase de diseño ha terminado, la visión predominante en la ingeniería de software establece que debemos proceder con la construcción del software, también llamada fase de implementación con frecuencia. La forma en que se hace típicamente es presentar algún tipo de proyección de cascada, también llamada gráficos de Gantt. Esto es lo que puedes ver en la pantalla. Creo que este enfoque, los gráficos de Gantt y las cascadas, es increíblemente tóxico y la toxicidad de este enfoque no debe subestimarse en lo que respecta al software. Abordar el problema de esta manera es literalmente condenar tu cadena de suministro al fracaso, al menos en lo que respecta a sus iniciativas de software.
Una forma mucho mejor de entender el problema y abordar la construcción del software es pensar en ello como un proceso de aprendizaje. La construcción del software se trata de 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 está emergiendo del proceso de construcción. El problema clave con una predicción de cascada es que estás proyectando lo que estás a punto de descubrir. Esto simplemente no es posible por definición. Lo que estás a punto de descubrir era desconocido hasta que descubres esos elementos. No puedes proyectar tus descubrimientos. Puedes esperarlos, pero no puedes planificar los detalles precisos de lo que estás a punto de descubrir. Puedes tener corazonadas, pero eso es lo mejor que puedes obtener. La idea de que puedes convertir esas vagas intuiciones en una predicción precisa de cascada es, nuevamente, una completa locura.
Por cierto, este pequeño aparente paradoja sobre la construcción de software como un proceso de aprendizaje también explica por qué a veces replicar un 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 este equipo tiene acceso a la comprensión o las lecciones que llevaron a la producción del software que están tratando de copiar, entonces típicamente replicar el producto de software - volver a implementarlo o recodificarlo - se puede hacer con solo una fracción mínima 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 tienen acceso es el código fuente, el equipo muy frecuentemente terminará con un producto de muy baja calidad porque esencialmente, todas las partes de aprendizaje o los fragmentos de conocimiento se han perdido. Solo has replicado la apariencia superficial del producto.
Desde una perspectiva de la cadena de suministro, el mayor desafío aquí es renunciar voluntariamente y controlar tu necesidad de control. El proceso de cascada es una expresión de una empresa que quiere controlar el proceso. Por ejemplo, si digo: “vamos a tener este proyecto bajo control”, eso se percibiría como algo muy razonable. ¿Por qué harías lo contrario? ¿Por qué dirías, por ejemplo, “vamos a tener 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 completamente tu capacidad para entregar un producto de alta calidad al final. Controlar tu deseo de control es, desde una perspectiva de la cadena de suministro, probablemente el mayor desafío cuando se trata de la construcción de software.
Desde la aparición de los programas de computadora, han estado plagados de errores y defectos. Para abordar esos problemas obvios, la opinión generalizada es que se debe realizar pruebas. Las pruebas toman muchas formas. En cuanto a la necesidad de pruebas, estoy de acuerdo, aunque esto es muy vago en este momento. Algunas herramientas enfatizan que las pruebas deben realizarse después de la construcción, algunas enfatizan que las pruebas deben realizarse durante la construcción y otras especifican que las pruebas deben realizarse antes de la construcción. Algunos enfoques afirman 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 debes hacer lo que sea necesario para mantener el ciclo de retroalimentación lo más corto posible. Discutimos este punto en la conferencia anterior: mantener el ciclo de retroalimentación lo más corto posible es de vital importancia para realmente obtener algo que funcione en el mundo real. Por lo tanto, normalmente recomendaría prestar atención a si lo que estás haciendo en términos de pruebas realmente está acortando este ciclo de retroalimentación o no. Por ejemplo, para la mayoría de las situaciones, no recomendaría naturalmente el desarrollo impulsado por pruebas (una metodología que dice que las pruebas vienen primero), simplemente porque para la mayoría de las situaciones, las pruebas primero solo retrasarán el tiempo que lleva obtener retroalimentación sobre tu software del mundo en general.
Sin embargo, mi mayor preocupación acerca de las pruebas es una limitación no mencionada, algo que parece ser generalmente pasado por alto. Las pruebas en última instancia solo pueden evaluar el cumplimiento de las reglas que tú mismo has establecido. El problema es que en el software no hay restricciones estrictas. No hay una forma química de abordar la adecuación de tu producto con respecto al problema que estás intentando resolver. Esto es muy diferente al ámbito físico. Por ejemplo, en la ingeniería mecánica, hay un criterio canónico: la tolerancia dimensional de una pieza. Cualquier cosa que estés diseñando en términos de ingeniería mecánica, la tolerancia dimensional va a ser de importancia primordial. Es un candidato obvio y natural. Sin embargo, no hay cosas obvias y naturales en el software.
El problema aquí se convierte en uno de adecuación. Si queremos tomar un ejemplo de la cadena de suministro, como existencias de seguridad, es completamente sencillo diseñar un conjunto 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 te puede decir que las existencias de seguridad sean una mala idea en primer lugar. Solo estás probando lo que conoces.
Cuando estamos lidiando con una máquina física, esperamos desgaste y, por lo tanto, esperamos algún tipo de mantenimiento para mantener la máquina en funcionamiento. Sin embargo, ¿por qué el software necesitaría algún tipo de mantenimiento para seguir funcionando? Ciertamente, necesitamos reemplazar las computadoras cuando se descomponen de vez en cuando. Sin embargo, este aspecto es muy marginal y, en el software empresarial, las fallas 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 pequeño.
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 disposición a pagar de los propios clientes. Si un proveedor puede cobrar una tarifa de mantenimiento anual del 20% con respecto a lo que se pagó por la configuración del software durante el primer año, entonces el proveedor de software cobrará eso. Esencialmente, desde la perspectiva del costo, el costo del mantenimiento está determinado por la disposición a pagar de los clientes empresariales.
El segundo factor es el tipo de mantenimiento que necesita ocurrir solo para mantener el software en funcionamiento. De hecho, cada día que pasa, el entorno que rodea al producto de interés se aleja del producto. El sistema operativo sigue evolucionando, el sistema de base de datos sigue evolucionando, y lo mismo se puede decir de todas las bibliotecas de terceros que son utilizadas por el software. Ningún producto de software es una isla. Cada producto de software depende de una miríada de otros productos de software, y esos otros productos están evolucionando por sí mismos. Las personas que están desarrollando esos productos de software siguen trabajando en ellos y, a medida que trabajan en esos productos, los siguen cambiando. Así, llega un momento en el que el producto que tienes simplemente deja de funcionar porque hay una incompatibilidad. No has hecho nada excepto no mantener el ritmo del resto del mercado. El segundo factor es todo el mantenimiento que necesita llevarse a cabo solo para mantener el software en funcionamiento y compatible con el resto del mercado.
El tercer factor es la cantidad de trabajo que se necesita para mantener el producto útil. De hecho, el software fue diseñado e ingenierizado en un cierto momento, y cada día que pasa, el mundo se aleja de lo que se vio en el momento en que se diseñó el producto en primer lugar. Así, incluso si nada se rompe realmente en términos de compatibilidad de hardware, resulta que a medida que el mundo cambia, inevitablemente la utilidad del producto disminuye porque el mundo simplemente se aleja de las expectativas que se construyeron en el producto. Si quieres mantener el software útil, necesitas mantener constantemente el software.
Desde una perspectiva de la cadena de suministro, el mantenimiento es un gran desafío, y tocamos este aspecto en la conferencia anterior, que trataba sobre la entrega orientada al producto para la cadena de suministro. El costo del mantenimiento afecta significativamente los beneficios capitalistas que puedes obtener de tu proyecto de software. Idealmente, quieres que tu proyecto de software tenga un retorno de inversión muy alto, pero para lograrlo, debes asegurarte de no terminar con costos de mantenimiento masivos. Estos costos desharán por completo el beneficio capitalista y el retorno que puedes obtener de tu inversión en software.
El mayor desafío aquí, nuevamente desde una perspectiva de la cadena de suministro, es que la forma más sencilla de minimizar los costos de mantenimiento es centrarse en lo que no cambia. Como mencioné anteriormente, la mayoría de los costos están relacionados con las cosas que están cambiando, ya sea en el ecosistema de software o en el mundo en general. Sin embargo, si te enfocas en las cosas que no cambian, entonces lo que obtienes es básicamente la mayor parte de tu software que solo se degradará lentamente porque, precisamente, la mayoría de lo que aborda tu software son las cosas que no cambian.
El problema es que centrarse en lo que no cambia es más fácil decirlo que hacerlo, porque tienes una fuerza muy humana que se opone a esta intención: el miedo a perderse algo. Cuando estás mirando la prensa, los medios de comunicación, tus colegas, etc., habrá un flujo constante de novedades, palabras de moda y cada una de estas palabras de moda tiene este impulso, debido al miedo a perderse algo, de simplemente hacer la cosa y no quedarse atrás. Por ejemplo, todas esas palabras de moda serían IA, blockchain, IoT y todas esas cosas que están muy presentes. Creo que en la cadena de suministro, estas palabras de moda son realmente una distracción y contribuyen significativamente a los problemas de mantenimiento porque son una distracción de lo que no cambia. Por el contrario, cuando comienzas a mirar esas palabras de moda, estás montando una ola y estás montando exactamente el tipo de cosas que es muy probable que cambien con el tiempo, lo que infla tus costos de mantenimiento con el tiempo.
Ahora que hemos terminado con la visión convencional de la ingeniería de software, adentrémonos en una serie de consejos personales que espero sean útiles para llevar a cabo iniciativas de software teniendo en cuenta la cadena de suministro. Uno de los problemas más frecuentes al tratar con personas de software es una concepción errónea sobre su propia identidad, y estoy robando esta idea de un empresario llamado Paul Graham. Un ingeniero, por ejemplo, dirá: “Soy un ingeniero de Python”. Si bien puede que no sea tan extremo, es muy frecuente que los ingenieros de software perciban su propia identidad a través de la serie corta de tecnologías que han dominado, que conforman su conjunto de habilidades. Esta confusión entre su identidad y su conjunto de habilidades actual tiende a ser reforzada por las prácticas de contratación que prevalecen en el mundo de la tecnología de la información y el software en general. Desde el punto de vista de contratación, hay muchas empresas que afirman en sus anuncios de trabajo: “Necesito un programador de Python”. Entonces, hay alguien pensando, “Soy un programador de Python”, y luego hay una empresa que va a publicar una posición de trabajo donde básicamente está escrito, “Necesito un programador de Python”. Así que de repente tener la identidad correcta no es solo una cuestión de percepción; hay recompensas financieras asociadas con tener la identidad correcta, la etiqueta correcta que puedes adjuntar a ti mismo, lo que te hace más atractivo en el mercado.
Sin embargo, esta percepción impulsada por la identidad, donde las tecnologías se vinculan a uno mismo como ingeniero de software, conduce a numerosos problemas que afectan prácticamente a todos los proyectos de software, y en particular a los proyectos de software de la cadena de suministro. Cuando se interactúa con una persona, típicamente un ingeniero de software, que tiene su identidad fuertemente vinculada a la tecnología que está en su lugar en su empresa, el problema es que cada crítica a la tecnología tiende a ser tomada desde un ángulo personal. Si dices que soy un programador de Python y criticas mi software, lo tomo como algo personal. El problema es que tan pronto como las personas toman la crítica de la tecnología como una crítica personal, se vuelve muy difícil razonar sobre esos problemas. Estos ingenieros de software, desafortunadamente, tienden a desviar todos los comentarios, simplemente porque lo ven parcialmente como una crítica personal.
Por otro lado, si la empresa está utilizando una tecnología que no es la tecnología percibida como identidad principal por el ingeniero de software, por ejemplo, si su empresa tiene algunos sistemas implementados en Java y tiene un ingeniero de software que dice: “Soy un programador de Python”, entonces todos los problemas serán percibidos a través de la lente de que esta tecnología es inferior. Nuevamente, ese es otro problema donde la crítica y los comentarios serán desviados como una actitud de “no es mi problema; esto es simplemente debido a esta tecnología muy pobre que se usó aquí y ahora en esta empresa”. En ambas situaciones, ya sea que el ingeniero de software tenga una identidad que esté vinculada a la tecnología que estás utilizando o tenga una identidad vinculada a una tecnología que no estás utilizando, se crean una serie de problemas y los comentarios se desvían en lugar de aprovecharse para mejorar la tecnología.
Ahora, desde una perspectiva de la cadena de suministro, debemos tener en cuenta que el entorno de la cadena de suministro es increíblemente caótico y, por lo tanto, los problemas ocurrirán todo el tiempo. Precisamente debido a este caos ambiental, es muy importante tener equipos de ingenieros de software que puedan enfrentar directamente estos problemas y hacer algo al respecto, y no simplemente desviar los comentarios cuando ocurren. Es crucial reunir equipos que no fomenten el drama sobre el caos de la cadena de suministro debido a su percepción de su identidad.
Esta idea se extiende a los ingenieros de software, que a menudo eligen tecnologías que se ajustan a su identidad o a la identidad que desean adquirir. Eligen tecnología para adquirir habilidades, para poder agregar otra palabra clave a su currículum. Sin embargo, este enfoque lleva a elegir tecnologías por razones no relacionadas con 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 hay beneficios financieros reales asociados con tener una lista de palabras clave en él. Las mejores compañías de software a menudo desprecian los currículums con una larga lista de palabras clave. Como CEO de Lokad, si veo un currículum con media página de palabras clave, lo descarto directamente. Sin embargo, muchas compañías, especialmente las mediocres, buscan activamente personas con muchas palabras clave, pensando que estas personas serán increíblemente versátiles y ágiles dentro de la organización. Por mi experiencia, esto suele ser lo contrario.
Continuando con el tema de la identidad y la construcción de currículums, es vital prestar atención al hecho de que los arquitectos de software no deben estar demasiado apegados a ninguna tecnología en particular. Ya es difícil contratar ingenieros de software, por lo que a veces se deben hacer compromisos. Sin embargo, cuando se trata de arquitectos de software, comprometerse seleccionando personas con un apego emocional a una determinada tecnología puede ser desastroso. Estas personas tendrán un impacto a gran escala en su empresa.
Este problema de sesgo en la construcción de currículums no se limita a los ingenieros de software o a los profesionales del software. También ocurre entre el personal de TI. Por ejemplo, he conocido a varios directores de TI en grandes empresas que querían hacer la transición a SAP mientras su ERP existente estaba perfectamente bien. Los enormes costos 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 estaba produciendo un comportamiento irracional, donde el interés personal del director de TI en implementar SAP en su currículum estaba superando el interés de la propia empresa.
Desde una perspectiva de la cadena de suministro, es esencial prestar atención a estos conflictos de interés. No se necesitan 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 recetar medicamentos incorrectos debido a conflictos de interés, incluso cuando están en juego vidas. Esto demuestra que los conflictos de interés son increíblemente tóxicos. Imagina cómo se desarrollan estos problemas en la gestión de la cadena de suministro, donde no hay vidas en juego y la principal preocupación es el dinero. Incluso hay menos reticencia para permitir que los conflictos de interés se desarrollen en este contexto.
A diferencia del ámbito físico, el ámbito del software ofrece muy pocas restricciones sobre cómo proceder con las iniciativas de software y el enfoque del trabajo. La naturaleza humana no tolera el vacío y las personas pueden sentirse inquietas ante la falta de estructura. Como resultado, han surgido numerosas prácticas a lo largo de los años y continúan surgiendo nuevas. Con cada práctica surge una noción de ortodoxia. Algunos ejemplos de estas prácticas incluyen la programación extrema, el diseño impulsado por dominios, el diseño impulsado por pruebas, los microservicios, Scrum y la programación ágil. Hay muchas prácticas y cada año surgen nuevas.
Con cada práctica surge una noción de ortodoxia. Tan pronto como las personas comienzan a seguir una práctica, pueden cuestionarse si están cumpliendo con los principios fundamentales. Los ingenieros de software son personas y a las personas les encantan los rituales y las tribus. Una práctica proporciona un sentido de pertenencia a una tribu con creencias compartidas. Es por eso que también encontrarás reuniones asociadas con estas prácticas, satisfaciendo una necesidad muy humana.
Puede ser difícil e incluso deprimente mirar un problema, sin estar seguro de nada y casi sin nadie con quien relacionarse para abordar el problema. 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 su empresa puede aumentar la moral y ayudar a contratar posibles solicitantes.
En una entrevista de trabajo, cuando las personas preguntan cómo trabajas, no es exactamente convincente decir que improvisas y no tienes reglas. Es más eficiente inspirar confianza presentando una práctica como si resolverá problemas dentro de la empresa. El punto clave es que, a corto plazo, estas prácticas no son del todo malas, incluso si son en su mayoría irracionales. Generar un sentido de pertenencia puede ser beneficioso. Sin embargo, se vuelve perjudicial si las prácticas se toman demasiado en serio o durante demasiado tiempo. Una práctica puede ser interesante simplemente porque te obliga a mirar el problema desde un ángulo diferente. Pero una vez que has mirado el problema desde un ángulo diferente, debes intentar encontrar otro ángulo. No debes quedarte con un ángulo durante demasiado tiempo. Desde una perspectiva de la cadena de suministro, esto ilustra la extrañeza radical del ámbito del software.
En el piso de la fábrica, la excelencia significa hacer siempre exactamente lo mismo. En el mundo del software, es exactamente lo contrario. Si estás haciendo lo mismo, entonces es una receta para la estancamiento y el fracaso a largo plazo.
El software es complejo y el software empresarial aún más. Con frecuencia, varios ingenieros terminan trabajando en una iniciativa determinada, lo que lleva a una tendencia natural a la especialización. Cuando un ingeniero trabaja en una cierta parte del código base, hay una inclinación natural a asignar la misma persona cuando las nuevas tareas requieren tocar esa misma parte del código base. Los beneficios son reales, ya que esta persona ya está familiarizada con el código y puede ser más productiva.
El principal problema con la especialización es que puede llevar a un sentido de propiedad sobre partes del código base, creando diversos problemas. Hay dos clases de problemas asociados con esta propiedad: el “factor camión” y los juegos de poder. El factor camión se refiere al riesgo de perder a un empleado que posee conocimientos o habilidades únicas. Esto podría deberse a que el empleado se va a otra empresa o no puede 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 esta ventaja para exigir un salario más alto u otros beneficios.
En mi experiencia, los ingenieros de software generalmente 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. Hay muchas prácticas de ingeniería de software que intentan abordar este problema de frente, como la programación en pareja. Sin embargo, la clave es darse cuenta de esta clase de problema, en lugar de simplemente aferrarse a una práctica en particular que se supone que aborda el problema. Esto se debe a que dichas prácticas pueden crear otros problemas, distraerte o limitar 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 tenemos un equilibrio muy sutil entre las ganancias de productividad logradas al tener personas especializadas en partes del código y los riesgos asociados con tener esas personas como propietarias de esas partes del código. Lo que quieres es cultivar una situación en la que siempre haya cierto grado de redundancia en términos de conocimiento sobre la base de código de todo el equipo, para que cada ingeniero tenga algún tipo de superposición de competencia. Este es un equilibrio muy sutil que debes lograr si quieres mantener algún grado de productividad. La única forma de hacerlo en el mundo real es a través de una cultura bien entendida sobre la ingeniería de software. No hay un proceso que pueda garantizar que las personas se interesen por el trabajo de sus colegas. No puedes tener un proceso sobre la curiosidad; tiene que ser parte de la cultura.
Evaluar las habilidades y competencia de los ingenieros de software es difícil, y esta pregunta es clave porque aunque el software es claramente un esfuerzo de 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 rendimiento del equipo en su conjunto.
Un aspecto que observé que se subestima en gran medida por parte de las personas fuera de la industria del software, y a veces también por parte de las 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 incansable que te dirá si tu código es correcto o incorrecto. El compilador es completamente predecible y tiene una paciencia infinita.
Por otro lado, tienes la audiencia de tus colegas, que probablemente 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 fue escrito por otra persona porque te parece tan desconocido. Cuando escribes código para tus colegas, la ventaja es que a diferencia de los compiladores, tus colegas intentarán entender lo que estás tratando de lograr. El compilador no intenta entender tus intenciones; aplica un conjunto de reglas mecánicamente.
Tus colegas intentarán entender, pero desafortunadamente, no son como los compiladores. No tienen una paciencia infinita y pueden confundirse y desorientarse fácilmente con tu código. Es por eso que, por ejemplo, elegir nombres memorables, perspicaces y apropiados es de suma importancia. Un buen programa no se trata solo de tener algo que sea correcto; incluso elegir los nombres de variables, funciones y módulos es de vital importancia si quieres tener un código que funcione bien con tus colegas, y nuevamente, tus colegas incluyen a ti mismo dentro de seis meses. Desde una perspectiva de supply chain, la lecció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 en bruto. Las buenas habilidades de escritura son la habilidad número uno que necesitarás para controlar la complejidad presente en tu cadena de suministro. Controlar la complejidad de tu panorama aplicativo no es un gran desafío técnico; es un desafío de organizar ideas y elementos, y tener una historia coherente en general. Estas son habilidades de escritura muy importantes, y hemos tocado este aspecto en una conferencia anterior titulada “Escribir para la cadena de suministro”.
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 un ingeniero de software en general: la tolerancia al dolor. Creo que esta es la habilidad número uno en el sentido de lo que se necesita para ser realmente un ingeniero de software, no uno excelente, solo ser uno. Más específicamente, cuando digo dolor, me refiero a la resistencia al aburrimiento y la frustración que acompaña al proceso de ingeniería de software al enfrentarse a sistemas que son increíblemente frágiles, mal diseñados y llenos de trampas de todo tipo, a veces por personas que ni siquiera están presentes. Cuando estás lidiando con software, tienes cuatro décadas de problemas acumulados bajo tus pies, y estás luchando 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 para pasar cuatro horas buscando a través de conversaciones aleatorias y semibasura en un foro web que mencionen un código de error similar al que estás enfrentando. Tendrás que pasar por este tipo de tonterías durante horas para llegar al fondo de ello, y a veces lleva semanas resolver un error aparentemente trivial. Por lo tanto, la consecuencia de eso es que tenemos un proceso de selección adversa muy intenso en toda la industria del software, que selecciona a personas que tienen una alta tolerancia al dolor. Este proceso de selección tiene dos consecuencias principales.
Primero, las personas que siguen siendo 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 de los constantes problemas de software que enfrentan. Al seleccionar personas con una tolerancia increíble al dolor, es posible que ni siquiera reconozcan cuando sus acciones están empeorando la situación. Pueden agregar peculiaridades adicionales a los productos de software, aumentando el nivel de dolor al interactuar con el software para todos, incluidos ellos mismos. Sin embargo, si resulta que son increíblemente tolerantes al dolor, no prestan atención. Este proceso de selección adversa deja fuera a personas comunes que prestarían atención pero no se convirtieron en ingenieros de software porque no podían soportar el dolor. Este problema es particularmente intenso para el software de la cadena de suministro porque hay muchas partes que no son muy emocionantes. Algunos aspectos pueden ser necesarios pero mundanos, lo que significa que las personas con alta tolerancia al dolor que operan 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 aceptar un salario más bajo para evitar problemas que generan un intenso dolor, lo hacen. Si alguien ya está bien remunerado, puede decidir aceptar un trabajo que no esté tan bien remunerado pero que venga con el beneficio de un dolor menos intenso. La mayoría de las personas probablemente harían esto, y en la práctica, muchas personas 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 empleos de ingeniería de software mejor remunerados debido a la alta demanda y los salarios más altos en comparación con sus salarios básicos. No tienen el lujo de optar por otra cosa, y así terminan siendo muy prevalentes en la industria.
No hay nada malo en estos países; es simplemente una aplicación mecánica de las fuerzas del mercado. Esto no es un juicio, solo una observación. Lo cierto 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 tienes eso, entonces no eres un ingeniero de software en absoluto. Sin embargo, si la tolerancia al dolor es lo único que tienes, te convertirás en un ingeniero de software bastante pobre. Desde una perspectiva de cadena de suministro, la lección aquí es prestar mucha atención al tipo de equipos que su empresa está reuniendo, ya sea internamente o a través de proveedores de software. Asegúrese de que los ingenieros que se están reuniendo no tengan la tolerancia al dolor como su única habilidad, porque eso significa que tendrá un resultado muy pobre en términos de calidad de software y valor agregado del software. Nuevamente, se requiere tolerancia al dolor, pero no es suficiente.
En 1975, Frederick Brooks ya señalaba que los meses-hombre no eran representativos del valor creado por el software y del valor generado por los ingenieros de software en general. Casi cinco décadas después, las empresas de tecnología de la información se encuentran entre los mayores empleadores del mundo. En 2020, en Estados Unidos, había 3 millones de empleados en la industria de TI, pero menos de 1 millón de personas en toda la industria automotriz. La industria de TI ahora tiene al menos tres veces más personas que la industria automotriz. La mayoría de esas empresas de TI, algunas de ellas absolutamente gigantescas con varios cientos o miles de empleados, ya no cobran por meses-hombre. Esto fue en los años 70. Ahora cobramos por kilo-días, que básicamente son mil días de trabajo. La situación ha empeorado considerablemente en comparación con el problema que Frederick Brooks estaba describiendo hace casi cinco décadas, principalmente debido al increíble aumento en términos de escala y magnitud del problema. Sin embargo, la mayoría de las lecciones tempranas siguen siendo válidas. “El hombre-mes mítico” 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 tienes personas con baja productividad; tienes personas con productividad negativa. Eso significa que cuando comienzan a trabajar en un producto de software, simplemente lo empeoran. Ya no puedes hacer una relación entre la productividad de las personas. Es mucho peor que eso; tienes personas que degradarán activamente tu producto. Eso es un problema masivo. En el otro extremo del espectro, tienes a los llamados ingenieros 10x, personas que tienen diez veces la productividad de un ingeniero promedio, que esperemos tenga una productividad positiva. Estos ingenieros 10x existen, pero esta productividad masiva depende enormemente del contexto. No puedes simplemente trasladar a un ingeniero de software 10x de una empresa a otra, ni siquiera de un puesto a otro, y esperar que esa persona mantenga su increíble productividad. Por lo general, es una combinación de habilidades únicas y una situación específica lo que genera esa productividad. Sin embargo, 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 crea la mayor parte de todos los elementos inteligentes del software y el verdadero valor agregado, mientras que el resto se ocupa de cosas que tienen un valor agregado dudoso en el mejor de los casos. La lección clave aquí, identificada hace cinco décadas, es que cuando te enfrentas a un plazo en la cadena de suministro, la única opción razonable que tienes a tu disposición es reducir el alcance de la iniciativa de software. Todas las demás opciones son peores.
Añadir mano de obra empeora las cosas, como se dice a menudo que añadir mano de obra a un proyecto de software retrasado lo hace aún más tarde. Esta afirmación de Brooks era válida hace cinco décadas y sigue siendo válida hoy en día. Las otras opciones tampoco funcionan. Si empiezas a hacer horas extras, te saldrá mal porque la gente estará cansada y cometerá más errores, retrasando aún más el producto. Si intentas reducir la calidad, terminarás con algo que ya no funciona. Estas cosas se descontrolarán y explotarán en tus manos, así que no puedes comprometer la calidad.
Desde una perspectiva de la cadena de suministro, la lección clave aquí es que si te enfrentas a cualquier iniciativa que parezca requerir más de diez ingenieros de software a tiempo completo, procede con extrema precaución. Por lo general, es una señal de que es un problema muy mal planteado. Se necesita un trabajo en equipo increíble para que diez personas trabajen simultáneamente en el mismo producto y mantengan la productividad. En la cadena de suministro, observo que las personas a menudo son demasiado ambiciosas en términos de escala y número 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 perderlo todo por la fricción. Si estás luchando, mantén tu iniciativa de software enfocada, corta y estrecha.
Mi observación final es sobre un malentendido frecuente con respecto a las grandes empresas. La mayoría de las personas dirían que las grandes empresas son adversas al riesgo, pero esa no es mi experiencia. Mi experiencia es que las grandes empresas son adversas a la incertidumbre, no al riesgo, aunque desde lejos, los dos pueden confundirse. Desde lejos, la explicación racional dada 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 a primera vista, 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 donde el resultado es seguro: fracasará. Sin embargo, estás siguiendo las reglas y todos saben que fracasará. Nadie te culpará por jugar seguro y fracasar, porque eso es lo que esperan. Por el contrario, el éxito incierto parece extraño. Seguir este camino significa hacer cosas inusuales y potencialmente perjudiciales para tu carrera, mucho más que simplemente seguir las reglas.
Desde una perspectiva de la cadena de suministro, la lección aquí es que en el mundo del software, es de vital importancia no prepararte para el fracaso solo por seguir las reglas, especialmente cuando el libro es completamente falso. Por ejemplo, he visto empresas fracasar durante décadas utilizando métodos como el análisis ABC y los stocks de seguridad, métodos que pueden ser demostrablemente incorrectos y garantizar el fracaso de las iniciativas correspondientes. Estos métodos son incorrectos por razones matemáticas y estadísticas básicas, por lo que no debería sorprender que no logren agregar valor en la cadena de suministro. Sin embargo, se consideraron preferibles porque no parecían tan locos, siendo material de libro de texto.
Ten cuidado con la comodidad que se puede obtener al prepararte para el fracaso solo para eliminar la incertidumbre. Eliminar la incertidumbre no es el objetivo; el objetivo es maximizar la posibilidad de éxito, no reducir la incertidumbre.
En conclusión, la ingeniería de software es demasiado importante para dejarla solo en manos de ingenieros de software. El software está en todas partes en la cadena de suministro y está impulsando la mecanización del trabajo intelectual. Aún 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 la cadena de suministro, el desafío más grande es cultural. Este 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 estar equivocadas, espectacularmente equivocadas.
En cierto sentido, la ingeniería de software en la cadena de suministro se trata de domar el caos, de domar toda la complejidad e incertidumbre que se encuentra en todas partes en la cadena de suministro. Para domar este caos, que será el trabajo de los ingenieros de software, si el proceso en sí mismo está demasiado pulido u ordenado, si el proceso en sí mismo no tiene un elemento de caos en su núcleo, entonces no queda espacio para el cambio, la oportunidad o la creatividad. Lo que se percibe como excelencia rápidamente se convierte 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 abandonar la ilusión de control. Tu plan de migración de ERP de cinco años es una ilusión; no tienes control sobre un proyecto tan masivo. De manera similar, tu caso de negocio 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 puedas racionalizar completamente. El mayor peligro es hacer cosas que son completamente irracionales bajo la apariencia de la racionalidad.
Echemos un vistazo a la pregunta. La próxima conferencia se llevará a cabo el miércoles 15 de diciembre, a la misma hora, a las 3 p.m., hora de París, y tratará sobre ciberseguridad. Ahora, echaré un vistazo a la pregunta.
Pregunta: ¿Cómo mides el retorno capitalista de tus inversiones en software?
En su mayoría, no lo haces. La medición es el subproducto del propio emprendimiento. Es algo desconcertante si quieres medir el retorno de la inversión. Supone que puedes llegar a una medición de antemano, lo cual suele implicarse con este tipo de pregunta. Supone que puedes llegar a esta medición antes de construir tu caso de negocio con escenarios, y luego puedes tomar una decisión y seguir adelante 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 tienes que aprender, y luego, en el camino, incluso aprenderás qué tipo de beneficios hay. Para guiar tu acción, necesitas una comprensión a alto nivel. La lección no es hacer las cosas al azar, sino no hacer cosas que sean profundamente irracionales bajo la apariencia 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 pretenden ser racionales pero se basan en números basura. La realidad es que a medida que avanzas en tu emprendimiento de software, las mediciones se volverán más claras porque comenzarás a aprender sobre lo que estás tratando de lograr, y luego aprenderás cómo medir la adecuación de lo que estás haciendo con lo que deberías estar haciendo. La medición es algo que vendrá como un subproducto si lo haces bien. Sin embargo, como consecuencia de esto, significa que en lo que respecta al software, es mucho mejor simplemente probar cosas y fracasar rápidamente. No quieres comprometerte en un compromiso masivo; es mejor hacerlo de manera increíblemente incremental, 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 gestió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 gestión no espera tener tantas iniciativas que vayan en diferentes direcciones. Sin embargo, esto es exactamente lo que ya ha estado sucediendo en las grandes empresas de software durante décadas, y esta es una de las esencias de las lecciones aprendidas 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 con una tecnología en particular. Son dos problemas diferentes. Uno es el problema de tener una persona que tiene 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 viene con un conflicto de intereses latente muy fuerte. Mi mensaje es, por un lado, cuidado con esa política de identidad; son increíblemente tóxicas. Mi segundo mensaje es cuidado con los conflictos de intereses en todas sus formas; también son increíblemente tóxicos.
Ahora, si realmente enfatizas mucho una tecnología en particular, puedes eliminar algunas palabras clave para la tecnología que desapruebas en tu currículum. Sin embargo, por lo general, los dos problemas son separados, e incluso puedes tener a alguien que diga: “Mi identidad es que soy un programador de Python”, como mostré en una diapositiva, y luego en tu currículum, poner más de 20 palabras clave. Las dos cosas no son excluyentes; incluso pueden ocurrir simultáneamente. Además, no subestimes el hecho de que a veces la identidad puede estar asociada con algo aspiracional, algo que quieres adquirir. Puedes decir: “Hasta ahora, he estado programando en Python, pero quiero convertirme en un programador de Rust, así que me consideraré como un programador de Rust, aunque hasta ahora he hecho principalmente Python”. Todo tipo de comportamientos son posibles.
Pregunta: La ingeniería de software se considera una ciencia auxiliar para la 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 ingeniería de software. Si comienzas a abordarlo como la interacción de las personas, entonces estas ciencias auxiliares son cruciales. Para realizar un trabajo serio en ingeniería de software, no se trata únicamente de la tecnología del software, aunque necesitas comprender el contexto del software para que las interacciones entre las personas tengan sentido. No necesariamente necesitas entender lo que se incluye en el código, pero debes 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 establecer un límite, decidir qué incluir y qué no incluir, ya que obviamente no puedo cubrir todos los campos de investigación.
Pregunta: Pide a diez personas inteligentes una solución y encontrarán más de diez formas. Llegar a un acuerdo sobre una de las cinco mejores y usarla de manera consistente es mejor. ¿Cómo equilibras esos dos enfoques y beneficios contradictorios?
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 considerarse con igual peso. Existe una habilidad como 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 lo son. La experiencia entra en juego cuando quieres ver quién tiene las habilidades para esta visión a largo plazo y qué no cambia. En mi humilde experiencia, generalmente se necesita que alguien tenga al menos 35 años para comenzar a ser muy bueno en eso, y las personas más destacadas tienen más de 60 años. Se necesitan años de experiencia para ver el movimiento y los patrones.
Cuando dices que tienes tantas personas, una ilusión es que todas esas soluciones parecen buenas, pero eso es solo una apariencia. No sabes cuánto esfuerzo tomará probar las aguas. ¿Puedes simplemente hacer un prototipo o probarlo? Entre esas diez personas, ¿hay algunas con habilidades únicas para identificar soluciones que serán perjudiciales a largo plazo? Recuerda que los costos de mantenimiento están impulsados esencialmente por las decisiones que has tomado. ¿Hay una decisión importante que pueda perjudicarte a largo plazo?
Este es un aspecto complicado, y por cierto, alguien que tiene una visión a largo plazo puede explicar por qué una cierta opción, a largo plazo, va a generar todo tipo de problemas. No es solo una corazonada o intuición. Te dirán: “Este tipo de cosas, ya lo he visto. Lo he visto en otros productos”. Hay un dicho: el hombre inteligente aprende de sus propios errores, pero el hombre sabio aprende de los errores de los demás. Esto es muy aplicable a este caso.
Pregunta: ¿Cómo miden las empresas el aumento en la eficiencia operativa por cada dólar invertido en la implementación de software para las supply chains?
Esta es una pregunta increíblemente difícil. El problema es literalmente la incompatibilidad de paradigmas. Viene 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 medidas son simplemente irrelevantes. Veamos las ventas telefónicas versus el comercio electrónico, por ejemplo. Las empresas de venta por correo existían desde mediados del siglo XIX. Si comienzas a ver el comercio electrónico como una mejora sobre 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 se declararon en quiebra. Las empresas de comercio electrónico que dominan en la actualidad son varias órdenes de magnitud más grandes que la empresa de venta por correo más grande que haya existido. Amazon probablemente sea 100 veces más grande que la empresa de venta por correo más grande de la historia, y la comparación es muy confusa.
La mecanización del trabajo intelectual es tan increíblemente preocupante y desconcertante porque no es como el ámbito físico. Con la producción física, puedes medir la eficiencia de formas canónicas. Sin embargo, cuando comienzas a mecanizar tu trabajo intelectual, ¿qué significa incluso la eficiencia? Para una empresa como Amazon, toda su cadena de suministro está completamente impulsada por software. Si las personas simplemente se quedaran en casa y no hicieran nada, sospecho que toda la cadena de suministro funcionaría perfectamente, incluso si todos esos ingenieros no hicieran nada durante uno o dos días. Entonces, ¿por qué Amazon mantiene a esos ingenieros? Bueno, porque invierten en sus mejoras.
Por cierto, algo interesante sobre Jeff Bezos es su proceso de gestión llamado “discrepar pero comprometerse”. Él dice que hay proyectos en los que su instinto como CEO le dice que está equivocado, y está en desacuerdo con el proyecto. Sin embargo, se compromete a apoyar el proyecto en términos de presupuesto 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 debe ser la máxima autoridad en la empresa, pero renuncia a esta autoridad y dice: “Estoy en desacuerdo, pero puedes tener el presupuesto y seguir adelante”.
La razón de este enfoque es que los proyectos de software suelen ser bastante baratos. Si alguien propone una idea aparentemente loca que no es muy cara y no va a llevar a la quiebra a la empresa, ¿por qué no probarlo? Si funciona, podría ser una idea brillante. Esto representa un choque cultural al hacer la transición de las empresas tradicionales de la cadena de suministro, donde se supone que la dirección tiene la visión y dirige a los equipos. En el ámbito del software, el liderazgo se trata principalmente de 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 cambio, el enfoque se centra en si la inversión aborda un aspecto fundamental de la gestión de la cadena de suministro. Si es fundamental para una amplia variedad de situaciones de la cadena de suministro, entonces vale la pena perseguirlo.
Por ejemplo, en el mercado de accesorios automotrices, abordar el problema de la compatibilidad mecánica es de vital importancia. No estás vendiendo piezas de automóviles para servir a las personas; estás vendiendo piezas para servir a los automóviles. Una sola pieza puede ser compatible con varios vehículos, y algunas piezas pueden tener superposición mecánica. Este problema debe abordarse; es fundamental para el negocio. Si no lo abordas, alguien más lo hará y eventualmente te sacará 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 equipos de proyectos grandes son ridículos. En los sistemas ERP, un equipo de 10 personas puede ser bueno para el desarrollo, pero los proyectos más grandes requieren más personas. Se requieren más personas para construir una torre que para construir 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 tantas personas, obviamente, todas las personas que ganan la vida vendiendo equipos grandes o formando parte de un equipo así estarán en desacuerdo conmigo de manera vehemente.
Mi contraargumento es: ¿tu desacuerdo proviene de razones científicas fundamentales que expliquen por qué el trabajo no se puede hacer con menos personas, o está en tu propio interés financiero mantener el statu quo y tener un ejército de personas para hacer el trabajo? Si observamos toda la innovación que tuvo lugar, la destrucción creativa delineada por el economista Schumpeter, cada vez que hubo una innovación económica importante, generalmente hubo una mejora masiva de la productividad. Pero aquellos que estaban rezagados lucharon amargamente para evitar que estas innovaciones tuvieran lugar.
Los ERPs no son nada nuevo; han existido durante aproximadamente cuatro décadas. La mayoría de los ERPs que veo hoy en día no agregan mucho valor en comparación con los que las empresas tenían hace una o dos décadas. He visto muchos ERPs más antiguos que están bien, y los ERPs nuevos a menudo no son sustancialmente mejores, especialmente considerando los millones invertidos en proyectos de migración de ERP. En estos proyectos masivos, veo una productividad abismal por parte de las empresas de TI.
Mi contraargumento es mirar a empresas como JD.com, Amazon o Rakuten. ¿Cuántas personas necesitan estas empresas para realizar tareas similares? Por lo general, terminas con ratios insanos. Por ejemplo, Zalando, una gran empresa de comercio electrónico europea 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 para empresas de un tamaño similar que necesitan migrar su ERP. Así que ves, por un lado, tienes una empresa como Zalando, capaz de diseñar 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 un tamaño similar necesitan para simplemente hacer una actualización de versión. El costo es nuevamente solo una fracción. Cuestiono si es necesario tener 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 a ti mismo, de volverte obsoleto.
Esto es algo muy peculiar. Cuando los trabajadores de cuello azul estaban quedando obsoletos, lo hacían otros. Pero hoy en día, casi no quedan trabajadores de cuello azul. Requiere una mentalidad diferente, y por eso hay una lucha para adaptarse a este nuevo paradigma, que proviene principalmente de la industria del software. Está bien 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 enfrentar el próximo desafío, que es aún 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 promueven para enfrentar el siguiente problema, que es más difícil.
En respuesta a una pregunta sobre los profesionales de la cadena de suministro que se quedan atrapados en el pensamiento analítico de la posguerra, estoy de acuerdo en que para muchas empresas, no todas, la ingeniería de software ha avanzado. Se define a sí misma como un proceso de personas o un proceso interpretativo. Estoy de acuerdo. La industria del software no se trata solo de 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 a sí misma como teniendo un enfoque orientado a las personas, una cultura compartida.
En gran medida, creo que la dominancia que Estados Unidos y Silicon Valley tienen en 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.
Hay 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 está replicando en 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 muy importante: la ciberseguridad. ¡Hasta la próxima vez!
