Creación y compra de software excelente para la fabricación de metales

scanrail/iStock/Getty Images Plus

El software es cada vez más relevante y fundamental para las fábricas modernas. Ya sea que esté desarrollando código internamente o comprando una herramienta de terceros, es importante comprender lo que está buscando. Esto puede resultar difícil sin tener un conocimiento profundo de cómo se crea el software.

Healthcare.gov representa un estudio de caso de fácil acceso sobre los riesgos del diseño de software. Se lanzó hace 10 años e inmediatamente aterrizó con un ruido sordo. Fue tan lento y con fallas que tan solo el 1% de las personas interesadas pudieron inscribirse en la primera semana. El diseño web no cumplió con los conceptos básicos absolutos, con flujos de trabajo deficientes e interfaces de usuario con fallas. Para colmo, el sitio proporcionó a los proveedores de seguros médicos información inexacta, lo que dificultó o incluso imposibilitó el manejo correcto de las inscripciones.

Las pruebas de estrés que deberían haber explorado el volumen de usuarios esperado fueron totalmente inadecuadas. Un día antes del lanzamiento, se descubrió que el sitio se volvía demasiado lento con solo 1100 usuarios simultáneos. El número de usuarios esperado era de 50.000 a 60.000. Si eso no fuera suficientemente malo, el número real de usuarios simultáneos se disparó a 250.000 en la primera semana, más de 200 veces el número de usuarios que las pruebas de estrés previas al lanzamiento indicaron que el sitio podía manejar. En retrospectiva, uno se pregunta por qué se realizaron las pruebas de estrés. Su claro fracaso no hizo nada para cambiar el cronograma de lanzamiento.

El proyecto no fracasó por falta de presupuesto. Originalmente se estimó que costaría 93,7 millones de dólares, una suma asombrosa incluso si el proyecto no excediera el presupuesto. Pero las estimaciones eran tremendamente incorrectas. Antes de su finalización, el coste total ascendió a la asombrosa cifra de 1.700 millones de dólares, casi 20 veces más de lo estimado.

Healthcare.gov funciona muy bien en 2023, pero en su lanzamiento fue quizás el fiasco de software público más espectacular, caro y de la historia. Si bien gran parte de la complejidad que rodeó el lanzamiento de Healthcare.gov fue inevitable, podemos utilizar su lanzamiento fallido para explorar qué hace que los proyectos de software tengan éxito o fracasen. Sus fallos podrían proporcionar información sobre cómo construir su propio equipo de software interno. También podría proporcionar información sobre qué buscar al comprar software de terceros.

En un artículo anterior, escribí sobre cómo Southwest Airlines se vino abajo durante las vacaciones de 2022. En pocas palabras, la compañía se basó en un software con décadas de antigüedad que hacía extremadamente difícil manejar las interrupciones en la programación. Los trabajadores entendieron el problema, pero los ejecutivos de la empresa, aislados del dolor operativo diario, durante décadas no invirtieron en nueva infraestructura. Ese fallo, combinado con una tormenta invernal y una alta demanda estacional, provocó que toda la empresa se paralizara, dejando varadas a decenas de miles de personas la semana de Navidad. La propia Southwest estima que el desastre finalmente le costará a la compañía casi mil millones de dólares. Ese gasto extraordinario podría haberse evitado si quienes tomaban las decisiones estuvieran lo suficientemente cerca de los problemas operativos como para comprender la urgencia.

La lección es que el buen software lo desarrollan equipos cercanos. Una buena proximidad implica dos cosas: primero, que el equipo de software esté íntimamente familiarizado con el problema que intenta resolver; en segundo lugar, los desarrolladores están cerca de los resultados producidos por su software. Dicho de otra manera, un equipo con buena proximidad comprende el problema y luego utiliza su propia herramienta de software para aliviarlo. Si el software no da en el blanco, tiene fallos o es difícil de usar, los desarrolladores deberían ser los primeros en descubrirlo.

Ésta es un área en la que el proyecto Healthcare.gov ciertamente fracasó. Es posible que los desarrolladores hayan comprendido los problemas para los que fue diseñado su sitio web, pero el contratista principal operaba desde Canadá, no desde Estados Unidos, el país al que presta servicios Healthcare.gov. También se entregaron diferentes componentes del sistema completo a muchos subcontratistas, ninguno de los cuales habría sido propietario de la aplicación completa. Incluso si los desarrolladores entendieran el problema que el software pretendía resolver, la experiencia del usuario de un extremo a otro habría estado firmemente fuera del control de cualquier desarrollador de software individual.

Un contratista, por ejemplo, se ocupaba exclusivamente de los sistemas de autenticación. Si el registro y la autenticación eran lentos o no funcionaban (y lo eran), ¿de quién era la culpa? ¿Los diseñadores de experiencia de usuario? ¿La base de datos? ¿Los ingenieros que manejan la infraestructura del servidor? ¿Los desarrolladores de aplicaciones web? ¿O todos juntos? Cada subgrupo podría haber estado dentro de una empresa diferente. Descubrir el problema central, comunicarlo y poner una solución en producción habría sido difícil incluso si el problema se hubiera entendido bien.

Nada de esto debería sorprender a un fabricante. La proximidad es sólo otra forma de decir: ve al gemba. En cierto modo, el desarrollo de software no es tan diferente de la mejora continua en la fabricación.

Imagine que le han encomendado la tarea de construir una nueva línea de fabricación desde cero, utilizando equipos nuevos, en una industria vertical a la que su empresa nunca antes había prestado servicios. Tienes un presupuesto enorme, por lo que deberías poder hacerlo funcionar. Pero hay una advertencia importante: solo puedes intentarlo una vez para que todo sea perfecto. Desde el inicio se debe seleccionar el equipo, el diseño de la fábrica y el número de personas; cómo es su entrenamiento y cómo serán entrenados; y cuánto trabajo en proceso y productos terminados tener a mano. Una vez que terminas de planificar, estás encerrado. No puedes cambiar el diseño.

Qué proyecto sería ese. No sólo es imposible predecir de antemano los problemas e ineficiencias de una nueva industria, sino que todo el proceso de diseño (todo por adelantado, sin cambios) va en contra del ciclo de planificar, hacer, verificar y actuar (PDCA) que siguen los fabricantes. He aprendido a aplicar continuamente. No tendría sentido abordar la fabricación de esa manera.

Tampoco tiene sentido para el software, pero así es precisamente como se desarrolló Healthcare.gov. Todo el sistema fue diseñado de antemano, por comité, en un proceso que llevó meses. Luego se crearon diagramas de Gantt meticulosamente elaborados, que mostraban cuánto tiempo llevaría desarrollar cada elemento, lo que culminaría en última instancia con las pruebas finales y el lanzamiento. Pero como cualquier fabricante podría adivinar, los cronogramas son imposibles de predecir y aún más imposibles de seguir.

En la fabricación, el proceso de mejora continua suele estar guiado por el ciclo PDCA. Planificamos un cambio de producción, que está diseñado como un experimento; luego lo hacemos, implementando el cambio para realizar el experimento. Pero no nos detenemos ahí. Una vez realizado un cambio, verificamos el resultado para asegurarnos de que tuvo el efecto deseado. Finalmente, actuamos sobre esa información, ajustando los planes en función de lo aprendido.

Este proceso es iterativo y debe aplicarse de forma continua y consistente. Esto no podría ser más diferente que un proceso de desarrollo de software en cascada, donde todo el proyecto se diseña por adelantado en un documento de especificaciones de cientos de páginas. En cambio, PDCA requeriría cambios de software relativamente pequeños, realizados rápidamente y luego implementados y probados completamente antes de pasar al siguiente paso. Healthcare.gov no se probó de principio a fin hasta días antes de su lanzamiento, momento en el que era imposible realizar cambios antes del lanzamiento.

Dos de las creaciones de software más impactantes del mundo, Git y Linux, fueron creadas originalmente por un brillante desarrollador: Linus Torvalds. Git es un sistema de control de versiones muy utilizado por prácticamente todos los equipos de software, y Linux es un sistema operativo de computadora. Es muy probable que la mayor parte del software que utiliza se haya desarrollado con la ayuda de Git. Y si posee algún equipo CNC moderno, es probable que funcione con Linux en su interior.

Después de que Torvalds puso las cosas en marcha, muchos otros contribuyeron (y continúan contribuyendo) a ambas herramientas. Aun así, me resulta convincente que un visionario brillante pueda tener un impacto tan grande. Torvalds entendió la necesidad, imaginó la solución y la hizo realidad.

Es natural que cuantas más partes interesadas haya y mayor sea la complejidad del software, más difícil será diseñar un sistema que resuelva perfectamente un problema. Nuevamente, considere Healthcare.gov. Desde cualquier punto de vista, el proyecto era increíblemente complicado. Se estima que en él trabajaron al menos 47 contratistas privados diferentes. El hecho de que 47 sea una estimación es revelador: ¡nadie sabe siquiera cuántas empresas ayudaron a redactar el sistema! Las empresas que trabajaron en ello han sido acusadas de grave incompetencia y corrupción. Y el esfuerzo general fue coordinado por un departamento gubernamental sin experiencia en desarrollo de software, por no hablar de un proyecto de este tamaño.

Compare esto con el desarrollo de Linux y Git por parte de Torvalds. No podrían ser más diferentes. En un extremo del espectro, tenemos a un tipo brillante con una visión que resuelve un problema claro, con un costo funcionalmente nulo. En el otro extremo, tenemos software diseñado por un comité, que involucra a miles de partes interesadas, con un presupuesto aparentemente ilimitado, implementado por al menos 47 empresas que emplean colectivamente a cientos de personas, y todo administrado por una organización gubernamental sin experiencia en desarrollo de software.

Para ser justos, escribir la esencia de Linux fue un tipo de proyecto muy diferente. Linux no es simple, pero es complicado de una manera más cuantificable que lo que debió ser el proyecto de pastoreo de gatos Healthcare.gov. No envidio a los gerentes e ingenieros que tuvieron que hacerlo funcionar.

La lección es que es más probable que un proyecto tenga un éxito brillante si puede ser implementado por un pequeño equipo de personas inteligentes y enfocadas que comprendan el problema en profundidad, tengan una visión clara de la solución y puedan iterar rápidamente. Si su empresa desarrolla software internamente, esta lección puede y debe aplicarse a sus propios equipos de desarrollo. Pero el desarrollo de software interno es un compromiso importante y que tal vez no siempre tenga sentido.

Para quienes compran software, puede que no sea tan obvio cómo se desarrolló el software. Pero hay señales. Los proveedores de software que prestan servicios específicamente a su industria vertical (es decir, fabricantes de metales) probablemente tengan más probabilidades de tener una solución que se ajuste a sus necesidades, porque pueden limitar el alcance y mantener una buena proximidad. En igualdad de condiciones, el software probablemente no será tan adecuado si fue diseñado para servir a decenas de miles de empresas en todas las industrias.

También puede explorar la frecuencia con la que se publican las actualizaciones de software y cómo los desarrolladores reciben y actúan en función de los comentarios de los usuarios. La forma en que un equipo de software se conecta con los clientes puede tener un gran impacto en el valor del software para su negocio.

Ya sea que cree o compre, el software es una parte indispensable de la fábrica moderna. Permite una eficiencia increíble y una mejor calidad de vida. Pero el pasado está plagado de desastres de software incomprensiblemente costosos como Healthcare.gov. Navegar por esa realidad puede ser complicado, pero comenzará un paso adelante si prefiere el software diseñado para fabricantes, por fabricantes, con equipos relativamente pequeños que realicen cambios rápidamente y los prueben personalmente.