Assim como vimos no post anterior, o uso dos níveis de maturidade tecnológica (TRL) tem se tornado um grande aliado no desenvolvimento seguro de um produto, podendo evitar custos que chegam a bilhões de dólares. Mas o mero conhecimento acerca dos níveis de TRL não é suficiente para garantir a maturação de uma tecnologia ou sua prontidão para integrar-se a um sistema complexo e gerenciar os riscos. Para isso, é necessário que a organização utilize um processo formal e confiável para avaliar a maturidade deste produto e, nesta linha, introduzimos o conceito de TRA – Technology Readiness Assessment.
A metodologia de avaliação de maturidade da tecnologia (TRA), utilizada por diversas agências governamentais e por empresas ao redor do mundo, é um processo sistemático e baseado em evidências a fim de avaliar essa maturidade almejada. E o que é certo: há a necessidade de maior atenção nas “tecnologias críticas”, que são aquelas essenciais para o desempenho de um sistema maior ou para o cumprimento dos objetivos principais de um projeto, como custos e cronograma [GAO – U.S. Government Accountability Office]. A TRA destaca tecnologias críticas e áreas de risco que requerem a atenção do gerente de projetos de desenvolvimento de produto e pode ajudar a identificar componentes imaturos ou a desenvolver um plano de maturação da tecnologia.
Nesse sentido, são sugeridos cinco passos para a realização da TRA, apresentados no fluxo abaixo:
Como aplicar o TRA no desenvolvimento de produtos
O método de aplicação do TRA no sistema depende da quantidade de componentes que o compõem e da complexidade de cada um deles durante o desenvolvimento de um produto. Em sistemas simples – baixa complexidade e poucas funções – ou compostos de apenas um componente, o método aplicado é de direta avaliação. Já em sistemas mais complexos, com grande volume de interfaces e compostos de muitos componentes ou subsistemas, é importante se utilizar de uma abordagem mais sistêmica.
Para estes últimos, a TRA utiliza princípios básicos de engenharia de sistemas para decompô-los em elementos menos complexos que podem ser avaliados com mais precisão, conforme sugerido pela norma API 17Q. Nesse caso, a avaliação começa no nível mais baixo da análise e prossegue na hierarquia em uma abordagem de baixo para cima, como pode ser visualizado na figura abaixo.
Segue-se essa regra pela determinação de que o TRL, para cada elemento da árvore de componentes, é igual ou inferior ao TRL mínimo de seus constituintes, como enunciado pela API 17Q. Como um exemplo simples, não se pode afirmar sobre a integridade final de uma parafusadeira sem que se prove a confiabilidade da broca.
Outro exemplo pode ser dado para sistemas submarinos, ainda segundo a API 17Q, onde o TRL é avaliado no nível do componente, pois geralmente estes que são desenvolvidos, testados, fabricados e integrados a um novo sistema ou ambiente. Contudo, uma avaliação TRL pode ser realizada em qualquer nível considerado necessário para comunicar, de maneira eficaz e precisa, a maturidade tecnológica no desenvolvimento de produto. Assim, o nível de detalhe no destrinchamento de árvore de componentes geralmente depende do desejo de uma organização e do grau de visibilidade do projeto.
Utilização da metodologia no mundo
Contudo, apesar de algumas diretrizes de TRA existentes nas agências governamentais e na indústria incluírem estratégias semelhantes para avaliar a maturidade da tecnologia, não há um processo de definição de maturidade durante o desenvolvimento de produto amplamente aceito e documentado para isso em nível mundial. Algumas organizações, como a CERTI e o NEO Empresarial, têm desenvolvido sua própria metodologia e já estão disponíveis para aplicação em seus projetos e para seus clientes.
A ferramenta desenvolvida promete facilitar a avaliação de maturidade tecnológica, visando diminuir o tempo gasto no processo do TRA, bem como promover maior alinhamento entre os diferentes stakeholders no projeto de desenvolvimento de produto. A eficácia dessa ferramenta é, contudo, dependente da responsabilidade e da confiança do preenchedor.
Como exemplo, para o TRL1 solicita-se a confirmação da existência de legislações que poderiam proibir o desenvolvimento de tecnologias críticas. Pode parecer prematuro, mas, caso descartada ou desconsiderada, os trabalhos em etapas de maior maturidade (ex. TRL6, com aplicação em ambiente significativo) correm sério risco de serem descartados, exigindo um retorno ao projeto conceitual – entre os TRLs 2 e 3. Isso significaria perder o tempo do mercado e, possivelmente, multiplicar o investimento no desenvolvimento do produto. Nessa linha, afirmamos que a identificação dos passos necessários para a conquista de maturidade são requisitos fundamentais da CERTI.
Essa aplicação de TRA tem potencial para tornar-se um guia essencial para os momentos de negociação entre as equipes de P&D+I e times de produtos, balanceando as necessidades de confiabilidade frente às estimativas de custo, risco e tempo de desenvolvimento. E esse é o tema discutido no nosso próximo artigo.
Quer saber mais sobre o assunto? Acesse nosso Guia Prático do TRL.
Fontes: API 17Q e GAO-20-48G
