Artigo

05 de agosto de 2026

Gestão de Cronograma na Implementação do Módulo de Inventário de Matéria-Prima do Sistema “KWS Tools”

Joel Lincoln dos Santos Garcez; Gabriel Custódio Rangel

DOI: 10.22167/2675-6528-202600965

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

Resumo

A gestão estratégica do cronograma mostrou-se crucial para o sucesso de projetos de desenvolvimento de software em ecossistemas corporativos que exigem alta integração técnica e lidam com requisitos voláteis. O objetivo foi propor e aplicar um modelo de gestão de cronograma fundamentado no framework Scrum para a implementação do módulo de inventário de matéria-prima do sistema “KWS Tools”, visando solucionar ineficiências de processos manuais e baixa rastreabilidade, e assegurar controle de prazos e previsibilidade. A pesquisa classificou-se como aplicada, de natureza qualitativa e abordagem descritiva, utilizando o método de estudo de caso para investigar o fenômeno em seu contexto organizacional real. Adotou-se o framework Scrum, estruturando o Product Backlog como ferramenta central de planejamento, com decomposição de requisitos em histórias de usuário e estimativa por Story Points. A operacionalização ocorreu por meio de Sprints de duração fixa, fundamentadas em Definition of Ready (DoR) e Definition of Done (DoD). Complementarmente, integraram-se práticas de Engenharia de Software, como controle de versão via GitLab, análise estática com SonarQube e arquitetura modular, além do uso de quadro Kanban para acompanhamento. Os resultados evidenciaram que a disciplina dos eventos do Scrum propiciou monitoramento contínuo do progresso e resposta ágil a impedimentos técnicos, conferindo robustez técnica ao cronograma e mitigando riscos de atrasos. Observou-se melhoria na previsibilidade das entregas, organização do trabalho e uma redução do Lead Time ao longo das iterações. Concluiu-se que o Scrum atua de forma eficaz não apenas como metodologia de desenvolvimento, mas como um sistema de gestão adaptativa que alinha escopo, tempo e qualidade, garantindo a entrega de valor contínuo e a estabilidade operacional em projetos de software de alta complexidade.

Palavras-chave: Desenvolvimento de software; Metodologias ágeis; Scrum; Sistemas corporativos.

1. Introdução

A gestão de cronogramas é universalmente reconhecida como um pilar fundamental para o sucesso de projetos em diversas indústrias, sendo sua eficácia diretamente correlacionada ao cumprimento de objetivos, controle de custos e satisfação das partes interessadas. No domínio da tecnologia da informação, essa importância é amplificada, dada a natureza intrinsecamente complexa e dinâmica do desenvolvimento de software. Falhas no planejamento e controle do tempo são frequentemente citadas como causas primárias de atrasos e estouros orçamentários em projetos de TI, impactando negativamente a competitividade e a capacidade de inovação das organizações (Kerzner, 2017). Em ecossistemas corporativos que demandam alta integração técnica e lidam com requisitos voláteis, a gestão do tempo torna-se um desafio ainda mais acentuado, exigindo abordagens que permitam flexibilidade e adaptação contínua.

Historicamente, abordagens tradicionais de gerenciamento de projetos, caracterizadas por planejamentos extensivos e cronogramas rígidos, demonstram limitações significativas em ambientes de alta incerteza e mudanças frequentes, típicos do desenvolvimento de software (Sommerville, 2019). Tais metodologias frequentemente resultam em inflexibilidade, dificuldade em incorporar novas demandas e um desalinhamento progressivo entre o produto entregue e as necessidades do negócio. Como resposta a esses desafios, as metodologias ágeis emergiram, propondo um paradigma de desenvolvimento iterativo e incremental. Essas abordagens priorizam ciclos curtos de trabalho, entregas frequentes de valor e a capacidade de adaptação a mudanças, permitindo que o cronograma evolua de forma progressiva à medida que o entendimento do produto se aprofunda (Highsmith, 2019).

Entre as metodologias ágeis, o framework Scrum destaca-se por sua estrutura leve, mas robusta, que oferece mecanismos específicos para a organização e o controle do tempo. O Scrum se baseia em Sprints de duração fixa, eventos regulares de inspeção e adaptação, e artefatos que promovem transparência e previsibilidade (Schwaber; Sutherland, 2020). Sua aplicação disciplinada tem demonstrado contribuir para a redução de riscos, melhoria da previsibilidade do cronograma e maior alinhamento entre escopo, prazo e valor entregue ao negócio, tornando-o particularmente adequado para projetos de software em ambientes complexos e com requisitos dinâmicos (Rubin, 2017; Sutherland, 2014).

No contexto organizacional, sistemas de informação corporativos, como o “KWS Tools”, desempenham um papel estratégico ao sustentar processos críticos e apoiar a tomada de decisão (Laudon; Laudon, 2014). Antes da implementação do módulo de inventário de matéria-prima do sistema “KWS Tools”, o cenário era marcado por ineficiências significativas. O processo de contagem anual de matéria-prima era predominantemente manual, utilizando cartões físicos e planilhas eletrônicas, o que gerava um alto risco de inconsistências de dados, erros humanos e retrabalho. O ciclo de inventário, que se estendia por três a quatro semanas, impactava diretamente a rotina produtiva e a disponibilidade de informações atualizadas. Além disso, a baixa rastreabilidade e a ausência de um histórico confiável de registros dificultavam auditorias e a identificação sistemática de padrões de erro, resultando em divergências recorrentes na acuracidade do estoque e desalinhamento com o sistema “ERP Oracle EBS”. A necessidade de uma solução que mitigasse esses problemas e garantisse maior controle e previsibilidade era evidente.

A complexidade inerente ao desenvolvimento de software, aliada à volatilidade dos requisitos e à necessidade de integração com sistemas corporativos existentes, justifica a busca por abordagens de gestão de cronograma que ofereçam maior adaptabilidade e controle incremental. Diante das ineficiências observadas em processos manuais e da baixa rastreabilidade no gerenciamento de inventário de matéria-prima, o presente trabalho objetiva propor e aplicar um modelo de gestão de cronograma fundamentado no framework Scrum para a implementação do módulo de inventário de matéria-prima do sistema “KWS Tools”, visando solucionar os problemas de inconsistência de dados e falta de previsibilidade, e assegurar um controle de prazos robusto e entregas de valor contínuo.

2. Material e Métodos

O presente trabalho caracteriza-se como uma pesquisa aplicada, de natureza qualitativa, com abordagem descritiva e exploratória, estruturada a partir de um estudo de caso. A pesquisa aplicada, conforme Gil (2017), visa à solução de problemas práticos, enquanto a abordagem qualitativa prioriza a compreensão aprofundada do fenômeno estudado (Creswell, 2021). O caráter descritivo detalhou o processo de desenvolvimento, e o exploratório investigou a aplicação do framework Scrum em um contexto organizacional real. O método de estudo de caso permitiu analisar o fenômeno em seu ambiente, onde as fronteiras entre o objeto e o contexto não estavam claramente definidas (Yin, 2015).

O objeto de estudo foi o desenvolvimento do “KWS Inventory Management Module”, um componente do sistema corporativo “KWS Tools”. Este módulo foi concebido para uma indústria do setor de duas rodas, de origem japonesa, localizada no Polo Industrial de Manaus, Brasil. A decisão de desenvolver o sistema integralmente em língua inglesa refletiu a natureza multinacional da organização, visando padronizar a comunicação e facilitar a manutenção global da ferramenta. A unidade de análise concentrou-se na aplicação do framework Scrum para a gestão do cronograma deste projeto específico de desenvolvimento de software.

Antes da implementação do módulo, o processo de inventário de matéria-prima era conduzido de forma predominantemente manual, com apoio de cartões físicos e planilhas eletrônicas, o que gerava alto risco de inconsistências de dados, erros humanos e retrabalho. O ciclo de inventário anual estendia-se por um período estimado entre três e quatro semanas, impactando diretamente a rotina produtiva e a disponibilidade de informações atualizadas. Divergências recorrentes na acuracidade do estoque eram evidenciadas por discrepâncias com o “ERP Oracle EBS”, devido a atrasos no lançamento e ausência de mecanismos de conferência em tempo real.

A baixa rastreabilidade e a ausência de um histórico confiável e padronizado de registros dificultavam auditorias e a identificação sistemática de padrões de erro em inventários anteriores. Diante desse cenário de ineficiências, o presente trabalho objetivou propor e aplicar um modelo de gestão de cronograma fundamentado no framework Scrum para a implementação do módulo de inventário de matéria-prima do sistema “KWS Tools”. Buscou-se solucionar os problemas de inconsistência de dados e falta de previsibilidade, assegurando um controle de prazos robusto e entregas de valor contínuo ao negócio.

O sistema “KWS Tools” foi desenvolvido em linguagem de programação C# Windows Forms, utilizando o .NET Framework 4.8, com arquitetura modular que permitia o carregamento dinâmico de funcionalidades por meio de bibliotecas DLL, conforme o perfil de acesso do usuário. O “KWS Inventory Management Module” foi concebido como uma extensão desse sistema, com o objetivo de automatizar integralmente o processo de inventário físico de matéria-prima. A solução adotou uma arquitetura desacoplada, com atualização automática de módulos via servidor “File Transfer Protocol” [FTP], integração com arquivos Excel e interoperabilidade com o “ERP Oracle EBS”. O banco de dados MySQL Server foi utilizado para persistência e gerenciamento das informações operacionais, e o ambiente de desenvolvimento foi o “Visual Studio Community Edition” 2019.

O controle de acesso aos módulos do sistema baseou-se em um modelo de autorização por perfis. Cada usuário, identificado por credenciais exclusivas, associava-se a um ou mais perfis de acesso que detinham permissões previamente definidas para conjuntos específicos de módulos. Essa estrutura estabeleceu uma relação muitos-para-muitos entre usuários, perfis e módulos. No ato da autenticação, o sistema identificava os perfis vinculados ao usuário e construía o menu principal de forma dinâmica. Esse mecanismo garantiu que apenas as funcionalidades autorizadas fossem disponibilizadas, conferindo segurança, flexibilidade e conformidade às diferentes funções organizacionais, influenciando diretamente o planejamento das Sprints e o controle do cronograma.

A metodologia de gerenciamento adotada foi o Scrum, um framework ágil amplamente utilizado no desenvolvimento de software, cujo foco está na entrega incremental de valor, na adaptação contínua às mudanças e na transparência do processo (Schwaber & Sutherland, 2020). O Scrum foi escolhido por sua aderência a projetos com requisitos dinâmicos, pela possibilidade de entregas frequentes e pela forte ênfase na gestão do tempo por meio de Sprints de duração fixa, permitindo maior previsibilidade do cronograma. De acordo com Highsmith (2019), metodologias ágeis são especialmente indicadas em contextos de incerteza e evolução contínua dos requisitos, características presentes no projeto analisado. No contexto deste estudo, o Scrum foi aplicado com foco explícito na gestão do cronograma.

Os papéis definidos no Scrum foram adaptados à realidade organizacional do projeto, de modo a garantir maior eficiência na condução das atividades e alinhamento com os objetivos estabelecidos. O “Product Owner” foi responsável por definir a visão do produto, priorizar o “Product Backlog” e assegurar o alinhamento das funcionalidades com os objetivos do negócio, papel exercido pelo próprio autor do trabalho. O Time de Desenvolvimento assumiu a responsabilidade pela implementação técnica das funcionalidades. Já o papel de “Scrum Master” foi exercido de forma implícita pelo autor, atuando na facilitação do processo Scrum, na remoção de impedimentos e na garantia da aderência ao framework (Schwaber e Sutherland, 2020).

O “Product Backlog” constituiu o principal instrumento metodológico utilizado para a gestão do cronograma do projeto. Conforme descrito por Schwaber (2004), ele representa uma lista ordenada e dinâmica de tudo o que é necessário para o produto, sendo continuamente refinado ao longo do projeto. No projeto “KWS Inventory Management Module”, o “Product Backlog” foi construído a partir da visão do produto e estruturado em épicos e histórias de usuário, contemplando funcionalidades relacionadas à inicialização do sistema, autenticação, navegação, gestão de módulos dinâmicos, auditoria, gestão de inventários, carga de dados, impressão de cartões, contagem física, análise de inventário e validação com o “ERP Oracle EBS”.

Cada história de usuário foi descrita de forma padronizada, contemplando a identificação do papel do usuário, a necessidade a ser atendida e o valor esperado para o negócio. Além disso, foram definidos critérios de aceitação, nível de prioridade e estimativa de esforço em “Story Points”, bem como a “Sprint” planejada para sua implementação. Também foram consideradas as dependências técnicas e funcionais associadas a cada história, de modo a garantir maior previsibilidade no planejamento e na execução do projeto. Essa estrutura permitiu transformar requisitos funcionais em unidades planejáveis de trabalho, possibilitando o controle efetivo do escopo e do tempo, além de apoiar o planejamento incremental das Sprints e o acompanhamento da evolução do projeto.

Para fins de ilustração, a Tabela 1 apresenta exemplos de histórias de usuário extraídas do “Product Backlog”, evidenciando a relação entre priorização, estimativa de esforço e o planejamento das “Sprints”. Este recorte demonstra como os requisitos foram detalhados e preparados para o desenvolvimento incremental, alinhando as expectativas de negócio com a capacidade técnica da equipe. A tabela inclui épicos, histórias de usuário, prioridade, estimativa em “Story Points” e a “Sprint” prevista para cada item, conforme o planejamento inicial do projeto.

Tabela 1. Recorte do “Product Backlog”: Histórias de Usuário e Estimativas

Diretriz

Descrição

Versionamento Obrigatório

Todo o código-fonte deve residir no repositório oficial do projeto no GitLab

Rastreabilidade de “Branches”

Identificação de ramificações baseada nos itens do “Product Backlog”

Integridade da Master

Proibição de “commits” diretos no “Branch” principal, garantindo sua estabilidade permanente

Qualidade Automatizada

Condicionamento da integração à aprovação nas inspeções do SonarQube

Padronização Semântica

Uso de mensagens de “commit” claras e objetivas, além da estrita observância aos padrões de nomenclatura pelo time

Fonte: Dados originais da pesquisa.

A “Definition of Ready” [DoR] foi adotada como um conjunto de critérios objetivos com o propósito de assegurar que os itens do “Product Backlog” estivessem adequadamente preparados antes de serem incluídos no planejamento das Sprints. Embora a DoR não seja formalmente definida no Guia do Scrum, a literatura sobre métodos ágeis reconhece a importância de critérios claros para a entrada de requisitos no ciclo de desenvolvimento, especialmente como forma de reduzir incertezas, minimizar retrabalho e aumentar a previsibilidade do planejamento (Cohn, 2011). Complementarmente, a “Definition of Done” [DoD] estabeleceu critérios objetivos para a conclusão das funcionalidades, promovendo padronização, redução de retrabalho e maior confiabilidade dos incrementos entregues ao final de cada Sprint (Schwaber e Sutherland, 2020).

O refinamento do “Product Backlog” ocorreu de forma contínua ao longo do desenvolvimento, sendo realizado principalmente durante as Sprints em andamento, com foco na preparação dos itens que seriam considerados para as Sprints subsequentes. Essa prática está alinhada às recomendações do Guia do Scrum, que define o refinamento como uma atividade contínua de detalhamento, estimativa e ordenação dos itens do “Product Backlog” (Schwaber e Sutherland, 2020). As atividades de refinamento envolveram o “Product Owner” e a Equipe de Desenvolvimento, papéis que, no contexto deste projeto acadêmico, foram desempenhados pelo próprio autor. Como parte do refinamento técnico, realizou-se a modelagem de dados do sistema por meio da elaboração de diagramas entidade-relacionamento [DER], utilizando a ferramenta “Visual Paradigm”, essencial para a compreensão da estrutura do sistema e para a identificação de dependências e impactos técnicos entre módulos (Pressman e Maxim, 2016).

Os eventos do Scrum foram aplicados de forma disciplinada e alinhada à realidade do projeto. O “Sprint Planning” permitiu o alinhamento entre prioridades, capacidade da equipe e objetivos incrementais, enquanto a execução e acompanhamento das Sprints, apoiada por reuniões diárias (“Daily Scrum”) e pelo uso do quadro Kanban do GitLab, assegurou transparência, rastreabilidade e resposta rápida a impedimentos (Anderson, 2011). A “Sprint Review” consolidou-se como o principal momento de validação do incremento funcional junto às partes interessadas, viabilizando a inspeção do produto em funcionamento e a coleta de feedback. A “Sprint Retrospective” possibilitou a reflexão sistemática sobre o processo, promovendo ajustes incrementais na forma de trabalho da equipe (Schwaber e Sutherland, 2020).

Do ponto de vista técnico, a aplicação do Scrum foi reforçada por práticas complementares de Engenharia de Software. Adotou-se o GitLab como sistema de controle de versão, hospedado em infraestrutura interna, com estratégia de ramificação por item de “backlog” e “merge requests” submetidos a “code review”. O GitLab foi integrado à ferramenta SonarQube para análise estática automática, avaliando indicadores como complexidade ciclomática, duplicidade de código e vulnerabilidades de segurança. O versionamento de DLLs e a distribuição via FTP também foram utilizados, garantindo a integridade técnica das entregas e fortalecendo a previsibilidade do cronograma (Pressman e Maxim, 2016; Sommerville, 2019).

Como limitações do estudo, destaca-se o fato de o projeto ter sido conduzido em um contexto acadêmico-profissional específico, com acumulação de papéis pelo autor. A atuação simultânea como “Product Owner”, “Scrum Master” e Desenvolvedor pode ter influenciado os resultados, reduzindo conflitos naturais e simplificando a tomada de decisão. Além disso, a participação limitada de “stakeholders” reduziu a diversidade de feedback nas validações realizadas, o que pode ter impactado a riqueza das validações. Não foram identificados procedimentos éticos formais além da conformidade com as boas práticas de engenharia de software.

3. Resultados e Discussão

A aplicação do framework Scrum no desenvolvimento do “KWS Inventory Management Module”, um componente crucial do sistema “KWS Tools”, revelou uma série de resultados significativos que impactam diretamente a gestão do cronograma do projeto. Estes achados foram sistematicamente observados e analisados ao longo da execução das Sprints, por meio da utilização disciplinada de artefatos ágeis, notadamente o Product Backlog, e da adesão rigorosa aos eventos do Scrum, conforme detalhado na metodologia. O Scrum, neste contexto, transcendeu sua função como mera abordagem de desenvolvimento de software, consolidando-se como um instrumento central para o planejamento, acompanhamento e controle temporal das atividades. De modo geral, os resultados obtidos apontam para avanços consistentes na previsibilidade das entregas, na organização do trabalho e no monitoramento contínuo do progresso, especialmente quando comparados aos modelos tradicionais de gestão de projetos que eram previamente empregados no ambiente organizacional em questão. Tais evidências reforçam a contribuição do Scrum para uma gestão de cronograma mais estruturada, transparente e adaptativa, alinhada às demandas intrínsecas de um projeto de software corporativo, que se caracteriza por um elevado grau de complexidade e múltiplas dependências técnicas.

A estruturação do cronograma por meio do Product Backlog e das Sprints demonstrou ser um dos pilares fundamentais para a eficácia da gestão do tempo no projeto. A utilização do Product Backlog como instrumento central de planejamento revelou-se altamente eficaz na organização do cronograma, permitindo a decomposição de requisitos complexos em unidades menores, as histórias de usuário, que foram subsequentemente estruturadas, priorizadas e estimadas. Este resultado está em total consonância com a literatura especializada, que reconhece o Product Backlog como o principal artefato de transparência e planejamento no Scrum (Schwaber & Sutherland, 2020). A capacidade de detalhar requisitos em histórias de usuário, atribuir-lhes prioridades e estimativas de esforço em Story Points permitiu uma visão clara do trabalho a ser realizado, facilitando a alocação de recursos e a definição de prazos realistas para cada iteração.

A divisão do trabalho em Sprints de duração fixa, um dos princípios centrais do Scrum, contribuiu significativamente para a redução da incerteza inerente ao cronograma. Cada Sprint funcionou como um ciclo fechado de planejamento, execução e validação, o que permitiu à equipe inspecionar o progresso e adaptar-se rapidamente a novas informações ou mudanças de requisitos. Este comportamento corrobora os achados de Highsmith (2019), que enfatiza a superioridade das abordagens iterativas em ambientes de projeto caracterizados por alta volatilidade e mudanças frequentes. A fixidez da duração das Sprints impôs uma disciplina temporal que forçou a equipe a focar em entregas incrementais e a evitar a expansão descontrolada do escopo dentro de cada ciclo, um desafio comum em projetos de software (Kerzner, 2017). A previsibilidade advinda dessa estrutura de ciclos curtos e repetitivos permitiu que as partes interessadas tivessem uma compreensão mais clara do que seria entregue e quando, fomentando a confiança no processo.

Entretanto, uma análise crítica revela que a eficácia dessa estrutura de Product Backlog e Sprints depende diretamente da qualidade do refinamento do backlog. Em momentos iniciais do projeto, identificou-se que histórias de usuário pouco detalhadas ou com critérios de aceitação ambíguos impactaram negativamente a previsibilidade das primeiras Sprints. Isso evidencia que a simples adoção do artefato não garante resultados ótimos sem uma maturidade adequada no seu uso e na sua manutenção. Cohn (2011) ressalta que o refinamento contínuo do backlog é uma prática essencial para assegurar que os itens estejam claros, priorizados e prontos para implementação, minimizando ambiguidades e retrabalho. A experiência no projeto KWS demonstrou que investir tempo no detalhamento e na quebra de histórias complexas em unidades menores e mais gerenciáveis é crucial para a saúde do cronograma.

A Tabela 2 ilustra um recorte do Product Backlog, evidenciando como a priorização, a estimativa de esforço em Story Points e o planejamento das Sprints foram interligados.

Tabela 2. Recorte do “Product Backlog”: Histórias de Usuário e Estimativas

Épico

História de Usuário

Prioridade

“Story Points”

“Sprint”

Inicialização do Sistema

Como usuário, quero visualizar uma tela de “splash” com efeitos de transição durante a inicialização para confirmar o carregamento do sistema.

Média

3

“Sprint” 1

Autenticação

Como usuário, quero realizar login com validação de credenciais e seleção de ambiente/ERP para acessar o sistema com as permissões corretas.

Alta

5

“Sprint” 1

Navegação e interface

Como usuário, quero um menu hierárquico baseado em permissões para navegar apenas nas funcionalidades autorizadas de forma intuitiva.

Alta

8

“Sprint” 2

Atualização de Módulos

Como usuário, quero que os módulos e DLLs sejam carregados e atualizados via FTP automaticamente para garantir o uso da versão mais recente sem intervenção manual.

Alta

8

“Sprint” 2

Auditoria e Segurança

Como administrador, quero que o sistema registre logs detalhados de cada acesso e operação para fins de auditoria e monitoramento de segurança.

Média

3

“Sprint” 3

Gestão de Inventários

Como administrador, quero criar inventários para organizar o processo de inventário físico.

Alta

3

“Sprint” 4

Fonte: Dados originais da pesquisa

Conforme apresentado na Tabela 2, a categorização das histórias por épico, prioridade e estimativa em *Story Points* permitiu uma visão granular do trabalho. Por exemplo, a história de “Inicialização do Sistema” com prioridade Média e 3 *Story Points* foi planejada para a “Sprint 1”, enquanto “Autenticação”, com prioridade Alta e 5 *Story Points*, também foi alocada para a “Sprint 1”. Essa abordagem facilitou o balanceamento da carga de trabalho e o foco em funcionalidades de alto valor desde o início do projeto. A prática de estimar em *Story Points*, em vez de horas, promoveu uma discussão mais rica sobre a complexidade e o esforço relativo, em vez de uma fixação prematura em prazos absolutos, o que é um benefício reconhecido das metodologias ágeis (Rubin, 2017). A previsibilidade do cronograma foi, portanto, construída a partir dessa granularidade e do alinhamento contínuo entre as expectativas de negócio e a capacidade técnica da equipe.

A previsibilidade e o acompanhamento do progresso no projeto KWS apresentaram uma melhora perceptível ao longo das *Sprints*, impulsionada principalmente pelo uso combinado do quadro Kanban do GitLab e das reuniões diárias (*Daily Scrum*). A visualização contínua do fluxo de trabalho, proporcionada pelo Kanban, permitiu a identificação antecipada de gargalos e impedimentos, possibilitando ações corretivas ainda dentro da *Sprint*. Este resultado está em consonância com Anderson (2011), que destaca o papel fundamental dos sistemas visuais na melhoria do fluxo de trabalho e na gestão do progresso em ambientes ágeis. O Kanban, ao tornar o trabalho visível, promoveu a transparência e facilitou a comunicação entre os membros da equipe, garantindo que todos tivessem uma compreensão compartilhada do status das tarefas e dos desafios.

A Figura 1 apresenta o gráfico de “Velocity” por “Sprint” (Planejado vs. Real), construído a partir das entregas realizadas no desenvolvimento do “KWS Inventory Management Module”.

Figura 1. “Velocity” por “Sprint” (Planejado vs. Real)

Fonte: Resultados originais da pesquisa

Conforme ilustrado na Figura 1, observa-se que, ao longo das seis Sprints executadas, a equipe concluiu integralmente o volume de trabalho planejado em todas as iterações, uma vez que os valores planejados coincidem com os valores reais entregues. Essa consistência entre o planejado e o realizado é um forte indicador de previsibilidade e maturidade no uso do Scrum. A variação do desempenho da equipe e a entrega de valor ao longo das iterações podem ser observadas por meio da métrica de velocidade. A linha de média geral, fixada em 11,5 Story Points por Sprint, evidencia uma capacidade produtiva consistente ao longo do projeto, ainda que com oscilações naturais decorrentes da complexidade e natureza das funcionalidades desenvolvidas em cada ciclo. Por exemplo, a Sprint 3 apresentou um volume menor de Story Points (3), associado a entregas mais específicas de auditoria e segurança, que, embora de menor volume, eram de alta complexidade técnica e crítica para a conformidade do sistema. Em contraste, a Sprint 5 concentrou a maior capacidade produtiva (19 Story Points), impulsionada pela implementação simultânea de funcionalidades centrais relacionadas à impressão de cartões e contagem física, que, apesar de demandarem maior esforço, eram mais bem compreendidas e com menos dependências externas. Esses resultados indicam um elevado nível de previsibilidade no planejamento e uma aderência robusta às estimativas definidas no Sprint Planning, demonstrando a maturidade do Scrum como instrumento de gestão do cronograma. A ausência de desvios significativos entre o escopo comprometido e o efetivamente entregue em nenhuma Sprint reforça a eficácia da abordagem.

A Figura 2 apresenta o “Burndown Chart” da “Sprint” 5, utilizado para monitorar diariamente a quantidade de trabalho restante ao longo da “Sprint,” medida em “Story Points.”

Figura 2. “Burndown Chart” da “Sprint” 5 (Progresso Diário)

Fonte: Resultados originais da pesquisa

A análise do Burndown Chart da Sprint 5 (Figura 2) revela que a Sprint foi iniciada com um escopo total de 19 Story Points, correspondente às histórias US09, US10, US11 e US12. A linha ideal representa a redução linear esperada do trabalho até o encerramento da Sprint, enquanto a linha real evidencia o ritmo efetivamente alcançado pela equipe. Observa-se que nos dois primeiros dias úteis o volume permaneceu estável em 19 pontos, indicando uma concentração inicial em atividades preparatórias, desenvolvimento técnico ou tarefas ainda não concluídas integralmente. Este comportamento é comum em Sprints onde há uma fase inicial de setup ou de aprofundamento técnico antes da implementação efetiva das funcionalidades. A partir do terceiro dia, ocorreu uma redução consistente do escopo remanescente, passando para 16 pontos, depois 11 pontos no quarto dia e apenas 3 pontos no quinto dia. No sexto dia útil, todo o trabalho planejado foi concluído, atingindo zero Story Points restantes antes mesmo do prazo final previsto, permanecendo assim até o encerramento da Sprint. Esse comportamento indica uma aceleração produtiva na segunda metade do ciclo, elevada capacidade de finalização das entregas e aderência ao objetivo da Sprint. Sob a perspectiva da gestão do cronograma, o gráfico evidencia um bom controle operacional, uma resposta eficiente ao planejamento estabelecido e a utilização eficaz do Scrum como mecanismo de transparência e acompanhamento contínuo do progresso. A conclusão antecipada do escopo sugere maturidade da equipe na decomposição das tarefas, execução coordenada e previsibilidade das entregas incrementais, alinhando-se com a importância da inspeção frequente para o controle empírico do projeto, conforme destacado por Sutherland (2016).

O impacto da Definition of Ready (DoR) e da Definition of Done (DoD) foi crucial para a qualidade e previsibilidade do cronograma. A adoção da DoR contribuiu diretamente para a melhoria da qualidade do planejamento, reduzindo ambiguidades e aumentando a confiabilidade das estimativas. Este achado está alinhado com Cohn (2011), que destaca a importância de histórias bem definidas para evitar retrabalho e atrasos. No projeto KWS, a DoR foi aplicada durante as atividades de refinamento do Product Backlog, garantindo que apenas histórias de usuário suficientemente detalhadas, compreendidas e estimadas fossem selecionadas para desenvolvimento. Os critérios estabelecidos para uma história ser considerada “pronta” incluíam clareza funcional, documentação dos critérios de aceitação, identificação de dependências técnicas e funcionais, priorização pelo Product Owner e estimativa de esforço em Story Points, além da inexistência de impedimentos conhecidos. Essa prática tornou o planejamento das Sprints mais previsível e consistente, em consonância com os princípios de transparência, inspeção e adaptação preconizados pelo Scrum (Schwaber & Sutherland, 2020). A DoR, portanto, atuou como um filtro de qualidade na entrada do processo de desenvolvimento, minimizando riscos e otimizando o uso do tempo da equipe.

Da mesma forma, a Definition of Done (DoD) atuou como um mecanismo efetivo de controle de qualidade, garantindo que apenas incrementos completos e validados fossem considerados concluídos. Conforme Pressman e Maxim (2016), critérios claros de aceitação e de conclusão são fundamentais para assegurar consistência e previsibilidade no desenvolvimento de software. No projeto KWS, a DoD foi aplicada durante a execução das Sprints como referência permanente para a Equipe de Desenvolvimento, orientando o acompanhamento das atividades registradas no quadro Kanban do GitLab. Apenas os itens que atendiam integralmente aos critérios definidos eram considerados concluídos e movidos para o status “Done”. Essa prática está alinhada ao princípio ágil de entrega de incrementos potencialmente utilizáveis ao final de cada iteração, conforme defendido por Sutherland (2016), que destaca a importância de garantir que cada Sprint resulte em valor real e verificável. A exigência de implementação funcional completa, conformidade arquitetural, validação da modelagem de dados e correta aplicação das regras de negócio reflete boas práticas da Engenharia de Software voltadas à manutenibilidade, reutilização e confiabilidade dos sistemas (Sommerville, 2019). A DoD, ao garantir a qualidade técnica e funcional das entregas, contribuiu diretamente para a estabilidade do cronograma, evitando a acumulação de dívida técnica que poderia gerar atrasos futuros.

Sob uma perspectiva crítica, embora a DoR e a DoD tenham contribuído positivamente para a gestão do cronograma, sua aplicação no contexto deste estudo apresentou uma particularidade relevante: a centralização dessas definições no próprio autor, que acumulou múltiplos papéis no Scrum (Product Owner, Scrum Master e Desenvolvedor). Isso pode ter influenciado os resultados, reduzindo conflitos naturais e simplificando a tomada de decisão, o que pode não ser replicável em equipes maiores e mais complexas. A concentração de papéis, embora tenha agilizado o processo decisório no contexto específico do estudo de caso, pode ter limitado a diversidade de perspectivas na definição dos critérios, potencialmente reduzindo o potencial colaborativo dessas práticas conforme previsto na literatura (Cohn, 2011; Schwaber & Sutherland, 2020). Em um ambiente com múltiplos stakeholders e membros de equipe, a construção colaborativa da DoR e DoD é essencial para garantir que todos os pontos de vista sejam considerados e que os critérios reflitam um consenso que abranja as diversas dimensões do projeto (negócio, técnica, qualidade).

As entregas incrementais e a validação contínua foram elementos cruciais para a gestão adaptativa do cronograma. A entrega de incrementos funcionais ao final de cada Sprint permitiu a validação contínua do sistema, reduzindo riscos associados à detecção tardia de erros. Esse resultado reforça o princípio ágil de entrega frequente de valor, amplamente discutido por Sommerville (2019). A realização das Sprint Reviews possibilitou a inspeção do sistema em funcionamento, incluindo aspectos técnicos como integração com o ERP Oracle EBS e carregamento dinâmico de módulos. Esse processo favoreceu a identificação precoce de inconsistências e a adaptação do Product Backlog, contribuindo para a manutenção do cronograma. Comparativamente às abordagens tradicionais, esse modelo mostrou-se mais eficiente na mitigação de riscos, conforme também apontado por Rubin (2017), ao defender que ciclos curtos reduzem o impacto de erros acumulados. A capacidade de inspecionar o produto em funcionamento e coletar feedback das partes interessadas em intervalos regulares permitiu que o cronograma fosse ajustado de forma proativa, evitando que problemas menores se transformassem em grandes atrasos.

No entanto, a ausência de múltiplos stakeholders ativos nas revisões — devido ao contexto específico do estudo de caso, onde o autor acumulava papéis — limitou parcialmente o potencial de feedback externo, o que pode ter reduzido a riqueza das validações realizadas. Em projetos maiores e mais complexos, a diversidade de perspectivas durante as Sprint Reviews é fundamental para garantir que o produto atenda a uma gama mais ampla de necessidades e expectativas. As decisões tomadas durante a Sprint Review impactam diretamente o replanejamento do Product Backlog e, consequentemente, a gestão do cronograma do projeto. De acordo com Sutherland (2016), a possibilidade de aceitar, ajustar ou replanejar funcionalidades ao final de cada Sprint permite uma gestão adaptativa do tempo, baseada em entregas reais e não em estimativas rígidas de longo prazo. Esse modelo favorece maior previsibilidade e controle, mesmo em ambientes sujeitos a incertezas, ao permitir que o cronograma seja um artefato vivo, que evolui com o projeto. A Sprint Review consolida-se, assim, como um mecanismo essencial de inspeção e adaptação no Scrum, exercendo papel estratégico na gestão do cronograma e na mitigação de riscos.

Um dos resultados mais relevantes do estudo foi a constatação de que a eficácia do Scrum na gestão do cronograma foi potencializada pela integração com práticas robustas de Engenharia de Software. A adoção de controle de versão com GitLab, análise estática de código com SonarQube e uma arquitetura modular baseada em carregamento dinâmico de bibliotecas DLLs, reforçou a previsibilidade e a qualidade das entregas. Essa integração corrobora o argumento de Sommerville (2019), de que métodos ágeis, isoladamente, não são suficientes para garantir qualidade e previsibilidade em projetos complexos, sendo necessário o suporte de práticas técnicas robustas. No contexto analisado, essas práticas contribuíram para a redução de retrabalho, o controle da dívida técnica e a estabilidade das entregas, aspectos que impactam diretamente a saúde do cronograma. O versionamento sistemático do código-fonte no GitLab, com estratégia de ramificação por item de backlog e merge requests submetidos a code review, garantiu a integridade do código e facilitou a rastreabilidade das alterações (Pressman & Maxim, 2016). A análise estática com SonarQube, por sua vez, atuou como um mecanismo de controle de qualidade contínuo, identificando precocemente problemas de complexidade, duplicidade e vulnerabilidades, evitando que a dívida técnica se acumulasse e comprometesse o cronograma futuro.

Entretanto, a adoção dessas ferramentas e práticas de engenharia de software também introduziu um aumento na complexidade operacional do projeto, exigindo maior disciplina e conhecimento técnico da equipe. Isso pode representar uma barreira em equipes menos experientes, que podem ter dificuldades em integrar e gerenciar essas ferramentas de forma eficaz. A necessidade de um code review rigoroso e a conformidade com as métricas do SonarQube, embora benéficas para a qualidade, adicionam etapas ao processo de desenvolvimento que precisam ser bem gerenciadas para não se tornarem gargalos. A Figura 3 apresenta o gráfico de Evolução do “Lead Time” por “Sprint”, um indicador crucial para mensurar o tempo decorrido entre o início e a conclusão das demandas planejadas em cada Sprint do projeto “KWS Inventory Management Module”.

Figura 3. Evolução do “Lead Time” por “Sprint” (redução de 50%)

Fonte: Resultados originais da pesquisa

Conforme demonstrado na Figura 3, o Lead Time iniciou em 6 dias nas Sprints 1 e 2, reduziu para 4 dias nas Sprints 3 e 4, apresentou elevação pontual para 6 dias na Sprint 5 e atingiu o menor valor do projeto na Sprint 6, com 3 dias. A média geral do processo foi de 4,83 dias, representada pela linha horizontal de referência, enquanto a linha de tendência linear demonstra um comportamento descendente ao longo das iterações, indicando um ganho progressivo de eficiência operacional. Em termos comparativos, verifica-se uma redução de 50% entre o pior desempenho observado (6 dias) e o melhor resultado alcançado (3 dias), evidenciando o amadurecimento do fluxo de trabalho, um melhor entendimento técnico do produto e uma maior sincronização entre planejamento e execução. A elevação registrada na Sprint 5 pode ser associada à implementação de funcionalidades mais complexas, relacionadas à impressão de cartões e contagem física, que demandaram maior esforço de validação e, consequentemente, um tempo maior para serem consideradas “Done”. Ainda assim, a recuperação imediata na Sprint 6, com o Lead Time mais baixo, reforça a capacidade adaptativa do Scrum e a eficácia das práticas de melhoria contínua adotadas. Essa redução do Lead Time é um resultado direto da otimização dos processos, da melhoria na qualidade do backlog e da integração eficaz das práticas de engenharia de software, contribuindo não apenas para a previsibilidade do cronograma, mas também para a aceleração do ciclo de entrega das funcionalidades ao longo do projeto.

De forma geral, os resultados indicam que a aplicação do Scrum contribuiu positivamente para a gestão do cronograma, promovendo maior organização, transparência e capacidade de adaptação. Esses achados estão alinhados com a literatura, que aponta o Scrum como uma abordagem eficaz em ambientes complexos e dinâmicos (Schwaber & Sutherland, 2020; Highsmith, 2019). A capacidade de responder rapidamente a mudanças e de entregar valor de forma incremental é um diferencial competitivo que o Scrum proporciona, especialmente em projetos de software onde os requisitos são frequentemente voláteis. A transparência gerada pelos artefatos e eventos do Scrum, como o Product Backlog, o Kanban e as Daily Scrums, permitiu que todos os envolvidos tivessem uma visão clara do progresso e dos desafios, facilitando a tomada de decisões informadas e a colaboração.

Entretanto, a análise crítica dos resultados evidencia algumas limitações importantes do estudo. Destaca-se, inicialmente, o acúmulo de papéis pelo autor, que atuou simultaneamente como Product Owner, Scrum Master e Desenvolvedor. Essa acumulação pode ter influenciado os resultados, reduzindo conflitos naturais e simplificando a tomada de decisão, o que pode não ser representativo de equipes maiores e estruturas organizacionais mais complexas. Em um cenário real com diferentes indivíduos desempenhando esses papéis, a dinâmica de comunicação, negociação e resolução de conflitos seria mais pronunciada, potencialmente impactando o cronograma. Além disso, a participação limitada de stakeholders externos reduziu a diversidade de feedback nas validações realizadas, o que pode ter impactado a riqueza das validações e a amplitude das perspectivas consideradas no desenvolvimento do produto. A ausência de um grupo diversificado de usuários e clientes nas Sprint Reviews pode ter limitado a capacidade de identificar necessidades não atendidas ou de validar a usabilidade do sistema de forma mais abrangente.

Por outro lado, destacam-se como pontos fortes do estudo a aplicação prática em um ambiente real, o que confere maior aderência aos desafios organizacionais e à validação empírica da eficácia do Scrum. A integração entre gestão ágil e engenharia de software, que contribuiu para a robustez da solução, é outro ponto forte, demonstrando que a combinação de metodologias e práticas técnicas é fundamental para o sucesso em projetos complexos. A aderência consistente ao framework Scrum ao longo do projeto e o foco específico na gestão do cronograma, aspecto que se configura como um diferencial acadêmico do presente trabalho, também são pontos positivos. A pesquisa não se limitou a descrever a aplicação do Scrum, mas buscou analisar seus impactos diretos na previsibilidade e controle do tempo, oferecendo insights valiosos para a comunidade de gestão de projetos.

Em síntese, a análise dos resultados permite concluir que o Scrum, quando aplicado de forma disciplinada e aliado a boas práticas técnicas de engenharia de software, atua como um mecanismo eficaz de gestão adaptativa do cronograma. Diferentemente de abordagens tradicionais, baseadas em planejamento rígido e sequencial, o modelo iterativo e incremental possibilitou um controle progressivo do tempo, fundamentado em entregas reais e validação contínua. Contudo, os resultados também indicam que a eficácia do Scrum não depende apenas da adoção formal de seus artefatos e eventos, mas da maturidade na sua aplicação, da colaboração efetiva entre os papéis e do suporte de práticas técnicas complementares. A experiência no projeto “KWS Inventory Management Module” demonstrou que a entrega contínua de incrementos funcionais, associada à inspeção frequente e à adaptação do planejamento, contribui significativamente para a redução de riscos, o aumento da transparência e a melhoria da previsibilidade em projetos de software corporativo.

4. Conclusão

Conclui-se que o objetivo foi atingido, uma vez que o presente trabalho propôs e aplicou com sucesso um modelo de gestão de cronograma fundamentado no framework Scrum para a implementação do módulo de inventário de matéria-prima do sistema “KWS Tools”. A aplicação disciplinada do Scrum, aliada a boas práticas de engenharia de software, demonstrou ser eficaz em solucionar os problemas de inconsistência de dados e aprimorar a previsibilidade, elementos críticos no cenário anterior. A estruturação do trabalho em Sprints de duração fixa, o uso do Product Backlog para priorização e estimativa, e a adoção de Definition of Ready e Definition of Done, promoveram maior organização, transparência e adaptabilidade. Isso resultou em maior previsibilidade das entregas e uma notável redução do Lead Time, evidenciando a robustez do controle de prazos e a entrega contínua de valor.

Contudo, é fundamental reconhecer as limitações deste estudo. O acúmulo de papéis pelo autor (Product Owner, Scrum Master e Desenvolvedor) pode ter simplificado a tomada de decisão e potencialmente limitado a diversidade de perspectivas, o que pode não ser replicável em equipes maiores e mais complexas. Adicionalmente, a participação limitada de stakeholders externos restringiu a riqueza do feedback nas validações do produto. Para estudos futuros, sugere-se a ampliação da pesquisa para incluir análises comparativas entre Scrum e outras abordagens ágeis ou híbridas. Recomenda-se também a incorporação de métricas quantitativas mais aprofundadas para avaliação do desempenho do cronograma ao longo de ciclos completos de desenvolvimento, e a aplicação do modelo em outros módulos do sistema “KWS Tools” ou em projetos similares. Isso permitiria não apenas generalizar os achados, mas também aprofundar a compreensão da gestão de cronogramas em projetos de software complexos e em diferentes contextos organizacionais.

Referências Bibliográficas

Anderson, D.J. 2011. Kanban: Mudança Evolucionária de Sucesso para o seu Negócio de Tecnologia.1ed. Bookman, Porto Alegre, RS, Brasil.

Cohn, Mike. 2011. Agile: desenvolvimento de software com Scrum. 1ed, Bookman, Porto Alegre, RS, Brasil.

Creswell, J.W. 2021. Projeto de pesquisa: métodos qualitativo, quantitativo e misto. 5ed. Penso, Porto Alegre, RS, Brasil.

Gil, A.C. 2017. Métodos e técnicas de pesquisa social. 6ed. Atlas, São Paulo, SP, Brasil.

Highsmith, J. 2019. Gerenciamento ágil de projetos: criando produtos inovadores. 2ed. Pearson, São Paulo, SP, Brasil.

Kerzner, H. 2017. Gestão de projetos: as melhores práticas. 3ed. Bookman, Porto Alegre, RS, Brasil.

Laudon, Kenneth C.; Laudon, Jane P. 2014. Sistemas de informação gerenciais. 11. ed. Pearson, São Paulo, SP, Brasil.

Pressman, Roger S.; Maxim, Bruce R. 2016. Engenharia de software: uma abordagem profissional. 8. ed. AMGH, Porto Alegre, RS, Brasil.

Rubin, K.S. 2017. Scrum essencial: um guia prático para o processo ágil mais popular. 1ed. Alta Books, São Paulo, SP, Brasil.

Schwaber, K. 2004. Agile project management with Scrum. Microsoft Press, Redmond, WA, EUA.

Schwaber, K.; Sutherland, J. 2020. O Guia do Scrum: o guia definitivo do Scrum. Tradução oficial. Disponível em: https://scrumguides.org. Acesso em: 10 out. 2020.

Sommerville, I. 2019. Engenharia de software. 10ed. Pearson, São Paulo, SP, Brasil.

Sutherland, J. 2016. Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo. 1ed. LeYa, São Paulo, SP, Brasil.

Yin, R.K. 2015. Estudo de caso: planejamento e métodos. 5ed. Bookman, Porto Alegre, RS, Brasil.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Gestão de Projetos do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy

Você também pode gostar

Compliance E Esg

11 de setembro de 2026

Inteligência Artificial na Gestão Contratual: Supervisão Humana, Riscos Jurídicos e Governança Algorítmica

O advento da inteligência artificial como tecnologia disruptiva reconfigurou processos econômicos, institucionais e jurídicos, conferindo centralidade à automação contratual na gestão de relações complexas. A automação contratual revelou-se um fenômeno juridicamente não neutro, com opacidade decisória, geração automatizada de cláusulas abusivas e dificuldades de atribuição de responsabilidade, deslocando a elaboração contratual para o domínio jurídico-normativo. O estudo analisou como a inteligência artificial na automação contratual intensificou a colisão entre eficiência tecnológica e segurança jurídica, e em que medida mecanismos de supervisão humana significativa e de governança algorítmica funcionaram como instrumentos de ponderação normativa para preservar princípios do direito contratual brasileiro. A pesquisa adotou abordagem qualitativa de estudo de casos múltiplos, com análise documental de quatro casos paradigmáticos: Moffatt v. Air Canada, United States v. RealPage, Deloitte/DEWR e INSS/TRF-4ª Região, representando os contextos consumerista, concorrencial, consultivo-contratual e administrativo. A análise identificou cinco padrões estruturais recorrentes – opacidade decisória, substituição da racionalidade normativa por inferências probabilísticas, accountability gap, assimetria informacional e incompreensão semântica – que emergiram de forma sistêmica. O desfecho fragmentado do caso RealPage reforçou a conclusão de que a jurisprudência sobre automação decisória permanece em formação. A governança algorítmica eficaz demonstrou exigir a integração de mecanismos de auditabilidade, responsabilização e supervisão humana, conforme as normas ISO 31000, COSO ERM e ISO 37301, como condição necessária à legitimidade dos sistemas automatizados de gestão contratual.

Palavras-chave: Contratos; Governança algorítmica; Inteligência artificial; Segurança jurídica; Supervisão humana.

Compliance E Esg

11 de setembro de 2026

Rituais de Verificação sob Pressão: Categorias de Ação ESG Relatadas por Grande Grupo Frigorífico Antes e Após Operação Deflagrada Pela Polícia Federal e Seus Desdobramentos, em Passado Recente

Relatórios de sustentabilidade são amplamente empregados como instrumentos de gestão da legitimidade corporativa, mas sua função como mecanismo de reorganização cognitiva em contextos de crise reputacional permaneceu subexplorada na literatura. O estudo analisou as transformações nas categorias de ação ESG reportadas pela Empresa JBS em seus relatórios anuais de sustentabilidade de 2015 a 2018, período que compreendeu dois anos anteriores e dois anos posteriores à Operação Carne Fraca e seus desdobramentos. O objetivo foi investigar como a organização alterou sua estrutura cognitiva após a crise reputacional, por meio de um de seus sistemas de reporte. Empregou-se um processo de catalogação sistemática de 1.088 práticas relatadas, classificadas por pilar ESG, tema material e categoria de ação. O referencial teórico mobilizou Mary Douglas (1986), Michael Power (1997), Meyer e Rowan (1977) e Edelman (2016) para interpretar os fenômenos observados. Os resultados evidenciaram um crescimento exigido em governança, que coexistiu com o colapso do pilar social, o desaparecimento de categorias substantivas e a substituição de ações voltadas a prêmios por ações que ressignificaram as relações da organização e seu posicionamento no mercado. Além disso, treinamentos de liderança migraram do tema de cultura para compliance, campanhas de comunicação cederam lugar a canais estruturais permanentes, e investidores tornaram-se a audiência de maior crescimento proporcional. Concluiu-se que a sofisticação do esforço de legitimação residiu não no que a empresa necessariamente fez, mas na consistência com que reorganizou quem ela diz ser e para quem, a partir das categorias de ação que relatou.

Palavras-chave: Crise reputacional; ESG; Pensamento institucional; Relatórios de sustentabilidade; Estratégia organizacional.

Gestão Escolar

11 de setembro de 2026

Liderança Escolar à Luz da Teoria U: um Diálogo com as Lideranças Transformacional e Servidora.

A integração de diferentes modelos de liderança mostrou-se um caminho relevante para instituições de ensino que buscaram inovar e alcançar excelência em suas práticas educacionais. Contudo, foram escassas as pesquisas empíricas que investigaram a aplicação da Teoria U na gestão escolar associada às abordagens Transformacional e Servidora, o que configurou uma lacuna na literatura. Este estudo buscou compreender como gestores educacionais perceberam e aplicaram princípios da Teoria U — escuta generativa, presencing e cocriação — em diálogo com as abordagens teóricas da Liderança Transformacional e da Liderança Servidora em suas práticas de gestão. A pesquisa, de natureza qualitativa e exploratória, foi realizada em uma instituição de ensino privada, localizada na cidade de São Paulo, que abrangeu desde a Educação Básica até a Pós-Graduação. Os dados foram coletados por meio de um roteiro de perguntas semiestruturadas, aplicado a sete gestores educacionais, e foram analisados com base na Análise de Conteúdo de Bardin. Os resultados evidenciaram aproximações entre as práticas observadas e os pressupostos teóricos dos modelos estudados, com a escuta destacando-se como a competência que melhor articulou as três abordagens no contexto investigado. Também foram identificadas algumas tensões entre os referenciais teóricos e o cotidiano da gestão. O estudo contribuiu para uma reflexão crítica sobre as possibilidades e os limites da integração desses diferentes modelos de liderança em ambientes escolares, ampliando o debate e oferecendo subsídios relevantes para o fortalecimento do campo da gestão educacional.

Palavras-chave: Análise de Conteúdo; Escuta Generativa; Estudo de Caso; Gestão Escolar; Liderança.

10 de setembro de 2026

Desempenho de Modelos de Machine Learning na Seleção de Ações da Bolsa de Valores Brasileira

O mercado acionário brasileiro, caracterizado por elevada volatilidade e restrições de liquidez, impõe desafios à aplicação de modelos de aprendizado de máquina na previsão de retornos e na construção de estratégias de investimento. O estudo comparou o desempenho preditivo e econômico de modelos de aprendizado de máquina e métodos estatísticos tradicionais na estimação de retornos futuros e na formação de carteiras baseadas em ranking de ativos. Utilizaram-se dados históricos de ações da B3, com variáveis técnicas e financeiras derivadas de preços e volume. Avaliaram-se modelos lineares (Regressão Linear, Ridge, LASSO, Elastic Net), de ensemble (Random Forest, XGBoost, LightGBM) e uma rede neural (Multilayer Perceptron). A avaliação preditiva ocorreu por métricas de erro em conjunto de teste, e a econômica por backtest de estratégias long-only, com custos operacionais baseados no turnover para análise de retornos brutos e líquidos. Os resultados revelaram baixa capacidade preditiva em todos os modelos, com R² negativos e erros elevados. Embora diferenças marginais nas previsões tenham gerado variações no desempenho econômico, estas foram de baixa magnitude e instáveis. O modelo LightGBM obteve o melhor desempenho econômico, mas com ganhos limitados em relação ao benchmark após a inclusão de custos operacionais. Não se observou evidência consistente de geração de retorno ajustado ao risco superior.

Palavras-chave: aprendizado de máquina; backtest; mercado acionário; previsão de retornos; seleção de ativos.

10 de setembro de 2026

Precificação Hedônica de Imóveis na Grande Florianópolis: Uso e Comparação de Modelos de “Machine Learning”

O mercado imobiliário da Grande Florianópolis tem experimentado valorização acelerada, impulsionada pelo crescimento populacional e pela demanda turística e de investimento. Este estudo analisou os determinantes do valor de imóveis residenciais e comparou o desempenho preditivo de modelos de aprendizado de máquina, especificamente Random Forest e Gradient Boosting (XGBoost), com uma regressão por Mínimos Quadrados Ordinários (MQO). Os dados foram coletados via web scraping de dois portais imobiliários em março de 2026, abrangendo os municípios de Florianópolis, São José, Palhoça e Biguaçu, resultando em 8.056 observações válidas após limpeza. Avaliou-se o desempenho dos modelos por meio das métricas R², RMSE e MAPE. O XGBoost apresentou o melhor desempenho preditivo geral (R² = 0,742, RMSE = R$ 927.113), enquanto o Random Forest obteve o menor erro relativo (MAPE = 25,69%). Os principais determinantes do preço identificados foram a área construída, a região de localização e o número de banheiros. Uma análise complementar por segmento de mercado revelou que o MQO dependeu dos valores extremos para sustentar seu ajuste, enquanto os modelos ensemble mantiveram desempenho estável. Concluiu-se que os métodos de aprendizado de máquina são mais robustos para precificação hedônica em mercados imobiliários heterogêneos, especialmente na presença de imóveis atípicos.

Palavras-chave: Ensemble; Imobiliário; Regressão; Residencial; Web Scraping.

Neurociência E Aprendizagem Na Educação

10 de setembro de 2026

A Produção de Memes como Estratégia de Formação Literária e Multiletramentos no Ensino Fundamental Ii

A leitura de obras literárias clássicas apresenta desafios no contexto escolar contemporâneo, devido ao distanciamento entre a linguagem dos textos e o repertório dos estudantes. Investigou-se como a utilização de memes contribuiu para a construção de sentidos na leitura da obra Senhora, de José de Alencar, no Ensino Fundamental II. A pesquisa adotou uma abordagem qualitativa, com caráter de pesquisa participante, e foi desenvolvida com duas turmas de 9º ano de uma escola privada em Volta Redonda, Rio de Janeiro. Os dados foram coletados por meio de questionários e das produções dos estudantes, e analisados à luz da análise de conteúdo. Os resultados indicaram que a utilização de memes favoreceu a aproximação dos alunos com o texto literário, reduziu a resistência inicial e ampliou o engajamento com a leitura. Observou-se, também, o avanço progressivo na compreensão da narrativa, evidenciado pela capacidade de interpretar fatos, analisar personagens, identificar relações implícitas e elaborar posicionamentos críticos. As produções revelaram a articulação entre o conteúdo da obra e o repertório sociocultural dos estudantes, indicando a construção de aprendizagens com significado. Concluiu-se que a integração entre literatura e cultura digital potencializou a mediação pedagógica, contribuindo para a formação de leitores mais ativos e interpretativamente autônomos.

Palavras-chave: aprendizagem significativa; cultura digital; leitura literária; multiletramentos; neurociência.

Gestão Tributária

10 de setembro de 2026

Definição de Insumos para Fins de Aproveitamento de Créditos de Pis e Cofins

O estudo analisou a interpretação e a aplicação da definição de insumos para fins de creditamento do Programa de Integração Social (PIS) e da Contribuição para o Financiamento da Seguridade Social (COFINS) no regime não cumulativo, à luz do entendimento firmado pelo Superior Tribunal de Justiça (STJ) no julgamento do Recurso Especial n.º 1.221.170 (Tema 779). Objetivou-se examinar os limites jurídicos da utilização desses créditos, considerando os critérios de essencialidade ou relevância estabelecidos pela jurisprudência do STJ. Realizou-se pesquisa documental e jurisprudencial, com análise de acórdãos representativos do Conselho Administrativo de Recursos Fiscais (CARF) e do STJ, abrangendo períodos anteriores e posteriores ao Tema 779. Complementarmente, conduziu-se pesquisa bibliográfica e estudos de dois casos concretos do CARF, com abordagem qualitativa, para verificar a aplicação prática dos critérios. Constatou-se que o STJ afastou a aplicação automática da definição de insumo do IPI, consolidando os critérios de essencialidade e relevância. Entretanto, a análise dos julgados do CARF evidenciou que, embora houvesse reconhecimento formal do precedente do STJ, sua incidência foi modulada conforme a natureza da atividade empresarial, mostrando-se mais restritiva para empresas de revenda. Os casos concretos ilustraram que creditamentos de fretes foram tratados de forma distinta, dependendo da vinculação do gasto à produção ou à revenda. Concluiu-se que a definição de insumos permanece um ponto sensível do sistema tributário, e a correta utilização dos créditos demanda análise casuística rigorosa, pautada na observância dos precedentes judiciais e dos limites normativos vigentes, para evitar glosas e penalidades.

Palavras-chave: COFINS; Creditamento; Insumos; PIS.

Gestão Tributária

10 de setembro de 2026

Fiscalização Delegada do ITR: Desestímulo aos Convênios, Reflexos na Arrecadação e Desinteresse Processual da União

O Imposto Territorial Rural (ITR), de competência da União, pode ter sua fiscalização e cobrança delegadas aos Municípios e ao Distrito Federal. Este trabalho examinou a adesão municipal a esses convênios e o impacto na arrecadação, analisou se os entraves processuais para os Municípios remeterem demandas aos órgãos federais desestimulavam a celebração de acordos, e avaliou o interesse processual da União em litígios de ITR sob delegação, à luz da Teoria Eclética da Ação, bem como a efetividade da diretriz constitucional de desestímulo a propriedades improdutivas. A pesquisa utilizou um estudo de caso, com base em dados e relatórios oficiais da Receita Federal do Brasil e referencial doutrinário jurídico. Os resultados indicaram baixa adesão municipal aos convênios, com quase 75% dos municípios sem acordo. A arrecadação do ITR, mesmo integralmente repassada, não justificou os investimentos municipais, e a manutenção da atuação processual pela União desestimulou a continuidade dos ajustes. Verificou-se que a União carecia de interesse processual nessas demandas, dada a ínfima representatividade do ITR na arrecadação federal e a ausência de proveito econômico-financeiro, o que impediu o cumprimento efetivo da diretriz constitucional de desestímulo à improdutividade rural. Concluiu-se que são necessárias modificações legislativas para que o ITR alcance seus objetivos de arrecadação e função social.

Palavras-chave: Arrecadação; Eficiência; Fiscalização; ITR; Municípios.

10 de setembro de 2026

Governança de Dados e Risco Financeiro no Setor Florestal: Evidências Empíricas em Perspectiva Brasil-Finlândia

A fragmentação informacional no setor florestal brasileiro constituiu o ponto de partida desta pesquisa, que investigou como a governança de dados impactou a capacidade analítica, o risco financeiro e a competitividade da gestão florestal, por meio de um estudo comparativo entre Brasil e Finlândia. Submeteram-se 332 documentos, incluindo 307 informativos CEPEA/Esalq/USP (2001–2025) e 25 relatórios setoriais (Bracelpa, ABRAF, Ibá, 2003–2025), a um pipeline de extração automatizado baseado em OCR, mineração de texto e expressões regulares, obtendo-se 13.059 registros estruturados. Realizou-se análise de sensibilidade do Valor Presente Líquido (VPL) e análise de sentimento léxica. Apenas 12,1% dos registros de custo continham Custo Operacional Efetivo preenchido, e nenhum apresentou margem líquida calculável. A incerteza nos dados de entrada oscilou o VPL de um projeto florestal em mais de R$ 20.000/ha, evidenciando a distorção da decisão orientada por dados quando a sofisticação algorítmica não substituiu a qualidade dos dados de origem. A análise de sentimento léxica confirmou a transição dos relatórios setoriais brasileiros de formato estatístico para promocional. Em contraste, o modelo finlandês demonstrou a viabilidade de uma governança integrada, com o inventário florestal consolidado como pilar de inteligência industrial. Os resultados indicaram que o fortalecimento da governança de dados constituiu pré-requisito para a transição do setor para um sistema de planejamento sustentado por evidências.

Palavras-chave: competitividade; fragmentação informacional; inteligência artificial; soberania digital; tomada de decisão.

Inscreva-se em nossa newsletter!

Receba conteúdos e fique sempre atualizado sobre as novidades em gestão, liderança e carreira com a Revista E&S.

Ao preencher o formulário você está ciente de que podemos enviar comunicações e conteúdos da Revista E&S. Confira nossa Política de Privacidade