Grupo C - DondeSiempre

En esta página se encuentra el feedback recogido por el grupo C - DondeSiempre durante el curso. Este feedback incluye comentarios, sugerencias y recomendaciones proporcionados por el profesor para mejorar el desempeño del grupo en futuras actividades y proyectos.

Última actualización: 26 de marzo

1. Tips para Presentaciones

• Gestión del tiempo y ritmo: En la Semana 4 se comentó que hubo "demasiado contenido y demasiado rápido". Es vital hablar más tranquilos y dar tiempo al cliente/profesor para asimilar los conceptos, especialmente en partes densas como el CI/CD. Se recomienda simplificar o reducir el contenido menos crítico.
• Hilo conductor y transiciones: El flujo narrativo debe tener sentido global. Evitad "saltos extraños" entre temas que rompan el hilo (por ejemplo, pasar del Team Building a los Usuarios Piloto; el Team Building debe presentarse junto a la sección del equipo). Las transiciones de ponente deben ser naturales.
• Equilibrio técnico/visual: Aunque el análisis técnico sea muy bueno, evitar un nivel de detalle excesivo en las diapositivas que abrume a la audiencia.Las presentaciones no deben perder los apoyos visuales en ningún momento. Mantener el equilibrio para no abrumar con texto, pero dejad en pantalla el tiempo suficiente las diapositivas con gráficas o datos complejos para que se puedan procesar.
• Seguimiento de proyecto: En las transparencias de seguimiento, las desviaciones deben ser explícitas. No mostrar solo horas; indicar desviaciones en contenidos y funcionalidades (qué se estimó vs. qué se hizo). Además, es clave resaltar el estado anterior y el actual a lo largo del Sprint y del total del proyecto.
• Explicación del CI/CD: Debe explicarse con suficiente detalle técnico (se pidió en la semana 3), pero con el tiempo necesario para que se entienda (en la semana 4 se pasó demasiado rápido).
• Demos Reales, Diferenciadoras y con Historia: Es obligatorio transicionar a demostraciones reales (en vivo o vídeo) asegurando un zoom adecuado para que se vea perfectamente. No mostréis funcionalidades aisladas; usad una historia de usuario como hilo conductor y aseguraos de que la demo destaque claramente los elementos diferenciadores de la plataforma frente a la competencia.
• Flujo de la Herramienta: Al mostrar la aplicación, refinar la explicación trazando un flujo claro de cómo funciona cada interacción con la herramienta.
• Síntesis y Feedback: Mantener el énfasis, la prioridad y la capacidad de síntesis, demostrando que se refleja activamente el feedback proporcionado en las semanas anteriores.
• Narrativa con flujo lógico: Transicionar hacia un modelo de demostración con una historia desde la perspectiva del usuario (ej. un cliente que llega desde Instagram).
• Gestión de tiempos visuales: Mantener durante más tiempo las diapositivas que contengan gráficas o datos complejos para que la audiencia pueda procesarlos.

2. Tips para Análisis de competidores

• Narrativa específica: Hablar primero del competidor (pequeña exposición de quiénes son), acto seguido, resaltar la diferenciación.
• Evitar lo genérico: El análisis DAFO debe reflejar la realidad específica del proyecto. Un DAFO que "podría aplicar a cualquiera" no aporta valor.
• Profundidad: Se exige una búsqueda objetiva y profunda, no superficial.
• Tabla Comparativa: Asegurarse de que en la tabla final figure nuestro propio MVP (DondeSiempre) para comparar funcionalidades visualmente.

3. Tips para Usuarios Piloto

• Objetivo Numérico: El número actual es bajo. El objetivo concreto es conseguir entre 12 y 20 tiendas reales.
• Acción Inmediata: Disponer de una lista de contactos sólida y salir a hablar con ellos cuanto antes.
• Validación de Precios: Usar a los pilotos para fijar el precio. Pregunta clave a realizarles: "¿Cuánto estarías dispuesto a pagar?".
• Dependencia: El éxito del proyecto depende directamente de la masa crítica de comercios en la aplicación.
• Análisis de feedback: No solo identificar bugs con los pilotos, sino explicar cómo esos hallazgos impactarán en la planificación o el backlog.

4. Tips para Killer Opener

• Objetivo Principal: Conseguir la atención del público desde el primer momento.
• Gestión del Tiempo: Emplear un tiempo máximo de 1 minuto. Presentarse como grupo y presentar cada uno de los ponentes.
• Interacción con la audiencia: Orientarlo a todo el público. Evitar preguntas abiertas retóricas o aquellas en las que todos conocen la respuesta (no aportan valor y pueden quedar artificiales).
• Coherencia: El opener no debe ser un "show" aislado; tiene que estar totalmente alineado con la narrativa del resto de la presentación.
• Variedad: No quedarse siempre con el mismo killer opener. Hay que ser atrayentes y buscar fórmulas nuevas que generen más enganche.
• Fuentes de Datos: Si se usan datos de impacto en el contexto real (ej. "se cierran 37 tiendas de media diariamente"), es obligatorio citar las fuentes para demostrar su veracidad.
• Toma de control inmediata: No esperéis a que la sala se quede en silencio por sí sola. El objetivo del opener es irrumpir, llamar su atención de golpe y hacer que su foco cambie hacia vosotros en menos de 1 minuto.
• Contenido seguro y alineado: El inicio debe estar totalmente alineado con la narrativa de la presentación. Además, evitad estrictamente tocar temas polémicos (como mencionar "residentes ilegales" u otros temas sensibles que puedan desviar la atención negativamente).

5. Tips para Idea de Negocio

• Responder clarísimamente: "¿Qué valor real aporta la plataforma a una pequeña tienda local?".
• Funcionalidad RRSS: La propuesta de valor diferencial es la automatización de RRSS (crear catálogo -> genera post automático en Instagram). Considerar si esta función debería ser gratuita (o una versión limitada gratis) para captar usuarios, en lugar de ser de pago desde el inicio.
• Información sensible: Riesgo alto de que competidores vean precios de otros y se genere "guerra de precios" o venta de información. Analizar y explicar cómo se controla esto.
• Viabilidad financiera: Justificar si es viable estar los primeros 4 meses sin ingresos (pagar sueldos, servidores, etc.).
• Claridad en el modelo: Diferenciar qué es core, qué es extra, y cómo se monetiza cada perfil.

6. Tips para Análisis de Coste y Presupuesto

• Precisión: Cuidado con la palabra "salario". Especificar siempre si es Salario Bruto, Líquido o Coste de Empresa/Contrato para evitar errores de interpretación.
• Análisis de Planes: Afinar el coste de los planes de suscripción basándose en el feedback de los pilotos, no en suposiciones.
• Nivel de Detalle: No ir al céntimo con los costes; es mucho mejor dar los números grandes para facilitar la lectura y comprensión.
• CapEX vs. OpEX: Aclarar la diferencia conceptual en los costes de contratación. El coste de construir el software debe añadirse al CapEX (que tiene mayor peso inicial). El OpEX debe reservarse para los gastos una vez construido el software (mantenimiento, soporte, etc.). Importante: no se debe separar el OpEx del mantenimiento, ya que forma este forma parte del primero.
• Formas de pago: Proporcionar formas claras de establecer costes (coste por hora, por trabajador, etc.) y evitar diapositivas con cifras que aturullen.
• Revisión de beneficios: Validar la coherencia de las estimaciones de ingresos (ej. los 500.000€ previstos) para que sean realistas.
• Punto de Equilibrio (Break Even): Mucho cuidado al calcular y presentar el Break Even en relación con el CapEx. Revisar bien los números para que no haya incongruencias financieras.

7. Tips para Organización del Equipo

• Política de Código: Norma estricta: Todos los miembros deben hacer commits, independientemente de si su rol es marketing o documentación.
• Priorización (Secuenciación): Planificar las tareas priorizando el desarrollo de las funcionalidades que aportan valor diferenciador frente a la competencia.
• Team Building: Se sugiere buscar dinámicas (opcionales) para fomentar el "buen rollo" ante los desajustes habituales del trabajo. Dadle mayor peso de manera general a las acciones de Team Building para fomentar el buen ambiente ante los desajustes, y aseguraos de presentarlo lógicamente cuando habléis de la organización del equipo.
• Comunicación: Aclarar en la presentación cómo se organiza el equipo (chat, reuniones, frecuencia).
• Gestión del Alcance: Reducir el alcance es una muy buena opción y una excelente práctica de gestión ante imprevistos; no es algo de lo que el equipo deba avergonzarse.
• Umbrales de éxito: Al definir una acción de mejora, marcar siempre un umbral objetivo (ej. "reducir un X% en este periodo").
• Gestión del sobreesfuerzo: Establecer mecanismos para evitar que el equipo trabaje el doble de lo pactado, analizando el impacto ético y económico.
• Métricas de valor: Definir el éxito de las tareas no solo por horas, sino por su peso, impacto y resolución efectiva.
• Rendimiento vs. Horas: Es un error conceptual grave medir el rendimiento en horas. O se miden horas consumidas, o se mide rendimiento (impacto, peso, resolución), pero no se puede medir el rendimiento en horas.
• Concreción en las medidas correctivas: No usar frases genéricas como "se tomarán medidas" ante imprevistos o sobreesfuerzos. Hay que ser concretos y especificar qué tipo de medida exacta o métrica se va a aplicar. Marcar siempre un umbral de éxito objetivo (ej. "reducir un X%").
• Dinámica de trabajo: Mantened la norma estricta de que todos hagan commits, priorizar tareas de valor diferenciador, aclarar canales de comunicación y recordad que reducir el alcance es una práctica de gestión válida de la que no hay que avergonzarse.

8. Tips para Commitment Agreement y Clockify

• Visualización: Presentar una imagen global donde se vea a todo el equipo para comparar participaciones.
• Análisis de Desviaciones: Explicar claramente por qué hay desviaciones elevadas. Entender y transmitir que tener un exceso de horas es igual de negativo que no llegar a las comprometidas, ya que indica una mala planificación.
• Gestión del Exceso de Horas: No basta con reconocer que mucha gente está muy desviada en horas; falta explicar si se va a seguir permitiendo y cómo se va a gestionar o abordar este problema a futuro.
• Detalle del Commitment: Refinar cómo se expone el acuerdo. Evitar que parezca genérico explicando las características concretas de cada Commitment y cómo se está abordando. Es muy recomendable crear una especie de checklist visual para demostrar su seguimiento.
• Transparencia en desviaciones: Explicar claramente si las tareas retrasadas se han replanificado, omitido o resuelto.

9. Notas

Semana 1 (05/02) [La idea era Knot, luego se cambió]

• No queda muy claro por qué estaría la gente dispuesta a pagar por la aplicación. (ej. Un talento pague por ser más promocionado). Concretar más y detallar mejor los aspectos diferenciadores y el valor añadido.
• Diversificar el foco de la aplicación (es decir, tener relaciones start-up inversor y start-up talento) puede hacer más difícil el aportar un valor añadido concreto.
• No se ve reflejada una búsqueda de competidores objetiva ni profunda.
• ¿Sólo se centrarán en start-ups? ¿O cualquier empresa? Debe quedar claro. O todos los tipos, un tipo, pero debe dejarse claro.
• En el apartado de la monetización, no queda claro cuál es el elemento core, cuál es el extra, o la extensión de los ingresos por suscripciones, anuncios, pagos únicos, etc.
• Debe dejarse claro qué valor se aporta a cada perfil de la aplicación: start-up, inversor y talento.

Semana 2 (12/02)

• Idea con potencial, casos de uso core diferenciados, pero no suficientemente detallados para ser una presentación a un cliente.
• Fundamental tener una lista de tiendas con las que hablar, pues nuestro éxito depende del número de tiendas y clientes que tengamos en la aplicación.
• Posible Idea por parte de Pablo: marketing en RRSS, a partir de la creación de un catálogo en la aplicación, suba un post a Instagram promocionándolo.
• Secuenciación de actividades pobre. Deben priorizarse las tareas o el desarrollo que se centre en el valor diferenciador, todo lo que te diferencia con los competidores.
• Hacer un análisis de riesgo más exhaustivo para el stack tecnológico: cuánta gente del grupo lo conoce, qué pasa si cambian la capa gratuita, reacción ante estos riesgos, etc.
• Preguntarnos: ¿Qué valor aporta la plataforma para una pequeña tienda de la localidad?
• Tener cuidado con la información. Cualquier persona con la aplicación podrá ver los precios de sus competidores, podría haber venta de información entre competidores. Analizar este riesgo.

Semana 3 (19/02), evaluación

• Presentación correcta, pero podría mejorarse la fluidez entre cambios de ponentes.
• Importante aclarar que todo el mundo va a hacer código, los de documentación, los de marketing, todos deben commitear código al repositorio.
• Las funcionalidades se han comunicado y expuesto correctamente.
• Para los competidores, es importante hablar primero de los competidores y luego lo que nos diferencian, pequeña exposición de cada competidor.
• El CI/CD no ha quedado muy claro, debería detallarse mejor para la próxima presentación.
• Número de usuarios piloto bajo. Deben buscarse más tiendas, entre 12 y 20.
• En nuestro análisis DAFO había bastantes aspectos genéricos, no parecía que fuese de nuestro proyecto, podría haber aplicado a cualquiera.

Semana 4 (26/02):

• Buen killer opener, buenas transiciones en la presentación.
• Demasiado contenido y demasiado rápido, muchas cosas, realmente está muy bien visualmente y se ha hecho un gran esfuerzo, pero al ser tan rápido, no da tiempo a asimilarlos. - Intentar hacer un análisis de cómo centrar ciertas cosas, hablar más tranquilos.
• Siempre aparecen desajustes. ¿habéis pensado algún modelo de team building? De forma opcional. Buscar buen rollo en los equipos.
• Análisis de tecnologías muy bueno, pero tanto detalle… Buscar un equilibrio. Se nota mucho el trabajo que hay por detrás, pero quizás el detalle en las presentaciones no debería ser tan profundo.
• Interesante la forma de presentar el CI/CD, pero se ha pasado demasiado rápido y no éramos capaces de interiorizar nada.
• En las transparencias del seguimiento sucede un error habitual, hay que decir de una forma más explícita desviaciones sobre lo estimado, no sólo en horas, sino también en contenidos, en funcionalidades hechas, etc.
• Cuidado con usar la palabra salario, no es igual salario bruto, liquido, coste de contrato, etc. Puede llevar a error.
• Búsqueda de pilotos interesante y buena, pero nuestro core funciona en base a los comercios que están en la aplicación, podría ampliarse más.
• Lo que más nos diferencia, que es la automatización de RRSS, está puesto como pago. Cree Pablo que debería ser gratuita, o al menos una versión más limitada, y ya se pone de pago la que está un poco más completa.
• Estaría bien hacer un análisis más fino de los costes de los planes. La forma de decidir esos precios, cuando ya tienes usuarios piloto, debería ser guiado por los usuarios piloto y las funcionalidades, cuánto estarían dispuesto a pagar los usuarios pilotos. Pregunta abierta: ¿Cuánto estarías dispuesto a pagar?
• Es igual de malo no llegar a las horas como que haya que echar un montón de horas para poder llevar a cabo el proyecto.

Semana 5 (05/03, evaluación):

• Tener cuidado. Es interesante comenzar a transicionar hacia demos reales, funcionando el sistema en tiempo real, un vídeo, no solo imágenes. Que pueda verse qué está desarrollado de verdad.
• No ir al céntimo con los costes, dar los números grandes.
• Problema conceptual del análisis del CapEX y el OpEX, en los costes de contratación. Los costes están en el opex, pero hay que diferenciar, pues están en los dos ámbitos, pero en nuestro caso es mayor en el CapEX, pues el construir el software forma parte del capex. Los del OpEX son una vez se ha construido el software, tema de mantenimiento, soporte, etc. Añadir al CapEX los costes de contratación.
• Muy bien: el reducir el alcance, muy buena opción que todos tenemos y no es algo de lo que avergonzarnos. Es una buena práctica de gestión.
• Se refleja el feedback proporcionado la semana pasada. Énfasis, prioridad, síntesis.
• Killer Opener: interesante, nos sitúan en un contexto real, pero: No siempre quedarnos con el mismo killer, ser atrayentes, algo que genere más enganche. ¿Cómo puedo demostrar que son 37 tiendas las que se cierran de media diariamente? Poner fuentes.
• Herramienta: se han mostrado detalles. Por refinar un poco: un flujo más de cómo funciona cada interacción con la herramienta.
• Exceso de horas: sigue chirriando. Mucha gente muy desviada, falta un análisis de: esto pasa, ¿lo vamos a seguir permitiendo? Una vez reconocido el problema, gestionar cómo se va a abordar. (ya que funcione o no es otra cosa)
• Commitment agreement: podría refinarse, no se dicen las características concretas de cada Commitment, no sabemos si es el genérico y cómo se está abordando. Ideal hacer una especie de checklist para que se vea cómo se está abordando.

Semana 6 (12/03):

• Definir umbrales: No basta con medir; cada acción de mejora debe incluir un objetivo porcentual y un marco temporal específico.
• Más allá de las horas: Es necesario definir métricas de impacto y peso de las tareas, no solo contabilizar el tiempo dedicado.
• Análisis de calidad: Se reconoce un buen esfuerzo técnico en la automatización y profundidad de las pruebas de aseguramiento.
• Hilo conductor: La demo debe seguir una historia lógica desde la perspectiva del usuario (ej. flujo desde Instagram a la tienda).
• Tiempos de exposición: Mantener más tiempo en pantalla las gráficas o datos complejos para permitir su correcta lectura.
• Killer Opener: Evaluar si ciertos elementos "divertidos" son adecuados para el contexto o si deben alinearse más con el producto.
• Evitar errores técnicos visibles, como outfits sin imagen; es preferible usar datos ficticios que dejen la interfaz incompleta.
• Roles claros: Se valora positivamente que se hayan identificado y mostrado los distintos roles de usuario en la demo.
• Gestión del sobreesfuerzo: Buscar mecanismos para evitar que los miembros del equipo doblen su carga de trabajo y analizar su impacto en el coste.
• Transparencia en la planificación: Aclarar si las tareas retrasadas se han resuelto, omitido o si han provocado una replanificación del sprint.
• Usuarios piloto: Detallar qué pruebas específicas hicieron los usuarios y cómo sus bugs afectarán al plan de trabajo.
• Claridad financiera: Desglosar los costes (ej. coste por hora o por trabajador) y revisar la coherencia de la estimación de beneficios de 500.000€.

Semana 7 (26/03, evaluación):

• Enfoque Narrativo (Storytelling): Evolucionar las demostraciones de producto hacia un modelo basado en historias de usuario, evitando la presentación de funcionalidades de manera aislada para aportar mayor contexto y valor.
• Optimización del Ritmo y Contenido: Se percibe una alta densidad de información debido a la extensión. Se recomienda simplificar o reducir ciertos apartados para mejorar la comprensión del mensaje.
• Refinamiento del Hilo Conductor: Fortalecer la transición entre bloques temáticos para evitar saltos abruptos.

  Ejemplo: Suavizar el paso de la sección de Team Building a Usuarios Piloto (una posible solución es integrar la presentación del equipo dentro de la dinámica de Team Building).

• Gestión de Expectativas: Mantener una actitud proactiva ante el feedback recibido, ya que la capacidad de reacción del equipo se considera un factor diferencial y clave para el éxito del proyecto.