En la mayoría de grandes compañías españolas que tienen su propio departamento de desarrollo, la construcción de software sigue viéndose como se veía hace unos 10 años y es francamente difícil incorporar metodologías nuevas de desarrollo que llevan años demostrando su mejores números con éxito si son bien aplicadas.

Esto en parte se debe a la lentitud inherente al tamaño, pero también (o más directamente) debido a las personas con la autoridad suficiente para apadrinar el cambio: el miedo a lo desconocido es directamente proporcional al miedo a perder el asiento.

Cuando las metodologías de la última mitad del siglo XX se llevan al extremo y se aplican además con poco sentido común, nos encontramos con casos como los que llevo viviendo durante unos meses: son los analistas de negocio los que definen la interface de usuario, que a su vez este “aprueba” y acto seguido se convierte en una especie de Libro Sagrado que cual talibanes algunos siguen hasta el extremo y lo defienden a capa y espada argumentando que “lo ha aceptado el usuario y no podemos cambiarlo ahora”.

Fantástico: el usuario ha aceptado la mejor opción que se le ha presentado, lo que no significa que sea la mejor opción de las posibles, porque en la fase de toma de requisitos no ha participado ningún experto en experiencia de usuario (sí, andamos con fases, ni se os ocurra preguntarme por sprints o si el usuario forma parte del equipo y valida en cada final de sprint las US entregadas…).

Por supuesto, más tarde o más temprano, al estar el analista (muy conocedor y experto en el negocio) dedicado a “pintar pantallas”, su tiempo se esfuma sin dedicarlo a aquellas tareas en las que realmente brilla: analizar las necesidades de negocio y proponer soluciones a los procesos repetitivos y manuales, limpiar “cacas” de los procesos existentes, etc.
Obviamente, cuando los prototipos hechos por el analista de negocio llega a las manos de los front-end developers, que sin ser expertos en usabilidad, solo con el “roce” han cogido cariño a determinados lay-outs, patrones de diseño y soluciones visuales a problemas comunes, estos propondrán mejoras a las interfaces que obviamente, será muy dificil que sean aceptadas, poque el usuario ya ha aceptado antes unas interfaces que figuran en un documento que viene a ser un contrato vinculante y en parte, porque el propio analista verá como un menosprecio a su trabajo en el que tanto esfuerzo y tiempobha dedicado.

Cuando estos “chavales” levantan la liebre e indican una mejor forma de hacer la misma pantalla (tampoco necesariamente la mejor por tampoco son expertos en experiencia de usuario, usabilidad, etc), es cuando por fin alguien comprenderá que se ha tirado el dinero: el del tiempo empleado por el analista haciendo cosas para las que no está preparado, el del tiempo empleado por el usuario revisando las pantallas con alguien que no sabe (aunque me consta que quiere y que seguro hace con la mejor de las voluntades) aportar ninguna solución de usabilidad mejor, el de los desarrolladores que en muchos casos deben construir elementos “ad-hoc” para que la pantalla sea como la “pintó” el analista, y todo el tiempo futuro que va a perder el usuario de la aplicación por no tener la mejor solución de interface posible y deba “pelear” día a día con una lasca de sílex porque no le han dado un cuchillo afilado para cortar….

Igual que el dicho del zapatero…  Analista, a tus análisis.

Y eso solo es posible con equipos de proyecto interdisciplinares, que colaboren como uno solo desde el primer momento hasta el ultimo, y por supuesto, con el usuario participando como uno mas en el equipo, marcando prioridades y tomando decisiones acorde avanza el desarrollo y se van viendo posibles mejoras.