En los procedimientos
administrativos que se han establecido para el control del desarrollo de
software en I-series Rpg y otras plataformas se han tomado en cuenta, en
general, al menos estos factores:
1.-Control de versiones de
programas
2.-Cumplimiento de cronogramas
3.-Matrices de prueba
4.-Certificación de pruebas
5.-Puesta en producción.
El énfasis se ha puesto en el
logro de los objetivos y en la puesta en
producción. Sin embargo, en cuanto a la medición de la gestión de los
incidentes diarios la mayoría de las organizaciones se ha quedado corta. Cuando
un usuario reporta un problema, el desarrollador a cargo de la aplicación registra en un formato de control de
incidente lo siguiente:
- La descripción del incidente realizada por el usuario.
- El tiempo en horas que se tomó para arreglarlo,
- Los programas, archivos, objetos y fuentes que fueron alterados y que hay que pasar a producción
- El resultado de las pruebas y su certificación.
- Un control de versiones estricto en el pase a producción. (Esto todavía no existe en muchas organizaciones)
Cuando se mira esta lista de registro del
incidente pareciera que es suficiente. Sin embargo, cuando otro desarrollador
debe realizar las funciones del informático que estaba a cargo de la aplicación
se encuentra con que no hay una base de
conocimiento que le permita acceder rápidamente a un registro histórico de los
problemas iguales o similares que fueron resueltos anteriormente y las acciones
concretas técnicas que se tomaron en ese
momento. Lo que está reflejado en esta documentación es escueto, con una
mención a nivel de “titulo” sobre los objetos y fuentes alterados, una
justificación del cambio y un tiempo de resolución. Nada que, sustancialmente
aporte algo significativo a quien técnicamente debe remangarse la camisa y
“hacer el trabajo sucio”.
El proceso para resolver el
problema se resume en contactar telefónicamente a quien se fue de vacaciones o
de la empresa, en revisar la documentación técnica que se tiene distribuida en
una o varias carpetas, en revisar con el usuario los correos que ha recibido o
enviado sobre el tema y finalmente en comenzar a ver el problema nuevamente
desde el principio, si es que no se puede esperar a que el programador encargado
regrese en algún momento.
En medio de la confusión
generalizada y del desconocimiento de lo que es el área de informática, se
espera que el desarrollador que queda encargado se haga cargo de la situación
rápidamente. Digamos que se trata al programador como al mecánico de turno que
debe reemplazar la bujía o el carburador de un automóvil. Algo así como quien
por saber desarrollar en una plataforma y en un lenguaje debe tener la
cosmo-visión omnisciente y todopoderosa del desarrollo de un producto
informático.
Considerando que el desarrollo
informático es:
- Un producto sujeto a un registro de propiedad intelectual.
- Un diseño realizado bajo un esquema único e irrepetible
- Adaptado a cada organización según sus necesidades de Parametrización y uso.
Debe
entenderse que NO es posible para ningún desarrollador, cualquiera que sea la
plataforma de su especialidad, resolver problema alguno sin el conocimiento
previo técnico del sistema.
Es necesario construir una base de
conocimientos compartida que esté automatizada que permita a un programador
registrar rigurosamente la manera como el incidente fue resuelto. Esta base de
conocimientos hace posible que
- Se resuelva rápidamente el incidente por cualquier persona de informática.
- Se mida la gestión de la gerencia de sistemas
- Se mejoren los procesos de control y seguimiento
- Se mejore la calidad de los sistemas
- Se aumente la satisfacción del usuario
- Se justifiquen los recursos del área de sistemas
Si diseñamos una plataforma
automatizada que permita registrar incidentes basándose en un formato diseñado
destinado al personal técnico en sistemas, es posible además, agregar
elementos estadísticos para medir la efectividad de una gestión informática en
un periodo de tiempo determinado.
Por ejemplo, si durante tres
meses observamos el mismo incidente repitiéndose, es necesario tomar alguna
acción que resuelva el problema de raíz. Esto indicaría además que quien
resuelve el problema lo esta controlando temporalmente pero no lo resuelve en
causas primarias por lo que el tiempo que utiliza en resolver una y otra vez el
mismo problema podría ser empleado en la resolución de nuevos requerimientos o
en la corrección de otras fallas. Esto
ampliaría el radio de acción del área de sistemas y alcanzaría mayores objetivos
para mejorar la dinámica del negocio.
¿Cómo
puede medirse una gestión sin llevar un registro automatizado de los
incidentes?
¿Cómo
puede mejorarse una gestión sin un control estadístico del comportamiento de
los incidentes entre varios periodos?
En la segunda parte de este
artículo continuaremos desarrollando este tema. Veremos el diseño y el
prototipo de un formato automatizado para los técnicos en sistemas y el
seguimiento de una gestión. Veremos los requisitos que debe cumplir una base de
conocimientos automatizada para que sea una herramienta útil en el control,
seguimiento y medición de la gestión del área de informática.
Si
te pareció interesante, reenvíalo a un amigo haciendo click en el sobrecito que
está al final del artículo. El conocimiento es valioso, compártelo.
Autor: Ing. Liliana Suárez
