Hay una idea generalizada que las empresas de tecnología operan moviéndose rápido, “rompiendo cosas” para luego arreglarlas y seguir avanzando rápidamente. Esta idea la comentó Mark Zuckerberg en algún momento: “Move fast and break things. Unless you are breaking stuff, you are not moving fast enough”
En un principio, esto puede sonar como una idea de grandes emprendedores, arriesgados, tal vez, hasta “románticos”.
Sin embargo, yo no puedo estar totalmente de acuerdo con esta idea o filosofía. No. De hecho, el mismo Mark tiempo después reconoció que eso de romper cosas y moverse rápido no aplicaba del todo bien y cambió su dicho a “Moverse rápido con una infraestructura estable”.
No todas las aplicaciones y sistemas son igual de relevantes
Y es que una cosa es que apliques estas ideas a una aplicación de filtros para mejorar tus fotografías, por darte un ejemplo, y otra cosa muy distinta es que sigas esta idea para un sistema de manejo de inventarios de la farmacia de un hospital, por poner otro ejemplo.
En el primer caso, si la aplicación de filtros para fotografías falla, no hay consecuencias mayores. Pero, si el sistema de inventarios de suministro en un hospital falla, puede haber consecuencias mortales y, difícilmente se podrá justificar que esto sucedió porque sus desarrolladores tenían la filosofía de moverse rápido y romper cosas.
De aquí que, sin duda, un factor a considerar con esta idea de “moverse rápido y romper cosas” no puede considerarse que aplica para todos los casos, esto es, en la medida de la relevancia o impacto a la sociedad de una aplicación o servicio, es en la medida en la que no puede “moverse rápido algo y romper cosas”.
Consecuencias de irrelevantes a mortales
Otro aspecto similar sería que esta filosofía se aplicara al desarrollo de la tecnología de agentes. ¿Te imaginas que por “moverse rápido” un agente al que le confiaste hacer una compra tuviera un error y gastara en algo que no pudiera devolverse, muy caro y que no te sirviera?
Esta filosofía es parte del tema de desarrollo de sistemas denominado como deuda tecnológica donde en principio, se desarrolla muy rápido pero luego se pagan las consecuencias en lo relacionado con la usabilidad, el soporte y/o mantenimiento de ese desarrollo y los problemas de integración o compartir información que se complican a futuro por simplemente no haberse diseñado sistémicamente bien. Dicho en otras palabras, le hemos puesto mucho énfasis a la reducción de tiempo que ha motivado el uso de la inteligencia artificial y nos vamos con la idea de que, si antes se tardaba en tener un desarrollo 30 días y ahora una persona sin experiencia en desarrollo de sistemas tarda tres días, aparentemente eso se identifica con hiper productividad, pero el desarrollo no lo es todo:
- ¿El sistema es seguro o será una puerta para maleantes a la empresa?
- ¿Se resolvió la interoperabilidad con otros sistemas y/o aplicaciones?
- ¿Está documentado el desarrollo o es una “caja negra”?
- ¿Se puede actualizar y medir el impacto sistémico con otros servicios o aplicaciones?
- ¿Quién va a responder en caso de correcciones o errores?
Estas son solo algunas preguntas que personas sin disciplina de ingeniería de sistemas ni siquiera piensa.
Tecnología accesible a personas no expertas
Lo peor es que veo que casi todo lo nuevo que se está diseñando está permitiéndole a las personas comunes y corrientes, sin conocimiento de teoría de sistemas, de ingeniería de desarrollo de software, de soporte técnico, en fin, de diferentes disciplinas que son los que precisamente velan por que un sistema tenga un costo de propiedad o TCO que baje con el tiempo en vez de que a mayor tiempo de usarlo los costos de operación suban y suban sean sustituidos por herramientas de desarrollo muy rápidas que provoquen problemas gravísimos de operación y eficiencia en el mediano plazo. Dicho en otras palabras, que alguien pueda construir una aplicación no significa que comprenda las consecuencias de ponerla en operación.
Y si hablamos del impacto de esto en inteligencia artificial agéntica, ya no estamos hablando solamente de una falla informática. Estamos hablando de decisiones ejecutadas con consecuencias financieras, comerciales o legales.
Veo entonces que habrá cada vez más problemas en los negocios, más fallas, menos integración, menos colaboración por no hacer las cosas no tan rápido, pero bien hechas.
Ante un problema ¿quién es responsable?
Por último, cuando una empresa decide moverse rápido y romper cosas, ¿quién asume el costo de lo que se rompe?
Pensemos en tres escenarios:
- Una empresa tecnológica lanza un producto defectuoso y sus clientes pierden información.
- Un directivo impulsa una automatización que reduce los costos de su departamento, pero multiplica los errores en otra área.
- Un proveedor entrega rápidamente una solución, cobra por ella y deja al cliente los costos de mantenimiento y corrección.
En los tres casos puede existir un incentivo perverso: quien obtiene el beneficio de la velocidad no necesariamente es quien absorbe el costo del error.
Mi conclusión es que, no es lo mismo experimentar con algo que puedes deshacer que experimentar con algo cuyas consecuencias no puedes revertir. Seguir apostando a que una filosofía empresarial se adopte sin pensar, puede tener consecuencias mortales para una gran cantidad de negocios, por lo que en vez de “moverse rápido y romper cosas” yo diría, “piensa y luego muévete”.
