Nota "1 + 1 = 10" - C
Si me equivoqué, pues, que me lo digan.
En todo desarrollo de un programa aplicativo está la posibilidad y la estadística dice que, en el 100% de los casos, tenga algún que otro problema, a veces son problemas menores, a veces problemas mas grandes y a veces problemas enormes que producen una re-codificación de partes.
El proceso evolutivo de un software es amplio, diverso y a mi me gusta mucho la frase de que “está vivo”, siempre hay algo para hacer, algo para mejorar, algo que cambiar, una nueva funcionalidad, siempre.
Pero al mismo tiempo, desde el dia “cero”, cuando ese programa es puesto en producción, los usuarios comienzan a descubrir esos errores, ausencias y demás, así que en paralelo con el lanzamiento con bombos y platillos del aplicativo, también en necesario un canal para recibir esos comentarios, sugerencias y feed-back del usuario final, en definitiva del motivador de que ese programa exista.
Algunos programadores muy experimentados, guardan logs al detectar un error, preparan una pantalla para que el usuario informe del problema, definen una casilla de correo para recibir mails, definen una persona que atiende los pedidos o reclamos de los clientes, quizás hasta un help desk y mucho mas, todo claro, dependiendo de la cantidad de usuarios que usen ese aplicativo.
Pensad ahora que debe hacer una empresa como Microsoft, donde un aplicativo como el SQL Server, que es usado por millones de personas en el mundo puede tener algún problema y que es necesario enterarse lo antes posible, para que se arregle cuando antes.
Y que decir, de aquellos problemas que aparecen en muchos lugares diferentes en el mundo. Pero como se puede recibir esos comentarios? Pues, desde hace tiempo existen casillas de correo para recibir mails con problemas, existen líneas de teléfonos asignadas a incidentes, existe una base de datos de conocimientos mundial montada sobre internet de consulta general, todo esto no es nuevo.
Lo que si es nuevo, es que recientemente están cambiando el perfil de la recepción de “incidentes” motivando que grupos de usuarios de un aplicativo, administradores expertos y usuarios con muchísima experiencia informe. Quizás debido a que reciben millones de reclamos de cosas casi triviales y solo algunos pocos de cosas realmente fundamentales.
He recibido un informe donde es posible participar enviando errores “complicados”, “de alta criticidad”, “bajos y feos” de un aplicativo como SQL, mediante un nuevo método que denomino, “convoquemos a especialistas”, incitando a especialistas de ese producto a que opinen.
Adjunto una copia de la invitación para que puedan ver el texto original.
Algunas cosas positivas que veo, es un especialista de un producto, sabe muy bien las cosas que suceden, sus errores, puede evaluar cuales son críticos, cuales no, cuales son problemas de otro tipo, cuales del propio producto, veo que utilizan parte del conocimiento de un experto en el producto para que informe de esos errores “feos y bajos”.
La parte negativa es justamente esa, están utilizando un recurso de una empresa para que les “filtren” los problemas que tiene el aplicativo, para que definan cual es , a su criterio, los que deben informar, y podría ser que la criticidad de millones de usuarios finales de un producto, es cambiada por unos pocos miles de administradores del mismo producto. En definitiva, esa política es mejor o peor.
A pensarlo.
En todo desarrollo de un programa aplicativo está la posibilidad y la estadística dice que, en el 100% de los casos, tenga algún que otro problema, a veces son problemas menores, a veces problemas mas grandes y a veces problemas enormes que producen una re-codificación de partes.
El proceso evolutivo de un software es amplio, diverso y a mi me gusta mucho la frase de que “está vivo”, siempre hay algo para hacer, algo para mejorar, algo que cambiar, una nueva funcionalidad, siempre.
Pero al mismo tiempo, desde el dia “cero”, cuando ese programa es puesto en producción, los usuarios comienzan a descubrir esos errores, ausencias y demás, así que en paralelo con el lanzamiento con bombos y platillos del aplicativo, también en necesario un canal para recibir esos comentarios, sugerencias y feed-back del usuario final, en definitiva del motivador de que ese programa exista.
Algunos programadores muy experimentados, guardan logs al detectar un error, preparan una pantalla para que el usuario informe del problema, definen una casilla de correo para recibir mails, definen una persona que atiende los pedidos o reclamos de los clientes, quizás hasta un help desk y mucho mas, todo claro, dependiendo de la cantidad de usuarios que usen ese aplicativo.
Pensad ahora que debe hacer una empresa como Microsoft, donde un aplicativo como el SQL Server, que es usado por millones de personas en el mundo puede tener algún problema y que es necesario enterarse lo antes posible, para que se arregle cuando antes.
Y que decir, de aquellos problemas que aparecen en muchos lugares diferentes en el mundo. Pero como se puede recibir esos comentarios? Pues, desde hace tiempo existen casillas de correo para recibir mails con problemas, existen líneas de teléfonos asignadas a incidentes, existe una base de datos de conocimientos mundial montada sobre internet de consulta general, todo esto no es nuevo.
Lo que si es nuevo, es que recientemente están cambiando el perfil de la recepción de “incidentes” motivando que grupos de usuarios de un aplicativo, administradores expertos y usuarios con muchísima experiencia informe. Quizás debido a que reciben millones de reclamos de cosas casi triviales y solo algunos pocos de cosas realmente fundamentales.
He recibido un informe donde es posible participar enviando errores “complicados”, “de alta criticidad”, “bajos y feos” de un aplicativo como SQL, mediante un nuevo método que denomino, “convoquemos a especialistas”, incitando a especialistas de ese producto a que opinen.
Adjunto una copia de la invitación para que puedan ver el texto original.
Algunas cosas positivas que veo, es un especialista de un producto, sabe muy bien las cosas que suceden, sus errores, puede evaluar cuales son críticos, cuales no, cuales son problemas de otro tipo, cuales del propio producto, veo que utilizan parte del conocimiento de un experto en el producto para que informe de esos errores “feos y bajos”.
La parte negativa es justamente esa, están utilizando un recurso de una empresa para que les “filtren” los problemas que tiene el aplicativo, para que definan cual es , a su criterio, los que deben informar, y podría ser que la criticidad de millones de usuarios finales de un producto, es cambiada por unos pocos miles de administradores del mismo producto. En definitiva, esa política es mejor o peor.
A pensarlo.
Comentarios