A colación de En beta constante, una nota de @angeljimenez, mi amigo @juantonioF sostiene que el usuario se ve perjudicado por el agilismo, que constantemente le obliga a actualizar de versión sus programas y aprender o cambiar sus rutinas.
Mi primera reacción es quitarle hierro al asunto, pero lo cierto es que algo de razón lleva… Yo creo que el usuario no tiene que ser necesariamente perjudicado, aunque sí es cierto que se abusa en ocasiones. ¿Cuál es la postura correcta?
La filosofía lean promueve despliegues tempranos, rápidos y frecuentes. Pero, ¿tienen que llegar al usuario forzosamente?
La respuesta rápida: los cambios en la experiencia del usuario tienen que resultar valiosos para el usuario.
La respuesta larga
Los cambios no necesitan ser necesariamente publicados. Cada iteración que genera una entrega de valor permite hacer un seguimiento de la evolución de un proyecto, depurado, corrección de errores, carga de datos, pivotar lo más temprano posible si es preciso, visibilidad del proyecto. El valor que genera una entrega frecuente es para el desarrollador y para su cliente, no necesariamente para el usuario final. Si para el usuario no hay un valor claro y demandado, los cambios deberían publicarse muy despacio. Porque lo que no puedes perder de vista es que la filosofía lean consiste en a) generar valor y b) quitar desperdicio, no en encalomárselo a otro.
Ahora bien, entregar novedades no es necesariamente valioso cuando obliga al usuario a aprender cosas nuevas y, lo que es más doloroso, desaprender hábitos de uso. Al valor de lo entregado hay que restarle el valor negativo de cambiar, porque el usuario, con razón o sin ella, percibe los cambios negativamente y necesita una buena razón de peso para que le merezca la pena. Es acomodaticio en grado sumo.
¿Cuándo tiene sentido publicar implacablemente?
Cuando estás trabajando en un escenario de early adopters y erlyvangelists. Es decir, aplicaciones inmaduras, con un público consciente de su papel innovador y probador.
¿Cuándo es improcedente?
Cuando tienes una base instalada muy amplia, muy tradicional y muy asentada de usuarios que han hecho suya tu aplicación, y el cambio es esencialmente en la experiencia de usuario en sentido amplio.
Entre estos dos extremos, hay una multitud de grises.
- Por ejemplo, en una aplicación de gestión interna que solo emplean cuarenta personas tiene todo el sentido del mundo liberar cuanto antes. Máxime si las modificaciones han sido solicitadas por los propios usuarios. Entregar pequeños cambios cada 15 días es un mecanismo fantástico para tranquilizar ánimos y escenificar velocidad y capacidad de escucha. Tu interlocutor en el cliente estará más que agradecido.
- Una aplicación que el usuario utiliza porque quiere y no le va la vida en ello, como, por ejemplo, «Manga generator«, puedes hacer todos los cambios que quieras.
- Una aplicación de banca online con demasiados cambios generará inseguridad, errores, desapego por la aplicación, llamadas al contact center.
- Una web en una administración pública, donde es primordial que la tarea del usuario se complete cuando hablamos de trámites e información.
Si un cambio puede ser percibido como el añadido de contenido y encaja en la estructura natural de la arquitectura de información, debería ser añadido cuanto antes. Si el cambio afecta a hábitos de uso, especialmente en herramientas de productividad (lo que incluye gestos, tics, atajos de teclado, orden de campos en formulario), hay que pensárselo dos veces. Si el cambio apenas toca el UX y aporta velocidad, seguridad y fiabilidad, es obvio que hay que publicar. Si afecta a pocas personas, también.
¿Cómo probar los cambios y validar entregas si no las publicas?
Entregando en un contexto cerrado. En experiencia de usuario se da por comprobado empíricamente que la vieja ley de Nielsen con Pareto se sigue cumpliendo: más de cinco usuarios representativos son una muestra suficiente para un estudio, y te aportarán el 80% de las propuestas de mejora que podrías recibir. El otro 20% de propuestas de mejora te costarán bastante más que diez entrevistas. En otras palabras, los siguientes usuarios que entrevistes apenas aportarán novedades significativas sobre lo que dijeron los cinco primeros. Por eso, un grupo de early adopters y earlyvangelists no tiene que ser necesariamente grande para validar entregas.
Obviamente hay otras consideraciones. Para audiencias amplias y acomodadas, lo ideal sería llevar dos ramas de versionado separadas. La más estable, con una masa de usuarios amplia, en la que solo se actualice para resolver problemas de seguridad y otros fallos. Una menos estable, que se utilice para innovar. Sí, lo sé, en los tiempos que corren a ver quién se puede pagar paralelizar dos versiones.
Pero lo que hay que entender es que en algún momento tendrás que cruzar un punto de inflexión en la madurez de tu proyecto. Si tardas demasiado, tus usuarios se habrán vuelto acomodaticios y acabarán cansándose de ti, te percibirán como un pelma fanático del cambio por el cambio, errático, indeciso y vacilante. Porque casi nadie es como Google: cambia la manera de redactar en gmail, y todos a fastidiarse.
