Oi!
Meu nome é Alexander e lidero o desenvolvimento de TI na UBRD!
Em 2017, nós, do centro de desenvolvimento de serviços de tecnologia da informação da UBRD, percebemos que havia chegado o momento de mudanças globais, ou melhor, de transformação ágil. Em condições de intenso desenvolvimento empresarial e rápido crescimento da concorrência no mercado financeiro, dois anos é um período impressionante. Portanto, é hora de resumir o projeto.
O mais difícil é mudar o pensamento e mudar gradativamente a cultura da organização, onde é comum pensar: “Quem vai ser o chefe dessa equipe?”, “O chefe sabe melhor o que precisamos fazer”, “ Trabalhamos aqui há 10 anos e conhecemos melhor nossos clientes.”, sabemos o que eles precisam.”
A transformação ágil só pode acontecer quando as próprias pessoas mudam.
Eu destacaria os seguintes medos principais que impedem as pessoas de mudar:
- Medo de perder poder e “drapas”;
- Medo de se tornar desnecessário para a empresa.
Tendo embarcado no caminho da transformação, selecionamos os primeiros “coelhos experientes” - funcionários do departamento de varejo. O primeiro passo foi redesenhar a estrutura de TI ineficiente. Tendo definido um conceito-alvo para a estrutura, começamos a formar equipes de desenvolvimento.
A arquitetura do nosso banco, como a de muitos outros, é “lixo”, para dizer o mínimo. Um grande número de aplicações e componentes são interligados monoliticamente pelo link DB, existe um barramento ESB, mas não cumpre a finalidade pretendida. Existem também alguns ABS.
Antes de formar equipes Scrum, surgiu a pergunta: “Em torno do que a equipe deve ser montada?” O conceito de que havia um produto na lata, claro, estava no ar, mas fora de alcance. Depois de muito pensar, decidimos que a equipe deveria estar reunida em torno de uma direção ou segmento. Por exemplo, “Team Credits”, que desenvolve empréstimos. Decidido isso, começamos a traçar uma composição-alvo de funções e um conjunto de competências necessárias ao efetivo desenvolvimento desta área. Como muitas outras empresas, levamos em consideração todas as funções, exceto o Scrum Master – naquela época era quase impossível explicar ao CIO qual era a função dessa pessoa maravilhosa.
Como resultado, após explicar a necessidade de lançar equipes de desenvolvimento, lançamos três equipes:
- Empréstimos
- Cartões
- Operações passivas
Com um conjunto de funções:
- Gerente de Desenvolvimento (Líder Técnico)
- Revelador
- Analista
- Testador
O próximo passo foi determinar como a equipe trabalharia. Realizamos treinamento ágil para todos os membros da equipe e reunimos todos em uma sala. Não houve POs nas equipes. Provavelmente todo mundo que fez uma transformação ágil entende o quão difícil é explicar o papel de um PO para o negócio, e ainda mais difícil colocá-lo ao lado da equipe e dar-lhe autoridade. Mas “entrámos” nestas mudanças com o que tínhamos.
Com tantas aplicações envolvidas em processos de empréstimo e no restante do negócio de varejo, começamos a pensar: quem poderia ser a pessoa certa para as funções? Um desenvolvedor de uma pilha de tecnologia, e então você olha - e precisa de um desenvolvedor de outra pilha de tecnologia! E agora você encontrou quem é necessário, mas a vontade do funcionário também é uma coisa importante, e é muito difícil obrigar uma pessoa a trabalhar onde ela não gosta.
Depois de analisar o trabalho do processo comercial de empréstimos e longas conversas com colegas, finalmente encontramos um meio-termo! Foi assim que surgiram três equipes de desenvolvimento.
Qual é o próximo?
As pessoas começaram a se dividir entre aqueles que querem mudar e aqueles que não querem. Todo mundo está acostumado a trabalhar na condição de “me deram um problema, eu consegui, me deixa em paz”, mas o trabalho em equipe não implica isso. Mas também resolvemos esse problema. No total, 8 em cada 150 pessoas desistiram durante as mudanças!
Então a diversão começou. Nossas equipes multicomponentes começaram a se desenvolver. Por exemplo, há uma tarefa para a qual você precisa ter habilidades na área de desenvolvedor de CRM. Ele está na equipe, mas está sozinho. Há também um desenvolvedor Oracle. O que fazer se precisar resolver 2 ou 3 tarefas no CRM? Ensinem uns aos outros! Os caras começaram a transferir suas competências entre si, e a equipe ampliou suas capacidades, minimizando a dependência de um especialista forte (aliás, em qualquer empresa existem super-homens que sabem tudo e não contam a ninguém).
Hoje reunimos 13 equipes de desenvolvimento para todas as áreas de desenvolvimento de negócios e serviços. Continuamos nossa transformação ágil e alcançamos um novo patamar. Isso exigirá novas mudanças. Vamos redesenhar equipes e arquitetura e desenvolver competências.
Nosso objetivo final: responder rapidamente às mudanças de produtos, trazer rapidamente novas funcionalidades ao mercado e melhorar os serviços do banco!
Fonte: habr.com