Errores al digitalizar que vimos de cerca (incluido uno mío)

Escribir sobre los errores de otros es fácil. Por eso este artículo incluye uno mío — y es el que probablemente te sirva más, porque explica por qué preguntamos ciertas cosas antes de escribir una sola línea de código.

Error 1: imponer la herramienta sin involucrar a quien la va a usar

Es el error que más he visto de cerca, y el más caro porque no se detecta hasta que el sistema ya está entregado.

El mecanismo es simple: cuando se impone una herramienta de la que no se conoce ni se entiende el fundamento ni los beneficios para quien la opera, esa herramienta se convierte en una tarea adicional al trabajo habitual. Y algo que se siente como carga extra, tarde o temprano, se deja de usar.

El reverso también es cierto, y por eso vale la pena. Si desde un principio se conoce el trabajo diario del equipo, y desde ahí se entienden y se proponen herramientas que reduzcan tiempos y esfuerzo, la nueva herramienta no se resiste: se espera.

Una plataforma que le quita trabajo a quien la usa no necesita convencer a nadie. Una que se lo agrega no se salva ni con capacitación.

Es la diferencia entre digitalizar sobre un equipo y digitalizar con él. De cómo se trabaja esa parte hablo en adopción: que tu equipo sí use la herramienta.

Error 2: dejar que todo dependa de una sola persona

Vi de cerca un caso con implicaciones fuertes dentro del equipo interno de desarrollo de una empresa. Con el tiempo, los intereses personales derivaron en una dependencia total hacia una persona que figuraba como propietaria de las plataformas. A su salida, se generó un caos: la empresa se quedó sin accesos de uso ni de administración de sus propios sistemas.

No lo cuento para señalar a nadie —esto se acomoda solo, sin mala intención de por medio, cuando nadie está vigilando el tema—. Lo cuento porque es un riesgo estructural que casi ninguna dirección revisa hasta que ya pasó.

La prevención es aburrida y barata: que los accesos estén a nombre de la empresa, que exista documentación del proceso y que recibas siempre los archivos necesarios para mantener tu sitio o plataforma publicada en cualquier hosting. Si eso no está garantizado, no importa qué tan bien funcione hoy tu sistema. Lo desarrollo en tu desarrollador desapareció.

Error 3 (mío): dar por hecho la infraestructura del cliente

Este me tocó aprenderlo en el proceso de desarrollo, y lo digo sin suavizarlo: diseñar desde la preferencia del desarrollador en vez de la realidad del cliente.

Como desarrollador uno busca implementar las soluciones más robustas y modernas disponibles. Es un instinto profesional legítimo. El problema es que la realidad del sector tecnológico varía muchísimo de región en región.

Mientras en mercados de primer mundo se asume infraestructura escalable, servidores privados o incluso plataformas serverless, en regiones como México muchas empresas disponen de presupuestos que solo alcanzan para servidores compartidos, como hace varios años. Y ahí no puedes ejecutar cualquier herramienta: tienes que buscar su máxima compatibilidad.

Si eso se descubre al final, el proyecto no se publica o cuesta el doble. Por eso hoy, antes de proponer nada, platicamos con el cliente —y con su equipo técnico, si existe— para conocer el alcance y las posibilidades reales de la empresa, e iniciar correctamente el desarrollo: partiendo de lo que se puede con lo que se tiene, y maximizando los resultados dentro de ese marco.

No es conformarse. Es que una plataforma brillante que tu empresa no puede alojar no le sirve a nadie.

Los tres, en una sola idea

Si los miras juntos, los tres errores son el mismo error con distinto disfraz: decidir desde el lado de quien construye, y no desde el lado de quien va a vivir con el resultado. El equipo que va a operarlo, la empresa que debe conservar el control, la infraestructura que tiene que sostenerlo.

Cómo lo evitamos por etapas

1. Hablar con quien va a usar el sistema, no solo con quien lo autoriza.
2. Revisar accesos y propiedad desde el día uno, no cuando alguien se va.
3. Conocer la infraestructura real antes de elegir tecnología.
4. Documentar del análisis a la operación, para que en cualquier momento se sepa en qué punto va el proyecto y qué queda pendiente.

Si estás por arrancar un proyecto o vienes de uno que salió mal, cuéntanos qué pasó y te decimos con franqueza dónde vemos el riesgo. Es un diagnóstico gratuito por WhatsApp.