En uno de los proyectos en los que participé tuvimos que resolver un problema bastante común: los usuarios no completaban suficiente información en su perfil.

La aplicación era una plataforma de recursos humanos. Los candidatos rellenaban sus datos, experiencia, estudios y otra información relevante para poder inscribirse a ofertas de empleo.

El negocio era claro: conectar empresas que necesitaban talento con candidatos que buscaban trabajo.

El problema era que, si el usuario no completaba bien su perfil, las empresas no podían valorar correctamente a los candidatos.

Y si las empresas no podían valorar bien a los candidatos, los candidatos tenían menos opciones de avanzar en los procesos.

El problema afectaba tanto a las empresas como a los candidatos.

¿Por qué hacía falta cambiar?​

El problema no era solo visual ni técnico.

La aplicación pedía demasiada información al usuario y lo hacía en un momento delicado: cuando una persona está buscando trabajo, probablemente con poco tiempo, poca paciencia y, en algunos casos, poca soltura con herramientas digitales.

Rellenar un formulario enorme no era precisamente motivador.

Y para negocio, esa falta de información tenía un impacto directo: perfiles menos completos, candidaturas más pobres y menos valor para las empresas que buscaban talento.

El proyecto necesitaba un cambio a varios niveles:

• Técnico: Migramos una MPA a una SPA con Angular. Eso nos ayudó a ordenar mejor la arquitectura frontend, reutilizar componentes y construir una experiencia más fluida.
• Experiencia de usuario: Los usuarios no rellenaban demasiados datos y cuando se inscribían a las ofertas de las empresas eran insuficientes para valorar candidatos.

Por qué la gamificación encajaba en este caso​

La gamificación funcionó bastante bien.

El problema real era que el usuario tenía que rellenar mucha información y no percibía claramente qué ganaba a cambio.

Con el nuevo modelo, cada bloque completado tenía una consecuencia visible: el usuario subía de nivel, veía progreso y desbloqueaba herramientas.

Por ejemplo, cuando el usuario añadía sus datos básicos, alcanzaba el nivel 1 y aparecía una animación de progreso, algo parecido a un cohete despegando.

Ya no eran los formularios complejos y interminables.

Lo importante era que el usuario entendía que estaba avanzando.

A medida que el usuario subía de nivel, también desbloqueaba herramientas útiles.

Una de ellas era un constructor de CV.

A partir de los datos que ya había completado, podía generar un CV en PDF usando diferentes plantillas. Ese CV podía descargarlo o compartirlo directamente desde la plataforma al inscribirse en una oferta.

Había una recompensa real.

Además utilizábamos diferentes componentes como:

• Un flujo guiado con pequeños formularios en cada paso.
• Modales con animaciones de progreso.
• Secciones diferenciadas con niveles, algunas desactivadas (las no desbloqueadas) y otras listas para utilizar.

Fue uno de esos proyectos en los que disfrutas porque ves claramente cómo una decisión de producto cambia la forma en la que los usuarios interactúan con la aplicación.

Problemas de la gamificación​

No todo funcionó bien desde el principio.

Algunos usuarios no entendían el modelo de niveles. Otros no estaban acostumbrados a este tipo de experiencias o simplemente no querían “jugar” dentro de una aplicación de empleo.

Y esto es importante: lo que para un equipo de producto puede parecer claro, visual y motivador, para ciertos usuarios puede parecer confuso o innecesario.

También aparecieron problemas técnicos con algunos dispositivos y comportamientos que tuvimos que ajustar.

Tuvimos que iterar desde frontend y UX para que el modelo fuera más comprensible.

Dónde sí y dónde no​

La gamificación puede ser un recurso muy potente, pero no funciona en cualquier contexto.

Funciona cuando ayuda al usuario a entender su progreso, reduce la sensación de esfuerzo y ofrece una recompensa clara.

En este proyecto tenía sentido porque estábamos transformando una tarea pesada, completar un perfil, en un proceso más guiado, visual y progresivo.

Pero si estoy en la aplicación de mi banco y voy a pedir una hipoteca o estoy construyendo mi cartera de inversión no quiero eso.

Necesito que me transmita seguridad, transparencia y fiabilidad.

En cambio, cuando la gamificación sí tiene sentido, debería aportar fluidez, sensación de progreso y un punto de diversión, sobre todo si la tarea original es aburrida.

Hay que tener criterio para decidir cuándo la gamificación puede ayudar y cuándo puede jugar en nuestra contra.

Lo que aprendí​

A nivel técnico fue un proyecto muy interesante porque nos obligó a cuidar varias cosas:

• Animaciones: tenían que aportar sensación de progreso.
• Performance: cuantos más recursos visuales añades, más fácil es estropear la experiencia si no los controlas.
• Formularios: dividir un formulario grande en pasos pequeños ayudaba a reducir la sensación de esfuerzo.
• Arquitectura CSS: al tener una interfaz tan visual, necesitábamos una arquitectura de estilos más ordenada.
• Sistema de diseño: los niveles, estados bloqueados, pasos, modales y recompensas necesitaban consistencia.
• Arquitectura frontend: la migración a Angular nos permitió ordenar mejor la experiencia y construir componentes reutilizables.

Pero el aprendizaje más importante para mí no fue técnico.

Fue entender que, como frontend, no solo implementamos pantallas.

También participamos en decisiones que afectan al comportamiento del usuario, al negocio y a la experiencia real del producto.

Porque el usuario no va a rellenar veinte campos sin nada a cambio.

Al menos no durante mucho tiempo.

Mientras escribía los primeros posts del blog me di cuenta de que repetía algunos errores antes de publicar.

No eran errores enormes, pero sí lo bastante molestos como para hacerme perder tiempo revisando PRs, imágenes, estructura y detalles de estilo.

Esto me ralentizaba mucho a la hora de crear, revisar y modificar.

Antes de entrar en la solución, pongo un poco de contexto técnico sobre el blog.

Para dar más contexto cada post está escrito en archivos md que mediante el framework son convertidos a html, así que cualquier cambio pasa por el flujo normal de trabajo: commit, push y Pull Request.

El problema aquí es que muchas veces subía un post con algunos errores:

• Añadía el thumbnail pero no la imagen de cabecera.
• Algunas secciones eran demasiado largas.
• Algunas explicaciones técnicas no eran lo suficientemente profundas.
• En algún caso obviaba información que yo sí tenía pero el lector no.
• Alguna falta de ortografía o de puntuación.

Entonces pensé en una solución que pudiera ayudarme a revisar antes de mergear la PR: añadir IA a mi flujo de CI.

El flujo de CI con IA que había implementado al principio​

La implementación es bastante sencilla, pero ahí no está el valor.

El valor está en comprobar si esta automatización ayuda de verdad o si solo añade ruido al flujo de desarrollo.

Estoy utilizando GitHub Actions y la API de OpenAI.

El flujo en resumidas cuentas consiste en lo siguiente:

1. Detecta qué archivos han cambiado en la Pull Request.
2. Genera un diff reducido para no enviar información innecesaria a la IA.
3. Decide si merece la pena ejecutar la review o si puede saltarla.
4. OpenAI analiza posibles problemas y genera o actualiza un comentario en la PR.

Problemas que fui encontrando​

Aunque era útil para mi caso, también empezó a generar bastante ruido:

• Sugerencias discutibles.
• Comentarios redundantes.
• Cambios de estilo que no quería.
• Críticas técnicamente correctas pero irrelevantes.

A veces veía problemas donde no los había y otras veces no detectaba partes que sí eran importantes.

Uno de los problemas más curiosos fue el tono.

La IA empezaba a sugerir cambios técnicamente correctos pero que hacían que el texto sonara menos mío.

Eso me obligó a ajustar bastante el prompt.

Quería una revisión que mantuviera mi estilo y eso a día de hoy sigue siendo muy complicado.

Qué le pedí exactamente a la IA​

Una de las partes más importantes fue dejar claro qué quería revisar.

Aquí es donde me di cuenta de que tenía que separar dos comprobaciones y que hasta ahora lo estaba haciendo mal.

Antes estaba delegando toda la revisión a la IA.

Ahí me di cuenta de que estaba mezclando dos problemas distintos: validaciones objetivas y revisiones subjetivas.

Por un lado, las cosas objetivas:

• Si el post tenía imagen de portada.
• Si el post tenía tags.
• Si el post tenía descripción.

Por otro lado, las cosas más subjetivas y que merecían debate en la PR:

• Si el título y la descripción tenían sentido.
• Si alguna sección era demasiado larga.
• Si estaba dando por hecho contexto que el lector no tenía.
• Si el tono sonaba demasiado artificial.
• Si la implementación técnica tenía sentido (en el caso de algún post más técnico).

Esto cambió bastante el resultado.

Delegué a node las comprobaciones más objetivas y el resto a la IA.

La IA trabaja mejor cuando le damos contexto, límites claros y ejemplos concretos de lo que esperamos.

Cuando el prompt era demasiado abierto, la IA opinaba demasiado. Cuando definí mejor tanto el flujo como el prompt, empezó a ser más útil.

Cómo quedó el nuevo flujo​

Ejemplos reales​

Para dar algunos ejemplos de cómo está funcionando actualmente el flujo tenemos tres tipos de casos.

A veces hace recomendaciones que no aportan demasiado, pero tampoco me molestan especialmente.

Otras veces sí que aporta valor.

Por ejemplo, inicialmente había eliminado el diagrama del flujo porque me parecía innecesario. Después de esta sugerencia decidí volver a incluirlo porque probablemente ayuda a entender mejor cómo funciona la automatización.

Y otras veces simplemente no encuentra nada.

Conclusiones​

Tengo algunas conclusiones claras:

• Meter IA en un workflow no significa automáticamente mejorar el workflow.
• No todo necesita IA: Quizás algunas comprobaciones deban ser reglas simples y no una llamada a la IA.
• Hay que vigilar si la automatización está generando valor o solo ruido.

Por ejemplo, validar que un post tiene imagen de portada o que el frontmatter está completo probablemente no necesita OpenAI.

Eso puede resolverse con un script.

En cambio, revisar si una explicación se entiende, si el tono suena artificial o si estoy dando por hecho contexto que el lector no tiene, encaja mejor con una revisión asistida por IA.

Lo difícil es tener criterio suficiente para decidir:

• Qué automatizar.
• Qué ignorar.
• Y qué decisiones deberían seguir siendo humanas.

Automatizar una review es relativamente fácil. Saber qué merece una regla fija, qué merece una opinión y qué decisiones deben seguir siendo humanas es bastante más complicado.

En el proceso de creación de este blog me he encontrado con varios retos, uno de ellos ha sido la performance.

Cada vez que pasaba la web por PageSpeed, quería ver ese 100.

Y si no estaba… seguía tocando cosas, revisando el informe e intentando encontrar la solución.

Me di cuenta de que estaba perdiendo demasiado tiempo o mejor dicho: no invirtiéndolo donde tocaba.

Estoy usando Docusaurus, que de base está bastante optimizado.

Pero en cuanto empecé a personalizar:

• fuentes
• estilos
• imágenes

la puntuación empezó a bajar y ahí empezaron los problemas.

Esto me frenó bastante a la hora de tener el blog listo y empezar a publicar.

Ahí es cuando me di cuenta de que optimizar está bien pero si te empieza a frenar te puedes quedar estancado.

Para mí personalmente creo que fue la excusa perfecta para no publicar, para no exponerme al mundo real y quedarme en el lado cómodo para mí (el técnico).

Publicar implica:

• Que te lean.
• Que te juzguen.
• Que no guste.

Estaba enfocado en:

• Optimizar imágenes.
• Revisar CSS.
• Peleándome con fuentes.
• Buscando cómo subir unos puntos más en PageSpeed.

Todo con ayuda de IA, iterando rápido… pero sin avanzar en lo importante.

Entonces, ¿optimizar no importa?​

No digo que optimizar no sea necesario, es más, ahora hay que estar más atentos que nunca porque hay muchos casos que debemos tener en cuenta:

• Usuarios con mala conexión (metro, zonas rurales).
• Accesibilidad.
• SEO.

Pero no todo tiene el mismo impacto. No todo merece el mismo nivel de esfuerzo.

Por eso también estoy mirando otras señales, no solo PageSpeed.

Herramientas como GTmetrix o Vercel Speed Insights me dan otra visión del estado del blog, pero también estoy revisando métricas reales en Umami, como el bounce rate o la visit duration.

Si los usuarios pueden entrar, leer y navegar sin complicaciones, quizá el problema no es tan grave como parece en una puntuación aislada.

La regla que me llevo​

Si te enfrascas en cosas con poco impacto y alto coste, deja de compensar.

Dicho esto, prometo optimizar la web lo máximo posible con el tiempo.

Si he aprendido algo es que tengo claro que hay que optimizar con criterio:

1. Quiero optimizar para mis usuarios, no por sacar un 100 en PageSpeed.
2. Optimizar demasiado no puede frenar aportar valor (en mi caso es lo que quiero conseguir publicando).

Esto también es aplicable al código.

Si optimizar microsegundos:

• Retrasa una feature.
• O bloquea una entrega.

Probablemente no es buena idea.

Conclusión​

Primero se debe aportar, luego se debe optimizar.

Porque sin aportar:

• No hay usuarios.
• No hay feedback.
• No hay producto.

Me di cuenta de que no estaba construyendo. Estaba procrastinando técnicamente.

Este post va a ser un poco más técnico porque me gustaría hablar de un problema real que nos encontramos en un proyecto en el que trabajé.

La aplicación trataba de dar a usuarios técnicos y comerciales datos para tomar decisiones estratégicas y de negocio.

Al manejar muchos datos un buscador era casi imprescindible, teníamos un buscador bastante avanzado que no solo buscaba por el término introducido, sino también por términos relacionados y otros campos asociados.

Había un equipo que estaba preparando un LLM para la compañía y desde negocio vieron una buena oportunidad para integrarlo en nuestra aplicación, más concretamente desde el buscador.

Qué dudas se nos vinieron a la mente​

Para que tengáis una visión clara, el buscador avanzado era simplemente un input con un icono de lupa, al añadir este nuevo comportamiento desde diseño se opto por añadir un switch para que el usuario pudiera elegir que tipo de búsqueda quería, "avanzado" o con "IA".

Algo más o menos así:

Empezamos a pensar como podríamos integrarlo en nuestro buscador, pero empezamos a ver problemas porque tanto la búsqueda y como se mostraban los resultados eran totalmente diferentes.

A simple vista empezamos a notar que añadir la lógica entre medias de la implementación actual no iba a ser una buena idea.

La alternativa habría sido añadir condicionales dentro del buscador existente, mezclando comportamientos distintos en una misma pieza y aumentando el acoplamiento.

Si queríamos agregar todo este nuevo comportamiento a nuestro buscador debería cumplir con los siguientes requerimientos:

1. No afectar al comportamiento actual del buscador avanzado.
2. Que no estuviera acoplado al buscador avanzado y tuviera independencia de él.
3. Que las dos soluciones fueran mantenibles fácilmente.

Entonces vimos que la solución pasaba por separar comportamientos. Con el tiempo entendí que esta aproximación encaja bastante bien con lo que se conoce como el patrón strategy.

Implementación de la solución​

La idea central es tener varios comportamientos intercambiables detrás de una misma interfaz, y que el contexto (la selección del usuario) elija cuál usar sin meter condicionales por todo el flujo.

Vamos a hacer un pequeño esquema para entender mejor como planteamos la implementación:

En nuestro caso, la idea era mantener una base común para el buscador, maquetación, eventos y delegar las diferencias de comportamiento en estrategias separadas: búsqueda avanzada, búsqueda con IA, etc.

Tenemos los diferentes tipos de búsqueda con un enum y un type.

const SearchModes = {
  ADVANCED: "ADVANCED",
  AI: "AI",
} as const;

type SearchMode = (typeof SearchModes)[keyof typeof SearchModes];

Además un type para los componentes con diferentes estrategias.

type SearcherProps = {
  term: string;
};

type SearchStrategy = {
  Searcher: ComponentType<SearcherProps>;
};

Las diferentes estrategias:

const strategies: Record<SearchMode, SearchStrategy> = {
  [SearchModes.ADVANCED]: {
    Searcher: AdvancedSearch,
  },
  [SearchModes.AI]: {
    Searcher: AISearch,
  },
};

Con esto ya tendríamos la base para ir montando componentes.

Los componentes que vamos a utilizar son los siguientes:

1. InputSearch: Es el componente principal el cual está formado por un input y un switch en este caso para elegir la estrategia.
2. AdvancedSearch: que tiene la funcionalidad del buscador avanzado (llamada a una API, transformación de la data, manejar como se muestran los datos, etc.)
3. AISearch: que tiene la funcionalidad del buscador con IA (llamada a una API, transformación de la data, manejar como se muestran los datos, etc.)

en InputSearch el usuario decide el tipo de búsqueda, y en base a esa decisión el componente selecciona la estrategia adecuada.

De esta forma evitamos duplicar UI y mantenemos la responsabilidad clara: el componente principal orquesta las estrategias que definen el comportamiento.

export const InputSearch = () => {
  // Añadimos el modo, por defecto será el modo de búsqueda avanzada.
  const [mode, setMode] = useState<SearchMode>(SearchModes.ADVANCED);
  // El término es un string vacío hasta que el usuario añada algún valor.
  const [term, setTerm] = useState("");
  // Se obtiene el modo de búsqueda que ha elegido el usuario.
  const strategy = strategies[mode];
  // El componente Searcher con el comportamiento que queremos.
  const Searcher = strategy.Searcher;

  return (
    <section>
      <div>
        <Input
          placeholder="Buscar"
          value={term}
          onChange={(event) => setTerm(event.target.value)}
          // En un caso real, el switch estaría separado. Aquí lo simplifico para centrarme en la idea.
          onSwitch={(value) => setMode(value)}
        />
      </div>
      {/* Resultados de búsqueda */}
      <div>
       <Searcher term={term} />
      </div>
    </section>
  );
};

Componentes de búsqueda con IA y avanzado, los he simplificado al máximo para no añadir información innecesaria.

Pero la idea es que cada componente realice una llamada a un servicio, transforme datos, los muestre de una determinada manera y así su comportamiento queda encapsulado.

Llevado al caso real podrían mostrar diferentes tipos de resultados, podría ser que el buscador avanzado devolviera una lista de elementos y el buscador con IA devolviera otro tipo de estructura.

const AdvancedSearch = ({ term }: SearcherProps) => {
// Aquí podríamos llamar a un servicio, transformar datos, montar estructura de la respuesta en base a como muestra los resultados el buscador avanzado.
  return (
    <article className={styles.result}>
      <h3>Búsqueda avanzada</h3>
      <p>
        Resultados filtrados mediante el buscador avanzado para el término: <strong>{term}</strong>
      </p>
    </article>
  );
};

const AISearch = ({ term }: SearcherProps) => {
// Aquí podríamos llamar a un servicio, transformar datos, montar estructura de la respuesta en base a como muestra los resultados el buscador con IA.
  return (
    <article className={styles.result}>
      <h3>Búsqueda con IA</h3>
      <p>
         Resultados filtrados mediante el buscador con IA para el término: <strong>{term}</strong>
      </p>
    </article>
  );
};

Conclusión​

Cuando una nueva funcionalidad cambia mucho el comportamiento de una pieza existente, conviene parar antes de meter lógica “entre medias”. A veces la solución no es añadir más condicionales, sino separar responsabilidades.

En nuestro caso, añadir IA al buscador era un cambio de comportamiento. Mezclar ambas cosas en la misma implementación habría complicado el mantenimiento y aumentado el acoplamiento.

Separar los comportamientos nos permitió mantener una base común y establecer cada tipo de búsqueda de forma independiente.

Al final no se trata de aplicar patrones por aplicarlos, sino de llegar a soluciones que nos permitan:

• Mantener el código entendible cuando la aplicación crece.
• Evitar mezclar responsabilidades distintas entre componentes o partes de nuestra aplicación.
• Modificar o extender funcionalidades sin romper nada.

Hoy quiero hablar de algo que aprendes con la observación y de ciertos patrones que se dan en las empresas: la mayoría de aplicaciones nacen de un Excel.

Equipos de negocio, tecnología, ventas, diseño… da igual el área.
Si necesitan guardar datos, modificarlos, analizarlos, calcularlos o simplemente extraerlos, tarde o temprano acaban creando un Excel.

El problema empieza cuando ese Excel funciona.

Empieza a crecer y, con él, empiezan los problemas. Algunos de ellos son:

• Lo tocan muchas personas y nadie tiene claro qué permisos debería tener cada uno.
• Alguien borra algo que no debe o se pisan entre ellos.
• Aparecen versiones duplicadas en distintos equipos para cosas que podrían ser la misma información o, al menos, compartirse.

Por suerte, esto tiene solución.

Del Excel a la aplicación​

En la mayoría de los casos, alguien se da cuenta de que ese Excel tiene demasiada responsabilidad, mucho desorden y otros problemas asociados.

Suele pasar que algún responsable pide a IT una aplicación para cubrir esa necesidad. Entonces nace un proyecto, los product managers empiezan a definir una hoja de ruta y, después, diseño y desarrollo se suman al proceso.

En realidad, cualquier Excel es candidato a ser una aplicación (incluidos los míos)​

Como digo en el título de esta sección, cualquier Excel, hoja de cálculo o similar es candidato a ser transformado en una aplicación, siempre y cuando las necesidades lo justifiquen.

Te pongo dos ejemplos personales que utilizo a diario:

1. Mi Excel de cursos, libros y rutas de aprendizaje​

Es el Excel que utilizo para seguir aprendiendo, registrando cursos, libros y artículos que tengo pendientes o que ya he realizado.

Lo tengo todo clasificado por temas, estado (Sin empezar / En curso / Finalizado) y con detalles de cada recurso.
Es un Excel muy buen candidato y extrapolable a otras personas que quieran crear su ruta de aprendizaje u organizar sus cursos, documentos o artículos pendientes de leer.

2. Mi Excel de finanzas personales​

El clásico.
Una columna de “presupuesto”, otra de “gastado”, 12 columnas más para cada mes, filas con categorías y subcategorías: ocio → restaurantes, etc.

Me imagino que apps como Fintonic empezaron exactamente así: alguien con su Excel que decidió convertirlo en una aplicación con más funcionalidades.

¿Qué quiero transmitir con todo esto?​

Muy simple, y muy relacionado con estar alineados con negocio como desarrolladores:

Empieza a observar las necesidades de los demás y a tener una mentalidad de producto.

El Excel no es el problema. Es la señal.

Todas las personas, equipos y empresas tienen necesidades. Nuestro trabajo como desarrolladores no es solo crear algo que funcione, sino también acompañarles en el proceso de ideación, diseño de la solución e implementación.

Debemos ser capaces de acompañar al usuario desde lo que tiene en la cabeza hasta lo que realmente necesita. Y, para ello, es necesario pasar por todas las fases, incluso antes de escribir una sola línea de código.

Detectar la necesidad es más importante que construir la solución.

Además, esto no solo aplica a grandes empresas. Quizás la tienda de barrio de al lado de tu casa tenga también necesidades y, si en tu ciudad hay más tiendas así, es probable que compartan los mismos problemas.

Cuando empecé en el desarrollo de software, me obsesioné con aprender lo máximo posible a nivel técnico. Con el tiempo entendí que eso importa, pero también estaba ignorando algo igual de clave: el negocio.

Empecé a darme cuenta de que el negocio es una parte esencial para cualquier developer y, en realidad, para cualquiera que trabaje en tecnología. Van de la mano.

Si no entiendes el negocio, es probable que te estés perdiendo algo muy importante a la hora de escribir código.

¿Sabes de dónde sale tu salario?​

Si no puedes responder con claridad, no pasa nada.
Si estás empezando o trabajas en un proyecto donde la monetización es compleja, es normal.
A mí también me pasó.

Te cuento una situación que me hizo darme cuenta de la importancia de entender de dónde sale el salario.

Un proyecto sin entender el negocio​

Entré en una gran empresa española a través de una consultora y, el proyecto parecía interesante.

El cliente quería una aplicación web donde usuarios técnicos y comerciales pudieran añadir información operativa. Para mí, era algo extraño: una Wikipedia interna.

💸 ¿Esto iba a pagar el salario?

Sinceramente, no tenía clara la utilidad real de esa aplicación, incluso cuando empecé a picar código. No sabíamos qué problema real estábamos resolviendo.

El proyecto avanzó, añadimos funcionalidades y, cuando llegaron los stakeholders… quejas.
No era lo que esperaban.

Hablamos con ellos, hicimos algunos ajustes y el proyecto empezó a encaminarse.

Aquí fue donde cambió todo.

Mi jefe me dijo después que solo esos cambios costaron más de lo que muchos cobran en un año.

No fue un problema de nadie en concreto, sino de no entender bien el contexto desde el principio.

Cuando todos entendimos el negocio, se cometieron menos errores, se redujeron funcionalidades innecesarias y empezamos a generar más valor.

Esto no es infalible, pero cambia mucho la calidad y la dirección de un proyecto.

En tecnología, todo suele ser un caos: cambios de prioridades, visión sesgada, MVPs, salidas rápidas con deuda técnica.
Por eso es más importante que nunca conocer el negocio: te ahorra muchos errores y, sobre todo, mucho dinero.

¿Cuál era realmente el problema?​

El problema del cliente era simple, pero importante:
la información operativa no estaba centralizada.

Cada tienda tenía sus notas y sus propias fórmulas para cálculos.
Esto generaba caos, errores y un montón de tiempo perdido.

Una llamada típica:

— “Hola, ¿me puedes recordar cómo se calcula el importe de devolución en rebajas? He perdido la hoja.”

— “Sí, es el (precio_final × unidades) – descuentos adicionales”

— “Vale, gracias… espera, no me cuadra.”

Este tipo de llamadas pasaban muchas veces.

Entre dos personas: media hora perdida.

Pongamos que ocurría 2 veces a la semana.
52 semanas al año → más de 100 incidencias.
Multiplica eso por 1.000 tiendas:

cientos de miles de horas perdidas.

La Wikipedia interna fue mano de santo. El ahorro fue inmediato. La mejora en eficiencia, brutal.

Conclusión​

Entender el negocio es entender por qué haces lo que haces.

Y cuando lo entiendes, tomas mejores decisiones, construyes mejores productos y generas más valor.

Porque, al final, si no entiendes el negocio, es muy difícil entender de dónde sale tu salario.