Um Estudo de Caso Utilizando Mapas Cognitivos para Coleta dos Requisitos de um Projeto de Desenvolvimento Tecnológico Regina Lucia A. Santos, Carlos Henrique Hassmann, Álvaro Augusto Neto e Mischel Carmen Neyra Belderrain [email protected]; [email protected]; [email protected]; [email protected] Instituto Tecnológico de Aeronáutica-Divisão de Engenharia Mecânica Praça Mal. Eduardo Gomes, nº 50. 12228-900 - São José dos Campos – SP - BRASIL Resumo Uma parcela significativa das dificuldades encontradas no gerenciamento de projetos está relacionada com a definição adequada do escopo real e a identificação de todos os stakeholders envolvidos na sua execução. Este trabalho apresenta um estudo de caso envolvendo a utilização de um Método para Estruturação de Problemas (PSM-Problem Structuring Methods), denominado SODA (Strategic Options Development and Analysis), por intermédio da aplicação da ferramenta Mapas Cognitivos (Cognitive Mapping) visando a coleta dos requisitos necessários ao desenvolvimento de um sistema complexo. A operacionalização e validação da sistemática proposta foi realizada através da conceituação do escopo real de um projeto compreendendo a definição das necessidades, requisitos e expectativas estabelecidas pelas diversas partes interessadas no desenvolvimento tecnológico de uma turbina de aplicação aeronáutica. Palavras-chave: Coleta de requisitos, Gerenciamento do escopo, Mapas cognitivos, SODA.

Introdução Grande parte do progresso da sociedade contemporânea é realizado através da execução de projetos. O desenvolvimento de novas tecnologias, a concepção de novos dispositivos baseados em software (IoT-Internet of Things), a criação de novos medicamentos, a construção de novos empreendimentos, o lançamento de produtos e serviços inovadores e tantos outros frutos da capacidade empreendedora, do trabalho e do talento humano, resultam da execução bem sucedida de projetos. Poucas atividades são tão desafiadoras e complexas quanto a realização de projetos. Boa parte dessa complexidade resulta do fato deles possuírem uma natureza temporária e voltada para a produção de resultados únicos e singulares. Segundo Valeriano (2014), para alcançar os objetivos estratégicos de uma organização é necessário executar projetos, programas e portfólios que implementem novas formas de atuação e/ou modifiquem as formas de atuação existentes. O sucesso no gerenciamento de projetos está associado com a maneira como as necessidades estratégicas das organizações são alcançadas, de forma que elas possam obter vantagens competitivas, por intermédio da resolução de problemas e necessidades de seus clientes e stakeholders, que permitam atingir um aproveitamento eficiente das novas oportunidades de negócio. O aumento da importância do gerenciamento de projetos para o sucesso das organizações tem levado à busca por sistematizar e padronizar melhores práticas, métodos e procedimentos 1   

empregados na sua execução, tais como propõem o Guia PMBOK-Project Management Body of Knowledge (PMI, 2013a), a Norma ISO 21500 (ABNT, 2012) e o NCB – National Competence Baseline (IPMA, 2012). Segundo Morris (2013), o sucesso no gerenciamento dos projetos está associado à aplicação adequada dos processos, ferramentas e técnicas que vem sendo desenvolvidos e aperfeiçoados ao longo dos anos. Apesar do grande progresso já alcançado, algumas dificuldades encontradas na realização de projetos persistem até hoje. Uma parcela significativa está associada aos problemas encontrados para definir adequadamente o escopo real dos projetos e identificar adequadamente os stakeholders envolvidos na sua execução. As manifestações mais frequentes dessas dificuldades são o avanço das atividades de planejamento e execução do projeto sem que os seus detalhes sejam conhecidos, as dificuldades para realizar uma estimativa adequada dos aspectos relacionados com custos e prazos, ocasionados pela falta de completeza na definição do escopo, a necessidade frequente de realizar mudanças não previstas, a falta de precisão das técnicas empregadas e o pouco comprometimento das partes interessadas. Segundo Vargas (2003), “escopo de um projeto é definido como o trabalho que precisa ser desenvolvido para garantir a entrega de um determinado produto dentro de todas as funções e suas especificações”. Dentro deste contexto, o principal objetivo deste trabalho é aplicar uma ferramenta denominada mapa cognitivo, integrante da metodologia Strategic Options Development and Analysis – SODA, como principal técnica para a coleta dos diferentes tipos de requisitos envolvidos em projetos de elevada complexidade técnica. Para operacionalização e validação da técnica proposta foi realizado um estudo de caso baseado na conceituação do escopo real de um projeto compreendendo a definição das necessidades, requisitos e expectativas estabelecidas pelas diversas partes interessadas envolvidas no desenvolvimento tecnológico de uma turbina de aplicação aeronáutica. As características peculiares do produto, e a complexidade intrínseca envolvida na compatibilização de diversas características técnicas conflitantes, se constituíram em uma motivação adicional para o uso da ferramenta proposta para a definição adequada do escopo do projeto.

1. Fundamentação Teórica A fundamentação teórica deste trabalho envolve três aspectos principais: a) Os processos para gerenciamento do escopo do projeto; b) Os processos para gerenciamento das partes interessadas; c) O método para estruturação de problemas com foco na ferramenta Mapas Cognitivos da metodologia SODA (Strategic Options Development and Analysis).

2   

Nas próximas seções apresenta-se uma breve revisão dos principais aspectos envolvidos na sua aplicação ao contexto de um projeto para desenvolvimento tecnológico de uma turbina de aplicação aeronáutica. 1.1. Gerenciamento do Escopo O gerenciamento de escopo do projeto inclui os processos necessários para assegurar que o projeto inclui todo o trabalho necessário, e apenas o necessário, para terminar o projeto com sucesso. O gerenciamento de escopo do projeto está relacionado principalmente com a definição e controle do que está e do que não está incluso no projeto (PMI, 2013). Nesse contexto, o termo escopo pode-se referir ao escopo do produto que representa as características e funcionalidades que definem e caracterizam as entregas esperadas ao término do projeto, ou então, o escopo do trabalho que deve ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas. O termo escopo do projeto as vezes é abordado de modo a incluir o escopo do produto. No início do projeto, é necessário levantar um número de informações e necessidades capazes de caracterizar adequadamente os resultados esperados. Esta atividade envolve não só a descoberta das necessidades dos stakeholders, mas também, uma cuidadosa análise da organização, do domínio tecnológico envolvido e dos processos organizacionais utilizados pela organização executora do projeto. Na realização dessa atividade, destacam-se as dificuldades encontradas para compreender apropriadamente as reais necessidades das diversas partes interessadas e a negociação dos aspectos conflitantes existentes entre elas. Esses conflitos em grande parte dos casos estão relacionados com características envolvendo demandas simultâneas com relação a custos, funcionalidades, performance, prazos, qualidade e viabilidade técnica e/ou financeira. A definição do escopo envolve a análise, priorização e seleção das diversas alternativas capazes de fornecer soluções viáveis para o desenvolvimento do projeto (PMI, 2013). Ela deve detalhar as principais entregas, premissas e restrições adotadas na fase de planejamento. Ela também pode conter exclusões explícitas ao escopo estabelecido, de forma a auxiliar no gerenciamento das expectativas das partes interessadas. O principal benefício deste processo é o fornecimento de uma baseline que irá possibilitar que as demais etapas do projeto sejam conduzidas sobre um conjunto de conhecimentos previamente conhecido e bem definido. Ao longo do desenvolvimento do projeto as mudanças no escopo são inevitáveis em função da variabilidade dos inúmeros fatores envolvidos, tornando necessário estabelecer um processo para controle das mudanças. 1.2. Gerenciamento das Partes Interessadas O Gerenciamento das Partes Interessadas inclui os processos necessários para identificar todas as pessoas, grupos e organizações que podem impactar, ou serem impactados pelo projeto, analisar suas expectativas e necessidades, visando desenvolver estratégias adequadas para o seu engajamento nas decisões e execução do projeto (PMI, 2013). Essas atividades devem inicialmente identificar as pessoas, grupos e organizações que estarão ativamente envolvidas com o projeto, pois seus interesses, níveis de engajamento, influência, 3   

comprometimento, poder e interdependência devem ser conhecidos visando desenvolver um relacionamento apropriado que possibilite aumentar as possibilidades de êxito do projeto. Os requisitos indispensáveis para o atendimento das necessidades e expectativas dos diversos stakeholders envolvidos em um projeto incluem condições ou capacidades que devem estar presentes no produto, serviço ou resultado previsto. Suas características detalhadas precisam ser quantificadas e documentadas, de forma que ao final do projeto elas possam verificadas e formalmente aceitas por todos os envolvidos. Esses requisitos precisam ser obtidos, analisados e registrados com detalhes suficientes para serem incluídos na linha de base do escopo, e avaliados periodicamente para garantir que o projeto siga o curso previsto no seu planejamento. O processo de Coletar os Requisitos apresenta grande complexidade tendo em vista que normalmente envolve um conteúdo muito grande de informação que precisa ser comunicada entre diferentes atores através de diversos meios e tecnologias. Uma parcela significativa dessa comunicação se realiza por intermédio de técnicas como entrevistas, grupos de discussão, oficinas facilitadas e técnicas de criatividade em grupo envolvendo as partes interessadas. Boa parte desses métodos baseia-se na comunicação humana que geralmente se caracteriza pela ambiguidade e imprecisão. Para contornar essas características propõe-se o uso de uma ferramenta que será detalhada a seguir. 1.3. Métodos para Estruturação de Problemas Os métodos para estruturação de problemas (PSM - Problem Structuring Methods) são abordagens destinadas a lidar com níveis de incerteza, complexidade, conflitos e riscos envolvendo diversas variáveis. A prática essencial dos PSM´s é estruturada para permitir a exploração de espaços de solução, a fim de ajudar aos agentes elaborar planos igualmente estruturados para uma ação futura (Rosenhead,1996). Eles podem ser particularmente úteis quando se trabalha dentro de um contexto de coleta de requisitos de sistemas complexos envolvendo situações caracterizadas por Rosenhead & Mingers (2001), onde prevalece a existência de: a) b) c) d) e)

Múltiplos atores; Perspectivas diferentes; Interesses parcialmente conflitantes; Aspectos intangíveis significativos; e Incertezas.

O objetivo dos métodos para estruturação de problemas não é alcançar um consenso em torno de uma solução, mas conseguir que os envolvidos considerem diferentes perspectivas para a formulação do problema e cheguem a um acordo sobre os principais aspectos a serem tratados. Se este consenso puder ser alcançado, a partir dele será possível buscar soluções para o problema identificado. Segundo Vidal (2005), dentre os principais métodos utilizados para a estruturação de problemas complexos destacam-se: o SODA (Strategic Options Development and Analysis), a SSM (Soft Systems Methodology) e a SCA (Strategic Choice Approach). 4   

O SODA é um método de aplicação geral, que utiliza o mapeamento cognitivo como uma ferramenta para modelagem visando obter e registrar visões individuais de uma situação problemática, através dos diferentes pontos de vista sobre o problema. Uma combinação dos mapas cognitivos individuais provê a estrutura para a discussão em equipe (Curo, 2011). Normalmente, esses mapas são desenvolvidos em um workshop coordenado por um facilitador, que orienta os participantes no sentido de se comprometerem com a busca de uma solução para a problemática analisada e a assumirem compromissos com a sua resolução. O método SODA tem suas raízes nos campos da psicologia cognitiva e foi desenvolvido inicialmente por Eden (1988). Atualmente, além de auxiliar na estruturação de problemas, o método tem sido bastante utilizado como ferramenta de planejamento estratégico (Ackermann, 2004). Duque (2009) empregou mapas cognitivos para o gerenciamento de projetos e gestão estratégica, trabalhando com o alinhamento dos processos para o alcance de objetivos organizacionais. Este método utiliza técnicas de construção de mapas cognitivos ou causais para representar como os diferentes stakeholders percebem e compreendem a situação problemática. É possível combinar mapas individuais dos envolvidos em um mapa agregado. A agregação de mapas cognitivos individuais oferece suporte para as discussões entre os envolvidos, facilitando a tomada de decisões (Eden, 1988). Segundo Cosset & Audet (1992), os mapas cognitivos são expressões gráficas de discursos realizados por um indivíduo, ou grupos de indivíduos, com o objetivo de demonstrar graficamente o resultado da interpretação mental dos diferentes pontos de vista expressos nos discursos dos vários atores envolvidos na solução de um determinado problema. Por meio de uma abordagem cognitiva, o problema é identificado, detalhado e analisado através de um processo de interação entre o facilitador e os stakeholders, visando encontrar uma definição precisa, admitindo-se a subjetividade do grupo ou do individuo. Desta forma os mapas cognitivos podem ser utilizados para resolução de conflitos de pontos de vista na definição dos requisitos de um projeto. Trabalhos publicados por Yeo, 1993; Winter e Checkland, 2003; Winter e Smith, 2004; Winter, 2006; Winter, Smith, Cooke-Davies, et al., 2006; Winter, Smith, Morris, et al., 2006, demonstram a relevância desta abordagem. Embora não se encontrem muitos trabalhos envolvendo a aplicação de Métodos de Estruturação de Problemas na área de gerenciamento de projetos, nos últimos anos tem crescido interesse na sua aplicação. Trentim (2013) apresenta uma proposta de abordagem integrando Strategic Choice Approach (SCA) e as melhores práticas do Guia PMBOK. A abordagem proposta é aplicada a um estudo de caso e seus resultados são discutidos quanto a utilidade e validade. A abordagem “Managing Stakeholders as Clients” proposta por Trentim (2013) consolida ferramentas e técnicas que sistematizam sua aplicação e a associam com outras áreas de conhecimento, tais como tomada de decisão, engenharia de sistemas e métodos de estruturação de problemas. Em 2012, José Finocchio publicou o Project Model Canvas (2012) baseado no princípios do Business Model Canvas, criado por Alexandre Osterwalder e Yves Pgneur (2010). Trata-se de 5   

um modelo visual e intuitivo envolvendo a definição das principais características de um projeto, representadas pelo TAP-Termo de Abertura do Projeto (PMI, 2013) utilizando apenas uma folha de papel e papéis auto-adesivos. Nesta técnica os campos são facilmente visualizados e preenchidos de forma colaborativa com utilização de papéis adesivos de diversos tamanhos e cores visando facilitar as anotações sobre as informações iniciais sobre o projeto. Assim como os mapas cognitivos o modelo baseia-se em alguns princípios na neurociência e também neuroliderança (Mei, 2015). O modelo Project Model Canvas é aplicado apenas na fase de iniciação e planejamento preliminar do projeto, não atendendo as etapas de execução, controle, e encerramento dos projetos. Para suprir essas deficiências Mei (2013), criou o PM Mind Map que além de abordar o planejamento de projetos, também enfoca a sua execução e controle. A utilização de Métodos de Estruturação de Problemas no gerenciamento de projetos oferece uma visão holística e abrangente de cada projeto, considerando suas particularidades e diferentes contextos. Eles são particularmente úteis em projetos envolvendo decisões complexas e a presença de múltiplos objetivos, avaliados sobre diferentes perspectivas (Clemen e Reilly, 2001; Rosenhead e Mingers, 2001; Winter e Checkland, 2003), conforme o estudo de caso que será apresentado a seguir.

2. Metodologia Para operacionalização e validação da sistemática proposta neste trabalho foi realizado um estudo de caso baseado na conceituação do escopo real de um projeto compreendendo a definição das necessidades, requisitos e expectativas estabelecidas pelas diversas partes interessadas no desenvolvimento tecnológico de uma turbina de aplicação aeronáutica As organizações envolvidas não foram identificadas por razões de sigilo comercial. O estudo de caso envolve o desenvolvimento tecnológico de um sistema de propulsão complexo envolvendo a criação, produção, operação e manutenção de um turbojato que emprega o ciclo termodinâmico de Brayton. O sistema é composto de três partes que são o compressor, a câmara de combustão e a turbina propriamente dita. Tendo em vista as peculiaridades do sistema a ser desenvolvido e de algumas características técnicas inovadoras que se pretende implementar, muitos de seus requisitos são pouco conhecidos até mesmo por boa parte dos stakeholders. No desenvolvimento do estudo de caso foram seguidos os processos de iniciação propostos pelo Guia PMBOK (2013) e elaborado um Termo de Abertura do Projeto, onde constam informações iniciais do cliente, os objetivos do projeto, sua justificativa, uma descrição dos produtos, serviços e resultados esperados, definido um gerente do projeto e registradas as partes interessadas, bem como o seu nível de envolvimento. Neste contexto, o PMBOK (2013) sugere que antes de iniciar o processo de coleta dos requisitos seja feita uma análise detalhada dessas informações, de forma a criar uma base de conhecimentos que será empregada na escolha adequada dos stakeholders e na estruturação das perguntas que deverão ser respondidas nas entrevistas com os entrevistados. A próxima etapa executada no estudo de caso desenvolvido envolveu a entrevista dos stakeholders relacionados na Tabela 1. Sua escolha foi feita com base nos parâmetros 6   

organizacionais da empresa e no entendimento que estes refletiriam a opinião de um grupo de outros stakeholders envolvidos no projeto. Dada a sua importância e grau de conhecimento, presume-se que, em tese, eles representam a visão, experiência e conhecimento da empresa obtida na realização de projetos similares. Tabela 1 – Stakeholders Entrevistados Stakeholders

Representação no Projeto

Gerente de Projeto

Reflete a opinião do cliente e equipe de projeto

Coordenador de Projeto

Coordena o projeto teórico do equipamento conforme orientação do gerente de projeto

Coordenador de Execução

Coordena a execução do projeto. Verifica, por exemplo, se o executor está seguindo as diretrizes do projeto.

Executor de montagem e manutenção

É o executor e efetivamente monta o equipamento e realiza a manutenção..

A próxima etapa envolveu a aplicação da metodologia SODA para construção dos Mapas Cognitivos. A Figura 1 apresenta de maneira esquemática as etapas envolvidas na sua aplicação, que podem ser representadas resumidamente pela: a) Construção dos mapas cognitivos individuais; b) Agregação dos mapas cognitivos individuais; c) Congregação dos mapas cognitivos e, d) Análise. A construção dos mapas cognitivos depende de dois fatores: a) uma abordagem inicial por parte do facilitador demonstrando empatia e; b) o estabelecimento de um processo de negociação entre os atores envolvidos.

Figura 1 – Aplicação Metodologia SODA (Barros, 2012) 7   

Dando sequencia a abordagem proposta foram entrevistados individualmente os stakeholders relacionados na Tabela 1. As entrevistas foram espontâneas permitindo ao entrevistado expor com tranquilidade os seus pontos de vista e as informações relevantes que detinham sobre o problema abordado. Para não se tornar cansativo, esse processo de extração do conhecimento não ultrapassou mais que sessenta minutos em cada reunião. As entrevistas foram realizadas no local de trabalho de cada entrevistado de modo que eles pudessem demonstrar quais eram suas condições de trabalho, ferramentas utilizadas, entre outras particularidades pertinentes ao projeto em questão. Por meio desta abordagem as ideias e concepções individuais puderam tomar forma por intermédio das explicações fornecidas durante a entrevista. Procurou-se realizar perguntas objetivas e que questionassem cada entrevistado sobre quais os requisitos ele achava prioritários para um projeto de turbojato, independente da utilização do mesmo, tomando como base a experiência profissional de cada um. Os quatro entrevistados falaram sobre seus valores, experiências e embora a visão de cada um deles sobre quais requisitos eram relevantes fossem diferenciadas, alguns pontos convergiram em requisitos comuns, muitas vezes expressos de maneiras diferentes em função da formação profissional de cada um. Todas as informações foram anotadas preservando a linguagem do autor. Cada entrevistado foi orientado pelo facilitador a expor os pontos que achassem relevantes com muita objetividade evitando ambiguidades e confusões. Após as entrevistas houve a construção dos mapas utilizando o software IHMC CmapTools, desenvolvido pelo Institute for Human Machine Cognition da University of West Florida. Este produto apresenta razoável flexibilidade permitindo que módulos sejam instalados à medida em que suas funcionalidades sejam requeridas ao longo da elaboração dos mapas. O sistema também permite exportação dos mapas criados em formato XML/XTM, o que possibilita a utilização dos mapas em outros ambientes e ferramentas. O software ainda disponibiliza recursos para formatação dos mapas, permitindo que eles sejam utilizados como imagens, vídeos, textos e até mesmo como outros mapas para detalhamento do conhecimento. Após a criação dos mapas individuais, eles foram apresentados aos respectivos entrevistados visando sua validação e confirmação dos conceitos e da hierarquia estabelecida. Neste ponto, a visualização gráfica proporcionada pelo mapa demonstrou ser um grande auxilio para que o entrevistado obtivesse uma percepção global de seu próprio pensamento. O próximo passo foi o agrupamento dos mapas individuais em um só mapa denominado mapa agregado. Essa agregação foi realizada pelo facilitador que criou uma lista com os conceitos relacionados em cada um dos mapas individuais e os classificou por assuntos relacionados que foram denominados como clusters. Desta maneira foram agrupados os conceitos similares pertencentes a cada cluster e escolhido um conceito que melhor exprimisse os seus correspondentes. Os outros conceitos foram eliminados e reestabelecidas as ligações formando o mapa agregado. Esse mapa agregado, assim como anteriormente feito, foi apresentado aos stakeholders entrevistados para sua validação e verificação.

8   

Após as alterações sugeridas o mapa validado passou a ser denominado como mapa congregado e os conceitos nele presentes, denominados construtos, que representam os conceitos consolidados pela equipe. A próxima etapa da metodologia SODA envolveu a análise do mapa congregado e a identificação de 6 clusters que foram representados por diferentes cores visando facilitar a identificação visual. Esta estratégia possibilitou aos stackholders entrevistados entender melhor o mapa. Os clusters identificados foram: planejamento, infraestrutura e ferramental, requisitos técnicos, requisitos operacionais, requisitos ambientais e sustentabilidade ambiental. A densidade (quociente entre o número de conectores (47) e número de construtos (43) foi de 1,09. O número está próximo ao recomendado pelos autores do método, que está entre 1,15 e 1,2. Segundo Curo (2011), esta densidade representa o fato que a modelagem do problema não apresenta alta complexidade cognitiva. Na etapa posterior foi feita a análise de domínio, que visa identificar os construtos que tem maior influência sobre o problema. Para isso calculou-se o grau de domínio de cada construto representado pela soma dos conectores que entram e que saem de cada um deles. Os construtos “planejamento”, “requisitos operacionais” e “requisitos técnicos” foram os dominantes. Esta análise pode ser visualizada no mapa cognitivo congregado. Um outro aspecto importante para a análise do problema envolve o grau de explosão e implosão. O grau de explosão indica os construtos que tem mais construtos saindo, ou seja, que são causa de muitos efeitos e que se forem bem trabalhados terão um grande impacto positivo. No presente estudo identificou-se o construto “requisitos operacionais”como o de maior importância. O grau de implosão, por sua vez, indica os construtos que tem alto prestígio, pois são afetados por diversos outros construtos. O construto com maior grau de implosão sob este aspecto foi o “ponto ótimo”.

3. Resultados Os resultados do presente trabalho são apresentados através de 4 mapas cognitivos individuais e 1 mapa cognitivo congregado. Na Figura 2 pode ser visualizado o mapa individual do gerente de projeto, o qual por ter contato com toda documentação inicial do projeto e contato direto com cliente representa também os requisitos e expectativas deste para o projeto. Os mapas individuais dos outros 3 stakeholders apresentados na Tabela 1, juntamente com o desse do gerente foram agregados e validados conforme metodologia formando o mapa cognitivo congregado, que é apresentado na Figura 3. Esses mapas possibilitaram a coleta dos requisitos pelos stakeholders para o projeto de uma turbina para uma aplicação específica. Por se tratar de um projeto de desenvolvimento tecnológico, esse processo e consequentemente a correta definição do escopo do projeto apresentou um elevado grau de dificuldade tendo em vista que, em função do contexto inovador do projeto, os stakeholders envolvidos não dispunham de todo o conhecimento sobre as necessidades para desenvolver o projeto.

9   

Figura 2 – Mapa Cognitivo Individual do Gerente do Projeto Na Figura 3 pode-se visualizar o mapa congregado com seus 6 clusters apresentados em diferentes cores, que representam os requisitos considerados importantes para o projeto. o detalhamento dos clusters são melhor detalhados na Tabela 2.

Figura 3 – Mapa Cognitivo Congregado 10   

Tabela 2 – Requisitos para Projeto da Turbina Cluster

Requisitos Presentes Gestão do Programa WBS/WBE Análise de Risco CFF/Viabilidade

Planejamento

Especificação de Clientes Documentação Adequada Recursos Humanos Adequados EPI (equipamento de proteção individual) Ferramentas de Qualidade

Infraestrutura e Ferramental

Ferramental Específico Área Adequada Temperatura Adequada Empuxo Massa e CG

Requisitos Técnicos Momento de Inércia Pressões Internas Temperatura de Operação Menor Quantidade de peças Acessos Internos Facilidade de Montagem Manutenção Confiabilidade Interface com Produto Final Requisitos Operacionais

Objetivo Funcional Limites Operacionais Tempo de Vida Tempo de Vida Estocado Consumo Combustível Peso Reduzido Ponto ótimo

Custo Reduzido Qualidade Material

Formas de Produção Sustentabilidade Ambiental

Tipo de Materiais Tipo de Combustíveis Resistência a umidade

Requisitos Ambientais

Resistência térmica Resistência a Vibrações

11   

A representação gráfica fornecida pelo mapa cognitivo proporcionou aos stakeholders envolvidos neste projeto o entendimento e visualização das necessidades reais e mais significativas para a sua realização com sucesso. A partir dela foi possível aprofundar os conhecimentos das características técnicas e dos requisitos do projeto e do produto. O principal benefício alcançado pela aplicação da metodologia utilizada foi o fornecimento da base de conhecimentos que possibilita os elementos necessários para o aprofundamento da definição do escopo do projeto e do produto, bem como, dos elementos principais para o seu gerenciamento.

4. Conclusões O sucesso dos projetos é diretamente influenciado pelo envolvimento ativo dos stakeholders na descoberta, decomposição e sistematização das necessidades, características e funcionalidades esperadas do produto em requisitos técnicos que devem ser atendidos ao final do projeto. Em projetos de desenvolvimento tecnológico e inovação, ou mesmo projetos com escopo que envolva grande grau de incerteza, esse processo atinge um nível de abstração muito grande, tornando a tarefa bastante complexa. Neste contexto, a aplicação dos mapas cognitivos como ferramenta da metodologia SODA vem contribuir de maneira decisiva, pois auxilia os stakeholders envolvidos a pensarem criativamente, favorecendo a visualização através dos mapas e facilitam a negociação entre diferentes opiniões relacionadas muitas vezes aos mesmos contextos e requisitos. A fase de análise da metodologia utilizada também vem a contribuir positivamente pois permite identificar os requisitos que tem maior influência sobre o sucesso do projeto, de forma a permitir o desenvolvimento de uma abordagem mais apropriada ao alcance das expectativas. A sistematização obtida através da sua aplicação também possibilita uma simplificação das tarefas envolvidas, pois facilita a identificação dos requisitos que, se incluídos adequadamente no escopo do projeto, irão possibilitar o atendimento de vários requisitos. Um aspecto importante que pode ser observado na utilização da técnica é que a disposição gráfica dos requisitos facilita posteriormente a criação da EAP - Estrutura Analítica do Projeto, simplificando o processo de subdivisão e estruturação hierárquica das entregas do projeto. Neste contexto, pode-se afirmar que a metodologia apresentada mostrou-se de grande valia para a definição correta do escopo do projeto e, principalmente, do produto. Como uma boa definição do escopo é um aspecto primordial para o sucesso dos projetos, deve-se ressaltar a importância da sistemática apresentada no sentido de criar uma base técnica que possibilite um bom gerenciamento dos aspectos relacionados com tempo, custo e qualidade nos projetos, bem como das outras áreas de conhecimento envolvidas.

Referências ACKERMANN, F.; EDEN, C.; CROPPER, S. Getting Started with Cognitive Mapping. 2004. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 21500: Orientações sobre Gerenciamento de Projetos. Rio de Janeiro, 2012.

12   

BARROS, P.R.S. Multimetodologia para estruturação e reconhecimento de melhorias aplicada a programa de logística reversa de alimentos. Tese de mestrado, Área de Produção – Instituto Tecnológico de Aeronáutica, São José dos Campos, 2012. BROWN, KAREN, HYER, NANCY LEA, Mind maps as a WBS Development Tool, IN:Project Management Institute Annual Seminars & Symposium. Nov, 1 - 10, Nashiville. Procedings…Nashville, TN, USA, 2001. CURO, R. S.G. Pensamento sistêmico aplicado à problemática da produção científica em uma instituição de ensino superior Peru. Dissertação (mestrado em Engenharia Aeronáutica e Mecânica– Instituto Tecnológico de Aeronáutica, São José dos Campos, 2011. CLEMEN, R. T.; REILLY, T. Making hard decisions with decisions tools. ISBN: 0-53436597-3, 2001. COSSETTE, P., AUDET, M. Mapping of an Idiosyncratic Schema. Journal of Management Studies. 1992. v. 29, n. 3, pp. 325-348. DUQUE, W.S. Gerenciamento de Projetos e Gestão Estratégica: Um alinhamento de processos para a realização de objetivos organizacionais. Dissertação Mestrado, Programa de Pós-graduação em Administração de Empresas da Fundação Instituto Capixaba de Pesquisas em Contabilidade, Economia e Finanças (FUCAPE), 2009. EDEN, C.; HUXHAM, C. Action – oriented strategic management. Journal of the Operational Research Society 39, 889-899, 1988. INTERNATIONAL PROJECT MANAGEMENT ASSOCIATION. NCB - National Competence Baseline, Version 3.0. Nijkerk, 2012. MEI, P. PM Mind Map – A gestão descomplicada de projetos, Rio de Janeiro: Brasport, 2015. MORRIS, P. Reconstructing Project Management Reprised: A Knowledge Perspective. Project Management Journal, v. 44, n. 5, p. 6-23, 2013. ISSN 1938-9507. PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK Guide). 5th ed. Newtown Square, PA: Project Management Institute, 2013. ROSENHEAD, J. What is the problem? An introduction to problem structuring methods. Interfaces, v. 6, 1996. ROSENHEAD, J.; MINGERS, J. Rational analysis for a problematic world revisited. John Wiley and Sons, 2001. TRENTIM, M. H. Integrando Strategic Choice Approach ao gerenciamento de projetos: Um estudo de caso. Tese de Mestrado, Área de Produção – Instituto Tecnológico de Aeronáutica, São José dos Campos, 2013. ______. Managing Stakeholders as Clients: Sponsorship, Partnership, Leadership, and Citizenship. Newton Square: Project Management Institute, 2013. ISBN 9781935589655. 13   

VARGAS, RICARDO VIANA, “Gerenciamento de Projetos: estabelecendo diferenciais competitivos”. 5ª edição, Rio de Janeiro: Brasport, 2003. VALERIANO, Dalton. Gerenciamento Estratégico de Projetos: governança, portfólio, programa e partes interessadas. 1 ed. Rio de Janeiro: Elsevier, 2014. VIDAL, R. V. V. Operational Research: a multidisciplinary field. Pesquisa Operacional, v.26, n.1, p.69-90, jan./abr. 2006. WINTER, M.; CHECKLAND, P. Soft systems: a fresh perspective for project management. Proceedings of the ICE-Civil Engineering, 2003, Ice Virtual Library. p.187-192. WINTER, M.; SMITH, C. Rethinking project management. EPSRC Network, v. 2006, 2004. WINTER, M. Problem structuring in project management: an application of soft systems methodology (SSM). Journal of the Operational Research Society, v. 57, n. 7, p. 802-812, 2006. ISSN 0160-5682. WINTER, M. et al. The importance of ‘process’ in rethinking project management: the story of a UK government-funded research network. International Journal of Project Management, v. 24, n. 8, p. 650-662, 2006. ISSN 0263-7863. WINTER, M. et al. Directions for future research in project management: the main findings of a UK government-funded research network. International Journal of Project Management, v. 24, n. 8, p. 638-649, 2006. ISSN 0263-7863. YEO, K. Systems thinking and project management—time to reunite. International journal of project management, v. 11, n. 2, p. 111-117, 1993. ISSN 0263-7863..

14