Cómo lanzar una nueva versión de tu producto sin retrocompatibilidad

En una reunión con mis compañeros de Nelio estuvimos discutiendo sobre el futuro de Nelio A/B Testing y las mejoras que queremos añadirle. Al tratarse de un plugin para realizar tests A/B en tu web, requiere un mimo continuo para mantenerlo al día con las nuevas versiones de WordPress y asegurarnos de que todo funciona como debería. Ten en cuenta que es el primer plugin que lanzamos para WordPress, a finales del 2013, y ha estado en continua evolución desde entonces.

Pues bien, con la llegada del editor de bloques de WordPress aparecen nuevas posibilidades para realizar tests A/B en una web en WordPress. Y eso planteó una duda interesante: ¿deberíamos hacer una mejora incremental del producto o sería mejor romper con lo que hacíamos hasta ahora y lanzar algo completamente nuevo?

Nosotros aún no hemos decidido qué vía tomar, pero he pensado que sería interesante comentar qué problemas supone lanzar una nueva versión de un producto sin retrocompatibilidad y cómo podemos mitigarlos o eliminarlos.

Así pues, hoy te explicaré dos soluciones para lanzar una nueva versión de tu servicio rompiendo la compatibilidad con las versiones anteriores sin que tus clientes se indignen por ello.

Consideraciones previas

Tal y como contaba Chris Lema hace ya cierto tiempo en su blog, «la compatibilidad hacia atrás es algo muy importante dentro de WordPress. (…) Es algo que no solo afecta y aporta valor a los desarrolladores, sino que también da valor a los usuarios. A fin de cuentas, son estos últimos los que [en caso de dejar de ser compatibles] verán un mensaje notificándoles que su web ya no funciona».

¿Qué quiere decir exactamente romper la compatibilidad hacia atrás? Pues pueden ser muchas cosas, pero lo más habitual suele ser:

1. Cambiar la API con la que se puede extender nuestro plugin (cambiamos las funciones, los hooks, etc).
2. Modificar la estructura de la base de datos.
3. Cambiar la API o los datos de los componentes que tengamos en el cloud.
4. Pasar a un nuevo modelo de negocio y, por lo tanto, cambiar la forma en que un usuario puede acceder a funcionalidades y actualizaciones.

Veamos con un ejemplo concreto alguno de los puntos anteriores. Piensa en nuestro servicio de test A/B, el que te comentaba al principio de la entrada. Por si no lo sabes, el servicio funciona (a grandes rasgos) tal que así:

• El usuario puede crear tests A/B en su web. En esencia, un test A/B consiste en la página que quiere testear, una o más variaciones de dicha página y los objetivos de conversión que persigue el test. Todo esto se almacena en WordPress.
• Un componente en el cloud se encarga de hacer el seguimiento de las visitas a una web que use Nelio A/B Testing. De forma parecida a lo que hace Google Analytics, este componente recoge la información, la procesa y genera unos resultados. Los datos se mandan a este cloud usando un script de tracking.
• Una vista en el plugin se conecta a esta nube a través de una API para mostrar los resultados de un test al usuario.

Como puedes ver, un plugin como Nelio A/B Testing puede cambiar de muchas formas y, si no andamos con cuidado, las cosas pueden dejar de funcionar para nuestros usuarios.

Si, por lo que sea, decidimos actualizar la API de nuestro cloud, estaremos obligados a actualizar también nuestro plugin, puesto que el script de tracking y la vista de resultados dependen de esa API para funcionar. Y con ello estaríamos obligando a los usuarios a actualizar la versión del plugin que tienen instalada ya que, de repente, las versiones anteriores dejarían de funcionar.

Soluciones posibles

Está claro, pues, que romper la compatibilidad hacia atrás no es un tema baladí. Es algo que hay que pensar muy cuidadosamente y, en cualquier caso, lo más importante es optar por una solución que no deje tirados a tus usuarios actuales. Especialmente a aquellos que te estén pagando por tu servicio.

Si estamos seguros de que lo que más nos conviene como autónomos o como empresa, por lo que sea, es romper la baraja y empezar con una versión totalmente nueva de nuestro producto, olvidándonos de todo lo que habíamos hecho hasta ahora, existen dos soluciones. Con ellas, conseguiremos hacer tabla rasa sin dejar a nadie por el camino.

Nelio A/B Testing

Pruebas A/B nativas en WordPress

Usa tu editor de páginas favorito en WordPress para crear variaciones y lanza pruebas A/B con solo un par de clics. No se necesita saber nada de programación para que funcione.

Más info

Lanzar un nuevo producto (opt-in)

La primera solución que tenemos a nuestro alcance para lanzar una versión sin retrocompatibilidad es, ¿cómo no?, olvidarnos de que se trata de una nueva versión y plantearlo como un nuevo producto. En cierta forma, estamos evitando romper esa compatibilidad: sencillamente, lanzamos un nuevo producto y descontinuamos el antiguo.

Esto garantiza que los usuarios actuales tienen un plugin operativo y que funciona como siempre. Y, de hecho, nunca podrán actualizarse a una versión que «rompa las cosas», sencillamente porque dicha versión jamás existirá; es un plugin totalmente nuevo y diferente a lo que teníamos.

Esto, por supuesto, plantea algunos problemas más o menos graves:

1. Los usuarios que ya tenemos no sabrán que existe una nueva versión de nuestro producto. Por suerte, esto lo podemos solucionar poniendo una notificación en la versión antigua e invitándoles a actualizar.
2. Lanzar un nuevo producto es muy difícil. Todo el esfuerzo que habías hecho con el producto anterior, creando una marca para él, posicionándolo, consiguiendo valoraciones, instalaciones activas… todo esto se pierde y empiezas de cero.

Esta solución es la que yo llamo opt-in: lanzamos un nuevo producto y te invito a que, si quieres, dejes de usar el viejo y te pases al nuevo. En cierta forma es lo que hizo WordPress hace varios meses cuando lanzó Gutenberg como plugin: tú decidías si querías usarlo instalando Gutenberg en tu web.

Lanzar una actualización que rompe la compatibilidad hacia atrás (opt-out)

Otra opción es plantear el enfoque inverso, y en eso consiste la segunda solución: lanzar una actualización de tu producto que rompa la compatibilidad hacia atrás y, en paralelo, lanzar un nuevo producto que sea la versión antigua. De esta forma, aunque rompamos con la retrocompatibilidad, ofrecemos a nuestros usuarios un plan B para que todo siga como antes.

Aplicando este método solucionamos los dos problemas que habíamos planteado en la solución anterior. Por un lado, conseguimos que todos los usuarios sepan que existe una nueva versión y podemos enseñarles directamente las ventajas que supone dicha versión (velocidad, UI, estabilidad…).

Por otro lado (y quizás más importante), seguimos sacando provecho a todo el trabajo que habíamos hecho hasta ahora, ya que estamos ante una nueva versión de un producto que llevaba ya un cierto tiempo en el mercado. La marca, las valoraciones, el posicionamiento… todo sigue igual, no hay que partir de cero.

Como puedes imaginar, esta es la solución opt-out: quiera o no, cuando el usuario actualice el plugin en su web, pasará a usar la nueva versión de tu producto. Pero tendrá disponible la opción de, si quiere, salirse de esta nueva versión y pasar a usar la anterior, instalando el nuevo plugin que hemos creado para ello. Esto es lo que hizo WordPress el pasado mes de diciembre cuando introdujo el editor de bloques en su última actualización y dejó la posibilidad de usar el antiguo editor instalando un plugin específico para ello.

Resumiendo

Romper la compatibilidad hacia atrás no es sencillo, ya que puede tener grandes implicaciones para tus usuarios. En general, no recomendaría hacerlo. Pero hay veces en que no queda otra.

Si te ves en la tesitura de hacerlo, te recomiendo que implementes una de las dos soluciones que hemos visto hoy. Con ellas, siempre les das la opción a los usuarios de «seguir como están», con lo que nadie podrá quejarse de que «las cosas han dejado de funcionar». Eso sí, como contrapartida tendrás dos productos que mantener (incluso suponiendo que la versión «vieja» pasa a tener un mantenimiento mínimo).

Y tú, ¿cómo gestionarías algo así? ¿Conoces alguna otra opción para salir del paso?

Imagen destacada de Dietmar Becker en Unsplash.