Especificación…cación…cación…

El bendito documento funcional, aquel documento que puede llevar a un proyecto al fracaso o a un exito rotundo con minimas complicaciones.

En el proyecto en que me veo envuelto estaré dejando pendiente, por 10 días, unas funcionalidades que deberé atender para apoyar en otro proyecto. Sin embargo, me enfrento a un gran problema. Una de las funcionalidades que debo programar, no está bien especificada. Y el único que me puede guiar a través de esto es quien estuvo viendo esta funcionalidad.

Remitámonos a los hechos, en principio, cuando uno va a relevar a otro programador, muchas veces uno llega a encontrarse con un panorama completamente nuevo y desconocido para uno, respecto a lo que tal o cual funcionalidad debe o no debe hacer. Un programador no es un adivino y en su mayoría necesita de la especificación funcional para no desviarse del sendero correcto. El programador en sí, leerá el documento y programará lo que alli se encuentre escrito, ni más ni menos. Por lo tanto, es un gran error que el analista haga suposiciones respecto a como el programador entenderá el documento.

Es por estas razones, que definir claramente el documento de especificaciones funcionales cobra una gran importancia. Indicar detalladamente las pre-condiciones, post-condiciones y lógica de cada una de las funcionalidades a fin de que el programador se limite a hacer su trabajo.

Con esto no quiero decir que el proyecto esté libre de errores, pero si puedo asegurar que los disminuirá considerablemente.

Asi que ya sabes… si eres analista funcional, especifica bien!

Probando Bugzilla (primer intento… fallido)

Y bueno, al igual que Lennon, yo también estoy buscando probar un bugtracker.

Actualmente, estoy como parte de un equipo validador, asi que estamos siempre siguiendo el siguiente flujo:

1. Nuestro cliente prueba uno de los módulos, encuentra una observación y lo agrega en un archivo de excel.
2. Luego, uno de nosotros checka su archivo y lo copia a otro excel, el mismo que luego será visto por los programadores.
3. Cuando un programador, corrige una observación lo anota en otro archivo de “seguimiento”. Este archivo es visto por uno de nosotros y prueba la corrección. Si pasa, se cambia el estado de la observación, tanto en nuestros archivos  como en los del cliente.
4. Y entramos en un bucle…

Los problemas que trae consigo esta forma de “monitorear” las observaciones son:

• La concurrencia con los archivos hace que frecuentemente digamos “por favor, cierren el archivo de seguimiento”.
• Para obtener estadísticas, debemos armar manualmente las formulas en los archivos de excel. Lo cual consume tiempo.
• Si por “a o b” una observación es retirada de alguno de los archivos, corremos el riesgo de descuadrar la numeración que colocamos a cada una.
• El ser humano de por si, comete errores (una cifra erronea, volver a validar una corrección ya validada, falta de concordancia entre los archivos de observaciones y el de seguimiento, etc).

Es así que surge la necesidad de encontrar una herramienta que se adecúe a la necesidad que tenemos.

Por el momento Lennon ya probó con JTrac y ahora está probando con Mantis. El primero, hasta el momento me parece una herramienta muy interesante, porque es muy personalizable. Sin embargo, dicha iniciativa fue rechazada. La segunda, está aun siendo probada.

Por otra parte, me he comprometido en probar Bugzilla. Sería interesante recalcar, que originalmente esta herramienta no fue diseñada para usarse en ambientes Windows. Por lo que al seguir el tutorial que nos muestra como hacerlo, nos indican que algunas funcionalidades no estarán disponibles.

Asi que a pesar de seguir atentamente los pasos, mi primer intento ha fallado (tengo problemas con la instalación de los módulos PERL).

Sin embargo, volveré a intentarlo otra vez… (continuará)

Servicio enfocado en el usuario…

En la mayoría de casos, los egresados de las carreras técnicas se centran mucho en el lado tecnológico. La tecnología, hoy en día, nos brinda una serie de herramientas que pueden aportar grandes beneficios a las empresas, y porqué no decirlo, a la humanidad.

Sin embargo, esta no sirve mucho si nuestro enfoque no va orientado a la prestación de servicios de calidad.

Al contrario de lo que muchos piensen, la calidad es determinada por nuestros clientes (o sea, quien pone el dinero) y los que se benefician de esto son nuestros usuarios (o en otras palabras, quienes recibirán el servicio a diario).

Una situación que se presenta con mucha frecuencia es la siguiente: el técnico, cree que la tecnología lo es el todo y menosprecia al usuario por su, posible, escasa compresión de la misma, lo que finalmente conlleva a la prestación de un servicio deficiente. Por el otro lado, el usuario aprecia que el servicio que recibe no satisface sus necesidad y esto recae en quejas hacia el personal que presta el servicio o en casos extremos, al rompimiento de relaciones entre el cliente y el prestador de servicios.

Para evitar este tipo de situaciones, es importante, centrar nuestros esfuerzos en entender qué es lo que usuario realmente requiere. En muchos casos el “asumir” cosas nos lleva a un análisis pobre de la situación y, por ende, a entregar un servicio o un producto deficiente.

Para aclarar la figura, sería como ponernos en el papel de un doctor. Tenemos a nuestro paciente, el cuál se queja de tener un problema. Simplemente con escucharle no podemos, buenamente, recetarle un medicamento. Como medicos tendríamos que conocer al paciente, saber que problemas ha tenido antes, auscultarlo o pedirle que se realice análisis antes de emitir un diagnóstico y recetar algo.

De forma similar, como profesionales de TI nuestro enfoque debe estar en saber que es lo que pueda estar ocurriendo en la organización, cuáles son los procesos, cuáles son las necesidades u oportunidades de mejorar las condiciones de labor de los usuarios. Y sobre todo, recordar que es el usuario, y no nosotros, quienes conocen el “know-how” del negocio.

El nivel de calidad del servicio lo establece el cliente y el servicio de calidad lo recibe el usuario.

Diplomado en Administración de Proyectos TI

El día de ayer, empecé el diplomado en Administración de Proyectos TI en Cibertec. Este diplomado consta de 5 cursos:

• Gestión de la Innovación
• Gestión de  Servicios TI
• Dirección Estratégica
• Gestión de las Telecomunicaciones.
• Administración del Desarrollo Profesional

Actualmente, estamos llevando los dos primeros cursos junto con un “Taller de Informe”. Este último es para presentar un Informe acerca de nuestras prácticas o sobre el trabajo que estamos desempeñando. En la medida que el tiempo me lo permita, iré posteando algunas notas sobre los cursos.

Futbol acrobático… no, no es Shao Lin Soccer

Bueno, este post no va tan relacionado a la temática de mi blog; sin embargo, me pareció tan bueno este video que realmente quiero compartirlo con ustedes.

Yo pensaba que estas cosas solo las veía en Supercampeones o Shao Lin Soccer.