lunes, 7 de noviembre de 2011

El Anillo del Rey

Hace algún tiempo atrás me encontré con una mujer que estaba desconsolada llorando en la cocina de la oficina. Si bien no eramos conocidos, no es una situación especialmente cómoda para nadie. Probablemente ella se sentía mucho más incómoda que todos los que andábamos por ahí también.

Sin querer entrar en detalles obviamente intenté animarla un poco. Después de tratar de decirle las cosas típicas (no te sientas mal, espero que no sea nada grave, etc., etc., etc.) y ver que no pasaba nada, me acordé de un cuento que había escuchado alguna vez y que me pareció era apropiado para la situación.

El cuento se llama El Anillo del Rey y, para los que no lo conocen, es una fábula respecto a cómo las cosas pasan, cómo la mayoría de las cosas en la vida no son permanentes y son pasajeras. Algo así como el tiempo de las Vacas Flacas y las Vacas Gordas, los ciclos económicos, etc. Mi intención, al contarle el cuento, era tratar de que no sintiera que su estado de ánimo iba a ser así para siemprea, que intentara concentrarse en lo que debería cambiar en el futuro cercano, etc. Sin embargo, ella me tenía una sorpresa.

Cuando llegué a la parte del cuento en que el rey está atrapado, abre el anillo y lee el mensaje, la miré con cara de curiosidad para ver si había logrado mi objetivo. Nos quedamos en silencio un momento… yo esperando su respuesta. Después de un rato me miró y me dijo:

- ¡Pero ya poh!… ¿Qué le pasó al rey?

Mi frustración fue grande después de su comentario. Obviamente me di cuenta que el problema era otro.

lunes, 31 de octubre de 2011

La Tranquilidad del Espíritu

Son muy pocas las personas que pueden vivir una vida sin preocupaciones económicas. Habitualmente, corresponden al grupo selecto de los millonarios que tienen sus necesidades básicas solucionadas y que, por lo tanto, pueden dedicarse a otras actividades sin preocuparse del día a día, de sus trabajos, etc. Para el resto de los mortales, una parte importante de la vida gira en torno la economía de la familia, del hogar, del país, etc.

Una vez que las necesidades básicas han sido relativamente solucionadas y gracias a todos los estímulos para consumir y las necesidades creadas del mercado, comienza el proceso de endeudamiento para lograr conseguir objetos, no siempre necesarios, pero si muy deseados. Ejemplos de estos son los televisores de más de 32”, los celulares y  las zapatillas de marca.

En este proceso, muchas personas están dispuestas a endeudarse para lograr comprar estos objetos. En algunos casos, el endeudamiento es por medio de los instrumentos de bancos tradicionales, sin embargo, para una parte importante de la población, el medio de endeudamiento es por medio de tarjetas de casas comerciales que están fuera de las reglas del sistema bancario tradicional y que se aprovechan de esta condición por medio de la aplicación de tasas que sobrepasan los límites establecidos, comisiones poco claras, seguros obligatorios, etc. Un ejemplo claro de esto es el caso de La Polar que explotó recientemente y las famosas repactaciones automáticas.

Este proceso, obviamente, no tiene fin: siempre habrá algo para comprar necesario o no y, por lo tanto, las reglas básicas para administrar un presupuesto, diferenciar los gastos necesarios de los superfluos, identificar la capacidad de ahorro, etc., son fundamentales para no cometer errores ni dejarse llevar por la tentación de las “tres cuotas precio contado”.

En un país en donde la comprensión de lectura y las matemáticas no son, precisamente, capacidades exigidas a la población, es necesario y casi imperioso, hacer algo para que las personas y las familias sepan y puedan administrar sus finanzas de manera correcta.

Al final de cuentas, el sobreendeudamiento, pone en riesgo la paz de las familias y de las personas y, salvo algunos supuestos, los gastos siempre pueden esperar. La máxima de comprar siempre al contado no es casualidad. Pero lo realmente importante, es darse cuenta que cualquier gasto no necesario que se postergue se puede convertir en un ahorro y, a la larga, no importa el monto del ahorro, lo importante es tener la capacidad de ahorrar algo. En términos simples, esto significa que los gastos son inferiores a los ingresos.

Relacionado con esto, el otro día escuché en la radio al hijo de Andrés Rillón hablando acerca de un curso que está dictando orientado a las personas y a las familias que quieren mejorar sus habilidades financieras. Es un curso que dicta en donde enseña las técnicas para administrar un presupuesto y tratar de ahorrar en vez de gastar. Por lo que explicó en la radio, el curso me parece una herramienta fundamental para las personas o familias que deseen seriamente mejorar sus capacidades financieras y aprender a vivir con lo que se tiene sin endeudarse. El curso se dicta esporádicamente y para acceder al curso se debe enviar un mail a librededeuda.cl@gmail.com consultando los horarios, ubicaciones, etc.

Para una persona que esté realmente angustiada por estos temas, el mail ya debiera producir cierta esperanza de poder superar el problema.

domingo, 23 de octubre de 2011

La Olla Destapada

En los últimos meses, la crisis provocada por la estafa de La Polar ha remecido y demostrado varias de las estructuras económicas de Chile: las AFP´s, la bolsa, el sistema bancario y las tarjetas de crédito, las multitiendas y sus tarjetas de crédito, Dicom, etc.

En una economía en donde está todo relacionado e interconectado, es obvio que esto iba a producir efectos en diversos ámbitos del país.

  • Caída de las acciones de La Polar. Una de las “vedettes” de la bolsa de comercio, un referente del sector retail. En menos de un día perdió el 80% de su valor bursátil y, de la mano de esto, arrastró a varias acciones similares.
  • Pérdida en las Fondos de Pensiones. Como resultado de lo anterior y dada la proporción de inversión que realizan las AFP´s en estos instrumentos, todos los fondos se vieron afectados en alguna medida, perjudicando a aquellas personas cercanas a su jubilación.
  • Revisión del Sistema de Tarjetas y Comisiones. Para evitar repetir un problema similar, el SERNAC anunció la revisión del sistema de tarjetas y la próxima creación de mecanismos de regulación de estos instrumentos con, por ejemplo, limitaciones de la tasa máxima convencional aplicable, revisión de los cobros de mantención y otros cobros similares.
  • Revisión de los Contratos. Alineado con el punto anterior, surge la necesidad de revisar los contratos de las empresas con sus clientes y eliminar y/o corregir las cláusulas abusivas vinculadas al servicio prestado y los incumplimientos.

Respecto al tema de los contratos, después de la revisión realizada, las conclusiones son obvias: todos los incumplimientos por parte de los contratantes están estipulados con plazos, tasas, multas, etc., sin embargo, no hay casi indicaciones ni cláusulas que hagan mención a incumplimientos por parte de las empresas que proveen el servicio. Como resultado de esto, por ejemplo, hace unos días se modificó un aviso de la radio sobre la última promoción para contratar el servicio de TV Cable, Internet y Telefonía en una empresa determinada. La modificación ha sido la incorporación de una frase al final del aviso del tipo: “El servicio XXX de YYY Megas tiene una velocidad máxima de YYY Megas bajo condiciones ZZZ y en ubicaciones en donde lo permitan las condiciones técnicas”.

A pesar de que el aviso hace sentido y “resuelve” en parte el problema, permitiendo a las empresas anticiparse a la principal característica del servicio prestado:

¿Es necesario que se destape una olla de este tipo para que el sistema se de cuenta que se debe privilegiar y honrar la relación entre empresa y cliente en ambos sentidos?

¿Es necesario que los clientes permanentemente estén preocupados y revisando la publicidad, los contratos y las especificaciones de los servicios ofrecidos sólo para asegurarse que no están siendo víctimas de publicidad engañosa?

Otro ejemplo típico de esta relación asimétrica. es lo que ocurre en los estacionamientos en donde, típicamente, hay un letrero que desliga de cualquier responsabilidad al comercio de cualquier cosa que pueda sucederle a los autos ahí estacionados. Por suerte ya han habido fallos que regulan en cierta medida esta situación (ver NOTICIA en el SERNAC).

En el largo plazo y en la medida que las acciones tomadas por las autoridades y las instituciones sean correctas, este tipo de situaciones sólo debieran producir una corrección y un estadio superior en el futuro para el sistema como un todo.

lunes, 17 de octubre de 2011

Las Trampas del Inglés

En estos días, la caída de BlackBerry ha sido tema obligado. Con el mercado de los SmartPhones candente, cualquier error, se paga caro. BlackBerry siempre se había caracterizado por ofrecer una infraestructura estable y, más aún, segura para los ambientes corporativos gracias a la utilización de servidores propios para la transferencia y comunicación entre los dispositivos lo que, en los últimos días, fue precisamente su talón de aquiles. Llega en un mal momento este problema, además, por los cuestionamientos respecto a las funcionalidades y dificultad de uso de los dispositivos en contraste con el iPhone y los que operan con Android.

Pero más allá del problema, hay algo que llama profundamente la atención y que tiene que ver con la comunicación del error. En el siguiente link se puede apreciar la noticia en Yahoo! sobre la explicación del fallo de BlackBerry:

“BlackBerry dice que el fallo de un interruptor provocó la caída de servicios
- http://es.finance.yahoo.com

Al leer el titular, es imposible no reflexionar sobre la causa del problema… ¿Un interruptor? ¿Falla en un interruptor?

No parece creíble, obviamente, que la falla a nivel mundial del servicio de BlackBerry se debiera a la falla en un interruptor, como dice el titular. Lo que en realidad falló fue un “switch” de la red principal de BlackBerry y la traducción literal de la palabra “switch” se hizo como “Interruptor”, cuando lo correcto es traducirla como Conmutador. Un error demasiado grosero como para un titular de este tipo. Al leer el artículo, ese parece ser el único error, sin embargo, se menciona otro error más grave aún desde mi punto de vista, que corresponde a la falla del “interruptor” de respaldo. Cuando algo así falla, inmediatamente todo el castillo de naipes sobre los esquemas de contingencia y respaldo comienza a tambalear y se hace evidente la primera razón de falla de estos esquemas: habitualmente no hay como probar las contingencias.

El problema de la traducción, es más común de lo que parece y no es un tema fácil de resolver. Desde mi punto de vista, debiéramos olvidarnos de traducir los términos estrictamente técnicos de inglés a español. Las siguientes traducciones, por ejemplo, no debieran existir:

TERMINO

TRADUCCION LITERAL

TRADUCCION CORRECTA

Mouse

Ratón

 

Form

Forma

Formulario

Switch

Interruptor

Conmutador

Computer

Ordenador

Computador

CPU

UCP

Procesador

Router

Enrutador

 

Firewall

Cortafuegos

 

El problema de la traducción de Software y/o textos para múltiples lenguajes es un problema grande de resolver. Hay dos definiciones que aplican a este proceso: Internacionalización y Localización. La primera corresponde al proceso de diseño de un software para que pueda adaptarse a diferentes idiomas y regiones sin necesidad de modificar el código. La segunda obedece a la adaptación del software para una región específica. En cualquiera de los dos casos, comprende la habilitación de todos los recursos, elementos, imágenes, íconos, textos, etc., en todos los idiomas requeridos para la operación.

En lo personal me ha tocado participar de un proceso de localización de una solución para el mercado Brasileño y no fue una tarea fácil. Más allá de la tecnología utilizada, en el caso particular de Brasil, son especialmente cuidadosos de su lenguaje por lo que varias veces tuvimos que dar explicaciones por traducciones erróneas que, desde un punto de vista funcional no hacían ninguna diferencia, sin embargo, desde el punto de vista del lenguaje si. En cierta medida es comprensible: a mi me molestaría mucho tener un software que en las ventanas de diálogo me diera las siguientes opciones: Aceptar, Serrar permanentemente. En el trabao que realizamos para la localización del software no logramos encontrar una herramienta y/o framework que nos permitiera resolver el problema de manera eficiente. Al final, el proceso fue una mezcla de fuerza bruta y bibliotecas de funciones ad-hoc. Lo que si aprendí es que si se desea hacer un software globalizado, la localización debe ser establecida como el requerimiento no funcional No. 1. Cualquier intento por abordar esto después, lo hará muy complejo y, además, hay que tener claro que el real problema no es la tecnología. El real problema es el lenguaje y su uso, cosa que no se puede resolver fácilmente con un diccionario y/o un traductor automatizado. Se requiere ayuda de personas que hablen el idioma deseado.

Otro ejemplo más donde se produce este error. Hace poco se instaló Netflix en Chile. La página principal tiene dos idiomas disponibles: Inglés y Español. Las imágenes siguientes muestran la misma opción, de la página principal, en Inglés y en Español. ¿Puedes detectar el problema?

INGLES

ESPAÑOL

netflix.en

netflix

miércoles, 12 de octubre de 2011

Diseño y Tecnología

Probablemente la muerte de Steve Jobs era una situación esperada, pero no deseada por muchas personas. El éxito de Apple se le atribuye en gran medida a su genialidad y a un sin fin de atributos que, hoy por hoy, están siendo revisados una y otra vez para lograr descifrar y explicar su personalidad, sus obsesiones y el trabajo que realizó.

Es imposible no considerar su relevancia en la historia reciente de la computación y, últimamente, en el mundo del entretenimiento y del consumo masivo con productos como el iPod y el iPhone. Esto último es, desde mi punto de vista, lo más relevante de su trayectoria. En todos lados confirman que siempre fue un hombre obsesionado con el diseño. A pesar de sus inicios en Atari, estaba mucho más cerca del mundo del arte que del de la informática.

Uno de sus cursos preferidos fue el de caligrafía en el que aprendió sobre los tipos de letras Serif, Sans-Serif, etc. Eso fue diez años antes de construir el primer Macintosh y, según el discurso que dio en la Universidad de Stanford el año 2005, cuando lo estaban diseñando, incorporaron en él todo lo que había aprendido, construyendo así, el primer computador con una tipografía preciosa (beautiful typography). Según sus palabras, esto le permitió unir los puntos, haciendo la metáfora con la manera en que se dibujan los tipos de letras en los computadores modernos, de las cosas que había hecho en el pasado con su presente.

Este tema es especialmente relevante ya que en su reflexión, considera que no se pueden conectar los puntos hacia el futuro o, dicho de otra manera, no se puede asegurar que las cosas que se hagan hoy necesariamente produzcan un resultado más adelante. En definitiva, hay que abrir las puertas y confiar en el instinto, ya que en algún momento las acciones del pasado se conectarán y demostrarán que nada ha sido en vano. Totalmente contrario a esta visión, me parece muy típico de nuestra sociedad, que las personas quieran el premio antes de correr la carrera. 

Mi primer contacto con un computador Macintosh fue en el año 1986. Recuerdo claramente que lo primero que me llamó la atención fue que no tenía cables. Mi experiencia más cercana con los computadores era con el Atari 2600 y el Commodore 64 que se conectaban a la tele y a monitores especiales que, por lo tanto, requerían un sin fin de cables y conexiones para operar. Lo otro que me llamó la atención fue el mouse y la nueva manera de operar con las aplicaciones y programas por medio de ventanas, menús, etc. Hoy miro hacia atrás y, al igual que lo que sucedió con los otros productos de Apple, todos estaban perfectamente diseñados y, no contentos con eso, adelantados a su tiempo. Alineada con esta visión, la siguiente frase de Steve Jobs me parece que resume y refleja, según yo, su carrera:

"That's been one of my mantras -- focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains."

-- BusinessWeek interview, Mayo de 1998

“Ese ha sido uno de mis mantras – foco y simplicidad. La simplicidad puede ser más difícil que lo complejo: Tienes que trabajar duro para lograr limpiar tus pensamientos y hacerlo simple. Pero, es válido al final porque, una vez que lo logras, puedes mover montañas.”

Yo estoy plenamente de acuerdo con eso. Habitualmente es difícil lograr hacer algo, pero, es aún más difícil hacerlo de manera simple. Por ejemplo, la diferencia que hay entre la opción de silencio de los teléfonos BlackBerry y el iPhone. En el primer caso, al apretar el botón de silencio, se activa un menú que permite elegir el perfil deseado (Silencio, Vibrar, Vibrar más Tono, etc.) y, además, ahí mismo se puede personalizar cada perfil permitiendo cambiar la música, el volumen, el número de rings, etc. En el caso del iPhone, la opción de silencio simplemente hace eso. El switch ubicado a un costado permite, precisamente, desactivar o activar el sonido, nada más. Tal vez la posibilidad de definir, modificar y/o eliminar los perfiles parezca algo atractivo, requerido, sin embargo, no me cabe la menor duda que en el 99,9% de las veces, esto se hace una vez y nunca más. Técnicamente es una funcionalidad importante pero, probablemente, su uso no amerite el esfuerzo para construirla y/o habilitarla como el equipo de diseño de RIM.

Ejemplos como estos hay muchos pero me parece que, la conclusión más importante, es que un buen diseño, intuitivo y fácil, no debe, necesariamente, generar prejuicios y/o subestimar a la tecnología subyacente. Steve Jobs se encargó, precisamente, de demostrar que el buen diseño y la tecnología pueden convivir.

jueves, 25 de agosto de 2011

El Remedio o la Enfermedad

Un remedio, según su definición, es “Una medida que se toma para reparar un daño o para evitar un inconveniente”. En este contexto y, en línea con la definición anterior, si se decide remediar una situación, es fundamental intentar hacerlo sin incorporar un problema mayor o, como dice el dicho, haciendo peor el remedio que la enfermedad. Esto es algo que, obviamente, aplica a cualquier ámbito. A continuación, algunos ejemplos al respecto.

Ejemplo No. 1
En un supermercado me encontré con una situación como la que se puede apreciar en la foto siguiente:

estacionamiento.01

En términos simples, lo que se puede apreciar acá es que se han tomado medidas para asegurar el uso de los estacionamientos para discapacitados por personas que realmente los requieren. Desde afuera, puedo interpretar que la pintura en el piso no es suficiente como mecanismo de demarcación y que muchas personas han de aludir a esta situación para estacionarse ahí “por error”. Por lo tanto, para evitar esta situación, se incorporaron los letreros en altura de manera de hacer más visible la situación, sin embargo, la pregunta es inmediata y obvia:

¿Será fácil para una persona con discapacidad estacionarse ahí?
¿Es razonable pensar que, para estacionarse, primero deba mover o pedir que muevan el letrero?

Ejemplo No. 2
En un control de asistencia de un lugar público, la puerta que se ubica al lado del cajero del control de acceso, tenía un letrero como el siguiente:

puerta

El letrero dice:

FUNCIONARIOS (CAJEROS)
POR RAZONES DE SEGURIDAD QUEDA EXTRICTAMENTE PROHIBIDO MANTENER LA PUERTA ABIERTA.

       LA ADMINISTRACIÓN.

Considerando la situación, las preguntas naturales son obvias:

¿El cajero no hace caso al aviso?
¿Nadie fiscaliza el cumplimiento del aviso de la Administración?

En los ejemplos anteriores, sin desmercer las buenas intenciones, no está claro si el remedio es mejor que la enfermedad.

En el mundo del software, pasa exactamente lo mismo, sin embargo, con mucha menor visibilidad. Son ejemplos típicos de esta situación, la incorporación de restricciones en el software para evitar condiciones determinadas, requeridas por cierto, pero, como resultado de esto, no se consideran correctamente las consecuencias ni las herramientas para la administración de tales restriccones en aquellos casos que se escapan del flujo normal. A continuación algunos ejemplos.

Ejemplo No. 3
En un modelo de operación determinado, se requiere que los documentos enviados por un cliente no sean enviados más de una vez al gobierno. Dado que los documentos del cliente poseen un identificador único, se decidió implementar la restricción considerando este hecho. En régimen, si los documentos del cliente estaban correctos, no había ningún problema, sin embargo, si un documento queda con error y el cliente requiere realizar el reenvío, no hay cómo hacerlo ya que:

  • El sistema lo rechaza por la restricción del identificador único
  • El sistema no tiene las interfaces para eliminar el documento malo y permitir el reenvío del documento correcto.

Ejemplo No. 4
En un modelo de operación similar al anterior, realizando una optimización de un proceso, se asumió que dada las condiciones de operación del sistema y del modelo, un elemento no podía llegar más de una vez (dado un identificador único). Dado esto, se implementó una validación que controlaba esta situación y, al momento de identficar un “caso duplicado”, símplemente se eliminaba el elemento. El problema fue que, como era de esperar, llegaron elementos con el mismo identificador pero que no eran equivalentes. El error acá no es la restricción asociada al identificador único, el error es decidir eliminar el elemento y no dejar un registro, mensaje, copia o respaldo para revisiones posteriores, por lo tanto, los errores son:

  • El sistema elimina los elementos duplicados
  • El sistema no deja un registro asociado a la decisión de eliminar un elemento duplicado
  • El sistema no posee las herramientas/mecanismos de auditoría para revisión de estos casos.

Ejemplo No. 5
Este ejemplo no es real, es símplemente un ejercicio para comprender el proceso y no caer en el error de que el remedio sea peor que la enfermedad. Supongamos una aplicación con un sistema de autenticación de usuarios por medio de un login y una password. Esta es la versión inicial. A continuación, una secuencia de funcionalidades nuevas requeridas que surgen de hacerse las preguntas correctas (ver el El Plan B).

  1. Cambio de Password. Se solicita que el sistema permita que el usuario cambie su clave. Como es lógico, se requiere que el usuario ingrese su clave anterior para poder cambiarla. Se habilita la opción pero… ¿Qué sucede si el usuario no recuerda su clave anterior?, entonces, si seguimos esta pregunta tenemos dos opciones:
    • Mecanismo de Reseteo de Clave.
      Se debe habilitar un mecanismo para resetear la clave por parte del usuario.
    • Herramienta de Administración.
      Se debe habilitar un ambiente para que el administrador pueda reingresar la clave de un usuario.
  2. Bloqueo de Usuario. Se solicita que el sistema bloquee al usuario si falla los intentos de ingreso más de tres veces.
    • Mecanismo de Administración.
      Si se bloquea un usuario, al igual que en el caso anterior, se requiere habilitar las interfaces para permitir desbloquearlo.
    • Mecanismo de Configuración.
      Es algo obvio, sin embargo, qué sucede si se desea modificar el número de intentos previo al bloqueo de tres a cuatro. Por lo tanto, se requiere un mecanismo de configuración para permitir modificar este valor. De esto, obviamente, es necesario hacerse algunas preguntas para asegurar que la configurabilidad sea correcta.

El desarrollo de software tiene muchas dificultades y éstas son cada vez más complejas dada la dimensión de los sistemas y el alcance global de los mismos y, por lo tanto, la incorporación de nuevas funcionalidades y, en particular, de nuevas restricciones, requiere la habilitación de los mecanismos de revisión y de auditoría para poder asegurar que las restricciones se están aplicando correctamente. Y, más importante que lo anterior, es que alguien realice la revisión correspondiente. Pero, lo más importante, es asegurar que el remedio no va a ser peor que la enfermedad.

jueves, 18 de agosto de 2011

Déjà vu

Dadas las modificaciones a la política de cambio de horario realizadas en el presente gobierno, el tema del cambio de hora volvió a ser noticia en estos días y, por lo tanto, varios noticiarios rellenaron su programación con él. Me parece que, considerando los hechos importantes que están ocurriendo en el mundo, la rebelión en Libia, los problemas económicos de Estados Unidos, Grecia y Europa y la hambruna en Somalia por mencionar algunos, una noticia de este tenor tiene una relevancia menor y refleja una mirada egocéntrica y aislada de la realidad de Chile y su inserción en el contexto global.

En términos generales, se debe informar para lograr comunicar a toda la población el hecho de que hay que adelantar y/o atrasar el reloj según corresponda. En este contexto, me parecería razonable que los noticieros dedicaran algunos minutos a informar sobre el tema y, cuando digo informar, me refiero única y exclusivamente a eso. 

Sin embargo, como parte de la noticia se incluyen reflexiones de doctores, psicólogos, etc., destinadas a divulgar las “consecuencias que el cambio de hora podría traer a las personas”. No tengo formación en áreas de la medicina, ni de la psicología, sin embargo, me parece que esta situación refleja poca resilencia de la población si un hecho tan menor, como el atraso o el adelanto del reloj, es capaz de producir cambios y/o impactos importantes en el estado de ánimo general. Desde mi punto de vista, esta situación es equivalente a lo que en física se conoce como un estado de equilibrio inestable, es decir, un sistema en el cual un pequeño desplazamiento en la posición de equilibrio (cambio de hora) producirá un alejamiento irreversible de esta posición (cambios en el estado de ánimo).

Lo simpático de la situación es que, cuando se atrasa la hora, todo el mundo considera que “ganó una hora” siendo que, desde el punto de vista estrictamente biológico, el cuerpo no necesariamente dormirá una hora más. Por el contrario, al adelantar la hora, todo el mundo considera que “pierde una hora” siendo que, nuevamente desde el punto de vista biológico, se podría evitar la pérdida acostándose más temprano. En cualquiera de las dos situaciones, es común escuchar a las personas quejándose de haber dormido menos y/o de estar descontrolados respecto al horario cosa que, creo, sólo en los niños más chicos tiene alguna justificación.

Pero, más allá de la noticia en sí, hay una situación peor. La noticia del cambio de hora es parte de un selecto grupo de noticias que se repiten todos los años, en las misma fechas en todos los noticiarios del país como un Déjà Vu, casi como un Copy-Paste periodístico. La gracia principal de estas noticias es que están vigentes siempre, es decir, se podría mostrar la noticia del año anterior y, probablemente, nadie se daría cuenta.

Las noticias que componen este selecto grupo son las siguientes:

  • Cambio de Hora.
    Marzo y Octubre. Básicamente, lo descrito anteriormente, dos veces al año.
  • Restricción Vehicular.
    Desde Marzo a principios de Abril. Básicamente, las fallas en el modelo predictivo obligan a la declaración de pre-emergencias y a la rehabilitación de la restricción vehicular.
  • Alza en el Precio de la Carne.
    Desde finales de Agosto hasta Fiestas Patrias. Básicamente, el alza en el precio de la carne como resultado de aumento en el consumo para Fiestas Patrias.
  • Alza en el Precio de los Mariscos y Pescados.
    Desde mediados de Marzo hasta Semana Santa. Básicamente, el alza en el precio de la carne como resultado de aumento en el consumo para Fiestas Patrias.
  • Uniformes escolares días después de Año Nuevo.
    Desde Enero a mediados de Febrero. Básicamente, la renovación inmediata de la mercadería de los malls y supermercados en plenas vacaciones y la tortura que representa para los estudiantes/alumnos que vayan a comprar.
  • Inicio de Clases en Vacaciones.
    Desde mediados de Febrero a la última semana de Febrero. Básicamente, la publicación de los colegios que deciden comenzar su año escolar en febrero y no en Marzo, cuando todavía medio país está de vacaciones.
  • Huevos de Pascua días después del inicio de clases.
    Desde Marzo hasta Semana Santa. Básicamente, la venta de huevos de pascua y todos los artículos relacionados con miras a semana santa.
  • Halloween días después del Día del Niño.
    Todo el mes de Octubre. Básicamente, el día siguiente del día del niño comienzan a venderse los productos de Hallowen.
  • Artículos de Navidad días después de Halloween.
    Desde Noviembre a Diciembre. Básicamente, el día siguiente de Halloween, comienzan a venderse los productos de navidad.
  • Operación Verano.
    Desde Agosto a Diciembre. Básicamente, la noticia sobre el aumento en la matrícula de los gimnasios debido a las personas que quieren llegar “en forma” al verano.
  • Alza en el Precio de los Pasajes.
    Antes de Semana Santa, Fiestas Patrias y Navidad. Básicamente, el alza indiscriminada de los precios de los pasajes de los buses interurbanos.
  • Monto de los Aguinaldos.
    Antes de Fiestas Patrias y Navidad. Básicamente, una revisión de los montos de los aguinaldos que serán pagados y la variaciones entre las diversas industrias y cargos.

Las noticias anteriores reflejan en gran medida varios cambios que se producen a lo largo del año y que, de alguna manera u otra, creo nos representan, son parte de nuestra cultura, de nuestro inconsciente colectivo.

lunes, 11 de julio de 2011

Diagrama Universal de Resolución de Problemas

Como parte de mis labores, habitualmente me toca resolver muchos y variados problemas. Buscando una manera estructurada de resolver y enfrentar estos desafíos es que me acordé del Diagrama Universal de Flujo para la Resolución de Problemas que me entregaron hace un tiempo atrás. Yo no lo uso, pero, creo que para más de alguno puede ser útil.

ResolucionProblemas

martes, 5 de julio de 2011

La Razón de Ser

En las últimas semanas me ha tocado ir a varias reuniones con clientes para revisar y evaluar problemáticas distintas y determinar la posibilidad de resolverlas. A pesar de todo el tiempo gastado en evaluar, medir, analizar, especificar, estudiar, preguntar, etc., cada una de estas problemáticas, si tuviera que resumirlas en un Tweet, diría que el mensaje subyacente en todas era el siguiente:

“Necesito modificar/hacer un sistema para que no me sigan robando”

Tal cual. En mi vida profesional me ha tocado directa o indirectamente trabajar en muchos proyectos y estas últimas reuniones me hicieron recordar las múltiples veces en que me quedé con esta sensación después de reunirme con el cliente. Personalmente, lo que más me sorprende de esta situación es que en casi el 99.9% de los casos, la necesidad del cliente era protegerse de robos realizados por personas que trabajaban para el cliente y no, como indicaría el sentido común, de robos realizados por personas externas.

En cualquier trabajo hay una relación de confianza entre el empleador y los empleados. Con esto no quiero decir que sean amigos pero, inevitablemente, se debe cambiar la relación ya que se comienzan a compartir espacios, hay obligaciones y derechos cruzados, etc. En este contexto el robo de un externo tiene penas claras, precisas, más evidentes y más simples de aplicar. ¿Pero el robo de un interno? Como cliente ¿Porqué tendría que preocuparme de gastar recursos para evitar que las personas que trabajan conmmigo me roben? Lo peor de todo, es que en la mayoría de los casos no estamos hablando del robo del tren del dinero, sino que robos pequeños (micro-robos) pero constantes. A continuación algunos ejemplos:

  • Comerse algo en el supermercado y no pagarlo (nadie se va a dar cuenta)
  • Subirse al Transantiago y no pagar con la excusa de que el servicio es malo (el servicio “avala” la falta)
  • No entregar la boleta al hacer una venta y quedarse con el dinero (no hay registro de la venta)
  • Sacar la vuelta y no respetar los horarios de trabajo (un poquito tarde y un poquito temprano no produce ninguna diferencia)

Como los anteriores, me ha tocado ver muchos ejemplos y, claramente, al multiplicar el micro-robo por cada una de las personas que lo realiza, deja de ser micro y pasa a ser relevante. Esta situación, que es un problema para algunos, no lo es para otros ya que genera trabajo pero, aún así, he visto muchos casos y, peor aún, mucho esfuerzo (tiempo y dinero) gastado para evitar esto y, obviamente, estoy seguro que ese dinero podría ser gastado en otras cosas más interesantes. Para ello, claro, se requiere preservar un valor muy simple: la lealtad.

Hace muchos años atrás, mi madre descubrió que un empleado le robaba las cucharas de té de una cuchillería de plata. No fue fácil pillarlo pero, cuando lo hizo, obviamente lo increpó exigiéndole la devolución de las cucharas como condición para continuar trabajando con ella (a pesar de todo, mi madre estaba dispuesta a darle una segunda oportunidad). La respuesta del empleado fue sorprendente:

- Mire señora… sin las cucharas este trabajo no me conviene.

Obviamente fue despedido pero, claramente, hay un tema valórico profundo en este tipo de situaciones que escapa a mi comprensión.

miércoles, 29 de junio de 2011

Twitter – La Integración Obligada

Para nadie es una sopresa las miles de herramientas y mecanismos de publicación que hay para Twitter. Aún así, intenté armar un proyecto para entender cómo es que funciona la API de integración de Twitter y, además, poder hacer una aplicación a la medida para las pocas publicaciones que realizo. En mi caso, la idea es construir una mini-aplicación que permita la publicación de un Tweet con un solo click y que me permita evitar el proceso (engorroso a veces) de abrir el browser, ingresar a Twitter, autenticarse, publicar, salir, etc.

La API está perfectamente documentada y es simple entender. En términos simples, el proceso para poder construir una aplicación es el siguiente:

  1. Registrar la aplicación.
  2. Construir la aplicación.
  3. Autorizar la aplicación para que pueda publicar a nombre de un usuario.
  4. Publicar un Tweet de prueba.

A continuación se describen los pasos anteriores.

1. Registrar la Aplicación.
El proceso de registro de la aplicación está destinado a, como su nombre lo indica, registrar la aplicación para hacer uso de la API. Esto es similar al AppStore de Apple en términos que las aplicaciones deben estar registradas, sin embargo, Twitter no provee un mecanismo para buscar y/o recorrer las aplicaciones ya existentes. Como yo no encontré la aplicación que quería, la tuve que hacer así que comencé con el proceso de registro. Para registrar una aplicación hay que acceder a la página de Registro de Aplicaciones. Realizado la autenticación, esta página despliega todas las aplicaciones ya registradas y permite agregar nuevas. La pantalla de registro es como la siguiente:

Twitter.RegisterApp.02

Lo más complejo es la elección del nombre de la aplicación (marcado en Azul) ya que, al igual que los nombres de dominios, están casi todos ocupados.

  • El Tipo de Aplicación (Application Type) indica si la aplicación es de escritorio o web. En el segundo caso, se debe indicar la URL a la que Twitter traspasará el control (Callback) una vez que termine el proceso de autenticación y autorización.
  • El Tipo de Acceso (Default Access Type) indica el tipo de acceso por defecto que se le solicitará al usuario al momento de la autorización.

Terminado el proceso de registro de la aplicación, Twitter entregará un token de acceso (Access Token) que contiene dos llaves únicas que identifican a la aplicación. Estas llaves son el Access Token (oauth_token) y el Access Token Secret (oauth_token_secret). El token de acceso identifica a la aplicación y, por lo tanto, debe ser protegido por el autor para mantenerla bajo su control. El protocolo utilizado por Twitter para hacer la autenticación es el estándar de autenticación OAuth.

2. Construir la Aplicación.
Registrada la aplicación, es necesario construirla. Para esto, obviamente, hay mil alternativas de lenguajes y de bibliotecas. Para este ejemplo, la aplicación será construída en VB.net y será una aplicación de escritorio (Desktop). Las bibliotecas disponibles para cada lenguaje se pueden revisar en la página de bibliotecas, Twitter Libraries.

Para la aplicación, utilizaré la biblioteca TwitterVB. Esta biblioteca tiene todos los métodos de integración con Twitter ya implementados, por lo tanto, se hace muy fácil integrarla a un proyecto existente.

La pantalla principal de la aplicación es como muestra la imágen siguiente. En términos simples, es una ventana que debiera omitir todos los detalles de autenticación y permitir elegir la cuenta de Twitter con la que se desea publicar. Para lograr esto, como revisaremos en el punto siguiente, es fundamental que el proceso de autorización de un usuario a una aplicación persiste en el tiempo.

Twitter.MainForm

3. Autorizar la Aplicación para Publicar a nombre de un Usuario.
El proceso de autorización de una aplicación consiste básicamente en realizar la secuencia para obtener las llaves secretas de autorización del usuario para la aplicación. El código siguiente muestra la secuencia anterior:

Twitter.Source.Link

Los pasos conceptualmente son:

a) Solicitar la página (URL) de autorización del usuario para la aplicación. La URL de autorización es como la siguiente:
http://twitter.com/oauth/authorize?oauth_token=RwcHZJHKshgdkahskwer7khkaasdfHKH

b) Abrir el browser en la página anterior para que el usuario realice el proceso de autorización. Como resultado de este proceso, el usuario deberá identificarse y obtendrá un PIN (Número de Identificación). El PIN es un número como el que se muestra a continuación:

Twitter.Auth.02

c) Recuperar el PIN desde el usuario.

d) Validar el PIN del usuario y recuperar las llaves de la autorización. Las llaves que se obtienen del proceso anterior son dos llaves que se llaman TokenKey y TokenSecret que se ven como sigue:

TokenKey = 177061323-9iPOqWwp9IhFEHN3bTvehjkHGJKJHGhjghghgjHGHGJk3qBtSWI
TokenSecret = 3neRlNafAPgKQBR5sv05Eq6MMhjyHGGTYUHysig

Con la autorización realizada, la aplicación está en condiciones de enviar Tweets a nombre del usuario. Una de las gracias de este mecanismo es que las llaves anteriores son únicas (obviamente) y no cambian en el tiempo. Esto implica que, una vez realizada la autorización y obtenidas las llaves, la aplicación podrá realizar la publicación de Tweets sin necesidad de repetir el proceso de autorización, a menos que el usuario cambie sus preferencias.

4. Publicar un Tweet
La publicación de un Tweet comprende la autenticación en Twitter de la aplicación a nombre del usuario (por medio de las respectivas llaves) y luego enviando el Tweet. El código siguiente muestra la secuencia anterior:

Twitter.Source.Post

Los pasos conceptualmente son:

a) Autenticar en Twitter la aplicación a nombre del usuario utilizando las llaves respectivas, es decir, las llaves de la aplicación y las llaves de la autorización del usuario para la aplicación.

b) Enviar el Tweet!.

c) Al enviar el Tweet! se obtiene un número que identifica la publicación y que puede ser utilizado para eliminar (deshacer) la publicación desde la aplicación.

Lo anterior es sólo un ejemplo de cómo utilizar la API en donde, lo fundamental, es tener claridad sobre el proceso de registro y posterior autorización de una aplicación para permitir realizar los Tweets.

Adicionalmente, Twitter provee otros métodos en la API que permiten recuperar el Timeline, los Seguidores, etc.

jueves, 23 de junio de 2011

Un Viaje en el Tiempo

Ayer tuve la oportunidad de asistir a la cena anual de la ACTI. Similar a otras ocasiones, la agenda es más o menos la siguiente: bienvenida, discursos varios, premiaciones a empresas y regalos a asistentes. Uno de los regalos, esta vez, fue un celular LG Optimus 2X de última generación. Lamentablemente, no me lo gané.

Hubo tres discursos. El primero del Sr. Jeffrey Cole invitado de USA y representante del Center for the Digital Future. El segundo del presidente de la ACTI, Sr. Raúl Ciudad y, el último, del Ministro de Economía, Sr. Juan Andrés Fontaine.

En términos generales, los discursos fueron bastante planos sin muchos elementos nuevos o que no hayan sido mencionados muchas veces antes. Algunas de las ideas fuerza que se mencionaron en los últimos dos discursos fueron:

  • Chile país desarrollado en el 2018
  • Computadores para todos los colegios de Chile
  • Banda Ancha debe ser un derecho... todos los ciudadanos debieran tener acceso a velocidades y precios adecuados
  • Es necesario fomentar el emprendimiento
  • Es necesario apoyar el I+D nacional

¿Parece familiar alguna de estas frases?
¿No parece un Déjà vu, un viaje en el tiempo y lo mismo que se viene discutiendo hace 10 años?

Desde que yo hacía clases en la universidad que vengo escuchando este tipo de declaraciones mientras hacíamos esfuerzos para vincular al DCC con la empresa por medio del curso CC61A – Proyecto de Software.

El miércoles fui a otro seminario llamado emprendeTIC destinado a promover el espíritu emprendedor. Uno de los oradores de InnovaChile, Adrian Magendzo, hizo una presentación espectacular (yo no lo había visto antes) y, al final, uno de los asistentes le dijo:

- "Adrián... he asistido a todas tus charlas en los últimos dos años y, aparte de felicitarte por lo bien que lo haces, debo decirte que es lo mismo ¿Me puedes realmente decir qué cosas nuevas está haciendo Corfo para apoyar al emprendimiento?”

Al margen que no comparto la manera, el mensaje era claro. Adrián respondió la pregunta bien y agregó algunas cosas nuevas.

Pero el tema de fondo yo creo que es que falta marketear (y mucho) las cosas buenas que se están haciendo. Creo que ya hay suficientes ejemplos de personas que están haciendo cosas importantes e interesantes en Chile, a menor escala, y que son ejemplos a seguir y no continuar, permanentemente, con el discurso de lo que tal vez habría que hacer. Creo que es necesario creerse el cuento, un pasito a la vez, y no esperar que de un día para otro aparezca algo como los ya clásicos ejemplos: Facebook, Google, etc.

Esto es muy parecido a la discusión de las "competencias" de hace 10 años... aún siguen apareciendo gurús que dicen "hay que hacer un modelo de competencias" y, bueno, se echa a andar la bolita nuevamente.

Otra cosa que me pareció sorprendente fue el premio entregado a Enlaces. No tengo nada encontra del proyecto, al contrario, conozco a varias personas que han estado muy involucradas en ese proyecto, pero, me parece que no se puede premiar en el contexto de un discurso sobre la innovación y el emprendimiento, un proyecto que ya lleva más de veinte años en ejecución. Lo que correspondía, en caso de haber sido necesario, era un premio al reconocimiento o similar, pero no un premio a la innovación.

viernes, 17 de junio de 2011

Mundo Touch

Mi primer contacto con computadores y/o dispositivos de juegos fue por el año ochenta. En ese momento, los ejemplos más cercanos eran el Atari 2600, Intellivision, ColecoVision y Sega. En el ámbito de los computadores eran el Commodore 64, Sinclair y Texas Instruments y, en mi colegio usaban computadores BBC Micro para enseñar Basic. Siendo un niño, para mí era sencillamente incomprensible y a la vez fantástico, la posibilidad de controlar con un joystick algo en pantalla y hacer que se moviera, saltara, disparara, etc. Los juegos que recuerdo más importantes eran el Q*Bert, PacMan (y toda su parentela), PitFall y PitStop, todos ellos provistos por mi mejor amigo ya que yo no tenía uno.

En ese momento, estar frente a la televisión jugando horas era algo impensado. Yo, y muchos de mis amigos, no teníamos incorporada esa variable, por lo tanto, era un juego más. Jugábamos un rato y luego volvíamos a nuestros juegos típicos. Aún así, a veces, la frustración nos atacaba y lo más perjudicado era el hardware asociado, es decir, la consola, los otros cartridges, los joystick, etc. Recuerdo especialmente que los joystick de Atari aguantaban todo, nunca me tocó ver uno destruído.

Han pasado algunos años desde ese momento y mis intereses y mi relación con la tecnología ha cambiado. Hoy trabajo con computadores todos los días por lo que, mirando hacia atrás, creo entender qué es lo que sucedia cuando movíamos el joystick y el monito pixelado saltaba o corría y, no dejo de sorprenderme, cómo eso sucedia con las infinitas restricciones de recursos y lenguajes que había en esas máquinitas. Pero, obviamente, el hardware de hoy no tiene nada que ver con el hardware de ese entonces. Hoy los computadores tienen discos duros, pantallas LCD (ya no se usa el televisor), son ultradelgados, etc., y, la tendencia más importante desde la incorporación de las cámaras a los celulares, es hacer todos los dispositivos touch copiando la tendencia establecida por Apple con el iPod, iPhone e iPad.

Dado esto, el otro día estaba intentando hacer una llamada con mi iPhone. Para los que tienen iPhone (o tienen plan con la compañia *********), deben haber experimentado la pérdida de señal habitual y, la mucho peor, latencia (demora) en la recuperación de la misma. Yo no tengo claro si es un problema del hardware o de la señal o de los dos, pero, es realmente irritante cuando sucede. Tanto así que el otro día necesitaba hacer una llamada urgente y no pude hacer que el teléfono recuperara la señal durante un buen rato. Surgió dentro de mi, como una explosión, el recuerdo de mi infancia y estuve a punto de golpear el teléfono con mi puño, tirarlo al suelo, etc., para lograr canalizar de alguna manera mi rabia. Lamentablemente, mi racionalidad me lo impidió por las consecuencias obvias que eso tendría sobre el teléfono.

Hay una frase que refleja esta situación a la perfección pero que, en este mundo cada vez más touch, no aplica lamentablemente:

Hardware = Lo que golpeas. Software = La causa”

Símplemente, habrá que buscar otros mecanismos para canalizar la rabia en estas situaciones.

martes, 14 de junio de 2011

WebServices… ¿La solución a todos los problemas?

Como es habitual, me toca asistir a muchas reuniones para revisar, evaluar y proponer soluciones para la integración entre los sistemas del cliente y los productos de Paperless. Una reunión de este tenor, casi siempre gira en torno a buscar la mejor manera (más barata, de menor impacto) de lograr que los dos sistemas conversen y/o intercambien información. Adicionalmente, típicamente el sistema del cliente es un sistema antiguo y/o en operación (la manera elegante de decir que ya está estable), por lo que cualquier intención de tocarlo o modificarlo es liquidada rápidamente. Claramente, la opción más natural es adaptarse a cualquier tipo de salida y/o esquema de integración ya existente.

En mi experiencia, cada cliente tiene una realidad particular que impide enfrentar este tipo de problemas con una oferta de interfaces estándar. Por tal razón, mi visión, es la de ofrecer diversos esquemas más o menos conocidos y comenzar a evaluarlos con él. Según el perfil con el que se realice la reunión, ésta puede ser una reunión exitosa (desde el punto de vista de encontrar la mejor solución) o un fracaso (en caso de no encontrar una salida). En general, el desafío es encontrar la alternativa más concreta y eficiente para la integración, es decir, aquella para la cual el cliente tiene algún tipo de conocimiento y/o expertise, tiene la tecnología, los recursos, etc. Muchas veces he visto proyectos de integración en los que se deciden estrategias entre cuatro paredes y, al intentar implementarlas, los problemas son infinitos.

En este contexto, los WebServices han pasado a convertirse en un salvavidas de dominio público, desde mi punto de vista, nunca antes visto. En muchas reuniones en las que me ha tocado participar y después de estar un buen rato buscando la alternativa correcta, aparece un iluminado (A) que, sin tener la más mínima idea de lo que significa, hace su gran aporte:

- ¿Y si hacemos un WebServices? – nótese la ‘s’ al final, fundamental para identificar este perfil.

Lo más simpático de esta situación es lo siguiente:

  • Posicionamiento. Casi inmediatamente A sube de rango entre sus pares. Pasa a ser un referente, el experto en integración. La persona que sabe y que va a resolver todos los problemas.
  • Optimismo. Los problemas de integración se terminan. Mágicamente, la palabra WebService se convierte en un salvavida, algo así como un WD40 que permitirá desentrabar la integración y avanzar y, en los casos más extremos, se concluye que este es el mecanismo de integración y la reunión avanza hacia otras problemáticas.

Desde el punto de vista de la integración vía WebService, ésta requiere dos componentes:

  • WebService. El WebService propiamente tal. Es un punto de entrada expuesto, típicamente, desde un servidor web hacia el resto del mundo. La
  • Consumidor. El cliente que consume (usa) el WebService. Esta, probablemente, es una de las ventajas más grandes de esta tecnología y es que, actualmente, existen diversas bibliotecas integrables a nivel cliente que permiten hacer uso cualquier WebService fácilmente. Visual Studio provee herramientas visuales para incorporar referencias a un WebService. Java posee la herramienta wsdl2java que permite hacer lo mismo y, para los otros lenguajes, hay muchas alternativas para lograr lo mismo.

Considerando lo anterior, es fundamental tener presente que la integración vía WebService no es bidireccional por naturaleza. Esto implica, básicamente, que si se desea que dos sistemas, S1 y S2, puedan intercambiar información, se requiere que S1 implemente un WebService y S2 también y, a su vez, S1 consuma el WebService de S2 y vice versa. Lo importante de esto es tener claro cuál es el objetivo de la integración. Por ejemplo, si se tiene un sistema legacy que no posee una implementación para publicar un WebService, sería absurdo proponer esta tecnología como esquema de integración bidireccional.

Mi experiencia personal es que los WebServices son una alternativa más de integración, no son necesariamente la única ni la mejor, como muchas personas hoy en día sienten. Esta es una situación similar a lo que pasa con el XML en que cualquier cosa, en formato XML, pasa a ser “estándar” y cumplir con las buenas prácticas de uso de esta tecnología. En este contexto, ejemplos me sobran.

lunes, 6 de junio de 2011

Los Piropos

El otro día encontré estos piropos absolutamente nerds, que creo pueden ser útiles para aquellos que andan en plan de conquistar a alguien:

- ¿Tu nombre es Google? Porque tienes todo lo que ando buscando.

- ¿Crees en el Orígen? Porque estás en mis sueños.

- Si yo pudiera ser una enzima, sería el DNA – Helicasa de manera de abrir tus genes.

- ¿Eres un ángulo de 90 grados? Porque estás perfecta.

- Me gustaría fueras Banda Ancha para tener acceso ilimitado.

- ¿Tienes un fantasma en tus pantalones? porque estás de miedo.

- Yo soy el estudiante y tú eres mi libro de matemáticas… me resuelves todos mis problemas.

martes, 31 de mayo de 2011

Gracias por lo Bueno

Hoy fue uno de esos días en que las cosas no funcionarion como siempre. En la mañana fui al Starbucks a comprarme un café. Cuando llegué me llamó mucho la atención que estuviera vacío, era un poco más tarde de lo normal pero no tanto como para estar vacío. Inmediatamente pensé que había algo raro y así fue: no había agua y, por lo tanto, no había café. Me fui con las manos vacías.

De regreso a la oficina, pasé al banco a depositar un cheque. Eran justo las 09:00 por lo que estaba vacío pero, igual, tuve que sacar un número y esperar. Cuando fue mi turno y me acerqué a depositar el cajero me avisó inmediatamente que no había sistema y que mi depósito quedaría reflejado cuando volviera. 

Estas dos situaciones me hicieron recordar el terremoto de febrero del año pasado y las múltiples cosas que dejaron de funcionar y que siempre habían funcionado hasta ese momento. Aún cuando tuve la suerte de que en mi casa no pasó nada muy importante, no fue lo mismo en la oficina en la que trabajo. La oficina queda en el piso 25 y, por lo tanto, hubo varias cosas que se vieron afectadas por el terremoto.

Lo primero y más evidente, fueron los ascensores. Como resultado del terremoto, ninguno de los cuatro disponibles funcionó durante por dos semanas. Esto, en términos simples, modificó un trámite de unos pocos minutos a un esfuerzo monumental para subir y bajar los venticinco pisos por las ecaleras. De la misma manera, las comunicaciones (internet) se vieron afectadas desde la oficina hacia nuestros servidores ya que el DataCenter también tuvo algunos problemas. Por la arquitectura de nuestras soluciones, nuestros clientes no tuvieron mayores problemas por este pequeñito detalle .

Hace algunos años hubo una situación similar y, por lo que está sucediendo en este invieron pareciera que se va a repetir, que fue la restricción para el uso del agua como resultado de una sequía grande que afectó a todo el país. Todavía recuerdo un slogan que invitaba a regar día por medio en la radio (Hoy te toca a ti… Hoy te toca a tí… y mañana le toca al vecino…). En ese momento, la restricción implicó cortes de luz programados y recuerdo lo complejo que era cuando el corte era en el horario de trabajo. En la empresa en la que trabajaba en ese momento, sencillamente, nos quedábamos de manos cruzadas. Aún cuando hubo algunas iniciativas por intentar avanzar en papel y otros soportes… esto era imposible.

Las situaciones como las que describo no sólo complican la vida personal, lo más cercano e inmediato, sino que, muchas veces, terminan por complicar a la sociedad entera lo que aumenta exponencialmente los niveles de stress e intolerancia y saca a relucir lo peor de cada uno de nosotros. Basta ver lo que sucede cuando los semáforos colpasan y/o cuando la gente compraba como nunca antes en los supermercados de Santiago, aún cuando no había ningún problema de abastecimiento.

Por esta razón, sin querer convertir esto en una declaración de principios, filosofía de vida, ni una obligación, agradezco cada vez que las cosas funcionan como deben: la luz, el agua, el celular, el computador, el auto, los ascensores, etc., porque, cada una de estos elementos está impregnado con la idea del progreso y el perfeccionamiento de los procesos realizado por el hombre a lo largo del tiempo y, esto, es algo que no se puede olvidar. Un ejemplo, más vinculado a mi profesión, es la migración de diskettes 5 1/4, 3 1/2, etc., a medios de almacenamiento de estado sólido (SD, pendrives, etc.). Nunca más tener que escuchar la diskettera una y otra vez tratando de leer el sector corrupto del diskette, realmente produce una satisfacción infinita.

Y tú… ¿De qué te sientes agradecido?

miércoles, 25 de mayo de 2011

La Libertad

Hace algunas semanas atrás compré un libro llamado “Osho – Libertad, La valentía de ser tú mismo” (ISBN 978-987-556-499-9). Yo había visto una y otra vez libros como este en las librerías, sin embargo, no tenía idea de lo que eran. Al parecer hace poco salió una edición nueva y, por lo tanto, están tratando de promoverla y/o liquidarla rápido. Con el libro en mis manos, logré descubrir de qué se trataba y, además, averigué en internet una breve historia de Osho, las peleas entre los que lo seguían y los que lo perseguían, etc. y, con todos estos antecedentes, me puse a leer el libro.

El libro es un libro fácil de leer, básicamente contiene la transcripción charlas, conversaciones, etc., que realizó Osho a lo largo del tiempo y está redactado de esta manera, es decir, como si uno estuviera escuchando su visión, descripción del mundo.

Siempre he sido afín a libros que reflexionen de este tipo, es decir, libros sobre la existencia, la razón de ser de la humanidad, ética, valores, etc. y, por lo tanto, sin comulgar con todas las cosas descritas en el libro, hay varias ideas desarrolladas a lo largo del libro que me parecieron extremadamente interesantes. En primer lugar por el hilo conductor de la reflexión: un lenguaje simple, con ejemplos simples, conectada con el entorno y con un razonamiento causa-efecto bastante simple tambíén. Con esto no quier minimizar las ideas, muy por el contrario, quiero destacar la simplicidad en la forma de expresarlas. Obviamente el hilo conductor del libro es el concepto de libertad, sin embargo, vinculado a él, se transmiten varias ideas respecto a la sociedad, la responsabilidad, la madurez, etc. y, en las cuales, no deja de sorprenderme la claridad para hilar las ideas y vincularlas en el tiempo, entre ellas, etc.

A continuación hay una selección de frases, obviamente sacadas de contexto, que me parece son interesantes del libro y que, me parece, permiten hacerse una idea de lo que dije antes.

“De manera que no asocies la libertad con independencia. la independencia naturalmente es de algo, de alguien. No asocies libertad con hacer lo que quieres hacer, porque eso es tu mente, no tú. Al querer hacer algo, al desear hacer algo, estás en el cautiverio de tu querer y tu desear. Con la libertad de la que hablo, símplemente eres.”

“De modo que quien esté dispuesto a aceptar la responsabilidad de ser él mismo, con toda sus bellezas, amarguras, sus alegrías y agonías, puede ser libre. Sólo semejante persona puede ser libre.”

“Libertad no significa caos. Libertad significa más responsabilidad; tanta responsabilidad que nadie necesita interferir en tu vida.”

“La verdad no se puede tomar prestada.No se puede estudiar en libros. Nadie te puede informar acerca de ella. Tú mismo tienes que agudizar tu inteligencia para poder investgar la existencia y descubrirla.”

“Es una cuestion muy compleja, pero también muy fundamental.En toda la existencia, sólo el hombre necesita normas. Ningún otro animal necesita normas.”

“Dios, el destino, el sino… son palabras falsas, embelesos, nada más que eso. Deséchalos completamente, porque desecharlos te convertirá en un individuo, totalmente responsable de tus actos. Y a menos que asumas la responsabilidad de ti mismo, nunca serás fuerte, nunca serás independiente, nunca saborearás la libertad. Puedes tener libertad. Pero el precio es aceptar la responsabilidad en su totalidad.”

“Y no te dejes embaucar por astrólogos, adivinadores del pensamiento, quirománticos, pronosticadores de tu futuro. ¡No hay futuro si tú no lo creas! Y lo que va a existir mañana va a ser tu creación. Y hay que hacerlo hoy, ahora… porque de hoy, del útero del hoy, nacerá el mañana.”

“La evolución es intrínseca a la naturaleza del hombre, la evolución es su alma misma. Y los que se dan a sí mismos por descontado permanecen insatisfechos; los que piensan que han nacido completos permanecen sin desarrollarse.”

“El hombre nace como potencial; es el único que lo hace. Todos los demás animales nacen completos, nacen como van a morir. No hay ninguna evolución entre su nacimiento y su muerte: están en el mismo plano, nunca experimentan ninguna transformación. Ningún cambio radical sucede nunca en su vida.”

“¿De dónde viene esta evolución? Viene porque el hombre es el único animal que puede asimilar el pasado. Una vez que el pasado está asimilado, eres libre de él. Puedes entrar en libertad y usar tu pasado… Puedes asentarte sobre los hombros de tus padres y antepasados y sus padres y sus antepasados. El hombre va asentándose sobre los hombros de todos los demás hombres; de ahí la altura que alcanza el hombre.”

Las dos últimas frases me parecen extremadamente potentes y simples. La primera por el hecho de sembrar en la esencia del ser humano la necesidad de crecer, avanzar y progresar y, la segunda, por establecer un piso a partir del cuál se puede realizar este progreso, básicamente, todo el conocimiento de la humanidad hasta el momento.

lunes, 16 de mayo de 2011

Alineando Conceptos

El otro día me tocó justificar y defender a la factibilidad de instalar una aplicación desarrollada en Java en convivencia con aplicaciones desarrolladas con otras tecnologías (C++ y C# de Microsoft®). Esto, obviamente, en una máquina con sistema operativo Windows®.

Como parte de esto, escuché muchos argumentos erróneos para intentar justificar la posición de no instalar la aplicación en Java en el ambiente indicado. Aún cuando hay una consideración importante respecto a las características del Hardware, desde el punto de vista del Software, en términos generales, todos los argumentos sólo reflejan errores conceptuales respecto a las componentes que participan en la decisión, como describo a continuación.

Afirmación 1 - Java ocupa muchos recursos
Casi todos los lenguajes modernos requieren de un “run-time” para ejecutarse. Un run-time ó ambiente de ejecución es básicamente un programa que provee un entorno para la ejecución de programas compilados en un determinado lenguaje. Hay múltiples ejemplos de run-times disponibles. Algunos de los más conocidos son Java, C# y otros menos evidentes, como Visual Basic 6.0 de Microsoft.

Un run-time es capaz de ejecutar un programa “compilado” para un lenguaje determinado a diferencia de lo que sucede con los lenguajes interpretados (php, asp, perl, etc.) que, también requieren un run-time pero que no pueden ser compilados previamente.

El problema con esta afirmación es, básicamente, considerar que el run-time ocupa recursos por sí mismo. Obviamente, el run-time ocupa espacio en disco, sin embargo, para que realmente ocupe recursos debe ejecutar un programa y, en este contexto, el uso de recursos depende única y exclusivamente del programa a ejecutar – no es una característica del run-time por si mismo.

Aunque una prueba de rendimiento siempre será posible de cargar hacia un lado u otro, en el siguiente link hay un benchmark que permite realizar la comparación entre diversos lenguajes de programación. Al hacer la comparación entre Java y C#, Java obtiene mejores resultados.

Afirmación 2 - Instalé Java y lo eché a andar
Siguiendo con la idea anterior, el run-time no se puede ejecutar por si solo. En este contexto, se puede instalar el run-time de java y/o .net en un computador en cualquier momento, sin embargo, si no se tiene un programa que haga uso del run-time, sencillamente no se puede ejecutar.

El problema con esta afirmación es considerar que el run-time se puede ejecutar. El run-time se utiliza para ejecutar otros programas y no se puede ejecutar por si solo.

Afirmación 3 – Microsoft ya no soporta Java
Efectivamente, el 30 de Junio de 2009, Microsoft terminó el soporte de su versión de Java. Esto no es un problema en sí mismo, sin embargo, si se convierte en un problema al considerar que el soporte de Microsoft® para Java es extensible a aplicaciones desarrolladas en otra versión de Java, por ejemplo, la de Sun (Oracle ahora).

Históricamente, Microsoft siempre estuvo en contra de Java como lenguaje de desarrollo y, obviamente, nunca iba a privilegiar esta tecnología en desmedro de sus propios ambientes de desarrollo. Menos aún cuando Java provee, desde sus inicios, el postulado de “write once run everywhere” (programa una vez ejecuta donde quieras) que, peor aún, potencia otros sistemas operativos en desmedro de Windows.

El problema con esta afirmación es considerar que se requiere soporte de Microsoft para ejecutar aplicaciones Java, lo cual, sólo aplica para aplicaciones desarrolladas para la máquina virtual de java de Microsoft (MSJVM).

Considerando todos los argumentos anteriores, la única manera de realmente resolver un dilema de este tipo es mediante la realización de una prueba de concepto, en particular, para descartar la primera afirmación. Las otras dos, en realidad, no son relevantes para tomar una decisión adecuada.

viernes, 13 de mayo de 2011

A la Chilena

En las últimas semanas me ha tocado realizar dos trámites distintos a través de internet. Honestamente, los sistemas están bien armados, hacen lo que deben hacer, están bien integrados con las plataformas de pago, etc., en definitiva, todo bien, pero… fallan en la última milla. ¿Por qué? básicamente porque la idea de hacer(ofrecer) un trámite en internet es que éste sea 100% virtual y, por lo tanto, uno como cliente espera que éste se inicie y se termine de igual manera. En el caso de los dos trámites que describo a continuación, los procesos son 100% virtuales, sin embargo, cuando ha concluído el proceso (desde el punto de vista del proveedor), es necesario realizar un trámite no virtual (desde el puntode vista del cliente) para poder concluir el proceso. Lo simpático es que se optimiza y se aumenta la eficiencia del proveedor pero no se logra el mismo efecto desde el punto de vista uno como cliente, es decir, como se suele decir… a la chilena.

1. Pago Patente

Como es habitual en el mes de Marzo, hay que pagar el permiso de circulación. Más habitual es dejarlo para última hora, por lo que, obviamente, la alternativa de hacerlo por internet es la mejor. Por lo tanto, hice el pago del permiso de circulación de mi auto por internet en una municipalidad determinada. El proceso fluyó bastante bien, obviamente, varios había que llenar varios formularios, ingresar bastantes datos del auto, pagar la póliza del seguro, etc. La verdad, me pareció excelente el proceso, los pasos estaban declarados y todo funcionó correctamente hasta el final. Concluído el pago y la ejecución del proceso completo, salió un mensaje como el siguiente en pantalla:

Felicitaciones. El proceso de pago de su permiso de circulación ha concluído. Para obtener su permiso, debe acercarse a la Dirección del Tránsito, Av. XXXXXX YYYY ZZZZZ, entre las 09:00 y las 12:00 del día siguiente al que realizó el pago.

Contrario a lo que yo esperaba, tuve que:

  • Ir físicamente a retirar el permiso de circulación a la dirección indicada (que, por suerte, no quedaba tan lejos)
  • Ir en el horario indicado (de lo menos flexible).
  • Por último, peor aún, sólo se podía ir a retirar el comprobante al día siguiente de realizado el trámite vía web y, cuando dice “día siguiente” efectivamente se referían a eso. Sólo entregarían el comprobante ese día.

2. Compañía de Seguros

Tuve la mala suerte de que me chocaron el otro día. Nada grave, pero, suficiente como para acudir al seguro del auto e intentar dejarlo como nuevo (porque es nuevo). Así que lo primero que hice fue llamar al teléfono de mi compañía de seguros para hacer el denuncio del siniestro como lo había hecho otras veces. Lo novedoso es que esta era mi primera vez en esta compañía.

Al hacer el llamado y después de superar la típica secuencia del call center (ver El Call Center), me antendió la ejecutiva. Comencé a darle los antecedentes del choque y todo lo demás. Después de unos minutos me detuvo y me dijo que el denuncio de los siniestros debía realizarse por internet. Hasta ahí, una pérdida de tiempo, pero, bueno, me alegro saber que existía la posibilidad de hacer el trámite más eficiente. Así que me fui a la página a hacer la denuncia del siniestro. Tema aparte, la necesidad de hacer la denuncia en carabineros. El formulario, nuevamente, muy bien hecho, con todas las recomendaciones esperables para este tipo de actividades: los pasos bien definidos, ajax por todos lados, validaciones en línea, etc. El formulario constaba de cinco pasos en los que realmente había que ingresar demasiada información, en definitiva, casi todo lo que se podría uno imaginar. Mientras llenaba los formularios, pensaba en las típicas frases de optimización de procesos: dejemos que el cliente nos entregue toda la información, sólo hagamos validaciones, etc., así que asumí e ingresé toda la información.

Terminado el proceso, me salió un mensaje que decía:

Una vez enviado este denuncio, usted recibirá un correo electrónico de confirmación que incluirá un formulario de Denuncio de Siniestro. En caso de que no reciba  este mensaje, dentro de las próximas horas, favor  llamar al 600 XXXXXXX y desde celulares al 02 XXXXXXXX. El Formulario de Denuncio que reciba, debe ser firmado a la mayor brevedad posible durante el Proceso de Liquidación.

Contrario a lo que yo esperaba, ahora:

  • Tengo que esperar un e-mail que, después de dos días, no ha llegado.
  • Voy a tener que llamar, considerando que ya ingresé toda la información en el sistema, para pedir me envíen el formulario
  • Tendré que ir físicamente a algún lugar a firmar el formulario en un plazo indefinido: la mayor brevedad posible.

En resumen, como cliente (y como persona que trabaja en la habilitación de soluciones tecnológicas), creo que:

  • No es aceptable que un proceso que se realiza sobre internet, que haga alusión a todas las ventajas de un canal como éste, no termine de la misma manera. No se puede dejar el proceso cojo, es 100% virtual o no lo es pero, mezclas como las descritas anteriormente, claramente no apuntan a mejorar la percepción de estos sistemas.
  • No es aceptable que una afirmación y/o promesa establecida como resultado del proceso no se cumpla. Esto, obviamente, sólo incluye desconfianzas respecto al proceso.
  • Como persona involucrada en el rubro informático, creo que es fundamental velar por evitar este tipo de implementaciones. Quiero pensar que hay otras razones para que así sea, sin embargo, creo que es deber de todos los que participamos en esto, asegurar que la experiencia del usuario sea la correcta.

lunes, 2 de mayo de 2011

¡Que viva el lunes!

Tengo la suerte que me gusta mi trabajo y, además, siempre me ha gustado trabajar. No tengo la suerte de haber nacido en cuna de oro por lo que, al igual que muchas otras personas, tengo claro que no voy a recibir ningún tipo de herencia, ni ayuda de terceros ni nada y, por lo tanto, todo lo que pueda lograr por darle un buen estándar de vida a mi familia, depende única y exclusivamente de lo que logre trabajando. Aunque he sido privilegiado en poder trabajar siempre en cosas que me gustan, estoy consciente de que esto no le sucede a todo el mundo y que hay muchas personas que trabajan en condiciones limitadas, inadecuadas y/o no deseadas lo que obviamente se traduce en una “disposición” hacia el trabajo llena de disconformidad.

No tengo claro si esto se repetirá en otros países, porque no he tenido la suerte de trabajar fuera de Chile, pero no deja de llamarme la atención los diálogos que se escuchan en el ascensor y/o en el metro cuando voy a mi oficina. Algunos ejemplos de respuestas que habitualmente escucho en respuesta a la pregunta ¿Como estas? a primera hora de la mañana:

  • Aquí estoy… como día lunes.
  • Aquí estoy… No llueve pero gotea.
  • Muerto de sueño, y recién es lunes
  • Bien… pero ya se me va a pasar.

En definitiva, ninguna de esas respuestas transmite energía, ni buenas vibras, ni lo deja a uno hiper motivado, muy por el contrario, transmite una sensación de aburrimiento, de energía negativa y, peor aún, de “culpabilidad” si es que uno, por alguna razón no se siente igual. Como siempre le digo a mi equipo, tal vez no se puede elegir lo que hay que hacer, sin embargo, si se puede elegir cómo hacerlo y esto, creo que es lo que marca la diferencia respecto a cómo enfrentar la obligación de tener que trabajar todos los días para los que nos toca hacerlo.

lunes, 25 de abril de 2011

En el Nombre del Mail

Habitualmente me toca recibir y revisar curriculums de personas que postulan a la empresa en la que trabajo. Es complejo el tema de la selección de personal, especialmente para personas como yo que no tenemos ninguna formación en las áreas más blandas que habitualmente están involucradas en estos procesos (psicología por ejemplo). En un principio mi primer foco siempre fue lo técnico, sin embargo, con el tiempo he intentado migrar mi atención hacia temas menos técnicos y más vinculados a las habilidades blandas de las personas, por ejemplo saber hablar, saber escribir, etc., de manera de intentar evitar problemas de comunicación posteriores (ver Las Dos Ilusiones). A la larga es mucho más valioso una persona que sabe preguntar y que es capaz de hacerlo, que una que intenta resolver los temas por su cuenta.

Creo que aún me falta mucho para sentir que es un área que domino en alguna medida y, alguna vez, me encantaría trabajar en alguna empresa grande en las que los responsables de contratar gente definen el perfil y luego lo derivan al área de recursos humanos quien, después de un tiempo, entrega la famosa “terna” para elegir. Tengo la suerte que en mi equipo hoy, hay personas muy aperradas que me permiten dedicarme a otros temas, considerando las pocas personas que somos y, de alguna manera, siento que seguimos privilegiando ser pocos y buenos que muchos y malos.

Independiente de lo anterior, hay algo que siempre me ha llamado la atención en las postulaciones que reviso y es el e-mail del postulante y/o el e-mail registrado en el curriculum. Por un momento, consideremos ejemplos como los siguientes (todos ficticios en todo caso):

Es imposible leer ese mail y no hacer una asociación directa o indirecta con algún rasgo de la personalidad del postulante (por si acaso, aún en casos extremos similares a los anteriores, he cumplido con entrevistar a los postulantes) pero creo, que en este escenario, es mejor tener un correo separado para los temas personales y otro para los temas laborales.

jueves, 14 de abril de 2011

El Rut

Nadie podría discutir la importancia que tiene el rut en la vida de los chilenos. Desde que uno comienza a hacer actividades en sociedad, lo primero que se requiere es el rut. Rápidamente, hay que aprendérselo de memoria para poder estar tranquilo que por lo menos se va a superar la primera barrera de cualquier trámite burocrático al que uno se vea enfrentado. La segunda barrera tiene que ver con el acceso a sistemas On Line chilenos, en los cuales, casi siempre como parte del proceso de inscripción, se debe indicar el rut. Como resultado de esto, en algunos casos (como en los bancos), el posterior proceso de ingreso es mediante el rut. Este último punto abre una discusión enorme respecto a temas de seguridad informática asociados a este mecanismo de autenticación, pero esa es otra conversación.

El caso es que, si uno revisa todos los sitios, las validaciones, los formularios de registro, etc., cada uno tiene condiciones distintas para el ingreso del rut. Considerando las características del rut, los casos posibles de ingreso son:

CASO
NUMEROS
DIGITO
VERIFICADOR
GUION
PUNTOS
EJEMPLO
1
SI
SI
SI
SI
99.123.456-7
2
SI
SI
SI
NO
99123456-7
3
SI
SI
NO
NO
991234567
4
SI
NO
NO
NO
99123456

En la tabla anterior hay combinaciones que faltan, pero las omití porque no son usables (ejemplo, sin numeros y sólo dígito verificador).

Considerando el escenario anterior, lo más increíble es que todas las combinaciones son válidas y están vigentes en los sitios que me ha tocado ver. Llega a tanto, que incluso hay sitios que “corrigen” o formatean el rut mientras uno escribe para ajustarlo al formato (tema aparte la usabilidad de esta solución).

Una primera solución es la de estandarizar, a nivel de industria, el mecanismo de ingreso/registro de un rut. Obviamente, creo que esto es imposible pero, si algún día sucediera, creo que resolvería varios problemas.

La segunda opción es incorporar a los validadores, interfaces de usuario, etc., los filtros necesarios para hacerle la vida fácil a los usuarios. Por ejemplo, en este escenario, ¿es relevante mostrar una alerta a un usuario indicando que el rut ingresado no es válido porque se esperaba con puntos y el usuario lo ingresó sin puntos? ¿o al revés? Yo considero que no y, por lo tanto, creo que cuando uno ve estos escenarios lo más probable es que la validación/formateo del rut se esté realizando a nivel capa web para evitar trabajo posterior y/o para asegurar un ingreso “correcto” hacia los sistemas internos (esto, claramente, es un punto de falla importante).

Por lo tanto, creo que lo más recomendable, antes de perder tiempo en ventanas de aviso, capturadores de eventos, detección de teclas y secuencias, etc., es símplemente intentar validar lo que sea que el usuario ingresó. El punto de partida para esto, además de hacer un trim(), es eliminar los “.” siempre y continuar. El resto, es historia.

miércoles, 13 de abril de 2011

El Call Center

Hace algunos meses me subscribí a la revista Wired. Hasta el momento me habían llegado los números correctamente (Enero y Febrero) pero, Marzo y Abril no llegaron. No quiero pensar que a alguien le gustó la revista y se la quedó en el camino a mi trabajo y/o en el camino de la entrada a mi oficina. Por lo tanto, me fui por el camino natural e ingresé a la página web de USA para buscar la información de la subscripción. Como era de esperar, la página tiene todo un módulo de atención a subscriptores. Ingresé superando todas las medidas de seguridad necesarias, captcha incluído, y comencé a buscar la información de cómo hacer mi reclamo. La opción electrónica sólo me daba la opción de extender la subscripción dos meses a costo de no hacer el reenvío de las revistas pendientes. Esta opción no es lo que yo quería, por lo tanto llamé vía Skype al call center de subscriptores de USA, típico número del típo 1-800-XXXXXX.

Cuando me comuniqué me contestó un IVR bastante más sofisticado que los que había usado anteriormente. Básicamente, en vez de apretar botones del teclado del teclado, había que hablar en inglés y contestar preguntas (Yes, No, etc.). La última acción antes de que me derivaran con un humano (je, je), fue ingresar el número de mi subscripción. Para esto, obviamente, había que utilizar el teclado. La primera pregunta que me hizo la operadora fue cuál era mi Zip Code (Código Postal en USA). Le indiqué que estaba llamando de afuera de USA, por lo que inmediatamente me pidió le indicara mi dirección y mi correo electrónico. Superada esta validación me dijo (traducido al español de ahora en adelante):

OPERADOR - Buenas tardes Sr. Bertini, ¿en qué puedo ayudarle?
YO - Tengo un problema. Mi subscripción…..bla…bla…bla… no me han llegado dos revisatas…bla…bla…bla… ¿qué puedo hacer?
OPERADOR - Bueno, la de Abril está a punto de ser despachada, así que le rogaría espere a que le llegue en aproximadamente 3 semanas. La de Marzo voy a pedir el reenvío, por lo que, debiera llegarle en el mismo tiempo. ¿Algo más que pueda ayudarle?
YO - No, muchas gracias, esperaré a que me lleguen las revistas.
OPERADOR - Ok. Si no le llegan, por favor no dude en contactarse con nosotros. Que tenga una buena tarde.

Además de destacar la amabilidad de la persona que me atendió, quisiera hacer notar un pequeño detalle MUY importante a mi entender en la secuencia anterior y que tiene que ver con la primera parte del diálogo. Cuando el operador recibió mi solicitud ya sabía quien era yo porque el IVR me había pedido mi información de subscripción pero, más importante que esto, es que esa información fue traspasada al operador correctamente. Inmediatamente me saludó por mi nombre.

Hace poco tuve que hacer una llamada a un call center en Chile. La secuencia es más o menos similar: contesta el IVR, si usted es cliente marque la opción 1, digite su rut, espere un momento, será transferido a un ejecutivo. Después de esperar un momento con la típica música de fondo y los mensajes salvadores (nuestros ejecutivos están ocupados por favor espere un momento, su llamada es muy importante para nosotros, esta llamada podría ser grabada, etc.), me atendió un ejecutivo. Hasta aquí iba todo bien, salvo cuando comenzó la conversación y me dijo:

- Buenas tardes, ¿con quien hablo?

Primer error grave. Si el IVR solicita el ingreso del rut, lo mínimo que debiera suceder es que eso sirva de algo. Si sólo sirve para filtrar a los clientes de los no clientes, creo que se está perdiendo una oportunidad de oro para mejorar el nivel de atención. Después de explicarle mi problema, me hizo la segunda pregunta:

- ¿Cuál es su dirección?

Segundo error grave. Símplemente, dado el primer error, toda la conversación a continuación giró en torno a preguntas y respuestas que la persona seguramente ya tenía en su sistema. De ahí en adelante, la conversación fluyó, no con la misma rapidez que con la de USA y, bueno, creo que algún día tendré una respuesta a mi consulta.

El otro día dieron en la tele un mini-reportaje acerca de las personas que atendían en los Call Center. Efectivamente, mostraron grabaciones de audio que ayudan a sensibilizar respecto al tipo de llamadas, estados de ánimo, impresiones, exigencias, etc., de los clientes que llaman. Difícil la misión de acoger y entender las solicitudes planteadas de esta manera. Admirable. Sin embargo, el tema que menciono acá va más allá de esto y es más transversal.

¿Para qué se pide la información si no sirve de nada? ¿Para que perder esta oportunidad de acelerar el tiempo de solución entregándole al mismo ejecutivo la información apenas contesta el teléfono?

Quisiera pensar que no es un problema tecnológico ya que en otras partes funciona así, pero, no logro entender cuál es el problema entonces. Me encantaría poder saber.