Efecto 2020 en Suunto, lo que se puede aprender

Suunto sufre el efecto 2020

El inicio de año no ha sido fácil para Suunto, una empresa que es un referente en el mundo de relojes multi deporte, orientación y exploración. De hecho llegó a mi muñeca el primer Suunto por recomendación de un triatleta cuando estaba buscando un reloj que fuera fiable y resistente tanto para navegar como para multi deporte como natación, ciclismo, atletismo y que fuera "llevable" en el día a día.

El caso es que por navidades ha caído un Spartan que llevaba tiempo detrás de él y mi sorpresa ha sido enorme cuando el primer día del año se manifestaba un problema con la fecha, en concreto con el día de la semana.

Sin lugar a dudas ha de tener relación con el cambio de año, al parecer el software del reloj sufre un efecto lateral en el cálculo del día de la semana que hace que se adelante 2 días a la fecha correcta. Si bien la empresa reporta que en la App se registra correctamente, en los relojes afectados por el bug han "desaparecido" dos días de nuestras vidas y vivimos en el futuro desde el inicio de 2020.

Mi visión sobre este fallo, lejos de ser la de un hater o pretender hacer blame de la marca por el bug, se centra en dos factores claves:

• Suunto no reconoció ni informó a los usuarios hasta el segundo día, con lo que muchos usuarios durante el primer día del año empezaron a twittear sobre el error y a preguntarse qué habían hecho mal
• Tras informar sobre el bug el 2 de enero Suunto da una fecha para la publicación del fix el 7 y el 9 de enero en función de las familias de relojes afectadas

¿Dónde están los puntos de mejora?

El primero es de monitorización y comunicación ya que al parecer, no se dispone de herramientas de monitoreo de las aplicaciones en producción ya que han sido los propios usuarios los que han dado con el problema. Sería interesante para esta empresa disponer de emuladores que ejecutaran el software que los relojes llevan para anticiparse a este tipo de problemas. Si esto es muy complejo o no se considerase como beneficioso por el cost-bennefit, quizás otra alternativa sería mejorar los canales con los usuarios para la detección temprana de incidencias.

El segundo es que se debería revisar el proceso de Release Management ya que 5 días laborables para publicar un fix que puede afectar al prestigio de la marca me parece demasiado (para el caso de las familias Suunto Fintess y Spartan).

Si bien es cierto que la fecha no es bloqueante para el resto de funcionalidades es un error que a nivel de imagen es muy dañino, en mi opinión, al final se dedican a hacer relojes y deben dar la fecha bien. En el argot de desarrollo este tipo de error pese a no ser bloqueante sería crítico ya que, como comento, entiendo que afecta a la imagen de la marca y puede dañar al valor percibido de la misma.

Si aceptamos lo anterior como un argumento válido entonces deberíamos convenir que la prioridad debería ser alta, o lo que es lo mismo, el time to market debería ser el menor posible.

Evidentemente es entendible que al afectar a varios modelos de reloj el impacto pueda tener más complejidad de la que desde aquí puedo ver, pero si es así me lleva a otro punto de mejora: El refactoring del software. Si existe tanta diferencia entre modelos y familias como para organizar dos release plan para cada grupo de familia es porque o bien los códigos son muy distintos o bien los equipos son los mismos y no pueden paralelizar los trabajos. Nuevamente es un "smell" más que un hecho que pueda contrastar. En el caso de que fuera el código quizás pudiera tener sentido refactorizar funcionalidades básicas (o críticas) para que estas tuvieran una forma más standard en todos los dispositivos, de tal forma de que si en el futuro otro bug apareciera el fix realizado fuera fácilmente aplicable a todos los modelos.

Por último, aunque es fácil de comentar a toro pasado, igual no ubiera sido raro que la empresa ubiera valorado la posibilidad de hacer escenarios de prueba antes del 2020 incluso no me parecería raro que alguien de la empresa reconociera o supiera del potencial riesgo ya que sin saber mucho de la causa del error todo apunta a algún cálculo basado en el último número del año que al cambiar de decena se retrotrae al 2010, en ese año tal día como hoy 3 de enero era Domingo, justo lo que dice mi reloj 10 años más tarde.

Resumiendo, lo que creo que podrían mejorar:

• Mejora del monitoring de las aplicaciones en producción
• Mejora de la escucha activa del usuario early-feedback
• Mejora del Release Management para ver puntos de reducción de tiempos ante fallos críticos
• Como acciones proactivas de cara a futuros escenarios:
  • Plantear un Refactoring de las funcionalidades básicas
  • Revisar la comunicación con los equipos de desarrollo para tener una visión más realista de los riesgos y planificar testing para evitar futuras situaciones similares

No hago este post para dañar a la marca, sinceramente creo que de este tipo de situaciones podemos aprender todos, de los fallos es de donde podemos sacar las oportunidades de mejora. De los nuestros y de los que podrían haber sido nuestros.