Llamada de descubrimiento hasta las pruebas: Nuestro proceso de desarrollo con Bubble

Las empresas buscan continuamente aprovechar las últimas herramientas para crear productos y servicios que satisfagan requisitos únicos. Uno de los desarrollos más emocionantes en este ámbito es la aparición de plataformas no-code como Bubble, que permiten a los desarrolladores crear aplicaciones de software sin necesidad de amplios conocimientos de codificación.

En nuestra agencia Bubble, hemos desarrollado un proceso robusto para la creación de aplicaciones de software utilizando Bubble.

En este artículo, te guiaremos a través de nuestro enfoque de desarrollo, desde la llamada de descubrimiento inicial hasta las etapas finales de prueba.

¿Por qué explicamos nuestro proceso de desarrollo?

Encontrar la agencia Bubble adecuada es un desafío. Saber qué preguntas hacer durante el proceso de descubrimiento puede ser confuso y, lo que es más importante, qué esperar una vez que el proyecto comienza.

Y si ya tienes algo de experiencia, querrás asegurarte de que tu negocio está obteniendo lo mejor de su trabajo con una agencia (es decir, no quieres costes ocultos ni sorpresas desagradables).

Mientras muchas agencias Bubble alardean de su portfolio, casos de estudio, presupuesto y cronograma, ninguna explicará su proceso de desarrollo. Es una caja negra.

En este artículo, nuestro objetivo es ser transparentes sobre las diferentes fases del proceso de desarrollo y ofrecerte un desglose de lo que implica cada paso. ¡Así sabrás cómo logramos resultados para nuestros clientes!

Relacionado: Qué es una agencia Bubble

1. Llamada de descubrimiento

Una llamada de descubrimiento es una reunión breve y preliminar. Es una oportunidad para que tú y nosotros nos presentemos, compartamos tus objetivos, necesidades y expectativas, y veamos cómo Bubble puede ayudarte a lograrlos.

Una llamada de descubrimiento suele involucrarte a ti (el cliente) y a nosotros (el equipo de desarrollo y posiblemente un gerente de proyecto). Podemos realizar la llamada a través de Zoom, Google Meet o cualquier otra herramienta de videoconferencia.

El objetivo de una llamada de descubrimiento es:

• Conocernos y aprender sobre los antecedentes.
• Obtener una visión general de tu visión, declaración del problema, público objetivo, propuesta de valor y criterios de éxito.
• Identificar las principales características y funcionalidades de tu aplicación.
• Determinar si tiene sentido programar otra llamada —la llamada de alcance— para discutir los detalles de tu proyecto.

Una llamada de descubrimiento resulta en una comprensión general de cómo quieres ayudar a tu audiencia. También recibirás un correo electrónico nuestro resumiendo los puntos clave de la discusión y proponiendo los próximos pasos.

Los siguientes pasos después de una llamada de descubrimiento pueden variar según la complejidad y los requisitos de tu proyecto. Algunos posibles pasos siguientes son:

• Firmar un contrato o un NDA (acuerdo de no divulgación) si es necesario.
• Programar una llamada de alcance para definir el alcance, el cronograma, el presupuesto y los entregables de tu proyecto.
• Crear un wireframe o un mockup del diseño de tu aplicación.
• Explorar la documentación de la API si es necesario.

Esta llamada sienta las bases para el resto del proceso de desarrollo.

2. Llamada de alcance

Una llamada de alcance es una reunión detallada y en profundidad. Es una sesión en la que profundizamos en tus objetivos, necesidades y expectativas y trazamos cómo Bubble puede ayudarte a lograrlos.

Una llamada de alcance suele involucrarte a ti (el cliente) y a nosotros (o al equipo de desarrollo y posiblemente a un gerente de proyecto). Podemos realizar la llamada a través de Zoom, Skype, Google Meet o cualquier otra herramienta de videoconferencia. Si es necesario, puede haber varias llamadas de alcance.

El objetivo de una llamada de alcance es:

• Comprender tus requisitos en detalle, como los recorridos de usuario, la estructura de datos, los flujos de trabajo, las preferencias de diseño y las integraciones.
• Identificar los principales desafíos y riesgos de tu proyecto.
• Determinar el alcance, el cronograma, el presupuesto y los entregables de tu proyecto.
• Aclarar cualquier pregunta o inquietud que puedas tener sobre Bubble.

El resultado de una llamada de alcance es un acuerdo claro y mutuo sobre lo que quieres construir con Bubble y cómo quieres construirlo.

Los siguientes pasos son:

• Compartir una propuesta preliminar que detalle el cronograma, el presupuesto, los hitos y los entregables.
• Revisar y aprobar el documento de propuesta.
• Crear un wireframe o un mockup del diseño de tu aplicación.

Una llamada de alcance es una parte importante de cualquier proceso de desarrollo exitoso con Bubble. Ayuda a alinear el alcance y las expectativas de tu proyecto.

3. Historias de usuario

El siguiente paso son las historias de usuario.

Las historias de usuario son descripciones cortas y sencillas de lo que un usuario quiere hacer o lograr con tu producto. Se escriben desde la perspectiva del usuario y se centran en el valor o beneficio de usar tu producto. Nos ayudan a priorizar y planificar el desarrollo basándonos en lo que más importa a tus usuarios.

Para escribir una buena historia de usuario, seguimos algunas pautas:

• Utiliza un formato estándar: Como un , quiero para que .
• Sé específico y conciso: Evitamos términos vagos o ambiguos y nos centramos en los detalles esenciales.
• Incluye criterios de aceptación: Definimos cómo sabrás cuándo la historia de usuario está terminada y cumple con las expectativas del usuario.
• Utiliza personas: Usamos ejemplos realistas y representativos de tus usuarios objetivo para hacer que tus historias de usuario sean más cercanas y empáticas.

Aquí tienes algunos ejemplos de historias de usuario para una plataforma de blog:

• Como blogger, quiero crear una cuenta para poder publicar mis entradas en línea.
• Como lector, quiero comentar las entradas del blog para poder compartir mis comentarios y opiniones con otros lectores y bloggers.
• Como editor, quiero revisar y aprobar las entradas del blog antes de que se publiquen para poder garantizar la calidad y la coherencia.

Las historias de usuario difieren de las características del producto porque se centran en el problema o la necesidad del usuario en lugar de la solución o la funcionalidad. Las características del producto describen lo que hace el producto o cómo funciona, mientras que las historias de usuario describen por qué existe el producto o a quién sirve.

• Característica del producto: La plataforma de blog tiene un editor de texto enriquecido que admite formato, imágenes, enlaces, etc.
• Historia de usuario: Como blogger, quiero formatear mis entradas fácilmente para poder hacerlas más atractivas y atractivas para mis lectores.

Las historias de usuario nos ayudan a desglosar proyectos complejos en fragmentos manejables que podemos entregar de forma incremental. Al escribir historias de usuario claras y valiosas, podemos asegurarnos de construir productos que resuelvan problemas reales para personas reales.

Mapas de historias de usuario

Utilizamos una técnica llamada mapeo de historias de usuario para organizar mejor nuestras historias de usuario.

El mapeo de historias de usuario es una visualización del recorrido de un cliente con nuestro producto de principio a fin. Incluye todas las tareas que normalmente completarían durante ese recorrido.

El mapeo de historias de usuario nos ayuda a identificar cómo los usuarios experimentan nuestro producto y qué esfuerzos conducirán a los mejores resultados para ellos. También nos ayuda a decidir qué es lo más importante, organizar el trabajo en lanzamientos (ofreciendo una nueva experiencia al cliente) y despriorizar el trabajo con menos valor para el usuario.

Para crear un mapa de historias de usuario, seguimos estos pasos:

• Identificar nuestras personas: Definimos quiénes son nuestros usuarios objetivo basándonos en sus objetivos, necesidades, comportamientos, puntos débiles, etc.
• Definir nuestra columna vertebral: Enumeramos todas las actividades de alto nivel (también llamadas Épicas) que nuestras personas realizarían con nuestro producto cronológicamente de izquierda a derecha.
• Desglosar en tareas: Añadimos detalles desglosando cada actividad en tareas más pequeñas (Historias) que representan acciones o pasos específicos dentro de cada Épica. Las organizamos verticalmente debajo de cada Épica según la prioridad (mayor prioridad en la parte superior).
• Dividir en lanzamientos: Agrupamos Historias relacionadas en piezas horizontales (también llamadas Lanzamientos) basándonos en su propuesta de valor.

Aquí tienes un ejemplo de un mapa parcial de historias de usuario para una plataforma para alojar y organizar eventos.

El mapeo de historias de usuario nos ayuda a crear un módulo utilizable asegurando que cada lanzamiento ofrezca una experiencia completa al cliente en lugar de características o tareas aisladas. También nos ayuda a asignar tareas a los equipos de frontend o backend solo si consideramos cómo encajan en el recorrido general del cliente.

4. Wireframes

Un wireframe es una representación visual del diseño de tu aplicación. Muestra el diseño, la estructura y la jerarquía de los elementos en cada página de tu aplicación. También indica la navegación y la funcionalidad y visualiza el recorrido del usuario.

Utilizamos Balsamiq o Miro para crear los wireframes.

Un wireframe debe ser:

• Esquemático: Un wireframe no pretende ser un diseño final o pulido. Su objetivo es ser un boceto o un plano que capture la esencia del diseño de tu aplicación. No consideramos colores, fuentes, imágenes u otros detalles.
• Delimitado: Un wireframe debe definir el alcance y los límites del diseño de tu aplicación. Debe mostrar qué características y funcionalidades están incluidas y excluidas de tu aplicación. También debe mostrar cómo se relaciona cada página con las demás y cómo los usuarios pueden navegar por ellas.
• Abierto: Un wireframe debe permitir flexibilidad y creatividad. No debe limitarnos a un diseño fijo o rígido. Debe animarnos a explorar diferentes opciones, experimentar con soluciones e iterar basándonos en los comentarios.

Algunas de las mejores prácticas para crear wireframes son:

• Empezar con lápiz y papel: Antes de usar cualquier herramienta digital, a menudo empezamos con lápiz y papel. Nos permite esbozar rápidamente nuestras ideas sin distraernos con detalles técnicos o limitaciones.
• Usar formas y símbolos sencillos: Para mantener tus wireframes simples y claros, usamos formas y símbolos básicos para representar los elementos en cada página. Por ejemplo, usamos rectángulos para botones o campos de texto, círculos para iconos o botones de radio, líneas para separadores o bordes, etc.
• Usar etiquetas y anotaciones: Para hacer tus wireframes más comprensibles e informativos, usamos etiquetas y anotaciones para describir los elementos en cada página. Por ejemplo, usamos anotaciones para explicar la funcionalidad o interacción de los elementos, etc.
• Usar marcadores de posición para el contenido: Para evitar empantanarse con los detalles del contenido en esta etapa, usamos marcadores de posición para el contenido, como texto o imágenes, por ejemplo, texto lorem ipsum para párrafos o encabezados.
• Usar ejemplos y referencias: Para inspirarte, adjuntamos ejemplos y referencias de otras aplicaciones o sitios web que tienen características o funcionalidades similares a las tuyas. Por ejemplo, si tu aplicación necesita una vista de calendario, haremos referencia a cómo lo hacen Google Calendar u Outlook Calendar.
• Usar comentarios y pruebas: Para validar y mejorar el diseño de tu aplicación, usamos la información y las pruebas de usuarios potenciales o partes interesadas.
• Usar iteraciones y revisiones: Iteramos y revisamos los wireframes basándonos en los comentarios y las pruebas para refinar y finalizar el diseño de tu aplicación.

5. Propuesta final

Una vez que tenemos las Historias de Usuario y los Wireframes definidos, conocemos el proyecto en detalle. Ahora podemos compartir contigo una propuesta vinculante con todo detallado: cronograma, presupuesto, hitos y alcance del trabajo.

6. Diseños de alta fidelidad

Los diseños de alta fidelidad son representaciones detalladas y realistas de cómo se verá y se sentirá tu producto una vez terminado. Incluyen colores, fuentes, iconos, imágenes e interacciones.

Utilizamos Figma como nuestra herramienta de diseño porque es fácil de usar, colaborativa y potente. También podemos compartir nuestros diseños con tu equipo y las partes interesadas para obtener comentarios y aprobación.

Para crear diseños de alta fidelidad en Figma, seguimos estos pasos:

• Utilizar historias de usuario y wireframes como base: Usamos las historias de usuario para guiar qué características y funciones necesitamos diseñar. También usamos los wireframes como base para nuestros diseños y estructura.
• Aplicar elementos de diseño visual: Definimos y aplicamos elementos de diseño visual comunes como la paleta de colores, la tipografía, la iconografía, el espaciado, etc. Utilizamos un sistema de diseño para la mayoría de nuestros proyectos.
• Probar e iterar: Compartimos nuestros diseños contigo para mostrar cómo funcionará el producto. Basándonos en tus comentarios, realizaremos cambios en los diseños.

Dado que estamos construyendo un MVP (producto mínimo viable), nos centramos más en la función que en la forma. Esto significa que priorizamos el diseño de características que aportan valor a nuestros usuarios sobre las características que son agradables de tener pero opcionales. Esto no significa que nuestra interfaz de usuario parezca de los años 2000. Será un diseño estéticamente agradable, pero no ganará ningún premio.

7. Desarrollo

Una vez que hemos finalizado las historias de usuario, los wireframes y los diseños de alta fidelidad, estamos listos para comenzar el desarrollo real del MVP. Aquí es donde convertimos tu visión en una aplicación web funcional utilizando Bubble, una plataforma no-code que nos permite construir aplicaciones sin escribir código.

Utilizamos Trello para rastrear las historias de usuario y los criterios de aceptación de cada característica. Trello es una herramienta que nos permite crear tableros con listas y tarjetas que representan diferentes tareas y etapas del proceso de desarrollo. También podemos adjuntar archivos, comentarios, listas de verificación y estimaciones a cada tarjeta.

Dividimos todo el proyecto en múltiples sprints (generalmente de una o dos semanas), centrándonos en entregar características que añaden valor a la aplicación. Los sprints se componen de una mezcla de épicas combinadas, por lo que no es que completemos el diseño y luego el flujo de trabajo, no.

Cada sprint aborda un módulo de aplicación específico, para que podamos mantener nuestro enfoque nítido y obtener resultados más rápido. Por ejemplo, podríamos dedicar un sprint a la página de inicio, el proceso de registro y la página de perfil de usuario.

Las historias de usuario y los criterios de aceptación de cada sprint se añaden al tablero de Trello. A medida que avanza el desarrollo, actualizamos el tablero de Trello, para que los clientes tengan visibilidad.

Ningún desarrollo de software exitoso puede ocurrir en silencio. Para toda la comunicación, utilizamos Slack para discutir dudas y otras preguntas. Es mucho mejor que comunicarse por correo electrónico o videollamadas.

Una vez que se completa una épica, pasamos al siguiente paso para las pruebas.

8. Pruebas

Las pruebas son un proceso que verifica la existencia de defectos y errores en el producto o aplicación de software. Las pruebas no son lo mismo que el control de calidad (QA), que es más amplio y se centra en mejorar los procesos y prácticas a lo largo del ciclo de vida del desarrollo de software.

Las pruebas son un enfoque reactivo y correctivo que se centra en encontrar y corregir los errores y problemas en el software.

Uno de los aspectos críticos de las pruebas es el uso de los criterios de aceptación para cada historia de usuario. Los criterios de aceptación deben cumplirse para que la historia de usuario se considere terminada y lista para la entrega. Ayudan a aclarar las expectativas y los requisitos, así como a guiarnos en nuestro trabajo.

El equipo de pruebas utiliza los criterios de aceptación para realizar diferentes pruebas en cada historia de usuario. Algunos de los tipos comunes de pruebas son:

• Pruebas unitarias: Validar que cada unidad de software funciona como se espera. Una unidad es el componente más pequeño y comprobable de una aplicación.
• Pruebas funcionales: Comprobar las funciones emulando escenarios de negocio, basándose en los requisitos funcionales.
• Pruebas de regresión: Comprobar si las nuevas características rompen o degradan la funcionalidad.

Si una historia de usuario pasa todas las pruebas, se marca como terminada y se pasa al siguiente paso. Si una historia de usuario falla alguna prueba, se devuelve al desarrollador para su corrección.

Una vez que se completa un sprint, te pedimos que verifiques las épicas (grandes características de múltiples historias de usuario) para su aceptación. Puedes aceptar o rechazar una épica según tu satisfacción. Si se acepta una épica, se considera parte del MVP (producto mínimo viable). Si se rechaza una épica, se envía de vuelta al equipo de desarrollo para su mejora.

El proceso de pruebas garantiza que el MVP se entregue con un mínimo de defectos y errores y que satisfaga tus necesidades y expectativas. También ayuda a mejorar la calidad, la fiabilidad y el rendimiento del software.

9. Entrega

Una vez que todas las épicas e historias de usuario han sido probadas, el MVP se marca como completado. Ahora puede ser entregado. Durante la entrega, hay 4 cosas que hacer:

• Transferencia de la propiedad de la aplicación: La aplicación Bubble se transfiere a tu cuenta de Bubble y se configura la facturación.
• Aplicación conectada al dominio: La aplicación se puede conectar a un dominio personalizado. Los cambios de DNS son sencillos y tardan menos de 10 minutos en completarse. A veces, conectamos la aplicación a un dominio antes en el desarrollo.
• Capacitación: Nuestro desarrollador de Bubble te dará un recorrido por la aplicación: estructura de la base de datos y diseño de la página. No te pediremos que mantengas la aplicación, pero Bubble es fácil de entender a un alto nivel, incluso para personas no técnicas. Y nuestros clientes aprecian saber cómo funciona la aplicación por dentro.
• Documentación: Documentamos la aplicación y compartimos la documentación contigo. Incluye los flujos de trabajo, la estructura de la base de datos, la estructura de la página y cómo realizar pequeños cambios en el contenido estático del sitio web. Utilizamos Notion o Google Docs para esto.

10. Mantenimiento

El mantenimiento es la última etapa de nuestro proceso de desarrollo.

El mantenimiento garantiza que el producto o aplicación de software siga funcionando correcta y eficientemente después de ser entregado y desplegado a los usuarios finales. El mantenimiento también implica actualizar y mejorar el producto o aplicación de software para satisfacer las necesidades y expectativas cambiantes.

Ofrecemos servicios de mantenimiento de dos maneras: bajo demanda o con contrato de retención.

El mantenimiento bajo demanda significa proporcionar servicios de mantenimiento cada vez que los solicites o los requieras. Cobramos una tarifa fija por hora por los servicios de mantenimiento bajo demanda.

El mantenimiento con contrato de retención significa que proporcionamos servicios de mantenimiento regularmente, como mensual, trimestral o anualmente. Cobramos una tarifa mensual fija por los servicios de mantenimiento con contrato de retención. Puedes elegir el tipo y nivel de servicios de mantenimiento que se adapten a tus necesidades y presupuesto.

¿Cómo gestionan los cambios de alcance a lo largo del proceso de desarrollo?

Los cambios de alcance son inevitables en cualquier proyecto. Pueden surgir por diversas razones y pueden afectar el cronograma, el presupuesto, la calidad y los entregables del proyecto.

Entendemos que los cambios de alcance a veces son necesarios e inevitables. Sin embargo, también intentamos minimizarlos lo máximo posible con el paso de las historias de usuario y los wireframes.

Revisamos las historias de usuario y los wireframes contigo y obtenemos tus comentarios y aprobación antes de pasar a la etapa de desarrollo. También documentamos el alcance del trabajo de forma clara y explícita en un contrato o acuerdo que describe los nuevos entregables, plazos, costes y responsabilidades. Esto garantiza que estemos en la misma sintonía con respecto al alcance del proyecto.

Sin embargo, también reconocemos que algunos cambios de alcance son esperados e inevitables durante el proceso de desarrollo. Seguimos estos pasos para gestionar los cambios de alcance:

• Evaluamos cualquier solicitud de cambio de alcance y consideramos la viabilidad, necesidad y valor del cambio.
• Discutimos la solicitud de cambio de alcance, los pros y los contras del cambio, e intentamos llegar a una solución mutuamente aceptable. También proponemos opciones alternativas que puedan satisfacer las necesidades.
• Documentamos cualquier solicitud de cambio de alcance y su resolución en una orden de cambio formal o una enmienda que modifique el contrato o acuerdo original. También actualizamos el plan del proyecto, el cronograma, el presupuesto y los entregables en consecuencia.

Relacionado: Cómo colaborar con una agencia Bubble

¿Qué nivel de participación tienen los clientes en el proceso de desarrollo?

El nivel de participación es alto hasta la etapa de wireframe. Hasta entonces, necesitamos tu aportación para entender qué necesitamos construir y si estamos en el camino correcto.

La mayoría de los proyectos de desarrollo de software fracasan no por el presupuesto, el cronograma o los desafíos técnicos, sino por las expectativas no cumplidas.

No es fácil traducir lo que tienes en mente al papel. Más difícil aún cuando tienes que explicárselo a otra persona. Con las historias de usuario y los wireframes, intentamos comprender la visión que tienes en mente.

Una vez que lo entendemos, puedes dar un paso atrás y nosotros podemos empezar a desarrollar el producto.

Así es exactamente como gestionamos cada proyecto en NocodeAssistant. Si está listo para iniciar un desarrollo con Bubble, nuestro equipo de la agencia Bubble sigue este proceso de principio a fin, desde el descubrimiento hasta la entrega. Reserve una llamada para conversar sobre lo que necesita.