Hola
¡Mi nombre es Alexander y lidero el desarrollo de TI en UBRD!
En 2017, en el centro de desarrollo de servicios de tecnología de la información de UBRD nos dimos cuenta de que había llegado el momento de los cambios globales, o más bien, las transformaciones ágiles. En condiciones de desarrollo comercial intensivo y rápido crecimiento de la competencia en el mercado financiero, dos años es un período impresionante. Así que es hora de hacer un balance del proyecto.
Lo más difícil es cambiar su forma de pensar y gradualmente la cultura en la organización, donde se acostumbra a razonar: "¿quién será el jefe en este equipo?", "El jefe sabe mejor lo que debemos hacer", "hemos estado trabajando aquí durante 10 años y sabemos mejor que nuestros clientes , sabemos lo que necesitan ".
La transformación ágil solo puede ocurrir cuando las personas mismas cambian en ella.
Destacaría los siguientes temores clave que evitan que las personas cambien:
- Miedo a perder poder y "charreteras";
- Miedo a volverse innecesario para la empresa.
Tras embarcarnos en un camino de transformación, seleccionamos los primeros "conejos experimentados": empleados del sector minorista. El primer paso fue rediseñar la ineficiente estructura de TI. Una vez que se nos ocurrió el concepto objetivo de la estructura, comenzamos a formar equipos de desarrollo.
La arquitectura en nuestro banco, como en muchos otros, para decirlo suavemente "golpear". Una gran cantidad de aplicaciones y componentes, perfectamente vinculados por el enlace DB, tienen un bus ESB, pero no cumple su propósito. También hay varios ABS.
Antes de formar equipos scrum, surgió la pregunta: "¿Y en torno a qué se debe formar el equipo?". El concepto de que hay un producto en el banco, por supuesto, estaba en el aire, pero a una distancia de inaccesibilidad. Después de mucha deliberación, decidieron que el equipo debería reunirse en torno a una dirección o segmento. Por ejemplo, "préstamos de equipo", que desarrolla préstamos. Una vez decidido esto, comenzamos a encontrar la composición objetivo de los roles y un conjunto de competencias necesarias para el desarrollo efectivo de esta área. Al igual que muchas otras compañías, tomamos en cuenta todos los roles, excepto 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 aclarar la necesidad de lanzar equipos de desarrollo, lanzamos tres equipos:
- Préstamos
- Tarjetas
- Operaciones pasivas
Con un conjunto de roles:
- Gerente de Desarrollo (Tech Lead)
- Desarrollador
- Analista
- Probador
El siguiente paso fue determinar cómo funcionaría el equipo. Llevamos a cabo una capacitación ágil para todos los miembros del equipo, pusimos a todos en una habitación. PO no estaba en los equipos. Probablemente, todos los que hicieron la transformación ágil entienden lo difícil que es explicar el papel de la OP a las empresas, y es aún más difícil ponerlo al lado del equipo y darle autoridad. Pero "entramos" en estos cambios con lo que era.
Dado que una gran cantidad de aplicaciones estaban involucradas en los procesos de préstamos y otras áreas del negocio minorista, comenzamos a pensar, ¿quién puede adaptarse a los roles? El desarrollador de una pila de tecnología, y ahí lo ves, ¡y necesitas un desarrollador de otra pila de tecnología! Y entonces encontraste a los que son necesarios, pero el deseo del empleado también es algo importante, y lograr que una persona trabaje donde no le gusta es bastante difícil.
Después de analizar el trabajo del proceso de préstamos comerciales y largas conversaciones con colegas, ¡todavía encontramos un término medio! Entonces había tres equipos de desarrollo.
Que sigue
La gente comenzó a dividirse en aquellos que quieren cambiar y en aquellos que no quieren cambiar. Todos están acostumbrados a trabajar en condiciones de "me dieron una tarea, lo hice, déjenme en paz", y el trabajo en equipo no implica esto. Pero hemos resuelto este problema. ¡En total, 8 de cada 150 personas dejaron de fumar durante los cambios!
Entonces comenzó la diversión. Nuestros equipos de componentes cruzados comenzaron a desarrollarse. Por ejemplo, hay una tarea para la que necesita tener habilidades en el campo de un desarrollador de CRM. Él está en el equipo, pero está solo. También hay un desarrollador de Oracle. ¿Qué hacer si necesita resolver 2 o 3 tareas en CRM? ¡Enseñarse unos a otros! Los muchachos comenzaron a transferir sus competencias entre ellos, 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 dicen a nadie).
Hoy, hemos reunido 13 equipos de desarrollo para todas las áreas de desarrollo de negocios y servicios. Continuamos la transformación ágil y avanzamos a un nuevo nivel. Esto requerirá nuevos cambios. Rediseñaremos equipos y arquitectura, desarrollaremos competencias.
Nuestro objetivo final: responder rápidamente a los cambios en el producto, introducir rápidamente nuevas funciones en el mercado y mejorar los servicios del banco.