gestÃo de riscos e a integraÇÃo do modelo de...

TÚLIO MARCO MOTTA E OLIVEIRA

GESTÃO DE RISCOS E A INTEGRAÇÃO DO MODELO DE GESTÃO

ÁGIL EM UM GRANDE BANCO BRASILEIRO

São Paulo

2018




Trabalho de formatura apresentado à Escola

Politécnica da Universidade de São Paulo para

obtenção do Diploma de Engenheiro de

Produção.

São Paulo

2018




Trabalho de formatura apresentado à Escola

Politécnica da Universidade de São Paulo para

obtenção do Diploma de Engenheiro de

Produção.

Orientador: Prof. Dr. André Leme Fleury

São Paulo

2018

FICHA CATALOGRÁFICA

Oliveira, Túlio Marco Motta e Oliveira

Gestão de Riscos e a Integração do Modelo de Gestão Ágil em um Banco / T.M.M. Oliveira – São Paulo, 2018. 104p Trabalho de Formatura – Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia de Produção 1. Compliance. 2. Gestão de risco. 3.Metodologias ágeis. 4. Digitalização.5. Gestão de processos. I. Universidade de São Paulo. Escola Politécnica. Departamento de Engenharia de produção II. t.

Dedico à minha mãe, ao meu pai, aos meus amigos, ao meu professor

“Trata de saborear a vida; e fica sabendo, que a pior filosofia é a do choramingas que se

deita à margem do rio para o fim de lastimar o curso incessante das águas. O ofício delas

é não parar nunca; acomoda-te com a lei, e trata de aproveitá-la”

Machado de Assis

RESUMO

O mercado de bancos de varejo passa por uma forte onda de digitalização. Novas empresas de

tecnologia no mercado financeiro, as fintechs, estão criando alternativas competitivas aos

serviços e produtos oferecidos pelos bancos tradicionais. Frente a essas mudanças, um grande

banco de varejo reconheceu a necessidade de se adaptar, mas a complexidade dos sistemas da

organização tornava a reação lenta e ineficaz. Nesse contexto, a solução foi criar uma nova

plataforma de cartões de crédito, independente dos sistemas do banco. Ela está sendo construída

por equipes multidisciplinares seguindo métodos ágeis de gestão de desenvolvimento de

software. No entanto, o projeto ainda está sujeito às políticas da instituição, como a Avaliação

de Riscos para o lançamento de novos produtos. O objetivo deste trabalho é analisar e propor

soluções para a integração operacional do sistema de gestão de riscos do banco ao modelo de

Gestão Ágil. Isso significa garantir que os riscos relevantes sejam mapeados e prevenidos de

acordo com os processos do banco enquanto a equipe mantém sua capacidade de adaptação

conforme os princípios ágeis. Para tanto, foi seguido um procedimento estruturado de resolução

de problemas. Após uma revisão bibliográfica sobre os temas relacionados, os principais

problemas foram identificados. Em seguida, foi feito um aprofundamento de forma a

reconhecer seus aspectos e onde se mostravam mais relevantes. Daí, puderam ser isoladas as

causas raízes e, a partir delas, levantadas e selecionadas soluções. Essas soluções foram

implementadas e seus resultados verificados quanto à eliminação ou mitigação das causas. As

soluções possibilitaram a redução do tempo de ciclo do processo de Avaliação e Riscos, e

estruturaram práticas para prevenir o risco de não compliance. As demandas operacionais

relacionadas à gestão de riscos foram integradas aos métodos e ferramentas ágeis da equipe,

para os quais se desenhou um plano de evolução para a fase posterior ao lançamento da

plataforma. Concluiu-se que integrar o processo atual de gestão de riscos ao modelo de trabalho

da equipe do projeto atende aos interesses da organização, mas não chega a eliminar a causa

raiz do problema. Não há forma direta de se transformar recursos em um produto que os clientes

amam. O alinhamento da estratégia da organização com o design do produto ainda é incipiente,

então os métodos de gestão e o fluxo de desenvolvimento de produtos precisam evoluir.

Palavras chave: Compliance. Gestão de risco. Metodologias ágeis. Digitalização. Gestão de

processos.

ABSTRACT

The retail banking market is undergoing strong digitalization. New technology companies

specialized in financial markets, fintechs, are developing new competitive products and

services. Realizing those changes, a big retail bank recognized the need to adapt, but the

complexity of the organization's systems made it slow and ineffective. In this context, the

solution was to create a new credit card platform, independent of the bank’s systems. It is being

built by a multidisciplinary team following agile methods for software development. However,

the project is still subject to the institution's policies, such as the Risk Assessment for the launch

of new products. The objective of this work is to analyze and propose solutions for the

operational integration of the bank’s risk management system and Agile Methods. This means

assuring the relevant risks are mapped and prevented according to the bank’s existing processes

while the project team maintains its adaptation capabilities according to the Agile principles.

For this, a structured problem-solving procedure was followed. After a bibliographical review

on the related themes, the main problems were identified. Then, further inspection took place

to discover the problem’s main factors and the points where they were more relevant. From

there, the problem’s root causes could be identified and, from them, the solutions. The solutions

were implemented and its results verified for the elimination or mitigation of the causes. The

solutions enabled the reduction of the Risk Assessment process cycle time and developed

practices to prevent the risk of noncompliance. The process demands were integrated into the

team's methods and tools, for which an evolution plan was designed to be implemented after

the release of the platform. In conclusion, integrating the risk management process to the

project team work model is within the organization's interests, but it does not eliminate the root

of the problem. There is no direct way to convert money into a product that customers love.

The alignment of the organization’s strategy and the product design is still incipient, so the

managing methods and the product development process still need to evolve.

Key words: Compliance. Risk management. Agile methods. Digitalization. Process

management.

LISTA DE ILUSTRAÇÕES

Figura 1 - Exemplo de quadro de kanban ...................................................34

Figura 2 - Elementos gráficos principais do BPMN................................... 36

Figura 3 - Exemplos de Swinlanes............................................................. 37

Figura 4 - Diagrama de Ishikawa................................................................ 38

Figura 5 - Matriz Impacto x Esforço........................................................... 39

Figura 6 - Fluxo da Norma de AR .............................................................. 56

Figura 7 - Fluxo Estendido e AR .................................................................62

Figura 8 - Fluxo de Avaliação do Produto................................................. 65

Figura 9 - Fluxo de Detalhamento de Planos de Ação............................... 67

Figura 10 - Implementação de Itens de Backlog........................................ 68

Figura 11 - Integração dos Planos no Backlog........................................... 69

Figura 12 - Diagrama de Ishikawa - Avaliação do Produto....................... 73

Figura 13 - Diagrama de Ishikawa - Detalhamento dos Planos de Ação .... 75

Figura 14 - Diagrama de Ishikawa - Implementação dos Planos de Ação... 77

Figura 15 - Matriz de Impacto vs Esforço.................................................... 81

LISTA DE TABELAS

Tabela 1 - Cronograma de Desenvolvimento do Trabalho...................... 41

Tabela 2 - Exemplos de Condicionantes, Evidências e Planos de Ação.. 60

Tabela 3- Tempos de Fluxo de AR........................................................... 70

Tabela 4 - Critérios de RUT..................................................................... 80

Tabela 5 - Balanceamento de Condicionantes Estruturantes................... 85

Tabela 6 - Identificação de Item de Backlog (Antigo)............................. 89

Tabela 7 - Critérios de Priorização de Backlog (Antigo)......................... 90

Tabela 8 - Status de Item de Backlog (Antigo)........................................ 90

Tabela 9 - Identificação de Item de Backlog (Novo)............................... 90

Tabela 10 - Identificação Extra para Condicionantes (Novo).................. 91

Tabela 11 - Status de Item de Backlog (Novo)........................................ 91

Tabela 12 - Dashboard das Squads.......................................................... 94

Tabela 13 - Kanban de Negócios............................................................. 94

Tabela 14 - Kanban de AR....................................................................... 94

Tabela 15 - Kanban da Plataforma........................................................... 95

Tabela 16 - Critérios de RUT................................................................... 95

Tabela 17 - Critério de Risco................................................................... 96

Tabela 18 - Critério de Estruturante......................................................... 96

Tabela 19 - Novos Critérios de Priorização..............................................97

LISTA DE ABREVIATURAS E SIGLAS

6M Método, Mão de Obra, Meio Ambiente, Matéria Prima, Medidas e Máquinas

AR Avaliação de Riscos

BPMN Business Process Model and Notation

CV Comitê de Varejo

du Dias úteis

DV Diretoria de Varejo

FAQ Frequently Asked Questions

FCR First Contact Resolution

GA Gestor de Apoio

GRC Governance, Risk Management and Compliance

IBGC Instituto Brasileiro de Governança Corporativa

IFC Internacional Finance Corporation

ISO International Organization for Standardization

NBR Norma Brasileira

PMO Project Management Office

PO Project Owner

QC Quality Control

RUT Relevância, Urgência e Tendência

RUTn RUT de negócios

RUTp RUT da plataforma

SLA Service Level Agrement

SM Scrum Master

UX User Experience

WIP Work In Progress

SUMÁRIO

1. INTRODUÇÃO.................................................................................................... 23

1.1 CONTEXTO DO DESENVOLVIMENTO DO TRABALHO ................................. 23

1.2 PROBLEMAS ................................................................................................... 24

1.3 OBJETIVO DO TRABALHO .............................................................................. 25

1.4 JUSTIFICATIVA ............................................................................................... 25

1.5 ESTRUTURA DO TRABALHO .......................................................................... 26

2. REVISÃO BIBLIOGRÁFICA .............................................................................. 27

2.1 GOVERNANÇA, GESTÃO DE RISCO E COMPLIANCE .................................... 27

2.1.1 Compliance ................................................................................................... 27

2.1.2 Governança ................................................................................................... 28

2.1.3 Gestão de Risco ............................................................................................ 29

2.2 GESTÃO ÁGIL ................................................................................................. 30

2.2.1 O Manifesto Ágil ............................................................................................ 30

2.2.2 Scrum ............................................................................................................ 30

2.2.3 Kanban .......................................................................................................... 33

2.2.4 Scrumban ...................................................................................................... 34

2.3 GESTÃO DE PROCESSOS................................................................................. 35

2.3.1 Modelagem de processos de negócio ........................................................... 35

2.4 PROCEDIMENTO DE RESOLUÇÃO DE PROBLEMAS ..................................... 37

2.4.1 Diagrama de Causa e Efeito ......................................................................... 37

2.4.2 Matriz de Impacto x Esforço .......................................................................... 39

3. MÉTODO ............................................................................................................ 41

3.1 SISTEMÁTICA ADOTADA ............................................................................... 41

3.2 ESCOLHA DO TEMA ....................................................................................... 43

3.3 DEFINIÇÃO DOS OBJETIVOS ........................................................................ 44

3.4 MAPEAMENTO DOS PROCESSOS................................................................ 44

3.5 IDENTIFICAÇÃO DOS PROCESSOS CRÍTICOS ........................................... 45

3.6 IDENTIFICAÇÃO DAS CAUSAS RAÍZES ........................................................ 45

3.7 LEVANTAMENTO DE SOLUÇÕES ................................................................. 46

3.8 PRIORIZAÇÃO DE SOLUÇÕES ...................................................................... 46

3.9 PLANO DE IMPLEMENTAÇÃO ....................................................................... 47

4. RESULTADOS OBTIDOS ................................................................................... 49

4.1 ESCOLHA DO TEMA ........................................................................................ 49

4.1.1 Levantamento de Stakeholders .................................................................... 49

4.1.2 Levantamento e Agrupamento de Problemas............................................... 52

4.2 DEFINIÇÃO DOS OBJETIVOS ......................................................................... 54

4.3 MAPEAMENTO DOS PROCESSOS................................................................... 55

4.3.1 Fluxo da norma de AR .................................................................................. 55

4.3.2 Fluxo expandido de AR................................................................................. 61

4.3.3 Fluxo de avaliação de produto ...................................................................... 63

4.3.4 Fluxo de Detalhamento dos Planos de Ação ................................................ 66

4.3.5 Fluxo de Implantação de Planos de Ação..................................................... 68

4.4 IDENTIFICAÇÃO DOS PROCESSOS CRÍTICOS ............................................... 69

4.4.1 Avaliação Quantitativa .................................................................................. 69

4.4.2 Avaliação Qualitativa ...................................................................................... 71

4.5 IDENTIFICAÇÃO DAS CAUSAS RAÍZES ......................................................... 72

4.5.1 Avaliação do produto .................................................................................... 72

4.5.2 Detalhamento dos planos de ação para atendimento das condicionantes ... 74

4.5.3 Implementação dos planos de ação ............................................................. 76

4.6 LEVANTAMENTO DE SOLUÇÕES .................................................................. 78

4.6.1 Avaliação do Produto .................................................................................... 78

4.6.2 Desenvolvimento dos planos de ação .......................................................... 79

4.6.3 Implementação dos planos ........................................................................... 79

4.7 PRIORIZAÇÃO DE SOLUÇÕES ........................................................................ 80

4.7.1 Análise de Impacto e Esforço ....................................................................... 81

4.7.2 Análise de Pilotabilidade ............................................................................... 81

4.7.3 Soluções Escolhidas ..................................................................................... 82

4.8 IMPLEMENTAÇÃO DE SOLUÇÕES ................................................................. 84

4.8.1 Pedir o Acesso ao Portal AR ........................................................................ 84

4.8.2 Rateio de Condicionantes Estruturantes....................................................... 84

4.8.3 Atuação nos GAs .......................................................................................... 86

4.8.4 Acompanhamento Interno do Tempo de Desenvolvimento de Planos de Ação.............................................................................................................. 87

4.8.5 Devolutivas acionáveis ................................................................................. 88

4.8.6 Transformação de condicionantes em itens de backlog ............................... 89

5. CONCLUSÕES ................................................................................................... 99

6. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................ 100

1. INTRODUÇÃO | 23

1. INTRODUÇÃO

1.1 CONTEXTO DO DESENVOLVIMENTO DO TRABALHO

O mercado de bancos de varejo passa por uma forte onda de digitalização. Segundo a

consultoria McKinsey (BROEDERS; KHANNA, 2015), os bancos de varejo da Europa têm até

2020 para alcançar a proficiência digital. As análises sugerem que os pioneiros podem realizar

um aumento de até 40% dos lucros, enquanto os retardatários podem sofrer uma diminuição de

até 35%. Desse aumento de lucro, dois terços se devem à redução de custos operacionais devido

à digitalização e a automação.

Até pouco tempo, o mercado bancário no Brasil era dominado por alguns poucos

grandes players consolidados. Esse cenário está mudando. A digitalização diminuiu as barreiras

de entrada e o Poder Público está tomando medidas para aumentar a competitividade do setor,

como o fim da exclusividade entre credenciadoras e bandeiras em 2010 (FOGAÇA, 2018).

Novas empresas de tecnologia no mercado financeiro, as fintechs, estão oferecendo

alternativas competitivas aos serviços e produtos oferecidos pelos bancos tradicionais. No

mercado de cartão de crédito, o cenário tem mudado rapidamente. Milhas viram commodities,

as agências bancárias perdem relevância para o autoatendimento digital e os clientes resistem a

pagar anuidades (ROMER, 2018).

Frente a essas mudanças, o grande banco de varejo reconheceu a necessidade de se

adaptar, mas a complexidade dos sistemas da organização tornava a reação lenta e ineficaz.

Nesse contexto, a solução foi criar uma nova plataforma de cartões de crédito, independente

dos sistemas do banco.

Os objetivos do idealizador da nova plataforma eram instaurar uma nova forma de

trabalho dentro da organização e substituir a área de cartão de crédito do banco. Segundo ele,

esses dois objetivos estavam intimamente relacionados. Para tornar o banco competitivo, não

bastaria um sistema adaptável. Acima de tudo, as pessoas por trás dele deveriam ser capazes de

identificar e reagir à mudança.

Sendo assim, a nova plataforma digital no grande banco de varejo brasileiro está sendo

construída por equipes multidisciplinares seguindo métodos ágeis de gestão de

desenvolvimento de software. Além se organizar de forma distinta da do banco, a equipe

trabalha em um ambiente fisicamente separado da matriz, junto a funcionários de empresas

parceiras.

24 | 1. INTRODUÇÃO

Este trabalho foi realizado durante o acompanhamento do projeto da nova plataforma

de cartão de crédito de um grande banco de varejo brasileiro. A plataforma será nativa digital,

o cliente poderá realizar todas as operações e consultas pelo celular. Para tanto, os processos da

empresa foram redesenhados visando a integração modular e a automação.

1.2 PROBLEMAS

O projeto da plataforma se propõe a fazer uma ruptura com o banco, contudo, ainda

está sujeito às políticas da instituição. O lançamento de novos produtos do banco está sujeito à

norma de Avaliação de Riscos (AR). A AR descreve o processo de avaliação de novos produtos

do sistema de gestão de riscos do banco. Em média, o processo envolve 20 áreas e dura 67 dias

úteis (du).

As principais demandas são reuniões de esclarecimento com as áreas avaliadoras,

preenchimento de documentos e implementação de planos de prevenção de riscos - todas pouco

compatíveis com a organização do trabalho da equipe de produto. Nesse sentido, existem três

grandes dificuldades implícitas: a complexidade da AR, a gestão de riscos e a

operacionalização dos planos de prevenção em gestão ágil.

Quanto ao primeiro, a norma descreve apenas o fluxo macro do processo. O fluxo dos

subprocessos é, em geral, desconhecido pelas equipes de produto e há grandes variações entre

as áreas. Para ser lançada, a plataforma precisou passar por três ARs, recebendo 675 obrigações

de compliance. Houve uma AR para o projeto piloto, uma para o desenvolvimento da

plataforma e uma para o primeiro produto de cartão de crédito. O fluxo do processo é pouco

estruturado e demasiadamente oneroso.

Em relação ao segundo, de fato há riscos que precisam ser prevenidos e mitigados. Na

AR do projeto piloto, as práticas da norma foram desrespeitadas tanto pelas equipes avaliadoras

quanto pela equipe de produto. Por um lado, os avaliadores emitiam pareceres genéricos sem

terem entendido o projeto e analisado corretamente os riscos. Por outro lado, mesmo que os

riscos estivessem bem delineados, a equipe de produto fez planos de prevenção e mitigação de

riscos genéricos, apenas para cumprir com a obrigação burocrática. Os riscos não estão sendo

geridos.

Quanto ao terceiro, uma vez aprovados os planos de prevenção e mitigação de riscos,

a equipe tem dificuldade de implementá-los. A equipe ainda está amadurecendo quanto às

práticas e ferramentas ágeis. Então, ao se deparar com demandas pouco alinhadas a essas

1. INTRODUÇÃO | 25

estruturas, não há um resposta bem definida. Não se definiu uma forma de cumprir com o

sistema de gestão de riscos a nível operacional utilizando metodologias ágeis.

1.3 OBJETIVO DO TRABALHO

O objetivo do trabalho é analisar e propor soluções para a integração operacional do

sistema de gestão de riscos de um banco ao modelo de gestão ágil. Isso significa garantir que

os riscos relevantes sejam mapeados e prevenidos de acordo com os processos do banco

enquanto a equipe mantém sua capacidade de adaptação conforme os princípios ágeis.

Será necessário, em um primeiro momento, dominar o processo de AR e o modelo de

gestão do projeto para que, em um segundo momento, sejam realizadas as adaptações e

melhorias necessárias. Há três objetivos associados a essas realizações:

Identificar os pontos de risco de não compliance no processo de Avaliação de Risco e

propor soluções;

Propor soluções para a diminuição do tempo de fluxo do processo de Avaliação de

Risco;

Adaptar as ferramentas e métodos ágeis utilizados no projeto conforme as necessidades

do banco.

1.4 JUSTIFICATIVA

A engenharia de produção deve não só se adaptar às novas tecnologias e formas de

trabalho, como também ajudar na transição e evolução. Neste trabalho, técnicas estabelecidas

da engenharia são aplicadas na resolução de problemas em contextos modernos. Elas são

componentes tanto da análise dos problemas, quanto das soluções em si.

A transição para o digital e formas de gestão ágeis ocorre de forma gradativa. Durante

a transição do modelo antigo de trabalho, é necessário desenvolver medidas que permitam a

convivência dos dois sistemas, em um primeiro momento, e sua integração em um segundo.

A equipe ainda enfrentará muitas ARs, então precisa entender bem o processo para

realizá-lo de forma rápida e sem retrabalho. A plataforma está sendo construída para permitir

adaptações e lançamento rápidos. No entanto, todas essas mudanças estão sujeitas aos atuais 67

du de AR. Diminuir esse tempo significa diminuir o time to market.

Os riscos precisam ser prevenidos e mitigados. O mercado financeiro é altamente

regulado e os problemas enfrentados pelos clientes resultam em perdas monetárias. Além disso,

26 | 1. INTRODUÇÃO

o nível de serviço é um diferencial competitivo: os clientes não querem problemas e, caso

ocorram, esperam um atendimento rápido e eficaz, com first contact resolution (FCR).

Além disso, cabe ressaltar que não há forma direta de se transformar recursos em um

produto que os clientes amam. O alinhamento da estratégia da organização com o design do

produto ainda é incipiente, então os métodos e gestão e o fluxo de desenvolvimento de produtos

precisam evoluir.

1.5 ESTRUTURA DO TRABALHO

O trabalho está dividido em seis capítulos. O primeiro apresenta o contexto, a

motivação e a estrutura do trabalho. Descreve a organização e o projeto no qual foi realizado,

seus principais problemas e objetivos.

O capítulo dois contém uma revisão bibliográfica sobre os temas relevantes para o

desenvolvimento do trabalho.

O capítulo três especifica o método e o ferramental empregados.

O capítulo quatro descreve a aplicação do método e os resultados obtidos. O projeto é

descrito através das análises e conclusões de cada etapa do método sistemático de resolução de

problemas. Os temas envolvidos no projeto forma explorados, os objetivos do trabalho

identificados e os processos relevantes mapeados. Então, foi possível levantar soluções,

priorizá-las e implementá-las.

O capítulo cinco conclui o trabalho com uma síntese dos resultados, principais

reflexões e próximos passos.

No sexto e último capítulo estão as referências bibliográficas nas quais o trabalho foi

baseado.

2. REVISÃO BIBLIOGRÁFICA | 27

2. REVISÃO BIBLIOGRÁFICA

Nesta parte estão descritos os principais temas relacionados com o trabalho. Cabe

ressaltar que esses temas não são discutidos em conjunto na literatura.

Os estudos sobre governança, gestão de risco e compliance (GRC do inglês

Governance, Risk Management and Compliance) abordam suas estruturas organizacionais ou

sua aplicação em mercados específicos. Os estudos sobre gestão ágil, por sua vez, analisam os

casos de transição para o modelo e as novas práticas e adaptações de modelos de

desenvolvimento de software e design de produtos. Já a teoria da qualidade e suas ferramentas,

base para o método deste trabalho, costumam ser discutidas no contexto da indústria.

No capítulo 4, sobre o desenvolvimento do trabalho e os resultados obtidos, as relações

entre esses temas serão discutidas no sentido de operacionalizar a integração de sistemas de

GRC e desenvolvimento ágil de software. Nesta revisão, os modelos e conceitos serão descritos

separadamente.

2.1 GOVERNANÇA, GESTÃO DE RISCO E COMPLIANCE

O objetivo de GRC é “ajudar à companhia a estabelecer políticas e controles para

endereçar suas obrigações de compliance e simultaneamente coletar informações que auxiliem

a gestão do negócio” (BROADY; ROLAND,2008, p.9). GRC é um termo guarda-chuva para a

abordagem integrada de práticas de governança, risco e compliance (ERNST & YOUNG,

2013).

Para Venkatesiah (2016), a integração das práticas do GRC contribui para o

gerenciamento de processos em níveis táticos e estratégicos. As empresas com boa integração

entre a GRC e a maneira com que procedem em seus negócios obterão sucesso e serão

referência em seus mercados (BIDNIUK, 2017). Assi (2010) ressalta a dificuldade de mensurar

as perdas por fraudes, riscos acima do apetite da empresa e deficiência de planos de

contingência. Contudo, afirma que o dano sobrepõe o retorno.

2.1.1 Compliance

Compliance, em termos simples, significa satisfazer um conjunto de condições

impostas (BROADY; ROLAND,2008). Como destaca Candeloro, Rizzo e Pinho (2012)

podemos entender compliance como um conjunto de padrões, regras e práticas que orientam o

28 | 2. REVISÃO BIBLIOGRÁFICA

comportamento de uma determinada organização no mercado em que opera, o que inclui

procedimentos éticos e legais em suas práticas corporativas e na de seus funcionários.

A ISO 19600:2014 é o padrão que, entre outras coisas, recomenda que organizações

adotem uma abordagem baseada em riscos para o compliance e desenvolvam um apetite de

riscos para riscos de compliance. Ela define a orientação para estabelecer, desenvolver,

implementar, avaliar, manter e melhorar sistemas de gestão de compliance eficazes e

responsivos em organizações

David Tattam (2018) resume alguns das principais definições da ISO19600:

Compromisso de compliance: Requisito que uma organização escolhe cumprir

Requisito de compliance: Requisito que uma organização tem que cumprir

Compliance: Cumprimento dos requisitos e compromissos de compliance de uma

organização

Não compliance: Não cumprimento de compromisso ou requisito de compliance

Risco de compliance: Efeito da incerteza em objetivos de compliance

2.1.2 Governança

O Instituto Brasileiro de Governança Corporativa (IBGC) define governança

corporativa como “o sistema pelo qual as empresas e demais organizações são dirigidas,

monitoradas e incentivadas, envolvendo os relacionamentos entre sócios, conselho de

administração, diretoria, órgãos de fiscalização e controle e demais partes interessadas” (2015,

p.20). Silva (2012) explica que a governança é o produto de um conjunto de regras, processos

e estruturas que influenciam a ação dos membros da organização com o fim de atender aos

stakeholders.

Esses dois conceitos de governança corporativa, expostos acima, destacam a

importância das partes interessadas na definição do sistema de governança. Freeman (2010)

explica o conceito de stakeholder como todos os grupos ou indivíduos que podem afetar ou são

afetados pela realização dos objetivos de uma organização. Cada um desses grupos tem um

papel vital no sucesso do negócio no ambiente atual. Segundo a Corporação Financeira

Internacional (IFC, 2009), do grupo do Banco Mundial, a governança é essencial para o

desenvolvimento sustentável e geração de valor para todos os stakeholders.


2.1.3 Gestão de Risco

Os bancos costumam divulgar informações sobre exposição a risco de crédito e

mercado a fim de explicitar seu perfil de risco. Contudo, também devem ser levados em

consideração outros riscos, como o risco operacional. (TRAPP; CORRAR, 2005).

No contexto do mercado financeiro, Gitman (1997, p.202 apud TRAPP; CORRAR

2005, p.27) define risco como "a possibilidade de prejuízo financeiro [...] ou, mais formalmente,

o termo risco é usado alternativamente com incerteza, ao referir-se à variabilidade de retornos

associada a um dado ativo".

Em outra perspectiva, Jorion (1997, p.16 apud TRAPP; CORRAR 2005, p.27) afirma

que riscos operacionais "referem-se às perdas potenciais resultantes de sistemas inadequados,

má administração, controles defeituosos ou falha humana [...] também inclui fraude [...] e risco

tecnológico."

Em um sentido mais abrangente, têm-se as definições de "perigo ou possibilidade de

perigo" (FERREIRA, 1999, p.1772 apud TRAPP; CORRAR 2005, p.27), e “chance de ocorrer

um evento desfavorável" (BRIGHAM, 1999, p.158 apud TRAPP; CORRAR 2005, p.27). Os

autores citados notam que a ideia de risco está associada a certo grau de incerteza. Trapp e

Corrar Sintetizam: “corre-se risco quando existe um desconhecimento de resultados futuros de

algum evento, ou seja, de algum acontecimento ou ocorrência” (2005, p.27).

A NBR ISO 31000:2009 “fornece princípios e diretrizes genéricas para a gestão de

riscos. (p.1) [...] o sucesso da gestão de riscos irá depender da eficácia da estrutura de gestão

que fornece os fundamentos e os arranjos que irão incorporá-la através de toda a organização,

em todos os níveis (p. 8) ”. A norma define alguns conceitos relevantes para a compreensão de

um sistema de gestão de riscos:

Risco: efeito da incerteza nos objetivos

Gestão de riscos: atividades coordenadas para dirigir e controlar uma organização no

que se refere a riscos

Estrutura da gestão de riscos: conjunto de componentes que fornecem os fundamentos

e os arranjos organizacionais para a concepção, implementação, monitoramento, análise

crítica e melhoria contínua da gestão de riscos através de toda a organização

Política de gestão de riscos: declaração das intenções e diretrizes gerais de uma

organização relacionadas à gestão de riscos


2.2 GESTÃO ÁGIL

2.2.1 O Manifesto Ágil

A gestão ágil de desenvolvimento de software é um termo guarda-chuva para uma

série de métodos e práticas baseados nos valores expressos no Manifesto Ágil Soluções que

evoluem a partir da colaboração entre equipes auto-organizadas e multidisciplinares que

utilizam as práticas apropriadas pare esse contexto.

O termo “ágil” foi aplicado a essa coleção de metodologias em 2001 quando 17

desenvolvedores se uniram para discutir idas e diferentes abordagens para o desenvolvimento

de software. Essa coleção de valores e princípios foi expressa no Manifesto Ágil (Manifesto for

Agile Software Development) (AGILE ALLIANCE, 2001).

A seguir, na íntegra, o manifesto.

2.2.2 Scrum

Segundo Highsmith e Cockburn (2001), o que há de novo sobre métodos ágeis não são

as práticas que eles usam, mas o reconhecimento das pessoas como o principal motor para o

Manifesto Ágil

Nós estamos descobrindo novas maneiras de desenvolver software enquanto o fazemos e

ajudamos outros a fazê-lo.

Por meio desse trabalho viemos a valorizar:

Indivíduos em detrimento de processos e ferramentas

Software em funcionamento em detrimento de documentação

Colaboração com clientes em detrimento de negociação de contratos

Responder à mudança em vez de seguir um plano

De fato, embora haja valor nos itens da direita, nós valorizamos mais os itens na

esquerda.


sucesso dos projetos, combinado com um foco intenso em eficácia e manobrabilidade. Isso gera

uma nova combinação de valores e princípios que definem uma visão de mundo ágil.

Uma das abordagens para o desenvolvimento ágil de software é o Scrum. Segundo Jeff

Sutherland (2011), o desenvolvedor do Scrum, o objetivo do método é entregar o máximo

possível de software de qualidade dentro de pequenas janelas de tempo chamadas sprints.

A abordagem do Scrum foi desenvolvida para gerenciar o processo de

desenvolvimento de sistemas. É uma abordagem empírica que aplica ideias de teoria de controle

para o desenvolvimento de sistemas resultando em uma abordagem que reintroduz as ideias de

flexibilidade, adaptabilidade e produtividade (SCHWABER; BEEDLE, 2002). Este método

não especifica parâmetros técnicos do produto, apenas sugere práticas gerenciais, ferramentas

e cerimônias (ABRAHAMSSON et al., 2002).

2.2.2.1 Cerimônias

O Scrum começa no backlog do produto, uma lista com todos os requisitoss de projeto

(ABRAHAMSSON et al, 2002). Uma lista de features ou atividades técnicas que são

suficientes para completar o projeto ou um release, a próxima versão. Antes de cada sprint, há

uma sprint planning. Nessa cerimônia, a equipe decide os itens de backlog de produto que irão

priorizar na próxima sprint e o plano inicial para completá-los (AGILE ALLIANCE, 2018).

Durante a sprint, todos os dias, no mesmo horário, ocorre a daily. Essa reunião tem

um prazo curto pré-determinado, em geral 15 minutos (AGILE ALLIANCE, 2018). Cada

membro da equipe expõe o que já concluiu desde a última daily e o que pretende concluir até a

próxima. Os impedimentos encontrados para o desenvolvimento também são brevemente

discutidos (ABRAHAMSSON, et al, 2002)

Ao fim da Sprint, há duas reuniões, a review e a retrospectiva. No último dia da Sprint,

ocorre a review. Nela, a equipe apresenta os resultados, incrementos no produto, para a gestão,

os clientes e as demais partes interessadas. A partir desses resultados, são feitas decisões para

as próximas sprints, podendo inclusive aparecer novos itens de backlog (ABRAHAMSSON et

al, 2002).

A retrospectiva, ou retro, não precisa necessariamente ser no último dia de toda Sprint.

Essa reunião ocorre de forma periódica para que os membros da equipe possam refletir sobre

acontecimentos importantes desde a última retro, tanto no sentido do desenvolvimento do

produto quanto na relação entre os membros da equipe (AGILE ALLIANCE, 2018).


2.2.2.2 Papéis

No Scrum, há alguns papeis característicos que acompanham o modelo.

Product Owner (PO)

É o responsável oficial pelo backlog. Isso significa entender os requerimentos para o

produto, gerenciar o desenvolvimento do projeto, decidir o que priorizar a cada sprint e avaliar

a qualidade das entregas (ABRAHAMSSON et al, 2002). Cada PO representa um produto ou

uma experiência em um produto/sistema maior. Dessa forma, as responsabilidades de cada um

são bem definidas (AGILE ALLIANCE, 2018).

Scrum Master (SM)

Papel gerencial introduzido pelo Scrum. É o profissional responsável pela adesão aos

valores e práticas do Scrum. Ele também entra em contato com o cliente e a gerência para retirar

impedimentos da equipe e impedir a entrada de demandas fora do backlog da sprint.

(ABRAHAMSSON et al, 2002). O SM não tem autoridade hierárquica, influencia a equipe em

uma posição de líder servo (AGILE ALLIANCE, 2018).

Scrum Team/Squad

É a equipe do projeto. São responsáveis por se organizar para atuar sobre os objetivos

de cada Sprint (ABRAHAMSSON et al, 2002). O time é composto por profissionais com as

habilidades necessárias para o desenvolvimento do projeto, sejam quais forem. É esperado que

tenha de três a dez membros. (Agile Alliance, 2018). Nos primeiros dias da Amazon, Jeff Bezos,

o fundador, instituiu a regra da pizza: cada time deveria poder ser alimentado por até duas

pizzas. (HERN, 2018)

2.2.2.3 Backlog

Pela sua importância, o backlog do produto merece uma análise mais profunda. O

backlog deriva do roadmap do produto (DAN RADIGAN, 2018). Um roadmap estratégico é

uma forma de delinear iniciativas para atingir um objetivo. A estratégia começa com a

compreensão clara de como as inovações do produto se relacionam aos objetivos de negócio

(COOPER; EDGETT, 2010). O roadmap de um produto é o planejamento da evolução do

produto no tempo.

Para realizar grandes iniciativas estratégicas, é necessário estruturar o trabalho, dividí-

lo em tarefas menores. Na gestão ágil, isso é feito em diferentes níveis de organização de tarefas


e objetivos (REHKOPF, 2018). A seguir, os diferentes níveis de quebra de objetivos no Scrum,

da menor para a maior:

Tarefa

Atividade discreta que faz parte de um requisito (LEYBOURN, 2013).

Histórias

Pequenas demandas de trabalho a ser desenvolvido. Incluem poucas tarefas e representam como

a realização delas entregará valor para o cliente. Do tamanho ideal para entrarem em quadros

de kanban, são os blocos que compõem features, épicos e iniciativas. (REHKOPF, 2018).

Feature

A feature é um serviço que soluciona uma necessidade de um stakeholder. Pode ser dividida

em partes menores conforme o tamanho do seu escopo (LEFFINGWELL, 2011).

Épicos

Demanda grande demais para caber um uma sprint. É composta por histórias. Em uma

perspectiva operacional, é objetivo de a maior escala (REHKOPF, 2018).

Iniciativas

Uma iniciativa é composta por épicos focados em um mesmo objetivo. (REHKOPF, 2018)

Iniciativas estão relacionadas com objetivos de negócios e critérios específicos (CHRISTIE-

BLICK, 2018).

Temas

Objetivo da organização com um todo composto por épicos e iniciativas (REHKOPF, 2018).

2.2.3 Kanban

O método Kanban é um meio de gerenciar o fluxo de trabalho de organizações. É

baseado na gestão visual do trabalho em quadros de kanban e no controle do fluxo de trabalho.

(AGILE ALLIANCE, 2018). Ao ajustar a quantidade de trabalho estabelecida para os times,

obtém-se mais flexibilidade, foco e transparência. O que estiver no quadro é a prioridade

(RADIGAN, 2018). Cada item de trabalho no kanban é representado por um card. Em níveis

mais operacionais, os cards são tarefas (LEYBOURN, 2013).

O conceito original de Kanban foi desenvolvido no contexto do Sistema de Produção

Toyota, como ferramenta de controle para processos de produção Just-In-Time, com o fluxo

puxado de produção. O método ágil é uma adaptação com ênfase em práticas de melhoria


constante de processo. As colunas do quadro representam as etapas do fluxo de trabalho do

time. A gestão visual facilita a identificação de acúmulos de trabalho em processo (Work In

Progress - WIP) e gargalos no fluxo de trabalho (LEYBOURN, 2013).

Na Figura 1 - Exemplo de quadro de kanbanFigura 1, pode-se ver como exemplo o kanban

utilizado para o desenvolvimento das análises, gráficos e tabelas deste trabalho. O fluxo de

trabalho foi descrito pelas etapas: To do, Doing, A revisar e Done. Foram impostos limites de

WIP na segunda e terceira colunas.

Figura 1 - Exemplo de quadro de kanban

Fonte: Elaborado pelo autor, 2018

2.2.4 Scrumban

A combinação dos métodos de Scrum e Kanban é conhecida como Scrumban,

(PAHUJA, 2018). Essa combinação pode ocorrer de diversas formas, mas aqui se discutirá o

caso no qual kanbans são utilizados para o controle de fluxo de trabalho dentro das sprints.

Combina-se a agilidade do Scrum com a melhoria contínua de processos do Kanban

(PAHUJA, 2018). Os itens que serão priorizados na Sprint entram como cards na coluna mais

à esquerda do quadro, a qual representa o início do fluxo de trabalho. Então, ao longo da Sprint,

a evolução do trabalho ocorre de forma puxada, com gestão visual e limite de WIP.

A gestão do fluxo de trabalho permite analisar os gargalos nos processos e a

capacidade dos times. As principais medidas de performance são os lead times de cada etapa e

o tempo de ciclo total. (PAHUJA, 2018)


2.3 GESTÃO DE PROCESSOS

Na expectativa de redução de custos e agilidade, a abordagem de processos vem

ganhando relevância nas empresas, tanto nas industriais quanto nas de serviços (SALERNO,

1999). Segundo De Sordi (2014, pg. 56), “processos de negócios são fluxos de trabalhos que

atendem a um ou mais objetivos da organização e que proporcionam Agregação de valor sob a

óptica do cliente final”.

A gestão de processos é considerada uma forma rápida de identificar problemas de

desempenho em processos e implementar as soluções cabíveis. Para tanto, os métodos de

modelagem a análise de processos devem estar bem estruturados. Cabe ressaltar a ligação

entre a engenharia de produção e a gestão de processos. A última, ao permitir o

desenvolvimento de soluções relativas aos fatores de produção, é parte essencial da primeira

PAIM et al., 2009).

A realização da estratégia de uma empresa envolve a definição de objetivos de longo

prazo e a alocação eficaz de recursos. Já é reconhecida a necessidade de haver alinhamento

organizacional entre a estratégia e a estrutura da organização. No entanto, também é necessário

a alinhamento entre a estratégia e os processos (PAIM et al., 2009).

2.3.1 Modelagem de processos de negócio

Ter um modelo dos processos do negócio significa ter conhecimento sobre o estado do

negócio e os recursos envolvidos. Os processos de negócios determinam como a empresa

entrega valor para os stakeholders. Gerenciar esses processos oferece maior retorno às partes.

(ABPMP, 2013).

O Modelo e Notação de Processos de Negócio (BPMN, do inglês Business Process

Model and Notation) permite às organizações entender seus procedimentos internos e

comunicá-los de forma clara. O BPMN deve ser capaz de criar modelos claros e simples de

processos complexos. (OMG, 2010). Seus principais elementos estão descritos abaixo (Figura

2):


Figura 2 - Elementos gráficos principais do BPMN

Fonte: (VALLE, 2009 Apud GIMENES, 2012, p.48)

Objetos de fluxo: São os principais elementos gráficos que definem um processo de

negócios (OMG, 2010):

o Atividade: Termo genérico para itens de trabalho no processo. Pode um

subprocesso ou apenas uma tarefa (OMG, 2010);

o Eventos: Algo que acontece de forma pontual, como um impulso, e possui uma

consequência (OMG, 2010);

o Gateways: Controlam convergências e divergências no processo. Seu uso mais

frequente é o de representação de escolhas e condições (OMG, 2010);

Informação: Representa o fluxo e o armazenamento de informação (OMG, 2010);

Objetos conectores: Formas de conectar objetos de fluxo ou informação (OMG, 2010);

Swimlanes: Formas de agrupar elementos de modelagem (Figura 3) (OMG, 2010);

o Pool: Representam áreas do negócio distintas no diagrama (VALLE, 2009).

Também é utilizada para agrupar os participantes de um processo (OMG, 2010);

o Lane: Utilizada para identificar atividades relacionadas a uma função ou papel

específicos no processo (VALLE, 2009);

Artefatos: São usados para exibir informações adicionais como comentários e

agrupamentos (OMG, 2010).


Figura 3 - Exemplos de Swinlanes


2.4 PROCEDIMENTO DE RESOLUÇÃO DE PROBLEMAS

Este trabalho foi guiado por um procedimento de resolução de problemas, o Quality

Control (QC) Story. Segundo Hitoshi Kume (1993), “Um problema é o resultado indesejável

de um trabalho”. Solucionar um problema é mudar o resultado de um patamar indesejado para

um razoável. Este método é um encadeamento lógico de atividades de controle de qualidade.

(KUME, 1993).

Kume (1993, p. 202) afirma que um problema pode ser resolvido ao se seguir as sete

etapas abaixo:

1.Problema: Identificação do problema 2.Observação: Reconhecimento dos aspectos do problema

3.Análise: Descoberta das principais causas 4.Ação: Ação para eliminar as causas 5.Verificação: Verificação da eficácia da ação

6.Padronização: Eliminação definitiva das causas

7.Conclusão: Revisão das atividades e planejamento para o trabalho futuro

Kume (1993) chega a prescrever as ferramentas da qualidade e procedimentos mais

adequados para cada etapa da resolução do problema e o encadeamento entre elas. Serão

descritas com maior profundidade apenas as ferramentas utilizadas neste trabalho.

2.4.1 Diagrama de Causa e Efeito

Na etapa nº 3, a análise de problemas, Kume (1993) recomenda estabelecer e testar

hipóteses. Para levantar as hipóteses, sugere-se o diagrama de causa e efeito, um diagrama com


as questões relacionadas aos diferentes aspectos do problema. Também é conhecido com

Diagrama de Espinha de Peixe ou Diagrama de Ishikawa (Figura 4). Ele relaciona características

da qualidade com possíveis fatores de causa, em diferentes níveis de detalhe.

Figura 4 - Diagrama de Ishikawa

Fonte: (KUME, 1993)

Uma configuração comum do diagrama é o 6M, com fatores pré-estabelecidos para

cada uma das espinhas grandes (DALE; VAN DER WIELE; VAN IWAARDEN, 2007). Esse

formato é um bom ponto inicial para a análise de causas mesmo em casos de incerteza. Seus

fatores são:

Método;

Mão de obra;

Meio Ambiente;

Matéria Prima;

Medidas;

Máquinas.

Para o levantamento das causas dentro de cada fator, Kume (1993) sugere o

aproveitamento das informações da fase de observação e a realização de brainstormings.

Segundo Dale, Van der Wiele e Van Iwaarden (2007), brainstorming é um método de expressão

livre empregado para a dedução de soluções de problemas, o levantamento de ideias criativas.

A dinâmica pode ser feita tanto de forma estruturada ou desestruturada e funciona melhor em

grupos, embora possa ser feita individualmente.


2.4.2 Matriz de Impacto x Esforço

A matriz de esforço e impacto serve para decidir, a partir de um conjunto de soluções

e critérios pré-estabelecidos, quantas e quais soluções devem ser implementadas. Ela explicita,

em teoria, as soluções com o maior impacto e menor dificuldade de implementação.

(ANDERSEN, FAGERHAUG e BELTZ, 2010)

Ao plotar as soluções na matriz, faz-se uma análise de priorização por quadrante.

Primeiro, desconsideram-se as no canto inferior direito. Depois, priorizam-se as do quadrante

superior esquerdo. Por fim, a depender do dos recursos do projeto e do apetite de risco, pode-

se priorizar uma combinação de soluções dos quadrantes superior direito e inferior esquerdo.

(GILAD, 2017).

Figura 5 - Matriz Impacto x Esforço

Fonte: Adaptado de (GILAD, 2017)

Deve-se ressaltar, entretanto, que há controvérsias sobre este método de priorização.

O método perde eficácia devido à baixa qualidade das estimativas de esforço e impacto.

(GILAD, 2017). Segundo Kohavi et al. (2009 - tradução nossa): “[...] é um exercício de

humildade ver como os especialistas são ruins em estimar o valor de features. Toda feature

construídas por um time de software é construída porque alguém acredita que ela terá valor,

mas muitos dos benefícios falham em se materializar”.

3. MÉTODO | 41

3. MÉTODO

Neste capítulo é apresentado o método empregado neste trabalho. De forma sucinta,

são apresentadas as etapas, os procedimentos e a relação entre eles, desde a concepção do

trabalho à discussão dos resultados.

Para integrar o sistema de gestão de riscos ao modelo de gestão ágil, primeiro foi

preciso conhecer bem cada um deles. O método escolhido para este trabalho teve que permitir

uma análise estruturada da AR e seus subprocessos e do fluxo de trabalho da equipe.

Entendendo a AR, foi possível simplificar suas complexidades e identificar de que

forma a gestão dos riscos era feita no processo. Entendendo o fluxo de trabalho da equipe, foi

possível avaliar a adequação do uso das ferramentas e métodos ágeis.

Este trabalho combinou ferramentas e métodos de vários autores em uma abordagem

baseada no procedimento de resolução de problemas de Kume (1993), o QC Story. Inicialmente,

os principais problemas foram identificados. Em seguida, foi feito um aprofundamento de

forma a reconhecer seus aspectos e onde se mostravam mais relevantes. Daí, puderam ser

isoladas as causas raízes e, a partir delas, levantadas e selecionadas soluções. Essas soluções

foram implementadas e seus resultados verificados quanto à eliminação ou mitigação das

causas.

3.1 SISTEMÁTICA ADOTADA

Antes mesmo do início do acompanhamento do projeto, os gestores foram avisados

que seria realizado um trabalho de engenharia de produção a partir de um problema relevante

no contexto da organização. A primeira etapa foi a escolha do tema, que já começou no primeiro

dia, 05 de maio de 2018. Abaixo, um cronograma do desenvolvimento do trabalho:

Tabela 1- Cronograma de Desenvolvimento do Trabalho

Etapa Data de início

Escolha do tema 05/mai

Definição dos Objetivos 02/jun

Mapeamento dos Processos 19/jun

Identificação das causas raízes 22/ago

Levantamento de soluções 12/set

Priorização de soluções 16/set

Implementação 16/set

Entrega da tese 09/nov

Cronograma de Desenvolvimento

42 | 3. MÉTODO

A escolha do tema consistiu em entender quais eram os problemas mais relevantes

para justificar a realização do trabalho (KUME, 1993) e a colaboração da organização. Ao longo

de um mês, foram feitas cerca de 20 pequenas entrevistas de cinco minutos com os stakeholders

(FREEMAN, 2010), a fim de levantar as percepções sobre os problemas do projeto. Os

problemas mencionados foram agrupados em temas e estes foram avaliados pela equipe e pelos

gestores em questão de relevância. Dessa forma, foi selecionado o tema referente ao problema

mais relevante para a equipe: a relação entre o sistema de gestão de riscos do banco e a agilidade

da equipe de projeto.

Em seguida, foram investigados os aspectos desse problema a partir de pontos de

vista diferentes, para que se pudessem verificar variações na vivência do tema (KUME, 1993).

A definição dos objetivos se deu ao longo de duas semanas por meio de reuniões e entrevistas

mais longas com colaboradores de diferentes áreas relacionadas ao sistema de gestão de riscos

da organização. Dessa forma, os objetivos levam em consideração tanto a necessidade de

agilidade da equipe de produto quanto a necessidade de prevenção e mitigação de riscos

defendida pela governança.

A forma mais eficaz de atingir os objetivos é basear a resolução do problema em dados

e informações (KUME, 1993). Portanto, foi necessário levantar informações sobre a forma

como o sistema de gestão de riscos do banco, na forma da Avaliação de Riscos, afetava o

projeto. A partir do estudo de normas internas e reuniões de esclarecimento com a área de

governança, os principais processos relacionados à AR foram mapeados ao longo de um mês e

meio.

Os diagramas de fluxo de processo (OMG, 2010) foram essenciais para a análise

científica das causas do problema. Eles permitiram a sistematização das informações fornecidas

pelos especialistas e a identificação dos subprocessos mais relevantes segundo os critérios do

objetivo do trabalho. Em duas semanas, cada um desses subprocessos foi analisado em um

diagrama de causa e efeito para levantar hipóteses sobre as possíveis causas dos problemas

(KUME, 1993).

Identificadas as causas raízes, para cada uma delas foram associadas propostas de

solução por meio de brainstorming (DALE; VAN DER WIELE; VAN IWAARDEN, 2007) e

o levantamento de sugestões de solução mencionadas pelos stakeholders (FREEMAN, 2010)

ao longo do desenvolvimento do trabalho. Foram feitas duas sessões ao longo de uma semana.

A fim de considerar os prós e contras dessas propostas, elas foram avaliadas por meio

de uma matriz de esforço x impacto (GILAD, 2017). Ao se verificar que nenhuma solução

possuía baixo esforço e alto impacto, fez-se uma avaliação apenas pelo critério de esforço.

3. MÉTODO | 43

Foram priorizadas tantas soluções de baixo esforço quanto os recursos permitiam. Dessa forma,

foi possível que o analista responsável tivesse total controle sobre a implementação das

soluções.

Antes de implementadas, contudo, as soluções deveriam ser previamente

amadurecidas. Então, cada uma delas foi revisitada considerando-se seu contexto e problema.

Essa prática facilitou a organização do portfólio de soluções. Por conseguinte, as soluções para

o problema estavam prontas para a implementação nos meados de setembro, cerca de quatro

meses após o início do trabalho.

Durante os dois meses seguintes, cada uma das soluções foi implementada em sua

respectiva frente. Conforme os primeiros resultados apareciam, já há partir da primeira semana,

as soluções foram sendo verificadas e readaptadas, a fim de melhor sua eficácia.

3.2 ESCOLHA DO TEMA

A escolha do tema consistiu em entender quais eram os problemas mais relevantes

para justificar a realização do trabalho (KUME, 1993). No início do acompanhamento do

projeto, não se tinha conhecimento dos temas relevantes no contexto. Como forma de entender

melhor o projeto e garantir percepções diferentes sobre os problemas relacionados, foi feito um

levantamento de stakeholders (FREEMAN, 2010). Para a primeira iteração da definição do

problema, considerou-se melhor realizar várias entrevistas rápidas do que algumas poucas

entrevistas em profundidade.

Ao longo de um mês, conforme os stakeholders eram mapeados, as pequenas

entrevistas de cinco minutos já aconteciam. Essa abordagem mostrou-se interessante, pois

permitiu o engajamento instantâneo do stakeholder no local de trabalho. Stakeholders não

estabelecidos no espaço do projeto forma abordados, em menor proporção, por telefone ou ao

fim de reuniões na matriz.

A essas entrevistas, somaram-se observações do dia a dia do trabalho, pesquisas sobre

o setor e uma reunião para discussão do projeto com os dois gestores imediatamente

responsáveis. Os problemas mencionados foram registrados e, em seguida, agrupados em

temas, problemas mais gerais. Para cada um deles, foram sistematizados os principais pontos

levantados e possíveis direcionamentos de estudo, de forma a estimar a forma final da

exploração do tema.

44 | 3. MÉTODO

Por fim, os temas e seus principais pontos foram submetidos à opinião dos gestores.

Ambos concordaram sobre a pertinência do estudo sobre relação entre o sistema de gestão de

riscos do banco e os métodos e ferramentas ágeis utilizados pela equipe do projeto.

3.3 DEFINIÇÃO DOS OBJETIVOS

Com o problema geral definido, foram investigados os aspectos desse problema a

partir de pontos de vista diferentes para que se pudessem verificar variações na sua vivência

(KUME, 1993). A equipe de produto foi clara em suas queixas a respeito da onerosidade e

pertinência do processo de AR. Por isso, para a etapa de definição dos objetivos tomou-se o

cuidado de incluir representantes da equipe de governança.

A primeira reunião sobre definição de objetivos ocorreu com os gestores do projeto,

logo após a escolha do tema. Nas duas semanas seguintes, foram marcadas reuniões presenciais

com representantes de governança. A partir dessas discussões mais profundas sobre o problema,

pode-se definir um conjunto de objetivos que reflete perspectivas diferentes de um mesmo

problema. Objetivos que levam em consideração tanto a necessidade de agilidade da equipe de

produto, quanto a necessidade de prevenção e mitigação de riscos defendida pela governança.

3.4 MAPEAMENTO DOS PROCESSOS

A forma mais eficaz de atingir os objetivos é basear a resolução do problema em dados

e informações (KUME, 1993). Nesse sentido, foi necessário primeiro desenvolver uma

compreensão estruturada do processo de AR para depois poder avaliar seus efeitos no projeto.

Ao longo de seis semanas, o processo de AR e o fluxo de trabalho do projeto foram analisados

e mapeados.

Durante uma das reuniões com governança para a definição dos objetivos, uma analista

explicou o fluxo de AR a partir de um modelo de processo simples que consta na norma interna

do banco sobre a AR. Contudo, não há registro oficial sobre os subprocessos. A área de

governança, como guardiã da AR, é responsável por manter e reforçar as boas práticas do fluxo.

Em sequência, foi marcada uma reunião adicional para a transcrição dos fluxos em

BPMN (OMG, 2010). A partir das descrições da especialista, foram feitos rascunhos em papel

dos fluxos, os quais, depois de validados, foram transcritos no software Bizagi Modeler

Nesta etapa, também foram mapeados processos da equipe de produto. Neste caso, a

tarefa foi consideravelmente mais simples. Além da proximidade física, a equipe discute o seu

3. MÉTODO | 45

fluxo de trabalho constantemente e as ferramentas e modelos de trabalho são adaptados em

função dele.

3.5 IDENTIFICAÇÃO DOS PROCESSOS CRÍTICOS

Os diagramas de fluxo de processo (OMG, 2010) foram essenciais para a análise

científica das causas do problema, por permitirem uma análise segmentada do subprocesso e

dos atores. Nesse contexto, por processos críticos definiram-se os subprocessos que impõem o

maior desafio ao alcance dos objetivos deste trabalho.

Logo, um processo crítico apresenta grande tempo de processo, elevado risco de não

compliance e não é facilmente integrado às ferramentas e métodos ágeis utilizados pela equipe.

Nesse sentido, a fim de considerar os interesses de áreas distintas e critérios tanto quantitativos,

quanto qualitativos (TRAPP; CORRAR 2005), os critérios de avaliação de criticidade de

processo foram definidos como tempo de processo e risco de não compliance.

A área de governança foi de grande ajuda na definição desses critérios e na estimativa

de seus valores. A área de analytcs da governança forneceu os tempos médios dos processos e

subprocessos de AR e a analista de PMO, ex-governança, auxiliou a levantar algumas das

principais brechas para riscos de não compliance no processo de AR.

A partir dessas informações, foram selecionados para análise posterior os subprocessos

relacionados a AR com o maior tempo de fluxo e as brechas mais sérias para o risco não

compliance.

3.6 IDENTIFICAÇÃO DAS CAUSAS RAÍZES

Nesta etapa, cada processo crítico foi analisado por meio do diagrama de causa e efeito.

Essa ferramenta é útil para a geração de hipóteses sobre as causas raízes de um problema

(KUME, 1993). Foi utilizado o modelo de diagrama 6M (DALE; VAN DER WIELE; VAN

IWAARDEN, 2007), contudo, como não houve fatores relacionados à matéria prima ou meio

ambiente, essas espinhas grandes (KUME, 1993) foram omitidas.

Ao longo de duas semanas, os processos foram avaliados quanto às causas de seu longo

tempo de processo e/ou alto risco de não compliance. Em teoria, cada diagrama se refere a

apenas um tipo de problema (KUME, 1993). Contudo, por fins de simplificação, os dois

problemas foram combinados em um diagrama só.

46 | 3. MÉTODO

As causas foram levantadas a partir de observações das etapas anteriores e por um

brainstorming individual (DALE; VAN DER WIELE; VAN IWAARDEN, 2007). Em seguida,

as causas pouco relevantes foram descartadas e as 20 restantes foram descritas em maior

detalhe.

3.7 LEVANTAMENTO DE SOLUÇÕES

Identificadas as causas raízes, para cada uma delas foram associadas propostas de

solução por meio de brainstorming (DALE; VAN DER WIELE; VAN IWAARDEN, 2007) e

o levantamento de sugestões de solução mencionadas pelos stakeholders (FREEMAN, 2010)

ao longo do desenvolvimento do trabalho. Foram feitas duas sessões de brainstorming para

cada subprocesso, com um intervalo de uma semana entre elas, resultando em 18 propostas.

Há dois tipos de ação no modelo de Kume, (1993): as que impedem a repetição do

problema e as que mitigam os efeitos do problema. O ideal seria levantar soluções do primeiro

tipo, que eliminam diretamente as causas do problema. Contudo, muitas das causas levantadas

se originavam de políticas do banco e não poderiam ser eliminadas até o lançamento da

plataforma e a conclusão deste trabalho. Assim, o levantamento de ideias incluiu propostas de

solução focadas na mitigação dos efeitos dos problemas.

3.8 PRIORIZAÇÃO DE SOLUÇÕES

A decisão sobre quais das propostas de solução implementar foi feita com uma matriz

de esforço x impacto, a fim de ser avaliar como gerar o maior impacto com o menor esforço

(ANDERSEN, FAGERHAUG e BELTZ, 2010). Para o critério de impacto, foi adaptada uma

nota de priorização utilizada no projeto, o RUT (CHIARA, 2016). Para o de esforço, criou-se

um indicador baseado no tempo de implementação da solução e na sua pilotabilidade, uma

estimativa da possibilidade do analista de integração implementar e controlar a solução.

Os valores para os critérios de avaliação foram estimados para cada uma das soluções

(GILAD, 2017) e, em seguida, elas foram plotadas na matriz. Ao se verificar que nenhuma

solução possuía baixo esforço e alto impacto, foi necessário desenvolver um plano de

contingência. Notou-se, então, que com os recursos disponíveis, era possível realizar quase

todas as soluções de baixo esforço. Priorizaram-se as soluções em função de sua pilotabilidade.

3. MÉTODO | 47

3.9 PLANO DE IMPLEMENTAÇÃO

Há dois meses do final do projeto, tinha-se um portfólio de soluções pilotáveis em

diferentes etapas do processo de Avaliação de Riscos do banco. Essas ações tinham a

característica de mitigar os efeitos de longo tempo de processo e risco de não compliance

(KUME, 1993).

As soluções foram aplicadas de forma independente e quase simultânea. Por estarem

associadas às atribuições diárias do analista de integração, puderam ser facilmente integradas à

sua rotina.

Para pedir acesso ao portal AR, as explicações necessárias foram requisitadas ao PMO

e as demais etapas do processo foram seguidas conforme o processo e os SLAs estabelecidos

pelo banco.

As soluções referentes à atuação nos GAs e às devolutivas acionáveis resultaram no

desenvolvimento de processos internos executados pelo próprio analista. Após se identificar as

situações tipicamente causadas por GAs ou devolutivas pouco acionáveis, foram criados planos

de contingência bem delineados.

A implantação do acompanhamento interno do tempo de desenvolvimento dos planos

de ação começou com a discussão com a equipe sobre as causas do problema e a necessidade

de sua mitigação. A partir do modelo do processo de desenvolvimento de planos de ação, SLAs

internos foram combinados. Posteriormente foi feito um documento para o acompanhamento

desses prazos. Contudo, os resultados mais importantes foram a consolidação do fluxo de

desenvolvimento de planos e a centralização das atribuições no analista de integração.

Para o rateio de condicionantes, executou-se um estudo da distribuição das

condicionantes entre as squads. Um modelo no Excel foi criado para verificar quantas

condicionantes cada squad já tinha e como foi feito o rateio ad hoc de condicionantes

estruturantes. Essas análises embasaram o diagnóstico de um rateio pouco balanceado e a

concentração de condicionantes estruturantes na área de segurança da informação. Ciente dos

fatos, o coordenador do projeto transferiu a responsabilidade de implantação de cerca de 180

condicionantes para outra área do banco.

A transformação de condicionantes em itens de backlog é uma forma de permitir a

integração operacional de uma ferramenta da equipe com sistema de gestão de riscos do banco.

Por consequência, sua implementação demandou a compreensão tanto dos fluxos de AR quanto

do fluxo de trabalho da equipe. Essa compreensão foi obtida a partir dos mapeamentos

realizadas em etapas anteriores e conversas com os Scrum Masterns do projeto.

48 | 3. MÉTODO

Na busca para garantir a implementação dos planos de ação de AR, identificou-se que

a principal ferramenta para o controle de demandas no Scrum é o backlog. Então, ele foi

adaptado para poder organizar simultaneamente features e condicionantes de AR. Mesmo

assim, as condicionantes não eram priorizadas nas sprints.

Deste modo, o foco mudou para o sistema de priorização de backlog do projeto. Em

busca de bechmarks, encontrou-se uma empresa da California cujo software de gestão de

backlog parecia se adequar às necessidades da equipe. Foi marcada uma reunião por Skype onde

foram discutidos os métodos e ferramentas ágeis mais adequados para o projeto e um plano de

testes do software de gestão..

4. RESULTADOS OBTIDOS | 49

4. RESULTADOS OBTIDOS

Neste capítulo a sistemática exposta no capítulo 3 é aplicada para a resolução dos

problemas do grande banco brasileiro. Todas as soluções têm fundamento na teoria discutida

no capítulo 2.

4.1 ESCOLHA DO TEMA

A primeira etapa do estudo foi uma exploração para identificar os problemas mais

relevantes a serem analisados e abordados. O levantamento de problemas foi feito tanto de

forma ordenada, com reuniões dedicadas e entrevistas, quanto de forma desordenada, em

conversas ao longo do cotidiano.

4.1.1 Levantamento de Stakeholders

Para construir uma visão completa do contexto do projeto da plataforma, foi feito um

levantamento dos stakeholders mais relevantes para que, em seguida, fossem realizadas

pequenas entrevistas sobre os principais problemas do projeto.

Além disso, como as atribuições de cada membro do projeto são muito bem definidas,

este levantamento foi um exercício de compreensão do todo a partir de suas partes.

4.1.1.1 Stakeholders Internos

Há uma divisão básica entre os colaboradores do banco envolvidos com a plataforma:

os da coordenação do projeto, com dedicação exclusiva, e os de outras áreas. A coordenação

tem um papel gerencial, no qual o coordenador faz a ponte entre a estratégia da empresa e o

projeto e os POs transformam a estratégia em itens de backlog e os priorizam nas sprints.

Os colaboradores de outras áreas podem ser membros das squads ou realizarem

funções de apoio, como recursos humanos ou compras. Os analistas das squads se deslocam

frequentemente entre a matriz do banco e o espaço do projeto. Eles auxiliam no

desenvolvimento de fluxos e regras de produto e realizam tarefas operacionais.

Os das funções de apoio, por sua vez, tem um contato menos intenso com o projeto.

Canais remotos como telefone e email em geral são satisfatórios para a colaboração.

50 | 4. RESULTADOS OBTIDOS

4.1.1.1.1 Stakeholders da Coordenação do Projeto

A seguir, uma lista dos stakeholders do banco mais envolvidos com o projeto:

• Coordenador: gestor imediato da equipe do projeto. Neste caso, idealizador do

projeto.

• Analistas de produto: Analistas responsáveis pela gestão das diferentes frentes do

projeto. São Project Owners (POs) de squads do projeto. As squads são:

o Conquistar: Compreende a experiência do cliente até o primeiro uso do cartão.

Envolve a análise de crédito e fraude, cadastro e fluxo de tangíveis.

o Comprar: Lidera temas relacionados ao uso do cartão de crédito para realizar

comprar. Envolve cartão virtual, wallets, pagamentos online e elementos

estruturantes para processamento das compras.

o Pagar: Compreende a experiência do cliente para pagar os boletos de cartão de

crédito e os fluxos financeiros desses pagamentos dentro do banco. Envolve

produtos de parcelamento de fatura, boletos e fluxos contábeis internos.

o Assistir: Responsável pelo atendimento ao cliente, desde a estruturação de

centrais de atendimento até à disponibilização de FAQs (Frequently Asked

Questions) para autoatendimento pelo cliente.

o Dados: Responsável pela coleta de dados relativos ao produto, sua estruturação

e desenvolvimento de relatórios.

• Analistas de negócio: Analistas responsáveis pela gestão das parcerias da plataforma.

Desempenham o papel de POs no que se refere a adaptações e construção de

features específicas para cada parceiro. Possuem uma squad menor que as squads

os POs de produto.

• Analista de integração: analista da equipe de negócios responsável por assuntos

cross. Lidera os assuntos de governança, backlog, pagamento de fornecedores e

testes de produto.

4.1.1.1.2 Stakeholders de Outras Áreas do Banco

A seguir, uma lista dos stakeholders do banco mais distantes do projeto:


• Colaboradores de cargos estratégicos: Gerentes, superintendentes e diretores.

Aprovam recursos para o projeto e o direcionam conforme a estratégia geral do

banco.

• Analistas das squads: analistas do banco alocados em dedicação parcial para auxiliar

o desenvolvimento do projeto. Levam o conhecimento do banco para o projeto e

atuam principalmente no mapeamento de processos para a automação.

• Pareceristas de áreas avaliadoras de AR: Analistas e gestores responsáveis por

avaliar o projeto em termos de riscos de não compliance.

• Project Management Office (PMO) cartões: Responsáveis por boas práticas de

projeto e avaliação da conformidade com os processos do banco. Devido à

ocorrência acima da média de casos de não compliance na área de cartões, auxiliam

e monitoram as ARs da área de cartões junto com os analistas de produto.

• Áreas de operacionais do banco: áreas responsáveis por pagamentos, emissão de

contratos e outros processos operacionais do banco. Prestam serviços baseados em

Service Level Agreements (SLAs) de tempos de fila pré-determinados.

• Desenvolvedores backend - banco: desenvolvedores do backend do ambiente da

plataforma do banco. Cuidam principalmente da arquitetura das soluções.

4.1.1.2 Stakeholders externos

Os stakeholders externos são os negócios parceiros, os clientes e os funcionários das

empresas de desenvolvimento de software.

Em termos de modelos de negócio, a nova plataforma de cartões do banco é um

negócio com duas frentes. A plataforma é um chassi único para processar cartões de diferentes

marcas e para diferentes segmentos de clientes. Ela fornece a estrutura entre as empresas que

desejam um cartão com a sua marca, como um supermercado, e os clientes que de fato usarão

esses cartões.

O desenvolvimento de software no projeto é realizado integralmente por empresas

terceirizadas, o banco apenas verifica o código. Uma empresa é responsável pela parte de

processamento de cartões e outra pelo aplicativo.

• Negócios parceiros: Empresas interessadas em usar as soluções de pagamento do

banco, principalmente na forma de cartões cobranded.


• Scrum masters: profissionais terceiros trazidos para auxiliar a adoção de métodos

ágeis no projeto. Responsáveis pela gestão do fluxo de trabalho e auxílio na

realização de cerimônias do Scrum.

• Desenvolvedores frontend: Desenvolvedores terceirizados responsáveis pelo

desenvolvimento do aplicativo do produto.

• Desenvolvedores backend - processamento de cartões: desenvolvedores

terceirizados do back end da plataforma de processamento de cartões. A

plataforma é externa ao banco e contém as principais regras de produto.

• Designers e UXers: Designers e profissionais de user experience (UX) terceirizados.

Responsáveis pela transformação de fluxos e regras em telas.

• Clientes: Clientes dos negócios parceiros, usuários dos cartões de crédito e dos canais

da plataforma.

4.1.2 Levantamento e Agrupamento de Problemas

Os problemas foram levantados a partir de reuniões e pequenas entrevistas com os

stakeholders. Ao todo, foram feitas cerca de 20 entrevistas. Em seguida, os problemas foram

listados e posteriormente agrupados em temas gerais. Ao fim do processo, havia três temas.

Para cada um deles, foram recuperados os principais comentários e problemas expostos; e em

sequência, foram sugeridas abordagens de estudo.

4.1.2.1 Tema 1: Ágil em Escala

Enquanto os desenvolvedores já estavam acostumados com metodologias ágeis, os

colaboradores do banco tiveram dificuldades em se adaptar. A coordenação do projeto já

amadurecia, mas os colaboradores das outras áreas não respeitavam as cerimônias e os

princípios. Ocorreram pequenos conflitos entre os analistas do projeto e os das áreas de apoio.

Esses eventos foram causados por demoras excessivas e falta de transparência, resultando em

cobranças e reclamações.

Entretanto, os alguns analistas das squads já mencionavam como a produtividade do

projeto era mais alta do que as de suas áreas de origem. Havia interesse em disseminar essas

práticas.


O estudo desse tema buscaria propor um plano para a disseminação do ágil dentro da

organização. Incluiria uma taxonomia das áreas mais propícias à mudança e formas de se

realizar essa transição, com foco na integração do trabalho das áreas ágeis e das convencionais.

4.1.2.2 Tema 2: Compliance e Inovação

Os colaboradores do banco foram claros em sua insatisfação com o processo de AR.

Todos escolheram estar no projeto por conta da possibilidade de inovar. Os analistas das squads

valorizavam o exercício de repensar o trabalho feito em suas áreas. Contudo, quando eram

solicitados a contribuir com a AR, se deparavam com requerimentos de que alguns processos

amplamente criticados permanecessem iguais.

Os POs, mais afetados pelo fluxo, afirmavam não saber como priorizar as

condicionantes de AR nas sprints nem acompanhar o trabalho que já tinha sido concluído. Antes

da chegada do analista de integração, ninguém dedicava atenção à AR e os planos de prevenção

e mitigação de riscos eram reconhecidamente mal feitos.

O estudo desse tema buscaria entender o processo de AR, identificar seus problemas e

traçar um plano para a sua realização pelos POs. Como parte desse plano, seria avaliado como

conciliar a organização ágil da equipe com as demandas de compliance.

4.1.2.3 Tema 3: Geração e Seleção de Ideias para Inovação Corporativa

A história não oficial da criação da plataforma era conhecida por praticamente todos

os membros da equipe. A ideia original para a nova plataforma veio de um analista do banco.

Ele estudou a viabilidade do projeto e convenceu os diretores a financiarem o desenvolvimento

de um piloto interno, o qual foi um sucesso. A diretoria decidiu investir no projeto como uma

aposta estratégica para o futuro da organização. O analista foi promovido a coordenador e

recebeu recursos e apoio interno para o desenvolvimento da plataforma.

Tem-se um caso bem sucedido de geração e seleção de ideias de inovação em uma

grande corporação. Contudo, ele seguiu processos ad hoc. Mesmo que haja outras iniciativas

interessantes no banco, há o risco de que elas não sejam reconhecidas e incentivadas.

O estudo desse tema buscaria estruturar um processo interno de geração, seleção e

desenvolvimento de ideias. Outras formas de apoio à inovação como corporate venture também

poderiam ser discutidas.


4.1.2.4 Seleção do Tema

Os temas e questionamentos foram então discutidos com o coordenador e o gerente do

projeto. Por fim, foi decidido que o trabalho se focaria no tema 2: Compliance e Inovação,

devido à urgência do problema dentro do projeto, à disponibilidade de dados quantitativos e

possibilidade de gerar soluções aplicáveis.

4.2 DEFINIÇÃO DOS OBJETIVOS

A fim de direcionar a exploração do tema definido; estudou-se melhor as necessidades

do projeto e como elas se relacionavam com compliance e inovação. Notou-se que a maior

lacuna de conhecimento era sobre o compliance. Procurou-se entender melhor quem eram as

partes envolvidas na gestão de riscos e quais eram suas atribuições.

A norma de AR estabelece o processo do sistema gestão de riscos no lançamento de

novos produtos. Este processo á administrado pela área de governança, a qual acompanha a

atuação das áreas avaliadores e da área demandante. No caso da diretoria de cartões, em ARs o

papel da área demandante é compartilhado pelo PMO cartões e a área de produtos.

Nesse contexto, as os responsáveis reuniram-se com representantes do PMO,

governança e produto. As áreas avaliadoras não foram envolvidas devido às diferenças de

escopo e forma de atuação de cada uma delas. Os representantes de governança esclareceram

sinteticamente as questões mais relevantes.

Foram feitas três reuniões:

Reunião 1: conversa com o gerente e o coordenador do projeto. Os principais

parâmetros foram discutidos logo após a decisão do tema.

Reunião 2: conversa com analista de governança cujo trabalho é analisar

quantitativamente os fluxos de compliance

Reunião 3: conversa com analista de PMO cartões que foi transferida recentemente da

área de governança. Ela possuía muita experiência com o fluxo de AR.

O gerente e o coordenador forneceram uma perspectiva gerencial do efeito da AR

sobre o projeto. Se por um lado a liberação de recursos e o apoio dos diretores estava

relacionada ao cumprimento da AR, por outro, ela dificultava o alcance de milestones do

projeto. Nota-se, contudo, que não foram mencionadas as dificuldades operacionais em adaptar


as demandas da AR para ágil. Embora muito mencionada pelos analistas, os gestores

desconheciam essa preocupação.

Os profissionais de governança e PMO explicaram o funcionamento geral do processo

e os principais problemas reportados pelas áreas. As ARs, em geral, são longas e mal

executadas, havendo brechas para riscos de não compliance.

Dessa forma, identificou-se a importância de diminuir o tempo de processo e garantir

a mitigação e prevenção de riscos. Para que isso fosse executado no projeto da plataforma,

também seria importante adaptar as ferramentas e métodos do ágil às necessidades do banco,

entre elas o processo de AGR.

Logo, o objetivo do trabalho é analisar e propor soluções para a integração operacional

do sistema de gestão de riscos de um banco ao modelo de gestão ágil. Isso significa garantir

que os riscos relevantes sejam mapeados e prevenidos de acordo com os processos do banco

enquanto a equipe mantém sua capacidade de adaptação conforme os princípios ágeis.

4.3 MAPEAMENTO DOS PROCESSOS

Antes de propor soluções, procurou-se entender com mais profundidade a situação

atual da organização. A AR pertence a uma política avaliação de riscos no lançamento de novos

produtos bem estruturada. Por produtos, a norma de AR engloba: “produtos, operações

específicas, estruturas específicas, serviços e processos, para qualquer segmento de negócio”.

Seu objetivo é “Estabelecer a governança de avaliação e aprovação de Produtos com foco na

gestão de riscos, observando as normas e regulamentações aplicáveis e as melhores práticas de

mercado”

Conforme a área de origem e o escopo do projeto há diferentes fluxos e alçadas de AR.

Neste trabalho será abordada AR de maior alçada da Diretoria de Varejo (DV), a AR alçada de

Comitê de Varejo (CV), por ser a avaliação à qual o projeto em estudo foi submetido.

4.3.1 Fluxo da norma de AR

A norma já tem fluxo de processo estabelecido (Erro! Fonte de referência não

encontrada.). Para melhor compreensão, a seguir estão um descritivo dos agentes do processo,

principais termos e uma descrição detalhada de cada etapa.



Figura 6 - Fluxo da Norma de AR


4.3.1.1 Descrição dos Atores e Principais Termos

A fim de se ter uma base teórica para acompanhar o processo de AR, abaixo,

segue uma descrição dos principais atores e termos envolvidos. Essas definições

foram adaptadas de normas e/ou de comentários de profissionais da área de

governança.

Área demandante: é a área responsável pelo produto. No caso em estudo, o papel da

área demandante é dividido entre a coordenação da área de produto e a área de PMO

cartões.

Governança de Aprovação de Produtos: a área de governança da DGV. Atuam como

guardiões do fluxo, garantindo a integridade dos materiais, das condicionantes, das

evidências e dos planos de ação.

Áreas pareceristas indicadas: são as áreas selecionadas para avaliar o produto. Elas

devem entender o escopo do produto, avaliar potenciais riscos e condicionar o

lançamento do produto a medidas que evitem e mitiguem riscos.

Comitê de Produtos Varejo: Comitê executivo composto por diretores das áreas de

governança e varejo.

Condicionantes: Demanda obrigatória visando a prevenção e mitigação de riscos

relacionados ao projeto.

Evidências: Cada condicionante possui uma evidência associada. Em caso de auditoria,

a evidência é a prova da implementação do plano de ação.

Planos de ação: Resposta da área demandante a cada uma das condicionantes.

Explicação das ações que serão tomadas para a prevenção e mitigação de riscos.

4.3.1.2 Etapas do Processo

A seguir, adaptações da definição de cada etapa do processo de AR descrito em norma

interna do banco:

1. Criação do projeto no portal AR: Criação do projeto na intranet de governança.


2. Apresentação no Fórum de Alinhamento: Apresentação do projeto para fórum com

analistas das áreas avaliadoras. Necessário apenas em projetos com alçadas maiores de

AR.

3. Preenchimento do Formulário Único de Aprovação de Produtos: Preenchimento de

formulário com o descritivo do escopo do projeto e detalhes do interesse específico das

áreas avaliadoras. O formulário indica as áreas que irão avaliar o projeto e serve como

material explicativo.

4. Avaliação da especificação e distribuição para Áreas Pareceristas Indicadas:

Avaliação do conteúdo do Formulário Único de Aprovação de Produtos pela

governança.

5. Avaliação do Produto: Avaliação do projeto pelas áreas pareceristas. Nesta etapa são

levantadas as condicionantes e evidências associadas.

6. Detalhamento dos planos de ação para atendimento das condicionantes: A área de

produto desenvolve planos de ação para as condicionantes levantadas pelas áreas

avaliadoras.

7. Validação dos planos de ação para atendimento das condicionantes: As áreas

pareceristas avaliam se os planos de ação serão suficientes para evitar os riscos e atender

às condicionantes.

8. Aprovação final em CV: Em projetos de maior risco, a equipe de produto deve

apresentar as principais condicionantes e planos de ação para diretores, os quais

decidem pela aprovação direta ou revisão de alguns planos.

4.3.1.3 Descrição Detalhada do Processo

Para desenvolver um novo produto, o primeiro passo é criar o projeto no portal AR.

Para acessar o portal, é necessária uma requisição formal de acesso. Um formulário deve ser

preenchido com as informações dos colaboradores solicitantes. Este formulário precisa ser

validado pelo gerente da área por meio de um e-mail com um “de acordo” com o formulário

anexado. Após o envio do formulário com a validação, o acesso é aprovado em cerca de uma

semana.

Com o acesso, pode-se criar o projeto no portal AR. Nesse momento inicia-se um timer

que passa a contar quantos dias úteis se passam até a aprovação de todos os planos de ação. No

caso de alçada CPV, o projeto deve ser apresentado em Fórum de Alinhamento, o qual inclui

40 áreas avaliadoras.


Em paralelo, deve ser preenchido o Formulário Único de Aprovação de Produtos, um

documento em Excel. Ele tem duas funções principais: conter as informações necessárias para

que os avaliadores possam compreender o escopo do produto e determinar quais áreas estarão

envolvidas na avaliação.

Após a realização do fórum e o envio do formulário no portal AR, a área de governança

avalia se o formulário está completo e claro o suficiente. Caso não esteja, retorna para a área de

produto via portal. Caso apto, segue para as áreas avaliadoras.

A depender do tamanho da área avaliadora, o SLA e o subprocesso de avaliação podem

ser diferentes. As áreas avaliadoras devem analisar o projeto em busca de potenciais riscos e

estabelecer condicionantes para prevenir e mitigar os riscos envolvidos. O parecer de uma área

se dá na forma de um formulário padrão com condicionantes e evidências.

Uma condicionante (Tabela ) é uma requisição para a equipe de produto. Cada

condicionante deve ser uma demanda diretamente relacionada a um risco ou obrigação. Não

podem ser sugestões ou dúvidas. Há dois tipos principais de condicionantes: pré e pós-

implementação. As de pré-implementação devem ser atendidas antes do lançamento do produto

e as de pós-implementação até um ano depois. Esses prazos qualificam o projeto a ser auditado

pela auditoria interna do banco.

Cada condicionante é acompanhada por uma evidência e um campo de plano de ação.

A área avaliadora coloca uma condicionante e indica o que serviria de evidência de que a área

de produto obedeceu à condicionante.


Tabela 2 - Exemplos de Condicionantes, Evidências e Planos de Ação


Os documentos com o parecer de cada área avaliadora são enviados para área

demandante com as condicionantes e evidências. Então, cabe à área demandante responder com

planos de ação para cada uma das condicionantes. Estes planos explicam quais ações serão

tomadas para satisfazer à condicionante ou justificam a não aplicabilidade da condicionante.

Após levantar todos os planos, a área demandante devolve os pareceres para as áreas

avaliadoras via portal. Então, os planos são avaliados e, caso reprovados, retornam para a área

demandante com uma devolutiva justificando a reprovação. Caso aprovados, a área muda o

status de sua avaliação no portal para concluído.

Quando todas as áreas concluem o parecer, o timer do portal para de contar e, nas

alçadas cabíveis, pode-se agendar uma reunião com o CPV. O comitê pode então aprovar o

produto para lançamento ou estabelecer condicionantes adicionais.


Espera-se que as áreas ajam de boa fé ao longo do processo. Contudo, a área de

auditoria do banco pode atuar para verificar se o produto de fato atendeu às condicionantes. Em

caso de auditoria, é esperado que a área de produto tenha de fato implementado os planos de

ação e tenha todas as evidências registradas no portal AR. No entanto, só é constatado o não

compliance caso se encontre uma evidência de descumprimento à condicionante. A não

conformidade com o a AR leva a sanções disciplinares

Entretanto, observou-se que o fluxo da AR do projeto em estudo tinha etapas

adicionais às da norma. Isso ocorreu porque o fluxo da norma é uma versão simplificada e a

área de cartões de crédito tem algumas especificidades. A área recebeu sanções por não

compliance com AR nos dois últimos anos e, por isso, o PMO da diretoria divide o papel de

área demandante com a área de produto na AR.

4.3.2 Fluxo expandido de AR

Objetivando compreender a situação da AR, foi realizado um mapeamento mais

robusto do processo. Ele foi mapeado na forma em que de fato ocorre na área, e três

subprocessos foram mapeados em profundidade.

As principais diferenças entre o fluxo expandido (Erro! Fonte de referência não

encontrada.) e o da norma são a divisão do papel de área demandante entre a área de produto

e o PMO, um loop adicional referente à aprovação do Formulário Único de Aprovação de

Produtos e o intermédio da governança entre cada ação das áreas demandante e avaliadoras.


Figura 7 - Fluxo Estendido e AR



Dentro do fluxo de AR há dois subprocessos de especial relevância, a avaliação do

produto por parte das áreas avaliadoras e o detalhamento dos planos de ação para atendimento

das condicionantes por parte da área demandante. Nesses subprocessos as condicionantes são

desenvolvidas e respondidas, respectivamente. Logo, é nesses momentos que os riscos serão

mapeados e efetivamente abordados.

Entretanto, notou-se que não havia um processo estruturado para a implementação dos

planos de ação após sua aprovação. Até serem passíveis de auditoria, as áreas demandantes

podem se organizar livremente. Tal liberdade é positiva, pois evita uma perda de agilidade

desnecessária, contudo, gera riscos relativos a implementações tardias ou demasiadamente

aceleradas. Então, também foi mapeado o processo de implementação de planos de ação.

4.3.3 Fluxo de avaliação de produto

Uma AR de alçada CPV envolve, em média, 20 áreas avaliadoras. Cada uma dessas

áreas é acionada por e-mail via portal AR e deve, resumidamente, entender o projeto, identificar

potenciais riscos, levantar condicionantes para prevenir ou mitigar tais riscos e indicar as

evidências associadas a cada condicionante.

4.3.3.1 Descrição dos Atores nas Áreas Avaliadoras

Dentro da área avaliadora, há diferentes papéis desempenhados pelos colaboradores.

Tais papéis não são fixos, a depender do tamanho do escopo e do tamanho da área, a gestão de

riscos pode ser mais ou menos dividida em diferentes hierarquias. A seguir, uma descrição dos

principais papéis e suas atribuições:

Gestor de Apoio (GA): Cargo mínimo gerente, é o responsável por administrar a AR

dentro da área.

o GA de Distribuição: É o GA que recebe a demanda e indica o executor que será

responsável dentro da área.

o GA de Aprovação: É o GA que verifica toda a informação que trafega pela

área. Ele deve aprovar o acionamento da área, as condicionantes, as evidências,

os planos de ação e a devolutivas.


o GA de Aprovação e Distribuição: É o GA que acumula as funções de GA de

aprovação e de GA de Distribuição.

Executor: O analista responsável por desenvolver pelo parecer da área

o Ponto focal: Executor que levanta as condicionantes pela área, verificando o

impacto nas subáreas.

o Consolidador: Executor responsável por consolidar os pareceres das subáreas.

Ele não levanta condicionantes, mas deve verificar a coesão das levantadas pelas

subáreas e consolidá-las em um único parecer.

Pool de Executores: grupo de analistas que podem desempenhar o papel de executores.

Em uma nova AR, o executor pode ser decidido entre os próprios analistas ou pelo GA.

4.3.3.2 Descrição dos Tipos de Serviço

O tipo de serviço de uma área define é determinado pelo número de subáreas dentro

da avaliadora. Em áreas pequenas, apenas uma pessoa é responsável pelo parecer. Em áreas

maiores, algumas com 51 subáreas, a responsabilidade é dividia. A seguir, os dois tipos de

serviço:

Ponto focal: Caso no qual a área possui apenas um executor. Ele pode fazer o parecer

sozinho ou chamar outras analistas para auxiliá-lo quando achar cabível.

Serviço composto: Caso no qual a área possui um executor consolidador e vários

executores pontos focais, um por subárea. Cada subárea emite um parecer e eles são em

seguida consolidados em um parecer único pelo executor consolidador.

4.3.3.3 Descrição do Fluxo

Independente do tipo de serviço e da organização interna de cada área, o subprocesso

de avaliação de produto é essencialmente o mesmo (Erro! Fonte de referência não

encontrada.). O produto é avaliado e são levantadas condicionantes. O que muda é o SLA, o

envolvimento ou não de um GA e a divisão de responsabilidade pelas condicionantes.


Figura 8 - Fluxo de Avaliação do Produto



Conforme as áreas concluem suas avaliações, os pareceres com condicionantes são

subidos no portal. A área de governança avalia os pareceres e aciona a área de produtos via

portal AR. O analista de produtos recebe um e-mail automático do portal, neste caso uma

analista de PMO cartões, Os pareceres são encaminhados um a um, via e-mail, para o analista

da área de negócios.

4.3.4 Fluxo de Detalhamento dos Planos de Ação

Em geral, um analista da área demandante sozinho é capaz de responder todas as

perguntas levantadas sobre o projeto e desenvolver planos de ação para as condicionantes.

Contudo, o escopo do projeto em estudo é amplo e há uma divisão funcional das squads do

projeto. Logo, um PO não tem pleno conhecimento do trabalho da squad de outro PO. Dessa

forma, no projeto em estudo o subprocesso de detalhamento dos planos de ação para

atendimento das condicionantes (figura 9) foi especialmente complexo.


Figura 9 - Fluxo de Detalhamento de Planos de Ação



O analista de integração é responsável por receber e avaliar os pareceres das áreas

avaliadoras. Caso os riscos relacionados às condicionantes sejam do seu conhecimento, ele já

responde o parecer com os planos e o envia por e-mail para a área de PMO. Caso os riscos

sejam mais específicos, ele identifica a squad relacionada e encaminha o parecer por e-mail

para o PO responsável. Não há SLA oficial para o desenvolvimento dos planos de ação.

O PO, então, avalia as condicionantes e tenta respondê-las. Em último caso, o parecer

é encaminhado para um analista envolvido com o projeto que tenha conhecimento específico

sobre os riscos em questão, normalmente um analista da mesma diretoria da área que emitiu o

parecer.

4.3.5 Fluxo de Implantação de Planos de Ação

O último subprocesso a ser detalhado não está oficialmente no fluxo de AR. É o

subprocesso de implantação dos planos de ação (Figura 10). Uma vez que o parecer da área

avaliadora foi dado como concluído, a área de produto tem o compromisso de implementar os

planos de ação e coletar as evidências combinadas.

Nessa etapa, surgem os desafios de delegar as condicionantes para os POs (Figura 11),

definir como quando serão priorizadas nas sprints e gerenciar a coleta de evidências dentro do

prazo estabelecido.

Figura 10 - Implementação de Itens de Backlog



Figura 11 - Integração dos Planos no Backlog


4.4 IDENTIFICAÇÃO DOS PROCESSOS CRÍTICOS

Tendo conhecimento dos processos, podem-se identificar os pontos mais críticos para

a diminuição do tempo do processo e do risco de não compliance. Enquanto o tempo pode ser

avaliado de forma quantitativa, o risco de não compliance requer uma análise qualitativa. Sendo

assim, os processos críticos foram escolhidos por meio de duas análises distintas.

4.4.1 Avaliação Quantitativa

Para identificar as etapas que tomam mais tempo no fluxo, fez-se um levantamento

com a área de analytics da governança do banco, a qual realiza estudos de tempo de fluxo

semestralmente. Embora estas informações não estejam expostas no portal, por meio dos logs

do sistema é possível identificar todos os instantes em que houve alteração de status no portal

e o tipo de alteração.

Tendo conhecimento do tipo de dado em posse da governança, foi feita uma requisição

de informações para a área, a fim de obter as medidas dos tempos médios de fluxo. Essas


medidas permitiram a identificação do tempo de processo de cada etapa da AR em relação ao

tempo total de ciclo.

Tabela 3- Tempos de Fluxo de AR


Uma semana depois se fez uma reunião para a discussão das informações fornecidas

(Tabela ). Nota-se que a soma dos tempos de cada etapa é inferior ao tempo médio de processo.

Isso ocorre porque os tempos de loop não são computados em detalhe. Um loop ocorre quando

um Formulário Único de Aprovação de Produtos ou um plano de ação é reprovado e o

documento retorna para a área demandante. O refazimento das etapas de preenchimento de

formulário e de desenvolvimento de planos são contabilizados apenas na duração total da AR.

Então, em média demora 7 dias úteis (du) para a avaliação dos planos de ação. Contudo, essa

avaliação é feita várias vezes em uma mesma AR.

Cabe adicionar que o tempo entre a conclusão dos pareceres e a aprovação em CPV

não é contabilizado. A concepção geral é que demore a partir de um mês. Dessa forma, o time

to market mínimo dos produtos ainda é maior do que o oficialmente divulgado.

A maior fração do processo se refere aos loops. Contudo, pode-se afirmar que esses

29du se referem quase que exclusivamente ao loop de revisão dos planos de ação. Isso ocorre

pois após a reprovação do Formulário Único de Aprovação por parte da governança, é uma

prática comum cancelar o projeto no portal, e submeter a versão corrigida em um novo projeto.

Dessa forma, o timer do projeto é reiniciado e não há sanções para os envolvidos, pois esse tipo

de cancelamento é tipificado com um cancelamento não oneroso.

As outras duas maiores frações se referem aos subprocessos das áreas avaliadoras, a

avaliação de produto e a validação dos planos de ação para o atendimento das condicionantes.

Logo, a maior parte da AR se dá na discussão dos planos de ação entre a área demandante e as

áreas avaliadoras, 29 du, sendo que a avaliação do produto e validação dos planos de ação

seguem logo atrás, 19 du.

1. Criação do

projeto no portal AR

2.

Apresentação no

Fórum

3.

Preenchimento do

Formulário

4. QA

-

Avaliação

5.

Avaliação do

Produto

6. Detalhamento

dos planos de ação

7.

Validação dos

planos

Tempo médio da etapa - - - 5 du 6 a 12 du 2 du 7 du

Tempo médio do conjunto 5du

Tempo médio total

Tempos de Fluxo da AR

2du 15 du a 21 du

67 du


4.4.2 Avaliação Qualitativa

Em busca de uma compreensão mais profunda dos problemas no fluxo de AR,

conversou-se com uma analista com experiência na área de governança. Ela demonstrou grande

conhecimento das más práticas recorrentes nas ARs. Como analista de PMO, atua junto à área

de produto para garantir a adesão às boas práticas no processo.

Dessa reunião obtiveram-se a descrição detalhada dos processos e algumas más

práticas pontuais. Ao longo do processo, alguns comportamentos que aumentam o risco de não

compliance se repetem nas diferentes áreas do banco.

Filtragem de e-mails automáticos do portal AR: Os analistas das áreas pareceristas e

de governança recebem e-mails automáticos indicando a mudança dos status dos

projetos no portal AR. Contudo, e-mails são enviados mesmo para alterações que não

demandam ações por parte do analista. Dessa forma, é comum o recebimento de 50 a

80 e-mails por dia do portal. Por conta o excesso de comunicação, os analistas filtram

os e-mails do portal AR diretamente para o spam, ficando sem informação comunicação

alguma. A verificação é feita de forma manual.

Geração de condicionantes padronizadas: Algumas áreas pareceristas nem chegam a

tentar entender o projeto em avaliação. Enviam sempre as mesmas condicionantes e

possuem um SLA de até 5 du para tanto.

Geração de condicionantes não conformes: É comum a imposição de condicionantes

sem o objetivo de prevenir e mitigar riscos. São condicionadas reuniões, dúvidas e

sugestões. Nesses casos, não se garante que os riscos serão abordados e são geradas

imposições desnecessárias para a área demandante.

Ausência de evidências: As áreas avaliadoras enviam condicionantes sem sugestão de

evidência. Nesses casos, a área demandante não consegue a aprovação do parecer pela

governança até que sejam decididas as evidências. Então, a área de produto devolve o

parecer e cobra as evidências, situação em que se costuma extrapolar o SLA para a

devolutiva, ou a própria área demandante sugere as evidências nos planos de ação. A

segunda opção, embora rápida, gera um trabalho adicional para a área demandante e

pode deixar passar interpretações erradas das condicionantes, desconsiderando a

prevenção e mitigação de riscos importantes.

Reprovação para renovação do SLA: Quando áreas de subprocesso se esquecem de

envolver alguma subárea, para evitar extrapolar o SLA e ter a meta impactada


negativamente, elas enviam um parecer reprovando o projeto. Então, a área de produto

deve pedir uma revisão de status, o que renova o SLA da área demandante e permite a

inclusão de todas as subáreas. Nesse caso, além do dispêndio desnecessário de tempo,

o indicador do SLAs é burlado; não se evidenciando portanto o testemunho desta má

prática.

Planos de ação genéricos: Planos de ação no formato “Será atendido” ou “OK”. Nesses

casos, interpretações erradas das condicionantes podem só ser percebidas no momento

da auditoria. Há casos em que se tem um plano de ação adequado para uma

condicionante mal interpretada ou um plano inadequado para a condicionante correta.

Demora na implementação dos planos: Algumas condicionantes requerem o

envolvimento de uma área até um momento discreto não relacionado com o prazo da

AR, como o fechamento de um contrato ou definição de um fluxo.

Os problemas indicados pela analista se referem à parte essencial da AR: a

identificação de riscos, o levantamento de condicionantes e o desenvolvimento e

implementação de planos de ação. Nesse sentido, para diminuir o risco de não compliance de

forma eficiente levando em consideração a diminuição do time to market, decidiu-se atuar nas

etapas de:

Avaliação do produto;

Detalhamento dos planos de ação para atendimento das condicionantes;

Implementação dos planos de ação.

4.5 IDENTIFICAÇÃO DAS CAUSAS RAÍZES

Para estabelecer hipóteses sobre as causas raízes dos problemas em cada uma das

etapas, foram utilizados diagramas de Ishikawa. O diagrama é utilizado para as causas

relacionadas a um problema específico. E, após o levantamento das causas, foi feita uma análise

mais profunda de cada uma delas.

4.5.1 Avaliação do produto

Para este subprocesso, as causas raízes forma analisadas no seguinte diagrama:


Figura 12 - Diagrama de Ishikawa - Avaliação do Produto


As causas levantadas são discutidas mais a fundo abaixo:

Muitos encaminhamentos: Em áreas com subprocesso há muitos encaminhamentos

até que o parecer chega à pessoa que pode atuar sobre ele. No pior caso, na reavaliação

de um parecer em uma área com GA de distribuição e subprocesso, o documento deve

passar por:

1. PO

2. Analista de produto

3. Analista de PMO

4. Analista de governança

5. GA de distribuição

6. Executor consolidador da área avaliadora

7. Executor ponto focal da subárea

Dependência do GA: O gestor de aprovação é um colaborador distante da parte

operacional do trabalho. Então, não raro o GA aprova os pareceres sem vê-los ou é

gargalo para o fluxo do parecer entre as áreas. Em um caso emblemático, duas semanas

se passaram até que o parecer pudesse chegar à parecerista, a qual já sabia o que tinha

que alterar. O PMO enviava para o portal, governança encaminhava para a área e o GA


aprovava o parecer imediatamente, retornando o parecer para o PMO. O GA deveria

assinalar a necessidade de correção e encaminhar o parecer para a executora.

Envio consolidado e manual: É necessário que um analista consolide os pareceres das

subáreas manualmente e o documento só pode seguir no processo de AR por inteiro.

Caso a área demandante já tenha os planos de ação para uma subárea, deve esperar até

ter a resposta para todas as subáreas para enviar o documento. Os SLAs funcionam para

a área como um todo.

Condicionantes fora de formato: Analistas de áreas pareceristas levantam

condicionantes fora dos modelos oficiais. Condicionam dúvidas, sugestões ou medidas

que não se aplicam ao projeto. Geram trabalho adicional para a área demandante e

podem ignorar riscos que deveriam gerar condicionantes aplicáveis.

Ausência de evidências ou evidências vagas: Ao não explicitarem as evidências,

correm o risco de admitir interpretações erradas das condicionantes por parte da área de

produto.

Visibilidade dos SLAs: A área de produto não sabe exatamente qual é o SLA de

resposta de cada área avaliadora para cada área do processo. O portal AR chega a

mostrar alguns indicadores do tempo que a responsabilidade está com a área avaliadora,

mas não é possível reponder qual é o prazo de resposta da área.

Não há rastreabilidade por analista: Em geral, a área demandante não sabe com quem

falar para discutir uma condicionante específica. Embora haja um campo para a

identificação do responsável pela condicionante, ele costuma ser preenchido apenas

com o nome da área.

Portal envia e-mails demais: O portal envia e-mails automaticamente para os analistas

de governança e das áreas avaliadoras responsáveis pelo projeto. No entanto, o portal

envia e-mails sobre alterações que não demandam ações do analista, gerando e-mails

demais. Em alguns casos, um analista pode chegar a receber de 50 a 80 e-mails por dia

do portal. Por isso, é comum o uso de filtros que arquivam todos os e-mails oriundos do

portal AR. Então, os analistas checam manualmente por alterações de status no portal.

4.5.2 Detalhamento dos planos de ação para atendimento das condicionantes



Figura 13 - Diagrama de Ishikawa - Detalhamento dos Planos de Ação



Condicionantes que não se aplicam: Algumas áreas emitem sempre a mesma lista de

condicionantes, muitas das quais não se aplicam. Em vez de o parecerista entender os

riscos envolvidos com o projeto e emitir condicionantes aplicáveis, a área de produto

tem que gastar tempo procurando entender o que está condicionado e discutir a não

aplicabilidade com a área avaliadora.

Ausência de rastreabilidade: Na hora de discutir uma condicionante, o analista da área

demandante não sabe com quem falar. Deve entrar em contato com o PMO para saber

o parecerista da área que levantou a condicionante em questão. Daí, deve ainda

perguntar ao consolidador quem emitiu a condicionante. Esse processo pode demorar

dias.

Evidências vagas: Evidências que deixam espaço para mais de uma interpretação

geram risco de não compliance e de penalidades desnecessárias. A área de produto pode

interpretar errado a evidência e, mesmo implementando um plano adequado, sofrer

sanções por não ter a evidência desejada.

Ausência de status: A área de negócios não sabe em tempo real o status de cada parecer.

Com quem está, em que estado e há quanto tempo. Para responder a essas perguntas,


deve esperar os relatórios semanais do PMO, ou deve requisitar que o PMO acesse o

portal e repasse as informações requisitadas.

POs sem conhecimentos específicos: Os analistas de produto não têm conhecimento

de todos os jargões, processos e normas das áreas avaliadoras. Dessa forma, surge

constantemente a necessidade de entrar em contato com a área avaliadora para tirar

dúvidas sobre as condicionantes.

Não há SLA para a área demandante: Não há um prazo determinado para a área de

produto desenvolver os planos de ação. Considera-se que é do interesse da área

desenvolver os planos o mais rápido possível. Contudo, quando um PO recebe uma

demanda sem prazo que não afeta a sua meta, ele dificilmente a trata como prioridade.

Fluxo de documentos por e-mail: A área de negócios recebe os pareceres por e-mail,

sem que haja um formato padrão. Dessa forma, os pareceres ficam dispersos e

eventualmente passam despercebidos. Esse fenômeno ocorre em todas as áreas

envolvidas na AR, até mesmo a de produto.

4.5.3 Implementação dos planos de ação



Figura 14 - Diagrama de Ishikawa - Implementação dos Planos de Ação



Dificuldade em distribuir as estruturantes: A divisão de trabalho entre os POs é feita

por critérios funcionais. Dessa forma, condicionantes estruturantes do projeto, as quais

não se relacionam necessariamente com entrega de valor ao cliente, não tem relação

clara com uma squad.

Planos de ação e condicionantes vagos: Os analistas ficam responsáveis por planos de

ação que outra pessoa desenvolveu para condicionante com a qual estão tendo o

primeiro contato. Nesse contexto, condicionantes e planos de ação vagos requerem um

retrabalho para a compreensão do que deve ser feito, abrindo espaço para que os riscos

não sejam prevenidos e mitigados adequadamente.

Prazos curtos para implementação: Algumas condicionantes requerem o

envolvimento de colaboradores específicos no desenvolvimento de um fluxo ou

contrato antes de sua finalização. Como em geral os planos de ação de AR demoram a

ser distribuídos e implementados, o analista responsável pode se dar conta da

necessidade tarde demais.


POs evitam lidar com AR: Ao priorizar uma demanda de condicionante em vez de

uma feature, os analistas de produto deixam de seguir suas metas e de entregar valor

para o cliente a fim de atender uma demanda interna do banco. A visão negativa que os

analistas têm sobre a AR afeta a priorização de planos de ação.

Não há SLAs intermediários: Não há metas intermediárias de implmentação dos

planos de ação. Apenas têm-se as datas chave de lançamento do produto, quando as

condicicionantes de pré-implantação já devem ter sido abordadas, e a data de início do

período de eligibilidade à auditoria. Dessa forma, os planos tendem a ser priorizados de

última hora, com o risco de serem implementados de forma incompleta.

4.6 LEVANTAMENTO DE SOLUÇÕES

A partir das causas dos problemas, para cada etapa do processo foi feito um

levantamento de soluções. Esse levantamento combinou sugestões dadas pelos próprios

stakeholders, e duas sessões individuais de brainstorming espaçadas em uma semana. As

soluções foram levantadas de forma segmentada. Cada solução foi relacionada a uma causa raiz

em um subprocesso.

4.6.1 Avaliação do Produto

A seguir estão as propostas de solução levantadas para as causas raízes relacionadas

ao subprocesso de avaliação de produto:

Disponibilizar documento do parecer em nuvem para permitir o acesso a todos os

pareceristas da área;

Para áreas que sempre mandam as mesmas condicionantes, transformar as

condicionantes em um checklist e diminuir o SLA para a avaliação;

Caso a área apresente condicionantes fora do formato e conteúdo sugeridos, envolver a

governança para acionar os GAs;

Não permitir o reset do SLA da área;

Abrir a possibilidade de reavaliações em apenas uma subárea;

Medir SLA por subárea;

Permitir configurar os casos de envio automático de e-mail pelo portal;

Inserir botão para enviar e-mail de lembrete no portal.


4.6.2 Desenvolvimento dos planos de ação


ao subprocesso de desenvolvimento de planos de ação:

Acompanhamento interno do tempo de resposta dos POs;

Estabelecer SLA para a resposta dos analistas de produto de acordo com o SLA para o

desenvolvimento dos planos por parte das áreas pareceristas;

Pedir acesso ao Portal AR para que a área de produto possa verificar em tempo real as

informações do projeto.

4.6.3 Implementação dos planos


ao subprocesso de implementação dos planos:

Dividir as condicionantes estruturantes em blocos conforme seu conteúdo e dividir esses

blocos de forma balanceada entre os POs. Distribuir considerando o número de

condicionantes que cada PO já tem sob sua responsabilidade.

Ao propor uma condicionante, as áreas poderiam ser obrigadas a colocar uma estimativa

de tempo para implantação do plano de ação da demanda;

Incluir exemplos de condicionantes e evidências corretas adequadas no formulário de

condicionantes para que as áreas tenham uma referência;

Ao recusar um plano de ação, a área deveria incluir o motivo de reprovação para cada

um dos planos;

Diminuir todos os SLAs para a avaliação dos planos de ação;

Reformatar o documento de parecer a fim de permitir o manuseio e a análise das

condicionantes, planos e evidências;

Identificação e contato do parecerista/especialista que levantou a condicionante no

próprio documento de condicionantes;


4.7 PRIORIZAÇÃO DE SOLUÇÕES

Para selecionar quais das soluções levantadas seriam implementadas, fez-se uma

análise baseada no impacto e esforço relativos de cada solução. Para estimar o impacto,

considerou-se a relevância para o projeto e a urgência da solução. Para o esforço, a

pilotabilidade.

Em primeiro lugar, foi feita uma análise de impacto. Devido à dificuldade de se estimar

a potencial redução de time to market e risco de não compliance de cada solução, para avaliar

o impacto foi empregada uma adaptação do RUT, critério usado na priorização de backlog do

projeto.

O RUT (Tabela ) é uma nota de priorização para o desenvolvimento de produtos. Que

permite avaliar quantitativamente o valor de uma feature. Baseia-se em um múltiplo de três

fatores (relevância, urgência e tendência), cada um com uma nota de um a cinco votada pela

squad - será descrita adiante no subitem 4.8.6.3

Tabela 4 - Critérios de RUT

Fonte: Retirado de (CHIARA, 2016)

Em segundo lugar, foi feita uma análise de esforço. O esforço foi determinado por um

produto entre o tempo de implementação (1-5) e a pilotabilidade (1-3). A pilotabilidade é um

indicador da possibilidade do analista de integração implementar e controlar a solução. Leva

em consideração a necessidade de abrir uma requisição interna ou aprovação de gestor e a

possibilidade de ser executada pelo próprio analista. Uma solução com baixo esforço pode ser

realizada rapidamente pelo próprio analista de integração sem a necessidade de passar por

processos internos na organização.


4.7.1 Análise de Impacto e Esforço

Para o uso mais eficiente de recursos, devem-se priorizar as soluções de alto impacto

e baixo esforço. Então, cada solução foi plotada em um gráfico Impacto x Esforço (Figura 15).

Figura 15 - Matriz de Impacto vs Esforço

Fonte: Estruturado pelo autor, 2018.

Adaptado de GILAD, 2018

Nota-se que o quadrante superior esquerdo está vazio. Ou seja, segundo o critério de

avaliação escolhido, não há soluções de baixo esforço e alto impacto. Nessa situação, foi

necessário encontrar outra forma de priorizar as soluções. Ao se verificar o conjunto de soluções

avaliadas como de baixo esforço, percebeu-se que seria possível executar quase todas.

4.7.2 Análise de Pilotabilidade

Ao se verificar as soluções de baixo esforço, as únicas que não poderiam ser

implementadas possuíam baixa pilotabilidade. Então, percebeu-se que todas as soluções com

pilotabilidade maior ou igual a dois poderiam ser executadas com os recursos disponíveis.

Então, foi decidido implementar várias soluções de pequeno impacto em detrimento de poucas

com alto impacto. Além de terem mais chances de serem implementadas de fato, as soluções

de baixo esforço ainda podem ser verificadas e incrementadas.


4.7.3 Soluções Escolhidas

As soluções escolhidas foram então revisitadas. A partir das soluções, buscou-se

entender melhor a situação atual da organização, os problemas e suas causas. Esse exercício

permitiu uma visão mais clara sobre os objetivos de cada solução.

4.7.3.1 Pedir o acesso ao portal

Contexto: A equipe de produto não tem acesso ao portal, onde estão as informações sobre o

andamento da AR. A atualização de status é feita apenas uma vez por semana e checagens

pontuais precisam sem pedidas para a área de PMO o nome dos pareceristas e se eles estão

dentro do prazo de resposta.

Problema: O tempo de resposta da área de produto é comprometido. Caso haja alguma

alteração de status, ela só é percebida após uma semana. Além disso, para ter acesso a

informações relevantes como o nome do parecerista, é preciso esperar a resposta e atuação do

PMO.

Solução: Pedir acesso ao portal à área responsável. Dessa forma, a área de produto terá

visibilidade instantânea, sem precisar acionar a área de PMO.

4.7.3.2 Rateio de condicionantes estruturantes:

Contexto: As condicionantes estruturantes são distribuídas arbitrariamente entre os POs e,

consequentemente, entre os desenvolvedores.

Problema: Ocorre grande desbalanceamento no uso de recursos e alguns POs ficam

desproporcionalmente prejudicados em relação às suas metas.

Solução: Fazer um rateio das condicionantes estruturantes considerando o backlog de cada um

dos POs, de forma a balancear as demandas distribuídas a cada um deles.

4.7.3.3 Atuação nos GAs:

Contexto: Em áreas com GA, um colaborador de cargo alto na hierarquia deve validar os

pareceres da área a cada alteração. As avaliações são feitas de forma superficial e não raro a

etapa é um gargalo para o avanço da AR. Discussões feitas com os analistas pareceristas devem

ser repetidas com os GAs e, em geral, chega-se às mesmas conclusões. As áreas repetem os

mesmos erros em ARs diferentes.


Problema: O GA torna o processo mais lento sem efetivamente diminuir o risco de não

compliance.

Solução: A área de produto deve identificar se há um GA e atuar diretamente nele, de forma a

evitar retrabalho e evitar demoras desnecessárias na avaliação do parecer. Em casos que áreas

avaliadoras não seguem a norma, a governança deve ser acionada para avisar o GA.

4.7.3.4 Acompanhamento interno do tempo de desenvolvimento de planos de ação

Contexto: Não há SLA estabelecido para o desenvolvimento de planos de ação por parte da

área de produto, é esperado que eles o façam o mais rápido possível.

Problema: Não há parâmetro de tempo para os POs responderem as condicionantes. Sem

prazo, outras demandas são priorizadas em vez do desenvolvimento de planos de ação.

Solução: Monitoramento dos tempos de processo na etapa de desenvolvimento de planos de

ação. Visão por área e PO.

4.7.3.5 Devolutivas acionáveis

Contexto: No momento da reprovação dos planos, algumas áreas enviam devolutivas vagas,

apenas constatando a reprovação.

Problema: A área de produto demora a entender o que pode fazer para obter a aprovação.

Solução: Pedir devolutivas acionáveis, contendo com quem falar e os pontos a serem

discutidos.

4.7.3.6 Transformação de condicionantes em itens de backlog

Contexto: As condicionantes e os planos de ação no documento oficial da governança estão

dispersos, em um formato difícil de ser trabalhado. A área de PMO possui uma macro que

transfere os campos para uma planilha mais bem formatada. Não há relação direta entre os

campos de informação relevantes para as condicionantes e os itens de backlog.

Problema: As condicionantes não encaixam no backlog do projeto e a transferência da planilha

do PMO para o backlog é lenta e manual, com chances de perda de informação.

Solução: Selecionar as informações das condicionantes pertinentes a serem inseridas no

backlog e adaptá-lo para recebê-las. Uma vez organizado, criar método automático para a

transferência.


4.8 IMPLEMENTAÇÃO DE SOLUÇÕES

4.8.1 Pedir o Acesso ao Portal AR

Há um fluxo de solicitação específico para o acesso ao portal AR. A área do PMO

explicou como proceder. Essa informação está disponível no portal de colaboradores, mas

usualmente é repassada às áreas de negócio pela própria governança.

Preenche-se um formulário específico para esse tipo de requisição com informações

como o nome dos analistas e as áreas do portal para as quais se pede o acesso. Esse formulário

é uma planilha de Excel com macros. No projeto em questão, devido a erros na automação da

planilha, o preenchimento da planilha demorou cerca de uma semana.

Em seguida, esse documento foi enviado para o gerente da área para a obtenção do “de

acordo”. Aqui nota-se que, embora um procedimento simples e de baixo risco, há a necessidade

de um “de acordo” da alçada mínima de gerente. Por conta de viagens de trabalho e de

problemas de agenda, esse “de acordo” só foi emitido mais de duas semanas depois da primeira

requisição.

Com o “de acordo”, foi possível realizar a requisição de acesso. Para tanto, foi

necessário preencher mais um formulário online. Após uma semana e meia, foi recebido o e-

mail com a aprovação. Dessa forma, foi necessário mais de um mês para obter o acesso ao

portal.

O acesso direto ao portal AR já tinha sido desaconselhado por outras áreas de produto

da diretoria. Alegaram que o esforço adicional não se justificava. De fato, o tempo gasto para

consolidar as informações de status de cada área no portal foi muito alto. Os analistas do PMO

não só têm mais familiaridade com o portal, como também tem ferramentas que

automaticamente extraem dados relevantes e os estruturam na forma de relatórios, os quais

enviam semanalmente para a área de produto.

Então, o acesso ao portal teve sua serventia limitada a consultas de nomes de

pareceristas das áreas avaliadoras. Antes, se dependia da disponibilidade do PMO para fornecer

essas informações. Cada consulta desse gênero feita diretamente no portal economiza cerca de

um dia útil.

4.8.2 Rateio de Condicionantes Estruturantes

A responsabilidade por um item em backlog é atribuída ao PO da squad responsável

por aquela experiência. O tracking da entrega do cartão pelos correios, por exemplo, é de


reponsabilidade da squad “Conquistar”, a qual engloba desde o cadastro do cliente até o seu

primeiro uso do cartão físico. Então, caso uma condicionante se refira a questões estruturantes

do projeto que não estejam diretamente ligadas à experiência do cliente, não há critério

estabelecido para direcionar essa demanda.

Na primeira AR da plataforma, quando a área de Segurança da Informação emitiu mais

de 100 condicionantes técnicas referentes ao ambiente dos servidores, não houve uma resposta

rápida sobre quem deveria se responsabilizar por elas. Enquanto isso, o ambiente cloud era

desenvolvido sem considerar os riscos.

Em busca de solucionar o problema, os POs se reuniram, agruparam as condicionantes

estruturantes em blocos e as distribuíram entre as squads, tentando gerar uma divisão justa em

termos de alocação de esforços. No entanto, esse sistema ad hoc levou a discrepâncias muito

grandes em relação ao número de condicionantes de cada PO. Alguns aspectos importantes,

como o número de itens em backlog e o número de condicionantes já sob responsabilidade de

cada POs, não foram levados em consideração.

Sabia-se que havia desequilíbrio, mas não exatamente em que proporção e onde. Por

iniciativa do analista de integração, foi feito um estudo sobre o número de condicionantes

estruturantes que tinha sido distribuído para cada um dos POs. Partindo da premissa de que o

esforço relacionado a cada condicionante não varia muito, fez-se uma análise do balanceamento

de esforços entre os POs (Tabela ), com uma proposta de rebalanceamento.

Tabela 5 - Balanceamento de Condicionantes Estruturantes


Bloco de conds. Total Conquistar Comprar Assistir Pagar Dados Conquistar Comprar Assistir Pagar Dados

B0 8 8 8

B1 2 2 2

B2 4 3 1 4

B3 21 1 7 13 21

B4 22 21 1 21 1

B5 3 3 3

Total 60 4 15 37 3 1 6 29 21 3 1

Total (%) 100% 7% 25% 62% 5% 2% 10% 48% 35% 5% 2%

Total Conquistar Comprar Assistir Pagar Dados Conquistar Comprar Assistir Pagar Dados

Total 26 2 1 2 19 2 2 1 2 19 2

Total 100% 8% 4% 8% 73% 8% 8% 4% 8% 73% 8%

Total Conquistar Comprar Assistir Pagar Dados Conquistar Comprar Assistir Pagar Dados

Total 86 6 16 39 22 3 8 30 23 22 3

Total 100% 7% 19% 45% 26% 3% 9% 35% 27% 26% 3%

Proposta

AR 1 - Estruturantes

Estruturantes - Totais

Hoje

Hoje

AR 2 - Estruturantes Hoje Proposta

Proposta


Pode-se constatar que de fato havia um desbalanceamento: um PO recebeu 62% das

condicionantes estruturantes da AR 2 e ficou com 45% do total. Esse estudo foi importante para

confirmar o problema e trazê-lo novamente para discussão.

Em reunião com o gestor, foi levantada a possibilidade de que a própria Diretoria de

Segurança Corporativa, a qual é responsável pela maioria das condicionantes estruturantes e

está envolvida no projeto, ficasse responsável por implementá-las. A área possui uma squad

própria e é responsável por cerca de 180 condicionantes, considerando as três ARs às quais o

projeto está sujeito.

Segundo essa proposta, ao emitir condicionantes, a área estaria gerando trabalho para

ela mesma. Antes, os POs precisavam buscar os analistas de segurança para compreender as

condicionantes. Com a proposta em vigor, os analistas encarregados da implementação já têm

o conhecimento técnico, o que os permite agir de forma rápida e precisa. Dessa forma, cerca

de 150 condicionantes foram retiradas dos backlogs dos POs enquanto reduziu-se o risco de

não compliance.

4.8.3 Atuação nos GAs

O projeto em estudo já foi submetido a três ARs. Não há registro em nenhuma delas,

cada uma com cerca de 20 áreas, da atuação de um GA para a melhoria de um parecer ou revisão

de planos de ação.

Em um caso, as condicionantes e planos de ação foram discutidos um a um com um

analista que, ao fim da reunião, disse que precisaríamos ter a mesma discussão com os GAs, os

verdadeiros tomadores de decisão. Uma vez que são colaboradores mais seniors, é necessário

mais tempo para conseguir uma agenda de reunião com os mesmos. Três semanas após a

definição com a analista, conseguiu-se discutir com os GAs. Não houve alteração nos planos.

Em outro caso, era necessário corrigir uma condicionante. Foi necessário quase um

mês para que o parecer chegasse à executora responsável pela correção. Quando a governança

retorna um parecer para a área avaliadora, caso haja GA de aprovação, o parecer deve passar

por ele antes de ser encaminhado para o executor. Ao ser acionado pelo portal, o GA

sumariamente aprovava o parecer e o retornava para governança, impedindo que o documento

chegasse ao analista.

Em áreas com GA, a discussão direta com o GA acelera a resolução de problemas.

Contudo, em áreas sem GA, esses problemas podem ser resolvidos diretamente com os

analistas. No segundo caso, não há necessidade de escalar a discussão, dado que o próprio


analista já possui alçada de decisão. Portanto, a necessidade de GAs é discutível. Seu papel

poderia ser desempenhado pelos analistas da área de forma mais ágil e sem aumento do risco

de não compliance.

Entretanto, essa seria uma alteração demorada que sairia da alçada de discussão do

analista de integração. Então, para efeitos práticos, em áreas com GA, fez se uso da hierarquia

para acelerar a resposta dos analistas pareceristas. Os GAs eram copiados frequentemente nos

e-mails com cobranças e em caso de discussões pouco produtivas sobre os planos de ação, eram

prontamente marcadas discussões diretamente com os GAs.

4.8.4 Acompanhamento Interno do Tempo de Desenvolvimento de Planos de Ação

Não há SLA para o desenvolvimento de planos de ação por parte da equipe de produto.

Assume-se que é do interesse da equipe desenvolvê-los o mais rápido possível. Em geral, um

analista é responsável por toda a AR de um produto. A mesma pessoa que recebe e discute os

pareceres desenvolve os planos de ação, pois possui conhecimento sobre todo o projeto.

Todavia, no projeto em estudo, o tamanho do escopo e as divisões funcionais das

squads levaram à alienação dos POs. Cada um possui conhecimento aprofundado sobre a sua

squad, mas um conhecimento superficial sobre o resto do projeto.

Nesse contexto, é preciso triar os pareceres para que eles sejam encaminhados para os

PO com os conhecimentos adequados. E quando nem mesmo o PO compreende, é necessário

contatar analistas de áreas de suporte do projeto ou com a área que emitiu o parecer, para que

as questões relevantes possam ser compreendidas e resolvidas dentro das expectativas das áreas

envolvidas. Além do tempo despendido nas etapas adicionais, ao receber os pareceres, os

analistas não os respondem imediatamente.

Para solucionar esses problemas, o processo de desenvolvimento de planos de ação foi

estruturado de forma a evitar o encaminhamento de pareceres para os POs. Nos casos em que

há encaminhamento, foi acordado em equipe um SLA de dois dias.

Ao longo das ARs, o analista de integração aprendeu um pouco sobre cada squad do

projeto e as demandas das principais áreas avaliadoras. Adquiriu um repertório de planos de

ação e evidências. Logo, ele consegue responder sozinho os pareceres de cerca de 60% das

áreas. Dos outros 40%, metade é composta por áreas com condicionantes específicas de risco

moderado, que mudam consideravelmente a cada AR. Nesses casos, o analista de integração

encaminha os planos para o PO responsável. A outra metade é composta por pareceres de


complexidade moderada a alta que envolvem riscos ainda sem definições para prevenção e

mitigação.

Nesses casos, há duas situações:

1. Registra-se no documento que os planos serão desenvolvidos em conjunto com as áreas

e, como evidência, serão enviados os planos desenvolvidos em conjunto com a

aprovação da área avaliadora.

2. Os planos são desenvolvidos na squad ou em reuniões de pré-projeto com os

colaboradores das áreas do banco afetadas. Em seguida são registrados nos pareceres e

enviados para avaliação.

No primeiro caso, a resposta é rápida, dentro do SLA de 2 dias. No segundo, a resposta

demorada, depende das datas de cerimônias de conceituação da squad, feitas quinzenalmente,

ou de datas de pré-projeto, as quais costumam demorar algumas semanas para acontecerem.

Nota-se que em geral o caso 2 ocorre após um plano do tipo do caso 1 é reprovado. Isso ocasiona

uma demora adicional referente ao tempo de validação dos planos de ação.

A maior parte do fluxo de AR é gasta no loop “desenvolvimento de planos” -

“avaliação dos planos” - “devolutiva”. Com o mapeamento e compreensão do processo de

desenvolvimento de planos, sempre se está avançando. Antes, os pareceres eram repassados

dentro da equipe sem registro de prazos e muitas vezes não se sabia como proceder em caso de

dúvidas. Hoje as os analistas de produto são capazes de reconhecer rapidamente a alçada de

discussão de cada condicionante e as áreas avaliadoras são prontamente acionadas em caso de

necessidade.

4.8.5 Devolutivas acionáveis

Há campos para a devolutiva geral no portal AR e devolutivas individuais para cada

condicionante no formulário. Quando as razões por trás da reprovação dos planos de ação são

claras, a área de produto entende os riscos envolvidos e as preocupações dos avaliadores. Dessa

forma, o desenvolvimento de novos planos de ação é rápido e preciso. Mesmo quando ainda é

necessário marcar uma reunião entre as áreas, boas devolutivas aumentam as chances de

consenso rápido.

Quando o parecer retorna para a área demandante sem demais explicações, torna-se

responsabilidade da área de produto identificar os pareceristas responsáveis por cada

condicionante negada e interrogá-los sobre a reprovação. Sem o registro oficial do motivo de


reprovação, a área de produto fica à mercê do pareceristas e exposta a condicionantes não

conformes.

O desenvolvimento de devolutivas claras e acionáveis é uma boa prática pouco

disseminada. O número de áreas avaliadoras e a alçada dos analistas responsáveis pela AR são

barreiras para essa disseminação. Embora a área demandante não tenha controle sobre a

qualidade das devolutivas das áreas avaliadoras, ela tem sobre sua forma de atuação frente a

devolutivas superficiais. Foi desenvolvido um fluxo interno para a revisão de planos de ação.

Quando algum parecer retorna, imediatamente são analisadas a especificidade e

clareza da devolutiva. Caso esteja claro o que deve ser modificado, os planos são adaptados e

o parecer é enviado novamente para as áreas. Caso haja alguma dúvida sobre o problema a ser

resolvido ou as razões da negativa, os responsáveis são identificados e contatados.

Em conversas em pessoa ou por telefone são identificadas as questões envolvidas nas

negativas. A comunicação por e-mail é evitada, pois permite respostas demoradas e vagas.

Antes da discussão sobre as possíveis soluções, verifica-se se o analista em questão possui

alçada para aprovar os planos. Caso não tenha, busca-se uma pessoa que a tenha e as discussões

são levadas a ela, de forma a evitar reuniões e discussões desnecessárias. Essa abordagem

também permite que os riscos mais relevantes fiquem claros para ambas as partes e sejam

diretamente tratados pelos planos de ação.

4.8.6 Transformação de condicionantes em itens de backlog

O backlog do projeto é o guia para o status de desenvolvimento do projeto e o trabalho

a ser realizado em cada squad. A estrutura do backlog da equipe foi adaptada para entregas

discretas de valor no projeto. Ela á composta por blocos referentes à identificação do item de

backlog (Tabela ), critérios de priorização (Tabela ) e acompanhamento de status (Tabela ). As

etapas de desenvolvimento de features e os critérios de aceite de cada uma delas foram

traduzidos em quadros de Kanban para permitir o controle e acompanhamento dos POs e o

coordenador da equipe.

Tabela 6 - Identificação de Item de Backlog (Antigo)


Assistir Onboarding Avaliação de credito Refazimento da avaliação de crédito (60 dias)

Esteira Jornada Épico Feature


Tabela 7 - Critérios de Priorização de Backlog (Antigo)


Tabela 8 - Status de Item de Backlog (Antigo)


Para decidir o que será priorizado em cada sprint, os POs avaliam dentre os itens do

backlog que subirão na próxima versão do produto, quais possuem a maior nota no critério de

priorização. O status dos itens é atualizado conforme eles evoluem nas etapas de

desenvolvimento e uma vez que são concluídos, são arquivados. Reparo de bugs e melhorias

entram como itens novos.

A fim de centralizar o controle de demandas, decidiu-se que as condicionantes também

deveriam estar no backlog. Então, foi necessário adaptar o backlog para que ele pudesse conter

tanto features quanto condicionantes.

Enquanto um item de feature é descrito por “Jornada”, “Épico” e “Feature”, os de AR

são por “AR”, “Área Avaliadora” e “Condicionante” (Tabela ). Duas colunas foram

adicionadas, “Evidências” e “Plano de Ação”, apenas aplicáveis a itens de AR (Tabela ). Essas

duas colunas em geral ficam ocultas, mas garantem que todas as informações relevantes sobre

a condicionante fiquem em um mesmo documento.

Tabela 9 - Identificação de Item de Backlog (Novo)


Curto Prazo 300

Release RUT

Discovery Fluxos UX UI Back Front

3 3 3 3 2 0 78%

StatusConceituação Design Desenvolvimento

Assistir Onboarding Avaliação de creditoRefazimento da avaliação de crédito (60

dias)

Assistir AGR - 1 Área XEnvolver a área X. Entrar em contato com

a coordenação de "Fulana"

Esteira Jornada Épico Feature


Tabela 10 - Identificação Extra para Condicionantes (Novo)


Para o acompanhamento da implementação dos planos, mantiveram-se as mesmas

colunas de status, mesmo que as etapas de implementação sejam diferentes. Enquanto as

fetaures são monitoradas pela taxa de conclusão, as condicionantes são avaliadas por “To do”,

“Doing” e “Done” (Tabela ). A taxa de conclusão de uma feature é calculada de forma

proporcional à conclusão de cada etapa de desenvolvimento.

Tabela 11 - Status de Item de Backlog (Novo)


Em um primeiro momento, foi pedido que cada PO fizesse a atualização dos status das

condicionantes levando em consideração as etapas de desenvolvimento de features. Caso uma

das etapas não se aplicasse, ela seria dada como concluída. Todavia, percebeu-se que eles só se

aplicavam em uma minoria dos casos. Acompanhar a conclusão dos planos de implementação

por uma porcentagem não refletia a realidade e não trazia informações relevantes para o

direcionamento do projeto.

Se por um lado, não se tinha um sistema de acompanhamento adequado para a

conclusão das condicionantes, a inserção das condicionantes no backlog afetou o cálculo dos

indicadores dos outros dos itens do projeto, os quais ainda estavam em estado incipiente. Uma

vez que seria necessário rever o cálculo dos indicadores, coube ao analista responsável pela

ARs o gerenciamento e melhoria do backlog como um todo. Isso significa garantir a atualização

do backlog pelos POs e desenvolver novos indicadores, dashboards e sistema de priorização.

Email com o envolvimento

oficial da coordenação de

"Fulana".

OK, entraremos em

contato com "Fulana"

Evidência Plano de ação

Discovery Fluxos UX UI Back Front

3 3 3 3 2 0 78%

3 2 1 1 1 0 Doing

StatusConceituação Design Desenvolvimento


4.8.6.1 Atualização do backlog pelos POs

Havia três locais para o acompanhamento de tarefas:

1. Jira: Software em cloud para o gerenciamento de kanbans. Os desenvolvedores do

projeto usam com afinco, porém sua adoção varia entre os POs, apenas metade atualiza

constantemente. Os que não usam atestam que os boards não os ajudam a se

organizarem, finda por ser uma documentação desnecessária. Os que usam, reclamam

que os boards não acompanharam as mudanças nos critérios de aceite e na organização

das squads.

2. Kanban na parede: Board físico montado pelo Scrum Master da equipe na parede da

sala do projeto. Foi uma resposta à baixa adesão ao Jira. Incentivou o mapeamento de

todas as features em desenvolvimento e permite uma avaliação geral de onde estão os

gargalos. Contudo, a equipe se desloca entre diferentes polos da empresa, nem sempre

tendo acesso ao kanban. Além disso, os quadros do kanban, de difícil modificação

devido ao tamanho do mural e da quantidade de post its, são pouco adequadas ao

monitoramento de AR, tendo sido até considerada a criação de um mural adicional para

tanto.

3. Planilha de backlog: Planilha em Excel baseada no kanban na parede. Em um primeiro

momento era uma iniciativa para permitir a portabilidade do kanban e o levantamento

de indicadores. Devido à maior facilidade de alteração dos quadros, gradativamente

substituiu o kanban da parede como ferramenta de acompanhamento. Contudo, a

frequência de atualização dos status era baixa e os itens variavam muito em

complexidade, ainda não permitindo uma avaliação de conclusão satisfatória.

Nesse contexto, percebeu-se que era inviável continuar dependendo do kanban da

parede. Embora útil em um primeiro momento, não era portátil nem permitia o controle da

evolução do projeto no nível desejado pelo coordenador da equipe.

Para a organização do trabalho dos desenvolvedores e demais analistas do projeto, o

acompanhamento de itens que já tinham sido priorizados na sprint, o Jira se apresentava como

uma boa ferramenta, porém subaproveitada. Porém, para a gestão do backlog geral do projeto,

deixava a desejar.

Para a gestão de backlog, a planilha de Excel permitia a organização dos itens a serem

priorizados junto com acompanhamento de status e critérios de priorização. Entretanto, o


versionamento mostrou-se um desafio. Além dos POs nem sempre atualizarem seus backlogs,

quando o faziam, não enviavam para a integração com a planilha central. Além disso, os

critérios de aceite e o fluxo de desenvolvimento ainda estavam em discussão e mudavam

frequentemente, dificultando a integração de versões antigas de backlog.

Para garantir a atualização do backlog, antes se teve que definir qual sistema de

acompanhamento seria de fato utilizado. Em discussão com a equipe, foi decido que o Jira seria

utilizado para o controle operacional, enquanto a planilha de Excel seria utilizada para a gestão

e priorização das demandas. Toda quarta feira seria feita uma reunião de uma hora com os POs

e o coordenador do para discutir o andamento do projeto e o que deveria ser priorizado.

Entre cada uma dessas reuniões, o analista responsável pelo backlog marcaria um

horário com cada PO para a atualização do backlog e o levantamento de indicadores como

preparação para a reunião de quarta-feira. Conforme a equipe ganhava maturidade com a gestão

do backlog, as reuniões intermediárias foram se tornando desnecessárias.

4.8.6.2 Novos indicadores e dashboards

Para o lançamento da primeira versão do produto, havia uma data meta e uma série de

itens estruturantes a serem desenvolvidos. Havia um controle geral, mas não era possível

afirmar com certeza o nível de conclusão do projeto.

Nos backlogs das squads havia itens de complexidade e escopo muito diferentes. Além

disso, a planilha de backlog continha itens que não entrariam na primeira versão do produto.

Um indicador geral de conclusão não era o suficiente.

Nesse cenário, o coordenador do projeto levantou algumas perguntas:

O quanto do projeto já está concluído?

Alguma squad está com mais dificuldades?

Algum recurso está sub ou sobre alocado?

Para responder a essas perguntas, fez-se uma análise dos itens no backlog e do fluxo

de desenvolvimento das demandas de cada squad. Era preciso identificar quais itens iriam para

a primeira versão. Não faria sentido ter um indicador geral de conclusão, era preciso avaliar as

ARs e itens de cada squad separadamente. E, das demandas das squads, algumas deveriam ser

avaliadas conforme os critérios de aceite e outras em termos de kanban: to do,doing e done.


Foram usados indicadores diferentes para cada uma das três frentes do projeto. Nas

squads da plataforma, a conclusão foi calculada a partir dos critérios de aceite no fluxo de

desenvolvimento (Tabela ).

Tabela 12 - Dashboard das Squads


Nas squads de negócio (Tabela ) e nas ARs (Tabela ), uma vez que as demandas não

passam por fluxos de desenvolvimento, a conclusão foi calculada a partir de um quadro de

kanban.

Tabela 13 - Kanban de Negócios


Tabela 14 - Kanban de AR


Esses quadros, ao dividirem as frentes e squads, oferecem informações para identificar

os pontos que necessitam de mais atenção. Entretanto, cada squad possui designers e

desenvolvedores próprios. Para identificar o potencial de realocação de recursos, foi

desenvolvido um kanban detalhado por squad e etapa de desenvolvimento (Tabela ).

Release: 1ª

Esteira Conceituação Design Desenvolvimento

Total 65% 59% 22%

Conquistar 62% 60% 18%

Comprar 68% 58% 47%

Pagar 74% 72% 30%

Assistir 52% 17% 4%

Status do Backlog

Esteira de Negócios To Do Doing Done Finalizado

Negócio 1 3 1 6 60%

Negócio 2 6 6 8 40%

Kanban Negócios

Esteira de Negócios To Do Doing Done Finalizado

AR 1 18 5 230 91%

AR 2 87 3 111 55%

AR 3 160 6 8 5%

Kanban AR - Planos de Ação


Tabela 15 - Kanban da Plataforma


A partir desses materiais, a equipe percebeu que não estava priorizando as ARs e que

havia um desequilíbrio no uso de designers entre as squads. Os POs voltaram a executar os

planos de ação e um designer foi realocado de squad. Além disso, com a visibilidade do nível

de conclusão do projeto, o prazo de lançamento foi revisto.

4.8.6.3 Sistema de Priorização

O sistema de priorização de demandas do projeto foi desenvolvido tendo em mente a

estruturação inicial da plataforma. A nota de priorização era dada por:

Nota final = RUT + Estruturante + Risco (1)

Conforme mencionado na seção 4.7, o RUT (Tabela ) é uma nota de priorização para

o desenvolvimento de produtos. Foi sugestão de uma empresa de desenvolvimento de software

parceira. É um critério desenvolvido para equipes ágeis de desenvolvimento de produto.

Permite avaliar quantitativamente o valor de uma feature.

Tabela 16 - Critérios de RUT

Fonte: Retirado de (CHIARA, 2016)

To do Doing Done To do Doing Done To do Doing Done

Total 51 46 122 76 32 108 175 26 2

Consquistar 10 30 0 0 8 49 62 9 2

Comprar 5 0 4 6 2 1 7 1 0

Pagar 21 5 15 23 5 30 38 11 0

Assistir 15 11 26 27 17 2 42 5 0

Kanban plataforma

Conceituação Design DesenvolvimentoEsteira


O RUT é obtido pela multiplicação de três fatores em uma escala de um a cinco. No

entanto, seu diferencial é a forma como os valores são atribuídos aos fatores. Essa é uma

ferramenta para ser utilizada em grupo. Os membros da equipe devem votar as notas do RUT

com a mão, uma categoria por vez e simultaneamente. Dessa forma, não há ancoragem nas

opiniões e discrepâncias quanto à percepção de um fator podem ser discutidas sem julgamentos.

A nota de se refere a riscos de segurança e de não compliance Risco (Tabela ). É

atribuída por analistas da Diretoria de Segurança Corporativa que participam do projeto.

Tabela 17 - Critério de Risco


A nota de Estruturante considera a necessidade da feature para a primeira versão

comercial do produto (Tabela ). Inclui itens de backend, features e produtos financeiros. A

necessidade vem de determinações do banco central, demandas técnicas e a estratégia da

organização. Pode assumir apenas dois valores

Tabela 18 - Critério de Estruturante


Esse sistema funcionou muito bem para o desenvolvimento da primeira versão da

plataforma. No entanto, quando o número de stakeholders e a variedade de demandas

aumentaram, as notas já não representavam bem a prioridade das demandas. A solução

encontrada foi adicionar um novo critério na nota, o RUT de negócios (RUTn). O RUTn seria

votado pelas equipes de negócio enquanto o original, o RUT da plataforma (RUTp) continuaria

sendo votado pelos membros das squads. Os critérios de nota foram adaptados para os

interesses dos parceiros e dos seus clientes. A nota final era composta por:

Nota Critério

0 Risco Insignificante

5 Risco Pequeno

25 Risco Moderado

125 Risco elevado ou condicionante de AR

Critérios de Riscos

Nota Critério

0 Não essencial

250 Essencial estar na próxima versão

Critérios de Riscos


Tabela 19 - Novos Critérios de Priorização


Esses critérios foram úteis para a estruturação de uma primeira versão da plataforma e

do aplicativo. Contudo, possui alguns problemas. A AR tem um peso muito alto na nota final e

a versão de lançamento da feature é considerada três vezes: uma no estruturante e mais uma

vez em cada RUT. Além disso, o valor para os stakeholders é decidido dentro da própria equipe,

sem um processo de sondagem ou avaliação direta com os clientes.

Ter um critério quantitativo único para a priorização de backlog é tentador. Dessa

forma, antes de cada sprint bastaria selecionar os itens com a maior nota. Contudo, a nota

funcione apenas como guia, frequentemente itens com notas baixas são priorizados em

detrimento de outros com notas mais altas.

Esse sistema de priorização estimula decisões estratégicas sobre o produto, mas as

resume uma nota. Sem oferecer agilidade e eficácia na priorização, o sistema engessou as

discussões sobre a estratégia da plataforma.

No momento atual do projeto, há muitos itens estruturantes a serem desenvolvidos até

uma data de lançamento preestabelecida. Mesmo que haja uma ordem prioritária, tudo o que

for estruturante deve ser feito até o prazo. O primeiro passa para recuperar a agilidade na

priorização de demandas foi o retorno à mentalidade de MVP, dentro do permitido pela

estratégia do banco. Quais são as features mínimas para o lançamento de um produto robusto?

Para responder a essa pergunta, tudo o que iria para a primeira versão foi reavaliado.

Isso incluiu desde features até planos de ação de condicionante. Itens com notas altas foram

enviados para o fim da fila.

Até o lançamento da versão inicial do produto, essa seria a única organização

necessária em termos de priorização. Atrasos nas sprints significariam o atraso do lançamento.

Contudo, a fim de preparar o backlog para os próximos releases, todos os itens foram

classificados em primeiro release, curto prazo e longo prazo.

-------------------------------------

A partir daqui, trata-se de um plano não implementado. Apenas sugestões.

RUTp RUTn Estruturante Risco Nota Final

Valores [0;125] [0;125] {0;250} {0;5;25;125} n/a

Máximo 125 125 250 125 625

Participação 20% 20% 40% 20% 100%

Critérios de Priorização


Os próximos passos consistiriam em uma reforma do sistema de priorização pautada na

dissociação das notas. Deve-se compreender que os interesses dos diversos stakeholders devem

ser gerenciados ao longo das sprints. Devem subir itens que entreguem valor para diferentes

stakeholders. Em vez de uma nota única, transformar cada RUTn e RUTp em uma nota para

um stakeholder:

RUTp: Para o usuário final, a feature é nice, good,must

RUTn: Para o parceiro, a feature é nice, good,must

Risco: Para o banco, a feature é nice, good,must

Estruturante: Release conforme os prazos do banco

Esse novo sistema poderia ser implementado no backlog em Excel, contudo, há um

software que permite essa gestão em Cloud com integração direta com o Jira. O analista

responsável entrou em contato com a empresa, a qual deu sugestões de como melhorar a gestão

de backlog do projeto e conseguiu um trial de 6 semanas. Em 6 semanas, seria possível testar

durante três sprints

Primeiro o teste seria feito em apenas uma squad, uma que já use o Jira assiduamente.

Na segunda, uma que não use assiduamente. E na terceira, uma tentativa de implementação

geral.

5. CONCLUSÕES | 99

5. CONCLUSÕES

O manifesto ágil é fundamentalmente contrário à AR como ela é realizada hoje. Têm-

se processos engessando a atuação de indivíduos, vasta documentação na forma de evidências,

contratos entre áreas da própria organização e planos detalhados para a resolução de problemas

pouco significativos. Integrar a gestão de riscos no fluxo de trabalho das squads atende aos

interesses da organização, mas efetivamente não elimina a causa raiz do problema.

O fluxo de gestão de riscos, embora necessário, está demasiadamente oneroso. Tem o

potencial de, enquanto previne riscos, também estimular a troca construtiva de conhecimentos

e boas práticas entre as áreas. Todavia, ainda seria necessário evoluir em demasia para alcançar

esse patamar.

De qualquer forma, este trabalho demonstra que é possível trabalhar de um jeito

distinto no grande banco de varejo brasileiro. Para estabelecer a mudança, contudo, são

necessárias estratégias de disseminação do ágil e a flexibilização da Avaliação de Riscos.

Quanto à organização da equipe, ainda há um gap entre o que entrega valor para os

clientes e o que é de fato priorizado. A proximidade com o cliente só será atingida com o

desenho e implementação de processos e estratégias deliberados para o uso de dados de

atendimento e opiniões dos clientes na construção e revisão de features.

Sugestões como essa são cabíveis, pois a forma de trabalho do projeto continuará

evoluindo. Além da mentalidade da equipe e da liderança, o projeto está em uma fase de

transição importante. A partir do lançamento da primeira versão da plataforma, será possível

ter um backlog mais flexível e adaptável. Esse momento também marca a entrada de novos

parceiros. Isso implica em mais interesses a serem considerados, e maior equipe para as squads.

Em suma, o projeto tem sido um sucesso. A diretoria já anunciou que irá substituir a

plataforma de cartões do banco e que aceita o modelo de trabalho proposto pela equipe. Agora

é preciso permanecer em evolução contínua, disseminar as boas práticas de gestão por toda a

organização e incentivar iniciativas de digitalização de outros produtos e serviços do banco.

100 | 6. REFERÊNCIAS BIBLIOGRÁFICAS

6. REFERÊNCIAS BIBLIOGRÁFICAS

ABRAHAMSSON, P. et al. Agile Software development methods: Review and analisys.

VVT publications 478, Espoo/FL, 2002. Disponível em: <https://www.vtt.fi/inf/pdf/publications/2002/P478.pdf>. Acesso em: 12 out. 2018.

AGILE 101. Agile Alliance. Disponível em: <https://www.agilealliance.org/agile101/>.

Acesso em: 20 ago. 2018.

AGILE ALLIANCE. Agile Glossary. Disponível em:

<https://www.agilealliance.org/agile101/agile-glossary/>. Acesso em: 12 ago.2018.

AGILE ALLIANCE. Manifesto para Desenvolvimento Ágil de Software. 2001. Disponível

em: < http://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em: 08.set. 2018.

ANDERSEN, Bjørn; FAGERHAUG, Tom; BELTZ Marti. Root Cause Analysis and

Improvement in the Healthcare Sector: A Step-by-Step Guide .Milwaukee/WI: ASQ Quality Press, 2010

ASSI, Marcos. Governança, Risco e Controles Internos. 2010. Disponível

em:<http://www.administradores.com.br/artigos/negocios/governanca-risco-e controles internos/49386/>. Acesso em: 12 out. 2018.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TECNICAS. ABNT NBR ISO 31000:2009.

Gestão de riscos — Princípios e diretrizes. 2009

ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS BRASIL -

ABPMP. Guia para o Gerenciamento de Processos de negócio. BPM CBOK. 2013.

Disponível em: <https://c.ymcdn.com/sites/www.abpmp.org/resource/resmgr/Docs/ABPMP_CBOK_Guide__

Portuguese.pdf>. Acesso em: 02 de agosto de 2018.

BACKLOG. Disponível em: <https://www.agilealliance.org/glossary/backlog/>. Acesso em:

10 ago.2018

BIDNIUK, Vladimir Barcellos. Governança, Gestão de Riscos e Compliance (GRC) são

fatores primordiais para o sucesso das empresas. 2017. Disponível em:

<http://www.administradores.com.br/noticias/negocios/governanca-gestao-de-riscos-e-compliance-sao-fatores-primordiais-para-o-sucesso-das-empresas>. Acesso em: 16 set 2018.

BROADY, Denise; ROLAND, Holly. SAP® GRC for Dummies. Indiana: Wiley Publishing, 2008.

BROEDERS, Henk; KHANNA, Somesh. Strategic choices for banks in the digital age. 2015. Disponível em: <https://www.mckinsey.com/industries/financial-services/our-

insights/strategic-choices-for-banks-in-the-digital-age#0>. Acesso em: 20 out. 2018.

CANDELORO, Ana Paula P.; RIZZO, Maria B. M. de; PINHO, Vinícius. Compliance 360°: riscos, estratégias, conflitos e vaidades no mundo corporativo. São Paulo: Trevisan Editora

Universitária, 2012.

https://www.agilealliance.org/glossary/backlog/

6. REFERÊNCIAS BIBLIOGRÁFICAS | 101

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. Prod., São Carlos,

v.19, n. 3, p. 557-573, 2012.

CHIARA, Andressa. Como priorizar sem traumas. 2016. Disponível em:

<https://www.concrete.com.br/2016/11/15/como-priorizar-sem-traumas/>. Acesso em: 05

jun.2018

CHRISTIE-BLICK, Winston. Define initiatives to group features that support the same

objective. Disponível em: <https://help.productboard.com/how-to-articles/define-initiatives-

to-group-features-that-support-the-same-objective>. Acesso em: 25 0ut.2018.

COOPER, R.G.; EDGETT, S.J. Developing a Product Innovation and Technology Strategy for

Your Business. Research-Technology Management, v.53, n.3, p.33-40, maio/jun. 2010.

Disponível em: < http://www.stage-gate.net/downloads/working_papers/wp_39.pdf>. Acesso em: 13 ago.2018.

CORPORAÇÃO FINANCEIRA INTERNACIONAL – IFC. Guia Prático de Governança

Corporativa Experiências do Círculo de Companhias da América Latina. Washington: IFC, 2009. Disponível em:

<https://www.ifc.org/wps/wcm/connect/577e088048a7e3d19a47df6060ad5911/Guide_Portug

uese.pdf?MOD=AJPERES&CACHEID=577e088048a7e3d19a47df6060ad5911. Acesso em:

19 set.2018.

DAILY MEETING. Disponível em: <https://www.agilealliance.org/glossary/daily-meeting/>.

Acesso em: 10 ago.2018

DALE, B.G; VAN DER WIELE, T; VAN IWAARDEN, J. Managing Quality. 5th ed.

Victoria/AU: Blackwell Publishing, 2007

DE SORDI, J.O. Gestão por Processos. Uma Abordagem da Moderna Administração. 4.ed. São Paulo: Saraiva, 2014

E

RNST & YOUNG. Unlocking the power of SAP’s governance, risk and compliance

technology. In: Insights on governance, risk and compliance. March,2013. Disponível em: <https://www.eyjapan.jp/services/advisory/global-contents/pdf/2013-10-16-06-en.pdf > .

Acesso em: 10 out. 2018.

FOGAÇA, Guilherme. O ano zero da competição entre cartões de crédito. Revista Exame. 04.mar.2011. Disponível em: < https://exame.abril.com.br/revista-exame/ano-zero-

competicao-559717/ > Acesso em: 05 jun.2018.

FREEMAN, R. Edward. STRATEGIC MANAGEMENT: A STAKEHOLDER APPROACH. Cambridge University Press, 2010. Disponível em: <

https://books.google.com.br/books?id=NpmA_qEiOpkC&pg=PA1&hl=pt-

PT&source=gbs_toc_r&cad=4#v=onepage&q&f=false >. Acesso em: 12 set. 2018

GILAD, Itamar. Why Prioritization by Impact/Effort Doesn’t Work. 2017. Disponível em:

<https://www.linkedin.com/pulse/why-prioritization-impacteffort-doesnt-work-itamar-

gilad/>. Acesso em: 8 ago.2018.

https://www.google.com.br/search?hl=pt-PT&tbo=p&tbm=bks&q=inauthor:%22R.+Edward+Freeman%22

https://www.google.com.br/search?hl=pt-PT&tbo=p&tbm=bks&q=inauthor:%22R.+Edward+Freeman%22


GIMENES, Rafael Oricchio. Análise e melhoria de processos em uma empresa

desenvolvedora de sistemas. Universidade de São Paulo. Escola Politécnica. Trabalho de Fomatura. São Paulo: 2012

HEARTBEAT RETROSPECTIVE. Disponível em:

<https://www.agilealliance.org/glossary/heartbeatretro/> Acesso em: 10 ago.2018

HERN, Alex. The two-pizza rule and the secret of Amazon's success . The Guardian, 24

abr.2018. Disponível em: <https://www.theguardian.com/technology/2018/apr/24/the-two-

pizza-rule-and-the-secret-of-amazons-success>. Acesso em:20ago.2018.

HIGHSMITH, J.; COCKBURN, A.. Agile Software Development: The Business of Innovation.

Computer, v. 34, n.9, p.120–127, set. 2001. doi:10.1109/2.947100

INSTITUTO BRASILEIRO DE GOVERNANÇA CORPORATIVA. Código das melhores

práticas de governança corporativa. 5.ed. São Paulo: IBGC, 2015. Disponivel em: <

http://conhecimento.ibgc.org.br/Lists/Publicacoes/Attachments/21138/Publicacao-

IBGCCodigo-CodigodasMelhoresPraticasdeGC-5aEdicao.pdf>. Acesso em: 10 ago. 2018.

ISO 19600:2014(en). Compliance management systems — Guidelines. Disponível em:

<https://www.iso.org/obp/ui/#iso:std:iso:19600:ed-1:v1:en>. Acesso em: 13 set. 2018

KANBAN BOARD. Disponível em: <https://www.agilealliance.org/glossary/kanban>. Acesso

em: 10 ago. 2018.

KOHAVI, Ronny et al. Online Experimentation at Microsoft. 2009. Disponível em: <http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf>. Acesso em:10 ago.2018.

KUME, Hitoshi. Métodos estatísticos para melhoria da qualidade. [Belo Horizonte]:

Instituto AOTS do Brasil/ Editora Gente1993.

LEFFINGWELL, Dean. Agile Software Requirements: Lean Requirements Practices for

Teams, Programs, and the Enterprise. Boston: Addison-Wesley, 2011.

LEYBOURN, Evan. Directing The Agile Organization: A Lean Approach To Business

Management. Cambridge: IT Governance Publishing, 2013.

OBJECT MANAGEMENT GROUP - OGM. Business Process Model and Notation

(BPMN), vf.2.0. 2010. Disponível em:

<http://www.oatsolutions.com.br/artigos/SpecBPMN_v2.pdf>. Acesso em: 05 ago.2018.

OLIVEIRA, Juliana Fochi. Governança, Risco e Compliance: A Conjugação de Ferramentas Aplicáveis nas Organizações. Disponível em: <http://www.marcosassi.com.br/governanca-

risco-e-compliance-a-conjugacao-de-ferramentas-aplicaveis-nas-organizacoes-por-juliana-

fochi-de-oliveira >. Acesso em: 29 ago. 2018.

PAHUJA, S. What is Scrumban? Disponível em: <https://www.agilealliance.org/what-is-

scrumban/>. Acesso em: 10 Ago. 2018.

https://www.agilealliance.org/glossary/heartbeatretro/

http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf

https://www.agilealliance.org/author/125

6. REFERÊNCIAS BIBLIOGRÁFICAS | 103

PAIM, R. et al. Gestão de Processos: pensar, agir e aprender. Porto Alegre: Bookman, 2009.

PRODUCT OWNER. Disponível em: <https://www.agilealliance.org/glossary/product-owner/>. Acesso em: 10 ago.2018

RADIGAN, D. The product backlog: your ultimate to-do list. Disponível em:

<https://www.atlassian.com/agile/scrum/backlogs>. Acesso em: 07 ago. 2018

REHKOPF, Max. Agile Epics: Definition, Examples, & Templates. Disponível em:

<https://www.atlassian.com/agile/project-management/epics>. Acesso em: 13 ago. 2018

REHKOPF, Max. Epics, Stories, Themes, and Initiatives. Disponível em:

<https://www.atlassian.com/agile/project-management/epics-stories-themes>. Acesso em:

Acesso em: 13 ago.2018.

REHKOPF, Max. User Stories. Disponível em: <https://www.atlassian.com/agile/project-

management/user-stories>. Acesso em: 13 ago.2018.

ROMER, RafaeL. O que são as fintechs e por que elas estão ganhando tanto espaço?

Disponível em: < https://canaltech.com.br/startup/o-que-sao-as-fintechs-e-por-que-elas-estao-

ganhando-tanto-espaco-65169/> Acesso em : 05 jun.2018.

SALERNO, MARIO S. Projeto de organizações integradas e flexíveis: processos, grupos e

gestão democrática via espaços de comunicação - negociação. São Paulo, Atlas, 1999.

SCHWABER, K; BEEDLE, M. Agile Software Development with Scrum. Prentice-Hall,

2002.

SCRUM MASTER. Disponível em: <https://www.agilealliance.org/glossary/scrum-master/>.

Acesso em: 10 ago.2018

SILVA, E. C. Governança Corporativa nas Empresas: guia prático de orientação para

acionistas, investidores, conselheiros de administração e fiscal, auditores, executivos,

gestores, analistas de mercado e pesquisadores. 3 ed. São Paulo: Atlas, 2012

SPRINT PLANNING. Disponível em: <https://www.agilealliance.org/glossary/sprint-

planning/>. Acesso em: 10 ago.2018

SUTHERLAND, Jeff. Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies. CUTTER IT journal, v.14, n.12, p. 5-11, dez. 2001. Disponível em:

<https://web.archive.org/web/20131217174707/http://www.controlchaos.com/storage/scrum-

articles/Sutherland%20200111%20proof.pdf>. Acesso em: 08 set.2018.

TATTAM, David. A Practical Guide to Compliance And Compliance Risk Management.

Disponível em: <https://cdn2.hubspot.net/hubfs/397867/eBooks/Complete-Guide-to-

Compliance-and-Compliance-Risk-Management.pdf? >. Acesso em: 15 set.2018.

TATTAM, David. Compliance Risk Management. 2015. Disponível em:

<https://blog.protecht.com.au/compliance-risk-management >. Acesso em 18 set. 2018

https://www.agilealliance.org/glossary/product-owner/

https://www.agilealliance.org/glossary/product-owner/

https://www.agilealliance.org/glossary/scrum-master/

https://www.agilealliance.org/glossary/sprint-planning/

https://www.agilealliance.org/glossary/sprint-planning/


TEAM. Disponível em: < https://www.agilealliance.org/glossary/team >. Acesso em: 10

ago.2018

TRAPP, Adriana Cristina Garcia; CORRAR, Luiz J.. Avaliação e gerenciamento do risco

operacional no Brasil: análise de caso de uma instituição financeira de grande porte. Rev.

contab. finanç., São Paulo , v. 16, n. 37, p. 24-36, Apr. 2005. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1519-

70772005000100002&lng=en&nrm=iso>. Acesso em: 28 set. 2018.

VALLE, R; OLIVEIRA, S.B. Análise e modelagem de processos de negócios . São Paulo: Atlas, 2009.

VENKATESIAH, Kumar. What You Need To Know About GRC Online Training. 2016.

Disponível em: < https://elearningindustry.com/what-need-know-grc-online-training>. Acesso em: 20 ago. 2018.

gestÃo de riscos e a integraÇÃo do modelo de...

Documents