Insights >Blog

Cómo evitar el error de Apple Maps

Alex Robbio


January 16th, 2019


¿Es aconsejable reconstruir un producto software desde cero?

En 2018 Apple anunció que iba a reconstruir la aplicación Maps desde cero que, a decir verdad, era bastante mala. Para que se hagan una idea de lo lejos que está de la competencia, lean el blog del cartógrafo, Justin O’Beirne donde sostiene que le será imposible a Apple alcanzar a Google Maps, y resalta cómo este último está creando “datos de otros datos” al combinar conjuntos de datos diferentes.

Es así que Apple decidió rehacer una aplicación principal en su ecosistema móvil. Es una decisión de suma importancia que los ejecutivos de la empresa no tomaron a la ligera.

De esta manera llegamos a pregunta en la que quería indagar: ¿Cuándo debemos aceptar que un producto software ya no funciona y cuándo debemos reconstruirlo completamente, teniendo en cuenta la inversión correspondiente?

Apple tiene a su disposición una gran cantidad de recursos lo que le permite tomar este tipo de decisiones – puede mantener la aplicación existente de Apple Maps funcionando mientras trabaja en la nueva versión, (que según informan lleva 4 años desarrollándose). Sin embargo, para la mayoría de las empresas, mantener dos versiones del mismo producto es excesivamente costoso – ya es bastante difícil mantener un sólo producto principal al día en cuanto a la tecnología existente y que satisfaga a los cambiantes y exigentes clientes, evitando caer en deuda técnica.

Empezar de cero es raramente una decisión que las empresas toman. Reconozco que puede ser tentador ver una nueva tecnología y pensar lo bien que le haría al producto. Yo recomendaría cautela: toma tiempo crear un nuevo producto software (a Apple le tomó 4 años renovar Maps) y para cuando hayan terminado, el mercado (y su competencia) habrá seguido adelante, dejándolos aún más atrás de lo que ya estaban. Recuerden lo ocurrió con Netscape cuando se decidió reconstruirla completamente. Tanto se tardó la empresa en lanzar su versión “nueva y mejorada” que le dio la oportunidad a Internet Explorer de acaparar el mercado (se culpó a la práctica anticompetitiva de Microsoft de agrupar Internet Explorer y Windows en un paquete, pero si Netscape hubiera mantenido su liderazgo, hubiera podido pelear, al igual que Firefox y Chrome hacen hoy en día).

Por otro lado, hay que recordar que un nuevo código no es perfecto. Se necesita invertir en un equipo de control de calidad para asegurarse que el nuevo código no tenga los mismos problemas del producto existente.

Es mejor prevenir que curar

Entonces, ¿cómo evitamos llegar a esta situación? Existen métodos muy conocidos, desde una administración de la cartera de aplicaciones efectiva, hasta una inversión temprana en testeo y control de calidad. Hoy me gustaría mencionar algunas estrategias que empresas con las que trabajamos utilizan. Es importante destacar que no es una descripción completa, sino algunas ideas a considerar al momento de tomar una decisión.

  1. Contratar a desarrolladores “canosos”. Si están desarrollando software de la manera correcta, pues entonces éste estará diseñado para sufrir cambios y evolucionar en el tiempo. Es decir, hay que considerar las dependencias y tener una visión más amplia del producto. Es por esta razón que vale la pena invertir en desarrolladores “canosos” que entiendan estos términos medios y que puedan ayudar a construir un mejor producto desde el inicio.
  2. El uso de nuevas tecnologías implica no tener que reconstruir completamente. Se pueden utilizar APIs para crear nuevos servicios y productos front-end por encima de la versión anterior. Ésta es una estrategia que muchos bancos grandes están empleando para hacer frente a las fintechs – en vez de comenzar de cero, amplían sus sistemas mediante APIs y crean nuevos productos y servicios con terceros. Tecnologías como WSO2 o MuleSoft son de bajo costo y permiten añadir APIs y service bus a la tecnología anterior.
  3. La refactorización de código reduce el riesgo, mientras que realizas mejoras. Optar por refactorizar el código implica invertir en mejorar el código y el producto, pero evita el riesgo (y el dolor de cabeza) de reescribirlo por completo. Es una propuesta totalmente diferente a comenzar de nuevo.
  4. Las startups invierten en su tecnología de base. Aconsejamos y guiamos a las startups con las que trabajamos para que inviertan más efectivamente en la Investigación y Desarrollo de su tecnología base; lo que supone comprender las tendencias, invertir en la arquitectura adecuada y tomar decisiones a largo plazo en una etapa temprana en ciclo de vida del producto. Es muy valioso para las startups trabajar con socios con experiencia, que ya hayan pasado por la misma situación y que puedan servir de orientación al momento de tomar una decisión que impactará sobre producto y la empresa por años.

Jugársela y seguir los pasos de Apple

En un mundo ideal no sería necesario “reinventar la rueda”. Sin embargo, cuando los productos no tienen bases sólidas o no están construidos a escala, la única opción es empezar desde cero. Por ejemplo, en Belatrix Software trabajamos con uno de los proveedores principales de servicios de vídeo bajo demanda en el rediseño y redesarrollo de su solución de video (cuando era una startup y también después cuando fue adquirida por una gran empresa multimedia). Los ayudamos a migrar de Flash a AngularJS debido a que Flash ya se estaba tornando obsoleto.  

Durante el proceso mantuvimos las dos versiones funcionando, pero el costo era muy elevado – hacíamos las actualizaciones de la versión anterior, manteniendo el negocio y el producto funcionado, y a la vez invertíamos tiempo en crear el nuevo producto. Tomamos la decisión de escribir el código desde cero, aunque las normas de la empresa no sufrieron cambios. Si bien fue un gran reto, el producto final fue todo un éxito. Debido al declive de Flash, consideramos que ésta era la mejor opción (y en definitiva, ayudó a que la empresa fuera adquirida por el gigante multimedia).

Aunque el software esté destinado a evolucionar, en situaciones en la que la tecnología ha avanzado drásticamente, es mejor empezar desde cero. Sin embargo, cuando el software está creado sobre una base sólida, y no es demasiado tarde, tiene más sentido refactorizar el código y hacer mejoras iterativas.   

Share

Related posts

See also

Services

Software development

Software testing

Consultancy & innovation

User experience

Industries

Fintech

Media & entertainment

Healthcare

All industries

Insights

Blog

Whitepapers

Webinars

Videos

Why Belatrix?

International presence

Nearshore advantages

Project governance

Agile expertise

Flexible engagement models

Our talent development