Establece un récord mundial Guinness. Disfruta una web mejor

Parece un buen trato, ¿verdad? Todo lo que tienes que hacer es descargar Firefox 3 durante el Download Day para ayudar a establecer el récord del software con más descargas durante 24 horas - es así de fácil. No te estamos pidiendo que te tragues una espada o que mantengas en equilibrio 30 cucharas sobre tu cara, aunque eso también sería bastante impresionante.

La fecha oficial de la publicación de Firefox 3 es el 17 de junio de 2008. Únete a nuestra comunidad hoy.

En fin, considerando que esta nueva versión de Firefox trae muchas mejoras, no debería significar mayor problema ayudar a alcanzar este récord. Asi que todos a apuntarse

Sobre desarrollo de portlets…

Recibí un par de comentarios en mi primer post sobre portlets. Mi intención fue postear más seguido dicha secuencia de post, sin embargo, el tiempo (si, el famoso tiempo) no me permitió hacerlo.

Sin embargo, justo ahora estoy trabajando en el desarrollo de un portlet que emplea JSF. Asi que en cuanto salga del ajetreo en el que me encuentro (bueno, tengo 3 exposiciones este fin de semana) retomaré los posts sobre desarrollo de portlets.

Ah! No quiero dejar pasar la oportunidad de saludar a Daniel y Dennis por sus comentarios en dicho post.

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.