Una base de conocimiento para todos (primera parte)

 

 

 

 

 

 

 

 

 

 

 

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