Qué puede evaluarse
RA1: Identifica necesidades del sector productivo, relacionándolas con proyectos tipo que puedan satisfacerlas.
Clasificación empresarialEstructura organizativaDepartamentos funcionalesB2BB2CSaaSDesarrollo a medidaNecesidades del mercadoOportunidades de negocioAnálisis DAFO
RA2: Diseña proyectos relacionados con las competencias expresadas en el título, desarrollando explícitamente las fases que lo componen.
StakeholdersObjetivos SMARTAlcance del proyectoDeriva del alcance (Scope Creep)BenchmarkingViabilidad técnicaRiesgos técnicosFases del proyectoHitosDiagrama de Gantt
RA3: Planifica la ejecución del proyecto, determinando el plan de intervención y la documentación asociada.
Estructura de Desglose del Trabajo (EDT/WBS)Secuenciación de tareasDependencias de tareasRuta CríticaDiagrama de GanttProcedimiento Operativo Estándar (POE)Recursos materialesRecursos humanosLogística del proyectoAsignación de recursos
RA4: Define los procedimientos para el seguimiento y control en la ejecución del proyecto, justificando la selección de variables e instrumentos empleados.
Procedimiento de evaluación de actividadesObjeto de evaluación (tarea, hito, fase)Responsable de la evaluaciónMétodo de evaluación (comparación planificado-real, criterios de aceptación)Registro y documentación de la evaluaciónPeriodicidad del seguimiento
Trampas habituales antes del examen
- Asumir homogeneidad en el sector: La diversidad de modelos de negocio y tamaños empresariales en el sector TIC es enorme. No investigar a fondo lleva a generalizaciones erróneas sobre sus necesidades. Corrección: Siempre segmentar y caracterizar el tipo de empresa antes de inferir sus demandas.
- Confundir rol de departamento con rol de persona: Un departamento puede tener múltiples funciones, y una persona puede desempeñar varios roles en una microempresa. Corrección: Entender las funciones esenciales de cada área, independientemente de quién las ejecute.
- Basar la oportunidad en una percepción personal: La creencia de que 'esto es una buena idea' sin validación de mercado. Corrección: Siempre buscar datos, encuestas, entrevistas y análisis de la competencia para fundamentar la oportunidad.
- Subestimar la complejidad de la necesidad: Pensar que una necesidad es sencilla de resolver sin considerar todos los requisitos funcionales y no funcionales. Corrección: Desglosar la necesidad en requisitos específicos y estimar la complejidad técnica y de negocio.
- Sobredimensionar el proyecto inicial: Intentar incluir demasiadas funcionalidades en la primera versión, lo que aumenta costes y tiempo. Corrección: Priorizar las funcionalidades clave (MVP - Producto Mínimo Viable) y planificar iteraciones futuras.
- No validar los requisitos con el cliente: Asumir que se ha entendido todo sin una confirmación explícita. Corrección: Realizar revisiones periódicas de los requisitos con el cliente o usuario final para asegurar que el proyecto se alinea con sus expectativas.
- No presupuestar los costes asociados a las obligaciones legales: Olvidar incluir en el plan de negocio los costes de gestoría, cotizaciones, impuestos, etc. Corrección: Elaborar un presupuesto detallado que contemple todos los gastos operativos y legales desde el inicio.
- Solicitar ayudas sin cumplir los requisitos: Presentar una solicitud sin haber leído a fondo las bases de la convocatoria. Corrección: Verificar exhaustivamente la elegibilidad, la documentación requerida y los plazos antes de iniciar cualquier trámite.
- No definir claramente el alcance: Esto lleva a la 'deriva del alcance' (scope creep), donde se añaden funcionalidades no previstas, aumentando costes y plazos. Corrección: Documentar explícitamente qué está dentro y fuera del alcance, y gestionar cualquier cambio mediante un proceso formal.
- Ignorar la gestión de riesgos: No prever posibles problemas puede paralizar el proyecto. Corrección: Realizar un análisis de riesgos al inicio, identificar los más probables y sus impactos, y definir planes de contingencia para cada uno.
- **Recopilación superficial:** No profundizar en las necesidades reales del usuario o del negocio, basándose en suposiciones. Causa: Falta de técnicas de entrevista o miedo a preguntar. Corrección: Utilizar preguntas abiertas, 'los 5 porqués' y validar la información con múltiples fuentes.
- **Objetivos vagos:** Establecer metas como 'hacer una aplicación mejor'. Causa: Falta de comprensión de los criterios SMART. Corrección: Convertir cada objetivo en medible y con un plazo, por ejemplo, 'mejorar la velocidad de carga en un 20% en 3 meses'.