Distribución de equipos de tecnología en el sector financiero

‍

Durante los últimos años, desde Ginko hemos estudiado por qué a los equipos de tecnología de los bancos les cuesta tanto llevar adelante sus desarrollos tecnológicos, siendo que cuentan con grandes equipos, talentos y recursos económicos. Empresas mucho más pequeñas, con menos recursos, pueden moverse con mayor agilidad.

Llegamos a la misma conclusión que Matthew Skelton cuenta en el libro Team Topologies (2019): la tecnología y la innovación de una organización son importantes, pero lo que de verdad marca la diferencia es la distribución o la conformación de los equipos.‍

Para lograr que un banco funcione de manera eficiente es imprescindible diseñar una arquitectura de software efectiva que pueda alinear la tecnología y la innovación con la cultura empresarial. ‍

Vayamos a eso pero, antes, recordarte que si te gusta el contenido de Ginko y quieres recibir en tu correo electrónico este y otros recursos de valor, apúntate a nuestra newsletter mensual.

Cultura organizacional: de la estructura a los resultados del negocio

La cultura de una organización —sea en un banco o en cualquier otro tipo de empresa— no surge por arte de magia.

Requiere de una arquitectura organizacional concreta que favorezca la aparición de todos los factores que transformarán un grupo de personas en un equipo, como veremos más adelante.

Antes, para entender cómo se desarrolla este proceso cultural, veamos algunas características claves de distribución de equipos, que nos ayudarán a diseñar una estructura organizacional que apunte a resultados:

• Estructura dinámica y flexible.
• Arquitectura con base en resultados.
• División de software.

Contemplando estos tres aspectos, ya estaremos mucho más cerca de asegurar el éxito de nuestros desarrollos.

‍

Estructura dinámica y flexible

Una estructura dinámica y flexible permite la generación de un flujo de entregables que cumpla con las necesidades actuales del negocio de la banca, algo que está en constante cambio. Las regulaciones son un buen ejemplo.

Cuando hablamos de flujo de entregables eficientes, nos referimos a diseñar un ambiente de trabajo que le quite carga cognitiva al equipo. Es decir, que le facilite la vida, porque no podemos gastar ciclos de CPU (y por CPU nos referimos a nuestros cerebros) resolviendo aspectos que son rutinarios y no tienen nada que ver con el negocio, o con el valor que se le entrega al usuario final. 

‍Si le sacamos el ruido y el esfuerzo innecesario al equipo de trabajo (desarrollo, DevOps, QA) estoy optimizando además la inversión en ese equipo.

Cuando utilizamos el término «flujo de entregables», también nos referimos a que el trabajo de cada equipo no termina cuando se entrega al siguiente eslabón de la cadena de producción, sino cuando se soluciona el problema en cuestión.

‍Cada uno de los procesos internos debe concluir en un resultado que haga sentido al negocio.
‍

‍Todos los equipos que forman parte de la estructura bancaria deben orientarse a la resolución de problemas.

‍
‍‍‍‍En el libro Team Topologies se concluye que el gran “pero” para conseguir que una estructura dinámica y flexible funcione bien, está en la construcción y distribución de los equipos.

‍Imaginemos que una empresa quiere desarrollar un microservicio bancario en el que intervendrán cuatro equipos.

Para desarrollar este proceso de manera correcta es imprescindible que los equipos se comuniquen entre sí.

Una buena manera de distribuir los equipos consistiría en reestructurar el espacio físico de trabajo para que se encuentren cerca unos de otros. En el caso de las dinámicas de trabajo remoto, lo ideal es habilitar herramientas de mensajería y gestión de procesos (Meet, Slack, Teams u otras que permitan la organización por grupos) para reemplazar los espacios físicos y facilitar una comunicación fluida.

De esta manera podrán mantener su propia autonomía e interactuar siempre que sea necesario. Bastará con levantarse y preguntar, en lugar de mandar un email y esperar varias semanas a que llegue una respuesta.

Asegura resultados para el banco con una estructura dinámica y flexible que facilite el flujo de entregables de manera consciente.
‍

Arquitecturas con base en resultado

Las estructuras de las organizaciones, si bien se dibujan de forma estática, no lo son. Las organizaciones deberían tener la capacidad de cambiar de forma que nos permitan resolver con eficiencia nuestras necesidades.

No deberíamos, entonces, estar limitados al organigrama.

Esto tiene que ver con el estudio de las organizaciones modernas. Para que la arquitectura de una organización funcione, debe estar alineada con el componente humano.

‍En varios estudios sobre las Organizaciones Teal, como por ejemplo el libro Reinventando las organizaciones de Federic Laloux, se puede concluir que la distribución de equipos de una organización no puede mantenerse estática, pero tampoco variar constantemente.

Se deben realizar los cambios pertinentes en cada momento que lleven a su desarrollo más eficiente.
‍

‍Las Organizaciones Teal deben estar inspiradas en el principio de naturaleza humana que considera a las personas como las protagonistas de cualquier gestión.

‍
‍‍Solo se logrará maximizar la eficiencia del banco adaptando los equipos a las necesidades de cada una de las etapas del flujo de trabajo.

Esto nos deja con una máxima: el software debería ser dividido cada vez que sobrepasa la capacidad cognitiva del equipo que lo tiene a cargo.
‍

División de software

Ya hemos tratado la importancia que tiene la autonomía de cada equipo para desarrollarse correctamente.

No obstante, habrá momentos en los que surja la necesidad de dividir el proceso de desarrollo de un software en diferentes equipos.

La pregunta es: ¿Cuándo debe realizarse esta división y cómo debe ejecutarse?
‍‍

‍A la hora de desarrollar un software, la unidad mínima de trabajo sobre la que debe recaer una responsabilidad es un equipo, nunca un individuo.

‍
‍‍La persona que sabe más, que se pone la capa de Superman, finalmente termina subrecargado y generando un cuello de botella, sufriendo burnout y finalmente renunciando. 

Entonces, se debe procurar responsabilizar a un equipo (no a un individuo) y además generar sensación de propiedad, principalmente para mantener viva la motivación. Dan Pink afirma que para mantener a un equipo motivado en este proceso se necesitan tres elementos:

• Autonomía de trabajo.
• Maestría en el proceso.
• Propósito en el proyecto.

Siempre que no se encuentren estos tres elementos en el proceso de desarrollo se producirá un desgaste continuado del equipo y de cada uno de sus miembros.

Todos estos aspectos los vivimos cotidianamente en Ginko como jefes de proyectos, como arquitectos, como gerentes de área. O sea, una teoría que se evidencia fácilmente en la práctica.

El software construido refleja la estructura organizacional

La Ley de Conwell afirma que la estructura que elija una empresa para organizarse se verá reflejada en el resultado del software que desarrolle. Lo que quiere decir que la manera de trabajar condiciona el producto final que podemos alcanzar.

Si pensamos en un banco que trabaje con una distribución de equipos en silos, esta división se manifestará también en el resultado final del software que hayan desarrollado.

‍Los silos son compartimentos estancos que impiden el flujo de trabajo entre equipos. Está en su naturaleza olvidarse de que hay alguien fuera de sus fronteras.

‍Como existen interferencias entre la transmisión entre un punto y otro, es imposible desarrollar un flujo de trabajo que piense más allá de “acabar la parte que me corresponde”.

Por lo tanto, si queremos desarrollar un software con un proceso de principio a fin, el equipo o los equipos que intervengan, necesitan (además de ser conscientes del proceso completo) estar pensados para responder a ese software, y no al revés.
‍

‍Organizar equipos de acuerdo a la arquitectura que queremos como resultado, en vez de organizar la arquitectura de acuerdo a los equipos.

‍
‍‍Es decir, si vamos a desarrollar microservicios, tenemos que pensar que la topología de equipos deberá reflejar la arquitectura que queremos como resultado. De lo contrario, estaríamos tratando de clavar un clavo con un destornillador. Podemos clavar el clavo, sí, pero no va a ser muy eficiente el proceso.

Ahora que ya hemos reflexionado sobre la estructura de la organización, toca focalizarse en la organización propia de cada equipo del banco.

‍

Cómo deben organizarse los equipos

Preparar un equipo de alto rendimiento requiere de mucho tiempo, inversión y energía para un banco. Nuestra búsqueda, desde Ginko, es ir acompañando a este proceso de organización interna.

Aquí nuestras recomendaciones: trabajar en los siguientes tres factores que ayudarán al banco a organizarse de manera eficiente:

• Pensar como equipo.
• Diseñar equipos pequeños y de larga duración.
• Cuidar la capacidad cognitiva del equipo.

Demos una mirada rápida a cada uno de ellos.
‍

Pensar como equipo

En las grandes corporaciones se suele cometer un error habitual: se piensa que juntar a un grupo de personas es tener a un equipo, pero nada más lejos de la realidad.

Es una tarea del CTO crear el ambiente adecuado donde todos los equipos se organicen de acuerdo a su nivel de necesidad y responsabilidad.
‍

Los equipos deben pensar como equipo, y sus integrantes deben respetar los compromisos adquiridos por el equipo.

Esto nos lleva a pensar en lo que se conoce como Mentalidad Team First, que implica, entre otras cosas, lo siguiente:

• Asistir a las reuniones diarias del equipo.
• Poner de manera constante el foco en los objetivos.
• Ayudar a los compañeros siempre que sea posible.
• Participar en sesiones de mentoring y de capacitación.
• Evitar discusiones para lograr victorias personales.
• Fomentar la diversidad del equipo para contar con diferentes puntos de vista.

Una vez que estas ideas claves están claras podemos pasar a hablar sobre cómo se diseñan estos equipos.
‍

Diseñar equipos pequeños y de larga duración

La teoría del Número de Dunbar afirma que es es mucho más fácil conocer a las personas con las que trabajas y realizar mejores asociaciones, cuando se trabaja en grupos pequeños.

150: ese es el número máximo de personas en las que se puede generar un círculo de confianza que facilite la gestión de conflictos de forma eficiente.

Si nos mantenemos debajo de esta cifra, con el paso del tiempo: 

• Aumentará el compromiso entre los miembros del equipo.
• Se fortalecerá el propósito del equipo.
• Se reducirá el número de potenciales conflictos que puedan aparecer.

A su vez, además de incentivar la construcción de equipos pequeños, debemos ser conscientes de no superar su carga de trabajo. Lo que nos lleva al siguiente punto.
‍

Cuidar de la capacidad cognitiva del equipo

La carga cognitiva de una tarea es la cantidad de recursos mentales que exige la realización de la misma.

Cuando distribuimos la carga de trabajo entre los equipos, es fundamental entender cuál es la carga cognitiva que genera cada acción requerida y dónde están los límites de esa carga.

Existen tres tipos de carga cognitiva que debemos tener en cuenta al realizar una distribución de tareas o proyectos:

• Carga cognitiva intrínseca.
• Carga cognitiva externa.
• Carga cognitiva relevante.

Carga cognitiva intrínseca

Este término hace referencia al conocimiento base de la tarea que hay que realizar.

Cuando buscamos a un colaborador que se encargue de un proyecto, es fundamental que sea alguien que ya domine la herramienta que podemos utilizar.

En caso contrario, este miembro del equipo estaría empleando gran parte de su capacidad cognitiva en algo que otra persona podría realizar sin mayor dificultad.

Por ejemplo, en el caso de tener que resolver una tarea donde se necesite utilizar lenguaje JAVA, buscaremos a un profesional que ya sea un experto, en vez de tener que entrenar a uno de nuestros colaboradores.

Una manera eficiente de reducir la carga cognitiva intrínseca es ofreciendo capacitaciones adecuadas a los miembros de los equipos.

Carga cognitiva externa

Está relacionada con el ambiente de tecnología del banco: despliegues técnicos, servidores, todo lo que guarda relación con el ambiente de DevOps.

Muchos bancos operan sin todo lo mencionado, lo que implica que durante el despliegue de operaciones se necesite a otro equipo particular que se encargue de gestionarlo.

Este departamento termina por convertirse en otro departamento de operaciones, que revisa lo que realiza el resto de los equipos.
‍

Carga cognitiva relevante 

Se refiere a todas las tareas que tienen que ver con un dominio específico. Es decir, aquello que ya sabemos, que es necesario para resolver un problema, y que no se puede aprender principalmente porque es un nuevo desafío, propio del problema a resolver.

Por ejemplo, el ingeniero del equipo no puede acudir a un foro en busca de información sobre cómo resolver la tarea que tiene por delante, sino que usará su conocimiento y experiencia para resolverlo.

Y digámoslo de otra forma. Para resolver de mejor forma un problema, hay que invertir la energía en esa tarea, en vez de malgastar el tiempo en reuniones e insistiendo por correo para que ejecuten una tarea que ya pedimos hace tiempo.
‍

Consecuencias de no respetar la carga cognitiva

Cuando se supera la capacidad cognitiva de un equipo, cada individuo querrá tomar el control de la situación y resolver su propia parte, perdiendo la dinámica de equipo. Una decisión que reducirá el rendimiento del equipo y afectará al clima laboral.

Cuando se sobrepasa la carga cognitiva, se pierde la mentalidad de equipo.

Durante mucho tiempo se extendió la idea de que la manera de solucionar esta situación era añadir más individuos a cada equipo. Sin embargo, esto no funciona por lo que afirma la Ley de Brooks: es más eficaz dividir los problemas en otros problemas más pequeños, de tal manera que pueden ser atacados por equipos del mismo tamaño.

Tal y como cuenta Tom deMarco en Peopleware: un equipo gestionado de forma correcta trabaja feliz, y esto finalmente se traduce en un mejor rendimiento.

Al fin y al cabo, estamos pagando los mismos sueldos. Para generar el mejor provecho al dinero hay que procurar que la gente trabaje motivada y contenta con lo que está haciendo.

Una propuesta de distribución a través de APIs

Hoy, en el mundo actual del desarrollo, tenemos que ser estratégicos a la hora de hacer una delimitación correcta entre equipos. Para ello, ya tenemos una herramienta básica: podemos usar las APIs. Las APIs son una especie de contrato de interacción entre componentes.

Se hace evidente entonces que un camino para darle forma a los equipos y proteger sus entregables, manteniendo a su vez la autonomía y motivación, es que estos equipos desarrollen servicios en los que expongan sus APIs.

Para llevar adelante esta buena práctica, es importante un buen desarrollo del código, por supuesto, pero principalmente lograr una buena documentación de la API y considerar la experiencia de usuario dentro de su entregable.
‍‍

El equipo debe tener en claro quién va a interactuar con su producto para satisfacer correctamente las necesidades de otros equipos.‍

Esto nos lleva además a evaluar constantemente si las APIs diseñadas están cumpliendo con su principal funcionalidad: interactuar con otros equipos de tecnología.

Para llevar adelante este tipo de proyectos, por supuesto que es necesario antes reflexionar y poner en práctica todo lo mencionado (una estructura de organización flexible y una cultura de trabajo que contemple la capacidad cognitiva de los equipos) y contar con tecnología que pueda facilitar el proceso.‍

Plataformas como PSD están preparadas para ello: desarrollar servicios y exponer APIs que permitan la interacción entre los equipos internos, alcanzar los objetivos planteados por el banco y, más importante aún, no sufrir durante el proceso. 

En este enfoque, distinto al tradicional, no es más importante tener el porcentaje perfecto de progreso en la gantt, sino generar un flujo de entregables que permita la continua evolución del software en el banco, y trabajar para que los equipos estén realmente motivados.

Parte de la gestión de equipos de trabajo, que está compuesto por humanos, es velar por el bienestar de las personas.

‍