jump to navigation

M-009 25.3.17

Posted by Migsar in Ideas, Uncategorized, Vida.
Tags: , , , , , , , , , , ,
1 comment so far

Después de la frustración de no poder hacer una simple transferencia bancaria decidí escribir un poco sobre mis experiencias y algunos consejos para mejorar el servicio. Me encantaría que algún alto ejecutivo de bancos mexicanos diera con este artículo, en particular, alguno de Banorte, de cualquier modo, creo que puede servir a cualquier usuario de banco para una reflexión sobre el estado de las cosas en México. Por facilidad de análisis, dividiré este post en dos partes: la primera sobre la filosofía de servicio y la segunda sobre cuestiones un poco más técnicas que están fallando en los sitios del país.

La experiencia

Quiero hacer una transferencia para ayudar a mi novia a pagar un curso, sé que por seguridad necesito el token, además tengo el servicio de Banorte móvil.

  1. La aplicación móvil me deja perder todo el tiempo llenando el formato de transferencia rápida para decirme al final que no puedo hacer la transferencia porque se sobrepasó el límite diario, lo cual, en esencia, no es cierto, intento realizar una operación por un monto mayor al permitido diario, pero no he realizado ninguna operación así que el límite aún no se ha sobrepasado.
  2. En la aplicación web cambio un límite, no sirve para nada.
  3. No puedo agregar un destinatario a una transferencia normal desde la aplicación móvil, para hacerlo desde la aplicación web necesito tener acceso adicional al email registrado.
  4. Intento quejarme en la aplicación, no se puede si no lleno toda la forma, son un par de datos, pero no quiero teclearlos, además deberían tenerlos si está super autenticada mi app móvil porque a banorte le preocupa mi seguridad.
  5. Termino por enviar un Twitter, porque sé, por experiencias previas, igual de inútiles, que les importa cuidar la percepción sobre la empresa y responden muy rápido cuando las cosas se hacen “públicas”.

Los mensajes públicos, respuesta casi inmediata, 1 minuto!

Cultura y filosofía de servicio

Un pequeño análisis de lo que sucedió. En Twitter responden rápido porque las cosas se viralizan, la opinión pública puede ser muy peligrosa y en algunos casos es muy difícil revertir la percepción de una empresa. Puede no haber mucha información de contacto, no servir bien la parte de las quejas, pero en el momento en que va a redes sociales el usuario al menos es escuchado. Hablar por télefono es esperar al menos, 12 minutos en línea (son estadísticas basadas en mi experiencia personal), mandar quejas por web app o móvil app, no tengo idea si sirva, alguna vez envié un email, otras un mensaje y nunca recibí respuesta, ponerlo en una red social, ¡una respuesta de menos de un minuto! Lo más rápido posible se saca la parte perniciosa de la opinión pública, es decir, el problema lo vemos en privado, la atención y la respuesta es pública. Ahora, no estoy diciendo que sea mala, inútil quizá, pero amable y pronta definitivamente y mala en ningún caso.

Seguridad por diseño o seguridad por ocultamiento

Quizá es un principio de seguridad informática pero aplica perfectamente a la atención al cliente, simplificando, seguridad por diseño es cuando es inherentemente seguro, es decir, está diseñado para que sea difícil acceder aunque sepas donde está la entrada, seguridad por ocultamiento se trata de esconder la entrada, quizá no sea nada segura, pero los recursos no se invierten en hacerla segura sino en esconderla para que poca gente la vea. ¿Qué tiene que ver con la filosofía de servicio? Uno puede gastar los recursos mejorando la calidad de los servicios o gastarlos ocultando las quejas. Se trata de lograr un equilibrio, tener atención al cliente para las quejas y hacerlas públicas, pero efectivamente buscar que se solucionen, no sólo en palabras.

Uno debe de ser el primero en consumir su producto

Todos los ejecutivos están al pendiente de sus productos, claro, es dinero, pero los usan para resolver sus problemas, ellos, personalmente, sin intermediarios. Tristemente me ha tocado que no es el caso, parte de las aptitudes de un ejecutivo es saber delegar responsabilidades, y los productos se ocupan de la parte mecánica mientras que los ejecutivos de la estrategia, los equipos de trabajo terminan diseñando funcionalidades que nunca han usado y posiblemente nunca usen en un ambiente no controlado, son expertos en lo que hacen, pero no tienen un objetivo claro. Siempre hay diferencia entre teoría y práctica, sin embargo, se trata de hacer que la práctica sea lo más fiel posible a la teoría. ¿Cuántos ejecutivos utilizan la banca personalmente y de manera eficiente? ¿Cuántos delegan estas responsabilidades a una persona cuyo tiempo vale menos, es decir, puede dedicar más tiempo a batallar con una aplicación inútil? Aquí hay un aspecto clasista que aunque crea que es un grave problema en el país no trataré.

El cliente se adapta al negocio, no el negocio al cliente

Cuando las opciones son limitadas y los clientes son cautivos es válida una postura de “si no te gusta lo que te ofrezco puedes irte con otro”, sabiendo que el otro está igual porque más que competencia abierta es un acuerdo de distribución del mercado, no te metas conmigo y no me meto contigo. Nuevas alternativas, convenios, posibilidades, todo esto sólo sucedera después de un congreso o reunión nacional en donde todos los que comparten un tajada del mercado acuerdan que es competencia justa dar un “mejor” servicio al usuario.

Soluciones para individuos sobre mecanismos de solución

Si como individuo haces saber que puedes ser una piedra en el zapato solucionan tu problema, y, como individuo, te olvidas del problema. Al final a nadie le importan los mecanismos para denunciar injusticias, de hecho, no importan las injusticias desde un tratamiento ético o moral, no existe una definición de injusticia más allá de “lo que no me hubiera gustado que me sucediera en esa situación”. En una sociedad desigual uno aprende a ignorar al otro y preocuparse sólo por uno mismo, se pierde la esperanza en la sociedad y se busca el bienestar personal sobre el colectivo

Aspectos técnicos

La parte técnica está muy ligada al interés por el servicio al cliente, sin embargo, hablo de aspectos particulares, me da gusto que hayan llegado hasta aquí. Esta es la interfaz del móvil, quizá en algún post futuro hable sobre el resto de opciones y la carencia de algunas que considero indispensables. Como se mencionó arriba, el diseño debería de ser hecho por alguien que tenga una idea muy clara de las necesidades que tiene que satisfacer el producto. A continuación muestro la pantalla de captura de la transferencia rápida, después de esta aparece una pantalla de confirmación, después aparece una forma para capturar el password y el token, después se hace una petición para validar las credenciales que tarda un par de segundos y finalmente se le informa al cliente que ha excedido el monto de transferencias, ¿de verdad es necesario todo esto? Si el límite para transferencias es fijo y el que se menciona arriba en mensaje privado y no aparece en la app por ningún lado ($1,200 pesos por operación, $7,000.00 pesos diarios y $19,000.00 pesos por mes) ¿no sería posible validar desde que se pone la cantidad y evitar la petición al servidor y el costo de recursos y perder el tiempo del cliente? No sólo es la cuestión de este caso, es el diseño detrás de la aplicación. Por otro lado, abajo aparece la parte de seguridad del nuevo diseño de la app web, en la versión anterior había como 20 o más límites y configuraciones, si se están usando los anteriores creo que deberían seguir apareciendo, si no, creo que este debería verse reflejado en otras cosas, es decir, congruencia.

La especialización es buena, cada tarea tiene dificultades únicas

Es un problema que considero muy grave y general en México, seguimos con la mentalidad del éxito individual. Se necesitan expertos para la parte de seguridad, conectividad, desarrollo web, desarrollo móvil, diseño de APIs, experiencia de usuario, interfaz de usario. No se trata de buen o mal programador, la cadena es tan débil como el más débil de los eslabones, esto también aplica a la estructura general de la organización, es bueno que exista una respuesta rápida y atenta al usuario en las redes sociales, pero por qué sólo en las redes sociales, los usuarios percibimos el todo como el servicio, no las partes.

Web APIs y su utilidad

Creo que es un término desconocido en México en casi todos los círculos menos en el de programación, se trata de interfaces a las posibilidades de información o acción en sitios o aplicaciones, para una visión general recomiendo la entrada de wikipedia de Web API. Por supuesto, para aplicaciones bancarias se necesita una muy buena seguridad en el API, pero no es mejor que la que se necesita al hacer la información accesible en la red. Las APIs permiten una mejor escalabilidad usando microservicios y también permiten que otros desarrolladores creen soluciones de calidad si el banco no puede darse abasto, más sobre eso en el próximo apartado, además el hecho de pensar en un API permite pensar en una política definida de manejo de datos y establecer fronteras claras sobre que parte tiene que ser privada y que parte no. No sólo permitiría mejores aplicacaciones para acceso al estado de cuenta, también permitiría pensar en un ecosistema mucho más rico de servicios financieros, y en la posibilidad de involucrar machine learning, analytics y otros trending topics, al final, la entidad financiera contratará consultores en estas áreas, no puede ser de otro modo por el grado de especialización, pero si podría ahorrarse el gasto y ofrecer una mejor calidad con una API pública.

Trabajo en equipo y colaboración

La especialidad de Banorte son los servicios financieros, no el desarrollo de aplicaciones, y esto es evidente cuando uno utiliza sus portales, sucede lo mismo con todas las instituciones financieras en México y en el mundo. No todo se tiene que hacer en casa, por supuesto, hay partes que tienen que ser internas, desde la administración de información que es parte esencial del banco hasta algunos detalles de confidencialidad, sin embargo, al hacer un acceso web se entiende que parte de los datos tendrá que ser accesible desde internet, esa misma parte puede ser gestionada por entidades externas debidamente autorizadas. Se trata de un gasto menor y de permitir una competencia externa que beneficia la calidad final para el usuario. Finalmente pienso que tiene que es algo que habla del orden interno de la organización, relacionándolo con lo mencionado en el principio de seguridad por diseño u ocultamiento, que una empresa crea que no puede abrir nada para mí, invariablemente significa que tiene un desmadre con sus datos por lo que mover cualquier hilo tiene consecuencias en el resto, tarde o temprano tiene que cambiarse por ser una desventaja en costos de operación.

Módulos y aplicaciones

El usuario percibe el servicio como un todo, es un monstruo con distintos tentáculos, no se trata de distintos monstruos. Además, en teoría, deberían ser la misma, desde el punto de vista de diseño de software, sí, son más vectores de entrada a un sistema seguro, pero es igual de malo el hecho de aislar los diferentes sistemas y tener incongruencias internas en los datos si se compromete alguno de ellos. Existe un principio que habla de no repetirse a sí mismo, mientras más veces aparezca algo en el código en más lugares se tendrá que hacer un cambio en el caso del cambio de las necesidades, en más lugares se puede equivocar un programador y en más lugares puede haber una falla de seguridad. Finalmente, el usuario termina por confundirse y buscar alternativas más sencillas.

Conclusiones

Al final, lo que pienso es lo siguiente. Hace unos años pensaba que Banorte era un banco excelente por el servicio que me han brindado, sigue bien posicionado, pero ha descendido algunos peldaños. Pienso que Banorte sabe bien que a muchos no nos gusta su rediseño del sitio, por eso sigue habilitada la opción de usar el sitio anterior, pero pienso que no sabe que no se trata de un capricho de gente con miedo al cambio sino de una cuestión de problemas de diseño del nuevo sitio. Los usuarios ahora sabemos que hay cosas que sólo podemos ver y cambiar en la versión vieja, no son exactamente compatibles con la versión nueva, hay cosas que sólo se pueden cambiar en la versión nueva, hay cosas que sólo aparecen en la versión web, uno tiene que dominar tres sistemas para hacer uso de la banca electrónica. Finalmente, quiero decir, que los de Twitter de Banorte me caen muy bien porque atienden muy rápido y amablemente, pero están atados a la hora de ofrecer soluciones y que he tenido peores experiencias en Bancomer o Santander, el hecho de que escriba sobre Banorte es algo circunstancial. Ojalá algún ejecutivo lo lea y haga algo pronto, pues aunque opciones web como Bankaool tienen las mismas deficiencias, existen criptodivisas y nuevos jugadores en el ecosistema financiero que están cerca de ofrecer mejores alternativas para el cliente.

Anuncios

Una breve introducción a la programación de QGIS 17.7.15

Posted by Migsar in Computación, GIS, Tecnología.
Tags: , , , , , , , , , , ,
add a comment

A continuación explico de manera breve los aspectos básicos de programación de QGIS. Es un error creer que se tiene que entender todo a la primera. La mayoría de los conceptos se verán a profundidad gradualmente al ser necesarios para el desarrollo de plugins, sin embargo, es bueno tener un panorama general que sirva como marco de referencia para los nuevos conocimientos.

QGIS

QGIS es un programa pensado para computadoras de escritorio que permite utilizar Sistemas de Información Geográfica, desde la visualización hasta la creación, edición y el posterior procesamiento o análisis. Es compatible con los formatos de otros programas comerciales y puede trabajar tanto con datos raster (imágenes) como con datos vectoriales.

C++

Es un lenguaje compilado, es el lenguaje en el que QGIS está escrito. Por ser compilado se necesita una versión diferente del programa o plugin para distintos tipos de computadora. Además, es mucho menos amigable que Python para los programadores principiantes. La interfaz gráfica de QGIS se hizo en C++ mediante una librería llamada Qt que se distribuye de manera libre, esta librería tiene una serie de componentes visuales que permiten crear programas, éstos van desde las distintas ventanas y cuadros de diálogo hasta las áreas para imágenes y botones. Es posible agregar plugins a QGIS escritos en C++, lamentablemente no se trata del lenguaje de programación más popular porque tiene una forma de escribir estricta y a veces complicada. Afortunadamente existe una capa en Python que permite utilizar los componentes de la interfaz gráfica sin programar en C++, ocultando las funciones originales con funciones de Python.

Python

Es un lenguaje de programación interpretado, es decir, el programa que lo interpreta (entiende) es diferente para cada plataforma pero los programas escritos en Python son exactamente iguales en todas las computadoras, lo que es una ventaja al escribir y compartir código. Es el lenguaje preferido en el ámbito científico porque es bastante flexible, con una estructura amigable y con manejo incluido de números complejos. QGIS tiene una interfaz en Python desde la que es posible controlar prácticamente todos los aspectos de la aplicación. Lleva tiempo conocer la estructura de objetos que la compone (en la próxima sección se habla al respecto) y pienso que esto es una de las barreras más comunes que enfrentan los usuarios que quieren empezar a utilizar la parte programática de QGIS, pues incluso es difícil empezar a buscar la información en la documentación referente a los distintos componentes.

Programación Orientada a Objetos

Existen libros en donde está muy bien explicada la programación orientada a objetos (recomendar uno) pero se tratará aquí de manera muy superficial para ubicarnos en el contexto necesario para empezar a programar plugins de QGIS. Generalmente se aborda el problema programando con clases y objetos reales y simulando su comportamiento y características, no obstante, creo que así es difícil percibir como se relaciona con un programa de cómputo. Es necesario empezar con ese ejemplo, pero no dejarlo ahí sino aterrizarlo en nuestra materia.

Primero los conceptos, existen tres que me parecen indispensables: objeto, propiedad y método. Existen otros conceptos que son básicos en un tratamiento computacional riguroso, pero que no mencionaremos aquí hasta que sean necesarios. La programación se trata de abstraer la realidad y general modelos, que consideran sólo las características que nos interesan.

Objeto

Si se considera de manera abstracta (indefinida, en el sentido del artículo indefinido en el lenguaje) se llama clase. Las clases representan componentes u objetos, por ejemplo, manzanas, patos, coches, plumas, etc. Estos objetos en el mundo real tienen ciertas características, como el sabor, color o funcionamiento. Es necesario incluirlas en nuestro modelo, aunque hay que tener cuidado de no incluir las características que complicarían innecesariamente el análisis. Las características se dividen en propiedades y métodos, la división es muy tenue y suele depender de los criterios del programador aunque existen ciertos parámetros considerados universales en la decisión.

Propiedad

Se refiere a características pasivas e inmutables por sí mismas. Por ejemplo, el color o el sabor de una manzana, el color o el tamaño de un pato o la velocidad máxima de un coche. En general se trata de datos descriptivos del objeto.

Método

Se refiere a posibilidades de acción o cambio, es decir, características activas. La manzana no tiene ninguna característica de este tipo a diferencia del pato, que puede hacer ruido, caminar, volar o nadar, si es hembra puede poner huevos, etc. El coche puede arrancar, detenerse, acelerar, frenar, abrir las puertas, la cajuela, cambiar de velocidad, etc. En general se trata de funciones, es decir, modificadores de los datos del objeto.

Algunas reflexiones sobre los objetos

Las definiciones anteriores quedarán claras con el uso y es importante saber que en programación siempre hay más de una forma de hacer las cosas, no existen formas incorrectas en términos generales sino que dependiendo del contexto hay formas que ofrecen ventajas sobre otras. Lo que para una persona puede parecer una función para otra puede parecer un dato, por ejemplo, con el pato, uno puede pensar que tiene tres métodos de desplazamiento: caminar, nadar y volar; alguien más puede decir que solo existe un método, desplazar y que el tipo de desplazamiento es una propiedad que puede tomar los valores caminar, nadar o volar. Las dos formas son válidas y la correcta dependerá del procesamiento que se necesite después, quizá solo es importante saber el estudio de las rutas migratorias y no importa el tipo de desplazamiento sino el origen y destino, por lo que resulta complicado escribir tres métodos y es necesario saber la posición espacial del pato, sin embargo, puede ser que se esté estudiando el metabolismo del pato y su consumo calórico diario, en este caso se requeriría una propiedad adicional que se refiera a la energía del pato pero además, no importa ni el origen ni el destino sino el tiempo que el pato pasa desplazándose y el consumo energético relacionado a cada forma por lo que tres métodos separados se vuelven la mejor alternativa. Pueden existir objetos sin propiedades ni métodos pero su utilidad es bastante limitada (o nula).

Ahora daremos un salto a lo abstracto, objetos propiedades y métodos en los programas de computadora. En esencia se trata de lo mismo, la ventana del programa es nuestro objeto padre (o madre) y tiene propiedades, como el tamaño horizontal y el tamaño vertical y métodos, como crear, cerrar, minimizar o detectar si el usuario hace click o mueve el mouse sobre ella. Las cosas se complican un poco si tenemos muchos botones como sucede en cualquier programa moderno, además de la pantalla de captura o visualización y los menús desplegables. Una forma de abordar el problema sería crear muchas funciones para cada uno de los elementos, pero rápidamente nos cansaremos de repetir código y veremos que surgen muchas generalidades, todos los botones se comportan de un modo similar, pueden parecer ligeramente presionados cuando el mouse está sobre ellos y completamente presionados cuando se les hace click, además, se trata de objetos dentro del objeto principal. Lo más fácil es decir que el objeto ventana contiene otros objetos más pequeños, cada uno con métodos y propiedades propios, una forma de representar esto es mediante una estructura de árbol invertida en la que la ventana principal está hasta arriba y los objetos descienden jerárquicamente, pues así como los botones son objetos también lo son los menús y las barras de herramientas; los primeros contienen opciones que pueden ser seleccionadas y las segundas contienen íconos que representan acciones.

APIs

Se conoce como API al conjunto de objetos disponibles para interactuar con una aplicación o biblioteca, el término significa Application Programming Interface, es decir, Interfaz de Programación de la Aplicación. El API es un término muy importante y con el que hay que familiarizarse pues es lo que se busca siempre que se quiere empezar a programar con alguna aplicación o librería en particular. En el caso de QGIS nos tendremos que familiarizar con dos APIs, uno para la parte visual y otro para el procesamiento de datos correspondiente a los sistemas de información geográfica.

Qt

Se mencionó anteriormente que Qt es una biblioteca de componentes (es común aunque semánticamente incorrecto llamar librería a la biblioteca por la similitud con library en inglés, yo uso intercambiablemente los dos términos y no me parece grave hacerlo siempre que se tenga claro el concepto de programación asociado). Se utilizará la documentación de Qt para todo lo que tenga que ver con la interfaz gráfica de QGIS, ya que los componentes no son particulares de QGIS sino generales a cualquier programa que use Qt.

La documentación se encuentra en:

http://doc.qt.io/qt-4.8/

Casi al final de la página aparece Qt API.

QGIS

El API de QGIS hace referencia a las funciones de C++, sin embargo, es accesible desde Python mediante el objeto iface, que se refiere a la interfaz de QGIS disponible para los plugins. Su documentación se encuentra en:

http://qgis.org/api/2.8/index.html

En ambos casos la documentación puede parecer abrumadora al inicio pero con el uso se irá aclarando.

APIs: Idea, diseño e importancia 30.3.14

Posted by Migsar in Computación.
Tags: , , , , , , , , , , , , , ,
add a comment

Un API (Application Programming Interface) es un concepto abstracto que especifíca como los componentes del software interactúan unos con otros. En un sentido básico el API favorece la implementación de la programación orientada a objetos pues permite definir las clases como abstracción de objetos del mundo real, con propiedades y métodos, pero además refuerza la encapsulación, al hacer que el usuario del API sepa como utilizarlo, que datos tiene que aportar y que datos recibirá, sin tener que conocer el funcionamiento interno del API y sin preocuparse de cambios en la implementación del mismo.

Con el crecimiento del tamaño de los proyectos de software el uso de APIs se ha hecho indispensable, pues cada vez es más necesario delegar responsabilidades para poder terminar un proyecto en tiempo y forma, esto se hace a través de bibliotecas o módulos de terceros que se incorporan al proyecto, en estos casos es indispensable el API y el conocerlo y su documentación pueden hacer la diferencia en la selección de uno u otro. Cuando el API se refiere a un software con una arquitectura REST (Representational State Transfer), inherentemente ligada a las redes e Internet, permite además otras ventajas, en particular, la implementación de un patrón de diseño MVC (Model-View-Controller), que se refiere a definir entidades abstractas discretas que sirven como modelo, es decir, representan a los objetos abstractos mencionados anteriormente, definir vistas, que sólo presentan los datos del modelo al usuario y, finalmente, conectar ambas mediante los controladores.

Con la virtualización, el Cloud y demás tecnologías recientes (RTC, Single-Page Apps, etc.), es cada vez más importante tener una idea clara de estos conceptos, pues la libertad y las alternativas son muchas pero es fácil perderse y complicar las cosas en lugar de simplificarlas. Creo que lo más importante es saber diferenciar correctamente la vista del modelo, existen muchos frameworks, en diferentes lenguajes de programación y para diferentes plataformas y estilos de desarrollo que facilitan el desarrollo de una app web basándose en MVC, sin embargo, es muy fácil empezar a mezclar las partes y terminar con sistemas supuestamente MVC, que no permiten obtener los modelos por separado, lo que significa que la app está fuertemente ligada a las vistas inciales y tendrá problemas de portabilidad y escalabilidad, que se necesitarán muchos ajustes cuando se intente migrar o mejorar la funcionalidad pues parte del modelo puede quedar en el controlador y que, en general, el uso de MVC es más una limitante que una herramienta.

Este video que muestra una visión de Apigee y Accenture sobre la importancia de las APIs en los desarrollos modernos, su dirección actual, y que enfatiza que esto ya no es exclusivo de programadores, sino que con el crecimiento de los servicios ofrecidos cada vez incluye a más personas y campos de trabajo, y el entenderlo es decisivo para el éxito de cualquier proyecto, el cliente no es sólo el que lo programa pues se utiliza como canal hacia el consumidor de los datos, se habla del dinamismo en la modelación e implementación de estos APIs y en que actualmente es algo demasiado distribuido, pero el API puede funcionar como punto de unión para servicios diversos y deb hacer esto transparente al usuario del API, también se menciona la seguridad como un factor crítico en estos tiempos. Definitivamente no podría explicar mejor que ellos el tema, por lo que sólo lo menciono para despertar su interés pero espero que se tomen el tiempo para verlo. Por último, algo que ellos mencionan: “Every business is now a digital business, and every executive needs to be able to understand the implications of technology trends and innovations for his or her company and industry.”

  • Relationships at Scale. APIs are the Common Channel to the Customer
  • Design for Analytics. The role of the API Supply Chain
  • Data Velocity. Guaranteed Speed and Reliability via an API Platform
  • Seamless Collaboration. Collaboration through the API Program
  • Software-Defined Networking. APIs unlock the Agility in Virtualization
  • Active Defense. API Management for Risk-based Security
  • Beyond the Cloud. APIs Connect the Cloud