Ola!
Chámome Alexander e dirixo o desenvolvemento de TI na UBRD.
En 2017, o centro para o desenvolvemento de servizos de tecnoloxía da información da UBRD decatámonos de que chegou o momento dos cambios globais, ou mellor dito, da transformación áxil. En condicións de desenvolvemento empresarial intensivo e rápido crecemento da competencia no mercado financeiro, dous anos son un período impresionante. Polo tanto, é o momento de resumir o proxecto.
O máis difícil é cambiar de pensamento e ir cambiando pouco a pouco a cultura na organización, onde é habitual pensar: “Quen será o xefe deste equipo?”, “O xefe sabe mellor o que temos que facer”, “ Levamos 10 anos traballando aquí e coñecemos mellor aos nosos clientes". , sabemos o que necesitan".
A transformación áxil só pode ocorrer cando as propias persoas cambian.
Destacaría os seguintes temores fundamentais que impiden que a xente cambie:
- Medo a perder poder e “charreteras”;
- Medo a facerse innecesario para a empresa.
Despois de emprender o camiño da transformación, seleccionamos os primeiros "coellos experimentados": empregados do departamento de venda polo miúdo. O primeiro paso foi redeseñar a ineficiente estrutura informática. Despois de ter un concepto obxectivo para a estrutura, comezamos a formar equipos de desenvolvemento.
A arquitectura do noso banco, como noutros moitos, é "lixo", por dicilo suavemente. Un gran número de aplicacións e compoñentes están interconectados monolíticamente mediante enlace DB, hai un bus ESB, pero non cumpre o seu propósito. Tamén hai ABS.
Antes de formar equipos Scrum, xurdiu a pregunta: "¿En que debería estar o equipo?" O concepto de que había un produto na lata, por suposto, estaba no aire, pero só fóra do alcance. Despois de pensar moito, decidimos que o equipo debería estar reunido arredor dunha dirección ou segmento. Por exemplo, "Team Credits", que desenvolve préstamos. Unha vez decidido isto, comezamos a elaborar unha composición obxectivo de roles e un conxunto de competencias necesarias para o desenvolvemento efectivo desta área. Como moitas outras empresas, tivemos en conta todos os roles excepto o Scrum Master; naquela época era case imposible explicarlle ao CIO cal era o papel desta marabillosa persoa.
Como resultado, despois de explicar a necesidade de poñer en marcha equipos de desenvolvemento, puxemos en marcha tres equipos:
- Préstamos
- Mapas
- Operacións pasivas
Cun conxunto de papeis:
- Gerente de Desenvolvemento (Líder Técnico)
- Desenvolvedor
- Analista
- Probador
O seguinte paso foi determinar como traballaría o equipo. Realizamos adestramentos áxiles para todos os membros do equipo e sentámonos a todos nunha sala. Non había OP nos equipos. Probablemente todos os que fixeron unha transformación áxil entendan o difícil que é explicar o papel dun OP á empresa, e aínda máis difícil sentalo ao carón do equipo e darlle autoridade. Pero "entramos" nestes cambios co que tiñamos.
Con tantas aplicacións implicadas nos procesos de préstamo e no resto do negocio de venda polo miúdo, comezamos a pensar, quen podería ser o axeitado para os roles? Un desenvolvedor dunha pila tecnolóxica, e despois miras, e necesitas un desenvolvedor doutra pila tecnolóxica! E agora atopaches os que son necesarios, pero o desexo do empregado tamén é algo importante, e é bastante difícil forzar a unha persoa a traballar onde non lle gusta.
Despois de analizar o traballo do proceso empresarial de préstamo e de longas conversas cos compañeiros, por fin atopamos un punto medio! Así apareceron tres equipos de desenvolvemento.
Cal é o próximo?
A xente comezou a dividirse entre os que queren cambiar e os que non. Todo o mundo está afeito a traballar nas condicións de “déronme un problema, fixémolo, déixame en paz”, pero o traballo en equipo non o implica. Pero tamén solucionamos este problema. En total, 8 de cada 150 persoas abandonaron durante os cambios.
Entón comezou a diversión. Os nosos equipos de compoñentes cruzados comezaron a desenvolverse. Por exemplo, hai unha tarefa para a que precisa ter habilidades no campo do programador CRM. Está no equipo, pero está só. Tamén hai un programador de Oracle. Que facer se precisa resolver 2 ou 3 tarefas en CRM? Ensinar uns a outros! Os mozos comezaron a transferirse as súas competencias entre si e o equipo ampliou as súas capacidades, minimizando a dependencia dun só especialista (por certo, en calquera empresa hai superhomes que o saben todo e non o di a ninguén).
Hoxe reunimos 13 equipos de desenvolvemento para todas as áreas de desenvolvemento empresarial e de servizos. Continuamos a nosa transformación áxil e alcanzamos un novo nivel. Isto requirirá novos cambios. Redeseñaremos equipos e arquitectura, e desenvolveremos competencias.
O noso obxectivo final: responder rapidamente aos cambios de produto, levar rapidamente novas funcións ao mercado e mellorar os servizos do banco.
Fonte: www.habr.com