lunes, 7 de enero de 2013

La Caída del Sistema... o la Salida más Fácil

Las siguientes frases tienen algo en común:
  • Tu crédito lo está evaluando el comité. Aún no he tenido respuesta.
  • Tengo que validar esto con el negocio, para ver si es lo que se requiere.
  • El gobierno tiene tiene que tomar una decisión.
Básicamente, la existencia de dos conceptos intangibles como son "El Negocio", "El Comité" o "El Gobierno". Al final, detrás de estos conceptos hay personas. Personas que deben tomar decisiones y que, blindadas detrás de ese título, son casi siempre inaccesibles e inalcanzables. Ya he discutido este concepto antes, sin embargo, hace poco salió una notica en el diario que incorpora un concepto parecido.

sirenas

La noticia declara que en una prueba del sistema de alerta de maremoto de la II región, realizado el mes de Diciembre en Iquique, sólo 10 de las 41 sirenas dispuestas para ello, funcionaron. Adicionalmente, las sirenas sonaron varias veces en un periodo muy corto provocando desconcierto en la población y, obviamente, confusión.

El titular de la noticia decía "Falla en Software afectó sirenas y descoordinó simulacro". El concepto que aparece como culpable, nuevamente como un concepto etéreo, es el del Software que, en realidad, es el último eslabón de la cadena al que se le puede echar la culpa y, como los conceptos anteriores, no es nadie. Es algo culpable pero que a la vez no es nadie.

Leyendo las explicaciones de la falla, se declara como causa del problema el "desperfecto de un software que respalda el sistema operativo". Honestamente, no parece una explicación muy sensata. Alguien no hizo la pega, inventó una excusa que sonara compleja o el periodista no entendió nada. La computación, al igual que otras especialidades, tiene ese halo de complejidad que permite que las personas que no saben nada reciban cualquier explicación (verídica o no) y, al no comprenderla, la acepten. Por ejemplo, si un médico dice "la causa el eritema multiforme es una reacción alérgica a la proteína de la leche y que ha producido una lesión debido a una combinación de factores multisistémicos que han afectado la microvasculatura de la piel", honestamente, no hay mucho que discutir. En el software pasa lo mismo y, en el contexto de la noticia, suena convincente pero, para los que estamos vinculados a la tecnología, no suena razonable que el desperfecto se atribuya a un error en el software que respalda el sistema operativo. El respaldo, en particular del sistema operativo, es exitoso o no, pero no permite estados intermedios que permitan, por ejemplo, que funcionaran menos sirenas de las habilitadas.

Independiente de la falla o si la explicación es coherente o no, lo más importante de la noticia es el hecho de que se haya realizado una Prueba de Concepto. Básicamente, una Prueba de Concepto corresponde a la liberación, en ambientes controlados y lo más parecidos a los reales, de un sistema, modelo, idea, etc., para verificar su viabilidad u operación en la vida real. Es un paso muy importante en el desarrollo de nuevas ideas pero, también, en la evolución de sistemas existentes.

En el caso del software, un software que esté cumpliendo esta misión se denomina Beta y que, en términos simples, corresponde a un software que es liberado a una gran masa de personas para su uso. Las personas que lo usan se denomina Beta Testers y, habitualmente, son personas que reciben las versiones sin costo y/o a un precio reducido. A cambio de esto, al usar el sistema (porque, honestamente, ésta es la única manera de realmente depurar todos los errores de un sistema) la empresa que lo libera acelera el proceso de depuración y corrección de errores, para, finalmente, hacer el release oficial. Google, por ejemplo, mantuvo a Gmail con el atributo Beta desde el 2004 hasta el 2009, es decir, casi 5 años. El atributo Beta, en este contexto, actúa como un paraguas que anestesia las expectativas de los usuarios, es decir, las caídas en este ambiente son relativamente aceptadas y, más importante aún, invita a los usuarios a reportarlas con la intención de mejorar el producto. Lo importante en este proceso es, obviamente, procesar la información recibida y corregir los errores.

El momento para incluir a los usuarios finales en las Pruebas de Concepto dependerá del alcance, tamaño y especialización de la aplicación, producto y/o servicio a desarrollar, sin embargo, la recomendación es intentar hacerlo lo antes posible, tal como Eduardo Díaz exageraba la situación en su post  El Mejor Proceso de Desarrollo de Software, del blog La Naturaleza del Software (lectura obligatoria por cierto).

Por lo tanto, hay algunas recomendaciones que creo son importantes:
  1. Incorporar e involucrar a él(los) usuario(s) final(es) lo antes posible en el proceso de desarrollo. Si se puede, obviamente, llevar a cabo un proceso de desarrollo evolutivo, de prototipado rápido, etc., que permita mantener las expectativas alineadas.
  2. Ojalá, no aprovecharse de la incapacidad técnica del 99,9% de la población y entregar respuestas y/o justificaciones que correspondan con la realidad. Si el error es un absurdo, lamentablemente, hay que reconocerlo. Si no, mayor razón para explicarlo como corresponde.
  3. Realizar Pruebas de Concepto como parte del proceso de liberación de los productos, sistemas. No es una tarea fácil, habitualmente, pero está claro cuál sería el primer paso: agregue el apellido Beta al producto y establezca un canal claro y preciso para la comunicación de los errores.
Por último, la recomendación final, sólo aplicable al desarrollo de software, es, como lo deja entrever ligeramente Eduardo, contar con programadores que sepan programar. Y, esto, es mucho más que saber la sintaxis del código y/o poder hacer Copy&Paste desde Google.

No hay comentarios.: