Oi
Meu nome é Alexander e lidero o desenvolvimento de TI na UBRD!
Em 2017, no Centro de Desenvolvimento de Serviços de Tecnologia da Informação da UBRD, chegamos à hora de mudanças globais, ou melhor, transformações ágeis. Em condições de intenso desenvolvimento de negócios e rápido crescimento da concorrência no mercado financeiro, dois anos são um período impressionante. Portanto, é hora de fazer um balanço do projeto.
O mais difícil é mudar o seu pensamento e gradualmente a cultura da organização, onde é costume raciocinar: “quem será o chefe dessa equipe?”, “O chefe sabe melhor o que precisamos fazer”, “trabalhamos aqui há 10 anos e conhecemos melhor que nossos clientes , sabemos o que eles precisam ".
A transformação ágil só pode acontecer quando as próprias pessoas mudam nela.
Eu destacaria os seguintes principais receios que impedem as pessoas de mudarem:
- Medo de perder poder e "dragonas";
- Medo de se tornar desnecessário para a empresa.
Tendo embarcado em um caminho de transformação, selecionamos os primeiros “coelhos experientes” - funcionários do setor de varejo. O primeiro passo foi redesenhar a ineficiente estrutura de TI. Tendo criado o conceito de alvo da estrutura, começamos a formar equipes de desenvolvimento.
A arquitetura em nosso banco, como em muitos outros, para dizer o mínimo "thrash". Um grande número de aplicativos e componentes, perfeitamente vinculados pelo link do DB, possui um barramento ESB, mas ele não cumpre seu objetivo. Existem também vários ABS.
Antes de formar equipes de scrum, surgiu a pergunta: “E em torno do que a equipe deve ser montada?”. O conceito de que existe um produto no banco, é claro, estava no ar, mas a uma distância de inacessibilidade. Após muita deliberação, eles decidiram que a equipe deveria se reunir em torno de uma direção ou segmento. Por exemplo, "Empréstimos para equipes", que desenvolve empréstimos. Tendo decidido isso, começamos a elaborar a composição alvo de papéis e um conjunto de competências necessárias para o desenvolvimento efetivo dessa área. Como muitas outras empresas, levamos em conta todos os papéis, exceto o Scrum Master - naquela época era quase impossível explicar ao CIO qual era o papel dessa pessoa maravilhosa.
Como resultado, depois de esclarecer a necessidade de lançar equipes de desenvolvimento, lançamos três equipes:
- Empréstimos
- Postais
- Operações passivas
Com um conjunto de funções:
- Gerente de Desenvolvimento (Líder Técnico)
- Desenvolvedor
- Analista
- Testador
O próximo passo foi determinar como a equipe funcionaria. Realizamos treinamento ágil para todos os membros da equipe, colocamos todos em uma sala. PO não estava nas equipes. Provavelmente, todo mundo que fez a transformação ágil entende o quão difícil é explicar o papel do OP para os negócios e é ainda mais difícil colocá-lo ao lado da equipe e dar autoridade. Mas nós "entramos" nessas mudanças com o que era.
Como um grande número de aplicativos estava envolvido nos processos de empréstimos e em outras áreas do negócio de varejo, começamos a pensar em quem poderia se encaixar nas funções? O desenvolvedor de uma pilha de tecnologia e pronto - e você precisa de um desenvolvedor de outra pilha de tecnologia! E então você encontrou aqueles que são necessários, mas o desejo do funcionário também é uma coisa importante, e conseguir que uma pessoa trabalhe onde ele não gosta é bastante difícil.
Depois de analisar o trabalho do processo de empréstimos comerciais e longas conversas com colegas, ainda encontramos um meio termo! Portanto, havia três equipes de desenvolvimento.
O que vem a seguir?
As pessoas começaram a se dividir entre aqueles que querem mudar e aqueles que não querem. Todo mundo está acostumado a trabalhar em condições de “eles me deram uma tarefa, eu fiz isso, me deixem em paz”, e o trabalho em equipe não implica isso. Mas nós resolvemos esse problema. No total, 8 em 150 pessoas desistem durante as mudanças!
Então a diversão começou. Nossas equipes de componentes cruzados começaram a se desenvolver. Por exemplo, há uma tarefa para a qual você precisa ter habilidades no campo de um desenvolvedor de CRM. Ele está no time, mas está sozinho. Há também um desenvolvedor Oracle. O que fazer se você precisar resolver 2 ou 3 tarefas no CRM? Ensinem um ao outro! Os caras começaram a transferir suas competências um para o outro, e a equipe expandiu suas capacidades, minimizando a dependência de um especialista forte (a propósito, em qualquer empresa, existem super-homens que sabem tudo e não contam a ninguém isso).
Hoje, reunimos 13 equipes de desenvolvimento para todas as áreas de desenvolvimento de negócios e serviços. Continuamos a transformação ágil e passamos para um novo nível. Isso exigirá novas alterações. Vamos redesenhar equipes e arquitetura, desenvolveremos competências.
Nosso objetivo final: responder rapidamente às mudanças no produto, introduzir rapidamente novos recursos no mercado e melhorar os serviços do banco!