Actualizaciones en SaaS, ¿cómo podemos hacer el mínimo daño al usuario?

El modelo SaaS –Software as a Service– tiene infinitas virtudes. La principal, tanto para la empresa como para el usuario, es el modelo de distribución. Las aplicaciones se sirven directamente desde un servidor central, permitiendo que, con la actualización de este servidor, todos los usuarios reciban sus actualizaciones sin realizar ninguna acción y a la vez.

Si comparamos este modelo con otros anteriores, veremos que tiene muchísimas ventajas:

• Es ultraconveniente tanto para el usuario como para la empresa. De forma transparente tu aplicación está siempre actualizada.
• La empresa se ahorra tener que distribuir soportes físicos con las actualizaciones.
• En el caso de que no sean soportes físicos, la empresa se ahorra tener varias versiones en distribución, con sus consecuentes parches de seguridad y demás actualizaciones. Hay un código corriendo. Punto.
• El usuario se ahorra que la empresa le cobre por cada actualización.

Pero también hay ciertas desventajas para el usuario. De la noche a la mañana, alguien puede encontrarse con que su herramienta de trabajo ha sido actualizada y esto le provoca dificultad para utilizarla, retrasando su trabajo, quizás urgente. A pesar de que todos creemos que ponemos cuidado en preparar a los usuarios para estas actualizaciones, no siempre resultan convenientes.

Las ventajas del SaaS para el usuario

La principal ventaja para el usuario, más allá de una actualización continua, es el precio de las aplicaciones. Seamos claros, el SaaS ha hecho que el software cueste infinitamente menos de lo que costaba. Lógicamente hay otros factores, como la reducción de los costes computaciones, pero si queremos abstraernos de todos ellos, podemos irnos al principio del SaaS.

Uno de los precursores del SaaS, fue Salesforce. Esa empresa que ahora nos parece un dinosaurio gigante y al que intentan meterle mano por todos lados con soluciones más ágiles y livianos, fue un día ágil y liviana. Y se enfrentó con un dinosaurio gigante llamado Siebel Systems en una guerra de troleos que mola muchísimo pero que trataremos otro día.

La principal diferenciación fue el modelo de distribución, Siebel era un modelo tradicional de venta de licencias y Salesforce fue de los primeros SaaS, por lo que es una de las pocas comparaciones directas de precio que podemos hacer. Así que, ¿cuánto costaba Siebel y cuánto costaba Salesforce? Cito directamente el libro del creador de Salesforce:

El software licenciado típico costaba unas cantidades extraordinarias de dinero. Los productos baratos costaban 1.500$ dólares por usuario. Pero lo peor es que este no era el único gasto. El soporte costaba unos 54.000$ anuales, 1.200.000$ por personalización y consultoría, 385.000$ por el hardware básico donde ejecutarlo, 100.000$ en personal administrativo y 30.000$ en formación. El coste total de un producto para una empresa de 200 personas, podía superar los 1.8M$ solamente en el primer año.

Además, el problema de este tipo de software es que muchísimas licencias (un 65% según un estudio de Gartner) no se utilizaban jamás, a pesar de estar pagadas. El modelo de Salesforce sin embargo tenía un coste de:

De 50$ a 100$ por usuario por año. Sin permanencia, sin cuota de alta.

Para una empresa de 200 usuarios el coste del SaaS serían entre 10.000$ y 20.000$ al año y el del software licenciado sería de 1.8M$. En resumen, el cambio de paradigma ha provocado que el usuario ahorre una tonelada de pasta.

¿Nos estamos comportando como dictadores con nuestros propios usuarios y clientes?

Seamos claros, si no somos unos psicópatas, lo normal es que siempre que hagamos una actualización pensemos que va a mejorar la vida de nuestros usuarios. Y, en la gran mayoría de los casos, vamos a llevar razón.

El problema es que hay usuarios que no quieren ser actualizados en un momento determinado, bien porque están cómodos con su entorno actual, o porque tienen prisa en realizar una tarea y no quieren verse nuestro nuevo how to en vídeo.

¿Es un problema que un tipo entre en nuestro software y, de repente, se encuentre otro diferente? La respuesta, como para todo es un rotundo depende. Creo que si estamos vendiendo B2B hay que ser más delicado que si estamos vendiendo B2C, cualquier proceso que influya en el trabajo de las personas es más complejo de modificar.

¿Nuestra actualización va a añadir funcionalidades o va a modificar las existentes? Si vamos a añadir algo nuevo, podemos tirar para adelante sin miedo ninguno, si vamos a modificar un flujo que se use con frecuencia, quizás hay que ser más cautos.

¿Cómo podemos hacer que las actualizaciones sean más human-friendly ?

Lo primero que tenemos que hacer es medir. Es muy útil conocer cuáles son los flujos críticos de nuestro producto. Cuál es el motivo por el que las personas nos están pagando y cuáles son los adornos que le hemos puesto alrededor para venderlo mejor. Hay softwares en los que es muy fácil saberlo pero, cuando tenemos un número de funcionalidades curioso, podemos sorprendernos.

Cuando vayamos a actualizar una funcionalidad que no sea parte de un flujo crítico, podemos tirar sin miedo. Pero si vamos a actualizar algo crítico, es probable que debamos probarlo primero con un flujo de usuarios reducido. Hay varias técnicas que podemos utilizar:

Funcionalidades con opt-in

Ofrecer un opt-in a las nuevas funcionalidades, presentando un popup o similar consultando a los usuarios si desean probar una nueva versión de la funcionalidad. Es una forma poco intrusiva pero que nos puede provocar una avalancha de usuarios si son muy early-adopters .

Progressive delivery

Utilizar progressive delivery . Esta es una técnica que lo que consiste en desplegar los cambios de forma paulatina, a un número controlado de usuarios. El principal problema es que deben coexistir dos versiones del producto, la antigua y la nueva. Pero las ventajas son mayores que que las desventajas:

• Se puede comenzar a desplegar una funcionalidad poco a poco, con la consecuente tranquilidad para los usuarios y para el equipo de soporte.
• Al probar con un número de usuarios pequeño, reduciremos la posibilidad de que pase una desgracia. Porque las desgracias pasan.
• Se puede segmentar a los usuarios que queremos que prueben una funcionalidad. Podemos elegir a usuarios muy poco activos para que no piensen que la aplicación cambia de un día para otro. O a usuarios muy activos para conseguir feedback muy rápido. Otra idea puede ser segmentar por el tipo de plan contratado para experimentar solamente con clientes que no nos supongan un riesgo financiero.
• Si se detectan problemas se puede apagar la funcionalidad de forma sencilla.

Hay muchos SaaS que permiten realizar este tipo de despliegues, por ejemplo LaunchDarkly, aunque también se puede desplegar de esta forma in-house . En el centro de esta técnica están los feature-flags , básicamente un botón que permite encender y apagar una funcionalidad.

Utilizar feature toggles o dejar la decisión en manos de los usuarios, ¿buena o mala idea?

Como comentaba, un feature-flag , permite activar o desactivar una determinada funcionalidad. La lógica nos dice que si queremos que un usuario pueda elegir cuándo recibe una actualización, podríamos dejarlo en sus manos. Esto suena bien sobre el papel, pero si existe un cierto inmovilismo en nuestros usuarios, podemos acabar conservando versiones antiguas durante años. Lo mejor es actualizar de forma progresiva pero forzar la actualización en un momento.

He visto algunos casos, en productos que tienen clientes muy grandes y cuyos procesos son muy críticos para las empresas, que permite utilizar feature flag durante periodos de tiempo relativamente largos para determinadas funcionalidades. Pero incluso en estos casos, existen funcionalidades que se acaban incorporando de forma obligatoria.

Los feature flags pueden parecer la panacea pero también crean deuda técnica, porque mantener dos versiones del código es una sobrecarga de trabaja y, además, la versión antigua se va desactualizando con el paso del tiempo; aumentando la probabilidad de que existan bugs y haciendo la compatibilidad con otros componentes cada vez más compleja.

En resumen

Deberíamos tener al usuario en el centro de nuestras actualizaciones, no solamente para proporcionarle mejores experiencias si no para proporcionárselas de forma gradual y, preferentemente, al ritmo que ellos decidan. Mantener decenas de versiones de un software no tiene sentido desde el punto de vista del SaaS, pero permitir una incorporación progresiva a las nuevas funcionalidades y aumentar la flexibilidad en la incorporación, es definitivamente una buena práctica que deberíamos tratar de implementar.