Navegando una Modernización a Gran Escala con DDD

Hace aproximadamente un año, comenzamos un esfuerzo de modernización. Así que teníamos grandes planes y cuando comenzamos y presenté esta charla, soñaba con hablar sobre la historia de éxito. Pero desafortunadamente, resultó diferente. Hace solo un par de semanas, mi empleador y yo decidimos separarnos. No solo por lo que estoy contando aquí, pero aún así jugó un papel. Así que todo lo que puedo contarles son las lecciones aprendidas y lo que no se debe hacer.

Entonces, ¿cuál era el plan? Nuestro plan era comenzar con el diseño impulsado por dominio, un enfoque de diseño impulsado por dominio, y también inspirarnos en las topologías de equipos. Y una pieza importante también era que queríamos tener una pila tecnológica unificada o más uniforme. En resumen, ¿qué es el diseño impulsado por dominio y qué intentamos hacer con él? Como no tenemos mucho tiempo, en pocas palabras, el diseño impulsado por dominio se trata de construir software de acuerdo con el dominio empresarial. Diseñar su software de manera que esté alineado con su dominio empresarial, con lo que su negocio está haciendo. Lo que hicimos en el primer paso fue utilizar el diseño impulsado por dominio para reestructurar nuestra organización, encontrar los contextos delimitados dentro de nuestra organización y luego planificar nuestros equipos de producto a lo largo de esas líneas. Así que utilizamos algo como el evento de tormenta de ideas de la imagen general para encontrar todos los contextos delimitados y en general, este proceso fue relativamente sencillo. Entonces, al final, teníamos algunos contextos delimitados y teníamos un plan de cómo reorganizar nuestra organización y cómo estructurar nuestros equipos. Y para esto, también echamos un vistazo a las topologías de equipos. Y nuevamente, en resumen, las topologías de equipos se tratan de cuatro tipos fundamentales de equipos. En primer lugar, tenemos equipos alineados con el flujo, lo que probablemente conozcas como equipos de producto o equipos multifuncionales, y luego hay otros tipos como equipos habilitadores y equipos de subsistemas complicados y también un equipo de plataforma. Pero para nosotros, era importante encontrar los equipos alineados con el flujo y allí puedes ver otra diapositiva en el enfoque de las topologías de equipos. También hay diferentes formas en las que esos equipos pueden interactuar entre sí. Pero como dije, para nosotros era importante encontrar cómo utilizar el diseño impulsado por dominio para encontrar los contextos delimitados dentro de nuestro negocio y luego aplicar las reglas de las topologías de equipos o combinar esas dos cosas y tener equipos que tengan equipos eficientes que estén listos para trabajar en un contexto delimitado dado. Eso es todo en teoría, pero en la práctica, las cosas no fueron tan sencillas como esperábamos. Lo primero que se interpuso en nuestro camino fue la política de la empresa, porque queríamos reestructurar nuestra organización a lo largo de esos contextos delimitados. Pero, por supuesto, ya había personas liderando ciertos equipos y tal vez algunos equipos ya no existirían o estarían en una forma completamente diferente. Y, por supuesto, no todas las personas estaban contentas con esto. Y luego está también la realidad de la pila tecnológica actual, a la que no le dimos suficiente importancia. Entonces, nuestro objetivo era reestructurar nuestros equipos de producto. Pero tuvimos que tener en cuenta que la estructura actual del equipo estaba organizada en torno a proyectos, en torno a proyectos técnicos. Entonces, los otros equipos en nuestra nueva estructura, o nuestra nueva forma de estructurar nuestra empresa, no sabían exactamente cómo lidiar con todas las tecnologías involucradas en esos otros proyectos. Entonces, la primera gran lección aprendida aquí es que debemos asegurarnos de que todos tengan los mismos objetivos. Al menos que todos estén conscientes y compren la visión de los objetivos, de la reestructuración, por ejemplo, y que todas las personas también tengan la misma comprensión de los problemas actuales. Si hay realidades tecnológicas, no se puede simplemente reorganizar toda la empresa y cambiar todos los equipos sin tener en cuenta la tecnología actual que se está utilizando.

Entonces, después de eso, decidimos que era el momento de construir una nueva plataforma para nuestras aplicaciones web, porque también era un aspecto que queríamos mejorar. Queremos avanzar hacia una pila tecnológica moderna y unificada. Establecí un proceso RFC. Esto es algo que no teníamos antes. Escribí un documento y solicité comentarios sobre este documento. En teoría, creo que es una buena idea. Pero en la práctica, como veremos, no funcionó tan bien.

En este documento, resalté que queremos utilizar un enfoque de monorepo en el futuro y queremos usar Next en lugar de Laravel. Luego, todas las personas fueron invitadas a contribuir en este documento. En teoría, esto es una buena idea, pero en la práctica, no todos sabían en ese momento qué tan importantes serían las decisiones que se tomarían en este proceso RFC. En general, aún se sentía mucho como si yo estuviera dictando el futuro de la plataforma del mañana. Esto llevó a aprender la lección dos.

Las personas deben sentirse involucradas en la búsqueda de la solución para una nueva pila tecnológica, por ejemplo, o cualquier otro esfuerzo importante dentro de una empresa o un equipo. Debemos asegurarnos de que todos estén a bordo. Y como esto no siempre es posible, para aquellas personas que no están contentas con la solución, para aquellas personas a las que no puedes convencer de que tu idea es la mejor, al menos deben ser conscientes de que necesitan estar en desacuerdo pero comprometerse. Debes hacer que sea una práctica en tu empresa que todos se sientan escuchados. Pero, por supuesto, no puedes convencer a todos, pero aún así, las personas deben ser conscientes de que, al final, aunque estén en desacuerdo, deben comprometerse y hacer todo lo posible para que el nuevo proyecto tenga éxito.

Ok, este fue el proceso RFC para una nueva pila tecnológica. Y luego llegó el momento de construirlo. Así que vamos a construirlo, pensé. Y hubo otro problema. Prometí demasiado. Y, por supuesto, todo llevó mucho más tiempo. Para encontrar apoyo para este RFC, dije que no sería un gran problema. Podía hacer gran parte del trabajo y podíamos hacerlo a un lado. Entonces, al final, no sería un gran problema y todo sería fácil. Pero, por supuesto, no fue así. Todo llevó mucho más tiempo de lo previsto. Y los equipos no eran conscientes de que también necesitaban invertir tiempo en ello. Básicamente, todos estaban descontentos porque ya no había progreso.

Y esto nos lleva directamente a la lección tres. Debemos convencer a todos los interesados de por qué necesitamos hacer esto y por qué vale la pena invertir tiempo en ello. Y para convencer a todos los interesados, debes contar una historia convincente. Y después de contarla la primera vez, debes contar la historia nuevamente. Y debes contarla una y otra vez y otra vez. Y lo más importante, debes contar tu historia al equipo directivo. Y debes obtener su apoyo y convencer al equipo directivo. Y debes hacer esto no con promesas falsas como yo lo hice. Sino contando, presentando tu caso de que al final, será mejor para todos si invertimos tiempo en esta nueva pila tecnológica, por ejemplo.

Entonces, para resumir, la primera lección que aprendí fue asegurarme de que todos tengan los mismos objetivos. Y que todos estén a bordo y respalden esos objetivos. Y que todos tengan la misma comprensión de los problemas. Lección dos, las personas deben sentirse involucradas en la búsqueda de la solución. Entonces, para hacer esto, asegúrate de que todos estén a bordo. Y si alguien aún no está de acuerdo después de ser escuchado y presentar su caso, entonces debes asegurarte de que estén en desacuerdo pero comprometidos. Y lección tres, convencer a todos los interesados y contar repetidamente tu historia de por qué lo que quieres hacer, por qué esta gran refactorización tecnológica, por ejemplo, vale la pena al final.

Mi nombre es Markus Oberliner. Y si quieres hablar sobre lo que te conté hoy, para no repetir los mismos problemas, contáctame en Twitter o LinkedIn, por ejemplo. Y tal vez si te interesa testing y Vue.js, piensa en Mapbook.