Hoy en día, existe una secuencia generalmente aceptada sobre las etapas que se requieren para construir un producto digital.
Hoy en día, existe una secuencia generalmente aceptada sobre las etapas que se requieren para construir un producto digital.
Se entiende, también, si estás familiarizad@ con procesos de diseño, que debemos comenzar por las fases de ideación desde el ángulo de negocio, y prototipamos una solución centrada en el usuario que los stakeholders puedan "ver y tocar".
Si quieres leer, más sobre esta fase, te recomiendo que eches un vistazo a nuestro post sobre el marco de trabajo que utilizamos en diseño de producto: Sprint Zero . El Sprint Zero, cubre esencialmente las etapas 1-3 de la infografía adjunta, así que en este artículo nos centramos en los factores de éxito para construir un producto digital en las fases de desarrollo..
Nuestra herramienta principal de gestión será el backlog de producto, y utilizar herramientas como Notion o Jira, nos permite visualizar diferentes tableros de gestión por funcionalidades, releases, o sprints. Tener toda la información centralizada nos va a permitir acceder al 'big picture' del desarrollo en el largo plazo, así como al detalle de las historias de usuario sobre los criterios de aceptación, archivos de UI, o status de GitHub.
Desde Wealize, solemos planificar con al menos 2 sprints vista, y priorizamos las funcionalidades a desarrollar según hemos definido el flujo de negocio principal, con el objetivo de asegurar una entrega de valor incremental a negocio y usuarios.
La hoja de ruta y backlog de producto son herramientas dinámicas, es decir, el orden o contenido de las historias de usuario puede cambiar siempre y cuando exista una lógica de negocio justificada por parte de los stakeholders, o técnica por parte del equipo de desarrollo. En los siguientes epígrafes, veremos cómo gestionar la hoja de ruta correctamente.
Una vez tenemos el marco operativo de los sprints de desarrollo bien definidos, nos centramos en los artefactos del día a día que nos ayudan a construir productos sólidos centrados en el usuario.
Diariamente, o cada dos días, nos reunimos el equipo técnico para revisar en qué hemos trabajado, qué vamos a trabajar próximo, y potenciales bloqueos que supongan un riesgo en el ciclo de desarrollo.
Desplegamos el código en GitHub, con lo que aseguramos un +80% de test del mismo, y alojamos nuestros productos en PaaS como Heroku para minimizar el impacto en la infraestructura.
Diseñamos siguiendo una visión atómica de los componentes basados en el sistema de diseño y actualizamos los archivos de UI que se van a trabajar en cada sprint en Zeplin.
Además del test de código, desde el punto de vista funcional probamos las funcionalidades con base en los criterios de aceptación antes de mergear a producto.
Ahora que tenemos el producto centralizado y hemos visualizado la estrategia a largo plazo del producto, es hora de planificar los sprints de trabajo.
El sprint es una herramienta utilizada en Scrum que consiste en un ciclo de desarrollo de (normalmente) dos semanas. Éste se utiliza, en contra de otros métodos más tradicionales como 'Waterfall', porque nos permite centrarnos en la hipótesis de negocio más actual; nos permite ser lean y ágiles en desarrollo iterativo para asegurar la entrega de valor a negocio con carácter periódico.
Para garantizar la correcta ejecución de los sprints, disponemos de los siguientes artefactos de control:
Repasamos con carácter semanal o bi-semanal la hoja de ruta con los stakeholders, para validar que estamos alineados con el objetivo de negocio principal y la tendencia de mercado.
Nos reunimos los equipos técnicos y stakeholders para estimar las historias de usuario en las que vamos a trabajar en el próximo sprint en materia de esfuerzo o coste, y prioridad de negocio.
El espectro Agile es muy amplio por lo que hoy en día los marcos de referencia que implantamos en nuestra cadena de valor resultan de una combinación de varias metodologías como Design Thinking, Scrum o Lean Startup. Es así como obtenemos el Sprint Zero (link) y estas prácticas de los ciclos de desarrollo que nos permiten asegurar una entrega de valor al negocio, al usuario, y nos permite mejorar en cada iteración.
Basado en nuestra experiencia, sabemos que existen actividades comunes al desarrollo de productos digitales como la gestión de usuarios desde un backend o las funcionalidades de onboarding de los mismos.
Es por ello que dimensionamos nuestra metodología de diseño y desarrollo de MVPs en los mencionados artefactos recogidos en este artículo y el anterior referido al Sprint Zero en un periodo de aproximadamente 3 meses desde cero.
Si estás interesado en conocer mejor en qué hemos trabajado, visita nuestro blog donde publicamos las historias de nuestros clientes; o contacta para que te lo contemos en primera persona.
El Sprint Zero es una metodología empleada en el diseño de productos digitales que aplica un proceso iterativo de descubrimiento, definición y diseño.
El proyecto POLDER es una solución de intercambio, reutilización y monetización de datos para ciudades inteligentes.
Uno de los resultados más relevantes de este proyecto fue producir aplicaciones nativas para cinco tecnologías diferentes con prácticamente el mismo...