2. La propuesta de proyecto

Una idea todavía no es un proyecto. Para que lo sea hay que decir qué se va a conseguir, qué entra y qué no, qué tiene que cumplir lo que entregues y de qué partes se compone el trabajo. Esta página te enseña a hacerlo y a resumirlo en una propuesta de una página que tu profesor pueda valorar. Trabaja los criterios de identificar las partes del proyecto y de prever sus recursos.

Cómo trabajar esta página

Tiempo orientativo: unos 50 minutos de lectura y 2 horas de práctica.

1. Parte de la idea que ganó en la matriz de la página anterior.
2. Lee las secciones 1 a 4 y rellena la pestaña «Requisitos» del laboratorio.
3. Las secciones 5 y 6 se practican en la pestaña «Alcance y EDT». Después haz la actividad 5.

1. Qué es un «pequeño proyecto» aquí

La programación del módulo habla de elaborar «un pequeño proyecto», pero no fija su tamaño. Esta web propone el siguiente criterio, que tu profesor puede ajustar:

Tamaño del proyecto (propuesta)

Un proyecto de esta unidad es un trabajo que un equipo de dos o tres personas puede diseñar, planificar y simular en el aula, pensado para una pyme concreta y resuelto con lo que sabe hacer un técnico SMR: instalar, configurar, mantener, proteger o documentar equipos y redes. Debe tener un solo problema central, entre tres y siete partes y un presupuesto de unos pocos miles de euros. Si tu idea necesita meses de trabajo, hay que recortarla.

2. Objetivos

El objetivo general dice para qué existe el proyecto en una frase. Los objetivos específicos lo bajan a resultados concretos. Para que sirvan, se redactan con el criterio SMART:

Letra	Significa	Pregunta de comprobación
S	Específico (specific)	¿Se entiende exactamente qué se quiere conseguir?
M	Medible (measurable)	¿Hay un número o una prueba que diga si se ha conseguido?
A	Alcanzable (achievable)	¿Podemos hacerlo con nuestros medios y tiempo?
R	Relevante (relevant)	¿Resuelve la necesidad que detectamos?
T	Con plazo (time-bound)	¿Hay una fecha o un periodo para lograrlo?

Dos ejemplos de objetivo para el proyecto de copias de Reparaciones Byte Alacant, S. L. (empresa ficticia):

Mal redactado	Bien redactado
«Mejorar las copias de seguridad»	«Instalar copias automáticas diarias en 5 pymes clientes en 8 semanas»
«Que los clientes estén contentos»	«Restaurar con éxito una copia de prueba en cada pyme al menos una vez al mes, con un tiempo de recuperación menor de 2 horas»

El primer «mal redactado» no dice cuánto, a quién ni cuándo. Si no puedes medirlo, no sabrás si has terminado.

3. Alcance

El alcance es la frontera del proyecto: qué hace y qué no hace. Lo importante es la segunda mitad. Casi todos los proyectos se retrasan porque se les va añadiendo trabajo sin decirlo.

Apartado	Qué contiene	Ejemplo
Dentro del alcance	Lo que se entrega	Copia diaria de las carpetas de trabajo; copia externa cifrada; restauración de prueba; manual de una página
Fuera del alcance	Lo que se descarta, aunque suene razonable	Migrar los programas de los clientes; copiar los móviles personales; atención 24 horas
Supuestos	Lo que damos por cierto	Cada pyme tiene conexión a Internet estable; hay una persona de contacto
Restricciones	Límites que no controlamos	Presupuesto máximo; plazo; instalar fuera del horario de apertura

Escribir «fuera del alcance» no es pereza: es una protección. Si el cliente pide algo de esa lista, se negocia como un cambio, con su coste.

4. Requisitos

Un requisito es algo que el proyecto debe cumplir. Se clasifican en:

• Funcionales: qué hace el sistema o el servicio («hace una copia diaria a las 22:00»).
• No funcionales: cómo lo hace («la restauración tarda menos de 2 horas»; seguridad; facilidad de uso).
• Restricciones: condiciones impuestas («solo software con licencia gratuita para uso comercial»).

Cada requisito importante lleva un criterio de aceptación: la prueba que dirá «cumplido» o «no cumplido».

4.1 Priorizar con MoSCoW

No todo es igual de importante. El método MoSCoW reparte los requisitos en cuatro grupos:

Grupo	Significa	Ejemplo
Must (debe)	Sin esto el proyecto no sirve	Copia diaria automática
Should (debería)	Muy importante, pero hay alternativa provisional	Aviso por correo si la copia falla
Could (podría)	Deseable si sobra tiempo	Informe mensual con gráficas
Won’t (no ahora)	Acordado que no se hace en esta versión	Copia de dispositivos móviles

Cuidado con tener «Must» por todas partes

Si todo es imprescindible, nada lo es. Como regla de esta unidad (propuesta), no más del 60 % de los requisitos deben ser Must. El laboratorio te avisa si te pasas.

5. Partes interesadas

Una parte interesada (stakeholder) es toda persona o entidad que afecta al proyecto o se ve afectada por él. Identificarlas pronto evita sorpresas: el requisito que olvidas casi siempre pertenece a alguien que no preguntaste.

Se ordenan en una cuadrícula de poder (cuánto puede influir) e interés (cuánto le afecta):

	Interés bajo	Interés alto
Poder alto	Mantener satisfecha	Gestionar de cerca
Poder bajo	Vigilar	Mantener informada

Ejemplo (proyecto de copias): la gerencia de cada pyme (poder y interés altos: gestionar de cerca); el personal administrativo que usa los equipos (poder bajo, interés alto: mantener informado); la gestoría que lleva su contabilidad (poder bajo, interés medio: vigilar); el proveedor del servicio en la nube (poder alto, interés bajo: mantener satisfecho con el cumplimiento de sus condiciones).

Cada requisito debería tener al menos una parte interesada que lo necesite. Un requisito sin nadie detrás suele sobrar.

6. Las partes del proyecto: la EDT

La estructura de desglose del trabajo (EDT) —en inglés WBS, work breakdown structure— descompone el proyecto en partes cada vez más pequeñas hasta llegar a paquetes de trabajo: tareas concretas con un resultado entregable y una estimación de horas.

Ejemplo del proyecto de copias:

Fase	Paquete de trabajo	Entregable	Horas
1. Diseño	1.1 Inventario de datos y requisitos de cada pyme	Ficha de cada pyme	8
	1.2 Política de copias	Documento de política	6
2. Despliegue	2.1 Instalación y configuración del almacenamiento	Equipos configurados	20
	2.2 Copia externa cifrada	Copia en la nube activa	6
3. Pruebas	3.1 Restauración de prueba en cada pyme	Informe de pruebas	8
4. Entrega	4.1 Formación y manual	Manual y sesión de formación	6
	4.2 Gestión y cierre	Acta de entrega	4
	Total		58

Cuatro reglas para que la EDT sea buena:

1. Todo el trabajo está dentro y nada más: si una tarea no cuelga de ningún paquete, o no es del proyecto o se te ha olvidado.
2. Cada paquete produce algo comprobable (un entregable), no «estar trabajando en».
3. Las horas son una estimación honesta: pregunta a quien haya hecho algo parecido y suma un poco de margen en la contingencia (ya lo verás en el presupuesto).
4. El total de horas de la EDT tiene que cuadrar con las horas de personas que prevés en el presupuesto.

La EDT es la base de la planificación: en la Unidad 3 pondrás estos paquetes en un cronograma, con orden y dependencias.

7. La propuesta de una página

Todo lo anterior se resume en una propuesta de proyecto de una sola página, que es lo que tu profesor valora antes de que sigas:

1. Título del proyecto y equipo.
2. Necesidad detectada (con su evidencia).
3. Solución propuesta y aspecto innovador.
4. Objetivo general y objetivos específicos SMART.
5. Alcance: qué entra y qué no.
6. Recursos y coste estimados (cifras aproximadas por ahora).
7. Plazos principales.
8. Riesgos principales (dos o tres).
9. Criterios de calidad con los que se dará por bueno.
10. Relación con los ODS.

Al final de la unidad, tras el presupuesto, la memoria y la presentación, tu profesor firma la hoja de aprobación (hito «proyecto aprobado»). Hasta entonces la propuesta es una versión 1 que se afina con sus comentarios.

Cómo se aprueba (propuesta)

Que el profesor apruebe la propuesta al cierre de la unidad es una decisión provisional de esta web. Tu profesor te dirá el procedimiento exacto y las fechas en Aules.

Comprueba lo aprendido

1. ¿Por qué «mejorar la atención al cliente» no es un buen objetivo? Reescríbelo de forma SMART para un servicio técnico.

   Respuesta

   Porque no es medible ni tiene plazo. Una versión SMART: «Reducir de 14 a 8 horas el tiempo medio de resolución de incidencias de las pymes con contrato en un plazo de seis meses».

2. ¿Qué diferencia hay entre «el sistema hace copias diarias» y «la restauración tarda menos de 2 horas»?

   Respuesta

   El primero es un requisito funcional (qué hace); el segundo es no funcional (cómo de bien lo hace).

3. De 10 requisitos, 7 son Must. ¿Qué problema hay y qué harías?

   Respuesta

   El 70 % supera el 60 % de la regla de la unidad: si casi todo es imprescindible, no hay prioridad real. Habría que revisar cuáles lo son de verdad y pasar el resto a Should o Could.

4. Una parte interesada tiene mucho poder y poco interés en el proyecto. ¿Cómo la tratas?

   Respuesta

   Hay que mantenerla satisfecha: sin dedicarle demasiado esfuerzo, pero cuidando que el proyecto no vaya contra sus condiciones o intereses.

5. La EDT de un proyecto suma 70 horas, pero el presupuesto prevé 55 horas de personas. ¿Qué indica?

   Respuesta

   Que algo no cuadra: o la EDT sobreestima el trabajo, o el presupuesto lo infravalora. Hay que revisar ambos hasta que coincidan.

Glosario

Término	Definición
Objetivo SMART	Objetivo específico, medible, alcanzable, relevante y con plazo
Alcance	Frontera del proyecto: qué incluye y qué no
Supuesto	Condición que se da por cierta al planificar
Restricción	Límite impuesto al proyecto (plazo, presupuesto, tecnología…)
Requisito funcional	Lo que debe hacer el sistema o el servicio
Requisito no funcional	Cómo de bien, de rápido o de seguro debe hacerlo
Criterio de aceptación	Prueba que decide si un requisito o un entregable está cumplido
MoSCoW	Priorización en Must, Should, Could y Won’t
Parte interesada (stakeholder)	Persona o entidad que afecta al proyecto o se ve afectada por él
EDT (WBS)	Descomposición jerárquica del proyecto en entregables y paquetes de trabajo
Paquete de trabajo	Unidad mínima de la EDT: tarea con entregable y horas estimadas