Estoy en una Subdirección, realmente
es una División, con un gran volumen de usuarios y, por ende, somos
una unidad muy basada en la gestión. En muchas ocasiones disponemos
de poco tiempo para planificar y aplicar metodología, ya que las
circunstancias demasiadas veces nos obligan a trabajar en el día a
día sin mucho tiempo para pensar y analizar.
Sin embargo se está haciendo un
esfuerzo considerable por aplicar técnicas y normas de calidad sobre
todo a los desarrollos SW, aunque también al resto de áreas que
conforman la División.
Como consecuencia de este esfuerzo,
surgen los primeros resultados, y uno de ellos es la normalización
de peticiones de entornos de preproducción y producción.
Ciertamente me parece una buena iniciativa, ya que actualmente existe
bastante caos y es difícil conocer todos los entornos que
disponemos, quién es responsable de cada aplicación, así como los
requisitos que dichas aplicaciones tienen a nivel de sistemas.
No obstante, examinando en detalle el
procedimiento implementado para peticiones de nuevos entornos, creo
que hemos cometido algunos errores en su definición como
consecuencia de nuestra poca experiencia, y que debemos corregirlos
si no queremos que la calidad buscada se torne en burocracia.
Por ejemplo, en el formulario que hay
que rellenar para dicha solicitud existen demasiados campos que
atañen al rendimiento de las aplicaciones, entre otros: número
medio de usuarios concurrentes, tiempo de tramitación media por
usuario, criticidad de la aplicación y un sinfín más. Una vez
visto ese formulario, inevitablemente nace la pregunta de ¿por qué
es necesario rellenar información tan precisa y tan detallada? ¿Con
que objeto se solicita? La respuesta viene a ser algo parecido a: “Es
que de esta forma tenemos controlado cuáles son las demandas
necesarias por las aplicaciones en cuanto a rendimiento, criticidad,
etc. Y si algún día queremos ser proactivos y detectar cuellos de
botella o malos funcionamientos en los servidores que sustentan
dichas aplicaciones, es necesario tener información relativa para
obrar en consecuencia”.
El objetivo final de quien argumenta
este tipo de respuesta es muy lícito y su consecución, sin duda,
redundaría en una mejora considerable en calidad del servicio, pero
la forma de conseguirlo no es la propicia, ya que se crea burocracia
innecesaria.
Antes de pedir cierta información
hay que analizar para qué realmente se está solicitando y si va a
ser explotada de alguna forma concreta, porque de lo contrario es
mejor no pedirla.
Si se quiere ser proactivo, lo
primero es determinar qué métricas concretas vas a aplicar para
lograrlo y, una vez definidas, si necesitas alguna información
que no conoces pero te la puede facilitar alguna otra Área o Unidad,
en ese caso debes solicitar exclusivamente aquello que sea necesario
para poder aplicar la métrica definida. No tiene ningún sentido
pedir información que jamás va a ser utilizada o que atienda a
razones tan difusas como “por si acaso algún día…”.
Matizo que el orden es muy
importante, primero son las métricas a aplicar y posteriormente los
datos que se solicitan para poder ejecutarlas. Nunca al revés
porque si no entramos en el papeleo innecesario.
La cuestión planteada es un ejemplo
muy concreto y, por supuesto, no muestra de manera global un concepto
tan amplio como la calidad del SW. Sin embargo al igual que la
frontera entre el amor y el odio está bastante difuminada, este
ejemplo debe servir para ver lo cerca que en ocasiones se encuentran
la calidad del SW en cuanto a procedimientos se refiere, y la
burocracia en sí.
No hay comentarios:
Publicar un comentario