Nunca es fácil meterse a hacer cambios dentro de una administración, pero es mucho peor intentar cambiar cosas que ningún órgano de dirección te haya pedido. Esto suele darse cuando quieres hacer cambios para beneficiar (según tu criterio) en la manera como se realiza el trabajo.
No quiero generalizar cuando hablo de la administración. Hay muchas, de varios tipos y con gente muy diferente. Simplemente hablo desde la pequeña ventana que tengo hacia este mundo.
En mi caso, ya hace bastante tiempo que estoy convencido que aprovechar lecciones que nos dan metodologías, filosofías y tendencias en las TIC beneficiaría el modo en que ofreceremos los servicios. No creo que tengamos que volvernos unos fanáticos, pero sí que es necesario hacer cambios en la forma de pensar las cosas para dar la vuelta a ciertas situaciones, que sin querer, nos dejan atados de manos y pies.
En muchos aspectos, la administración es un buen lugar para aplicar metodologías adaptativas y en muchos casos la única forma viable para los proyectos. En mi caso llevo tiempo experimentando en el uso de metodologías ágiles y la filosofía de DevOps. Lo hago desde un puesto en el que no me es posible aplicarlo transversalmente a todo el área TIC, pero poco a poco he podido convencer a algunos compañeros y compañeras de diferentes divisiones (secciones) que adquieran estas prácticas. Eso aunque puede sonar bien, no nos deja en una situación demasiado cómoda para nadie.
En mi sección tenemos varias responsabilidades. Somos (teóricamente) el equipo de desarrollo, pero en un área TIC estructurada totalmente funcional. Con lo cual nos quedamos con la gestión de todo aquello que ponemos en marcha. Ya llevamos bastantes años trabajando y si queríamos seguir desarrollando la mayoría del tiempo, teníamos que abrazar filosofías que nos permitiese reducir al máximo el trabajo no planeado, repetitivo que no aportase valor.
En este momento, en nuestra sección gestionamos los proyectos relativamente grandes usando Scrum, y del resto intentamos gestionarlo mediante Kanban, sobretodo lo referente a incidencias y gestión del cambio. Tenemos incorporada la filosofía del testeo automatizado, documentar aquello relevante, compartir la información del trabajo que se esta realizando, CI/CD, checkings de seguridad automatizados, monitorización, etc. Con todo esto y con algunas técnicas más tenemos mayor capacidad para desarrollar nuevos proyectos. Pero este mismo salvavidas que nos permite flotar es también el que nos deja ahí tirados en medio del mar, ya que hemos optimizado una pequeña parte del servicio pero no se ha extendido al resto del área.
Esta forma de trabajar nos ha funcionado por la forma que tiene de distribuirse el área. La parte de operaciones se encarga del mantenimiento de la infraestructura (hw, virtualización, red y backup), pero no va más allà, ya que ellos también se hacen responsables de punta a punta de otros servicios TIC. Una vez nos han dado los recursos solicitados para desplegar el proyecto va de la mano de nuestro equipo mantener los servidores actualizados, seguros, monitorear cargas, gestionar BDs, establecer protocolos de recuperación, etc. Pasa lo mismo con el soporte al usuario de los servicios. Podemos decir que damos el soporte de nivel 2 del servicio (al que van incidencias desde nivel 1 con mucha facilidad), con lo cual nuestra mayor preocupación al poner en marcha los servicios es hacerlo de tal manera que lleguen las menos posibles. Aunque parezca obvio que esto debe ser así, no todo el mundo lo hace.
Trabajar así tiene sus ventajas e inconvenientes. Por ejemplo nos permite tener mucho feedback, tenemos más cerca al cliente, y tenemos en mente toda la cadena de valor, pero eso es porque casi toda pasa por nuestras manos. Para dar un servicio de calidad va muy bien, pero si vas a tener varios servicios gestionados de esta manera se va a saturar. Si no se controla se cae en ese trabajo que no queremos. Normalmente se empieza por distanciar más las actualizaciones de servicios, y a partir de ahí se entra en una espiral de trabajo no planeado, tareas más costosas, etc. Es muy fácil caer allí y muy difícil salir.
Ampliar el número de personas que hay en una sección (funcional) ayudaría, pero tampoco es el maná. Llegará un punto en que se tendrá divisiones completamente aisladas dentro del área TIC, donde no se aprovechan recursos que podrían ser fácilmente compartidos, donde la información quedará aislada, y los flujos de comunicación con otras divisiones debido a las dependencias (malditas dependencias) se resentirá. Además, es mucho más difícil y lenta la justificación de la necesidad de más personas en una sección en la que se tiene tareas de todo tipo sin que queden muy claros los perfiles, que si tenemos claros los puestos de trabajo que intervienen en la cadena de valor de los servicios, y está clara qué capacidad de trabajo y el nivel de ocupación tienen.
En el siguiente post explicaré cuáles son las reticencias que se presentan cuando se plantea extender las metodologías y filosofías de forma global al área TIC (y a la institución).
No hay comentarios:
Publicar un comentario