Resumo Executivo

Sthefane Neli de Aguiar Bento; Charles Gomes da Silva

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Este estudo analisou os fatores determinantes na abertura de tickets em projetos de uma empresa multinacional do setor alimentício. Os objetivos específicos foram: realizar uma análise descritiva para identificar categorias com maior incidência de tickets; verificar associações estatísticas entre a abertura de tickets e variáveis dos projetos; e desenvolver um modelo preditivo com o algoritmo de aprendizado de máquina supervisionado Random Forest para estimar a probabilidade de ocorrência de tickets. A pesquisa utiliza dados da equipe de gestão de projetos, responsável pelo desenvolvimento de ferramentas digitais de suporte, visando otimizar a alocação de recursos e a qualidade das entregas.

A gestão de projetos é a aplicação de conhecimentos, habilidades e técnicas para atender aos requisitos de um projeto (Project Management Institute, 2017). Projetos são esforços temporários que dependem da gestão de escopo e cronograma, sendo a administração do tempo essencial para a eficiência operacional (Kerzner & Saladis, 2017). Contudo, a gestão transcende a entrega pontual, pois a manutenção e as melhorias pós-conclusão são vitais para prolongar a vida útil e a eficácia de um projeto.

O sucesso organizacional está ligado à qualidade da gestão de processos operacionais; a flexibilidade para melhorias contínuas é indispensável (Mulcahy, 2018). Fatores como mudanças de mercado e novas necessidades dos usuários impactam a eficácia de projetos finalizados, exigindo adaptações para otimizar o desempenho (Drucker, 1954). Nesse cenário, equipes de desenvolvimento precisam de um sistema robusto para gerenciar problemas e melhorias identificados após a conclusão, garantindo que os produtos mantenham altos padrões de qualidade e relevância.

O termo “ticket” é utilizado para registrar solicitações de serviço ou incidentes. Conforme as práticas da ITIL (Information Technology Infrastructure Library), um ticket representa um problema a ser resolvido, permitindo o monitoramento sistemático de questões pós-projeto (ITIL, 2019). A adoção de um sistema de gerenciamento de tickets promove a comunicação, aumenta a transparência e a rastreabilidade, aprimorando a eficiência na resposta aos problemas identificados (Verma & Raghavan, 2017).

A frequência de tickets abertos é um indicador da saúde operacional de uma equipe. Um volume elevado pode sinalizar problemas recorrentes que impactam o desempenho, a alocação de recursos e a satisfação do cliente. A redução de incidentes é, portanto, um objetivo crucial para a qualidade do serviço. Uma gestão eficaz de tickets libera as equipes para tarefas mais estratégicas, e a capacidade de minimizar a necessidade de abertura de tickets é um sinal de maturidade organizacional (Kerzner, 2017). Assim, a análise dos fatores que influenciam essa abertura é fundamental para a melhoria contínua da gestão de projetos.

Trata-se de uma pesquisa aplicada, com objetivos descritivos e explicativos, conduzida como estudo de caso com dados documentais e aprendizado de máquina. Os dados foram obtidos da equipe de projetos da empresa, coletados desde 2022 e armazenados em uma lista do SharePoint alimentada pela ferramenta interna de tickets. Cada registro corresponde a um ticket. Os dados foram rigorosamente anonimizados para proteger a confidencialidade, em conformidade com a Lei Geral de Proteção de Dados (Brasil, 2018), atribuindo codinomes para impossibilitar a identificação de pessoas.

Após a anonimização, aplicou-se o processo de ETL (Extract, Transform, Load), fundamental para a integração de dados (Inmon, 2005). O processo envolveu a extração de dados de duas fontes, sua transformação e carregamento em um ambiente de análise. Integrou-se a tabela fato (ocorrências de tickets) com a tabela dimensão (informações de projetos) no ambiente Spyder, utilizando Python e a função merge do pacote pandas, com o ID do projeto como chave. Subsequentemente, uma etapa de limpeza de dados tratou valores ausentes e duplicatas, passo crucial para evitar conclusões errôneas (Rahm & Do, 2000).

Com os dados preparados, realizou-se uma Análise Exploratória de Dados (EDA) para obter um entendimento aprofundado dos padrões. A EDA usou Python (Spyder) com as bibliotecas pandas, matplotlib. pyplot, seaborn e plotly. express. Adicionalmente, para explorar a relação entre a abertura de tickets e variáveis categóricas, utilizou-se o teste de independência do qui-quadrado (χ²), adequado para avaliar associações entre variáveis categóricas (Fávero & Belfiore, 2017). O processo incluiu a construção de tabelas de contingência, o cálculo da estatística do teste e a análise dos resíduos padronizados ajustados.

Para a modelagem preditiva, utilizou-se o algoritmo de aprendizado de máquina supervisionado Random Forest para identificar as variáveis de maior influência na ocorrência de tickets e estimar sua probabilidade. O algoritmo foi escolhido por sua robustez com dados categóricos, capacidade de lidar com classes desbalanceadas e de capturar interações complexas sem pressupostos de linearidade (Breiman, 2001; Biau & Scornet, 2015). O modelo também fornece métricas de importância das variáveis, auxiliando na identificação dos atributos de maior impacto (Au, 2018). Para sua aplicação, a base de dados foi transformada para conter uma linha por projeto, com uma variável alvo binária (1 para existência de ticket, 0 para ausência). O modelo foi configurado com 100 árvores, profundidade máxima de 5 e mínimo de 10 observações por folha. Para o desbalanceamento das classes, utilizou-se o parâmetro class_weight=”balanced”.

A Análise Exploratória de Dados revelou que os projetos dos tipos 1 e 2 são responsáveis pela maioria dos tickets. A análise do tipo de solicitação indicou que a categoria “issue” (problema) é a mais recorrente. Um gráfico de Pareto demonstrou que 80% de todos os tickets se concentram em cinco motivos: erro na interface (desenvolvedor), falta de conhecimento do usuário, erro na formulação das regras de negócio (desenvolvedor), problema sistêmico da plataforma e atualização incorreta da base de dados (usuário). Isso sugere que ações focadas nesses pontos podem reduzir significativamente o volume de tickets.

A distribuição de tickets por área de negócio também se mostrou concentrada. A área de “Química” destacou-se com o maior volume, seguida por “Psicologia” e “Nutrição”, enquanto áreas como “Enfermagem” e “Tecnologia da Informação” registraram baixa frequência. Essa disparidade pode indicar diferenças na complexidade dos projetos ou na adesão dos usuários. Outro achado foi a distribuição desigual de tickets entre desenvolvedores: um gráfico de Pareto revelou que 80% dos tickets estão concentrados em apenas 15 dos 63 desenvolvedores. Essa concentração pode indicar alocação em projetos mais complexos, dificuldades técnicas individuais ou má definição de escopo, resultando em sobrecarga para uma minoria.

As análises de associação com o teste do qui-quadrado confirmaram relações significativas. A primeira análise, cruzando abertura de tickets com o status da documentação, mostrou que o status “Complete” associou-se positivamente à abertura de tickets, enquanto “Missing” e “Not Applicable” se correlacionaram com a não abertura. Este resultado contraintuitivo sugere que projetos com documentação completa podem ser os de maior engajamento ou criticidade, levando a um escrutínio mais detalhado e, consequentemente, a mais tickets, ou que o processo de documentação não está prevenindo problemas eficazmente.

Uma segunda análise investigou a relação entre o status da entrega e a abertura de tickets. Identificou-se que projetos com status “Near to Deadline” já possuíam tickets, indicando um desvio no processo, com a gestão de mudanças ocorrendo antes da finalização formal. Além disso, o status “On Time” demonstrou associação significativa com a abertura de tickets, enquanto “Delayed” apresentou associação com a não abertura. Este padrão pode reforçar a hipótese de que projetos entregues no prazo são mais utilizados e monitorados, enquanto os atrasados podem ter menor engajamento dos usuários.

O modelo Random Forest obteve bom desempenho na previsão de tickets, alcançando uma Área sob a Curva ROC (AUC) de 0,81, o que indica excelente capacidade de discriminação. A acurácia global foi de 69%. A matriz de confusão revelou um desempenho assimétrico. Para a classe “não” (sem ticket), o modelo teve alta precisão (0,89) mas baixo recall (0,60), significando que, ao prever ausência de tickets, tende a acertar, mas não captura todos os casos reais. Em contrapartida, para a classe “sim” (com ticket), o modelo alcançou um recall elevado (0,85), identificando a maioria dos projetos que tiveram tickets, embora com precisão menor (0,52), o que implica alguns falsos positivos.

O desempenho do modelo é valioso na prática, pois seu alto recall para a classe “sim” o torna uma ferramenta eficaz para identificar projetos com maior risco de gerar tickets, permitindo à gestão priorizar recursos de forma preventiva. O uso do parâmetro class_weight=”balanced” foi fundamental para este resultado, compensando o desbalanceamento na base de dados. A análise da importância das variáveis revelou que a área “Venezuela” foi o fator de maior influência na abertura de tickets, seguida pelo status de documentação “Complete” e pela área “Brasil”. Este achado direciona a atenção para fatores geográficos ou de mercado que podem impactar os projetos.

O modelo também identificou combinações de variáveis que aumentam a probabilidade de tickets. A área “Venezuela” esteve presente em todas as dez combinações de maior risco, reforçando sua importância. O status de documentação “Complete” também apareceu com frequência. Variáveis como a linha de serviço “Sustentabilidade” e o status de entrega “On time”, menos importantes individualmente, tornaram-se relevantes quando combinadas com outros fatores. Isso demonstra a capacidade do modelo de capturar interações complexas e a necessidade de analisar padrões combinados.

Com base no modelo, desenvolveu-se um código funcional que recebe características de um novo projeto e retorna a probabilidade de abertura de ticket, a classe prevista e as variáveis mais influentes. Testes com projetos fictícios confirmaram a funcionalidade da ferramenta e a forte influência da área “Venezuela” nas previsões de alto risco. Esta ferramenta permite uma gestão mais proativa e baseada em dados. O modelo deve ser re-treinado periodicamente com novos dados para manter sua precisão e relevância.

Os resultados sugerem um plano de ação para reduzir a abertura de tickets. Recomenda-se uma revisão aprofundada dos projetos associados à área “Venezuela”, o fator de maior impacto, e da área “Química”, de maior frequência. A revisão deve buscar falhas sistêmicas ou complexidades específicas. Dado que a maioria dos tickets são do tipo “issue” e se concentram em cinco causas, sugere-se a realização de treinamentos para a equipe de desenvolvimento e usuários, focados em evitar a recorrência desses problemas. Adicionalmente, a concentração de 80% dos tickets em 15 desenvolvedores aponta para a necessidade de uma distribuição mais equilibrada das demandas.

Finalmente, recomenda-se a implementação da ferramenta de previsão como parte do processo de encerramento de cada projeto. A ferramenta permitirá à gestão avaliar a probabilidade de futuros tickets e planejar as atividades de manutenção de forma mais proativa, otimizando a alocação de recursos. A atualização periódica do modelo será fundamental para garantir que suas previsões permaneçam precisas, consolidando uma cultura de melhoria contínua. Conclui-se que o objetivo foi atingido: demonstrou-se, por meio de análises descritivas, estatísticas e de aprendizado de máquina, os fatores determinantes na abertura de tickets e desenvolveu-se um modelo preditivo funcional com acurácia de 69% e AUC de 0,81.

Referências:
Allison, P. D. 1999. Logistic Regression Using SAS: Theory and Application. Cary, NC: SAS Institute Inc.
Au, T. C. (2018). Random Forests, Decision Trees, and Categorical Predictors: The “Absent Levels” Problem. Journal of Machine Learning Research, 19, 1–30.
Biau, G., & Scornet, E. (2015). A Random Forest Guided Tour. TEST, 25(2), 197–227.
Brasil. (2018). Lei nº 13.709, de 14 de agosto de 2018. Dispõe sobre a proteção de dados pessoais e altera a Lei nº 12.965, de 23 de abril de 2014. Retrieved from http://www. planalto. gov. br/ccivil03/ato2015-2018/2018/lei/l13709. htm
Breiman, L. (2001). Random Forests. Machine Learning, 45(1), 5–32.
Drucker, P. F. (1954). The practice of management.
Fávero, L. P.; Belfiore, P. 2017. Manual de análise de dados. 1ed. Elsevier, Rio de Janeiro, RJ, Brasil.
Hosmer, D. W., & Lemeshow, S. (2000). Applied Logistic Regression (2nd ed.).
Inmon, W. H. (2005). Building the Data Warehouse (4th ed.).
ITIL Foundation. (2019). ITIL Foundation: ITIL 4 edition.
Kerzner, H., & Saladis, F. P. (2017). Project management: A systems approach to planning, scheduling, and controlling (12th ed.).
Mulcahy, R. (2018). PMP exam prep (10th ed.).
Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK® Guide) (6th ed.).
Rahm, E., & Do, H. H. (2000). Data cleaning: Problems and current approaches. IEEE Data Engineering Bulletin, 23(4), 3-13. Retrieved from https://cs. uwaterloo. ca/~jimmylin/teaching/2019/cleaning. pdf
Scornet, E. (2015). Consistency of random forests. The Annals of Statistics, 43(4), 1716–1741.
Verma, V., & Raghavan, S. (2017). Project management: A systems approach.
Wright, M. N. (2019). Splitting on categorical predictors in random forests. PeerJ, 7, e6339.

Resumo executivo oriundo de Trabalho de Conclusão de Curso de Especialização em Data Science e Analytics do MBA USP/Esalq

_{Saiba mais sobre o curso; clique aqui:}