Año sabático para el blog

Por varios motivos, el principal de ello mejoras en la organización, voy a dejar en suspense el blog durante un tiempo. 

Serán unos meses o quizás hasta el verano del próximo año (tengo la costumbre de aprovechar los veranos para cambios importanes de organización)

¿Qué es más seguro, la nube o el servidor local?

Hoy hemos sufrido un percance con nuestra aplicación en la nube.  Voy a contarlo con la intención de plantear el tema de la seguridad.

El organismo encargado de los dominios .es ha sufrido hoy un problema técnico y durante algo más de una hora no se han resuelto bien sus DNS.  Como resultado algunos clientes no han podido entrar en nuestra aplicación en la nube.  Los que habían entrado antes, por ejemplo a primeras horas de la mañana, no han notado nada. Algunos incluso que lo han hecho durante la avería tampoco han tenido problemas.  Lo cierto es que algunos clientes han estado entorno a una hora sin poder ejecutar la aplicación.  

Como algunos dirán que es un problema de la nube y por eso ellos dirán que es más seguro un servidor local, voy a desmentirlos.

Nosotros llevamos algo más de 3 años funcionando en la nube.  En estos 3 años este es el tercer percance que afecta de forma generalizada a nuestros clientes durante más de 5 minutos.   Pongo ese límite de 5 minutos porque por cuestiones de mantenimiento es el límite que nos hemos puesto como admisible.  Esto es, 5 minutos sin funcionar y fuera del horario habitual.

El mayor de los percances fue en el verano de 2016.  El servidor principal sufrió una avería en la instalación de Linux y estuvo inoperativo casi dos horas.  La avería ocurrió entorno a las 7 de la mañana.

En resumen, debido a problemas de nuestras instalaciones en la nube llevamos acumulados unas 4-5 horas de inoperatividad en más de 3 años.   

A estos problemas generales hay que añadir que algunos clientes han tenido problemas locales de acceso a internet. También han ocurrido problemas con algunas zonas u operadoras.  

Estos problemas no hubieran ocurrido con una instalación local.  Así que más de uno dirá que es un argumento a favor de no usar la nube.

Pero ahora voy a hablar de los problemas en instalaciones locales.  En estos 3 años nuestros clientes han sufrido muchos percances en sus instalaciones.   Hace un mes un cliente de Madrid estuvo toda una mañana sin poder trabajar. El problema fue debido a un error de su servicio técnico que no se apercibió de que se había llenado el disco del servidor.  Fue detectado por nosotros, aunque en primera instancia pensaron que era un diagnóstico equivocado por nuestra parte.

Un cliente sufrió una inundación, que afectó a su servidor. Tuvieron que esperar a que se secara.  Resultado un día enterno inoperativo.

La lista de caída del suministro eléctrico es larga.  Se nos han dado dos casos curiosos. Ambos en clientes instalados en polígono industriales.   Gracias a tener la aplicación en la nube al quedarse sin electricidad pudieron seguir trabajando con sus portátiles o en otras instalaciones.  Concretamente uno trasladó dos personas a una cafetería cercana con wi-fi

La lista de anécdota me daría para un montón de artículos, pero la conclusión es clara.  La lista de averías en instalaciones locales es muy superior a la de averías en la nube.   Raro es nuestro cliente que con una instalación local no tiene más de 10 horas de inactividad en 3 años.

No he mentado el principal problema de las instalaciones locales, la pérdida de datos.  Aquí la diferencia es abrumadora. Cero percances con G4100v3 en la nube por más de diez en instalaciones locales.

Conclusión:  En la nube estás más seguro que con una instalación local. Tendrás menos horas de inactividad y más tranquilidad con los datos

Complicarse la vida a base de cosas sencillas

Recuerdo una aplicación de contabilidad de las que presumía como muchas de 'No hace falta saber contabilidad' y ser lo más sencillo del mundo.  He conocido muchas parecidas, que pretendiendo simplificar las cosas, complicaban la gestión de una empresa a unos niveles poco aceptables.  

Hay una frase atribuida a Einsteins (una más entre muchas, sí) que me gusta citar a menudo. Es más ya la he citado un par de veces en este blog.  La frase dice así:

Todo debe hacerse tan simple como sea posible, pero no más simple  

Y ahora voy a contar lo que pasó con ese programa de contabilidad.  Su 'facilidad', el motivo por el que no era necesario saber contabilidad, era que te salía un lista de asientos, decías lo que era y rellenabas unos datos, ¿sencillo? ¿no?  Pues no, veamos.

Vas a contabilizar un papel.  Te sale la lista de opciones y una de ellas tiene la leyenda 'Factura de compra con un único tipo de iva'. Guay, Lo eliges, te pregunta la base, el iva, el proveedor y todo listo.  Hasta aquí sencillo. 

De eso presumía un cliente que hicimos, antes de que lo captaramos.  Al poco tiempo presumía de que le habían incorporado un nuevo tipo de asiento que necesitaba: Facturas de gastos con retención.   Un poco después tenía otro tipo nuevo, la factura de gastos con dos tipos de iva y retención.  Pasó el tiempo y le pusieron otro tipo más y ...

Y a la tercera le vendimos nuestra aplicación.  Cuando se la instalamos me enseñó lo complicado que era meter un asiento en su programa fácil.  Tenías más de mil tipos de asientos 'fáciles'.

¿Ibas a meter fácilmente una factura recibida? Pues nada, eliges facturas de gastos (o de compras, hasta ahí vale) y luego ves una lista de casi un centenar de opciones, de tal gastos, sin iva , con varios ivas, con retención, con domiciliación, etc.

Total que para meter un asiento necesitaba media hora para elegir cual de los tipos fáciles era el correcto.

Tengo muchos más ejemplos.  Hay que buscar la sencillez al máximo.  Pero no más del máximo posible.

Prestaciones Chernobil

En cuanto te cuente dos cosas vas a entender el nombre de estas prestaciones.

Se trata de peticiones de clientes en las que nos dicen que la aplicación les haga algo más fácil, por ejemplo, no pedirle un dato o no obligarle a hacer algo de una manera y como consecuencia de esa petición... ¡algo puede explotar!

Chernobil es un pueblecito de Rusia en el que había una central nuclear.  A unos técnicos se les ocurrió pedirle a unos ingenieros que quitaran el apagado automático cuando ocurrían ciertas alarmas, para evitar que pasara en las pruebas. Los ingenieros le hicieron caso. Pusieron la nueva prestación y ... bueno, habrás oído lo que pasó

Desgraciadamente este tipo de pretaciones abundan.  Poder meter un artículo sin código, hacer un cobro sin indicar el medio de pago, quitar el aviso de que no se ha hecho la copia de seguridad, etc.  En resumen ahorrar un par de horas al mes a cambio de ocasionar problemas que te hacen perder veinte o más horas al mes.  A veces hay suerte y no ocurre nada, te ahorras esas veinte horas perdidas. Otras ocurre algo gordo y no son veinte sino doscientas las horas perdidas.

La idea que quiero transmitir es simple.  

Cuando queramos introducir una mejora en una aplicación informática de gestión hay que evitar que eso pueda acarrear consecuencias desastrosas.
 
 

Prestaciones tamagotchi

¿Os acordáis de lo que eran los tamagotchi?  Una especie de mascotas virtuales.  Nacieron a finales del siglo pasado y durante unos años estuvieron de modas. Era un aparatito electrónico que cabía sobradamente en la mano, con tres botones y una pantalla muy simple en blanco y negro. Luego hubo algunas variantes más o menos bonitas.

El aparatito presentaba en pantalla determinados mensajes que obligaban a hacer operaciones al que lo poseía.  A menudo era tirarse varios minutos moviendo los botones o haciendo algo parecido, en respuesta a los mensajes de pantallas.  La idea era que el tamagotchi te requería tu atención un montó de veces al día y te hacía perder un par de horas entre unas cosas y otras.

Y nada, la gente era feliz perdiendo un par de horas todos los días apretando botones para nada.

Comprenderás que yo le llame 'Prestaciones tamagotchi' a solicitudes de clientes que solo sirven para perder tiempo sin aportar nada.

Antes de entrar en detalle, un ejemplo

Un cliente nos pidió que en la introducción de líneas en albaranes el ordenador asignará el precio de tarifa y mostrará una información de precios al cliente por si se quería cambiar.  Le dijimos la posibilidad de que el ordenador aplicara directamente el precio con un criterio que le dijéramos.  Eso ya estaba previsto.  Lo que el pedía había que añadirlo.  Pero no, no lo convencimos.  Lo cierto es que lo que hacía es ver el precio de última venta al cliente y el precio de coste y escribir el primero de estos datos.   Pudimos comprobar que al cabo de un mes había escrito a mano varios miles de precios y que siempre se había aplicado el mismo criterio.  O sea, todos los días trabajaba un par de horas que el ordenador podía hacer solo sin intervención humana

Puede parecer raro.  Normalmente la gente pide cosas para trabajar más y el problema suele ser que ese trabajo que se ahorra genera problemas en el futuro.  el famoso pan de hoy y hambre para mañana. Típicamente nos piden que quitemos una condición en la introducción de datos que genera un problema a medio plazo. Pero claro a corto plazo ha ahorrado tiempo al meter los datos.  Pues bien, este problema que digo es al revés.

¿Y porqué quiere un cliente que la aplicación haga algo que le supone más trabajo y no sirve para nada?

Pues básicamente porque cree que sirve.   Y aquí distingo dos casos.

Uno es que se suele pensar que un operador humano hacer mejor una tarea que un ordenador, o de forma más segura.  Eso es cierto para algunas tareas pero es un error para otras.  ¿Piensas que puedes sumar 100 números mejor que una calculadora? A que no.

Y la segunda es algo más psicológico, la necesidad de sentirse útil y no perder protagonismo frente a la máquina.  

En ambos caso si queremos que nuestra empresa funcione bien lo que procede es actuar racionalmente y dejar a la máquina hacer lo que debe hacer.  De la misma forma que usamos carretillas para cargar palets debemos usar ordenadores para las tareas de los ordenadores.  Precisamente muchos errores se producen cuando hacemos algo que el ordenador puede hacer directamente. Por ejemplo contabilizar manualmente una factura. Eso no aporta control, sino confusión y posibilidades de error.

Los humanos tenemos muchas posibilidades y podamos aportar mucho. No es cuestión de perder el tiempo en tareas inútiles.

Así que ya sabes, si nos pides una prestación que solo sirve para perder tiempo, intentaremos quitartela de la cabeza.

Resolver problemas resueltos

Hace unas semanas tuvimos la queja de un cliente que llevaba varias llamadas para que le resolvieramos un problema: En la factura impresa faltaban unos datos en la cabecera.  Se quejaba de que era la quinta vez que llamaba y no se le resolvía el problema.

Ciertamente (casi acierta) era la cuarta vez en las que nos llamaba diciendo que faltaban datos en la cabecera de la factura impresa.

Lo malo es que ... que no faltaban datos en la cabecera.  En su momento pidió que se colocaran unos datos en el formato impreso (un segundo teléfono de la empresa) y se le colocaron de forma inmediata.

Sin embargo, como digo, tuvimos una llamada de queja y el cliente estaba ya desesperado porque después de varias llamadas decía que el problema seguía sin resolverse. Y el problema estaba resuelto.

Situaciones parecidas se suceden con asiduidad.  Nos reclaman la resolución de un problema que o bien no existe o bien ya está resuelto.  A menudo el servicio de soporte resuelve la confusión en el momento.  Pero hay casos, como el que he citado al comienzo, en que no es así y el 'problema' se alarga y no se consigue resolver (pese a que está resuelto).   He observado que en algunos casos el técnico encargado de soporte no era capaz de avanzar, supongo que confundido por tener que arregla algo que no falla.  

Preocupado por estos problemas inexistentes que se repiten constatemente. que consumen mucho tiempo y generan quejas y malestar he hecho unas breves notas que espero que ayuden a nuestros técnicos a afrontar el problema. 

No me refiero a una confusión que se resuelva en el momento sino a confusiones que se alargan en el tiempo y se repiten generando la sensación de un problema que no se resuelve pese a que no hay problema que resolver.

Por qué se dan avisos de problemas inexistentes.

Hay muchos motivos por los que nos llegan lo que podemos llamar falsas alarmas.  Un supuesto fallo que es una confusión.  Esto es lógico y para nada  preocupante.  Se trata de confusiones que entran dentro del servicio que debemos dar de atención al cliente.  Es habitual que un cliente se confunda y nos contacte.  ¡Para eso estamos!.

No voy a estudiar esas confusiones (ya lo hago en otros sitios de este blog) pero voy a enumerar un par de casos a modo de ejemplos.

'Un dato está mal'.  Son numerosos los casos en que recibimos un aviso de que el  programa 'suma mal' o da un resultado equivocado.  Como comprenderás el programa no suma mal.  Normalmente esto se resuelve acudiendo al informe que justifica el datos supuestamente erróneo.  Por lo general viendo este informe descubrimos el 'error'.

'Una funcionalidad ha desaparecido'.  En muchos casos porque no debe aparecer. Por ejemplo, se ha perdido el botón 'Contabilizar'. Sencillamente porque ya está contabilizado

Por qué se repite un problema inexistente

A menudo es un acto reflejo.  Ves algo raro y enseguida lo asocias con ese problema que te suena que ocurría.

El caso que enunciaba al comienzo era de estos.  El cliente imprimió una factura y el NIF del cilente salía en blanco.  Como unas semanas antes añadimos en el formato un segundo teléfono de la empresa asoció 'faltaba un dato' (el segundo telefóno de la empresa) con 'me falta algo' (el NIF del cliente). Asociación que derivó en 'Sigue sin salir bien la cabecera'.  Por cierto, el NIF del cliente no se imprimía ... porque no estaba puesto en su ficha.  Solo que era la cuarta vez que creía que faltaban datos sin que faltaran. 

Posiblemente el principal motivo por el que un problema se repite es ... que no se entendió bien.   Ya conté en una ocasión el caso que tuvimos de un cliente al que le fallaba la copia de seguridad en disquetes (sí, el caso es antiguo, vale) porque el disquete estaba sin formatear, otro día porque el disquete estaba lleno, otro porque no metía el disquete (sí, incluso eso llegó a pasar), otro día porque otra vez el disquete estaba lleno.  Total, que tras no me cuerdo cuantas confusiones el cliente estaba seguro de que 'no funcionaba el punto de copias de seguridad'.   De nada valía que aparecieran unos mensajes en castellano diciendo justo que el disquete estaba lleno.

Y, en segundo lugar de nuestro ranking de confusiones, el motivo por el que un problema se repite es ... porque es otro problema.  En algunos casos porque tiene alguna relación en otros sin tenerla.  Recuerdo una llamada de un cliente diciendo que el día de antes estuvo nuestro técnico arreglando una cosa y que había vuelto a fallar.  Lo que arregló el técnico el día anterior era una impresora.  Lo que había 'vuelto a fallar' era un monitor'.   Nunca supe porque al cliente le pareció que era la misma avería.

Tengo que añadir una culpa para nuestro servicio de soporte.  A veces el problema se repite porque no insistimo en aclararlo o porque no pensamos que un problema inexistente sea problema.  Hemos tenido algún técnico que pensaba que si un cliente llamaba varias veces para decir que algo que funcionaba bien no funcionaba no tenía que hacer nada, que su función se limitaba a comprobar que funcionaba bien.  Grave error.

 

Cómo resolver esos problemas inexistentes

Básicamente confirmando explícitamente con el cliente que está resuelto, muy claro y explícito y ... ¡comprobándolo al menos un par de veces!

Nuestro procedimientos obligan a confirmar y anotar como confirmado cuando un problema se repite y se da por resuelto.  Esto no evita las futuras confusiones pero ayuda bastante.