Digital nativa = software + estrategia + organización

¿Te imaginas que tus equipos de ventas tienen a un equipo de ingeniería de software que funciona solo y eso sirve para digitalizar el proceso de ventas y vender más? y ¿te imaginas, además, que estos equipos de ingeniería de software trabajan tecnológicamente alineados con el resto de equipos digitales de la compañía de manera natural?

Si estás en el ámbito de las empresas digitales nativas, tal vez esto no te parezca tan raro, pero, los más antiguos del lugar, aquellos que ya picaban código hace 20 o 30 años, habrán visto la evolución organizativa de los equipos de desarrollo para hacerlos cada vez más adaptables al cambio. En mi carrera, me ha tocado ver como aquellos semidioses solitarios programadores de host (que trabajaban sin internet ni stackoverflow) llegaban con su bote a la cascada del sistema jerárquico del desarrollo waterflow, una cascada que que nos desembocó en el río de la democratización organizativa del agile, un río que se quedó parado en la presa devops dando paso a metodologías para grandes organizaciones digitales como las de las tribus y squads de los amigos de Spotify.

Una evolución que ha implicado varios cambios de paradigma orgánico que tienen sus grises y sus matices pero que cada vez hacen que los equipos de tecnología se integren mejor en las organizaciones, haciendo más consciente a los equipos de ingeniería de software de su impacto en la compañía.

Os confesaré que no siempre que me han pedido implementar DevOps en una compañía, me han pedido lo mismo, por ejemplo, hay directores de tecnología que entienden DevOps como un conjunto de herramientas que mejoran el Time to market. Pero DevOps es una filosofía organizativa que ubica a las personas en el centro potenciando sus capacidades y les dota de herramientas para eliminar aquellas tareas rutinarias que no aportan valor. Si lo vemos desde el plano de los equipos, yo suelo hacer un planteamiento de equipos dedicados a las áreas de negocio que se coordinan diariamente con sus daily's. Esta coordinación nos permite detectar problemas de coordinación empresarial y actuar como integradores entre departamentos (no sólo a nivel de software, si no a nivel operativo).

Con el equipo alineado con la estructura, nos queda garantizar la capacidad de adaptarnos a las necesidades del mercado pudiendo mover las personas entre equipos. Para ello, es imprescindible disponer de un código limpio y bien organizado. Por lo tanto, alinear la arquitectura de software con la estructura y objetivos empresariales es extremadamente estratégica y nos permitirá adaptarnos a los constantes cambios del mercado con un time to market muy competitivo, a la par que minimizamos en las dependencias interdepartamentales con una clara orientación a la integración con nuestros partners y a nuestros usuarios (tanto internos como externos).

Un ejemplo de arquitectura que se adecua a los cambios del mercado y nos facilita la escalabilidad tanto funcional, orgánica como de infraestructura es la organización del código en 3 tipologías básicas de building block (acuñando la terminología TOGAF) o artefactos de software.

?      El primer tipo de artefacto son los microservicios, los microservicios conforman nuestro backend y nos permiten alinear nuestros equipos con los departamentos. Cosa que hay que tener muy en cuenta cuando se define la granularidad de los mismos, un microservicio nunca puede recaer en medio de dos departamentos. Cuando buscamos implementar rápido los requisitos departamentales, puedes dedicar un equipo específico  (o varios) a implementar un backend de microservicios robustos con un product owner conocedor del sector.

?      El segundo tipo de artefactos son los micro frontends, una tipología de artefactos pensada para la interacción del usuario con la compañía. Aquí el equipo que se requiere es un equipo de front con un product owner especializado en entender al usuario, un perfil muy de UX. Muchas veces, el conocimiento de campo es importante, por lo que, encontrar un product owner que sea capaz de conectar con las necesidades del usuario es un punto clave para el éxito.

?      La última tipología de artefactos son las micro interfaces, que son un frontal que mediante la publicación de una API rest documentada permite a nuestro sistema conectarse con terceros. Típicamente suelo usar product owners en este punto puesto que las integraciones son bastante técnicas y establecen subconjunto mapeado de nuestro modelo, por lo que es preferible que este tipo de proyectos están liderados por un perfil de ingeniería técnica.

Esta forma de trabajar permite pivotar, es escalable en todos sus sentidos, permite dar prioridad a la digitalización de áreas de negocio en función de la oportunidad o el momento estratégico y sin duda es la que más se adecua a las necesidades reales de una empresa digital nativa.

Está claro que las empresas digitales nativas cada vez son más, y las no digitales cada vez son menos porque o se digitalizan o terminan muriendo por falta de competitividad. La digitalización no es un proceso de compra de software, es un proceso de transformación y renovación de los pilares de una compañía, unos pilares organizativos digitales que deben poner el software de la compañía en el eje estratégico de la misma forma que lo hacemos en las empresas digitales nativas.

Noticias Relacionadas: