Al hilo de un reciente estudio de Kaspersky “How IT security leaders can unlock the potential of their teams”: https://www.kaspersky.com/blog/it-security-economics-2020-part-4/, al que no viene mal echar un vistazo, y que básicamente habla de los motivos principales por los que los profesionales IT orientados a ciberseguridad se desgastan y cambian de trabajo, lo cuál se resume en: cargas de trabajo excesivas y actividades rutinarias.
Me parece interesante tratar el primero de los puntos, el correspondiente a las cargas de trabajo excesivas, ya que considero que es uno de esos problemas endémicos que parecen no tener una solución sencilla, especialmente aquí, en España.
Y es que por ejemplo en el informe anterior, se habla de PYMES dónde lo común es que haya un SOC dedicado, incluso con apoyo de fuera (subcontratación), es decir, un equipo de personas en la empresa dedicadas exclusivamente a seguridad informática, pero eso contrastado con la realidad de las pequeñas empresas de nuestro alrededor, difiere bastante, de modo que este SOC se traduce muchas veces en una única persona, que además se encarga de mil historias más en el centro de trabajo.
Es decir, es habitual encontrarnos con la típica persona que controla todo y de todo, responsable de comunicaciones, seguridad, redes, servidores, soporte a usuario, desarrollo software, y más y más historias. Os suena ese perfil?
Lo anterior tiene una cosa buena, que es además lo que más me gusta de mi trabajo habitual, el hecho de tener distintas y variadas tareas, y huir de rutinas y trabajos repetitivos (ese otro “pero” del informe Kaspersky), lo cual se traduce además en una constante adquisición de nuevos conocimientos y aprendizaje continuo.
Pero por otro lado, el problema subyacente de ese exceso de trabajo, responsabilidades y tareas de fondo, puede complicar, y mucho las cosas, y no sólo para la persona que las soporta, sino también para el buen funcionamiento de la empresa. Si una persona tiene 50 tareas asignadas en un momento dado, es imposible que por muy buena que sea, todas salgan con la máxima calidad, y que se preste atención a los detalles que al final, son los que marcan diferencia.
Lo peor de todo, haciendo referencia al título de la entrada, es que el modus operandi a veces se traduce en apagar fuegos de manera constante, y es que cada día puede generar una sorpresa: un incidente, un problema… que por urgencia pare las 50 tareas pendientes, y que por tanto haga imposible una planificación tan siquiera a largo plazo.
Por otro lado está el tema de las interrupciones típicas, esas que normalmente se lidian mejor en modo teletrabajo (https://ciberseguridadtotal.com/teletrabajo-reflexion-y-conclusiones/), y que en el día a día supone que cualquiera de las 50 tareas del ejemplo, termina teniendo decenas de cortes, lo cual se traduce de facto en desarrollos más largos (el típico te quitas para hacer esto otro, te pones, consigues coger el hilo del tema, te tienes que volver a quitar…) y en definitiva calidad de resultados, sobre todo por la imposibilidad de concentrarse y dar el 100% en algo concreto con el tiempo y tranquilidad adecuados.
En lo personal, la acumulación de trabajo puede generar otro tipo de inconvenientes, desde el típico estrés y cansancio, a según lo respetuosa de la empresa con la ley, la infinita acumulación de horas extras, que como es lógico, genera descontento y ganas de cambio de aires.
Como última reflexión, recuerdo leer hace ya tiempo (otra cosa es que sea verdad), que Apple apostaba para los proyectos importantes, por grupos pequeños de trabajo, es decir, por los mejores. Porque se entienda con un ejemplo sencillo, todos hemos visto personas más excepcionales que otras en el desarrollo de un trabajo, esas personas que en realidad parecen sacar el trabajo de 4 por sus capacidades, pues bien, Apple apostaba por equipos pequeños de este tipo de personas, prefiriendo tener a 10 tíos o tías así, que 50 normales. Y eso se consideraba como una ventaja competitiva, hasta que un día iOS salió con un importante bug, explicado por el insuficiente personal para ejecutar pruebas funcionales. Vamos, que se pasaron de cortos, por un lado está genial tener grupos pequeños de desarrollo, más unidos, con mejor feedback y comunicación, y además formados por los mejores, pero si calculamos mal, se producirá esa carga excesiva de trabajo que comentamos, y por tanto se traducirá en problemas igualmente.
Para rizar más el rizo, es importante notar otro apunte, quizá la solución más sencilla a estos problemas pueda parecer la contratación de más y más personal, pero esto no siempre es así, y los motivos pueden ser varios, por un lado el personal debe tener la cualificación suficiente, no es lo mismo contar con un desarrollador que lleva en tu empresa X años, que conoce todo al dedillo y que saca código como churros, a una persona recién contratada, que como es lógico necesita un tiempo para coger el hilo de todo. Además como hemos comentado, tampoco es igual comparar a una persona de esas excepcionales que sacan el trabajo de 4, a otra normal que siendo totalmente válida, posee otro nivel de rendimiento. En este sentido, además, otro motivo habitual de cambio de aires, son las rígidas tablas salariales, dónde esas personas excepcionales se ven encorsetadas en categorías inferiores a su rendimiento, con el consiguiente descontento, porque se entienda, 2 albañiles con la misma formación y categoría debieran ganar lo mismo, es lógico que sea así, pero si uno demuestra unas condiciones excepcionales y pone el doble de azulejo que el otro cada jornada, lo lógico también es que lo vea recompensado, o de otro modo o bien cambiará de trabajo a un lugar dónde si se reconozca, o bien decidirá no darse la paliza cada día adecuando su rendimiento a lo que es práctica normal.
En todo caso, creo que estos 4 simples consejos son más que válidos:
- La correcta gestión de los procesos de la empresa que permita tomar decisiones a tiempo, el saber si hay demasiada carga de trabajo, si es algo puntual, quién rinde más, quién tiene más tareas asignadas, qué perfiles son críticos en un proyecto concreto. Este conocimiento que parece obvio deba tenerse, pero que no siempre se tiene, o no se tiene con exactitud, ya que rara vez los responsables conocen lo que hay a bajo nivel.
- Valorar a las personas, en ocasiones no se valora el trabajo de alguien hasta que se marcha, dando como resultado cosas insólitas como descartar subir el salario a una persona, y luego terminar contratando 3 para suplirla.
- Evitar a toda costa el método apagafuegos salvo momentos excepcionales, y contar con los suficientes perfiles de apagafuegos para no quedarte sin plan B.
- Comunicación, es importante que haya comunicación en los grupos de trabajo, conocer aunque sea por encima las labores de los compañeros, tener grupos de trabajo unidos, y en definitiva aprovechar esa fortaleza normalmente asociada a startups aunque la empresa posea otro tipo de organización o tamaño.
