Gestión de Usuarios Piloto - Sprint 1
Universidad de Sevilla
Escuela Técnica Superior de Ingeniería Informática
Grado en Ingeniería Informática – Ingeniería del Software
Curso: 2024 – 2025
Fecha: 25/02/2025
Versión: v1.3
Grupo de prácticas: G1
Nombre del grupo de prácticas: ISPP - Grupo 1 - Holos
- María del Mar Ávila Maqueda
- Joaquín González Ganfornina
- Nerea Jiménez Adorna
- Juan del Junco Obregón
- Miguel Ángel Gómez Vela
- Juan Antonio Moreno Moguel
- María del Carmen Barrera Garrancho
- Daniel Guedes Preciados
- Julia Virginia Ángeles Burgos
- Javier Muñoz Romero
- Juan Núñez Sánchez
- Nicolás Pérez Gómez
- Francisco Pérez Lázaro
- Celia Aguilera Camino
- Gabriel María Vacaro Goytía
- Ignacio Warleta Murcia
- José María Portela Huerta
Responsables:
| Miembro | Responsabilidad |
|---|---|
| Nerea Jiménez Adorna | Redactora |
| María del Mar Ávila | Revisora |
Repositorio: GitHub - Holos-INC
Control de Versiones
| Fecha | Versión | Descripción | Autor |
|---|---|---|---|
| 25/02/2025 | v1.0 | Creación de documento | Nerea Jiménez Adorna |
| 03/03/2025 | v1.1 | Correcciones y añadidos | Nerea Jiménez Adorna |
| 03/03/2025 | v1.2 | Más usuarios piloto | Nerea Jiménez Adorna |
| 09/03/2025 | v1.3 | Corrección Usuarios Piloto y añadido "Evaluación de Usuarios piloto de otros grupos" | Nerea Jiménez Adorna |
| 13/03/2025 | v1.4 | Añadida evaluación de Usuarios Piloto y actualización del calendario | Nerea Jiménez Adorna |
Índice de Contenidos
- Introducción
- Selección de participantes
- Escenarios de prueba
- Plan de Testing y Feedback Survey
- Plan de Comunicación
- Evaluación de los Usuarios Piloto
- Beneficios para los Usuarios Piloto
- Lecciones Aprendidas
1. Introducción
En este documento se describe el método que utilizaremos a lo largo del curso para gestionar a los usuarios piloto y el feedback recibido. Además, se describirá el plan a seguir por los encargados de contactar con los usuarios piloto, así como el procedimiento para evaluar la información recibida en las entrevistas.
2. Selección de participantes
Nuestro proyecto se enfoca en facilitar el trabajo de los artistas para gestionar sus obras y a sus respectivos clientes. Es por eso que hemos decidido dividir nuestros usuarios piloto en dos grupos, que representan los dos roles principales que tenemos: clientes y artistas.
- Los clientes son los usuarios que encargan las comisiones, es decir, ellos pagan a los artistas para encargarle dibujos personalizados.
- Los artistas son los usuarios que realizan las comisiones encargadas por los clientes. Ellos gestionan su arte mediante nuestra aplicación.
2.1 Criterios de selección de participantes
Para la elección de los participantes, hemos aplicado un criterio para los usuarios tipo artista y otro distinto para los usuarios tipo cliente.
-
Para seleccionar a los artistas, hemos escogido a personas que se dedican de forma profesional o como trabajo extra al mundo del arte. Son personas que ya tienen experiencia en el ámbito de vender sus dibujos y atender a clientes, o bien pretenden empezar a hacerlo y quieren comprobar que nuestra plataforma es buena para ello.
-
Para seleccionar a los clientes, hemos escogido a personas que tienen interés en comprar obras personalizadas, tengan o no experiencia comprando arte por Internet.
2.2 Listado de participantes
2.2.1 Usuarios piloto de otros grupos
Además de los usuarios pilotos seleccionados anteriormente, a continuación, mostramos el listado de los usuarios piloto asignados de otros grupos. Estos usuarios desempeñarán las funciones tanto de clientes como de artistas para poder evaluar el sistema por completo.
| Nombre | Rol | Email de contacto |
|---|---|---|
| Daniel Galván Cancho | Artista/Cliente | megamagolas@gmail.com |
| Rafael Duque Colete | Artista/Cliente | rafduqcol@alum.us.es |
| Rafael Castillo Cebolla | Artista/Cliente | rafaelcastillocebolla@gmail.com |
| Mohamed Abouri | Artista/Cliente | mohmmedabourihhh@gmail.com |
| Enrique García Abadía | Artista/Cliente | kiquegaraba@gmail.com |
3. Escenarios de prueba
El objetivo de establecer escenarios de prueba es evaluar la funcionalidad de Holos en la gestión de comisiones artísticas. Los usuarios piloto deben probar cada escenario de prueba que les propongamos. En cada entrega de un prototipo, se evaluarán diferentes escenarios de prueba, lo cual se especificará en el documento de guía que le entreguemos a los usuarios piloto.
A continuación se detallan los escenarios de prueba que se deberán de probar por cada Sprint en caso de que sea efectivo y se logren todos los objetivos.
Planificación para el Sprint 1
1. Inicio de sesión
Rol: Cliente y artista
Objetivo: Verificar que los usuarios pueden iniciar sesión sin problemas con las credenciales que les vamos a proporcionar.
A comprobar:
- Que las credenciales proporcionadas sean correctas.
- Iniciar sesión correctamente.
- Poder acceder desde diferentes navegadores.
2. Búsqueda de artistas
Rol: Cliente
Objetivo: Verificar que los usuarios tienen acceso a una página donde pueden buscar los artistas por diferentes parámetros de búsqueda. Les daremos ejemplos de artistas para que puedan buscar.
A comprobar:
- Ver en la pantalla principal ejemplos de comisiones/arte publicado por los artistas.
- Poder buscar a los artistas por nombre.
- Poder filtrar a los artistas por diferentes parámetros.
3. Creación de Comisiones
⭐ Creación de solicitud como usuario
Rol: Cliente
Objetivo: Evaluar la facilidad con la que un cliente puede redactar solicitudes de comisiones personalizadas.
A comprobar:
- Después de seleccionar al artista deseado, hay un botón para poder hacer una solicitud.
- Poder rellenar la solicitud con el nivel de detalle específico según el plan del artista, que en este caso será el básico.
- Poder enviar la solicitud al artista.
⭐ Recepción de solicitud como artista
Rol: Artista
Objetivo: Evaluar la facilidad con la que un artista puede recibir solicitudes bien detalladas.
A comprobar:
- Poder recibir solicitudes hechas por clientes.
4. Gestión de Comisiones
⭐ Uso del tablero
Rol: Artista
Objetivo: Evaluar la funcionalidad del tablero y su utilidad en la organización de comisiones.
A comprobar:
- Recibir una comisión de prueba.
- Mover la comisión por las diferentes fases del tablero.
- Subir avances en cada etapa.
- Leer el feedback del cliente.
⭐ Gestión de pedidos
Rol: Cliente
Objetivo: Ver en una página las comisiones que he pedido y poder dejar feedback.
A comprobar:
- Ver en qué estado está mi comisión.
- Dejar feedback si el artista ha subido una imagen del proceso en una etapa.
Planificación para siguientes Sprint
5. Personalización del perfil de artista y portfolio
Rol: Artistas
Objetivo: Evaluar qué tan intuitivo es el proceso de configuración del perfil del artista.
A comprobar:
- Completar la información del perfil.
- Establecer precios y términos de servicio.
- Definir la cantidad de slots disponibles.
- Poder subir la cantidad de imágenes del portfolio que te permita el plan de precios asignado.
6. Waitlist
Rol: Cliente
Objetivo: Probar cómo se gestionan las listas de espera.
A comprobar:
- Encontrar un artista con plan premium con todos los slots llenos.
- Poder unirse a la waitlist del artista y rellenar una request.
- Simular la liberación de un slot y ver si la notificación se envía correctamente.
7. Personalización del formulario de request en plan Premium
⭐ Personalización del formulario
Rol: Artista
Objetivo: Evaluar la facilidad con la que un artista puede personalizar el formulario de solicitudes de forma detallada.
- Crear un formulario de request personalizado.
- Recibir request que han usado la plantilla personalizada
⭐ Rellenar el formulario personalizado
Rol: Cliente
Objetivo: Probar cómo se rellena el formulario personalizado del artista con el plan premium.
- Encontrar un artista con plan premium y hacerle el pedido.
- Rellenar la plantilla de request personalizada y enviarla.
Más características futuras por añadir
Este documento está sujeto a múltiples cambios dependiendo del Sprint Planning de cada iteración, así que se irá editando conforme se vayan tomando decisiones de diseño e implementación.
4. Plan de Testing y Feedback Survey
El plan inicial consiste en enviar un prototipo por Sprint con lo implementado hasta el momento que sea completamente funcional. Con esto, se busca que los usuarios piloto prueben determinadas funcionalidades y rellenen un formulario de opinión sobre las mismas, de modo que los miembros de nuestro equipo puedan recopilar el feedback, corregir errores, implementar mejoras y, en general, tener en cuenta la opinión de nuestros usuarios piloto para que se sientan valorados.
Fases del Testeo
- Fase 1/Envío 1: Se les enviará un correo con el Commitment Agreement y la próxima fecha estimada del siguiente envío.
- Fase 2/Envío 2: Evaluación de uso del tablero y requests.
- Fase 3/Envío 3: Validación de slots, waitlist y funcionalidades premium.
- Fase 4/Envío 4: Encuesta final con todas las funcionalidades para recopilar impresiones generales y posibles mejoras.
Evaluación del Éxito
Se plantearán preguntas a los usuarios piloto después de probar el sistema. Se les pedirá que especifiquen sus preferencias con respecto a cada funcionalidad concreta que prueben, calificándolas con una nota del 1 al 5 (números discretos), siendo 1 muy descontento y 5 muy satisfecho. Para considerar que el proyecto ha sido un éxito en la iteración final, estimaremos que:
- Más del 80% de los usuarios deben calificar la facilidad de uso/utilidad de cada feature con al menos un 4/5.
- Menos del 10% debe reportar problemas en la plataforma. Con esto nos referimos a todo tipo de incidencia que impida que el usuario pueda disfrutar con plenitud del programa.
Se deben identificar, además, tendencias claras en las respuestas sobre el precio del plan premium con las características que ofrecemos. Esto implica que quizá debamos replantearnos el modelo de negocio si los usuarios piloto no se sienten del todo satisfechos con las funcionalidades, consideran que no valen la pena o que el precio es demasiado elevado. Por el contrario, si los usuarios piloto están muy satisfechos y sienten que nuestra apliación realmente vale la pena, también se podría llegar a considerar un aumento de precio en el plan premium.
4.1 Calendario de envíos
| Envío | Sprint | Fecha de Entrega | Fecha Límite | Estado | Descripción |
|---|---|---|---|---|---|
| 1 | Sprint 1 | 3/03/2025 | 8/03/2025 | Completado | Envío del Commitment Agreement para firma |
| 2 | Sprint 1 | 9/03/2025 | 13/03/2025 | Retrasado | Primera entrega de prototipo para prueba inicial |
| 3 | Sprint 2 | 22/03/2025 | 27/03/2025 | Pendiente | Primera entrega de prototipo con features adicionales. Fusión con el envío 2 |
| 4 | Sprint 3 | 5/04/2025 | 10/04/2025 | Pendiente | Implementación de feedback recibido y funcionalidades adicionales |
| 5 | PPL | 19/04/2025 | 24/04/2025 | Pendiente | Implementación de feedback y evaluación de características visuales (UI) |
| 6 | WPL | 10/05/2025 | 15/05/2025 | Pendiente | Última iteración antes del cierre de pruebas, evaluación definitiva |
Estado de los envíos:
- Pendiente: Aún no enviado.
- Retrasado: No se ha podido cumplir la fecha prevista en el calendario. Se establece otra fecha para ese envío.
- Completado: Se ha recibido feedback y el envío ha sido procesado.
Este calendario será actualizado conforme avancen los sprints y se realicen los envíos a los usuarios piloto. En caso de no cumplir con la fecha de un envío, avisaremos con la máxima antelación posible y nos disculparemos por no haber podido cumplir los plazos. Si un usuario piloto se demora más de la fecha límite para entregar el feedback, se aceptará, pero se valorará negativamente a no ser que tenga una justificación comprensible.
5. Plan de Comunicación
Se establece como objetivo principal que los usuarios piloto tengan acceso a soporte continuo y puedan comunicarse con los miembros del equipo en caso de que surja cualquier tipo de incidencia en el programa de pilotaje.
Canales de Comunicación:
- Email: Para notificaciones formales. Por correo se enviarán las instrucciones de cada envío, las credenciales de cada usuario piloto y el link al despliegue del prototipo.
- WhatsApp/Telegram: Para garantizar soporte en tiempo real y discusión de dudas, así como para avisar en caso de no recibir respuesta por correo electrónico.
- Formulario de Feedback en Google Forms: Para recopilar la opinión de los usuarios piloto sobre nuestra aplicación.
- Formulario de Incidencias en Google Forms: Para que los usuarios piloto puedan rellenarla con las incidencias que han sufrido (si es que se da el caso).
Disponibilidad del Equipo:
Como parte del plan de usuarios piloto, todos los miembros del equipo se comprometen a:
- Responder dudas en menos de 24 horas.
- Enviar, como mínimo, una actualización mensual sobre el proyecto desde que enviamos el primer comunicado del plan de usuarios piloto.
6. Evaluación de los Usuarios Piloto
A pesar de que los usuarios piloto son un pilar fundamental en el proyecto, no todos rinden de la misma manera. Por ello, se evaluará su participación y desempeño durante la fase de pruebas de nuestra aplicación. A través de esta evaluación cuantitativa, buscamos analizar la calidad del feedback recibido, la detección de errores y la utilidad de las sugerencias de mejora.
Para calificar el desempeño del usuario piloto, se asignará un valor dentro de la escala [1,5], donde:
- 1: Muy deficiente
- 2: Deficiente
- 3: Aceptable
- 4: Bueno
- 5: Excelente
Criterios de Evaluación
Se han definido los siguientes criterios para la evaluación:
- Participación activa en la fase de prueba
- Claridad y detalle en la retroalimentación
- Identificación y reporte de errores
- Calidad de las sugerencias de mejora
- Cumplimiento de las instrucciones dadas
- Actitud colaborativa y disposición
- Frecuencia de interacción con la aplicación
- Impacto del feedback en la mejora del producto
Métricas de Evaluación
Participación activa en la fase de prueba
- (1) No interactuó con la aplicación.
- (2) Uso ocasional y sin compromiso.
- (3) Uso moderado y cumplió con las pruebas básicas.
- (4) Uso frecuente y aportó comentarios relevantes.
- (5) Uso constante con contribuciones significativas.
Claridad y detalle en la retroalimentación
- (1) No proporcionó feedback.
- (2) Comentarios vagos o irrelevantes.
- (3) Retroalimentación con algunos detalles.
- (4) Feedback detallado y útil.
- (5) Comentarios estructurados, detallados y valiosos.
Identificación y reporte de errores
- (1) No reportó errores.
- (2) Reportó errores sin descripción clara.
- (3) Identificó errores básicos con descripción moderada.
- (4) Reportó errores detallados con contexto.
- (5) Identificó errores críticos y sugirió soluciones.
Calidad de las sugerencias de mejora
- (1) No proporcionó sugerencias.
- (2) Sugerencias poco relevantes o sin contexto.
- (3) Sugerencias generales y aplicables.
- (4) Sugerencias con justificación y detalles técnicos.
- (5) Propuestas innovadoras y fundamentadas.
Cumplimiento de las instrucciones dadas
- (1) No siguió instrucciones.
- (2) Siguiendo instrucciones mínimas.
- (3) Cumplió con las tareas básicas.
- (4) Realizó todas las tareas correctamente.
- (5) Siguiendo instrucciones con precisión y proactividad.
Actitud colaborativa y disposición
- (1) No mostró disposición para colaborar.
- (2) Participación mínima y poco interés.
- (3) Colaboró ocasionalmente.
- (4) Actitud positiva y dispuesta a ayudar.
- (5) Mostró alta disposición y entusiasmo.
Frecuencia de interacción con la aplicación
- (1) No usó la aplicación.
- (2) Uso muy esporádico.
- (3) Uso moderado.
- (4) Uso regular y constante.
- (5) Uso intensivo y comprometido.
Impacto del feedback en la mejora del producto
- (1) No aportó mejoras.
- (2) Sugerencias sin impacto significativo.
- (3) Comentarios útiles con algunos cambios aplicados.
- (4) Feedback valioso que llevó a mejoras claras.
- (5) Aportaciones críticas que impactaron positivamente.
Evaluación por Fase
Envío 1
Evaluación de Usuarios Piloto
| Nombre | Participación activa | Claridad del feedback | Reporte de errores | Sugerencias de mejora | Cumplimiento de instrucciones | Actitud colaborativa | Interacción con la app | Impacto del feedback | Promedio |
|---|---|---|---|---|---|---|---|---|---|
| Braulio | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Claudia | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Miriam | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Paola | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Víctor | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Yellow | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Alex S | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Patricia | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Artofiz | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Gabriela | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Alex | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Gurutze | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Damaris | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Sofía | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Jeenii | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Emilio | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Rafael | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Félix | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Raúl | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Patricia | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Joker | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Henrique | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Javier Pacheco | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Horacio | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Keegan | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Milagros | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Simón | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Lucas | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
| Carlos | 10 | N/A | N/A | N/A | 10 | 10 | N/A | N/A | N/A |
6.1. Criterios de Evaluación
Para evaluar a los usuarios piloto asignados por la asignatura a nuestro programa de pilotaje, debemos adaptarnos al método de evaluación convencional estableciendo una nota del 1 al 10. Para ello, se ha transformado la evaluación original (de 1 a 5) en un sistema de puntuación más acorde.
Después de evaluar con las mismas métricas descritas en el anterior apartado, se implementa el método de multiplicar por dos la nota para hacer la conversión más sencilla.
- 1 en la escala original → 2 en la nueva
- 2 en la escala original → 4 en la nueva
- 3 en la escala original → 6 en la nueva
- 4 en la escala original → 8 en la nueva
- 5 en la escala original → 10 en la nueva
Después, simplemente se hace un promedio y esa será la nota final.
Ejemplo de Evaluación
Un usuario piloto obtiene estas puntuaciones en la escala de 1 a 5:
| Criterio | Puntuación (1-5) | Convertido (1-10) |
|---|---|---|
| Participación activa | 4 | 8 |
| Claridad del feedback | 5 | 10 |
| Reporte de errores | 3 | 6 |
| Sugerencias de mejora | 4 | 8 |
| Cumplimiento de instrucciones | 5 | 10 |
| Actitud colaborativa | 4 | 8 |
| Interacción con la app | 3 | 6 |
| Impacto del feedback | 2 | 4 |
Promedio: (8+10+6+8+10+8+6+4) / 8 = 7.5
Evaluación por Fase
Envío 1
En el documento pilotUsersPerformanceEvaluation.md o Evaluación del Desempeño de los Usuarios Piloto se detalla la evaluación de los Usuarios Piloto asignados de otros grupos con más exactitud.
| Nombre | Participación activa | Claridad del feedback | Reporte de errores | Sugerencias de mejora | Cumplimiento de instrucciones | Actitud colaborativa | Interacción con la app | Impacto del feedback | Promedio |
|---|---|---|---|---|---|---|---|---|---|
| Daniel Galván Cancho | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
| Rafael Duque Colete | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
| Rafael Castillo Cebolla | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
| Mohamed Abouri | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
| Enrique García Abadía | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
7. Beneficios para los Usuarios Piloto
En el equipo se busca incentivar la participación activa de los usuarios piloto mediante beneficios exclusivos, asegurando una fase de prueba efectiva y con un feedback valioso.
Se garantiza:
- Acceso gratuito al Plan Premium durante los tres primeros meses de uso.
- Prioridad en futuras funciones y mejoras en la aplicación según su feedback.
Estrategia de Fomento del Pilotaje:
- Comunicación clara sobre los beneficios desde el inicio.
- Recordatorios periódicos sobre las pruebas pendientes.
- Encuestas cortas y dinámicas para reducir la carga del usuario y fomentar respuestas rápidas.
- Periodos de prueba largos. Con el objetivo de no agobiar a los usuarios piloto se les dejará un margen de unos 4-5 días para poder probar la aplicación y rellenar la encuesta de feedback.
8. Lecciones Aprendidas
Se ha establecido un equipo que asegurará la asimilación del feedback de los usuarios piloto, de forma que sea escuchado, analizado y aplicado de manera efectiva en la evolución de Holos.
Estrategia para asimilar el Feedback:
-
Clasificación de Incidencias:
- Críticos: Errores que afectan la funcionalidad clave (ej. problemas en pagos, fallos en la gestión de comisiones, etc).
- Importantes: Funciones que mejoran la experiencia pero no bloquean el uso (ej. mejoras en la interfaz, añadidos importantes a considerar, etc).
- Opcionales: Sugerencias que aportan valor pero no son esenciales.
-
Transparencia con los Usuarios Piloto:
- Resumir en reportes qué feedback ha sido tomado en cuenta para que puedan comprobarlo.
- Explicar qué sugerencias se implementarán y cuáles se consideran para el futuro.
- Incluir a los usuarios más activos en la toma de decisiones finales.
9. Conclusiones
El programa piloto de Holos es una fase clave para evaluar la viabilidad y usabilidad de la plataforma antes de su lanzamiento oficial. A través de la participación activa de los usuarios piloto, se han de identificar fortalezas, áreas de mejora y algunos ajustes necesarios para garantizar una experiencia óptima para nuestros usuarios finales.