Seus engenheiros estão conversando uns com os outros quando deveriam?

Todas as empresas que projetam produtos complexos e de alta engenharia têm suas histórias de terror. A Ford e a Bridgestone Firestone perderam bilhões de dólares após o fracasso em coordenar o design do veículo do Ford Explorer com o design de seus pneus. Da mesma forma, o desenvolvimento do “superjumbo” A380 pela Airbus sofreu grandes atrasos e custos excessivos devido às incompatibilidades emergentes tardias no projeto dos chicotes elétricos de várias seções da fuselagem do avião. Esses erros provavelmente contribuíram para a perda do CEO da Airbus e para mudanças importantes na gestão do programa A380. O que chama a atenção nessas histórias e em muitas outras semelhantes é que, em praticamente todos os casos, todas as pessoas envolvidas concordaram, em retrospectiva, que poderiam ter evitado seus caros erros ao garantir que as diferentes equipes responsáveis pelo desenvolvimento dos componentes dos produtos tivessem se comunicado de forma mais eficaz. É claro que, com projetos de desenvolvimento complexos, você nunca pode ter certeza de que planejou todas as contingências. No entanto, nossa experiência mostra que, na fase de design desses projetos, muitas empresas se beneficiariam se concentrassem fortemente nos pontos críticos de contato entre suas várias equipes de desenvolvimento de componentes para garantir que todos saibam quando e com quem devem compartilhar informações. Este artigo ajuda os gerentes a atenuar esse problema de comunicação de design. Com base em pesquisas detalhadas sobre como a Pratt & Whitney conduziu o desenvolvimento de seu motor a jato comercial de maior empuxo — o PW4098, que alimenta o Boeing 777 — apresentamos uma nova aplicação de uma ferramenta de gerenciamento de projetos estabelecida: a matriz de estrutura de design (DSM). Nosso aplicativo ajuda os gerentes a identificar onde as falhas nas comunicações planejadas podem ocorrer, bem como a reconhecer quando as equipes do projeto se envolvem em comunicações técnicas não planejadas. Também analisamos as comunicações entre as equipes de projeto que ocorrem dentro e fora da estrutura formal do projeto. Concluímos discutindo como os gerentes devem lidar com os problemas de comunicação que são revelados no processo. Embora não pretendamos oferecer uma solução definitiva para o problema de comunicação de design, acreditamos que os gerentes que usarem nossas ferramentas nas gerações seguintes de produtos melhorarão a qualidade de seus processos de desenvolvimento. Detectando interfaces perdidas antes que elas ocorram A primeira coisa que uma equipe de projeto faz quando se depara com um desafio complexo de desenvolvimento é dividir o projeto em partes gerenciáveis que são então atribuídas a subequipes dedicadas. No contexto do desenvolvimento de um produto como um motor a jato, isso resulta em um grande número de equipes multifuncionais especializadas, cada uma trabalhando em um componente ou subsistema diferente do motor. Obviamente, essas equipes não podem trabalhar isoladamente; além de projetar seus componentes atribuídos, elas também devem integrar seus projetos aos dos outros componentes para garantir que todo o produto ou sistema funcione como um todo. Portanto, ao planejar um processo complexo de desenvolvimento de produtos, é fundamental que os gerentes de projeto especifiquem exatamente quais recursos e informações as diferentes equipes precisarão umas das outras em estágios específicos do projeto. No projeto de desenvolvimento de motores a jato Pratt & Whitney que estudamos, o motor foi dividido em oito subsistemas, cada um dos quais foi posteriormente decomposto em cinco a dez componentes, totalizando 54 componentes do motor. Típica para esses projetos, a organização de desenvolvimento foi estruturada correspondentemente em 54 equipes de design multifuncionais responsáveis por cada componente, além de seis equipes de integração responsáveis por gerenciar os requisitos de nível de motor em áreas como eficiência de combustível. Essas equipes tiveram que interagir muito: havia várias centenas de interfaces entre os componentes do motor, muitas das quais teriam enfrentado problemas significativos sem a comunicação adequada entre as equipes de design relevantes. Para ajudar a gerenciar o aspecto de comunicação de tais projetos, propomos a seguinte abordagem: (a) identificar interfaces autônomas, áreas onde a comunicação deveria estar ocorrendo, mas não está, e (b) procure interfaces não identificadas, áreas onde a comunicação está ocorrendo, mas não foi planejada. O resultado da implementação dessa abordagem é o que chamamos de matriz de alinhamento, que revela incompatibilidades entre as comunicações e trocas que deveriam ocorrer e aquelas que realmente ocorrem. Também demonstra, portanto, quão bem o projeto foi planejado e executado. Para ver como a abordagem funciona, suponhamos que planejemos desenvolver um produto com quatro componentes, cada um dos quais requer sua própria equipe de design especializada. (Essa abordagem pode ser usada quando a estrutura organizacional é mapeada diretamente para a arquitetura do produto — ou seja, o componente X é projetado pela equipe X — o que é o caso da maioria dos projetos complexos de desenvolvimento nas empresas automotivas e aeroespaciais que estudamos. Para casos em que as estruturas organizacionais e de produto não são mapeadas diretamente, consulte “Alinhando Arquiteturas Organizacionais, de Processo e de Produto no Desenvolvimento de Software” de M.E. Sosa no Anais da 14ª Conferência Internacional em Design de Engenharia, Paris, agosto de 2007.) Nossa análise envolve as três etapas a seguir: 1. Entreviste os arquitetos do sistema. Começamos exigindo que os engenheiros seniores responsáveis pela função geral e pelo layout do produto — os arquitetos de sistema na área de engenharia — identifiquem as interfaces de design técnico entre os quatro componentes. Os componentes precisam estar conectados espacialmente entre si? Alguns componentes transferem forças, materiais, energia ou informações para outros componentes para permitir que funcionem corretamente? As respostas a essas perguntas são usadas para identificar as interfaces entre todos os componentes do produto. Com esses dados, os gerentes de projeto podem apresentar as respostas em um esquema de quatro por quatro matriz de interface de design (um tipo de DSM usado para mapear a rede de interfaces de componentes), como o ilustrado na exposição “Avaliando a adequação entre design e comunicação”. Avaliando a adequação entre design e comunicação A primeira etapa na análise do problema de comunicação entre engenheiros de projeto é fazer com que os arquitetos do sistema identifiquem as interfaces técnicas entre os componentes e registrem suas respostas em uma matriz de interface de projeto. Em seguida, peça aos membros da equipe de design de componentes e subsistemas que identifiquem as interações técnicas que tiveram, estão tendo ou esperam ter com outras equipes e apresentem essas respostas em uma matriz de interação da equipe. Em seguida, mescle as duas matrizes para gerar uma matriz de alinhamento que revela correspondências e incompatibilidades entre interfaces e interações. As matrizes abaixo são baseadas em um produto com quatro componentes. Na matriz de interface de design abaixo, uma célula sombreada indica a presença de uma interface técnica entre dois componentes. Assim, a primeira linha da matriz indica que o componente A exigirá alguma entrada dos componentes B e D, mas nada de C. A primeira coluna mostra que se espera que A forneça entrada (ou imponha restrições técnicas a) B e D, mas não C. Na matriz de interação da equipe, cada linha indica de quais outras equipes uma equipe específica espera precisar de informações e recursos, e cada coluna mostra onde se espera que uma equipe forneça as informações e os recursos. Uma célula sombreada indica onde as equipes esperam interagir. 2. Pesquise as equipes de design de componentes. Na segunda etapa, identificamos as comunicações técnicas que as pessoas que trabalham em cada equipe de design de componentes esperam que ocorram com as pessoas das outras equipes. Especificamente, perguntamos aos membros de cada equipe se eles antecipam a necessidade de informações técnicas ou recursos de outras equipes. Ao examiná-los, precisamos garantir que todos estejam familiarizados com a função e as especificações do componente ou componentes que estão desenvolvendo. (Não compartilhamos com eles a matriz produzida na primeira etapa, pois isso enviesaria as respostas das equipes.) Usando esses dados da pesquisa, podemos representar os padrões de interação técnica das equipes em outra matriz de quatro por quatro (correspondente às quatro equipes de design) que chamamos de matriz de interação da equipe, também exibida na exposição “Avaliando a adequação entre design e comunicação”. 3. Combine os resultados. Na terceira e última etapa, sobrepomos as duas matrizes para obter a matriz de alinhamento (novamente, veja a exposição “Avaliando a adequação entre design e comunicação). Essa matriz mostra as correspondências e incompatibilidades entre a arquitetura do produto, conforme concebida pelos arquitetos do sistema, e as expectativas das equipes envolvidas no desenvolvimento do produto. Mais importante ainda, ele destaca as incompatibilidades: quando as interfaces de design foram identificadas, mas as interações da equipe não estão ocorrendo (interfaces autônomas) e quando as interações da equipe ocorrem sem que uma interface de design correspondente seja identificada pelos arquitetos do sistema (interfaces não identificadas). Como veremos, às vezes essas interfaces não identificadas acabam sendo críticas. No final de um projeto, os gerentes podem atualizar a matriz de alinhamento redesenhando a matriz de interação da equipe com base em pesquisas mais recentes nas quais os membros da equipe componente são solicitados a declarar onde realmente receberam as informações e os recursos de que precisavam. A sobreposição da nova matriz de interação da equipe na matriz original da interface de design revelaria se as incompatibilidades descobertas no início do projeto persistiram e se outras incompatibilidades haviam surgido. Uma autópsia desse tipo fornece informações valiosas sobre projetos futuros de desenvolvimento de produtos, especialmente para empresas que esperam desenvolver produtos similares no futuro ou em gerações futuras do mesmo produto. Conduzimos uma dessas análises do desenvolvimento do PW4098 pela Pratt & Whitney, o motor que, na época, estabeleceu novos padrões no setor de aviação em termos de velocidade e custo de desenvolvimento. (Também foi o primeiro motor a jato comercial certificado para operações duplas de alcance estendido de 180 minutos desde seu primeiro dia de serviço.) Começamos entrevistando os arquitetos do motor, que identificaram 569 interfaces entre os 54 componentes principais do motor. Muitas dessas interfaces eram críticas e complexas porque não envolviam apenas componentes fisicamente adjacentes, mas também a transferência de material (ar, combustível ou óleo), energia (vibração ou calor), forças estruturais ou sinais usados pelo sistema de controle do motor. A matriz da interface de design extraída dessas informações é mostrada na exposição “Criando uma matriz de alinhamento para a Pratt & Whitney”. Em seguida, perguntamos a pelo menos dois membros de cada uma das 54 equipes envolvidas no projeto com que frequência eles receberam informações técnicas de outras equipes durante a fase de design detalhado do projeto e quão críticas eles consideravam essas informações. Os resultados desta pesquisa documentaram 423 interações entre equipes de componentes, que aparecem na matriz de interação da equipe mostrada na exposição. Finalmente calculamos uma matriz de alinhamento mesclando as duas primeiras matrizes. Criando uma matriz de alinhamento para Pratt & Whitney Esta exposição mostra a interface de design, a interação da equipe e as matrizes de alinhamento que desenvolvemos para a Pratt & Whitney após o projeto PW4098. É impressionante quantas incompatibilidades (294 ao todo) surgiram mesmo em uma análise post hoc. A realização desse exercício antes ou durante o projeto provavelmente teria revelado muitas incompatibilidades adicionais que foram corrigidas durante o curso do projeto. Observe que os componentes (na matriz da interface de design) e as equipes (na matriz de interação da equipe) que pertencem ao mesmo subsistema são agrupados para que possamos distinguir facilmente (com as caixas na diagonal) entre interfaces (e interações) que ocorrem dentro dos limites e aquelas que ultrapassam os limites. Leitores armados com uma lupa contariam 220 interfaces de design autônomas que não eram compatíveis com as interações da equipe e 74 interfaces não identificadas nas quais as equipes trocavam informações técnicas, embora não houvesse uma interface de design identificada entre os componentes. Embora fosse ingenuidade esperar um alinhamento perfeito das interfaces de design e das interações da equipe — e, nesse caso, muitas das 220 interfaces autônomas não eram problemáticas ou não eram críticas — o desalinhamento nessa escala indica que a Pratt & Whitney estava sujeita a riscos consideráveis envolvendo custos excessivos ou outros problemas com esse projeto. Por que as incompatibilidades ocorrem As incompatibilidades não ocorrem aleatoriamente em um produto ou organização. Pelo contrário, eles são o resultado do design do produto e de fatores organizacionais. Os principais pontos de comunicação planejados podem permanecer problemáticos por vários motivos, incluindo a presença de limites organizacionais (interfaces transfronteiriças têm maior probabilidade de serem perdidas do que interfaces com uma equipe pertencente ao mesmo grupo), a falta de criticidade da interface (interfaces complexas e críticas recebem mais atenção do que as não críticas), o uso de canais de comunicação indiretos (as equipes às vezes passam informações técnicas por meio de outras equipes intermediárias em vez de interagir diretamente), a presença de transferência de interface (interfaces que têm foram definidas em projetos anteriores (talvez não precisem ser reconfirmadas na concepção do novo projeto) e o uso da padronização de interfaces (interfaces cujas especificações foram formalmente documentadas devem permanecer inalteradas). No caso do projeto Pratt & Whitney, algumas incompatibilidades ocorreram porque os designs dos componentes foram transferidos dos projetos anteriores. Vários componentes do compressor de alta pressão, por exemplo, permaneceram praticamente inalterados em relação à geração anterior de motores. Como resultado, algumas das equipes responsáveis por esses componentes tiveram que prestar pouca atenção para coordenar suas interfaces entre si, embora ainda precisassem se coordenar com outros componentes altamente redesenhados. Essa desatenção se espalhou por suas comunicações envolvendo outros componentes altamente projetados. Além disso, muitas interfaces de projeto estrutural e térmico foram deixadas sem supervisão porque não eram críticas ou eram consideradas padrão. Em muitos casos, essas interfaces envolveram equipes de diferentes partes da organização que tinham menos oportunidades de comunicação informal, o que pode ter revelado mudanças nos padrões anteriores. O impacto dessas interfaces autônomas provavelmente resultou em reduções muito pequenas no desempenho ou na durabilidade dos componentes e sistemas afetados. Mas, dada a expectativa de vida de 25 a 30 anos de um produto como o PW4098, mesmo pequenos desvios de desempenho podem se somar e causar despesas significativas de garantia ou serviço durante a vida útil do produto. Por exemplo, se um componente crítico, como um aerofólio de turbina, perder sua expectativa de vida útil em apenas alguns por cento, isso pode significar uma ou mais remoções não planejadas do motor para manutenção durante a vida útil do motor. Para esse produto, uma única remoção não planejada do motor pode adicionar um custo incremental de até $150.000 para o cliente. Embora a maioria das interfaces autônomas não sejam críticas, algumas são. Essas interfaces críticas autônomas ocorrem principalmente quando as equipes envolvidas vêm de diferentes partes da organização. Os custos podem ser substanciais. No projeto PW4098, duas interfaces autônomas se mostraram críticas e seus custos variaram com o tempo necessário para que os problemas associados às interfaces fossem descobertos e resolvidos. Uma delas estava relacionada a uma mudança nas cargas estruturais transferidas entre conjuntos de hardware rotativos no núcleo de alta pressão e resultou em cargas excessivas no hardware de acoplamento durante os testes dos primeiros motores de desenvolvimento. Consequentemente, a Pratt & Whitney teve que desmontar, redesenhar e reconstruir os motores de teste. Estimamos que esse único problema adicionou de 1% a 2% ao custo do programa e um atraso de três a quatro meses a certos elementos do programa. A outra interface autônoma foi descoberta mais tarde, após o início da montagem da produção, mas antes do envio de qualquer motor. Esse, também relacionado às cargas transferidas entre os módulos do motor, reduziu a expectativa de vida de um dos rolamentos principais do motor. O número de peças e motores afetados foi significativamente maior do que o associado ao primeiro problema, assim como o impacto no programa em termos de custo e tempo. Descobrimos que interfaces não identificadas são menos comuns do que interfaces autônomas. No entanto, diferentemente das interfaces autônomas, sua ocorrência quase sempre é positiva para o projeto porque elas revelam interdependências potencialmente críticas, mas imprevistas, entre as peças ou sistemas de um produto. Muitas das interfaces não identificadas que descobrimos na Pratt & Whitney estão relacionadas a investigações sobre possíveis problemas de projeto no nível do motor que poderiam ter resultado em tensão excessiva, superaquecimento ou pressão insuficiente no motor de teste. Como as equipes envolvidas conversaram umas com as outras quando começaram a ver ou antecipar os problemas inesperados, elas conseguiram mitigá-los antes da fase de teste do produto do projeto, resultando em um potencial considerável de economia de tempo e custos. Quando interfaces não identificadas como essas são descobertas, a principal questão é se devemos incorporá-las formalmente ao cronograma e às rotinas de um projeto ou deixá-las em paz. Essa decisão depende muito da importância da comunicação. No caso das interfaces descritas acima, a Pratt & Whitney formalizou algumas das interações relevantes da equipe no planejamento do desenvolvimento de seu mecanismo de próxima geração. As condições que geram interfaces não identificadas são diferentes daquelas que fazem com que as pessoas ignorem as interfaces. Várias das interfaces não identificadas da Pratt & Whitney ocorreram entre equipes que trabalhavam em cenários de projeto no nível do motor que criavam cargas estruturais ou térmicas adversas. Isso, por sua vez, gerou a necessidade de soluções técnicas em componentes distintos. Em um caso, três equipes da turbina de alta pressão e da turbina de baixa pressão tiveram que interagir com as equipes que trabalhavam na câmara de combustão para otimizar o ambiente térmico e a durabilidade resultante de seus respectivos componentes. Essas foram consideradas interfaces críticas que não haviam sido identificadas pelos arquitetos do sistema. Felizmente, as pessoas dessas equipes haviam trabalhado juntas nas mesmas funções em projetos anteriores, aumentando a probabilidade de trocas de informações não planejadas. Como gerenciar incompatibilidades Uma vez que as causas principais das incompatibilidades sejam compreendidas, uma organização pode decidir como lidar com elas. As soluções potenciais podem ser variadas, incluindo redesenhar linhas organizacionais, reatribuir ou criar novas responsabilidades de gerenciamento de interface e ferramentas de facilitação, ou até mesmo redesenhar a arquitetura do sistema (algumas delas são discutidas abaixo). Para encontrar a solução apropriada para seu projeto, considere as três etapas a seguir: 1. Analise os limites organizacionais e do sistema. Para projetos nos quais um número significativo de interfaces autônomas ultrapassa os limites organizacionais, os gerentes de projeto devem revisitar suas estruturas organizacionais. Fazer isso provavelmente teria ajudado a Airbus a evitar os problemas que encontrou. A empresa baseou a estrutura organizacional de seus programas não apenas na arquitetura do avião, mas também na parcela de trabalho de propriedade dos vários parceiros da EADS (o consórcio europeu ao qual a Airbus pertence). A adição desse conjunto extra de limites aumentou a probabilidade de ocorrência de interfaces autônomas e reduziu a probabilidade de ocorrência de interfaces não identificadas na solução de problemas. Para mudar a estrutura organizacional, no entanto, pode ser necessário mudar a arquitetura do sistema, porque é isso que impulsiona a estrutura organizacional na maioria das empresas. O desenvolvimento de componentes mais modulares que compartilham menos interfaces diretas e indiretas com outros componentes do produto é especialmente útil porque a comunicação técnica nesses projetos é mais fácil de gerenciar do que em projetos que exigem muita interação entre componentes. No projeto Pratt & Whitney, as equipes responsáveis por projetar componentes mais modulares perderam muito menos interfaces críticas com equipes de outros componentes. Havia menos a perder, e a carga de trabalho associada a menos interfaces diretas e indiretas era mais previsível. Muita modularidade, no entanto, pode levar à miopia, particularmente no nível dos subcomponentes. Na Pratt & Whitney, descobrimos que as equipes de design de subsistemas altamente modularizados tinham menos probabilidade de conversar com equipes que trabalhavam em outros subsistemas modularizados do que com equipes trabalhando em subsistemas mais integrados. Portanto, ao se tornarem modulares, os projetistas de produtos ainda precisam prestar muita atenção às interfaces críticas entre esses subsistemas. 2. Forme equipes para lidar com interfaces mal gerenciadas. Os gerentes também têm a opção de gerenciar interfaces críticas — para garantir que as não identificadas ocorram ou que as não atendidas sejam formalizadas — atribuindo esse trabalho às equipes já encarregadas da interação ou tornando as pessoas das equipes envolvidas formalmente e ativamente responsáveis pelas interfaces. Recomendamos essa abordagem para gerenciar interfaces identificadas além dos limites — o que as equipes de design de interfaces provavelmente ignorarão. Outra forma de lidar com interfaces perdidas, que também evita a necessidade de mudar significativamente a estrutura organizacional, é ampliar a responsabilidade das equipes de integração existentes. A maioria dos grandes projetos tem essas equipes: na Pratt & Whitney, havia seis equipes gerenciando problemas do sistema, como eficiência de ar e combustível, que afetaram o design de praticamente todos os componentes do motor. Embora o gerenciamento das comunicações da equipe geralmente não seja a função principal das equipes de integração, pela natureza de seu trabalho, essas equipes se comunicam com quase todas as outras equipes da organização. Assim, eles podem aprender em tempo real sobre o status das interfaces críticas durante o processo de design e reunir equipes desconectadas para lidar com interfaces críticas que precisam de atenção especial. Essas equipes de integração podem ser responsáveis por sinalizar as interfaces críticas que não estão sendo atendidas adequadamente. No projeto PW4098, a equipe de fluxo de ar secundário (uma das seis equipes de integração) foi responsável por gerenciar os vários sistemas internos de gerenciamento térmico e de pressão do motor para otimizar o desempenho aerodinâmico do motor e a durabilidade dos componentes. Ele organiza regularmente reuniões e outras comunicações entre equipes que, de outra forma, não estavam conectadas para lidar com interfaces críticas. Infelizmente, a maioria das equipes de integração se concentra no planejamento de marcos e na alocação de recursos, prestando apenas pouca atenção à qualidade da comunicação entre as equipes de componentes. Isso precisa mudar. Considere a dor que poderia ter sido evitada nas últimas fases do desenvolvimento do Airbus A380 se uma das equipes de integração tivesse percebido que a equipe de chicotes elétricos na Alemanha e sua equipe equivalente na França, responsáveis por diferentes seções da fuselagem, não estavam se comunicando adequadamente sobre suas especificações de interface de design. A maioria das equipes de integração presta apenas uma atenção marginal à qualidade da comunicação entre as equipes componentes. Isso precisa mudar. 3. Selecione as ferramentas de suporte de comunicação apropriadas. Muitas equipes de design sentem falta de interfaces porque os planejadores de projetos não pensaram no uso de ferramentas de comunicação e plataformas compartilhadas. Na Airbus, um dos principais motivos para a falha na comunicação entre as equipes do A380 foi a falta de compatibilidade entre as ferramentas de design auxiliado por computador (CAD) que elas usavam. Muitas equipes de design sentem falta de interfaces porque os planejadores de projetos não pensaram no uso de ferramentas de comunicação e plataformas compartilhadas. Ser mais inteligente ao usar ferramentas de comunicação não precisa envolver muita tecnologia: a Pratt & Whitney exige que as equipes preencham regularmente documentos de interface controlada e documentos de requisitos de componentes (especificações) para garantir que as interfaces críticas sejam identificadas e atendidas. Nos casos em que os membros da equipe usam a tecnologia para concluir o trabalho, as várias ferramentas e plataformas devem ser cuidadosamente integradas. Ao planejar o desenvolvimento do projeto de motor que se seguiu ao PW4098, por exemplo, a Pratt & Whitney vinculou a aerodinâmica completa do motor e os modelos analíticos de fluxo de ar secundário aos modelos de componentes para ajudar as equipes de projeto a gerenciar suas interfaces com o apoio das equipes de integração. Pessoas específicas de cada equipe foram então encarregadas de monitorar o impacto das mudanças de design nos modelos de componentes e sistemas e comunicar essas descobertas aos colegas de outras equipes. • • • Nossa abordagem fornece um método sistemático para uma organização aprender como e onde está exposta ao risco de falhas de comunicação entre equipes de design que trabalham juntas para desenvolver produtos complexos. Além disso, uma organização pode usar nossas ferramentas para determinar como as mudanças na arquitetura do sistema, ou o surgimento e a remoção de interfaces entre os componentes do sistema, afetarão sua capacidade de evitar falhas de comunicação no futuro. Ao usar os DSMs para documentar a arquitetura do produto para cada geração de uma família de produtos, os gerentes podem identificar as principais diferenças entre arquiteturas antigas e novas. Com a matriz de alinhamento, os gerentes criam uma representação compacta e visual das interfaces e interações que lhes permite diagnosticar como sua organização aborda as interfaces de design. Mais importante ainda, a matriz de alinhamento pode ajudar os gerentes a direcionar adequadamente seus esforços para alinhar as interações da equipe com as interfaces de design para evitar que problemas dispendiosos ocorram mais tarde no ciclo de vida do produto.

Seus engenheiros estão conversando uns com os outros quando deveriam?

Resumo.

Partner Center