Siempre tuve claro el objetivo de sacar Karate Stars cuanto antes sin invertir demasiado tiempo en desarrollo, como ya he comentado en anteriores artículos. En este artículo repaso las decisiones que tome funcionales y técnicas.

Diseñando funcionalmente el producto mínimo viable

Inicialmente no quería tener muchos karatecas, hice una selección de los que desde mi punto de vista son los mejores.
Pensé en la información mínima que a los usuarios que hacen karate les molaría tener de cada competidor y más adelante iría ampliando.

Los datos que decidí tener de cada competidor fueron:

• Foto, esta sería una de las diferencias con otras apps como ya vimos en anteriores artículos. La foto debía ser grande y que se viera bien en tablet.
• Biografía, donde debía de aparecer la fecha de nacimiento ya que es habitual interesarse por la edad de un competidor que esta despuntando por ver si le queda mucho recorrido todavía.
• Logros, palmares de resultados deportivos, pero solo en Europeos y Mundiales, continuando la misma linea del PMV de lo simple a lo complejo.
• Videos, misma decisión respecto a otros puntos, solo videos de Europeos y Mundiales.

Al final la decisión fue que información mínima necesito para que la app tenga enganche y sea útil. Por hacer un producto mínimo viable tampoco es cuestión de llevarlo al extremo y poner solo un listado con nombres y poco más. Desde mi punto de vista tiene que existir un criterio y unos mínimos, sino el fracaso esta asegurado.

Diseñando técnicamente el producto mínimo viable

En este apartado es donde tuve más claro lo que quería hacer y donde seguramente muchos 'arquitectos', que poco me ha gustado siempre esa palabra, se llevarán las manos a la cabeza.

Inicialmente no se descargaría la info de un servidor, ¿Que dices? ¿estas loco?, bueno al final según mi experiencia uno de los puntos de mayor inversión de desarrollo es en la comunicación con un api rest. No iba a existir API Rest ni un Mobile Backend as a Service inicialmente, me ahorraba bastante desarrollo y me aseguraba seguir en la linea marcada de tener la app en la tienda cuanto antes con la menor inversión de desarrollo. ¿Pero entonces de donde saldrían los datos?, mi decisión y de la que estoy más convencido de haber acertado a medida que pasa el tiempo fue que los datos los sacaría de un json embebido en la aplicación.

Se que esto suponía que cada vez que quisiera actualizar datos tendría que publicar una nueva versión de la aplicación pero eso no era un problema realmente más allá de la moral :)

Lo que si que diseñe como si fuera un producto final y no un producto mínimo fue la parte de presentación, aquí no había opción a realizar un producto mínimo viable. A futuro la aplicación tendría una Arquitectura Clean, así que la capa de presentación la iba a crear siguiendo el patrón Model View Presenter. El objetivo era que a medida que la aplicación fuera creciendo y tomando forma de clean architecture la capa de presentación sufriera esos cambios lo mínimo posible. Es decir la capa de presentación para las funcionalidades existentes iba a ser definitiva.

¿Porque decidí no seguir la misma estrategia en la capa de presentación? la capa de presentación iba a tener toda su logica, con mensajes etc.. creo que es clave tener esta capa bien organizada desde el principio para luego poder crecer. En la parte de datos yo tengo un repositorio que me devuelve los datos de un json y si mas adelante es a través de una conexión de red, el cliente del repositorio no debe notar la diferencia, digamos que la refactorización es viable. Pero una capa de presentación mal organizada requiere que muchos conceptos del framework, como controles, contextos etc.. se mezclan con lógica de presentación como sacar un mensaje, navegar a otra pantalla etc.. y luego resulta muy complicado refactorizar o lo que es lo mismo luego hay mucho que refactorizar y se complica bastante.

Conclusiones

Como hemos visto en la fase de diseño prioricé el tener la aplicación en la store en el menor tiempo posible frente a desarrollar un producto funcionalmente y técnicamente perfecto.
Podríamos decir que existía un requisito de fecha, ya sean por cuestiones de viabilidad del producto, promoción etc.. por encima de una arquitectura y funcionalidades perfectas. Eso suponía hacer sacrificios, por ejemplo no había búsqueda y filtros, inicialmente con 12 karatecas esas funcionalidades me parecían totalmente prescindibles.

Yo lo tenía claro, si la aplicación era aceptada en el mercado, tendría que ir haciendo refactorizaciones hasta que técnicamente y funcionalmente se elevara el nivel sin percer la usabilidad y rapidez de la aplicación.

Lamentablemente no siempre en la empresas tienen claro estos conceptos y suelen querer algo rápido y técnicamente digno de enseñar en conferencias. Luego cuando planteas que el producto tiene que evolucionar despacio porque hay mucho que ordenar internamente, eso se entiende aun menos.