Tema 1. El proyecto tecnológico: investigación, ideación y gestión

1. Qué es un proyecto de investigación y desarrollo

En el lenguaje corriente, «investigar» significa buscar información y «desarrollar» significa construir algo. En ingeniería, las tres letras de I+D+i designan actividades distintas, con objetivos distintos y con resultados que se miden de forma distinta. Conviene separarlas desde el principio, porque de ello depende qué se considera un éxito del proyecto.

Las fases y lo que produce cada una

Un proyecto de ingeniería no es una sucesión de tareas sueltas: cada fase termina con un entregable que la siguiente necesita. Si una fase no produce nada revisable, es imposible saber si se ha terminado.

2. Investigar: buscar, seleccionar e interpretar

El criterio de evaluación 1.1 pide investigar y diseñar proyectos «seleccionando, referenciando e interpretando información relacionada». Son tres verbos distintos y los tres se evalúan. Buscar es fácil; seleccionar exige criterio; interpretar exige entender qué dice el dato y qué no dice.

Dónde se busca información técnica

Seleccionar: cuatro preguntas antes de dar por buena una fuente

• ¿Quién lo firma? Una persona u organización identificable, con competencia en el asunto y responsabilidad sobre lo que publica.
• ¿Cuándo se publicó? En tecnología, cinco años pueden dejar obsoleto un componente, un protocolo o un precio.
• ¿Con qué intención? Informar, enseñar, normalizar o vender. Un catálogo comercial es una fuente legítima para conocer especificaciones y precios, y una fuente sesgada para comparar alternativas.
• ¿Se puede contrastar? Si dos fuentes independientes coinciden, la confianza aumenta. Si una cifra solo aparece copiada de sitio en sitio sin origen, es una cifra huérfana.

Interpretar: el dato, su unidad y su límite

Interpretar es responder a «¿qué puedo afirmar con esto?». Tres errores aparecen sin falta en los primeros proyectos:

3. Referenciar y no plagiar

Referenciar es indicar de dónde procede cada afirmación que no es tuya, de modo que otra persona pueda ir a comprobarla. No es un trámite burocrático: es lo que convierte una opinión en un argumento y lo que permite que un tercero repita tu trabajo. En ingeniería tiene además un efecto práctico inmediato: cuando el prototipo no funciona, las referencias son el mapa que te dice dónde volver a mirar.

Qué debe llevar una referencia

Existen estilos normalizados para ordenar esos elementos —la norma ISO 690 y su versión española UNE-ISO 690 son las más usadas en documentación técnica—. Para este curso basta con una regla: elige un estilo, sé coherente en todo el documento y no omitas nunca la fecha de consulta de un recurso en línea.

4. Ideación y Design Thinking

Con la necesidad comprendida y los datos en la mano hay que producir alternativas. La trampa habitual es llegar a esta fase con una sola idea —la primera que apareció— y dedicar el resto del proyecto a justificarla. El Design Thinking reúne un conjunto de modos de trabajo centrados en las personas que usarán la solución: comprender, definir, idear, prototipar y probar, empleados con flexibilidad y no como una receta en fila.^[3]

Abrir y cerrar: divergencia y convergencia

El modelo del doble diamante del Design Council describe dos movimientos consecutivos de apertura y cierre: primero se explora el problema y se concreta su definición; después se exploran muchas respuestas y se concreta una.^[4] Las dos mitades necesitan maneras de pensar opuestas, y mezclarlas es la causa más común de que una sesión de ideas no produzca nada.

Cinco técnicas de ideación que funcionan en clase

• Brainwriting: cada persona escribe o dibuja sus propuestas en silencio antes de compartirlas. Evita que la sesión la dominen las dos voces más rápidas.
• Ideación por funciones: descomponer el sistema en funciones —medir, decidir, abrir el paso del agua, avisar, alimentarse de energía— y generar alternativas para cada una por separado. Después se combinan.
• Matriz morfológica: una tabla con una función por fila y sus alternativas por columna. Cada recorrido por la tabla es una solución candidata distinta, y aparecen combinaciones que nadie habría propuesto entera.
• Analogía: preguntar cómo resuelve un problema parecido un gotero de hospital, una cisterna de inodoro o una cafetera. Las soluciones maduras de otro campo son ideas gratis.
• Hipótesis extrema: «¿y si no hubiera electricidad?», «¿y si nadie pudiera venir en tres semanas?». No se fabrica el extremo: se extrae el principio que aparece al pensarlo.

Cerrar: elegir con una matriz de decisión

Para converger, se puntúa cada alternativa frente a los criterios que importan y se pondera cada criterio según su peso. El resultado no decide por ti, pero obliga a que la decisión sea explicable.

5. Planificar: identificar tareas, secuenciarlas y dibujarlas

Planificar es convertir una intención en un compromiso comprobable. El currículo lo concreta en tres pasos: identificación de tareas, secuenciación y diagramas de Gantt con seguimiento. Se hacen en ese orden, y saltarse el primero es la causa habitual de que un proyecto escolar se entregue a medias.

Identificar: descomponer hasta poder estimar

Una tarea está bien definida cuando tiene un responsable, un entregable y una duración estimable. «Hacer el circuito» no cumple ninguna de las tres. «Montar y medir el divisor de tensión del sensor en placa de pruebas, con acta de medidas» cumple las tres. La regla práctica: si no eres capaz de estimar cuánto durará, la tarea todavía es demasiado grande.

Secuenciar: qué depende de qué

Dibujar: el diagrama de Gantt

Un diagrama de Gantt coloca las tareas en filas y el tiempo en columnas, de modo que la longitud de cada barra es su duración y su posición, su fecha. Añadiendo las dependencias se ve de un golpe de vista qué tareas pueden retrasarse sin daño y qué tareas arrastran a todo el proyecto.

6. Metodologías ágiles

El Gantt supone que se puede definir todo al principio y ejecutarlo después. Eso funciona cuando se sabe lo que hay que hacer —construir un muro— y falla cuando hay incertidumbre técnica, que es la situación normal en I+D. Las metodologías ágiles nacieron para eso: en lugar de una entrega al final, muchas entregas pequeñas, cada una probada con quien va a usarla.

El texto que dio nombre al movimiento, el Manifiesto por el desarrollo ágil de software, se resume en cuatro preferencias: las personas y su interacción sobre los procesos; el producto que funciona sobre la documentación exhaustiva; la colaboración con el cliente sobre la negociación del contrato; y la respuesta al cambio sobre el seguimiento de un plan.^[5] Obsérvese que dice «sobre», no «en lugar de»: la documentación y el plan siguen siendo necesarios.

Cómo se organiza una iteración

Los marcos ágiles más extendidos, como Scrum, formalizan estos elementos con roles y reuniones definidas.^[6] En un proyecto de aula basta con conservar lo esencial: una pila ordenada, iteraciones con fecha, un tablero visible y una retrospectiva honesta.

Priorizar: qué entra en la primera versión

Si todo es importante, nada se termina. Una técnica sencilla de priorización clasifica cada requisito en cuatro grupos —imprescindible, importante, deseable y descartado por ahora—, con la condición de que el primer grupo no supere la mitad del esfuerzo disponible.

7. El equipo: roles, escucha y acuerdos

El criterio 1.3 no evalúa la simpatía del grupo: evalúa colaborar «escuchando el razonamiento de los demás, aportando al equipo a través del rol asignado y fomentando el bienestar grupal y las relaciones saludables e inclusivas». Son tres conductas observables, y las tres se aprenden.

Escuchar el razonamiento, no solo la conclusión

En una discusión técnica lo que importa no es qué defiende cada cual, sino por qué. Dos hábitos cambian por completo la calidad de las decisiones de un equipo:

• Reformular antes de responder: «entiendo que prefieres la sonda capacitiva porque la resistiva se corroe, ¿es eso?». Si la reformulación es correcta, la discusión avanza; si no, acabas de evitar media hora de malentendido.
• Separar la idea de quien la propone: se descartan propuestas, no personas. Y quien propone una alternativa no está atacando a nadie: está haciendo su trabajo.

Estereotipos: quién se cree capaz de esto

El currículo de esta materia pide expresamente «fomentar la ruptura de estereotipos e ideas preconcebidas sobre las materias tecnológicas asociadas a cuestiones individuales, como por ejemplo la aptitud para las materias tecnológicas».^[9] No es una frase decorativa: describe un problema medible que empieza mucho antes de esta clase y que se manifiesta, dentro del equipo, en el reparto de tareas.

La idea preconcebida más dañina no es «esto es de chicos»; es «hay gente que vale para esto y gente que no». Es falsa: montar un circuito, acotar una pieza o depurar un programa son destrezas que se aprenden con horas, no aptitudes con las que se nace. Pero se comporta como una profecía: quien cree no valer no pide el taladro, no coge el teclado y termina encargándose de «la parte de escribir». Al final de curso habrá aprendido menos, y tendrá la prueba de que no valía.

Acuerdos de equipo: cuatro decisiones que evitan casi todos los conflictos

1. Dónde vive la información. Una única carpeta compartida, con una convención de nombres de archivo y de versiones acordada el primer día.
2. Cómo se decide. Por consenso razonado y, si no lo hay en quince minutos, con el criterio del rol responsable de ese asunto, dejándolo anotado.
3. Cuándo se responde. Un compromiso realista de respuesta fuera de clase, para que nadie quede bloqueado un fin de semana entero.
4. Qué se hace si alguien no entrega. Se habla en la siguiente reunión, se replanifica y se avisa al profesorado si se repite. Ni se tapa ni se reparte el trabajo en silencio.

8. Iniciativa, perseverancia y el error como información

El currículo incluye entre los contenidos del bloque el emprendimiento, la perseverancia, la creatividad, la autoconfianza, la iniciativa y «el error y la reevaluación como parte del proceso de aprendizaje y como herramienta para la mejora de los proyectos». No son adornos: son las conductas que distinguen un proyecto que llega a funcionar de uno que se queda a medias.

Reevaluar: el error como dato de proyecto

Un prototipo que falla no es un accidente: es la respuesta a una pregunta que el equipo había planteado sin saberlo. Convertir ese fallo en información exige tratarlo con método, igual que una medida.

Comprueba lo que has aprendido

Este tema no se demuestra recitando las fases de un proyecto, sino mostrando el rastro que deja un equipo que trabaja con método.

Prueba final antes de entregar: dale tu documentación a alguien de otro equipo y pídele que reconstruya el camino. Si no puede explicar por qué elegisteis la sonda capacitiva, la culpa no es suya.

Glosario del tema

Camino crítico

Cadena más larga de tareas dependientes de un proyecto; determina su duración mínima y sus tareas no admiten retraso.

Dependencia

Relación por la que una tarea no puede empezar o terminar hasta que otra alcanza un estado determinado.

Design Thinking

Conjunto flexible de modos de trabajo centrados en las personas para comprender un problema, definirlo, idear, prototipar y probar.

Diagrama de Gantt

Representación del plan de un proyecto con las tareas en filas y el tiempo en columnas, donde la longitud de cada barra es su duración.

Entregable

Resultado concreto y revisable que produce una tarea o una fase.

Especificación

Documento que recoge los requisitos que la solución debe cumplir y cómo se comprobará cada uno.

Estereotipo

Creencia previa y no verificada sobre la aptitud de una persona o grupo, que condiciona lo que se le pide y lo que acaba aprendiendo.

Estado de la técnica

Conjunto de lo ya publicado sobre un problema técnico; se revisa antes de diseñar y antes de conceder una patente.

Hito

Punto del plan, sin duración, en el que se comprueba un avance y se decide continuar o rectificar.

Holgura

Tiempo que una tarea puede retrasarse sin afectar a la fecha de entrega del proyecto.

I+D+i

Investigación, desarrollo e innovación: generar conocimiento nuevo, aplicarlo a una solución y ponerla en uso real.

Iteración

Ciclo corto de trabajo que termina en un resultado utilizable y en lo aprendido que modifica el ciclo siguiente.

Matriz de decisión

Tabla que puntúa cada alternativa frente a criterios ponderados para hacer explícita la elección.

Matriz morfológica

Tabla de funciones y alternativas cuya combinación genera sistemáticamente soluciones candidatas.

Patente

Derecho de explotación exclusiva de una invención durante un tiempo limitado, concedido a cambio de publicar su descripción.

Pila de trabajo

Lista única y ordenada de lo que falta por hacer, expresada en términos de valor para quien usará el sistema.

Plagio

Presentar como propio un texto, imagen, plano, dato o código ajeno, con o sin modificaciones.

Referencia

Conjunto de datos que identifican una fuente y permiten localizarla y comprobarla.

Requisito

Condición que la solución debe cumplir, redactada de modo que pueda comprobarse.

Retrospectiva

Reunión en la que un equipo revisa su forma de trabajar y elige una mejora para la iteración siguiente.

Solución mínima viable

Versión más reducida que ya satisface la necesidad y permite probarla con personas reales.

Trazabilidad

Posibilidad de seguir el rastro que une una característica de la solución con su requisito, su necesidad y su evidencia.

Validación

Comprobación de que la solución responde a la necesidad real.

Verificación

Comprobación de que la solución cumple los requisitos especificados.

Fuentes y recursos fiables

• [1] Eurostat — Glosario: investigación y desarrollo (I+D) (en inglés). Definición estadística basada en el Manual de Frascati de la OCDE.
• [2] Oficina Española de Patentes y Marcas — Invenciones: patentes y modelos de utilidad.
• [3] Stanford d.school — Design Thinking Bootleg (en inglés).
• [4] Design Council — The Double Diamond (en inglés).
• [5] Manifiesto por el desarrollo ágil de software (versión en español).
• [6] Schwaber, K. y Sutherland, J. — The Scrum Guide (en inglés; hay traducción al español en el mismo sitio).
• [7] Comisión Europea — Metodología de gestión de proyectos PM² (en inglés).
• [8] Organización Mundial de la Propiedad Intelectual — Patentes.
• [9] Decreto 64/2022, de 20 de julio (BOCM). Currículo de Tecnología e Ingeniería I, bloque A y competencia específica 1.
• [10] Ministerio de Ciencia, Innovación y Universidades — Datos y cifras del Sistema Universitario Español. Distribución del alumnado por rama de conocimiento y sexo.