En este post os acerco un libro que he leído recientemente titulado «Applied minds. How engineers think«. El texto gira alrededor del papel de las ciencias aplicadas en el desarrollo de la sociedad. El autor, Guru Madhavan, tiene un perfil interesante, porque combina una carrera científica con una ingenieril. Desarrolla su actividad profesional en el Departamento de Salud del Gobierno de Estados Unidos como asesor.
El título ya de por sí me llamó la atención, por lo explícito que es, vinculando una manera de entender la vida, la de ser una persona que busca la aplicación de las cosas, con una disciplina como la ingeniería. Me pregunto si los estudios que uno hace acaban estructurando nuestra manera de razonar o es más bien al revés. El libro se centra en la primera opción: estudiar una ingeniería conlleva una manera de razonar determinada.
No esperes encontrar en el libro una explicación profunda y razonada sobre la manera de pensar de un ingeniero. Más bien es una recopilación de historias a través de las cuales el autor va mostrando cuáles son las 7 principales características del pensamiento ingenieril. Es un recurso muy utilizado en libros de carácter divulgativo, aunque a mi entender, en este caso hace un uso excesivo de estas historias. La mayoría conectan bien con el tema pero otras son difícilmente relacionables con lo que trata de explicar. Echo en falta un capítulo en el que hubiese intentado relacionar todas estas características del pensamiento ingenieril que salpican las diferentes historias que presenta. De hecho no hay ni un solo diagrama a lo largo del texto. Esto último es importante, porque es muchas veces en esas imágenes donde se puede observar la capacidad de abstracción del autor sobre el tema que está tratando.
A lo largo del texto parece enfrentar la ciencia básica con la ciencia aplicada, con una clara inclinación hacia la ciencia aplicada. Diferencia ciencia de ingeniería especificando el enfoque de cada una, siendo el objetivo de la ciencia el descubrimiento y el de la ingeniería la creación. Esto es una tendencia hoy día, muchas veces con la intención de denostar la ciencia básica, pero no hay que olvidar que muchas veces son dos caras de la misma moneda. Para tener ciencia aplicada necesitamos tener ciencia básica, y alguien tiene que hacer la ciencia básica y financiarla. Si no que se lo digan al Profesor Francisco Mojica de la Universidad de Alicante que descubrió las bases de uno de los métodos más utilizados para hacer modificaciones genéticas. Tampoco olvidemos que los tres tipos de escáner más avanzados de la medicina moderna (PET, TAC y RMN) provienen de descubrimientos de 3 premios Nóbel que nunca pudieron imaginarse que lo que habían descubierto tendría esa aplicación futura.
Me gusta el hecho de que pone de manifiesto el valor de la formación en humanidades como complemento a cualquier formación ingenieril. Como dice un amigo mío, «yo soy ingeniero, pero de letras».
Knowledge for the sake of knowledge has its role, but practical reality shapes social progress (Página 15)
Otro tema interesante que apunta el autor es que la ingeniería no debe confundirse con la aplicación tecnológica. No se trata de reemplazar el trabajo de las personas por el de las máquinas ni de ser expertos en una determinada tecnología. La tecnología es una herramienta para la ingeniería pero la ingeniería es estrategia, resuelve problemas prácticos más que tecnológicos. En esta línea presenta una visión muy interesante sobre el «ingeniero de sistemas», también conocido como «Ingeniero de Organización» frente a los expertos en tecnología.
For an aerodynamics expert, it may become an issue of the airplane needing to flyfaster, for a systems engineer the approach is different
La cita es muy interesante, porque la visión del sistema muchas veces aporta más que la visión de una pequeña parte del sistema: el tiempo de desplazamiento de Paris a San Francisco no depende sólo del tiempo de vuelo desde el despegue hasta el aterrizaje. Las mayores eficiencias se pueden sacar de otros sitios: checkin, control de seguridad, desplazamientos en el aeropuerto, tiempos de espera, sincronización de las conexiones…
Es fundamental tener en cuenta la escala del problema, porque determina de manera radical el enfoque de la solución y su aplicabilidad: una solución que funcione bien a pequeña escala no tiene porqué funcionar igual de bien a mayor escala.
El ingeniero hace uso de mucha información para resolver los problemas, pero hay que tener en cuenta que la relevancia de la información tiene una ventana temporal muy reducida. Hay que utilizarla en el momento adecuado para que realmente sea útil. Pasado ese momento no podremos hacer gran cosa con ella.
Una parte que me gustaría resaltar es la referencia que hace a George Heilmer, antiguo director del famoso DARPA (U.S. Defense Advanced Research Projects Agency), quien tenía un checklist para definir bien los proyectos y que recuerda a cualquier formulario de proyectos de innovación que podamos pedir hoy día a, por ejemplo, el programa Horizon 2020 de la UE:
- ¿Qué pretendes hacer? Explícalo sin utilizar ningún tipo de jerga especial, de tal manera que lo pueda entender cualquiera
- ¿Cómo se está haciendo en la actualidad y con qué limitaciones nos encontramos?
- ¿Qué tiene de novedoso tu proyecto y por qué piensas que será exitoso?
- ¿A quién le afecta lo que tú vayas a hacer y cómo influirá en sus vidas?
- ¿Cuáles son los riesgos con los que te vas a enfrentar?
- ¿Cuánto va a costar en tiempo y dinero?
- ¿De qué manera vas a comprobar que el proyecto evoluciona correctamente?
Otra cuestión que saca en el libro son las similitudes entre la economía y la ingeniería. De hecho justifica porqué el perfil del ingeniero se adapta muy bien al mundo económico.
Os adelanto aquí algunas de las s características del pensamiento ingenieril que presenta el libro:
- Búsqueda de la alta eficiencia, la uniformidad y la versatilidad:
- La mejora de la eficiencia se basa en preguntarse 7 veces el porqué de la causa de un problema
- Se busca la maximización de la utilidad
- Adaptar, mejorar y aplicar
- Pensamiento sistemático y modular: la clave está en identificar los vínculos y clasificarlos en fuertes y débiles con un refinamiento sucesivo de las soluciones que se van obteniendo
- El pensamiento modular varía con el contexto, con lo que no hay una manera única de resolver los problemas, aunque sí parece definirse un procedimiento
- Capacidad de ver una estructura en algo que aparentemente no lo tiene: esto deriva en la creación de modelos que se aproximan a la realidad y permiten resolver los problemas de manera estructurada
- Adaptación y diseño bajo restricciones: Los plazos y las restricciones no desincentivan la innovación, la dirigen hacia nuevas posibilidades
- Los ingenieros suelen interpretar de forma laxa los métodos científicos para obtener los resultados
- Optimización en base a modelos:
- Los modelos deben apoyar la optimización para poder discutir de manera estructurada sobre las restricciones
- Los estándares son a los productos como la gramática al lenguaje
- En lugar de debatir durante días sobre la mejor manera de hacer algo, es mejor ponerse manos a la obra e ir mejorando la solución con la práctica
- Backward design: la capacidad de imaginarse el resultado esperado y trabajar de modo inverso hasta alcanzarlo
- Pensamiento orientado a objetivos
- Prototipado
- Es necesario considerar todas las fuentes de incertidumbre para minimizarlas
Además descubres algunas curiosidades, como por ejemplo:
- El origen de los códigos postales y el significado del acrónimo ZIP: Zone Improvement Program
- Un avión de Boeing volando de Londres a Nueva York genera alrededor de 10 Tb de datos cada 30 minutos: la verdad es que me parece una cantidad descomunal de datos
- El río Ganges nace en la cordillera del Himalaya y en sus 1.500 millas de recorrido proporciona agua al 40% de la población de India
En resumen, es un libro agradable de leer, con un estilo muy divulgativo y que ayudará al ingeniero a entender su forma de pensar y al no ingeniero a entender mejor a los ingenieros. Un buen libro para aproximar posturas.
