Feedback general primera evaluación
Este es el documento dentro de la categoría Conocimiento común. El contenido presentado puede modificarse añadiendo nuevos puntos a tratar.
1. Narrativa y Estructura del Discurso
Para lograr una defensa exitosa, es fundamental construir un hilo conductor continuo. La presentación debe fluir lógicamente de principio a fin, evitando saltos erráticos entre secciones o retrocesos que confundan a la audiencia.
El enfoque del discurso debe priorizar el valor aportado sobre la implementación técnica. No se trata solo de explicar cómo funciona, sino de vender la solución. Esto requiere que el equipo muestre pasión y convicción; es imperativo "creerse" lo que se está vendiendo. Además, se debe evitar el contenido genérico (que podría aplicar a cualquier proyecto) y centrarse exclusivamente en lo que hace única a vuestra propuesta.
2. Diseño Visual y Material de Soporte
Las diapositivas deben diseñarse bajo la premisa de la economía del texto e impacto visual. Se recomienda sustituir párrafos por imágenes o esquemas siempre que sea posible. Una buena métrica de calidad es la "regla de los 15 segundos": si un oyente se distrae y vuelve a mirar la pantalla, debe ser capaz de reengancharse y entender qué se está analizando de un solo vistazo.
Es crucial cuidar aspectos estéticos como el tamaño de la letra, el contraste de colores y el zoom de las capturas. Los mock-ups no deben ser meramente decorativos, sino que deben utilizarse para resaltar visualmente los elementos diferenciadores de la propuesta. Durante la exposición, el ponente debe ocupar el espacio con naturalidad, pero teniendo especial cuidado de no bloquear la proyección ni tapar el contenido visual.
3. Objetividad y Usuarios Piloto
El análisis de competidores exige profesionalidad y objetividad. Se deben evitar juicios de valor subjetivos o despectivos (tipo "esto no funciona", "nadie los conoce"). En su lugar, el análisis debe basarse en datos concretos que justifiquen por qué, a pesar de existir esas alternativas, el cliente debería elegir vuestra solución. La diferenciación debe ser radical y estar detallada a fondo.
Un requisito indispensable en esta fase es la validación con el mercado real: es obligatorio presentar una lista de usuarios piloto (clientes reales contactados) para demostrar tracción. La ausencia de este listado se considera una carencia grave en la viabilidad del proyecto.
4. Justificación Técnica y Metodología
Las decisiones tecnológicas no pueden basarse en la inercia o la duda. Si existe un debate entre dos tecnologías (Stack X vs. Stack Y), la elección final debe estar respaldada por un análisis comparativo que exponga las razones técnicas y de negocio para elegir una y descartar la otra. Asimismo, los planes de Integración y Despliegue Continuo (CI/CD) deben dejar de ser abstractos y concretarse con detalle técnico.
A nivel metodológico y de equipo, existe una regla: la implicación debe ser total. Debe quedar explícito y patente que todos los miembros del equipo van a desarrollar código, independientemente de sus roles de gestión o documentación.
5. Logística, Coordinación y Penalizaciones
El éxito de la presentación también depende de la preparación logística. Es vital ensayar la puesta en escena repetidamente para pulir tiempos y transiciones. Se recomienda encarecidamente a los coordinadores el uso de herramientas de control de tiempo (como ISPP Timer) y la gestión proactiva de recursos, como solicitar con antelación por correo a secretaría cualquier hardware necesario (mandos para diapositivas, adaptadores, etc.).
Finalmente, antes de cada entrega, es responsabilidad del grupo consultar la Base de Conocimiento Común. Entregar o presentar sin verificar los requisitos esperados conlleva penalizaciones directas por omitir contenidos obligatorios.