AGILE METHODOLOGY APPLIED TO AN ACTIVITY MANAGEMENT SYSTEM – A CASE STUDY IN THE PRODUCT DATA MANAGEMENT SECTOR
REGISTRO DOI:10.5281/zenodo.10938613
Alana G. Rodrigues1
Christian Augusto Guimarães Vargas Carneiro²
Cecilia Toledo Hernández³
Vanessa Aparecida de Sá Machado⁴
Camila Aparecida Maciel da Silveira⁵
Resumo
O objetivo deste trabalho é apresentar um sistema para gerenciar as atividades do setor de Gerenciamento de dados do produto de uma empresa do segmento automobilístico, com foco no escopo para melhorar os processos de organização das atividades e garantir as entregas dos projetos, cumprimento dos cronogramas e viabilizar negociações. Diante da alta demanda de projetos complexos e alto volume de atividades não era possível manter uma boa rastreabilidade e organização das tarefas. Este estudo implementou um novo sistema, baseado nos preceitos do PMBOK e aplicação da metodologia ágil. O Guia PMBOK possibilitou a extração de informações e compreensão do que cada área do conhecimento precisa abordar, controlar e desenvolver. As áreas escolhidas para este estudo de caso trazem sinergia com o framework Scrum, pois este possui foco nos escopos, cronograma e comunicação. A criação do novo sistema obteve ótima aceitação em outros departamentos. Os resultados foram ganhos nas funcionalidades de entrega da documentação de forma digital, emissão de suplementos, acompanhamento online, consultas para auxílio em reuniões de projeto e ganho em agilidade para realizar correções nas documentações técnicas do produto. Após implementação, os relatórios saem com as informações mais fáceis de manipular e construir os indicadores e, atualmente, é uma das principais fontes de informação da empresa.
Palavras-chave: PMBOK, Metodologia Ágil, Gerenciamento de escopo, Gerenciamento do cronograma, Gerenciamento da comunicação.
1 INTRODUÇÃO
A pandemia de Covid 19 teve um grande impacto nas empresas sendo necessário criar um novo modelo para realizar atividades como cadastros e comunicação. Muitas atividades que anteriormente eram realizadas de forma presencial foram alteradas para o modo remoto, a vídeo conferência passou a ser muito utilizada. O aumento de flexibilidade e a automação dos processos foram mantidos pela maioria das empresas após a pandemia.
O trabalho remoto foi adotado imediatamente por muitas empresas e exigiu mudanças imediatas nos sistemas de gerenciamento exigindo plataformas e ferramentas que permitissem com que a equipe colaborasse de qualquer local (MAHFUZUL; SHAMIM, 2022).
As empresas tiveram de repensar suas prioridades e seu plano de negócios impactando diretamente no sistema de gerenciamento de atividades, havendo a necessidade de ajustar o foco e a alocação de recursos em diferentes projetos e atividades (FIGUEIREDO; MARQUES, 2023). A maior flexibilidade em relação aos prazos e entregas gera necessidade de ajustes nos cronogramas impactando o sistema de gerenciamento de atividades. Assim como a introdução de ferramentas de automação para agilizar os processos e aumentar a produtividade (FIGUEIREDO; MARQUES, 2023).
As empresas adotam metodologias ágeis em seus processos devido a crescente complexidade dos projetos e a necessidade de entregas rápidas e com alta qualidade. Dentre as diversas aplicações das metodologias ágeis, destaca-se a sua utilização em sistemas de gerenciamento de atividades, que tem por objetivo organizar e acompanhar as tarefas e atividades dos projetos em andamento (RACHID; STOPA, 2019).
Diante dos fatos apresentados fica claro que a pandemia de Covid 19 trouxe mudanças nas relações empresariais e impacto no gerenciamento de atividades de empresas com alta demanda de projetos. Neste estudo houve a necessidade de agilizar e flexibilizar processos internos por meio de metodologias ágeis, reduzindo a burocracia e a inflexibilidade.
Sendo assim, esse estudo de caso que foi realizado durante a pandemia de Covid 19, tem como objetivo apresentar as vivências e experiências durante a implementação de um novo sistema de gerenciamento das atividades do setor de Gerenciamento de dados do produto, utilizando a metodologia Scrum. Trazendo como vantagens como entregas contínuas, ganhos incrementais que acabam agregando valor ao produto e visibilidade no progresso do projeto.
Como o setor estava desenvolvendo um sistema que poderia apresentar várias mudanças ao longo do processo de desenvolvimento, a metodologia Scrum possibilitou trabalhar com essas incertezas sem prejudicar o andamento do projeto.
2 FUNDAMENTAÇÃO TEÓRICA OU REVISÃO DA LITERATURA
2.1 Gerenciamento de projetos
Durante a década de 1990, surgiu a metodologia ágil como uma proposta para reduzir a burocracia nos processos e uma resposta às metodologias tradicionais de gerenciamento de projetos (mais inflexíveis e lentos). Surgindo a necessidade de gerenciamento de projetos mais ágeis e flexíveis a metodologia ágil tornou-se amplamente conhecida, resultando na criação do “Manifesto Ágil” (GOES; COSTA, 2022).
Diferentemente do gerenciamento de projetos tradicionais, a metodologia ágil é uma abordagem que valoriza a flexibilidade e adaptação às mudanças durante o ciclo de desenvolvimento de um projeto, permitindo a realização de pequenos testes, reuniões, adaptações e correções até se chegar ao produto final (CATTO, 2022). Essa metodologia tem suas aplicações expandidas para diversas áreas e é caracterizada pela entrega de valor em espaço de tempo reduzido, alinhamento da equipe com os produtos ou serviços e interação com o cliente (CATTO, 2022). A abordagem ágil requer um ambiente favorável à melhoria contínua, priorizando entregas incrementais, sendo uma vantagem pela união das equipes, a diminuição da dependência das terceirizações e a mudança de foco do produto para o cliente (CATTO, 2022).
Sendo o gerenciamento de atividades uma prática fundamental para o sucesso de qualquer projeto, independentemente do seu tamanho ou complexidade. Ele envolve o planejamento, execução e controle de todas as tarefas e atividades necessárias para alcançar os objetivos do projeto dentro do prazo e orçamento estabelecidos (BARROS, 2021).
De acordo com o Guia PMI (2021), uma das principais referências em gestão de projetos, o gerenciamento de atividades envolve a definição das atividades necessárias para produzir os entregáveis do projeto, a sequência e relacionamentos entre as atividades, a estimativa de recursos necessários, à elaboração do cronograma e o controle das atividades durante a execução do projeto. As áreas de conhecimento do PMI (2021) são um conjunto de práticas e técnicas essenciais para o gerenciamento de projetos. Entre essas áreas, destacam-se três que são fundamentais para o sucesso do projeto e que foram escolhidas para este estudo: escopo, cronograma e comunicação.
Segundo o Guia (PMI, 2021), o gerenciamento de escopo é responsável pela definição, planejamento, execução e controle de tudo o que precisa ser feito no projeto, bem como o que está fora do escopo. É essencial para garantir que o projeto atenda aos objetivos definidos e que as entregas sejam adequadas (PMI, 2021).
Para o Guia (PMI, 2021) o gerenciamento de cronograma tem como objetivo a elaboração de um plano de trabalho que estabeleça as atividades e o tempo necessário para executá-las. O cronograma deve ser elaborado com base nas estimativas de duração das atividades e nas dependências entre elas (PMI, 2021).
De acordo com o Guia (PMI, 2021), o gerenciamento de comunicação envolve o estabelecimento de um plano de comunicação que define quais informações serão compartilhadas com quem, quando e como. O objetivo é garantir que as informações relevantes sejam transmitidas para todas as partes interessadas de forma clara e objetiva, minimizando possíveis mal-entendidos e garantindo o alinhamento do projeto com as expectativas das partes interessadas (PMI, 2021).
O sucesso do projeto depende da efetiva aplicação dessas áreas de conhecimento do PMBOK, bem como de outras áreas, como gerenciamento de riscos, recursos humanos, qualidade, entre outras. Cada área é importante e complementar, para garantir que o projeto seja entregue dentro do prazo, orçamento e escopo definidos, atendendo às expectativas das partes interessadas (PMI, 2021).
2.2 O método Scrum
O método Scrum é uma metodologia ágil, sua implementação torna mais flexível e rápida a mudança de cenários nos ciclos de vida de um projeto (BARROS, 2021). Sendo um framework ágil e interativo que traz otimizações nos processos de desenvolvimento e manutenção. A Figura 1 apresenta o framework do Scrum, onde visualiza-se as etapas, ferramentas e fluxo de dados.
Figura 1: Framework Scrum
Fonte: Voitto (2018).
No Product Backlog, é gerado uma lista de atividades pelos membros envolvidos. Nessa lista estão as sequências de atividades que compõem o projeto, precisa estar ordenada por prioridade, e colocar o que realmente é imprescindível para o projeto (GUARDIA; GUARDIA; MENDES FILHO, 2022).
Para que o Product Backlog seja colocado em prática são necessárias as etapas (PAULO et al., 2022):
- Inclusão: é a primeira etapa onde se transforma os desejos dos clientes em itens na lista de atividades do Product Backlog;
- Priorização: esta etapa deve ser baseada no valor gerado por cada um dos itens, ou seja, os que agregam mais valor devem vir em primeiro e precisa respeitar a sequência lógica de desenvolvimento do projeto;
- Refinamento: etapa importante que deve ser realizada de forma cíclica para garantir o sucesso do projeto;
- Estimativa: se refere a uma definição da quantidade de membros que devem ficar responsáveis por cada atividade, quantas horas devem ser dedicadas para a conclusão de cada item;
- Construção: nesta etapa mostra o quão os itens estão maduros para seguirem para o desenvolvimento e consequentemente sair do Product Backlog. Este é o momento de ação, de realmente desenvolver os itens no momento certo e adequado, de acordo com o Sprint previsto.
O Sprint Planning é o planejamento das empreitadas, um esforço com período de tempo bem definido onde será aplicado para gerar valor ao projeto, gerar entregas e colher um resultado bem determinado (MELO FILHO et al., 2023).
O Product Owner estará sempre buscando garantir que o projeto caminhe de acordo com o esperado ou de acordo com as expectativas do cliente, ele exerce a voz do cliente dentro do projeto (SOARES; PEREIRA, 2021).
O Daily Scrum trata-se de uma cerimônia diária, cerca de 15 minutos, para alinhamento continuo entre a equipe sobre as atividades (DE CARVALHO; MELLO, 2012).
O Sprint Review trata-se de uma cerimônia onde o time deverá apresentar todas as entregas naquele ciclo aos stakeholders. Por fim o Sprint Retrospective, é uma reunião de toda equipe para trocar feedbacks, acertos e erros naquele ciclo buscando a melhoria contínua (CARVALHO et al., 2020).
O Scrum Master é o coach do time, um facilitador, exerce um papel de mentor de todo o projeto. Ele é responsável por quebrar barreiras, facilitar processos e fazer as coisas caminharem dentro do projeto e principalmente ajudar os envolvidos a entenderem e abraçarem os valores, princípios e práticas do Scrum (SOARES; PEREIRA, 2021).
3 METODOLOGIA
Esta pesquisa possui abordagem qualitativa e natureza aplicada, sendo caracterizado por ser um estudo de caso. A metodologia utilizada foi a pesquisa bibliográfica em bases de dados como Web of Science e Scielo, pesquisa documental, pesquisa de campo e análise de conteúdo. Como parte da investigação, foram utilizados instrumentos de pesquisa para nortear, embasar e fortalecer a temática sobre a utilização de sistemas para gerências atividades e auxiliar nas tomadas de decisão.
Através de conversas com os colaboradores e trabalho diário na execução das atividades do setor, os dados foram analisados e interpretados de forma qualitativa, através da análise de conteúdo.
Para empresa na qual este estudo, do setor automobilístico, foi realizado era previsto uma alta demanda de projetos complexos, novas atividades e parceiros. No entanto, a forma como a empresa estava estruturada, o excesso de burocracia e alto volume de documentações técnicas do produto não era possível manter as atividades do setor organizada.
O sistema de registro de documentos utilizado não atendia às novas demandas, pois, permitia apenas registros de entradas e saídas e não dispunha de boa rastreabilidade. Os cadastros eram feitos de forma manual por um funcionário do setor, fazendo toda a análise, transferência dos dados das documentações entregues para o sistema. Essa atividade demandava um tempo considerável, além da possibilidade de perda ou erro de cadastro, duplicidade de registro, entre outros contratempos devido à alta quantidade de documentos.
Algumas simulações de atividades foram realizadas no antigo sistema para identificar se o resultado atenderia a demanda desejada, entretanto, não foi obtido o resultado esperado. Foram encontrados problemas como: ausência da identificação da empresa responsável pelo processamento da documentação técnica, não era possível ter uma atualização para a inclusão de anexos das modificações técnicas do produto e o fluxo de trabalho do sistema não suportaria a demanda diária. Um outro problema relevante foi a emissão de suplementos, pois era uma função realizada através de uma planilha de Excel, e como esses arquivos estavam armazenados no servidor, em alguns momentos apresentava erros ao abrir, não mostrava o aviso que já havia uma pessoa fazendo a utilização do mesmo e consequentemente gerava duplicidade de números, ocasionando retrabalhos e atraso nas entregas.
Para o desenvolvimento do novo sistema foi aplicado a metodologia Scrum, por ser um framework simples, ágil e interativo que possibilita a otimização no processo de desenvolvimento e manutenção de qualquer tipo de projeto complexo. Com uma abordagem iterativa e incremental, é capaz de reduzir os riscos nos projetos.
O contato inicial com o tema aconteceu com a primeira reunião da equipe, que teve como objetivo apresentar a metodologia Scrum e as ferramentas que seriam utilizadas. Para dar início ao projeto, realizou-se o primeiro Sprint Planning Meeting com a presença de todos os participantes e definição de quem exerceria cada função dentro do funcionamento do Scrum e quais os requisitos necessários para criação do novo sistema. Nessa reunião foi definido o Product Backlog, o cronograma do projeto e a periodicidade dos Sprints.
No planejamento dos Sprints, mediante uma reunião ficou definido que cada Sprint teria 4 semanas, devido à equipe atender outras demandas de desenvolvimentos e suportes locais, e quantos seriam necessários para completar o projeto. Em reunião prévia com as partes interessadas, foi solicitado que o sistema estivesse pronto em julho de 2020 e, conforme este direcional todo o planejamento dos Sprints foi feito para atender esta solicitação.
O projeto foi dividido em três Sprints, com Dayly Scrum entre as Sprints e uma de apresentação ao fim da Sprint 3. Pois, após o término do desenvolvimento do projeto é necessário apresentar, para as partes interessadas, os setores que passarão a ser usuários e a data de implementação.
As etapas de Sprint Review e Retrospective foram planejadas na mesma semana de execução do Sprint (1, 2 e 3).
Ao fim da última atividade do Sprint 3 foi realizada a apresentação do projeto para a equipe e a implementação do sistema.
4 RESULTADOS E DISCUSSÕES
Com a implementação do sistema, umas das atividades que mais foi beneficiada foi a de cadastro e planejamento da documentação técnica, pois, agora, cada solicitante faz o cadastro e entrega de sua documentação; não sendo mais centralizado em uma única pessoa. O que é feito agora é apenas a análise da documentação e, se estiver tudo de acordo, ela é enviada para processamento. A realização da entrega da documentação técnica de forma digital trouxe a facilidade de realizar a entrega de forma mais ágil e simplificada, pois, agora somente será feita a análise para envio ao processamento. Todavia, agora, basta que os setores internos façam um extrato do que foi planejado e se organizem para realizar o processamento e atender às datas planejadas. A comunicação nas etapas de cadastro, planejamento e processamento melhorou, pois, dúvidas podem ser sanadas rapidamente, correções na documentação podem ser realizadas com mais facilidade e, quando houver correções na documentação técnica, basta que seja realizada a entrega de uma nova versão. A interação entre engenharia e o setor de Gerenciamento de Dados do Produto melhorou a performance na troca de informações e consequentemente o processamento das atividades. Com os relatórios já criados para controle interno do setor, as reuniões de projetos ficaram mais dinâmicas com a apresentação de status de projetos, para mostrar para o time como estava a etapa de processamento da documentação técnica. Dessa forma, estratégias foram elaboradas, prazos foram negociados e, assim, os objetivos foram alcançados e todos os projetos foram devidamente atendidos.
Outras áreas apresentaram demandas de acesso ao sistema e foi criado um perfil de consulta das informações personalizado, ou seja, cada área possui uma personalização no perfil de acesso, logo, não possuem acesso completo a todas as informações. Dessa forma, um departamento não corre o risco de realizar alterações em documentos que não são de sua responsabilidade. Com a possibilidade de consolidar as informações descritas no Guia PMBOK, foram extraídas informações complementares para compreensão do que cada área do conhecimento precisa abordar, controlar e desenvolver. Áreas, como desenvolvimento do cronograma, da comunicação e do escopo, foram escolhidas para aplicação desta pesquisa. O guia PMBOK possui de forma detalhada as informações necessárias para cada etapa de desenvolvimento do projeto. Destaque para o desenvolvimento do sistema de controle de documentação técnica que foi realizado seguindo os processos do framework do Scrum, já que o mesmo foi criado para ser aplicado em desenvolvimento de softwares e projetos de alta complexidade. Este framework possui etapas e tarefas definidas que facilitam a organização das atividades e os papeis dos membros do time. Com todos estes pontos positivos, o sistema de gerenciamento da documentação técnica teve ótima aceitação não só por parte da engenharia, que foi beneficiada com a facilidade nas entregas e controle, como também por outras áreas que acessam o sistema para verificar status de entregas e outras atividades.
A metodologia Scrum traz vantagens como entregas contínuas, os conhecidos ganhos incrementais (sprints), e dessa forma serão agregados valores ao produto e visibilidade do progresso do projeto. Como essa ferramenta foi desenvolvida para lidar com ambientes de alta volatilidade, ambiente de alto grau de incerteza e, como o setor estava desenvolvendo um sistema que, pode apresentar várias mudanças durante o processo de desenvolvimento, essa ferramenta possibilitava trabalhar com essas incertezas sem prejudicar o andamento do projeto (CARVALHO et al., 2020).
Analisando o que foi mencionado percebe-se que está sendo abordado dentro deste framework as áreas do PMBOK relacionadas ao escopo, cronograma e comunicação.
4.1 Product Backlog
No Product Backlog estão os requisitos levantados nas reuniões internas do setor para o desenvolvimento do sistema. Segundo o PMBOK (2021) a EAP é uma decomposição hierárquica do escopo completo do projeto e, cada nível inferior representa um nível mais detalhado do escopo da entrega. Os projetos que utilizam as abordagens ágeis, iterativas ou incrementais devem utilizar a prática de decomposição em níveis de funcionalidades ou itens de Backlog. Essa decomposição deve ser realizada seguindo a ordem dos itens que apresentam maior complexidade, ou agregação significativa ou de categoria arriscada para a realização do projeto, estes devem ser priorizados no início do projeto), ou seja, o Product Backlog (PMBOK, 2021). A seguir serão listados os itens para que sejam adequados nas etapas do Product Backlog, já com um refinamento do que realmente deveria ser desenvolvido dentro do sistema.
4.2 Inclusão de itens ao Product Backlog
Com o objetivo de desenvolver bases de cadastro base, planejamento e processamento. O desenvolvimento da aba de “Cadastro Base” precisa conter informações que possibilitam a identificação do registro com informações importantes como tipo de documento, programa afetado (Descrição do Programa), descrição prévia da modificação (assunto), nível de liberação, conta de pagamento do programa ou projeto (EJA), o tamanho do documento que ajuda no planejamento da demanda e o engenheiro responsável e se afetará a ilustração técnica do produto. A Figura 2 mostra a ilustração do esboço de como deverá ser a aba “Cadastro Base”.
Figura 2: Esboço aba Cadastro Base
Fonte: Autores (2024).
Com essas informações sobre a documentação que está sendo entregue para o processamento no setor, é possível fazer uma breve análise e planejar o início do processamento.
Depois da análise da documentação técnica se faz necessário uma aba separada para planejamento, sendo realizado: escolha da empresa que será responsável pelo processamento, definir o prazo de execução para cada etapa, informar a quantidade de peças novas que a documentação possui, classificar a prioridade da documentação, classificar a qualidade da documentação recebida, escolher a complexidade para realizar o processamento, colocar alguma orientação para o analista que fará a análise e processamento. A Figura 3 traz um esboço da aba “Planejamento”, exemplificando como ficará a ilustração dos campos e preenchimentos.
Figura 3: Esboço aba Planejamento
Fonte: Autores (2024).
A Figura 3 apresenta uma aba com parâmetros já definidos entre uma data e outra, ou seja, somente uma data é preenchida e as outras duas são preenchidas automaticamente de acordo com o intervalo de dias inseridos.
A aba de “Processamento” é destinada para trazer o fluxo de trabalho operacional da documentação e, foi necessário colocar uma coluna que informe a empresa que está realizando determinada etapa, dessa forma, é possível identificar quais empresas, quais os responsáveis pelas etapas e a data que trabalharam no processamento da documentação. A Figura 4 exemplifica um esboço de como deverá ser a tela de processamento.
Figura 4: Esboço aba Processamento
Fonte: Autores (2024).
Nessa aba, constam informações relacionadas à numeração do documento, a data em que foi realizada a ação, o responsável pela ação, uma coluna destinada para mostrar quando ocorreu uma alteração na etapa. Na aba de processamento é possível que o analista preencha um checklist, informando todas as ocorrências encontradas durante o processamento do documento e, consequentemente, essas ocorrências serão transformadas em um indicador de qualidade.
4.2.1 Desenvolver opção para cadastrar novos projetos.
Os novos projetos recebem no sistema uma descrição, um código para abertura de conta de pagamento e um código para que seja utilizado nos sistemas para realizar as modificações dos produtos. Esse código do projeto é chamado de Evento (TESTE), que possui a finalidade de identificação do projeto dentro dos sistemas e gerar suplementos para a documentação técnica.
Um dos itens levantados para o novo sistema foi a opção de cadastrar informações de novos projetos para que posteriormente essas informações sejam utilizadas na emissão de suplementos de documentação técnica de modificação do produto. A Figura 5 mostra um esboço de como será a tela de cadastro de novos programas.
Figura 5: Esboço tela de emissão de suplemento
Fonte: Autores (2024).
Todos os programas cadastrados possuem um período de data de utilização de acordo com seus respectivos cronogramas. Os times de projetos solicitam um status de andamento das entregas e processamento das documentações técnicas e, quando o prazo de realização está próximo de finalizar, as áreas pendentes são alertadas para que ao final do prazo o Evento seja desabilitado para utilização. Dessa forma não será possível realizar a entrega de documentos fora do prazo tão pouco o processamento.
4.2.2 Desenvolver opção para emitir suplementos para elaboração da documentação técnica.
Como já explicado no tópico anterior, todo novo projeto recebe um código para realização das modificações do produto dentro do sistema e essas modificações são realizadas por meio da documentação técnica. Estes documentos recebem uma identificação utilizando o código do projeto e mais um número sequencial, como pode exemplo “TESTE-0001”, sendo a parte “TESTE” o código do projeto e “-0001” um número sequencial, um contador. Estes números são chamados de suplementos de projeto, ou seja, cada documento possui suplementos distintos que não podem ser duplicados ou o mesmo ser utilizado por dois ou mais setores de engenharia.
Nas reuniões de elaboração dos requisitos, esta função foi incluída com a finalidade de facilitar e agilizar as atividades de emissão de suplemento do programa para a documentação técnica pois, essa função era realizada através de uma planilha de Excel e, como estes arquivos estavam armazenados no servidor, em alguns momentos apresentava erros ao abrir, não mostravam o aviso que já havia uma pessoa fazendo a utilização entre outros. Havia reclamação de que os solicitantes não estavam conseguindo emitir suplemento devido a planilha estar sendo utilizada por outro usuário e, consequentemente, gerando problemas. Com tantas reclamações esta função foi um dos pontos que mais trouxe benefício para o time de trabalho.
A Figura 6 mostra um esboço de criação da tela de emissão de suplementos de programa, que traz informações já cadastradas previamente no Cadastro de Programa. O campo assunto está disponível para inserir uma descrição mais familiar e direta para o solicitante. Após o preenchimento do assunto o solicitante precisa clicar em solicitar para que seja gerado um suplemento do programa, que no caso foram os TESTE-0001 e TESTE-0002, registrado o assunto, o emitente, a data de emissão e o setor ao qual o solicitante está cadastrado.
Figura 6: Esboço da função de solicitação de suplemento
Fonte: Autores (2024).
Com essa função no sistema, foram eliminadas as planilhas de Excel que faziam o controle desses suplementos emitidos e utilizados. Problemas de funcionamento como o solicitante utilizar um suplemento, no qual já estava destinado a outro setor, foi resolvido. Antes, no momento da entrega era feita a detecção de duplicidade e, uma das partes era prejudicado com um retrabalho e, consequentemente atraso na entrega. Agora com a informação no sistema mesmo se um solicitante tentar utilizar o suplemento de outro setor, a opção de visualização e cadastro não estará habilitada, ou seja, não será possível. Essa foi uma das regras solicitadas para a criação dessa opção.
4.2.3 Desenvolver opção para cadastrar empresas terceirizadas.
A atividade CORE do setor é análise e processamento da documentação técnica, ou seja, a parte operacional é realizada por uma empresa prestadora de serviços, terceirizada. A terceirização não é exclusividade do setor de Gerenciamento de Dados do Produto e outros setores também possuem empresas contratadas para prestação de serviço. Como o sistema estava para se tornar o local para armazenar a documentação técnica, isso significava que, as outras empresas prestadoras de serviços de outros setores, também entraram nessa etapa de cadastro.
Com o desenvolvimento de função de “cadastro das empresas terceirizadas” possibilitou a identificação de quem realiza as entregas e também qual seria a empresa responsável pelo processamento interno do setor, ou seja, com uma só função seria possível identificar tanto internamente quanto externamente.
O desenvolvimento dessa função foi incluído na lista de requisitos para identificação das novas empresas que prestariam serviços internamente em novos projetos e atividades. Dessa forma é necessário um controle para organizar e direcionar corretamente as atividades.
A Figura 7 mostra um esboço de cadastro de empresas e quais dados foram solicitados para cadastro.
Figura 7: Esboço tela de cadastro de empresas
Fonte: Autores (2024).
Um ponto importante para esta função de cadastrar as empresas terceirizadas é que o setor ganha a autonomia para administrar, ou seja, pode-se fazer a atualização dos dados quando necessário. Em alguns sistemas já desenvolvidos e utilizados esta função “cadastrar e editar”, não estava disponível, sendo necessário solicitar suporte técnico de TI para manutenção dos dados no sistema.
4.2.4 Desenvolver opção para entregar a documentação técnica de forma digital
Desenvolver a função de entrega da documentação técnica de forma digital foi uma quebra de paradigma marcante para todo o setor de engenharia pois, no começo das discussões a ideia não foi bem recebida, gerando desconforto. Mas com a chegada da pandemia, o sistema ainda não estava totalmente pronto, as entregas foram feitas via e-mail, o que não trouxe benefícios e sim problemas.
O recebimento da documentação técnica por e-mail trouxe problemas, entre eles a falta de cadastro devido esquecimento, cadastro incorretos (pois o registro era feito manualmente e erros de digitação aconteceram), alta demanda de cadastros para uma única pessoa realizar entre outros.
Com o desenvolvimento da função de armazenamento de documentos no sistema haveria ganhos como rápida entrega e fácil cadastro pois, cada solicitante faria o cadastro de sua documentação. Isso agiliza o processo de análise para planejamento, os documentos são rapidamente colocados para processamento ou devolvidos para retrabalhos.
A Figura 8 apresenta o esboço de como funciona a entrega, o que pode ser armazenado e o que está disponível para acesso.
Figura 8: Esboço função anexar arquivos
Fonte: Autores (2024).
O sistema se tornou o veículo de entrega das documentações técnicas do produto, o que antes era feito por uma pessoa uma vez por dia, agora fica armazenado direto no sistema facilitando a comunicação, os times possuem rápido acesso a informação para iniciar suas atividades. O armazenamento acontece no momento da entrega da documentação pelo solicitante, sendo a etapa ilustrada na Figura 9 realizada pelo solicitante. Após salvar a documentação ganha o status de “pendente planejamento” significando que foi entregue e está na responsabilidade do setor de GDP.
4.2.5 Desenvolver opção para criar perfis de atuação no sistema.
A função de criação de perfis para o sistema possui a finalidade de separar e escolher o que cada usuário poderá executar no sistema sem prejudicar o andamento da atividade e preservar a integridade das informações cadastradas. A criação de perfis promove autonomia possibilitando que outros departamentos possam interagir no sistema e realizar a entrega da documentação técnica. Esta função tem um importante papel no sistema pois, possibilita habilitar quais telas do sistema podem ser acessadas, administrar o que pode ser visualizado/editado e principalmente quem pode realizar determinadas etapas. A Figura 9 mostra o esboço de como funciona a tela de criação de perfis.
Figura 9: Esboço da função criação de perfis
Fonte: Autores (2024).
Esta função possibilita a criação de perfil personalizado para cada tipo de atividade e setor. Alguns setores não farão entregas e sim consultas sobre as documentações que devem ou deveriam ser entregues pelo setor de engenharia, por exemplo.
Na Figura 9 está ilustrada a função dividida em duas opções, sendo elas, perfil e permissão, onde na primeira será feita a criação e na segunda será feita a marcação (atribuição) do que este perfil poderá realizar dentro do sistema. A Figura 10 ilustra a tela e como funciona a marcação (atribuição) de direitos no sistema.
Figura 10: Esboço atribuição de direitos no sistema
Fonte: Autores (2024).
Diante dessa função é possível criar perfis de consulta para determinados setores, como por exemplo “Manufatura”, que pode realizar uma consulta para verificar se a documentação já foi entregue ou processada sem realizar nenhuma alteração dentro do sistema.
4.2.6 Criar/alterar fluxos de processamento (Dynamic Workflow).
Na situação de adaptação e novas atividades no setor, ter flexibilidade e autonomia na alteração do fluxo de processamento do sistema tornou-se importante pois, as novas atividades que já estavam em discussão possuíam fluxos já definidos, mas, havia indefinição para outras e, essas teriam que entrar como registro no sistema e precisariam de um fluxo com descrições distintas para classificá-las no processamento. A Figura 11 mostra um esboço da ideia de como foi pensada a construção do fluxo de trabalho (workflow).
Figura 11: Esboço da ideia de fluxo de trabalho dinâmico
Fonte: Autores (2024).
A Figura 11 ilustra uma forma de como o fluxo deve ser, ou seja, o que será necessário para que o fluxo atenda à todas as atividades do setor, permitindo que sejam adicionadas as etapas de todas as atividades. Sendo assim, quando uma atividade for iniciada no sistema, será possível distingui-la pelas descrições às quais estão atreladas em cada OS ou documentação técnica e saber em qual time do setor a atividade se encontra. Os retângulos que possuem a borda pontilhada, estes representam a possibilidade de criação de uma nova opção nesta etapa do fluxo. Dessa forma é possível flexibilizar o fluxo para todas as atividades.
Em primeiro contato o time de desenvolvimento apresentou resistência e não concordou com o que estava sendo solicitado e, foram necessárias mais reuniões para maturar a ideia e convencê-los a comprar a ideia. Essa resistência era devido à quebra de paradigma de que, somente o time desenvolvedor estava autorizado à manutenção de fluxos dentro do sistema, mas, seguindo os procedimentos corretos e uma lógica, a função ganhou destaque até mesmo entre o time de desenvolvimento de outras unidades.
O fluxo criado dentro do sistema tem como função atender todas as atividades do setor, sendo de processamento da documentação técnica até Ordens de Serviços (OS). Ou seja, as opções de escolha devem conter opções para todas as atividades.
4.2.7 Novos relatórios
O item de novos relatórios possui uma característica para pessoas que não fariam nenhum tratamento de dados, e sim filtros já preparados e que pudessem ser convertidos em gráficos e relatórios para apresentação nos fóruns de projetos. Este item entrou na lista do Product Backlog com essa função, de ser de fácil acesso e direcionado.
O direcionamento dos relatórios que são exportados em formato Excel do sistema são para apresentar os dados pendentes dentro do setor para que o rastreamento seja acompanhado e devidamente reportado, em caso de atrasos, neste caso, os documentos pendentes (Backlog).
A Figura 12 esboça como a exportação dos dados deve ser, onde o usuário pode selecionar o ano do qual será feito uma avaliação, pode selecionar quais os dados serão analisados sendo os documentos já concluídos ou documentos pendentes dentro do setor, e clica em exportar.
Figura 12: Esboço da função exportar para Excel
Fonte: Autores (2024).
Com estes relatórios qualquer membro do setor teria acesso rapidamente aos dados para construir indicadores de performance e indicadores de documentos pendentes, por exemplo. Uma das condições para estes extratos é que sejam simples, contendo todas as informações sem a necessidade de fazer alguma alteração para se obter um resultado.
Espera-se que no extrato de documentos pendentes sejam encontradas todas as documentações técnicas pendentes de processamento dentro do setor independente da etapa. Assim é possível acompanhar o andamento do processamento dentro do setor, reportar eventuais atrasos e visualizar possíveis negociações de datas e prioridades.
4.3 Priorização (Grooming)
Um dos papeis do líder dos projetos é ser um visionário, ajudando a descrever pontos de valor, metas e objetivos do projeto, ser capaz de traduzir os sonhos a outras pessoas. Um líder deve ter foco nas coisas importantes, priorização constante do trabalho através de revisões conforme necessário para o projeto. O líder deve encontrar um método de priorização que funcione para pessoas e projetos (PMBOK, 2021).
A Figura 13 apresenta de forma ordenada os itens do Product Backlog que, ao serem cumpridos agregaram mais valor ao projeto.
Figura 13: Priorização dos itens do Product Backlog
Fonte: Autores (2023).
O líder do projeto é responsável por priorizar constantemente os itens do escopo, da mesma forma o Product Owner, que é o líder do projeto no Framework Scrum, faz a priorização dos itens do Product Backlog. O Scrum Master pode auxiliar na priorização para que seja respeitada uma lógica de construção do projeto e exercendo seu papel de facilitador (PAULO et al., 2022).
4.4 Planejamento dos Sprints
No planejamento dos Sprints são criados os backlogs da Sprint, com base na capacidade e habilidade da equipe Scrum que faz uma avaliação de quantos itens podem ser construídos no Sprint (PAULO et al., 2022).
A Figura 14 ilustra o planejamento completo do projeto e dessa forma é possível identificar que a data de implementação atende à data limite informada pelas partes interessadas (julho de 2020).
Figura 14: Cronograma completo de desenvolvimento do sistema
Fonte: Autores (2024).
A elaboração dos Sprints Backlog foi feita com a interação de todos dos membros do projeto (Product Owner, Scrum Master e Dev Team), dessa forma a construção incremental do projeto seria mais eficiente pois, com a experiência de todos, etapas como armazenamento da documentação no sistema seria um pouco mais demorada devido a disponibilidade de servidor.
Apresentando o cronograma de forma segmentada por Sprint, a Figura 15 ilustra o planejamento de execução do Sprint 1. Este planejamento possui os itens que foram escolhidos para iniciar o desenvolvimento e etapas de teste para verificar o desenvolvimento e aderência.
Figura 15: Planejamento Sprint 1
Fonte: Autores (2024).
As etapas de Sprint Review e Retrospective estão na mesma semana para realizar as validações durante a execução do Sprint e verificar a necessidade de atualizações no Product Backlog.
No planejamento do Sprint 2 a etapa de desenvolvimento do fluxo de trabalho dinâmico está com 2 semanas, pois, na escolha dos itens do Sprint Backlog o Dev Team informou que esta função demandaria mais tempo e foi tratada como alta complexidade. Sendo assim, foram feitas adaptações no planejamento para respeitar as 4 semanas de duração do Sprint. A Figura 16 mostra o cronograma de planejamento do Sprint 2.
Figura 16: Planejamento Sprint 2
Fonte: Autores (2024).
Percebe-se que as etapas de teste e Sprint Review/Retrospective estão na mesma semana de realização, dessa forma o teste fica comprometido, mas, foi alinhado com o time que, em paralelo ao desenvolvimento dos itens do Sprint 3, os testes continuaram sendo realizados em um ambiente separado e os possíveis pontos de atualização seriam feitos na etapa do Sprint 3.
No planejamento do Sprint 3 estão os itens com menor complexidade para o desenvolvimento. De acordo com o Dev Team a função de criação de perfil faz mais sentido ao final para que sejam feitos os mapeamento dos campos já desenvolvidos nas etapas iniciais. A Figura 17 ilustra o cronograma do planejamento do Sprint 3.
Figura 17: Planejamento Sprint 3
Fonte: Autores (2024).
No Sprint final também está o item de desenvolvimento de novos relatórios que, para ser devidamente estruturado precisará de todo o processo de construção do fluxo de trabalho já em execução pois, para definir quais são as etapas de finalização e quais etapas serão tratadas como pendente, é necessário que as informações já estejam estruturadas.
4.5 Construção
Neste capítulo serão apresentados os cronogramas dos Sprints realizados, dessa forma será possível analisar se o planejamento dos Sprints foi eficiente, e identificar pontos que não foram levantados anteriormente. A Figura 18 ilustra como foi a realização do Sprint 1.
Figura 18: Cronograma Sprint 1 realizado
Fonte: Autores (2024).
Analisando o planejamento do Sprint 1, observa-se que a escolha dos itens para iniciar o desenvolvimento do projeto foi eficiente pois, não houve motivos que causassem atraso para o planejamento e que a data objetivo do projeto estava sendo respeitada.
O Sprint 1 apresentou um aspecto positivo para o início do desenvolvimento do projeto e isso motivou a equipe na realização dos próximos itens do planejamento dos Sprints restantes. Mas a Figura 19, que é referente ao Sprint 2, mostra que os itens de desenvolvimento do fluxo de trabalho dinâmico apresentaram atraso de uma semana e o item de armazenamento da documentação técnica também apresentou atraso mais acentuado e potencialmente prejudicial à data de objetivo do projeto.
Figura 19: Cronograma Sprint 2 realizado
Fonte: Autores (2024).
Conforme a Figura 19, pode-se constatar que pela realização do Sprint 2 a data objetivo do projeto foi comprometida de forma crítica e para mantê-la será necessária uma força tarefa para resolver os itens pendentes.
Realizando a verificação do item de fluxo de trabalho dinâmico, houve uma dificuldade de trazer o conceito flexível para a programação do sistema pois este foi o primeiro fluxo solicitado para o desenvolvimento a partir do usuário. Os demais sistemas são padronizados e não se alteram conforme necessidade, mas, sim realizando a abertura de um novo projeto ou solicitação de manutenção ao departamento de TI. O Dev Team realizou um trabalho de colaboração com outros grupos de desenvolvedores para trocar informações para elaborar a programação dessa nova função.
O desenvolvimento de fluxo de trabalho dinâmico ficou pronto para teste com uma semana de atraso e para não ficar aguardando a etapa de testes ser finalizada, o sistema foi redirecionado para um outro servidor para realizar os testes de funcionalidades para que o desenvolvimento pudesse continuar.
O desenvolvimento do item de armazenamento da documentação técnica, apresentou um atraso que surpreendeu a toda equipe. A função foi rapidamente desenvolvida e testada, porém, em um servidor temporário e para atender ao sistema. Foi constatada a necessidade de um novo servidor que atenda às especificações recomendadas pelo Dev Team. Para realizar a compra, primeiro foi realizado o processo de negociação dentro do setor de Compras, após isso a emissão do Pedido de Compras, autorizando a compra de um novo servidor. O que a equipe não estava prevendo foi a duração do processo de compras que teve a duração de um mês de negociação até o hardware ser entregue e configurado.
Devido aos fatos ocorridos no Sprint 2, foi necessário realizar uma força tarefa no Sprint 3 para mitigar os impactos de atraso na data de objetivo de implementação (julho/2020). Antes o sistema estava previsto para finalização na semana 27 que seria a última semana de junho, mas, com o atraso do processo de Compras a nova data objetivo de conclusão do sistema passou a ser a mesma data indicada pelas partes interessadas, a semana 30. A Figura 20 mostra o impacto nos planejamentos do Sprint 3.
Figura 20: Cronograma Sprint 3 realizado
Fonte: Autores (2024).
Pode ser observado na Figura 20 que, a etapa de testes teve duração de duas semanas ao invés de uma, isso se deve a realização de testes funcionais também do Sprint Backlog 2 (validar a função de armazenamento da documentação técnica) e Sprint Backlog 3 para validação completa dos itens desenvolvidos.
A reunião de Sprint Retrospective/Review foi realizada em uma semana, antes estava prevista para semana 27 e passou para semana 29. A etapa de apresentação do sistema desenvolvido para as partes interessadas e a comunidade foi realizada na semana 29 e na semana seguinte o sistema foi disponibilizado para utilização dos setores da companhia. Ou seja, a força tarefa realizada no Sprint 3 foi benevolente para manter a data objetivo do lançamento do sistema.
5 CONSIDERAÇÕES FINAIS
Com a implantação do sistema, umas das atividades que mais foi beneficiada foi a de cadastro e planejamento da documentação técnica. Com o novo sistema cada solicitante faz o cadastro e entrega a documentação, não ficando mais restrito. No sistema é feita a análise da documentação e, se estiver tudo de acordo, o planejamento e envio para processamento.
A realização da entrega da documentação técnica de forma digital, trouxe a facilidade de realizar a entrega de forma mais ágil e simplificada. No novo sistema basta que os setores internos façam um extrato do que foi planejado e se organizem para realizar o processamento e atender às datas planejadas.
A comunicação nas etapas de cadastro, planejamento e processamento melhorou, pois, dúvidas podem ser sanadas rapidamente, correções na documentação podem ser realizadas com mais facilidade e, quando houver correções na documentação técnica, basta que seja realizada a entrega de uma nova versão. A interação entre as áreas elevou a performance pela maior troca de informações e processamento das atividades.
Com os relatórios já criados para controle interno do setor, as reuniões de projetos ficaram mais dinâmicas com a apresentação de status de projetos e visão das etapas de processamento da documentação técnica. Dessa forma, estratégias foram elaboradas, os prazos foram negociados, os objetivos alcançados e os projetos devidamente atendidos.
Outras áreas apresentaram demandas de acesso ao sistema, sendo criado um perfil de consulta das informações personalizado, ou seja, cada área possui uma personalização no perfil de acesso. Assim, os departamentos não correm o risco de realizar alterações em documentos que não são de sua responsabilidade.
Com a possibilidade de consolidar as informações descritas no Guia PMBOK, foram extraídas informações complementares para compreensão do que cada área do conhecimento precisa abordar, controlar e desenvolver. Áreas, como desenvolvimento do cronograma, desenvolvimento da comunicação e desenvolvimento do escopo, foram escolhidas para aplicação desta pesquisa.
Com todos estes pontos positivos, o sistema de gerenciamento da documentação técnica teve ótima aceitação não só por parte da engenharia, que foi beneficiada com a facilidade nas entregas e controle, como também por outras áreas que acessam o sistema para verificar status de entregas e outras atividades.
REFERÊNCIAS
BARROS, M. F. Desenvolvimento de um sistema para gerenciamento de atividades complementares Desenvolvimento de um sistema para gerenciamento de atividades complementares. Disponível em: <https://dspace.uniceplac.edu.br/bitstream/123456789/918/1/Mateus Ferreira Barros_0008186_Allan Welerson Gonçalves da Silva_0007890_Guilherme Rodrigues de Carvalho Oliveira_0007940.pdf>. Acesso em: 25 abr. 2023.
CARVALHO, F. DOS S. et al. Práticas ágeis para gestão de projetos baseadas no PMBOK guide, no agile practice guide e na metodologia scrum: uma análise da aplicabilidade em um projeto-piloto de uma organização pública. Revista de Ciência da Computação, v. 2, n. 1 SE-, p. 53–60, 13 maio 2020.
CATTO, S. L. A Utilização da Metodologia Ágil em Projetos do Segmento Industrial Automotivo The Use of Agile Methodology in Projects in the Automotive Industrial Segment. v. 5, n. 1, p. 1–16, 2022.
DE CARVALHO, B. V.; MELLO, C. H. P. Aplicação do método ágil scrum no desenvolvimento de produtos de software em uma pequena empresa de base tecnológica. Gestão e Produção, v. 19, n. 3, p. 557–573, 2012.
FIGUEIREDO, P. S.; MARQUES, F. T. Challenges to agile software project management practices in the context of the COVID-19 pandemic. p. 1–20, 2023.
GOES, R. DE S.; COSTA, I. Agile portfolio management and knowledge management in digital transformation: a systematic literature review / Gestão ágil de portfólio e gestão do conhecimento na transformação digital: uma revisão sistemática da literatura. Brazilian Journal of Development, v. 8, n. 4, p. 28283–28299, 2022.
GUARDIA, S.; GUARDIA, M.; MENDES FILHO, L. Proposta de framework para desenvolvimento de trabalhos científicos baseada na metodologia Scrum. Metodologias e Aprendizado , v. 5, n. SE-Artigos, p. 15–32, 3 jan. 2022.
MAHFUZUL, M.; SHAMIM, I. CENTRAL ASIAN JOURNAL OF THEORETICAL AND APPLIED SCIENCES The Effects of COVID-19 on Project Management Processes and Practices. n. c, p. 221–227, 2022.
MELO FILHO, D. R. DE et al. Scrum Methodology: An ally in the implementation of LGPD. Research, Society and Development, v. 12, n. 4 SE-, p. e22712441189, 16 abr. 2023.
PAULO, P. et al. Association for Information Systems Association for Information Systems Metodologias Ágeis Baseadas em SCRUM: Uma Revisão Metodologias Ágeis Baseadas em SCRUM: Uma Revisão Sistemática da Literatura Sistemática da Literatura. 2022.
PROJECT MANAGEMENT INSTITUTE. Padrão de gerenciamento de projetos e Guia do conhecimento em gerenciamento de projetos (Guia PMBOK). 7ª edição. Newtown Square, PA: Project Management Institute, 2021.
RACHID, C. L.; STOPA, G. R. Scrum: Metodologia Ágil Como Ferramenta De Gerenciamento De Projetos. CES Revista, v. 33, n. 1, p. 302–323, 2019.
SOARES, G. B. V.; PEREIRA, T. F. Case study on the application of Scrum methodology in a technology startup of Minas Gerais . Research, Society and Development, v. 10, n. 3 SE-, p. e9410313064, 8 mar. 2021.
1 Pós-graduada no MBA em Gestão de Projetos da UFF Campus Volta Redonda. E-mail: alana.grodrigues@hotmail.com
2 Discente do programa de Doutorado em Engenharia da UNESP/FEG. E-mail: camila.a.silveira@unesp.br
3 Discente do programa de Doutorado em Engenharia de Produção do CEFET/RJ. E-mail: vanessa.machado@aluno.cefet-rj.br
4 Docente da Universidade Federal Fluminense. E-mail: ctoledo@id.uff.br
5 Docente da Universidade Federal Fluminense. E-mail: christianvargas@id.uff.br