Em 1994, o exército norte-americano começou a desenvolver o Crusader – um sistema de artilharia de campo mais leve e versátil para substituir o sistema Paladin, mas mudou seus requisitos de projeto no ano 2000. Porém, em 2002, o GAO (U.S. Government Accountability Office) notou que o exército havia superestimado a maturidade de tecnologias críticas e colocou em risco muito recurso financeiro, atrasos de cronograma e déficits de desempenho, comprometendo prematuramente o programa do produto em desenvolvimento.
O caso de estudo acima, descrito pelo “Technology Readiness Assessment (TRA) Guide – GAO-20-48G”, elucida o embate mais comum de qualquer time de P&D+I: custos vs. confiabilidade. Um gestor de desenvolvimento se vê frequentemente na “zona de guerra” entre seus clientes e equipe, cada qual com seus requisitos de projeto, esforçando-se para balancear investimento, tempo de mercado, segurança e riscos.
Isso acontece porque cada um dos envolvidos no projeto enxerga uma parte do problema. Especialmente em projetos complexos, que exigem o desenvolvimento de maturidade tecnológica até o último nível de TRL, é quase impossível seguir sua execução se não houver um método claro que defina todos os requisitos de projeto e evidencie as discussões necessárias para decisões do produto.
Por outro lado, é correto afirmar que a escala TRL não é única e universal: cada setor e aplicação tem suas peculiaridades que devem ser respeitadas e consideradas. Como descrito no artigo que fala sobre framework de confiabilidade em projetos da NASA, existem variações para incluir desenvolvimento em software, hardware e manufatura, bem como a alternativa de 8 níveis – em vez de 9, como apresentado, além das diferentes definições de cada órgão de desenvolvimento, como DoD (Department of Defense), DoE (Department of Energy) e GAO.
A própria API-17Q sugere que “cada empresa deve desenvolver seu próprio método [de avaliação de maturidade de tecnologia ou TRA]”. Mais do que isso, o GAO indica que se deve rever os conceitos e métricas de TRL que serão usados como padrão no início de cada avaliação de maturidade.
Por esse motivo, manter todos os envolvidos alinhados em relação aos requisitos de projeto na execução e nos resultados que devem ser obtidos é essencial para garantir que se entregará o valor esperado ao cliente ao final do projeto. Porém, executar essa retificação não é fácil e é pensando nisso que a CERTI, com apoio do NEO Empresarial, desenvolveu um plano de aplicação do TRA. O objetivo é fornecer regras de uso que explicite todas as informações críticas, gerando discussões e detalhamentos no decorrer do projeto.
Modo de uso do TRA
A primeira regra de uma boa comunicação é eliminar qualquer informação ambígua. Por isso, é necessário alinhar exatamente quais pesquisas, testes e documentações serão realizadas durante a execução do projeto. Para tanto, o GAO sugere o uso de um checklist de entregas: um questionário que confirme tudo o que deve ser entregue ao cliente. Assim, se o cliente demanda a elevação do TRL1 (princípios básicos observados e reportados) ao TRL4 (validação funcional dos componentes em ambiente de laboratório), ele deve saber quais são os experimentos que comprovam que o produto teve a efetiva verificação funcional em ambiente laboratorial.
No artigo sobre confiabilidade para projetos, é possível perceber o quanto as definições de TRL são abstratas e abertas à interpretação. Por isso, o desenvolvimento de um checklist eficiente e objetivo é um dos focos da metodologia. A tabela abaixo ilustra parte das perguntas que a CERTI utiliza em sua ferramenta para comprovar o TRL4.
| Checklist do TRL4 | Resposta |
| Foram estabelecidos requisitos de desempenho do teste de laboratório, derivados dos requisitos do produto? |  |
| Foram iniciados os estudos de integração dos componentes ao produto final? | |
| Foram testados subsistemas compostos de múltiplos componentes em escala de laboratório por meio de experimentos práticos ou simuladores? |  |
| Foram utilizadas modelagem e simulação ou experimentos práticos para simular alguns componentes e interfaces entre componentes? | |
Finalizada a lista de entregáveis de cada TRL deve-se, então, enviá-la ao cliente e ao gerente do projeto antes da assinatura do contrato ou, no caso de equipes de P&D+I internas, do início do desenvolvimento. É quase certo que uma discussão será desencadeada a partir da leitura dessa lista, e é importante que ela ocorra. Em conjunto, o cliente e o gerente devem rever se todas essas etapas fazem sentido para o projeto em questão, bem como alterar métodos de avaliação na medida necessária. Dessa forma, quando o negócio for fechado, ambos os lados saberão, exatamente, o que esperar da continuidade do projeto.
Feito isso, as entregas e, principalmente, as transições de TRL devem ser adicionadas ao cronograma de desenvolvimento, explicitando seus prazos. Agora, além de saber o que esperar, o cliente também pode saber quando será entregue. Essa etapa é crítica para o gerente: o embate de custos vs. confiabilidade retorna. Usualmente, é nesse momento que o cliente deve reclamar de todas as atividades elencadas e propor possíveis alterações em seu desenvolvimento.
Requisitos de projeto no TRA
O gerente, então, deve tomar uma decisão: tendo em vista todos os requisitos de projeto, os riscos de não se executar certos testes e a severidade de uma falha, ele deve escolher o que pode e o que não pode ser rejeitado. Não há resposta objetiva e categórica para essa questão e a experiência do gerente é que fará a diferença. Uma coisa, porém, é certa: na dúvida, seja cauteloso.
Essas questões são continuamente revisitadas pela indústria aeronáutica, por exemplo. Imagine o longo desenvolvimento do projeto de um avião, que procura diminuir sua massa para redução do consumo de combustível. Na etapa de transição do TRL 5 ao TRL 6, um ponto que talvez pareça burlável é modificação no ambiente de laboratório para torná-lo um ambiente relevante, deixando-o apto a testes, já que o custo dessa etapa costuma ser bastante elevado. Nesse caso, por decisão do cliente, busca-se fazer o mínimo de modificações possível e são nesses momentos que a falha encontra uma brecha.
Você já imaginou que a troca de material de algumas peças pode ter aumentado a severidade dos danos por raios no avião? Um artigo da BBC mostra alguns dos exaustivos testes em ambiente relevante aos quais uma aeronave é entregue em níveis medianos de TRL. Nesse sentido, os maiores competidores desse mercado desenvolvem, inclusive em conjunto, plataformas muito bem instrumentadas de testes em ambientes relevantes, permitindo um desenvolvimento mais maduro. Esse é o caso dos projetos Clean Sky, NextGen e NRC’s Aerospace Research Centre.
E agora, quais os próximos passos?
Requisitos de projeto definidos e iniciado o desenvolvimento, a equipe terá o trabalho de transformar as entregas desse checklist em atividades, sejam elas pesquisas, desenhos ou cotações. Se possível, recomenda-se que as etapas sejam marcadas como concluídas no checklist quando são efetivamente completadas. Em não havendo essa possibilidade, as datas de execução das avaliações devem ser adicionadas ao cronograma.
É importante salientar que cada avaliação de TRL é válida apenas para aquele sistema – isso inclui conjunto de componentes, disposição deles e ambiente ao qual foi imposto. Assim, se uma nova solução foi adicionada ao projeto, possivelmente uma tecnologia diferente foi adicionada também. Por isso é necessária uma nova avaliação a cada modificação, incluindo essas alterações na confiabilidade do produto.
Além disso, de tempos em tempos, as evidências científicas e os avanços devem ser mostrados ao cliente, de modo a mantê-lo alinhado quanto ao andamento do plano de maturidade. Isso evita qualquer desalinhamento na entrega do produto final.
Enfim, na finalização do desenvolvimento, é importante que todas as evidências científicas que comprovem o funcionamento do produto sejam muito bem documentadas. Tal gestão do conhecimento fornece, inclusive, uma proteção contratual para o time de desenvolvimento: se todas as decisões foram documentadas e validadas com o cliente, mostrando o cumprimento de todos os requisitos de projeto, a equipe tem todas as ferramentas para argumentar a seu favor.
Os anexos de evidências de experimentos devem ser, portanto, suficientes para explicitar toda a carga teórica de confiabilidade do produto. Em complemento, as avaliações constantes são base para a construção de discussões de alinhamento frequentes entre cliente e time de desenvolvimento. Dessa forma, é muito mais seguro tomar decisões que otimizem a balança custo-confiabilidade.
Assim, é importante seguir alguns passos para equilibrar custos e confiabilidade em um desenvolvimento assertivo de projeto, não esquecendo de:
- Elaborar um checklist de entregas para cada TRL (ou use o modelo da CERTI);
- Avaliar as entregas junto ao seu cliente e incorporar as transições de TRL ao seu cronograma;
- Decidir quais são os pontos do desenvolvimento que você pode abrir mão pelo seu cliente e com o seu cliente;
- Detalhar as entregas em atividades para sua equipe;
- Fazer avaliações de TRL periódicas, armazenando evidências científicas e comunicando o andamento ao cliente;
- E, na conclusão do projeto, revisar o checklist e armazene todas as provas de desenvolvimento.
A CERTI, em parceria com o NEO Empresarial, desenvolveu esse framework para garantir a melhor solução em evolução da maturidade tecnológica para sua empresa. Com base em documentos da NASA, GAO, DoD, DoE, API e DNV, foi criada uma ferramenta específica para o modelo de P&D+I brasileiro, que atuará como suporte para a execução dos projetos.
Quer saber mais sobre o assunto? Acesse nosso Guia Prático do TRL.
Fontes: API 17Q e GAO-20-48G
