Yo sólo ejecuto, no documento

Soy incapaz de recordar cuántas veces me ha comentado un técnico que su trabajo no es documentar sino ejecutar su parte técnica y esperar los resultados.

En realidad creo que el error no proviene en su totalidad del técnico, los que gestionamos su trabajo tenemos una gran responsabilidad ante ese problema. Un Jefe de equipo, Jefe de proyecto, Director o en el mejor de los casos la Oficina de Calidad debe dejar clara la forma de trabajo que hay que seguir, evidentemente basándose en una guía de buenas prácticas. Y esta forma de trabajo es válida para una empresa que se dedique a la Tecnología de la información o a una imprenta, un quiosco, una carnicería, etc.

Voy a describir, a grandes rasgos y sin entrar en muchos tecnicismos (si alguien quiere entrar en ellos hay mucha documentación al respecto), en lo que podría ser el trabajo de un técnico ante un cambio por un problema o por una petición del Cliente (el Cliente puede ser una empresa externa o nosotros mismos).

Nos basamos en la premisa de la existencia de un cambio que hay que realizar en un servidor.

1. Problema o cambio a petición del Cliente:
   1. Si se trata de un problema que nos ha comunicado el Cliente o hemos descubierto con nuestra monitorización (esperemos que sea el segundo caso), debemos abrir una incidencia con el problema en alguna aplicación que tengamos para estos temas (hay muchísimas gratuitas y muy buenas). Esto iniciará un escalado de la incidencia. También debemos comunicarlo al Jefe de equipo o Jefe de proyecto (además de la reunión de seguimiento semanal yo creo que es importante reunirse diez minutos al principio de cada día para repasar lo más importante).
   2. Si se trata de un cambio a petición del Cliente igualmente habrá que abrir un caso en la aplicación adecuada que seguirá también un escalado.
2. En ambos supuestos habrá que realizar una Mesa de cambios. Si el cambio es urgente, el comité de la Mesa de cambios deberá contar con personal específico para casos urgentes. Y si el cambio afecta a la Estrategia del servicio, el comité de la Mesa de cambios deberá contar con algún miembro de dirección. Además deberán estar las áreas afectadas del Servicio (técnicos, Jefes de proyecto, etc.). En esta Mesa de cambios se hablará del cambio a realizar. Se pondrán fechas para las ventanas de actuación en preproducción y producción (en los cambios urgentes serán fechas más ajustadas). Se hablará de la afectación del Servicio, de la documentación a realizar, de los técnicos de los procesos, los técnicos de guardia, de los gestores de los procesos y del responsable del cambio. De las personas que deberán ser avisadas antes, durante y después del cambio. De los costes e implicaciones en el negocio. Y un largo etcétera (aunque aquí sólo trataré el aspecto general, se puede encontrar mucha información en ITIL, en otras guías de buenas prácticas y como digo siempre en nuestro sentido común).
3. Suponemos que, después de la Mesa de cambios, todo el mundo sabe lo que tiene que hacer. Y todos los que deben intervenir de una forma u otra en el cambio deben documentar su parte o estar disponible para quién necesite documentar su actuación. El técnico debe investigar el cambio, documentarlo, realizar la hoja de ruta o por lo menos su parte (si depende de más de un técnico). Tener prevista y documentada una “marcha a tras” por si hay que deshacer el cambio. Deberá probarlo todo en un entorno de preproducción (pruebas). Documentar este paso y sacar conclusiones y tiempos de ejecución para incluirlos en la documentación del cambio final.
4. Ya estamos en la recta final. Sabemos que cambio hay que realizar y con qué tecnología (Diseño). Lo hemos probado en preproducción y ha funcionado correctamente (Transición). Y estamos preparados para ponerlo en producción (Operación). En este punto debemos poner en común todos estos avances (que podremos ir viendo en el escalado y documentación adjunta de la aplicación que hemos utilizado a tal efecto y a la que tendrán acceso todos los implicados. Esta aplicación deberá mandar correos a todos los implicados con los cambios que se van realizado y a las personas a las que se les vaya escalando la incidencia).
5. Llega el día del cambio y todo el mundo tiene claro su trabajo gracias a la Mesa de cambios, al seguimiento, al escalado de la aplicación de cambios, a las “mini reuniones” y a la documentación. Todos los implicados en el proceso deben tener clara la hoja de ruta (algunos estarán presentes y otros no, pero todos los implicados deberán estar con disponibilidad). Empezamos.
6. El responsable del cambio autorizará el inicio de la intervención y siguiendo la hoja de ruta debemos empezar por crear un Diario para ir documentando el cambio. Esto es necesario porque hasta ahora lo que tenemos es una planificación y unas pruebas realizadas en un entorno de preproducción, que por razones obvias de costes (y que además muchas veces no están suficientemente actualizados) no es idéntico al de producción y podríamos necesitar realizar pequeños cambios sobre la marcha que deben ser documentados.
7. Siguiendo con la hoja de ruta y después de crear el Diario para el cambio, habrá que avisar a todas las personas afectadas y mencionadas en la Mesa de cambio (a todos por correo y a algunos también por teléfono). Es importante no avisar a todo el mundo con el mismo correo, ya que habrá información “sensible” o incluso confusa sólo para algunos implicados.
8. Es ahora cuando el técnico o técnicos deberán realiza el cambio y no olvidarse de, por un lado seguir la documentación que tienen y la hoja de ruta y por otro lado ir documentando el Diario con lo que están haciendo.
9. Finaliza la intervención técnica y los técnicos levantan el servicio y lo comprueban (en este paso y aunque se levante el servicio, no se podrá acceder a él externamente). Si todo ha ido según lo previsto y funciona correctamente se avisan de su finalización y del estado de la misma a los responsables de los procesos. Si no funciona habrá que deshacer el cambio según la documentación. Esto implicará otra operativa.
10. Aunque hemos dado el visto bueno al cambio, nadie como el Cliente conoce su operación, por lo que necesitaremos que él pruebe y de el visto bueno al cambio. Normalmente se suele tener un grupo de confianza en el Cliente que realice esta función de prueba. Si todo está bien por parte del Cliente se notifica la finalización del la intervención, se cierra el diario y se actualiza la documentación existente. Y se cierra la incidencia en la aplicación destinada a este fin (la incidencia sólo se puede cerrar si el Cliente ha dado el visto bueno).

En definitiva y aun resumiéndolo mucho, el trabajo del técnico no consiste tan sólo en ejecutar y eso debemos tenerlo muy claro todos.