No necesitas más normas, necesitas mejores
Cuando se publican ofertas de empleo nos plantean una realidad casi mágica: ambiente sano, flexibilidad, el país de la gominola con ríos de chocolate y sueldos tan altos que no solo te darás todos los caprichos, sino que además te sobrará dinero. Luego es cierto que para ser reponedor te piden tres idiomas, diez años de experiencia, un máster en logística, otro en gestión financiera y se valorarán conocimientos de jiu-jitsu. Es lo que tiene una tasa de paro tan alta: se puede exigir más de lo necesario porque habrá candidatos, aunque después se quejan de que faltan profesionales cualificados. Pero este es un melón que me gustaría abrir en otro momento.
Si eres de los que tu CV ha pasado todos los filtros de la IA, has aceptado las TAC, pasado el primer filtro online de preguntas y, tras cinco entrevistas, te han seleccionado, te das cuenta de que lo que te prometieron no es que sea exactamente mentira: es una proyección a futuro si consigues hacer tu trabajo correctamente. Porque ahora es más un objetivo a alcanzar que una realidad. Tu rol actual es de bombero: apagar fuego tras fuego y, si tienes tiempo, empezar a edificar la estructura que dé soporte a la idea que te vendieron en la descripción del puesto de trabajo.
Como vengo de tecnología, he apagado muchos marrones, he visto muchos protocolos y he visto cómo se empedraba todo el departamento de IT de normas y procedimientos. Estos principios básicos que os pongo, para mí, son la biblia:
• IT no es tecnología, es servicio.
• La herramienta no es lo importante, es el valor que genera.
• Todo se puede mejorar.
He visto fracasar proyectos porque la presión de la moda ha llevado a creer a muchos que el logo de SAP solventaría problemas que vienen de un lugar diferente, y donde el argumento principal es que se ha gastado X euros en la herramienta y no en qué valor nos va a generar.
Con estos caballos a muchos nos ha tocado arar. Afortunadamente, hemos encontrado el camino para alinear las inversiones —que no gastos— con los objetivos empresariales. Hemos de trabajar cada día para mejorar; podemos medirlo con SLA o cualquier otra métrica que creamos conveniente, pero que sea fiable y válida. Y sí, hay que medir todo lo importante, que no es lo mismo que medirlo todo.
En este camino de mejora hay varias normas que intentan guiar a los que nos hemos dedicado a esto, como pueden ser ITIL, FitSM, COBIT, y seguro que hay alguna ISO por ahí que intenta poner orden al maravilloso mundo entrópico que pueden ser los departamentos de tecnología.
Yo soy entrenador de baloncesto de formación y vivo en ese lugar que existe entre el juego libre y la necesidad de alguna norma. Creo firmemente que, al igual que con los niños, si impongo más normas de las necesarias voy a cortar el crecimiento del equipo, voy a cercenar el talento y, lo peor, se aburrirán y los convertiré en burócratas en vez de en agentes activos de la mejora.
Cuando eres capaz de encontrar las normas básicas que hacen que un equipo fluya sin meter muchas excepciones, tendrás algo dinámico, lleno de energía y con ganas. Y esto pasa por dos variables fundamentales: como responsable, has de perder tu ego y tu necesidad de control. Hay que dejar un espacio controlado para que, sabiendo qué normas existen, puedan buscar la mejor solución y proponer mejoras.
La segunda variable, una vez dejamos el ego, es formar a tu equipo. Has de inculcarles la necesidad de mejorar profesional y personalmente, tanto en las herramientas que usan como en las que podrían usar, pero, sobre todo, en las habilidades personales. Son profesionales de las herramientas tecnológicas, pero dan servicio y valor a personas. Si son unos expertos en código binario, APIs, JSON, Docker…, al final quien paga tu sueldo es una cadena de personas que empieza con el cliente, sigue con el comercial, el jefe de proyecto y acaba en ti. Muchas personas en el proceso, y de tu capacidad de mejorar no solo cómo te comunicas, sino cómo comprendes esta cadena, dependerá en gran parte tu progreso profesional.
Os hago una pregunta que no tiene nada que ver, pero como soy un hombre del Renacimiento y tengo más intereses que un préstamo bancario, ¿sabéis qué me dijo un director de un restaurante de esos en los que no sabes si eso es el precio o el teléfono cuando te llega la cuenta? Que prefería contratar a un camarero que no tenía ni idea de cuál era el tenedor de los caracoles, pero que sabía comunicarse con el comensal, que le hacía sentirse bien, especial, bien tratado y mimado, como si fuera el único cliente en todo el restaurante. Su razonamiento tenía su lógica.
Estos detalles —personas que se comunican con personas y cuyos objetivos personales están alineados con los del grupo, estos con los de la empresa, y que tienen como centro de todas las operaciones al cliente, sea interno o externo— marcan la diferencia.
Lo que me preocupa, y esto lo digo después de conocer muchos procesos, es que a veces escondemos la ineficacia en la burocracia. Las normativas han de ser claras, efectivas, protegernos y proteger, pero no convertirse en un muro contra el que tengamos que luchar, porque entonces estamos poniéndonos palos en las ruedas.
Los tickets de soporte se han de contestar en tiempo y forma; los errores recurrentes, solucionarlos. No se necesitan cuatro formularios para reportar. Que seas ingeniero informático no te impide usar un lenguaje llano y común para entenderte. Y, sobre todo, prohibido el “ya te contactaremos” y que el desdén se apodere de todos los procesos.
Por eso, sí, es bueno tener un bombero en la empresa para que apague fuegos, pero la idea es evitarlos. Y eso no se soluciona lanzando normativa si no hay un cambio cultural de arriba abajo.
Los protocolos no existen para complicar el trabajo, sino para que las personas puedan dar un mejor servicio sin depender del heroísmo ni del caos. Cuando los usamos con criterio, IT deja de apagar fuegos y empieza a aportar estabilidad, confianza y mejora continua. Porque al final, la tecnología no da valor por sí sola: lo dan las personas cuando los procesos les ayudan, en lugar de estorbarles.