Por Ivsen Platcheck, MSC. ENG.

27/04/2023

Apresentação

Entre 2001 e 2021 estive trabalhando no cargo de Analista de Sistemas em uma empresa estatal. Omito o nome para não gerar qualquer desconforto ou arriscar ultrapassar os limites legais. Neste período, participei como líder e/ou membro de times de projetos de vários aplicativos e serviços complementares ao ERP da empresa, buscando automatizar e melhorar processos.

Por alguns anos, estive ligado ao setor de Recursos Humanos (RH), para o qual desenvolvi algumas aplicações para substituir aquelas já existentes ou para suprir alguma lacuna sem atendimento pelo ERP ou programas complementares.

Depois de terminar um projeto bastante malsucedido, que seu muito trabalho e nunca ficou sequer próximo de atender às necessidades da empresa, me pediram para comandar a construção de um novo sistema de gestão de benefícios aos empregados.

Foi numa época em que eu estava começando a ter contato mais formal com as chamadas metodologias ágeis, depois conheci o Manifesto Ágil e seus desdobramentos. Tive contato também com frameworks como Extreme-Programing (XP), principalmente, e conheci vagamente o framework SCRUM.

Comecei a estudar mais a fundo o SCRUM, e resolvi propor o uso de algumas de suas técnicas, na construção do sistema de gestão de benefícios, o que nada mais era do que um programa para fazer os cálculos dos benefícios, alimentar as verbas referentes, à folha de pagamentos, além de gerar o arquivo de dados para envio dos dados ao provedor destes benefícios.

Porém, a minha chefia foi contra o uso de técnicas ágeis. Em vista disso, chamei para uma reunião, a chefe do setor de Recursos Humanos, responsável pela administração destes benefícios. Para evitar os problemas que tivemos no projeto anterior, eu gostaria de usar algumas técnicas que expliquei a ela.

Ela teria que bancar comigo esta decisão, e ela aceitou me dar todo o apoio. Apenas não contamos a ninguém, que as técnicas usadas seriam aderentes ao framework SCRUM.

Eu assumi a posição de Scrum Master, acumulada pela de Desenvolvedor. A chefe do RH, mesmo não sabendo exatamente o que era, assumiu um papel com as características de um Product Owner (Dono do Produto), e algumas pessoas do setor de RH fariam parte do time de desenvolvimento comigo, para fazer os testes e validações.

O sistema original usado pela empresa tinha problemas estruturais e de programação. O sistema até então precisava de uma janela de sistema que variava de 4 a seis horas para execução. Portanto, para não interferir nos processos diários da empresa, seria executado ao longo da noite.

Na manhã seguinte os resultados eram auditados e, com certeza, correções e intervenções manuais nos documentos e registros gerados se tornavam imperioso. Após as alterações, nova execução e apenas no dia seguinte, seria possível nova investigação dos resultados. Todo o processo gerava desgaste, angústia, e muitas vezes intervenções manuais no Banco de Dados e nos relatórios gerados. O que é totalmente inadequado para que a precisão dos dados, além de muitos erros deixados para trás por omissão involuntária, ou cansaço e desânimo.

Primeiro Passo – Ideação e solicitação

Conversando com os responsáveis pelo RH, estes decidiram partir para uma solução totalmente nova, partindo apenas das bases legais e dos registros de colaboradores, visando um sistema mais preciso, com algum mecanismo de crítica aos dados armazenados e, se possível, processamento mais rápido.

Nesta etapa, eu solicito a todos os que participarem do processo de ideação e inovação fizessem um pequeno texto com os objetivos básicos para o novo sistema a ser desenvolvido. Este artefato é uma ideia pessoal de como iniciar o processo, e eu o chamo de Estória de Usuário Textual. Um texto onde são colocados os principais desejos e objetivos, inicialmente identificados.

Nesta época, eu ainda estava começando a ler sobre o Pensamento Ágil, SCRUM, e comecei a criar minha própria visão e meu próprio fluxo de trabalho para levar a cabo um projeto. Eu já havia feito treinamentos em gestão de projetos usando outros frameworks e metodologias, e decidi usar os artefatos, técnicas, ferramentas e princípios que mais se adequassem à natureza de cada projeto.

De posse dos documentos, elenquei as principais características, funcionalidades e regras a serem observadas no projeto.

Os primeiros objetivos macros, concernentes à organização, foram escritos, e como estes seriam avaliados para confirmação de atendimento. Todo o processo, com a participação, anuência e aceitação por parte dos interessados já identificados, os quais podemos chamar de Stakeholders, uma identificação comum para designar os interessados no projeto, seja líderes dentro da organização, responsáveis pelo processo a ser afetado, usuários do produto a ser gerado, entre outros menos importantes, mas que possam de alguma forma influenciar no projeto em si. Quando comecei a estudar

De posse dos primeiros objetivos da organização serem identificados, estes são comunicados ao setor de Recursos Humanos. Neste setor, os Stakeholders definem, a partir dos objetivos iniciais prescritos pela organização, os seus objetivos particulares para a sua área dentro do setor.

Na época, eu ainda não tinha entrado em contato com a técnica dos OKRs, e, ao invés de Resultados-Chave, partimos direto para as atividades, as quais eu consegui, junto com três pessoas do RH indicadas para me assessorarem, incluindo a chefe da turma responsável pelos benefícios e seus colaboradores mais diretos e que conhecem bem as normas, regras e os aspectos legais, referentes à concessão dos benefícios, e como funciona o processo.

Preparando o trabalho

Inicialmente, fizemos junto uma lista do que precisaria ser feito. Primeiro, esquematizar as regras legais referentes aos benefícios concedidos pela empresa.

Segundo item seria esquematizar e organizar as normas internas da empresa, levando em conta as regras ditadas pela legislação trabalhista.

O próximo item seria análise do banco de dados da empresa para buscar todos os dados necessários para caracterizar os parâmetros de cada colaborador que tenha direito a receber os benefícios.

Fazer um piloto que busque todos os empregados, sem filtragem, análise ou crítica, que teriam direito à perceber os benefícios

Depois aplicar as condições legais e organizacionais que possam afetar no valor destes benefícios ou na negação da concessão, quando pertinente.

Implantar um por um, os filtros e condições para concessão ou negação, assim como algum desconto ou acréscimo aos valores.

Fazer as cargas das verbas pertinentes, no banco de dados da empresa, para reflexo no processo da folha de pagamentos

Fazer com que o programa ao ser executado, elimine todos os dados gerados, caso seja executado novamente, após testes, correções e ajustes, referente ao mesmo período concessivo.

Iniciando o desenvolvimento em si

Na época, eu tinha alguma noção, mas não tinha a certeza de ter construído, com a chefe do setor responsável pelos benefícios, o Backlog do desenvolvimento. Nesta altura, eu já havia aprendido a usar os princípios de ciclos curtos, entregas incrementais, fazer, testar e adaptar, corrigindo rotas se necessário.

No meu planejamento, eu ficaria com o desenvolvimento do código dos programas e rotinas, enquanto o restante do time ficaria com a incumbência dos testes de validação. Por minha determinação, e com anuência dos responsáveis, no RH, mantivemos o sistema antigo rodando para podermos fazer as checagens de resultados. Nos primeiros testes, faríamos com apenas uma unidade organizacional, uma vez que ainda não tínhamos o tempo de execução do novo sistema.

A cada ciclo, executávamos, buscávamos os resultados e eram efetivadas as checagens e validação dos dados gerados.

Cada ciclo, eu entregava uma nova funcionalidade, um novo filtro, uma nova regra implementada. As pessoas do RH não acreditaram muito quando os primeiros testes ocuparam uma janela de execução inferior a dois minutos.

A cada incremento, algumas correções se mostraram necessárias, os programas foram alterados, ajustados e entregaram os dados que deveriam entregar.

Finalizando o desenvolvimento

Com a aplicação totalmente montada, começamos a testar para mais colaboradores, até chegarmos a toda a empresa.

No princípio, as pessoas do RH ficaram céticas do funcionamento, pois levando em conta o sistema anterior que usava uma janela de seis horas de execução, o novo programa, para os mesmos mais de quatro mil colaboradores da época, uso uma janela de quinze minutos.

Após a análise dos dados, houve alguns ajustes a serem feitos, mas nada que tomasse mais do que um ciclo de desenvolvimento.

Conclusões finais

Conduzi todo o processo sem dizer, uma única vez, para qualquer pessoa, que estava usando técnicas que estaria aprendendo, naquele momento, lendo artigos e livros sobre agilidade, metodologias ágeis. Depois que tudo estava funcionando, sim, eu contei aos meus colegas de TI e às chefias que havia usado as tais técnicas ágeis.

Mesmo sem ter, na época, qualquer treinamento em agilidade, usei o que me pareceu lógico para a situação e levei o processo de forma a entregar, em quatro meses, um sistema muito mais robusto, eficiente e eficaz, ao mesmo tempo. Os colaboradores responsáveis pelo setor de RH ficaram muito mais aliviados, em trabalho, por ter uma solução que permitia a eles verificar a qualidade dos dados armazenados no Banco de Dados corporativo, corrigir distorções, e gerar mais valor para si próprios, para a empresa, e muito menos sobressaltos.

A execução em janelas que variaram de quinze a vinte-e-cinco minutos, devido à carga de trabalho do servidor, permitia a elas executar o programa, analisar os dados, corrigir, e executar novamente.