¿Sus ingenieros hablan entre sí cuando deberían?

Todas las empresas que diseñan productos complejos y de alta ingeniería tienen sus historias de terror. Ford y Bridgestone Firestone perdieron miles de millones de dólares al no coordinar el diseño del vehículo del Ford Explorer con el diseño de sus neumáticos. Del mismo modo, el desarrollo del «superjumbo» del A380 por parte de Airbus sufrió importantes retrasos y sobrecostes debido a las incompatibilidades emergentes tardías en el diseño de los arneses eléctricos de varias secciones del fuselaje del avión. Estos errores probablemente contribuyeron a la pérdida del CEO de Airbus y a cambios importantes en la gestión del programa del A380. Lo que llama la atención de estas historias y de muchas otras similares es que, en prácticamente todos los casos, todas las personas implicadas estuvieron de acuerdo, en retrospectiva, en que podrían haber evitado sus costosos errores si se hubieran asegurado de que los diferentes equipos responsables del desarrollo de los componentes de los productos se habían comunicado de manera más eficaz. Por supuesto, con los proyectos de desarrollo complejos, nunca puede estar seguro de haber planificado todos los imprevistos. Sin embargo, nuestra experiencia demuestra que, en la fase de diseño de este tipo de proyectos, muchas empresas se beneficiarían si se centraran claramente en los puntos de contacto críticos entre sus distintos equipos de desarrollo de componentes para garantizar que todos sepan cuándo y con quién deben compartir la información. Este artículo ayuda a los gerentes a mitigar este problema de comunicación en el diseño. Basándonos en una investigación detallada sobre cómo Pratt & Whitney gestionó el desarrollo de su motor a reacción comercial de mayor empuje, el PW4098, que impulsa el Boeing 777, presentamos una nueva aplicación de una herramienta de gestión de proyectos establecida: la matriz de estructura de diseño (DSM). Nuestra aplicación ayuda a los directores a identificar dónde pueden producirse fallos en las comunicaciones planificadas y a reconocer cuándo los equipos del proyecto intervienen en comunicaciones técnicas no planificadas. También analizamos las comunicaciones entre los equipos del proyecto que tienen lugar tanto dentro como fuera de la estructura formal del proyecto. Concluimos hablando de cómo los gerentes deben gestionar los problemas de comunicación que se revelan en el proceso. Si bien no pretendemos ofrecer una solución definitiva al problema del diseño y la comunicación, sí creemos que los gerentes que utilizan nuestras herramientas en las próximas generaciones de productos mejorarán la calidad de sus procesos de desarrollo. Detectar las interfaces perdidas antes de que se produzcan Lo primero que hace un equipo de proyecto cuando se enfrenta a un desafío de desarrollo complejo es dividir el proyecto en partes manejables que luego se asignan a subequipos dedicados. En el contexto del desarrollo de un producto como un motor a reacción, esto se traduce en un gran número de equipos interfuncionales especializados, cada uno de los cuales trabaja en un componente o subsistema diferente del motor. Por supuesto, estos equipos no pueden trabajar de forma aislada; además de diseñar los componentes que se les asignan, también deben integrar sus diseños con los de los demás componentes para garantizar que todo el producto o sistema funciona como un todo. Por lo tanto, al planificar un proceso complejo de desarrollo de productos es fundamental que los directores del proyecto especifiquen qué recursos e información necesitarán los diferentes equipos unos de otros en determinadas etapas del proyecto. En el proyecto de desarrollo de motores a reacción de Pratt & Whitney que estudiamos, el motor se dividió en ocho subsistemas, cada uno de los cuales se descompuso aún más en cinco o diez componentes, lo que hace un total de 54 componentes del motor. Como es habitual en estos proyectos, la organización de desarrollo se estructuraba en consecuencia en 54 equipos de diseño interfuncionales responsables de cada componente, además de seis equipos de integración responsables de gestionar los requisitos a nivel del motor en áreas como la eficiencia del combustible. Estos equipos tenían que interactuar mucho: había varios cientos de interfaces entre los componentes del motor, muchas de las cuales habrían tenido problemas importantes sin una comunicación adecuada entre los equipos de diseño pertinentes. Para ayudar a gestionar el aspecto comunicativo de estos proyectos, proponemos el siguiente enfoque: (a) identificar interfaces desatendidas, áreas en las que la comunicación debería producirse pero no lo es, y (b) busque interfaces no identificadas, áreas en las que la comunicación se produce pero no se ha planificado. El resultado de la implementación de este enfoque es lo que llamamos un matriz de alineación, que revela desajustes entre las comunicaciones e intercambios que se supone que tienen lugar y las que realmente se producen. Por lo tanto, también demuestra lo bien que se ha planificado y ejecutado el proyecto. Para ver cómo funciona el enfoque, supongamos que tenemos previsto desarrollar un producto con cuatro componentes, cada uno de los cuales requiere su propio equipo de diseño especializado. (Este enfoque se puede utilizar cuando la estructura organizativa depende directamente de la arquitectura del producto, es decir, el componente X lo diseña el equipo X, como ocurre en la mayoría de los complejos proyectos de desarrollo de las empresas automotrices y aeroespaciales que hemos estudiado. Para los casos en los que las estructuras organizativas y de productos no se mapean directamente, consulte «Alinear las arquitecturas de procesos, productos y organizaciones en el desarrollo de software», de M.E. Sosa, en Actas de la 14ª Conferencia Internacional de Diseño de Ingeniería, París, agosto de 2007.) Nuestro análisis incluye los tres pasos siguientes: 1. Entreviste a los arquitectos del sistema. Empezamos por pedir a los ingenieros superiores responsables de la función y el diseño generales del producto (los arquitectos de sistemas en la jerga de ingeniería) que identifiquen las interfaces de diseño técnico entre los cuatro componentes. ¿Los componentes tienen que estar conectados espacialmente entre sí? ¿Algunos componentes transfieren fuerzas, material, energía o información a otros componentes para que puedan funcionar correctamente? Las respuestas a estas preguntas se utilizan para identificar las interfaces entre todos los componentes del producto. Con estos datos, los directores del proyecto pueden presentar las respuestas de cuatro por cuatro matriz de interfaz de diseño (un tipo de DSM que se utiliza para mapear la red de interfaces de componentes), como el que se ilustra en la exposición «Evaluar el ajuste entre el diseño y la comunicación». Evaluar el ajuste entre el diseño y la comunicación El primer paso para analizar el problema de comunicación entre los ingenieros de diseño es hacer que los arquitectos del sistema identifiquen las interfaces técnicas entre los componentes y registren sus respuestas en una matriz de interfaces de diseño. Luego, pida a los miembros del equipo de diseño de componentes y subsistemas que identifiquen las interacciones técnicas que han tenido, tienen o esperan tener con otros equipos y que presenten esas respuestas en una matriz de interacciones de equipo. A continuación, combine las dos matrices para generar una matriz de alineación que revele las coincidencias y los desajustes entre las interfaces y las interacciones. Las siguientes matrices se basan en un producto con cuatro componentes. En la siguiente matriz de interfaz de diseño, una celda sombreada indica la presencia de una interfaz técnica entre dos componentes. Por lo tanto, la primera fila de la matriz indica que el componente A necesitará algunos datos de los componentes B y D, pero nada de C. La primera columna muestra que se espera que A dé datos a B y D (o imponga restricciones técnicas a) B y D, pero no a C. En la matriz de interacciones del equipo, cada fila indica de qué otros equipos espera un equipo en particular que necesite información y recursos, y cada columna muestra dónde se espera que un equipo proporcione la información y los recursos. Una celda sombreada indica dónde esperan interactuar los equipos. 2. Encueste a los equipos de diseño de componentes. En el segundo paso, identificamos las comunicaciones técnicas que las personas que trabajan en cada equipo de diseño de componentes esperan que tengan lugar con las personas de los demás equipos. En concreto, preguntamos a los miembros de cada equipo si prevén que necesitarán información técnica o recursos de otros equipos. Al encuestarlos, tenemos que asegurarnos de que todos están familiarizados con la función y las especificaciones del componente o componentes que están desarrollando. (No compartimos con ellos la matriz elaborada en el primer paso, ya que esto sesgaría las respuestas de los equipos). Con estos datos de la encuesta, podemos representar los patrones de interacción técnica de los equipos en otra matriz de cuatro por cuatro (correspondiente a los cuatro equipos de diseño) que denominamos matriz de interacción en equipo, que también se muestra en la exposición «Evaluar el ajuste entre el diseño y la comunicación». 3. Combine los resultados. En el tercer y último paso, superponemos las dos matrices para obtener la matriz de alineación (de nuevo, consulte la exposición «Evaluar el ajuste entre el diseño y la comunicación»). Esta matriz muestra las coincidencias y los desajustes entre la arquitectura del producto tal como la concibieron los arquitectos del sistema y las expectativas de los equipos que participan en el desarrollo del producto. Más importante aún, pone de relieve los desajustes: cuando se han identificado las interfaces de diseño pero no se producen interacciones en equipo (interfaces desatendidas) y cuando las interacciones en equipo tienen lugar sin que los arquitectos de sistemas identifiquen la interfaz de diseño correspondiente (interfaces no identificadas). Como veremos, a veces estas interfaces no identificadas resultan críticas. Al final de un proyecto, los directores pueden actualizar la matriz de alineación rediseñando la matriz de interacciones del equipo en función de las encuestas más recientes en las que se pide a los miembros del equipo de los componentes que digan de dónde han recibido realmente la información y los recursos que necesitaban. Superponer la nueva matriz de interacción del equipo sobre la matriz de la interfaz de diseño original revelaría si los desajustes descubiertos al principio del proyecto habían persistido y si habían aparecido otros desajustes. Una autopsia de este tipo proporciona información valiosa sobre los futuros proyectos de desarrollo de productos, especialmente para las empresas que esperan desarrollar productos similares en el futuro o en las próximas generaciones del mismo producto. Realizamos uno de esos análisis del desarrollo por parte de Pratt & Whitney del PW4098, el motor que, en ese momento, estableció nuevos estándares en la industria de la aviación en cuanto a velocidad y coste de desarrollo. (También fue el primer motor a reacción comercial de la historia certificado para operaciones de doble alcance extendido de 180 minutos desde su primer día de servicio). Empezamos entrevistando a los arquitectos del motor, quienes identificaron 569 interfaces entre los 54 componentes principales del motor. Muchas de estas interfaces eran críticas y complejas porque no solo implicaban componentes físicamente adyacentes, sino también la transferencia de material (aire, combustible o aceite), energía (vibración o calor), fuerzas estructurales o señales utilizadas por el sistema de control del motor. La matriz de interfaz de diseño extraída de esta información se muestra en la exposición «Creación de una matriz de alineación para Pratt & Whitney». Luego preguntamos al menos a dos miembros de cada uno de los 54 equipos que participan en el proyecto con qué frecuencia recibían información técnica de otros equipos durante la fase de diseño detallado del proyecto y qué tan importante percibían que era esta información. Los resultados de esta encuesta documentaron 423 interacciones entre los equipos componentes, que aparecen en la matriz de interacciones en equipo que se muestra en la exposición. Por fin calculamos una matriz de alineación fusionando las dos primeras matrices. Crear una matriz de alineación para Pratt & Whitney Esta exposición muestra la interfaz de diseño, la interacción en equipo y las matrices de alineación que desarrollamos para Pratt & Whitney tras el proyecto PW4098. Llama la atención el número de desajustes (294 en total) que aparecieron incluso en un análisis post hoc. Realizar este ejercicio antes o durante el proyecto probablemente habría revelado muchos desajustes adicionales que se corrigieron a lo largo del proyecto. Tenga en cuenta que los componentes (en la matriz de interfaces de diseño) y los equipos (en la matriz de interacciones en equipo) que pertenecen al mismo subsistema se agrupan para que podamos distinguir fácilmente (con los cuadros a lo largo de la diagonal) entre las interfaces (e interacciones) que se producen dentro de los límites y las que cruzan los límites. Los lectores con una lupa contaban 220 interfaces de diseño desatendidas que no coincidían con las interacciones del equipo y 74 interfaces no identificadas en las que los equipos intercambiaban información técnica a pesar de que no había ninguna interfaz de diseño identificada entre los componentes. Aunque sería ingenuo esperar una alineación perfecta entre las interfaces de diseño y las interacciones del equipo (y, en este caso, muchas de las 220 interfaces desatendidas no presentaban problemas o no eran críticas), un desajuste en esta escala indica que Pratt & Whitney corría riesgos considerables relacionados con sobrecostes u otros problemas con este proyecto. Por qué se producen los desajustes Los desajustes no se producen al azar en un producto u organización. Más bien, son el resultado del diseño del producto y de factores organizativos. Los puntos de comunicación clave planificados pueden seguir siendo problemáticos por varios motivos, entre ellos la presencia de límites organizativos (es más probable que se pierdan las interfaces transfronterizas que las interfaces con un equipo que pertenece al mismo grupo), la falta de criticidad de la interfaz (las interfaces complejas y críticas reciben más atención que las no críticas), el uso de canales de comunicación indirectos (los equipos a veces pasan la información técnica a través de otros equipos intermediarios en lugar de interactuar directamente), la presencia de interfaces remanentes (interfaces que tienen definido en proyectos anteriores puede que no sea necesario volver a confirmarlo al diseñar el nuevo proyecto) y el uso de la estandarización de interfaces (las interfaces cuyas especificaciones se han documentado formalmente se supone que permanecerán sin cambios). En el caso del proyecto Pratt & Whitney, se produjeron algunos desajustes porque los diseños de los componentes procedían de diseños anteriores. Varios componentes del compresor de alta presión, por ejemplo, prácticamente no cambiaron con respecto a la generación de motores anterior. Como resultado, algunos de los equipos responsables de estos componentes solo tuvieron que prestar una atención marginal para coordinar sus interfaces entre sí, aunque aun así tenían que coordinarse con otros componentes muy rediseñados. Esa falta de atención se extendió a sus comunicaciones relacionadas con otros componentes de alto diseño. Además, muchas interfaces de diseño estructural y térmico quedaron desatendidas porque no eran críticas o se suponía que eran estándar. En muchos casos, estas interfaces involucraban a equipos de diferentes partes de la organización que tenían menos oportunidades de comunicación informal, lo que podría haber descubierto cambios en las normas anteriores. El impacto de estas interfaces desatendidas probablemente se tradujo en reducciones muy pequeñas en el rendimiento o la durabilidad de los componentes y sistemas afectados. Pero dada la esperanza de vida útil de 25 a 30 años de un producto como el PW4098, incluso pequeñas desviaciones de rendimiento podrían acumularse y provocar importantes gastos de garantía o servicio a lo largo de la vida útil del producto. Por ejemplo, si un componente crítico, como el perfil aerodinámico de una turbina, no cumple con su esperanza de vida solo un pequeño porcentaje, podría significar una o más retiradas no planificadas del motor para su mantenimiento durante su vida útil. Para un producto así, una sola retirada no planificada del motor podría suponer un coste adicional de 150 000$ para el cliente. Aunque la mayoría de las interfaces desatendidas no son críticas, algunas sí. Esas interfaces desatendidas críticas se producen en su mayoría cuando los equipos involucrados provienen de diferentes partes de la organización. Los costes pueden ser sustanciales. En el proyecto PW4098, dos interfaces desatendidas resultaron ser críticas y sus costes variaron según el tiempo que tardaron en descubrirse y resolverse los problemas asociados con las interfaces. Una se refería a un cambio en las cargas estructurales transferidas entre los conjuntos de hardware giratorios del núcleo de alta presión y provocó cargas excesivas en el hardware de acoplamiento durante las pruebas de los primeros motores de desarrollo. En consecuencia, Pratt & Whitney tuvo que desmontar, rediseñar y reconstruir los motores de prueba. Estimamos que este problema añadió entre un 1 y un 2% al coste del programa y un retraso de tres a cuatro meses a ciertos elementos del programa. La otra interfaz desatendida se descubrió más tarde, cuando comenzó el montaje de producción inicial, pero antes de que se enviara ningún motor. Este, también relacionado con las cargas transferidas entre los módulos del motor, redujo la esperanza de vida de uno de los cojinetes principales del motor. El número de piezas y motores afectados fue significativamente mayor que el asociado con el primer problema, y también lo fue el impacto en el programa en términos de coste y tiempo. Hemos descubierto que las interfaces no identificadas son menos comunes que las interfaces desatendidas. Sin embargo, a diferencia de las interfaces desatendidas, su aparición casi siempre es positiva para el proyecto, ya que revelan interdependencias potencialmente críticas pero imprevistas entre las piezas o los sistemas de un producto. Muchas de las interfaces no identificadas que descubrimos en Pratt & Whitney estaban relacionadas con investigaciones sobre posibles problemas de diseño a nivel del motor que podrían haber provocado una tensión excesiva, un sobrecalentamiento o una presión insuficiente en el motor de pruebas. Como los equipos implicados hablaron entre sí cuando empezaron a ver o anticipar los problemas inesperados, pudieron mitigarlos antes de la fase de prueba del producto del proyecto, lo que supuso un considerable potencial de ahorro de tiempo y costes. Cuando se descubren interfaces no identificadas como estas, la pregunta principal es si incorporarlas formalmente al cronograma y las rutinas de un proyecto o dejarlas en paz. Esta decisión depende en gran medida de la importancia de la comunicación. En el caso de las interfaces descritas anteriormente, Pratt & Whitney formalizó algunas de las interacciones pertinentes del equipo al planificar el desarrollo de su motor de próxima generación. Las condiciones que generan las interfaces no identificadas son diferentes de las que hacen que la gente pase por alto las interfaces. Varias de las interfaces no identificadas de Pratt & Whitney se produjeron entre equipos que trabajaban en escenarios de diseño a nivel de motor que creaban cargas estructurales o térmicas adversas. Esto, a su vez, generó la necesidad de soluciones técnicas en distintos componentes. En un caso, tres equipos de la turbina de alta presión y de la turbina de baja presión tuvieron que interactuar con los equipos que trabajaban en la cámara de combustión para optimizar el entorno térmico y, por lo tanto, la durabilidad de sus respectivos componentes. Se consideraron interfaces críticas que los arquitectos del sistema no habían identificado. Afortunadamente, las personas de estos equipos habían trabajado juntas en las mismas funciones en proyectos anteriores, por lo que era más probable que tuvieran intercambios de información no planificados. Cómo gestionar los desajustes Una vez que se entiendan las causas fundamentales de los desajustes, una organización puede decidir cómo tratarlos. Las posibles soluciones pueden variar, como rediseñar las líneas organizativas, reasignar o crear nuevas responsabilidades de gestión de interfaces y herramientas de facilitación o incluso rediseñar la arquitectura del sistema (algunas de ellas se analizan más adelante). Para encontrar la solución adecuada para su proyecto, tenga en cuenta los tres pasos siguientes: 1. Revise los límites organizativos y del sistema. En los proyectos en los que un número significativo de interfaces desatendidas superan los límites organizativos, los directores de proyectos deberían revisar sus estructuras organizativas. Hacerlo probablemente habría ayudado a Airbus a evitar los problemas que encontró. La empresa basó la estructura organizativa de sus programas no solo en la arquitectura del avión, sino también en la participación del trabajo de los distintos socios de EADS (el consorcio europeo al que pertenece Airbus). La adición de este conjunto adicional de límites aumentó la probabilidad de que se produjeran interfaces desatendidas y redujo la probabilidad de que se produjeran interfaces no identificadas que resolvieran problemas. Sin embargo, para cambiar la estructura organizativa puede ser necesario cambiar la arquitectura del sistema, porque eso es lo que impulsa la estructura organizativa en la mayoría de las empresas. Desarrollar componentes más modulares que compartan menos interfaces directas e indirectas con otros componentes del producto es especialmente útil porque la comunicación técnica en estos proyectos es más fácil de gestionar que en los proyectos que requieren una gran interacción entre los componentes. En el proyecto Pratt & Whitney, los equipos responsables del diseño de componentes más modulares omitieron muchas menos interfaces críticas con los equipos de otros componentes. Había menos que perder y la carga de trabajo asociada a un menor número de interfaces directas e indirectas era más predecible. Sin embargo, un exceso de modularidad puede provocar miopía, sobre todo a nivel de subcomponentes. En Pratt & Whitney descubrimos que los equipos de diseño de subsistemas altamente modularizados tenían menos probabilidades de hablar con los equipos que trabajaban en otros subsistemas modularizados que los equipos que trabajaban en subsistemas más integrados. Por lo tanto, al pasar a ser modular, los diseñadores de productos deben prestar mucha atención a las interfaces críticas de esos subsistemas. 2. Forme equipos para gestionar las interfaces mal gestionadas. Los gerentes también tienen la opción de gestionar las interfaces críticas (para garantizar que se producen las no identificadas o que se formalizan las desatendidas), asignando ese trabajo a los equipos que ya tienen la tarea de la interacción o haciendo que las personas de los equipos implicados rindan cuentas formal y activamente por las interfaces. Nosotros recomendaríamos este enfoque para gestionar las interfaces identificadas más allá de los límites; lo más probable es que los equipos de diseño de interfaces las ignoren. Otra forma de gestionar la falta de interfaces —una que también evite la necesidad de cambiar significativamente la estructura organizativa— es ampliar la responsabilidad de los equipos de integración existentes. La mayoría de los grandes proyectos tienen equipos de este tipo: en Pratt & Whitney había seis equipos que gestionaban problemas del sistema, como la eficiencia del aire y el combustible, que afectaban al diseño de prácticamente todos los componentes del motor. A pesar de que la gestión de las comunicaciones del equipo no suele ser la función principal de los equipos de integración, por la naturaleza de su trabajo, estos equipos se comunican con casi todos los demás equipos de la organización. En consecuencia, están en condiciones de conocer en tiempo real el estado de las interfaces críticas durante el proceso de diseño y de reunir a los equipos no conectados para gestionar las interfaces críticas que necesitan una atención especial. Estos equipos de integración podrían hacerse responsables de marcar las interfaces críticas que no están siendo atendidas adecuadamente. En el proyecto PW4098, el equipo de flujo de aire secundario (uno de los seis equipos de integración) se encargó de gestionar los múltiples sistemas internos de gestión térmica y de presión del motor para optimizar el rendimiento aerodinámico del motor y la durabilidad de los componentes. Organiza regularmente reuniones y otras comunicaciones entre equipos que de otro modo no estarían conectados para abordar las interfaces críticas. Por desgracia, la mayoría de los equipos de integración se centran en la planificación de los hitos y en la asignación de recursos, y solo prestan una atención marginal a la calidad de la comunicación entre los equipos de los componentes. Eso tiene que cambiar. Considere el problema que se podría haber evitado en las últimas fases del desarrollo del Airbus A380 si uno de los equipos de integración se hubiera dado cuenta de que el equipo de arneses eléctricos de Alemania y su equipo homólogo en Francia, que eran responsables de las diferentes secciones del fuselaje, no se comunicaban correctamente sobre las especificaciones de su interfaz de diseño. La mayoría de los equipos de integración solo prestan una atención marginal a la calidad de la comunicación entre los equipos de los componentes. Eso tiene que cambiar. 3. Seleccione las herramientas de apoyo a la comunicación adecuadas. Muchos equipos de diseño echan de menos las interfaces porque los planificadores de proyectos no han pensado detenidamente en el uso de las herramientas de comunicación y las plataformas compartidas. En Airbus, una de las principales razones de la interrupción de la comunicación entre los equipos del A380 fue la falta de compatibilidad entre las herramientas de diseño asistido por ordenador (CAD) que utilizaban. Muchos equipos de diseño echan de menos las interfaces porque los planificadores de proyectos no han pensado detenidamente en el uso de las herramientas de comunicación y las plataformas compartidas. Ser más inteligente en el uso de las herramientas de comunicación no tiene por qué implicar mucha tecnología: Pratt & Whitney exige que los equipos rellenen con regularidad los documentos de interfaz controlada y los documentos de requisitos de los componentes (especificaciones) para garantizar que las interfaces críticas están identificadas y atendidas. En los casos en que los miembros del equipo utilizan la tecnología para completar el trabajo, las distintas herramientas y plataformas deben integrarse cuidadosamente. Al planificar el desarrollo del proyecto de motores que siguió a la PW4098, por ejemplo, Pratt & Whitney vinculó los modelos analíticos de aerodinámica total del motor y del flujo de aire secundario con los modelos de componentes para ayudar a los equipos de diseño a gestionar sus interfaces con el apoyo de los equipos de integración. Luego, a personas específicas de cada equipo se les encargó hacer un seguimiento del impacto de los cambios de diseño en los modelos de componentes y sistemas y comunicar esas conclusiones a sus homólogos de otros equipos. • • • Nuestro enfoque proporciona un método sistemático para que una organización aprenda cómo y dónde está expuesta al riesgo de fallos de comunicación entre los equipos de diseño que trabajan juntos para desarrollar productos complejos. Además, una organización puede utilizar nuestras herramientas para determinar cómo los cambios en la arquitectura del sistema, o la aparición y eliminación de interfaces entre los componentes del sistema, afectarán a su capacidad de evitar fallos de comunicación en el futuro. Al utilizar los DSM para documentar la arquitectura del producto para cada generación de una familia de productos, los gestores pueden identificar las diferencias clave entre las arquitecturas antiguas y nuevas. Con la matriz de alineación, los gerentes crean una representación compacta y visual de las interfaces e interacciones que les permite diagnosticar la forma en que su organización aborda las interfaces de diseño. Lo que es más importante, la matriz de alineación puede ayudar a los directivos a dirigir correctamente sus esfuerzos para alinear las interacciones del equipo con las interfaces de diseño a fin de evitar que se produzcan costosos problemas más adelante en el ciclo de vida del producto.

¿Sus ingenieros hablan entre sí cuando deberían?

Resumen.

Partner Center