6 errores a evitar si eres una startup móvil y quieres evolucionar tu app

Post on 06-Apr-2017

184 views 0 download

Transcript of 6 errores a evitar si eres una startup móvil y quieres evolucionar tu app

6 errores a evitar si eres una

startup móvil y quieres

evolucionar tu app de forma rápida y segura

Roberto Garridorobertogarrido.com

@che1404

• Freelance

• Desarrollo nativo iOS

• Trabajo remoto

• Equipos ágiles

¿Qué os voy a contar?

1. No apostar por una arquitectura limpia y modular

2. No establecer tests unitarios como metodología de trabajo en tu equipo

3. No realizar crash reporting

4. No analizar el uso que tus usuarios hacen de tu app (app analytics)

5. No escuchar a tus usuarios ni probar tu app con usuarios reales (beta testing)

6. No entregar valor a tus usuarios de forma continua y planificada

1. No apostar por una arquitectura limpia y modular

• Publicas una feature que no tiene la adopción esperada

• Surge un problema en producción y empiezas a perder usuarios

• Tienes una suite de apps que comparten funcionalidad y te ves duplicando código y recursos

1. No apostar por una arquitectura limpia y modular

• La arquitectura son los cimientos de tu app

• Evolucionar nuestra app rápidamente ya sea añadiendo, modificando o eliminando funcionalidad

• Reaccionar rápido frente a crashes y malas reviews

• Reduce costes y reutiliza recursos

1. No apostar por una arquitectura limpia y modular

• MVC: Model View Controller

• MVP: Model View Presenter

• MVVM: Model View ViewModel

• VIPER: View Interactor Presenter Entity Routing

2. No establecer TDD como metodología de trabajo

• Al añadir código siempre introduces alguna inestabilidad

• Probar todas y cada una tus funcionalidades manualmente

2. No establecer TDD como metodología de trabajo

• Comprobar automáticamente (mediante una suits de tests) tras cada cambio introducido, que todo lo anterior funciona

• Detectar efectos secundarios antes de que lo hagan nuestros usuarios

2. No establecer TDD como metodología de trabajo

• Quick: Librería de BDD

• Nimble: Librería de matchers

• Cuckoo: Framework de mocking

3. No realizar crash reporting

• No hay peor sensación que los casques y salidas inesperadas de una app

• Pérdida de usuarios

• Problemas legales…

3. No realizar crash reporting

• Configurar alertas que te avisan cuando un error es muy recurrente

• Monitorizar pequeños errores

• Reaccionamos pronto ante los errores más graves

3. No realizar crash reporting

4. No usar app analytics

• ¿Cuántos usuarios están usando la app?

• ¿Cuántas sesiones tiene al día?

• ¿Cuánto duran esas sesiones?

• ¿Están usando tu app de la forma en la que la habías imaginado, o el flujo de navegación es diferente?

• ¿Cuántos usuarios están gastando dinero en tu app?

• ¿Cuánto dinero están gastando?

4. No usar app analytics

• Para retener usuarios debes ofrecerles un producto que se adapte a sus necesidades, tienes que medir

• Nos ofrecen estadísticas de cuánto, cómo, y durante cuánto tiempo se está usando nuestra app

• Hacer hipótesis y A/B testing

4. No usar app analytics

5. No escuchar a tus usuarios

• Cuando tienes una base de usuarios grande y no quieres sorpresas en producción

• Estás lanzando un MVP y quieres medir resultados primero con un grupo reducido y controlado

6. No entregar valor de forma continua

• Una nueva versión de iOS y tu código no es compatible

• Actualizaciones de software de terceros que rompen tus funcionalidades

• Problemas ajenos a nuestro negocio

• Nuestros usuarios esperan que les entreguemos actualizaciones

• Nuestro clientes quieren conocer el estado del proyecto

6. No entregar valor de forma continua

• Sistemas de integración continua

• Compilan y lanzan los tests por nosotros

• Algunos prueba también las betas de iOS

• Nos permiten estar preparados para publicar, porque detectamos errores de integración antes

• Automatización del despliegue

• Herramientas para automatizar tareas de release: compilación, testing, tags y descripciones en el store, capturas de pantalla, etc.

• Nuestros usuarios perciben los cambios

• Nuestros clientes comprueban dónde va su inversión

6. No entregar valor de forma continua

Atención startup: Sprint bi semanal

• ¿Para quién es este servicio?

• Tienes financiación ahora, pero incertidumbre en el futuro

• Tienes una app obsoleta, y necesitas actualizarla

• Tienes una app en producción y quieres evolucionarla

• Tu proyecto ha pasado por varias manos, y necesita arquitectura

• Quieres empezar una app, pero no tienes muy claros aún los requisitos

Atención startup: Sprint bi semanal

• ¿En qué consiste?

• Paquetes bisemanales de trabajo en remoto, hasta 40 horas de disponibilidad

• Programación, consultoría, investigación, etc.

• ¿Cómo funciona?

• Seguimos metodología ágil en sprints de 2 semanas

• Los proyectos llave en mano hace tiempo que dejaron de funcionar

• Reunión inicial + trabajo + validación

Atención startup: Sprint bi semanal

Más info en robertogarrido.com/sprint-bi-semanal

¡Gracias!

robertogarrido.com @che1404

facebook.com/freelanceiosdev