¡No me hagas pensar!

domingo, 16 de agosto de 2015

La usabilidad es una cuestión que siempre me ha interesado y a la que suelo prestar atención. Por ejemplo, acostumbro a lanzar improperios al operar en la banca online, o incluso al retirar efectivo de un cajero automático... ¿Cómo puede ser que entidades de este tamaño tengan unas interfaces de usuario tan rematadamente malas? ¿De verdad no pueden dedicar varios miles de euros para hacer unas pruebas de usabilidad de estos sistemas que usaran diariamente millones de personas?... En fin, el tema de la usabilidad de estos sistemas merecería un artículo propio con ejemplos concretos.

Hoy quería hablar de un libro que he leído estos días. Trata sobre la usabilidad de los sitios web y cómo conseguir que los visitantes entiendan el contenido y se sientan cómodos en el sitio. Es sabido que si la gente se encuentra cómoda en un sitio permanecerán más tiempo en el mismo (y aumentarán las opciones de que interaccionen del modo que queremos...). El libro en cuestión se llama "¡No me hagas pensar!", de Steve Krug.

Portada del libro sobre usabilidad de los sitios web

La idea principal del libro es sencilla e indiscutible: Lo importante para que un sitio web sea "fácil de usar" no está en que cualquier contenido esté "a dos clics de distancia", o que el contenido "hable el lenguaje del usuario"... Por supuesto, tampoco se trata de que el sitio sea bonito o agradable... Lo principal es que el sitio sea tan simple que el usuario no tenga que pensar para entender su funcionamiento o su organización...

Los internautas no leen las páginas con el detenimiento y la atención que los diseñadores o los programadores piensan. En lugar de leer, las hojeamos buscando algo que nos interese o cubra suficientemente nuestras expectativas... No nos leemos las instrucciones ni buscamos el funcionamiento óptimo de las cosas... Nos las arreglamos para conseguir lo que deseamos (aunque no entendamos como funciona o aunque sea de un modo opuesto a como el diseñador pensó que lo haríamos).

Es un libro del año 2005, y eso se nota en los ejemplos que pone y en la ausencia de cualquier referencia a los dispositivos móviles (hoy en día los diseñadores han de apañárselas para que los sitios se vean bien en todo tipo de pantallas).

En cualquier caso, es un libro que vale la pena ya que las ideas que aporta siguen siendo válidas al cien por cien. De hecho, aunque el libro habla de sitios web, las mismas ideas son extrapolables a todo tipo de software... Y, por supuesto, al software de Business Intelligence.

Inevitablemente, al leer el libro, me han venido a la cabeza situaciones donde el usuario de BI llegaba al resultado correcto por los caminos más extraños (desde mi experto punto de vista). Por ejemplo, ¿quién no ha visto un usuario que exporta a Excel una tabla de su mega sistema BI para añadir una columna con un cociente o para añadir unos subtotales? Por supuesto, las herramientas de BI tienen esas funcionalidades pero están escondidas detrás de varias trampas infranqueables para el usuario medio. Son trampas sutiles, invisibles para el experto, pero que están ahí y requieren que el usuario piense y entienda mejor el funcionamiento intrínseco de la herramienta. Lógicamente, el usuario prefiere el camino conocido y ancho de la hoja de cálculo. El Excel es territorio amigo, desaparecen las incertezas y el usuario sabe que llegará al resultado correcto. En cambio, manteniéndose dentro del marco de la herramienta BI, el resultado final es incierto y las posibilidades de frustración casi aseguradas.

Muchas personas que se encuentran con problemas con su herramientas de BI tienden a culparse a si mismos y no a la propia herramienta. La culpa es de la herramienta. Por supuesto. IMHO.

Si estás suscrito a este blog, o si eres un lector asiduo de este sitio, sabrás que en CRONO aspiramos a construir un software asequible y fácil de usar para construir informes, cuadros de mandos y hojas Excel... La clave de nuestro éxito será en que seamos capaces de detectar esas trampas sutiles e invisibles que frustran y paralizan al usuario medio... El software de BI ha de ser mucho más simple y fácil de usar que cualquiera de las alternativas tradicionales existentes hoy por hoy en el mercado... Se ha de poder usar sin pensar.

En esto estamos y estaremos.

¿Qué gráfico elegir?

domingo, 19 de julio de 2015

He encontrado en el blog de Extreme Presentation este interesante diagrama que muestra diferentes tipos de gráficos en función de la información que se quiera mostrar:

Qué gráfico elegir en un sistema Business Intelligence

Evidentemente, el diagrama es espléndido, y me enorgullece comprobar que Crono Analysis supera con nota el examen, ya que nuestro software de Business Intelligence es capaz de realizar la mayoría de estas visualizaciones.

Entre los pocos (y raros) gráficos que (aún) no podemos hacer están los gráficos de área 3D, las columnas de anchura variable, y alguno más... Son gráficos poco habituales... En cambio, somos capaces de representar algunas visualizaciones que no aparecen en la imagen superior, y que considero que son importantes... Me refiero, en especial, a los gráficos geográficos (¡mapas!), los gráficos de embudo, y alguno más.

La siguiente imagen muestra los gráficos que pueden hacerse a día de hoy con Crono:

Visualizaciones disponibles en Crono Business Intelligence

Como siempre, lo más destacable de Crono no es tanto el número o la cantidad de opciones (que como veis son muchas) sino la facilidad con las que el usuario puede realizar cualquiera de esta visualizaciones a partir de sus datos...

Seguiremos informando.

Business Intelligence fácil (y minimalista)

domingo, 12 de julio de 2015

Hola,

Esta semana estreno un nuevo diseño en nuestro blog de Business Intelligence fácil. El nuevo diseño es más sencillo y minimalista que el anterior. Es curioso que rediseño tras rediseño siempre busco la simplicidad y un aspecto limpio, elegante y profesional... Me pregunto cómo será el próximo rediseño... ¿Y cómo serán los blogs dentro de 10 años? ¿Y cómo serán las aplicaciones BI dentro de 10 años? De lo que estoy seguro es que primarán las interfaces sencillas y muy usables. Se acabaron esas aplicaciones con decenas de botones o funcionalidades que nadie usa... El siguiente chascarrillo muestra claramente lo que quiero decir....

La simplicidad y las tendencias minimalistas marcan sin duda el camino

En fin... El cambio de hoy es probablemente el cambio estético más relevante desde que inicie este blog hace más de 7 años... Aquí dejo las imágenes para recordarlo:

Este era el antiguo diseño del blog BI fácil



Y este es el diseño del blog BI fácil hoy

Como no podía de ser de otra manera, en esta ocasión hemos pensado especialmente en los lectores desde dispositivos móviles. Si lees este blog desde un móvil o tableta, verás que la lectura es más cómoda y ya no es necesario hacer zoom para leer el texto cómodamente, etc...

¿Lo veis todo correctamente?

Espero que os guste.

Dimensiones lentamente cambiantes (SCD)

viernes, 3 de julio de 2015

Un concepto importante en el diseño de los procesos de aprovisionamiento de un DWH es la estrategia de carga de las dimensiones. No es la primera vez que hablo sobre esto.

Trataré de explicar en este artículo cómo se deben cargar las dimensiones de un DWH. Conceptualmente, no es algo complejo en absoluto.

Se suele hablar de "dimensiones lentamente cambiantes" pero desde mi simplificador punto de vista esa es una expresión desafortunada. Todas las dimensiones son "lentamente cambiantes". Me explico:

  • El término dimensiones lentamente cambiantes (SCD, por sus siglas en inglés: Slowly Changing Dimensions) hace referencia a que los datos de las dimensiones van cambiando poco a poco a lo largo del tiempo. No son incrementales como los "hechos". Cada día hay nuevas ventas o pedidos, sin embargo la categorización de los productos o clientes va cambiando poco a poco a lo largo del tiempo.
  • Las dimensiones pueden ser estáticas como los meses, o cambiar muy muy lentamente (como el nombre de los municipios), o cambiar algo más rápidamente (como la edad de los clientes, o la clasificación de los productos en familias...). Entre dos días consecutivos, nuestro maestro de clientes puede crecer un poco, o puede aparecer un nuevo producto esporádicamente.
  • En realidad, no sé cuales son las dimensiones rápidamente cambiantes. Dependerá, en todo caso, de la paciencia del observador el determinar si los cambios son más rápidos o más lentos.

Por lo tanto, a todos los efectos, hablar de estrategias SCD es hablar del modo de cargar dimensiones. Punto. Las dimensiones son así.

Si buscas por internet, verás que se habla hasta de seis tipos de estrategias de carga SCD. La Wikipedia también habla de un montón de tipos de carga SCD.

Desde un punto de vista práctico, sin embargo, solo dos tipos de carga SCD merecen nuestra atención. Las cargas tipo 1 y las cargas tipo 2. El resto solo tienen interés desde un punto de vista académico (o histórico). En la práctica, hoy en día, lo único que hemos de tener en cuenta a la hora de diseñar la estrategia de carga de una tabla de dimensión es si queremos guardar la historia de los cambios o no.

Dimensiones Tipo 1: Se sobrescriben los valores

Es el tipo de carga más básico y el más habitual. En este caso, se sobrescriben los valores existentes en el maestro con los nuevos valores.

Pensemos en el caso del pueblo burgalés de "Castrillo Mota de Judíos" que antes se llamaba "Castrillo Matajudíos". ¿Cómo debemos cargar la tabla de municipios de nuestro datawarehouse? ¿Es importante conocer la fecha en que ese pueblo cambio de nombre? ¿Cuando consultemos las ventas de los habitantes de Castrillo Mota de Judíos queremos que se incluyan también las ventas de cuando se llamaba Castrillo Matajudíos?

Evidentemente, no. No nos importa. Ese cambio de nombre será importante desde un punto de vista histórico y será relevante políticamente como muestra de integración y respeto cultural, etc. Sin embargo, en nuestro DWH de llamadas telefónicas, o de ventas, o de acciones comerciales... es un cambio irrelevante. No es necesario guardar esa historia. Nos basta con el nombre actual.

Para finalizar este tema, un apunte relevante: Que no nos interese guardar la historia de cambios no implica que no debamos mantener campos de auditoría. Todas las tablas de dimensión deben tener los campos de fecha de alta, fecha de baja y fecha de modificación. Es una buena práctica tener siempre estos campos de auditoría y nos será de utilidad para detectar incidencias... Recuerda:

Dimensiones Tipo 2: Se guarda la historia de cambios

En los casos que sí que nos interesa guardar la historia se utiliza la estrategia conocida como "SCD Tipo 2". En este caso, la tabla de dimensión incluye los campos de fecha inicio de vigencia y fecha fin de vigencia. Estas fechas nos permiten determinar en que estado estaba la dimensión en cualquier fecha del calendario.

Esta estrategia ETL de aprovisionamiento se utiliza, por ejemplo, para guardar la estructura comercial de una organización (quién es el responsable de un determinado producto o zona en un momento determinado...). También es habitual en otros escenarios: En un entorno CRM puede interesar conocer los cambios de domicilio de los clientes, o sus cambios de preferencias...

Siempre que nos interese guardar la historia de cambios utilizaremos fechas de vigencia (ya sea en el maestro principal o en una tabla auxiliar...).

En estos casos, tampoco hemos de olvidar los campos de auditoría (fecha de alta y fecha de modificación, al menos...).

Cómo se hace

Todo lo anterior está muy bien, ¿Pero cómo se hacen estas cargas? ¿Cuál es el código SQL o qué herramientas tenemos para aplicar correctamente estas estrategias de carga?

Lo comento otro día que hoy ya me he alargado suficiente. Suscríbete al blog si no quieres perdértelo... :-)

La clave para aplicar metodologías ágiles correctamente

jueves, 25 de junio de 2015

Tras casi 20 años en el mundo de la consultaría Business Intelligence, como consultor y como cliente, he cometido todos los errores que se pueden cometer... como consultor y como cliente... Eso me permite hablar con cierto conocimiento. Actualmente, no soy exactamente lo uno ni lo otro, por lo que puedo desvelar algunos secretos de tirios y troyanos con cierta libertad :-)

La semana pasada hablaba de las "metodologías ágiles" de un modo algo teórico. Hoy trataré de explicar, siempre desde mi personal punto de vista, la cuestión diferencial de este tipo de proyectos y algunas consecuencias prácticas muy importantes. Hablare de LA CUESTIÓN.

En último artículo decía que los proyectos ágiles debían entregar resultados de una manera frecuente, continua e incremental. Esa es la clave. De modo orientativo, hablaba de entregar resultados cada 3 o 4 semanas... Pero podrían ser igualmente 5 o 6... A estos periodos de tiempo se les suele denominar "sprints" o "iteraciones" (yo prefiero este último término).

El contrato

Antes de hablar propiamente de las iteraciones conviene recordar cómo se contratan los proyectos (ágiles o no), porque una cosa es decir que cliente y consultor deben colaborar codo con codo con independencia del contrato, y otra cosa es hacerlo. No es lo mismo predicar que dar trigo.

Tradicionalmente han existido y existen dos tipos de contratos claramente diferenciados:

  • Contratos por horas. Oh, los proyectos por horas. Escasos y deseados. Es la gloria de cualquier consultaría. Cualquier retraso es siempre compensado por el cliente. Si después de 5 meses el proyecto aún no está terminado, es porque falta análisis, diseño, pruebas o lo que sea. Por supuesto, no es difícil de imaginar que el cliente evita contratar proyectos por horas, y este tipo de contratos se reserva para mantenimientos, pequeños evolutivos, bolsas de horas, o simple subcontratación de recursos....

  • Proyectos a precio cerrado. En este caso, el alcance y el precio es acordado al principio del proyecto y cualquier retraso es asumido por el consultor (de los "adelantos" ya tal). Teóricamente es todo muy sencillo: Solo es necesario calcular los materiales que harán falta, las nóminas del equipo, añadir un margen, etc. Este es, evidentemente, el método preferido por el contratador.

No desvelo ningún secreto al señalar los efectos indeseables que generan estos tipos de contratos. Las consultoras están obligadas a sobrevalorar el esfuerzo de cualquier proyecto para protegerse de posibles retrasos. Y los clientes utilizan la fuerza que les proporciona la aceptación del proyecto para alargarlo y pedir extras a base de lecturas imaginativas del "alcance". O requerimientos de última hora. O por mis cataplines:

SIN ESTO QUE PIDO AHORA EL PROYECTO NO SIRVE PARA NADA (Super jefe en la reunión de cierre)

Por supuesto, ninguna consultora puede tolerar tener un equipo de 5 o 6 personas durante un par de meses cerrando flecos y sin facturar. Conozco un amigo que ha visto equipos de 10 personas trabajando "gratis" (de manera no planificada) durante meses. Por supuesto, se buscarán el modo de facturarlos y al cliente no le saldrá gratis (se facturará en el siguiente proyecto, ya sea sobreestimando los costes o reduciendo la calidad).

En serio, clientes y consultoras, los REYES NO EXISTEN.

Esos contratos tradicionales tienen sentido para contratar la construcción de una autopista o para hacer los planos de una casa. El alcance y los requerimientos en esos casos están claros, y clientes y proveedores han participado en proyectos similares. En el caso de la consultaría tecnológica (estoy hablando de proyectos de desarrollo, y específicamente de Business Intelligence), el alcance esconde sorpresas y los requerimientos se van descubriendo tras cada reunión. El grado de indefinición y los riesgos son mucho más elevados en nuestro caso. Si no cambiamos la manera de trabajar, con independencia del tipo de contrato escogido, es solo cuestión de tiempo que clientes y proveedores se estén engañando mutuamente... y sabiendo mutuamente que son mutuamente engañados. No os riáis que hablo en serio. Conozco un amigo que pedía 10 manzanas a 1 euro porque necesitaba 2 sandías de 5€. En fin...

Por lo anterior, creo que la apuesta por las metodologías ágiles ha de reflejarse de algún modo desde el contrato mismo. En caso contrario, más pronto que tarde empezarán a surgir bandos y tiranteces que afectarán negativamente al proyecto... Más controles, más seguimientos, más listados de cosas con las que defenderse o atacarse.... Y menos entregas frecuentes.

La solución

DISCLAIMER: La solución que propongo es puramente teórica, y forma parte de una guerra que de momento voy perdiendo. No penséis que hablo por experiencia. Cualquier cambio es complicado, y clientes y consultoras seguirán empleando sus viejas armas para defender lo que creen que los beneficia. Se desconocen los efectos a largo plazo. Si estás embarazada o crees que puedes estarlo, consulta tu abogado. No emplear sobre lactantes.

La solución es trabajar por iteraciones. No es un proyecto a precio cerrado (pero se le parece), ni es un proyecto por horas o por jornadas (pero se le parece).

En un proyecto por iteraciones el precio es conocido (lo que gusta al cliente... y también al consultor) y la duración también es conocida de antemano (lo que gusta al consultor... y también al cliente).

La teoría es relativamente sencilla:

  • En lugar de planificar un proyecto de 9 meses con 3 meses de análisis, 3 meses de diseño, y 3 meses de construcción, debes planificar un proyecto de 9 iteraciones de 1 mes cada uno.
  • Cada una de estas iteraciones tendrá un entregable. Insisto, cada iteración debe tener un entregable funcional. No un diseño o un powerpoint. Software que funciona. Debemos entregar valor para el cliente en cada una de las iteraciones.
  • Debemos empezar desarrollando aquellos aspectos más importantes y prioritarios (siempre y cuando estén suficientemente definidos).
  • Cada iteración tendrá su propio alcance. Al comenzar la iteración, ese alcance debe estar suficientemente acotado (sí, hemos de ser capaces de describir suficientemente el resultado de un mes de trabajo).
  • La iteración se cierra en la semana prevista, por definición. Se entrega lo que ha podido hacerse. El cliente debe revisarlo, trasmitir su feedback y replanificar el proyecto.
  • El proyecto finaliza 3 o 4 semanas después de finalizar la última iteración. Punto. Se abonan todas las facturas y clientes y consultores se dan un beso.
  • Si es necesario, se contratan más iteraciones y se dan nuevos besos.

Este modo de trabajo tiene algunas implicaciones positivas que a mi me resultan evidentes (y a ti no sé):

  • Los consultores no necesitan sobreestimar costes ni los clientes necesitan un abogado para escribir o interpretar los requerimientos.
  • Clientes y consultores pasan a ser un mismo equipo. No hay razón para mirar el contrato ya que ambos saben que finalizará en la fecha prevista.
  • El equipo conoce el ritmo de trabajo. Cada mes hay un entregable, y existe visibilidad sobre lo que se ha hecho (y sobre lo que no ha podido hacerse).
  • Por lo anterior, es fácil replanificar mensualmente el trabajo y tener una idea realista sobre lo que se alcanzará al finalizar el proyecto (y lo que no y deberá renunciarse a ello o posponerse para siguientes proyectos).
  • El esfuerzo de "seguimiento" y "perseguimiento" es menor. No andamos valorando si tal funcionalidad está al X%. Eso es siempre una farsa. Deja al equipo de desarrollo trabajar y al finalizar la iteración tendrás el resultado.

Y algunas implicaciones negativas... ¿negativas?

  • El cliente debe involucrarse más. Debe ir definiendo y validando el proyecto durante mucho más tiempo. Esto no es como comprar un coche que te entregan las llaves cuando está listo. En el caso de los proyecto IT, el coche lo has de construir tú...
  • El consultor no puede escudarse en un contrato o en un acta para no hacer algo que solicita el cliente. El consultor ha de ser flexibile, diseñar y construir sabiendo que los requerimientos pueden cambiar. Cambiarán seguro, de hecho.

Este método no te asegura el éxito del proyecto. Únicamente te asegura descubrir pronto que vas por el buen o mal camino. Si eres cliente, en la tercera o cuarta iteración ya debes tener una idea de la capacidad de trabajo del equipo. Debes decidir si te conformas con ello o decides cancelar el proyecto y probar con otro proveedor. La alternativa no es, desde luego, esperar al último día para decir que además quieres esto u aquello. Lo verdaderamente prioritario ya deberías tenerlo desde hace meses, y lo que falta por hacer, probablemente, no sea tan importante como piensas...

Sin duda, al terminar el proyecto quedarán cosas por hacer y otras podrían mejorarse. Es estéril discutir en ese momento si se debe a la mediocridad del equipo de desarrollo, a la indefinición de los usuarios. Unos dirán que el cliente no proporcionó los medios adecuados, otros que el proyecto estaba mal planificados desde el inicio, etc... Con toda seguridad, la causa es la suma de todas esas cosas al mismo tiempo. Usuarios, clientes, gestores y técnicos son culpables por igual de resultado. Cada uno tiene su parte de culpa y su parte de mérito. Por eso son un equipo.

Esos problemas, de existir, deberían haberse detectado y gestionado durante el proyecto. Si eres cliente, y crees que la culpa es de los consultores, trata de buscar soluciones cuanto antes. Los problemas no se resuelven solos. Si no te gusta su trabajo, échales al tercer mes, o al cuarto, o al quinto, o al sexto... O propón soluciones. Involucrarte y pon más recursos. En el único momento que no puedes quejarte es al final del proyecto. En ese momento la culpa es solo tuya por no haberlos echado antes.

Lo que queremos evitar son cosas así:

¿Cómo puede ser que un proyecto, tras 10 años, no esté en producción? RT si te parece inadmisible. A las pocas semanas debería estarlo.

Las claves

Tras el sensacionalista título del artículo, me veo obligado a señalar dos claves (distintas que las que señale la semana pasada, por cierto):

  • Entrega frecuente de resultados. Hemos de ser transparentes. Mostrar cada mes hasta donde hemos llegado y tener un listado actualizado realista de hasta donde llegaremos.
  • Flexibilidad. Los requerimientos se van descubriendo a lo largo del proyecto. El cambio es la norma. Hemos de ser flexibles para hacer cosas de más y que nadie había pedido, y flexibles para hacer cosas de menos que no son tan importantes o tal vez son demasiado complicadas. Eso nos obliga a ser creativos y buscar alternativas. En equipo todo es mucho más fácil de lo que parece...

Me dejo muchísimas cosas en el tintero. Gestión de expectativas, listado de funcionalidades, la importancia del feedback de los usuarios, los tests, el calendario, los mantenimientos, y cosas así. Tal vez otro día.

Me despido con el último vídeo promocional de Crono que hemos preparado. Espero que os guste. Crono es el software de Business Intelligence más fácil de usar y creado pensando en el usuario de negocio. (¡y desarrollado siguiendo metodologías ágiles, por supuesto!).


Si te ha interesado lo anterior, te encantará este otro vídeo sobre cómo construir un cuadro de mando con Crono Business Intelligence.