Un desarrollador y, sin embargo, amigo, me tiene entretenido de vez en cuando revisando un proyecto. Las revisiones suelen consistir en sesiones con café en las que este joven, la gerente y algún espontáneo hablan de cualquier cosa mientras yo le digo que no a todo. Product Managing at its best.
En la última sesión el proyecto, que originalmente hacía una cosa, había crecido para hacer tres o cuatro más o menos relacionadas. El joven ha adquirido el típico retrovirus MS3WTF1 conocido popularmente como “Bloatware”. Este virus es más común de lo que parece y encuentra su caldo de cultivo en la mente de
- Programadores que están aprendiendo,
- vendedores tras tomar unas copas con un cliente y
- empresas que organizan grupos de estudio.
Sin embargo no todo está perdido. Especialmente el tiempo invertido en añadir features (poyaques en español). Veamos, pues, como afrontar el problema en cuestión: un proyecto que engorda más allá de lo necesario.
Hablamos de un proyecto para iOS.
En este contexto, añadir poyaques a un programa va contra una importante regla (posíblemente) no escrita:
Una app debe hacer una única cosa. Muy bien. Muy rápido.
Por supuesto, esa app puede incluir distintas características necesarias para poder hacer esa única cosa. Pero un objetivo deseable, al menos para ciertas escuelas de pensamiento, es tener un botón en tu dispositivo en el que haces algo, rápidamente, sin tener que perderte pensando cuál de las cinco posibles y distintas características que tiene vas a usar en un momento dado. Entras, usas, sales.
Contra-argumenta el joven que está usando un sistema de testing donde tiene un log de lo que la gente emplería más o menos dentro del programa. Contra-contra-argumento de quien escribe: deja que sea el mercado quien te de esa información.
Es decir, en lugar de tener una app con tres utilidades distintas, crea tres apps distintas. La base de código es la misma, los datos serán los mismos o similares en los tres casos. Y los usuarios descargarán, e incluso pagarán, la que más les interese. Es una forma rápida de saber donde dedicar los siempre escasos recursos.
Adicionalmente, este producto tiene el potencial de ser dirigido a distintos targets, con una mínima variación. En este caso, la ventaja es tener una app en el segmento, por ejemplo de “Recetas” y otra en el de “Salud”. Nuevamente, misma base de código, pequeños cambios en contenido y/o interface, usando una de cara distinta característica para cada segmento.
Resumiendo: puedes programar el nuevo office, pero habrá usuarios que sólo querrán la característica de Outline y otros sólo necesitan tres funciones del Excel. Crea una app centrada en cada una de las principales características de tu proyecto. De esta forma podrás:
- Simplificar el uso de tu programa en un mercado donde el tiempo que un usuario dedica a probar una app desciende cada día y
- llegar a usuarios que, de otra manera, ni se acercarían a tu producto.