Una semana mejorando nuestro ERP: personas, pruebas y Docker

Mejorar nuestro ERP también empieza por las personas

Esta semana se ha incorporado un compañero con un perfil técnico cercano al mío, entre CTO y Tech Lead. Y es un tipo de incorporación que me gusta especialmente, porque no consiste solo en enseñar cómo funciona nuestro proyecto.

Cuando alguien acumula años de desarrollo, también trae una forma de pensar: decisiones que le salieron bien, otras que no repetiría, maneras diferentes de organizar un equipo y cierta facilidad para detectar cosas que los demás hemos normalizado.

En un onboarding solemos hablar de accesos, repositorios, documentación y entornos de desarrollo. Todo eso hace falta, por supuesto. Pero hay una parte bastante menos mecánica: explicar por qué hemos tomado determinadas decisiones y escuchar qué preguntas le surgen a quien acaba de llegar.

A veces esa persona te pregunta por qué un componente está organizado de una forma concreta. Tú empiezas a explicarlo, recuerdas una restricción que existía hace años y descubres que quizá ya no es tan relevante. Otras veces, al contrario, encuentras buenos motivos para conservar algo que desde fuera parecía extraño.

Cuando otra mirada nos obliga a pensar

Y ahí está lo interesante. No buscamos que alguien llegue para darnos la razón. Lo valioso es contar con otra mirada que nos obligue a explicar mejor lo que hacemos.

Además, compartir el espacio técnico de decisión también requiere práctica. Tener experiencia no significa tener siempre la mejor respuesta, y trabajar con otro perfil sénior es una buena ocasión para recordarlo.

El contexto de un ERP no cabe en un diagrama de arquitectura: hay procesos, reglas de negocio, clientes y años de pequeños ajustes detrás de muchas pantallas. Transmitir todo eso lleva tiempo. Para mejorar nuestro ERP, necesitamos que ese conocimiento circule entre más personas. Prefiero que el onboarding empiece con preguntas honestas antes que con la ficción de que en un par de días alguien puede conocerlo todo.

Lo que no aparece en el README

Mientras compartimos contexto, pienso bastante en todo lo que damos por supuesto cuando llevamos tiempo cerca de un proyecto. Sabemos qué módulo tocar, qué parte conviene dejar tranquila y a quién preguntar cuando aparece una duda. Es información útil, pero mucha de ella no está en el código ni en la documentación de instalación.

De hecho, una de las preguntas más difíciles de responder a una persona nueva no es «¿dónde está esta clase?», sino «¿qué necesito entender antes de modificar esto?». Puedes enseñarle el repositorio en una hora; transmitirle qué decisiones afectan al día a día del negocio es otro asunto.

Por eso me parece más práctico enseñar el sistema a través de sus recorridos reales: de dónde sale la información, qué decisiones se toman con ella y dónde termina. Cuando entiendes esos recorridos, la estructura del código empieza a tener sentido. Hacerlo al revés, enseñando primero carpetas y nombres de servicios, a menudo obliga a memorizar piezas sin comprender el conjunto.

También intento evitar otra trampa: llenar los primeros días de explicaciones. Una persona con experiencia necesita margen para explorar, formular hipótesis y volver con preguntas. Si todo el onboarding consiste en escuchar, perdemos una buena oportunidad de descubrir dónde nuestra propia explicación del sistema tiene agujeros.

No espero que dos perfiles técnicos coincidamos siempre. Espero que, cuando no coincidamos, sepamos argumentar las opciones y dejar clara la decisión. A la larga eso vale más que tener a todo el mundo asintiendo en una reunión.

Mejorar nuestro ERP con pruebas donde más hacen falta

La segunda parte de la semana ha estado centrada en algo menos visible, pero muy necesario: las pruebas.

Nuestro ERP lleva años evolucionando. Para mejorar nuestro ERP con cierta seguridad, debemos comprender las relaciones entre sus procesos. Un cambio pequeño puede tener consecuencias en otras áreas, no porque el software esté necesariamente mal, sino porque la lógica de negocio crece, aparecen dependencias y algunas relaciones dejan de ser evidentes cuando miras un archivo aislado.

Seguro que a más de uno le ha pasado: vas a modificar una condición o una consulta, entiendes perfectamente el problema que estás resolviendo y, aun así, antes de tocar nada te preguntas qué otra cosa podría verse afectada.

Esa duda no desaparece por tener más años de experiencia. En realidad, con el tiempo aprendes a tomártela más en serio.

Por eso, una de las formas más útiles de mejorar nuestro ERP está siendo incorporar pruebas de manera progresiva. No estamos intentando alcanzar un porcentaje de cobertura espectacular de un día para otro. Me interesa mucho más que una modificación en una regla de negocio importante deje detrás una comprobación que podamos repetir.

Proteger el comportamiento, no perseguir un porcentaje

Si corregimos un defecto, buscamos que su comprobación no dependa de recordar cómo se reproducía. En una refactorización, necesitamos saber qué comportamiento conservar. Y si una prueba falla, debería darnos información útil, no limitarse a aumentar un contador.

También hay un matiz que me parece importante: en software existente, primero hay que entender lo que hace el código y después decidir si ese comportamiento es el correcto. Una prueba de caracterización ayuda a detectar cambios inesperados, pero no convierte en buena una regla de negocio que ya estuviera equivocada.

Nos quedan partes difíciles de aislar, dependencias que no fueron diseñadas pensando en pruebas y decisiones que habrá que abordar con calma. No pasa nada. Me parece mejor empezar por los puntos que tocamos y por los riesgos que conocemos que esperar a tener tiempo para una refactorización total que probablemente nunca llegue. En este contexto, resulta útil la reflexión de Martin Fowler sobre cómo crear puntos de cambio en sistemas heredados.

Las pruebas también nos obligan a hablar de negocio

Hay una parte del testing que me parece especialmente valiosa y que no tiene que ver con herramientas ni frameworks: escribir una buena prueba obliga a concretar qué esperamos del sistema. Y eso, en un ERP, no siempre es tan sencillo como parece.

Pensemos en un cálculo que depende de varios estados, una excepción comercial o una operación que solo debe ejecutarse bajo determinadas condiciones. Antes de automatizar una comprobación tenemos que responder preguntas bastante humanas: ¿qué resultado es correcto?, ¿qué ocurre en el caso límite?, ¿qué hacemos si faltan datos?, ¿la excepción es una regla o un parche histórico?

Muchas veces la conversación que surge al intentar responderlas tiene tanto valor como la prueba que terminamos escribiendo. Mejorar nuestro ERP exige dejar atrás el «yo creo que funciona así» y empezar a definir comportamientos que podamos contrastar entre varios.

También hay que escoger bien qué dejamos fuera al principio. No todo merece un test unitario, no toda pantalla necesita automatización de extremo a extremo y no toda dependencia debe simularse. Me interesa una mezcla sensata: comprobaciones rápidas para reglas aisladas, integración donde las piezas se relacionan y validaciones de humo al desplegar.

Lo que quiero evitar es confundir movimiento con progreso: añadir decenas de pruebas poco útiles puede consumir tiempo sin darnos mucha seguridad. Prefiero pocas, relevantes y mantenibles, e ir ampliando desde ahí.

Que una pull request no sea un ejercicio de adivinación

En paralelo, hemos estado afinando el proceso de pull requests. Y aquí reconozco que tengo una debilidad: me gusta abrir una PR y entender en poco tiempo qué se ha querido resolver.

No siempre ocurre. A veces el título dice poco, el cambio toca demasiados archivos y te encuentras reconstruyendo la historia a partir del diff. Puede que el código esté bien, pero revisar así cuesta más de lo necesario.

Para mejorar nuestro ERP, también necesitamos que los cambios se entiendan. Estamos afinando ese punto sin convertir cada modificación en un documento interminable. Con unas pocas líneas suele bastar: qué problema había, por qué se ha elegido esta solución, cómo se ha comprobado y qué partes pueden verse afectadas.

También estamos prestando atención al tamaño de los cambios. Hay ocasiones en las que no puedes dividir una modificación sin complicarla artificialmente. Pero, cuando se puede, una PR pequeña es más fácil de entender y permite revisar mejor los detalles.

Una revisión útil es una conversación

Me interesa que la revisión no se reduzca a pulsar «Approve». Tampoco debería convertirse en una demostración de quién sabe más. La idea es revisar el trabajo, no examinar a la persona que lo hizo. La guía de GitHub sobre revisiones de pull requests recoge las opciones de comentar, aprobar o solicitar cambios; lo importante es que las utilicemos con criterio.

La llegada de un compañero nuevo encaja especialmente bien con esto. Las PR permiten conocer partes del producto, discutir decisiones y dejar contexto que más adelante agradeceremos. Al final, mejorar nuestro ERP a través de las revisiones también sirve para aprender unos de otros. En ese sentido, la revisión de código es otra forma de onboarding.

Y sí: a veces alguien te propone una solución mejor que la tuya. No debería ser una derrota, sino exactamente el motivo por el que revisamos el código entre varias personas.

Revisar la intención, no solo el diff

Hay una diferencia entre comprobar que un fragmento de código tiene sentido y comprender si realmente resuelve lo que debía resolver. En una PR podemos pasar mucho tiempo discutiendo nombres de variables y, sin querer, dejar en segundo plano la pregunta más importante: ¿este cambio respeta el comportamiento que necesita el negocio?

Por eso intento comenzar las revisiones por el contexto. Si sé cuál era el problema y cómo se ha validado, puedo leer el diff con otra perspectiva. También puedo detectar que faltaba un escenario, que una dependencia merece atención o que algo aparentemente inocente afectará al despliegue.

Me gusta que las observaciones tengan una explicación. «Yo lo habría hecho de otra manera» no ayuda demasiado si no cuenta por qué. En cambio, señalar que una alternativa simplifica las pruebas, reduce acoplamiento o facilita la recuperación ante errores abre una conversación útil.

Y hay algo que todavía cuesta en muchas organizaciones: aceptar que no todas las observaciones tienen la misma importancia. Un defecto funcional o un riesgo de datos merece detener la integración; una preferencia de estilo debería estar resuelta por convenciones o herramientas, no convertirse en una discusión interminable.

Si logramos que la revisión sea clara y respetuosa, se convierte en una rutina que mejora el producto sin desgastar al equipo. Ese equilibrio me parece mucho más importante que contar cuántos comentarios dejamos en cada PR.

Docker, servidores SUSE antiguos y el mundo fuera del portátil

La otra parte intensa de estos días ha estado en los despliegues. Hemos estado trabajando para ejecutar nuestro ERP en contenedores Docker sobre máquinas SUSE con bastante historia detrás.

Hay algo curioso en estos entornos: cualquier documento de despliegue parece muy sencillo hasta que te sientas delante del servidor real. Una cosa es arrancar el proyecto en una máquina de desarrollo actual y otra encontrarte con un sistema operativo antiguo, servicios que ya existen y decisiones de infraestructura que se tomaron en otro momento.

La contenerización nos ayuda mucho. Separar servicios, declarar dependencias y disponer de un despliegue más repetible es una mejora importante. Pero también nos ha recordado algo básico: Docker no borra las características del servidor anfitrión.

En Linux, los contenedores comparten el kernel del host. Por eso hay que comprobar compatibilidad, versiones soportadas, almacenamiento, permisos y redes. Si queremos mejorar nuestro ERP mediante contenedores, esas restricciones deben formar parte del plan. No todo se arregla cambiando una imagen ni añadiendo otra línea al archivo Compose. La documentación oficial de Docker sobre contenedores explica precisamente esta diferencia respecto a las máquinas virtuales.

También entra en juego lo que rodea a la aplicación: el proxy inverso, Apache cuando forma parte del entorno, las conexiones con la base de datos, la persistencia y los servicios con los que nuestro ERP necesita hablar.

Lo que Docker no hace por nosotros

Que un contenedor aparezca como «running» es una buena noticia, pero no significa que el despliegue esté terminado. Todavía falta comprobar que los procesos importantes funcionan, que los datos permanecen donde deben y que sabemos qué hacer si una actualización no sale como esperábamos.

Es precisamente ahí donde una operación aparentemente de infraestructura se convierte en trabajo de ingeniería del software: preparar el entorno, comprobar supuestos, documentar lo que hemos aprendido y hacer que la próxima instalación sea menos artesanal.

Tampoco quiero vender la idea de que Docker moderniza automáticamente cualquier servidor. Si el sistema anfitrión o alguna dependencia está fuera de soporte, el contenedor no elimina por arte de magia ese riesgo. Es una pieza útil dentro de un camino de evolución, no una solución universal.

Aun con estas limitaciones, veo en estos despliegues otra forma de mejorar nuestro ERP sin parar su evolución. No porque vayamos a tirar toda la infraestructura y empezar de cero, sino porque estamos ganando consistencia sin perder de vista que el negocio tiene que seguir funcionando.

La instalación no termina cuando aparece el estado «running»

Uno de los aprendizajes que más se repiten al desplegar software es que una aplicación puede arrancar perfectamente y seguir sin estar preparada para trabajar. El proceso está levantado, el puerto responde y, sin embargo, todavía quedan por comprobar los permisos, las rutas, las conexiones y los datos.

Con un servidor veterano hay que ser todavía más metódico. Antes de modificar nada conviene saber con qué versiones contamos y qué servicios están ya dando soporte a otras aplicaciones. Después, comprobar desde dónde se accede a cada componente: no es lo mismo una comunicación dentro de la red de contenedores que una conexión desde el host o desde un equipo externo.

La persistencia también merece su propia conversación. En desarrollo es fácil recrear un contenedor y empezar de cero; en producción, los datos no forman parte de ese experimento. Hay que saber qué se guarda, dónde se guarda, quién puede acceder y cómo lo recuperaríamos si algo falla.

El despliegue también necesita un plan de vuelta

A menudo hablamos de backup como si realizar una copia cerrara la cuestión. Para mí, el paso que realmente aporta tranquilidad es saber restaurarla. Y lo mismo ocurre con una actualización: tener preparado un camino de vuelta antes de necesitarlo suele ser bastante más barato que improvisarlo bajo presión.

No estamos buscando desplegar por desplegar. Queremos que el siguiente entorno se parezca al anterior en lo que debe parecerse, que las diferencias estén identificadas y que cualquier persona del equipo pueda comprobar el resultado. Eso requiere algo más de trabajo inicial, pero evita repetir las mismas sorpresas instalación tras instalación.

Además, no conviene confundir reproducibilidad con seguridad: un despliegue repetible también puede repetir una mala configuración. Las versiones soportadas, la exposición de servicios y los permisos siguen siendo decisiones que tenemos que revisar de forma explícita.

Los procedimientos que se agradecen cuando no estás tú

Toda esta parte de despliegue ha vuelto a sacar un tema que aparece una y otra vez en proyectos con recorrido: las instrucciones que viven solamente en la cabeza de alguien.

Puede ser una configuración específica de un cliente, una particularidad de una instalación o el orden exacto de unos pasos que una persona conoce porque ya los ha repetido muchas veces.

Ese conocimiento vale mucho. El problema llega cuando necesitamos que la misma persona esté disponible para todo.

Por eso también estamos dedicando tiempo a los procedimientos. Una manera muy práctica de mejorar nuestro ERP es reducir las instrucciones que solo conoce una persona. No queremos llenar carpetas de documentación que nadie vuelve a abrir; queremos dejar respuestas a preguntas concretas: qué requisitos tiene un despliegue, qué pasos hay que seguir, cómo comprobar que ha ido bien y cómo volver atrás si es necesario.

A mí me sirve una prueba muy sencilla: si otro compañero tiene que repetir el proceso dentro de un mes, ¿podrá hacerlo sin reconstruir una conversación por mensajes? Si la respuesta es no, todavía hay trabajo por hacer.

Y conviene mantener los documentos vivos. Un procedimiento que funcionó una vez y nunca se revisó puede generar tanta confusión como no tenerlo. La documentación es parte del trabajo, no la foto final de una tarea terminada.

Documentar el «por qué» evita volver a empezar la discusión

Algo que intento cuidar especialmente es la diferencia entre documentar un procedimiento y documentar una decisión. El primero explica qué pasos hay que seguir. La segunda cuenta qué alternativas valoramos, qué condicionantes teníamos y por qué elegimos un camino.

Ambas cosas son necesarias. Si solo documentamos los comandos, alguien podrá repetir una operación, pero quizá no sabrá cuándo ya no es adecuada. Si solo guardamos decisiones arquitectónicas, entenderemos las razones, pero tendremos que reconstruir los pasos prácticos cada vez que toque actuar.

Tampoco hace falta montar un sistema complicado. A veces bastan una página corta, una fecha, el contexto, la decisión y las consecuencias conocidas. Lo importante es que pueda encontrarse y que no se quede olvidada en una conversación o en un documento que nadie sabe dónde está.

Una buena señal de calidad de la documentación es que la utilice quien no la escribió. Cuando una persona nueva consigue seguir un procedimiento y señala un paso ambiguo, no está fallando el onboarding: nos está ayudando a mejorar una parte del sistema que antes dependía demasiado de nuestra memoria.

En el fondo, la documentación también se revisa. Igual que el código. Y probablemente esa sea la forma más realista de mantenerla útil: pequeña, cerca del trabajo cotidiano y abierta a correcciones.

Mejorar nuestro ERP también es construir confianza

Visto por separado, podríamos decir que hemos tenido una semana de onboarding, testing, revisión de código e infraestructura. Pero yo veo algo más sencillo: estamos intentando repartir mejor la confianza.

Esa confianza empieza cuando un compañero nuevo entiende por qué tomamos una decisión. Se refuerza al modificar una regla de negocio sin alterar otra por accidente. También la sentimos cuando una PR ofrece contexto suficiente para revisarla o cuando repetimos un despliegue sin depender de instrucciones que nadie había escrito.

Ninguna de esas mejoras funciona de manera aislada. Las pruebas no sustituyen una revisión cuidadosa. Las PR no arreglan una configuración de producción. Docker no conoce las reglas de negocio. Y los procedimientos no sirven de mucho si nadie los sigue ni los actualiza.

Pero cuando empiezan a trabajar juntas, ocurre algo interesante: dejamos de necesitar tantas explicaciones de última hora y tantas comprobaciones improvisadas.

No es que una persona deje de ser importante. Es que el equipo empieza a poder apoyarse más en el conocimiento compartido y menos en la memoria individual.

Compartir el liderazgo técnico no significa perder criterio

La incorporación de otro perfil con experiencia también me ha hecho pensar en cómo cambia el papel de quien lleva tiempo coordinando decisiones técnicas. A veces, sin darte cuenta, acabas siendo el punto por el que pasan demasiadas preguntas. No porque alguien lo haya diseñado así, sino porque resulta cómodo preguntar a quien conoce el contexto.

A corto plazo es eficiente. A largo plazo puede convertirse en un cuello de botella. Si cada detalle de arquitectura necesita la misma aprobación o cada duda termina en la misma persona, el equipo tiene menos espacio para crecer.

Compartir decisiones obliga a hacer algo que no siempre sale de forma automática: explicar tus criterios y aceptar que otros pueden llegar a conclusiones distintas. Para mejorar nuestro ERP, debemos distinguir dónde es importante mantener una línea común —por seguridad, compatibilidad o consistencia— y dónde merece la pena dejar libertad para probar una alternativa.

No veo el trabajo de un Tech Lead como tener la última palabra en cada conversación. Lo veo más como ayudar a que las decisiones importantes tengan contexto, se puedan discutir y, una vez tomadas, se lleven a la práctica con responsabilidad.

Y si un compañero encuentra una manera más sencilla de resolver un problema, la respuesta debería ser aprender de ello. Con un equipo experimentado, el objetivo no es defender una parcela técnica; es conseguir que el producto se beneficie de más de una cabeza pensando.

Mejorar nuestro ERP poco a poco es una decisión técnica

En proyectos grandes siempre existe la tentación de plantear un cambio total. Nuevo stack, arquitectura nueva, servidores nuevos y todas las buenas prácticas implantadas desde el primer día.

Sobre el papel puede quedar precioso. En la práctica hay usuarios trabajando, integraciones que no podemos interrumpir y un ERP que tiene que seguir resolviendo el trabajo de cada día.

Eso no significa resignarse a mantenerlo todo igual. Hace poco escribí sobre modernizar software sin perder lo que funciona, y esta semana he vuelto a pensar en esa misma idea: importa tanto elegir qué mejorar como decidir en qué orden hacerlo.

Es posible empezar por las pruebas de los módulos que estamos modificando, acompañar las PR con explicaciones útiles y documentar una instalación antes de automatizarla. Mientras tanto, podemos contenerizar componentes y preparar con tiempo las mejoras de infraestructura que requieren más planificación.

No todas las semanas se notará la diferencia. Algunas mejoras tardan en demostrar su valor. Se agradecen cuando aparece una regresión y la detectamos pronto, cuando alguien se incorpora y puede avanzar con menos ayuda o cuando repetimos un despliegue sin volver a resolver los mismos problemas.

Eso también tiene una cara menos cómoda: hay que comprobar si las medidas funcionan. Una plantilla que nadie rellena, una suite de tests que no cubre riesgos reales o un procedimiento obsoleto no son una victoria por el simple hecho de existir.

Cómo sabremos si realmente estamos trabajando mejor

Me gusta hablar de buenas prácticas, pero hay una pregunta incómoda que deberíamos hacernos más a menudo: ¿están cambiando algo de verdad o simplemente estamos añadiendo pasos al proceso?

Una plantilla de PR que nadie lee solo añade trabajo. Una batería de pruebas que falla de forma aleatoria puede acabar generando más desconfianza que seguridad. Y un despliegue con muchos automatismos, pero sin un modo claro de diagnosticar errores, también puede dejarnos vendidos.

No creo que debamos empezar creando un gran cuadro de mando para todo. Para saber si estamos consiguiendo mejorar nuestro ERP, podemos observar cosas mucho más cercanas: cuánto contexto necesita una revisión, cuántas veces repetimos la misma explicación, qué errores empiezan a detectarse antes de la entrega o si somos capaces de reproducir una instalación siguiendo el procedimiento.

Más adelante tendrá sentido medir tendencias con indicadores como el tiempo de revisión, los fallos introducidos por cambios o la capacidad de recuperación después de una incidencia. Pero prefiero utilizarlos para encontrar problemas y conversar sobre ellos, no como objetivos aislados que alguien tenga que maquillar.

También hay señales que no caben bien en una gráfica. Por ejemplo, que un compañero se anime a tocar un módulo porque entiende sus contratos. O que una discusión técnica termine con una decisión mejor documentada y sin dejar a nadie frustrado. Son cambios difíciles de cuantificar, pero muy fáciles de reconocer cuando empiezan a ocurrir.

Si dentro de unos meses las tareas rutinarias nos requieren menos improvisación y las decisiones importantes están mejor fundamentadas, para mí será una buena señal de que la dirección elegida tiene sentido.

Todavía estamos empezando

No quiero cerrar el artículo con la sensación de que hemos construido un proceso perfecto en unos días. No sería verdad.

Nos queda camino con las pruebas. Habrá PRs que podríamos haber explicado mejor. Tendremos que corregir y completar procedimientos. Y seguro que volveremos a encontrarnos con alguna peculiaridad en una instalación antigua.

Es normal. Después de años dedicándome a desarrollar software, cada vez tengo menos interés en presentar las cosas como si una metodología o una herramienta fueran a resolverlo todo.

Me interesa que, dentro de un tiempo, trabajar sobre nuestro ERP sea algo más sencillo. Detectar ciertos errores antes, entender un cambio sin llamar a quien lo escribió y desplegar una versión con menos improvisación serían señales bastante claras.

No necesitamos una gran cifra para empezar a observarlo. Basta con prestar atención a qué problemas se repiten y si vamos dejando de tropezar siempre con los mismos.

Una buena semana, aunque no haya grandes titulares

Si tuviera que resumir estos días, diría que hemos hecho trabajo poco vistoso, pero del que acaba notándose.

Esta semana hemos compartido contexto con alguien que llega con experiencia propia. Seguimos incorporando pruebas donde hacen falta garantías y pidiendo a las PR que expliquen mejor las decisiones. Además, avanzamos con Docker sobre una infraestructura que nos obliga a entender el entorno real, no solo el de nuestros portátiles.

Mejorar nuestro ERP no se resuelve en una semana, ni esto es una transformación completa o el final de ningún camino. Es una semana más intentando que nuestro ERP se mantenga y evolucione con menos sobresaltos.

A veces, cuando pensamos en modernizar software, nos vienen a la cabeza los frameworks y las arquitecturas. Y está bien. Pero esta semana me ha recordado que también se moderniza cuando compartimos mejor lo que sabemos, revisamos con más criterio y dejamos de depender de soluciones que solo una persona puede repetir.

La calidad del software no está solo en el código que entregamos. También está en cómo nos organizamos para entenderlo, cambiarlo y mantenerlo juntos.