Los peligros de reescribir una aplicación
Los peligros de reescribir una aplicaciónLa historia de cómo todo el equipo ejecutivo de Sonos acabó despedido por la mala gestión de la reescritura de una aplicación.
En mayo de 2024, Sonos, reconocida marca de sistemas de altavoces inalámbricos en el hogar, actualizó su aplicación móvil. Ocho meses después, en enero, el consejo de la compañía “dimitió” al CEO. Esta es la historia que llevó a aquel despido. La actualización, no era menor. En Sonos habían decidido cambiar la aplicación a todos los niveles. Cambiaron la forma de conexión de la aplicación con los altavoces, el backend y la infraestructura que lo soportaba, y también la experiencia de uso, el frontend. Los usuarios de Sonos comenzaron a quejarse desde el primer momento. Por una parte, altavoces que con la aplicación previa funcionaban perfectamente, en esta eran inalcanzables. Por otra, algunas funcionalidades importantes habían desaparecido, y otras habían dejado de funcionar por completo. En un primer momento, Sonos, si bien reconoció algunos problemas, defendió su decisión aduciendo a que el rediseño de su app había requerido de mucho coraje y que los problemas se solucionarían. Los más viejos del lugar recordarán una escena parecida cuando Steve Jobs les decía a los usuarios de Apple que cogían mal el iPhone 4 y por eso perdía la señal. Sin embargo, el tiempo pasó y los problemas no terminaban de solucionarse. A los pocos meses del lanzamiento, el CEO tuvo que excusarse públicamente en una nota incrustada en la nueva app. Poco después llegaría una primera ronda de despidos, y más excusas, hasta la salida final del CEO, seguida de la del CPO, Chief Commercial Officer y CMO. La cronología de los hechos, narrada por The Verge, vendría a ser así:
¿No está mal para una simple actualización de la app, eh? ¿Qué llevó a Sonos a actualizar su aplicación?Las razones para lanzar una actualización de semejante envergadura suelen ser casi siempre técnicas y operacionales. Muy probablemente la empresa, durante años, se dedicó a añadir código y funcionalidades a la aplicación sin preocuparse del impacto de este en la experiencia de desarrollo y en el propio rendimiento de la aplicación. Con el tiempo, la base de código es tan terrible, que empieza a impactar la velocidad de desarrollo, y la empresa comienza a preguntarse qué puede hacer para ir más rápido. Siempre, y digo, absolutamente siempre, alguien, generalmente con poca experiencia, sugiere que la única solución es rehacer la aplicación desde cero. Se crea un equipo especial para hacer la nueva app y se convierte en el centro de atención de toda la compañía. La aplicación anterior se congela en el tiempo, lo que curiosamente hace que funcione mejor durante unos meses, y el nuevo desarrollo se convierte en el centro de todas las peticiones históricas que nunca se pudieron llevar a cabo en la antigua app. ¿Cambio de infraestructura? Adelante. ¿Rediseño por completo? Venga, vamos. ¿Aquella funcionalidad que pidió el CMO en algún momento? Por supuesto. Todo tiene cabida cuando te pones a reescribir una aplicación. El alcance de la nueva aplicación crece. Se empieza a invertir más tiempo de lo que se pensaba. Se empieza a recortar a última hora para lanzar. Se fuerza el lanzamiento pese a las advertencias del equipo técnico y de aquellos más cercanos al cliente final. Y, así, se consuma el desastre. Sobre la salida del CPO, The Verge, escribe:
Como reescribir una aplicación sin terminar despedidoEl primer consejo que os puedo dar, es que no lo hagáis. Casi siempre es una mala idea. Joel Spolsky tiene el artículo definitivo al respecto: Things You Should Never Do, Part I. Citándole:
Si tras leer esta entrada y el artículo de Spolsky, todavía te quedan ganas de reescribir una aplicación porque la situación es totalmente insostenible, hay formas de hacerlo sin morir en el intento. Por ejemplo:
¿Por qué no todas las empresas lo hacen así? Principalmente por falta de experiencia, y porque no es sexy. Se ve la reescritura como la oportunidad de hacer todo lo que durante años se ha querido hacer pero no se podía. De hecho, se suele vender como uno de los argumentos principales para hacer la reescritura, porque la realidad es que a nadie le gusta invertir tiempo de ingeniería en cosas lo que no se ven. Y entonces llegan las prisas. Y se rebaja la calidad. Y si se lanza al mercado, ocurre el desastre. Aún en ese caso, hay una forma de amortiguar el golpe, y es evitar la actualización de todos los usuarios, creando una nueva aplicación en lugar de reemplazar a la antigua. Sonos podría haber lanzado una V2 de su aplicación en modo beta, sin forzar a todos los usuarios a actualizar a una versión inferior de lo que tenían. Decidió no hacerlo así y terminó con todo el equipo ejecutivo fuera de la empresa, y con suerte, servirá de lección para una generación de líderes de producto. |
Similar newsletters
There are other similar shared emails that you might be interested in: