Hi!
¡Mi nombre es Alexander y dirijo el desarrollo de TI en la UBRD!
En 2017, en el Centro de Desarrollo de Servicios de Tecnologías de la Información de la UBRD nos dimos cuenta de que había llegado el momento de cambios globales, o mejor dicho, de transformación ágil. En condiciones de intenso desarrollo empresarial y rápido crecimiento de la competencia en el mercado financiero, dos años es un período impresionante. Por tanto, es hora de resumir el proyecto.
Lo más difícil es cambiar tu forma de pensar y poco a poco cambiar la cultura en la organización, donde es común pensar: “¿Quién será el jefe en este equipo?”, “El jefe sabe mejor lo que tenemos que hacer”, “ Llevamos 10 años trabajando aquí y conocemos mejor a nuestros clientes, sabemos lo que necesitan."
La transformación ágil sólo puede ocurrir cuando las propias personas cambian.
Destacaría los siguientes miedos clave que impiden que las personas cambien:
- Miedo a perder poder y “charreteras”;
- Miedo a volverse innecesario para la empresa.
Habiendo emprendido el camino de la transformación, seleccionamos a los primeros "conejos experimentados": empleados del departamento minorista. El primer paso fue rediseñar la ineficiente estructura de TI. Habiendo ideado un concepto objetivo para la estructura, comenzamos a formar equipos de desarrollo.
La arquitectura de nuestro banco, como la de muchos otros, es "basura", por decirlo suavemente. Una gran cantidad de aplicaciones y componentes están interconectados monolíticamente mediante un enlace DB, hay un bus ESB, pero no cumple su propósito previsto. También hay algunos ABS.
Antes de formar equipos Scrum, surgió la pregunta: "¿En torno a qué debería formarse el equipo?" La idea de que había un producto en la lata, por supuesto, estaba en el aire, pero fuera de su alcance. Después de pensarlo mucho, decidimos que el equipo debería reunirse en torno a una dirección o segmento. Por ejemplo, "Créditos de equipo", que desarrolla préstamos. Una vez decidido esto, comenzamos a elaborar una composición objetivo de roles y un conjunto de competencias necesarias para el desarrollo efectivo de esta área. Como muchas otras empresas, tomamos en cuenta todos los roles excepto el Scrum Master; en ese momento era casi imposible explicarle al CIO cuál era el papel de esta maravillosa persona.
Como resultado, después de explicar la necesidad de lanzar equipos de desarrollo, lanzamos tres equipos:
- Préstamos
- Tarjetas
- Operaciones Pasivas
Con un conjunto de roles:
- Gerente de Desarrollo (Líder Técnico)
- revelador
- Analista
- Ensayador
El siguiente paso fue determinar cómo trabajaría el equipo. Llevamos a cabo una capacitación ágil para todos los miembros del equipo y sentamos a todos en una sala. No había PO en los equipos. Probablemente todos los que han realizado una transformación ágil comprenden lo difícil que es explicar el papel de un PO a la empresa, y aún más difícil sentarlo al lado del equipo y darle autoridad. Pero “entramos” en estos cambios con lo que teníamos.
Con tantas aplicaciones involucradas en los procesos de préstamos y el resto del negocio minorista, comenzamos a pensar: ¿quién podría ser el más adecuado para los roles? Un desarrollador de una pila de tecnología, y luego miras, ¡y necesitas un desarrollador de otra pila de tecnología! Y ahora ha encontrado a los que se necesitan, pero el deseo del empleado también es importante, y es bastante difícil obligar a una persona a trabajar donde no le gusta.
Después de analizar el funcionamiento del proceso empresarial de préstamo y de largas conversaciones con colegas, ¡finalmente encontramos un punto medio! Así aparecieron tres equipos de desarrollo.
¿Qué será lo próximo?
La gente empezó a dividirse entre los que quieren cambiar y los que no. Todo el mundo está acostumbrado a trabajar en condiciones de “me dieron un problema, lo hice, déjenme en paz”, pero el trabajo en equipo no implica eso. Pero también resolvimos este problema. ¡En total, 8 de cada 150 personas renunciaron durante los cambios!
Entonces empezó la diversión. Nuestros equipos intercomponentes comenzaron a desarrollarse. Por ejemplo, hay una tarea para la que es necesario tener habilidades en el campo del desarrollador de CRM. Está en el equipo, pero está solo. También hay un desarrollador de Oracle. ¿Qué hacer si necesitas resolver 2 o 3 tareas en CRM? ¡Enséñense unos a otros! Los muchachos comenzaron a transferirse sus competencias entre sí y el equipo amplió sus capacidades, minimizando la dependencia de un especialista fuerte (por cierto, en cualquier empresa hay superhombres que lo saben todo y no se lo cuentan a nadie).
Hoy hemos reunido 13 equipos de desarrollo para todas las áreas de desarrollo de negocios y servicios. Continuamos nuestra transformación ágil y alcanzamos un nuevo nivel. Esto requerirá nuevos cambios. Rediseñaremos equipos y arquitectura, y desarrollaremos competencias.
Nuestro objetivo final: responder rápidamente a los cambios de productos, traer rápidamente nuevas funciones al mercado y mejorar los servicios del banco.
Fuente: habr.com