No somos raritos

Hay una idea bastante extendida sobre la informática que no ayuda a nadie. Se nos pinta como gente encerrada entre pantallas, hablando un idioma incomprensible y con poca capacidad para entender lo que pasa fuera del teclado. Es una caricatura cómoda, porque simplifica una profesión que, en realidad, tiene mucho menos de extraña y mucho más de disciplina, criterio y trabajo con personas.

Quienes hemos pasado años en este sector sabemos que la realidad es bastante distinta. Un buen profesional IT no vive aislado del negocio. Al contrario: pasa buena parte del tiempo intentando entenderlo. Escuchando. Preguntando. Traduciendo necesidades que a veces llegan mal formuladas, o mezcladas con urgencias, o con expectativas que no encajan con la realidad técnica, económica o operativa.

Y ahí está precisamente el valor. No en hacer magia. Sino en ordenar problemas complejos hasta que se puedan resolver.

La informática es mucho más humana de lo que parece

Cuando alguien piensa en informática, suele imaginar código, servidores, incidencias, despliegues o ciberseguridad. Todo eso existe, claro. Pero lo que no se ve desde fuera es que la parte más difícil casi nunca es tecnológica. Lo difícil suele estar en el contexto.

Un CIO lo sabe bien. También un responsable IT. Muchas veces no gestionan un problema, sino una suma de problemas: el ERP que no encaja con una nueva operativa, un proveedor que promete más de lo que puede entregar, usuarios que trabajan como pueden porque el sistema no acompaña, y dirección pidiendo resultados rápidos sin detenerse demasiado en las dependencias reales.

En ese escenario, el trabajo del equipo técnico no consiste solo en “hacer que funcione”. Consiste en entender qué significa realmente funcionar. Porque no es lo mismo que el sistema arranque a que el negocio opere bien. No es lo mismo que una integración pase en pruebas a que aguante el día a día con excepciones y cambios de última hora. Y no es lo mismo entregar una aplicación que entregar una solución útil.

El problema no suele ser la tecnología, sino la forma de plantearlo

Muchos proyectos empezar por la solución. “Necesitamos una app”. “Hace falta una integración”. “Hay que meter IA”. “Queremos automatizar esto”. Todo eso puede ser correcto o no. Depende de la pregunta de fondo.

Cuando una empresa trabaja con varios proveedores, el riesgo aumenta. Cada uno conoce su pieza, pero nadie tiene la foto completa. El integrador habla de su alcance. El proveedor del ERP dice que el problema no es suyo. El desarrollador externo avisa de que necesita especificaciones más claras. Y el equipo interno, en medio, intenta sostener la operación sin que el negocio se pare.

Ese es uno de los lugares donde de verdad se nota la experiencia. Un consultor tecnológico con oficio no se limita a tomar nota de lo que le piden. Detecta dónde está el hueco. Pregunta por el proceso real, no por el que aparece en el diagrama bonito. Comprueba qué pasa cuando hay un error, quién lo corrige, cuánto tarda en detectarse y qué coste operativo tiene. Porque muchas veces el proyecto no falla por falta de tecnología. Falla por haber ignorado el funcionamiento real.

Y eso se arregla arregla pensando mejor.

Lo que un CIO necesita no es un proveedor más

En muchas organizaciones, el responsable IT llega a una situación bastante conocida: demasiados interlocutores, poca claridad y una sensación constante de estar haciendo de coordinador de coordinadores. El proveedor de infra, el de aplicaciones, el de soporte, el de ciberseguridad, el de desarrollo a medida, el de licencias, el de analítica. Cada uno con su parte. Cada uno con su contrato. Cada uno con sus prioridades.

En teoría, eso debería dar flexibilidad. En la práctica, muchas veces no es asi.

El CIO termina recibiendo mensajes como estos: “Eso está fuera de alcance”, “eso lo tiene que ver el otro proveedor”, “el problema viene de la configuración”, “en nuestro sistema funciona bien”, “necesitamos una evolución aparte”. Y mientras tanto, el usuario sigue esperando. El negocio sigue buscando respuestas y la deuda operativa sigue creciendo.

Ahí es donde cambia la conversación. Porque un socio tecnológico útil no es el que hace muchas cosas. Es el que ayuda a reducir complejidad. El que entiende cómo encajar piezas distintas. El que no compite con el resto de proveedores por protagonismo, sino que trabaja para que todo encaje.

Eso requiere humildad. Y bastante experiencia.

Resolver problemas complejos no es improvisar bien

Hay una visión muy romántica del trabajo técnico, como si todo consistiera en encontrar soluciones brillantes. Pero la realidad es bastante más sobria. Resolver problemas complejos implica aceptar límites, priorizar bien y saber dónde merece la pena intervenir.

Un ejemplo muy habitual: una empresa quiere automatizar procesos internos porque “se pierde demasiado tiempo”. La petición parece clara. Pero cuando se analiza con calma, aparecen matices. Quizá el proceso está mal diseñado. Quizá hay demasiadas excepciones manuales. Quizá distintos departamentos llaman de la misma forma a cosas distintas. Quizá el verdadero problema no es la falta de automatización, sino la falta de un criterio común sobre cómo se trabaja.

Si uno se precipita, automatiza el caos. Y eso es peligrosamente caro. Porque digitalizar un mal proceso no lo mejora; solo lo vuelve más rápido y más difícil de corregir.

Por eso los profesionales con experiencia suelen insistir en hacer preguntas incómodas al principio. No para retrasar nada. Sino para evitar errores caros más adelante. Y no siempre gustan esas preguntas. A veces suenan poco “comerciales”. Pero son las que separan una solución sólida de una demo bonita.

La buena tecnología no se nota tanto

Cuando algo funciona bien, casi nadie habla de ello. Y eso, aunque parezca una obviedad, es una gran noticia. Que el usuario puede trabajar. Que el equipo de negocio no tiene que pelearse cada día con el sistema. Que los responsables IT no viven apagando incendios.

A veces el éxito de un proyecto no se mide en características, sino en tranquilidad. Menos incidencias. Menos dependencia de personas concretas. Menos llamadas improvisadas. Menos tareas repetitivas. Más visibilidad sobre lo que está pasando.

Eso también es resolver problemas complejos. No solo hacer software. Diseñar entornos donde las personas trabajen mejor.

Y aquí conviene romper otro cliché. La informática no es una disciplina asocial. De hecho, probablemente sea una de las profesiones donde más se depende de la capacidad para comunicar bien. Entender al cliente. Explicar un riesgo sin sonar alarmista. Decir que algo no conviene. Defender una arquitectura que simplifica el futuro, aunque no sea la opción más rápida hoy. Mantener conversaciones difíciles sin romper la confianza.

Eso no lo hace alguien raro. Lo hace un profesional serio.

Lo que realmente aporta un equipo informático maduro

Con los años, uno aprende que la diferencia entre un proveedor correcto y uno útil está en cómo se comporta cuando el proyecto se complica. Cuando aparecen dependencias. Cuando hay que integrar sistemas viejos con nuevos. Cuando el usuario cambia de criterio. Cuando el calendario aprieta. Cuando el presupuesto no da para todo. Cuando el problema real no es técnico, pero sí impacta en lo técnico.

Un equipo maduro no promete milagros. Tampoco se esconde detrás de la complejidad para no mojarse. Hace algo bastante más valioso: ayuda a pensar.

Ayuda a priorizar. A poner orden. A distinguir entre urgencia y relevancia. A decidir qué se puede resolver ahora, qué conviene dejar preparado y qué es mejor no tocar todavía. Y eso, en entornos con muchos proveedores, vale oro. Porque reduce problemas y devuelve capacidad de decisión al CIO y al responsable IT.

La informática bien hecha no va de excentricidades. Va de método, de escucha y de responsabilidad. Y sí, también de personas. Mucho más de lo que algunos imaginan.

No somos raritos. Somos gente que trabaja con problemas difíciles

Quizá la mejor forma de explicar esta profesión es esta: no nos dedicamos a la tecnología por la tecnología. Nos dedicamos a resolver problemas que, sin una buena base técnica, se vuelven lentos, caros o directamente inmanejables.

A veces eso implica escribir código. O diseñar una integración. O revisar procesos. O sentarse con varios proveedores y decir, con calma, qué encaja y qué no. O traducir una necesidad de negocio a una solución que se pueda sostener en el tiempo.

No tiene mucho de raro. Tiene mucho de oficio.

Y, sinceramente, también tiene bastante de sentido común.