Te contamos los aprendizajes obtenidos de la experiencia de APIficar un banco con un contexto de equipos distribuidos en varios países. Hablaremos de cómo nos enfrentamos al reto de crear, escalar y evolucionar comunidades de desarrollo de software de más de 1000 personas en diferentes áreas tecnológicas y países.

Punto de partida

Estamos en un proyecto de transformación multinacional. Más de 1000 personas enfocadas en transformar cómo se realizaba el desarrollo de software para aumentar la productividad y reducir el tiempo de construcción de nuevos productos. El objetivo era ofrecer a los desarrolladores una plataforma que les permita construir software global para los clientes de forma que se maximizase la reutilización.

Una de las iniciativas de transformación dentro de este proyecto tenía el propósito de APIficar todos los servicios backend de forma que:

• Se aumentase la entrega de valor llegando más rápido a los clientes
• Se contase con un único punto de entrada donde encontrar todos los servicios backend apificados de todos los países
• Se tuviera un lenguaje común que unifique todos los conceptos de negocio
• Se adoptasen los diseños de APIs de forma global de forma que se diseñe el API una vez y se reutilice n veces

Cómo lo llevamos a cabo

Para acometer esta iniciativa primero había que unificar criterios de diseño y definición de APIs por lo que **iniciamos con un equipo centralizado **para realizar los diseños -la especificación del API- de los servicios que demandaba el negocio.

Elegimos un proyecto de negocio que tuviese como objetivo disponibilizar sus funciones a todos los países de la multinacional. Es decir, que dicha aplicación permitiese por ejemplo contratar un seguro de coche en España, en México, en Chile etc… y que la experiencia fuese la misma para el cliente final.

El equipo centralizado trabajaba codo con codo con los equipos de negocio para realizar estas definiciones y conseguir que tuvieran un lenguaje común. Con la definición terminada, un equipo de desarrollo backend de un país, tomaba esta definición y construía el código software del servicio. Posteriormente se integraba la funcionalidad con los equipos de desarrollo frontend que la consumían, para finalmente disponibilizarse la funcionalidad a los clientes finales.

Pero pronto surgieron los primeros desafíos:

• Las definiciones de APIs que se realizaban no siempre era posible implementarlas en su completitud debido a que ciertos campos del API no están presentes en el país. Esto derivó en realizar varios ciclos de retrabajo del API
• El descontento de los países por varios motivos. Uno relacionado con las funciones de los desarrolladores - les estábamos quitando la responsabilidad de realizar los diseños a los equipos de desarrollo- y otro relacionado con el tiempo, en vez de mejorarlo, empeoraba al añadir el trabajo del equipo centralizado
• El equipo centralizado estaba sobrepasado de trabajo, no era capaz de abordar la cantidad de solicitudes que se recibían desde negocio sin realizar un escalado insano del equipo.

Nos estábamos enfrentando a un reto del que no existe un precedente sobre cómo proceder. Así que, cambiamos el enfoque y empezamos a experimentar con el objetivo de encontrar la mejor forma de trabajar que funciona en este contexto.

La forma de trabajar centralizada no nos estaba ayudando en absoluto, además no estábamos aprovechando el talento local para acometer la iniciativa necesario para poder escalar y adoptar la forma de trabajo, así que cambiamos la forma de trabajar de centralizada a descentralizada. Comunicamos a los países este cambio en la forma de trabajar. Para no quemar cartuchos, pedimos dos países voluntarios que quisieran probar una forma diferente con la que trabajar.

Del trabajo en conjunto de los equipos de desarrolladores locales, los equipos de negocio locales y globales y del equipo inicial centralizado surge una nueva forma de trabajar a la que llamamos Comunidad.

¿Y por qué una comunidad?

Porque una comunidad es la **unión de un grupo de personas que comparten un mismo interés **y que se organizan para llevar a cabo un propósito.

Teníamos un propósito muy claro que es: “Construir APIs Globales para que ofrezcamos un mejor servicio a nuestros clientes”.

Además las comunidades son idóneas para:

• Impulsar la inteligencia colectiva y la co-creación
• Gestionar el aprendizaje y expandir el conocimiento
• Crear un alineamiento en lo que se necesita hacer y en cómo llevarlo a cabo
• Potenciar la cultura de la empresa y la satisfacción de los empleados

La comunidad tenía los siguientes elementos:

• Un mínimo de estructura basada en roles y funciones que permite saber quién hace qué y cómo.
• Una base de conocimiento compartida que permite a todos los miembros contar con la información que necesitan para realizar sus actividades.
• Un flujo de trabajo sencillo, claro y conocido por todos los miembros de la comunidad. Backlog de trabajo compartido y visible permite conocer la carga de trabajo y facilita la colaboración
• Uso de herramientas que faciliten la co-creación. Todos utilizan las mismas herramientas para los mismos fines, por ejemplo todos usamos Slack para comunicarnos de forma online, o todos usamos Git como repositorio de código fuente
• Gestionar la comunicación de forma adecuada con transparencia pero evitando el exceso de información. Canales de comunicación establecidos, conocidos por todos y con propósito claro

Madurando a través del tiempo

Con el paso del tiempo, el contexto de la iniciativa iba cambiando provocado tanto de forma externa, por la evolución de otras de las iniciativas de transformación, como de forma interna. Esto ha hizo que la comunidad estuviera siempre en continuo cambio, y por tanto los elementos mencionados anteriormente también:

• Añadimos métricas que ayudaban a entender cómo mejorar la forma de trabajar
• Empezamos a impulsar la mejora contínua a través de estas métricas basándonos en los datos
• Escuchamos a los miembros de la comunidad a través de sesiones específicas y obteniendo feedback para impulsar acciones sobre los problemas y necesidades de los mismos
• Empezamos a tomar decisiones de forma inclusiva y participativa utilizando un sistema de pasos
• … y un largo etcétera de más acciones que realizamos

Lo más importante de todo es que estas evoluciones fueron surgiendo a través de los miembros de la comunidad, más de 1000 personas trabajando de forma colaborativa y co-creada. Esto ha permitido evolucionar la comunidad según los miembros han considerado necesario para cumplir el propósito.

Conclusiones

• Las comunidades son muy potentes pero no se pueden clonar, porque no hay dos organizaciones iguales, cada organización necesita diseñar la suya
• Una comunidad necesita de un mínimo de estructura y organización que les permita a las personas comunicarse, gestionar el trabajo y el conocimiento
• Las comunidades deben estar en constante cambio y evolución, necesitan ir adaptándose al contexto y a las necesidades de los miembros

Si estás interesado en este tema ¡siguenos!. Además puedes dejarnos tus dudas y problemáticas en un comentario o contactanos!