Este post es el segundo en el que me sumerjo en el estudio del Extreme Manufacturing, aquí hice un miniresumen del Scrum, metodología para la gestión de equipos de trabajo.

v3familyEl Extreme Manufacturing (XM) es la metodología de trabajo usada por la OSE y Wikispeed para desarrollar sus prototipos. Básicamente consigue reducir los tiempos de desarrollo de productos hasta 15 veces, bajar los costes de producción y prototipado mucho (no tengo el dato y no sé si existe), en definitiva, aumenta la capacidad de innovación a tope. En palabras de Joe Justice (Wikispeed) el XM reúne “las mejores prácticas de la gestión distribuida de equipos, la ingeniería frugal y el diseño frugal y los aplica de vuelta al mundo físico”.

Navegando por la wiki de OSE, he llegado al concepto Contract-First Manufacturing (CFM) que, para mí, es vital para el diseño frugal. El CFM viene a destacar la importancia de la interfaz. Personalmente me alegra este descubrimiento porque intuitivamente llevaba tiempo estudiando cosas de diseño de interfaz, sin encontrar el porqué de esa intuición, además creo que, de alguna manera, hará que las técnicas de estudio de la etnografía pero no necesariamente de humanos (“Nunca hemos sido humanos” dice Haraway y qué guay que todo se combine tan magníficamente aunque aún no sea evidente ni para mí: en la oficina yo hablando de las rutinas de arrsa y de la gobernanza de los comunes, Helena recordando su post de los pellets en mimbrea y “Andy” escribiendo sobre las interfaces entre módulos de máquinas, y en el fondo el mismo problema). Bueno, me dejo de desvaríos y voy al meollo.

El CFM viene a decir que se establecen “contratos” entre los módulos de las máquinas y una vez establecidos no pueden cambiarse para el desarrollo distribuido y prototipado rápido de los módulos. Joe Justice suele usar el ejemplo de los modelos de coches. Éstos tardan una media de 15 años en rediseñarse lo que significa que un nuevo Porsche estará satifasciendo las necesidades establecidas en 1998, ¿por qué?. Porque todos los módulos son dependientes unos de otros y cada cambio en un componente modifica el conjunto de componentes del modelo.

En cambio, en el prototipado rápido (o agile development), y más aún combinado con el Scrum, se pretende que cada módulo pueda desarrollarse por separado y mejorarse con independencia del resto. Esto es lo que permite el CFM. Traduzco unas líneas de la wiki de OSE que lo explican muy bien:

La idea detrás del CFM (cdd en el texto concreto) es identificar los trabajos que cada modulo hace y cómo los modulos se relacionan entre ellos sin identificar cómo consiguen sus objetivos. (…) ¿Por qué esto es importante? Significa que cualquier módulo que consiga esos objetivos con esa interfaz puede ser usado en la máquina. (…) Una idea clave en el [CFM] es la ‘separación de asuntos’ (concerns). Esto significa que un módulo no debe preocuparse sobre cómo otro módulo hace su trabajo. El Poer Cube es un gran ejemplo de esta idea puesta en práctica. Cualquier sistema que usa un Power Cube no debe de preocuparse de dónde viene la energía. Sólo asume que la energía hidráulica entrará según se necesite. Esto significa que podemos cambiar muchos aspectos del Power Cube de forma fácil y segura. Podemos cambiarla a vapor. Podemos añadir un motor mayor, añadir encendido eléctrico y monitorización. ¿Qué no podemos cambiar? ¡No podemos cambiar la interfaz! (…) Y qué es la interfaz (…) Tiene un determinado tamaño (sobre 2’x2’x2′). Cambiar el tamaño va contra las reglas de la interfaz (el contrato). (…) Hay muchas cosas que no puedes cambiar pero tienes un montón de oportunidades para mejorar y cambiar el Power Cube sin tener que cambiar cualquier otra parte de cuaquier máquina de GVCS. (…) El GVCS no tiene tiempo para eso (la reingeniería que se hace en los coches y los hace tan caros) Tenemos un contrato entre el sistema energético y la máquina que lo conduce. Si haces otra máquina que respete el contrato, simplemente funcionará.

Con esto claro, podemos pensar en el diseño de cada módulo. ¿Qué necesita para funcionar y qué aporta? Lo que necesita para funcionar y cómo pensamos que va a aportarlo es lo que determinará su interfaz. Esto es lo que hay que diseñar muy bien desde el principio. Una vez establecidos esos límites podremos establecer un primer prototipo y dar la “Definición de Listo”.

Pero, ¿cómo separamos los módulos? Es decir cómo establecemos los límites entre uno y otro módulo. Cuestión importante. En el Agile Development tienen una respuesta que me encanta: las Cartacterísticas Mínimas Comercializables (Minimun Market Features, MMF). En el hardware hablaremos de Componentes. Se trata de separar en los mínimos componentes que podrías vender o enviar un mail a un cliente contándole las mejoras. Sólo cuando estás desarrollando sabes si algo se puede cortar o no y en el proceso aparecerán “descendencias” entre componentes. Dónde cortar y cuándo se convierte en un arte.

Y, ¿cómo mejorar o medir los componentes? Aquí es donde entra la idea de rendimiento o desempeño, pero otra vez la interfaz tiene mucho que decir. ¿Cuánto puedo mejorar el componente para que desarrolle mejor su función sin cambiar su interfaz? Nunca hay que olvidar el contrato si se quiere trabajar en un equipo distribuido.

Tanto importa la interfaz que algunos proyectos se dedican sólo a ella. Hablamos de interfaces que permiten la interoperabilidad y ya han aparecido en esta blog, para juntar piezas, para relacionarse entre comunidades, etc. Son una buena alternativa al universalismo… Pero no me quiero poner abstracta. Mientras vamos aplicando todo esto al desarrollo del Sistema Dinamo, os dejo con un vídeo que siempre me fascinó:

3 comments on “Extreme Manufacturing II. Contract-First Manufacturing o La importancia de la interfaz

  • ¡Me encantó el post!
    Con la referencia a OSE y a la peli y todo…

    En el desarrollo de dispositivos para el Sistema Dinamo comenzamos a desarrollar prototipos. La interfaz entre ellos vendrá después o se piensa simultáneamente.
    Pero me fascina pensar en las interfaces entre los distintos dispositivos: ¿cómo ensamblar un MuroTrombeAdobe1.0 con un RadiadorSolar2.1? Y como éste, otros muchos ejemplos. Porque, claro, existen o existirán unos puntos de unión que hacen que la combinación de sistemas suponga una captación de recursos más intensa.

    También hablamos un poco sobre lo que nos permite el CFM: centrarnos en la evolución de cada versión dejando estable la conexión entre ellas, pudiendo así mejorar un prototipo sabiendo que siempre se puede conectar con otros, hasta que los saltos cualitativos sean tan importantes que haya que cambiar la versión de interfaz entre módulos (pero eso ya serían otros dispositivos, con otras interfaces, creo).

    Esto podría aparecer como una cualidad del prototipo: la interfaz y con qué otros prototipos es compatible. Me lo apunto para la wiki.

    Y después de unos buenos conceptos repartidos aquí y allá seguimos con la fase beta de la calefacción…

    ¡Enhorabuena!

Leave a Reply

Your email address will not be published. Required fields are marked *