Quando desenvolvemos produtos e serviços que visam obtenção de receita, temos diversas métricas que nos auxiliam a priorizar e descartar itens que devemos construir. Todavia, uma pergunta muito comum no nosso treinamento de CSPO e A-CSPO é: “Como faço para utilizar agilidade em demandas regulatórias / legais?”. Continue a leitura até o final e descubra!
O Que é uma Demanda Regulatória?
Se você nunca ouviu o termo regulatório, significa necessidades externas à empresa, normalmente vindas de órgãos governamentais, que obrigam organizações a adequarem seus produtos e serviços a normas e leis.
Por exemplo, o Banco Central do Brasil (BACEN) cria uma regra de proteção ao sistema financeiro e as instituições financeiras como bancos, caixas de depósito e fintechs têm que modificar sua forma de trabalho em um determinado período. Caso contrário, a organização deverá arcar com as consequências que vão desde advertências, multas até a suspensão das atividades.
Há áreas que estão mais suscetíveis à regulação. É o caso de empresas de telecomunicações com a Anatel, aéreas com a ANAC, energia elétrica como a ANEEL e por aí vai. Também há aquelas que devem se adequar às regulações para entrar em programas governamentais.
Por exemplo, se sua empresa quiser receber incentivos fiscais para se instalar na Zona Franca de Manaus, ela deverá seguir as regras da SUFRAMA (Superintendência da Zona Franca de Manaus).
O Problema com Demandas Regulatórias na Agilidade
Normalmente empresas e times que têm que atender demandas regulatórias vão para o tudo ou nada. Pegam todas as regras que devem alterar em sistemas, normas internas e procedimentos, criam um grande backlog e quando se pergunta: “Qual a prioridade de cada item do backlog?”, a resposta normalmente é: “Tudo tem a mesma prioridade.”.
O time fica doido sem saber por qual dos 100, 200, 1.000 itens vai começar. Aí, quando tudo é prioridade, nada é prioridade e, se ninguém prioriza, as pessoas vão priorizar ao seu bel prazer. Utilizando o método RMC (Regras da Minha Cabeça).
Você já sabe, mas não custa lembrar:
Além do Mega Backlog despriorizado, outra característica interessante dessas demandas é que quando elas finalmente chegam no time que deverá fazer as adaptações, depois de percorrer toda a estrutura da empresa umas vinte vezes, eles recebem informação que TUDO deverá ser feito em até 15-30 dias, caso contrário, a organização receberá uma multa astronômica e poderá até parar de funcionar.
Esse mesmo time não faz só isso, tradicionalmente ele recebe outras demandas vindas de vários lugares que também não podem parar. É um cenário de Armagedom. É doloroso, tem muita cobrança, normalmente até o nível de diretores se envolve nesse tipo de coisa.
Já passei por isso algumas vezes e gostaria de contar algumas experiências e dar algumas ideias para ajudar.
Como atender às Demandas Regulatórias com Agilidade
Considere o oposto do que as pessoas pensam. A Agilidade é a única coisa que pode te salvar da cobrança legal.
Formando um time realmente multidisciplinar
Dificilmente as demandas Regulatórias envolvem uma simples modificação de software. Elas são bem mais profundas do que isso. São necessárias novas normas internas para tratá-las, novos procedimentos e até mesmo treinamento das pessoas envolvidas.
Sendo assim, um time formado apenas por pessoas da TI não vai funcionar. Você precisa de pessoas que entendam de instruções normativas (juristas e administradores), Gestão de pessoas para administrar treinamentos e conscientização dos colaboradores, alguém com contato com a Alta Administração, pessoas de unidades impactadas diretamente e, lógico, pessoal de TI.
Se cada um desses grupos se comportar de forma independente, no final teremos uma grande bagunça. Como um jogo de encaixe onde um traz um quadrado para tentar encaixar em um triângulo. Não funcionará e o resultado será terrível para todos. Então, primeiro passo, crie um time verdadeiramente multidisciplinar.
Dependendo da alteração, seu time terá que contar com os advogados da empresa ou consultoria especializada. Lembro de quando houve a “extinção” do eSocial em 2019 e diversas empresas ficaram em uma situação de insegurança jurídica.
Como o experimento do Gato de Schrödinger, o eSocial ficou “extinto”, mas as empresas enviavam informações por ele, por não haver substituto. Os times que faziam a comunicação entre os softwares da empresa e o eSocial ficaram em um vácuo sem saber se continuavam o desenvolvimento de algo que estava morto e vivo ao mesmo tempo.
O apoio especializado ajudou principalmente a responder dúvidas quanto às consequências de parar a comunicação e desenvolvimento de sistemas de conexão com o eSocial que voltou a vida em menos de um ano.
Há momentos em que você terá que chamar pessoas de sindicatos. Principalmente quando a insegurança jurídica impacta seus colaboradores. Um exemplo foi quando, em 2021, órgãos governamentais tiveram que retornar ao modelo presencial durante a pandemia de COVID19.
Se livre da princesa Jaquê
No livro em que escrevi junto com Rodrigo de Toledo, Gestão de Portfólio Tradicional: Um Castelo de Mentiras, associamos as mentiras mais comuns na gestão de portfólios com personagens medievais.
Uma delas é a Princesa Jaquê. É aquela famosa história. Já que estamos mexendo em tal coisa por causa da demanda regulatória, vamos então acrescentar mais isso, isso e isso.
No final, seu backlog terá um monte de coisa que não é urgente e poderia ser implementada em um momento posterior, após a pressão do prazo do regulatório.
Um Product Owner (PO) terá que dizer muito não. Em momentos críticos, ele ou ela terá que multiplicar a quantidade de nãos.
Case: 97% de itens inúteis
Lembro de um caso em que tínhamos um período apertadíssimo para criar um software, treinar centenas de pessoas e ainda regulamentar internamente um processo de troca de equipamentos. No meio disso, foram pedidos 33 relatórios gerenciais.
Como as pessoas eram novas na empresa, não houve questionamentos. Sábados e domingos passaram a ser dia da semana e o expediente começava cedo e acabava quando acabava.
No final, colocamos um contador para ver quantos relatórios foram utilizados e dos 33 apenas 3 tiveram pelo menos um acesso. Desses, apenas 1 foi realmente utilizado durante toda a vida do sistema. Ou seja, 97% do trabalho foi totalmente inútil.
Case: Dica do Balu
Se você não entendeu a referência, Balu é o urso do desenho-musical Mogli o Menino Lobo. Em determinada parte do desenho ele canta a música: Necessário, somente o necessário que é uma tradução de The Bare Necessities de Terry Gilkyson.
Desde que passei por esse trauma dos 33 relatórios, passamos por outra experiência de, em 15 dias, criarmos um software que deveria integrar, durante as Eleições de 2012 diversos órgãos de segurança pública no Rio de Janeiro. Polícia Militar, Polícia Civil, Polícia Federal e Rodoviária Federal.
O estado pediu auxílio de tropas militares e havia integração com Exército e Marinha (na época responsável pela pacificação do Complexo do Alemão). Apesar do prazo esguio e ter que treinar as pessoas no uso de um software que ainda não existia, pediram Relatórios Gerenciais, Telão de Apresentação de Informação e mais algumas dezenas de funcionalidades que não eram essenciais para resolver a necessidade de integração.
Foram nãos, muitos, muitos, muitos nãos. Na prática, criamos um sistema de que criaríamos uma classificação binária de necessidades. Tudo que era essencial seria feito, o que não fosse essencial, poderia ser feito, um dia, sem compromisso, se ainda fosse relevante.
Infelizmente, não tem outra maneira. Se temos um backlog despriorizado e permitimos que itens não essenciais e desnecessários entrem nele, teremos que ordenar o caos de coisas que têm prioridades muito distintas.
OK. Temos um time multidisciplinar e nosso backlog conta apenas com o que é essencial, mas como priorizá-lo?
Mantenha o formato de Histórias de Usuário
Utilizei personas que eram os próprios auditores.
Exemplo: “Eu, enquanto Bruno Bacen, gostaria de verificar se o somatório das contas bate com os débitos gerados e cumpre o requisito disposto no art. 4º da Resolução 4192/13, tal que não se aplique as penalidades dispostas na Lei 9.613/98”.
É interessante vincular a legislação que está sendo mencionada à história.
Priorizando o que é essencial para atender à Demanda Regulatória
Esse é o momento de sangue frio, foco, racionalidade e total transparência. A falta de qualquer um desses atributos pode comprometer a priorização do que devemos fazer.
As pessoas que mais entendem do negócio e das exigências legais têm que estar no time ou pelo menos com o time nesse momento.
Se você tem voz nesse grupo, está na hora de deixar tudo às claras. Algo do tipo: “Pessoal, entendemos que atender a essa demanda regulatória é fundamental e queremos atendê-la por completo. Todavia temos um prazo curto e temos que priorizar nossas ações. Sendo assim, gostaria que, dentro tudo isso que nós temos que fazer…” agora vem algumas sugestões de perguntas que podemos utilizar:
- Dentre toda a regulamentação, quais itens que se não forem feitos irão nos trazer o pior impacto (multa mais alta ou suspensão das atividades)?
- Quais itens os reguladores, auditores, fiscais mais procuram durante uma avaliação? (a ideia aqui não é esconder coisas e sim atender aquilo que é mais procurado)
- Quais itens, se não forem atendidos, podem trazer consequências terríveis como mortes de pessoas, processos criminais, ambientais ou cíveis, prisões, indenizações, multas e depreciação da imagem da empresa?
- Quais itens, se não forem atendidos, podem representar um prejuízo financeiro tão grande que “quebraria” a empresa?
- Esses itens geram advertências antes de multa?
Na verdade, é a mesma pegada para priorizar produtos que geram valor, mas invertendo as perguntas.
Enquanto nos produtos e serviços que nós vendemos as perguntas normalmente giram em torno de quanto ganhamos com isso, Demandas Regulatórias normalmente é a pergunta inversa: Quanto perdemos se não atendermos tais itens?
Não é um exercício fácil e é comum as pessoas de negócio quererem tudo ao mesmo tempo, mas é um exercício essencial para atender a demandas dessa natureza. No final, você poderá dizer que no seu backlog teria uma priorização em algo como:
| Prioridade | Item | Motivo |
| 1 | Item A | Danos incalculáveis com perda de vidas, danos ambientais e possível falência da empresa. |
| 2 | Item B | Multa de $100 milhões. Ponto focal de auditores nas últimas 5 avaliações. |
| 3 | Item C | Multa de $90 milhões. Ponto focal de auditores nas últimas 4 avaliações |
| … | … | … |
| N | Item Z | Possível advertência. Não lembramos de auditores terem solicitado essa informação. |
Case: Segurança de Barragens de Hidrelétricas
Lá em meados dos anos 90, estive em um projeto de Segurança de Barragens de Hidrelétricas. Os métodos ágeis ainda não eram conhecidos aqui no Brasil, mas tínhamos algumas ideias que nos ajudaram muito a priorizar os itens que desenvolveríamos.
Também tínhamos que percorrer o interior de boa parte do Brasil e algumas cidades de Angola para ensinar as pessoas a operar os sistemas e estabelecer novos procedimentos.
Uma barragem hidrelétrica tem algumas centenas de equipamentos que medem se ela está estável ou corre algum risco de rompimento. Cada equipamento precisava de cálculos para avaliar a situação daquele ponto específico. Além disso, nem todos têm um padrão.
Há instrumentos americanos, brasileiros e até russos, mas todos tinham que dar um resultado padronizado na escala métrica.
Nossa primeira vontade era resolver os instrumentos mais práticos. Por exemplo, nível do Reservatório. É basicamente uma régua gigante que fica dentro do reservatório e diz quantos metros d’água tem ali.
Com algumas constantes e voilà. A implementação da equação era muito fácil. Se você comparar com os instrumentos de medição de deslocamento da barragem, era confrontar educação infantil com pós-graduação stricto-sensu 😁.
Todavia, a pergunta determinante que nos ajudou a priorizar o que faríamos primeiro foi: Quais informações sobre as medições que, se não a tivermos ou se elas estiverem erradas, podem fazer com que a barragem rompa, mate pessoas e destrua cidades inteiras?
Esse foi o direcionador que nos ajudou a sair do modo: “mais fácil primeiro”.
Mesmo em demandas regulatórias há descarte.
Em diversos projetos com demanda regulatória que participei, há descarte de itens. Alguns, os procedimentos e softwares existentes já atendem. Também há regras que não produzem efeito e regras contestáveis. Procure por elas.
Outro ponto que é comum, é irmos muito além do que a regra solicita. Uma vez estive em uma empresa que tinha que preparar um relatório para o órgão regulatório. As informações, quando impressas, davam um livro. Na verdade, o órgão pedia apenas 1/5 de todas as informações que estavam ali.
Passado mais um tempo, o órgão padronizou e pediu para enviar os dados por XML já que as empresas mandavam muito mais do que era necessário e isso tomava um tempo enorme dos auditores. Mais uma vez, pense na Dica do Balu.
Outra forma que serve para descarte é quando o item regulatório não é suficientemente claro. Através da leitura de pessoal especializado, não se chega a um entendimento sobre o que deverá ser feito ou porque deverá ser feito. Normalmente tais dúvidas são enviadas ao órgão regulador e levam um bom tempo para receberem a resposta.
Quando há vários demandantes regulatórios
Eu me deparei com vários times que tinham esse fator complicante. Um desses times tinha 3 tipos de auditorias (CMMI interno, Sarbanes-Oxley e Ministério de Minas e Energia). Isso já cria uma vantagem para fatiamento de histórias pois cria pelo menos três fatias. Qual a mais prioritária? Aquela cuja multa era mais pesada.
Conclusão
Espero que essas dicas sejam suficientes para compreender que a Agilidade pode ser utilizada para demandas regulatórias. Na verdade, ela é fundamental para atender demandas regulatórias. Tem alguma experiência legal para compartilhar conosco? Conte aqui nos comentários.
