En desarrollo de software hay un concepto que todo equipo conoce: la deuda técnica. Es lo que se acumula cuando resolvés rápido en vez de resolver bien. No se ve el día que la contraés. Se ve dos años después, cuando cualquier cambio simple se vuelve caro.
Las escuelas están contrayendo una deuda equivalente con la educación tecnológica, y casi nadie la está contabilizando.
Cómo se contrae
Una institución decide que necesita "tener robótica". La decisión es correcta y viene de buenas intenciones.
Lo que sigue casi siempre es esto: se compra un lote de kits cerrados, se capacita a un docente en un curso de fin de semana, se arma un espacio con buena luz para las fotos, y se agrega la materia a la grilla.
El primer año funciona. Los chicos arman modelos, los padres ven fotos, la escuela tiene algo nuevo que mostrar en la muestra anual.
El segundo año se repiten los mismos modelos, porque el kit tiene un número finito de proyectos y el docente no tiene formación para salir de ellos.
El tercer año los chicos que estuvieron desde el principio están aburridos, y los que se suman nuevos hacen exactamente lo que hicieron los anteriores.
Ahí es cuando la deuda se hace visible. Y para entonces ya está pagada la inversión, ya está en el currículum, ya está comunicada a las familias.
Los intereses de esta deuda
Primero: el techo. Un kit cerrado tiene un límite estructural. Cuando un alumno lo alcanza —y lo alcanza más rápido de lo que uno espera— no hay progresión posible sin cambiar de sistema. La inversión no escala; se reemplaza.
Segundo: la falsa señal. Un alumno que armó veinte modelos siguiendo instrucciones cree que sabe robótica. La escuela también lo cree. Los dos descubren lo contrario cuando el chico enfrenta un problema abierto y no tiene por dónde empezar. Esa brecha entre lo que se cree que se aprendió y lo que efectivamente se aprendió es el interés más caro de todos.
Tercero: el docente sin salida. Un profesor capacitado en un kit específico queda atado a ese kit. No puede improvisar, no puede responder una pregunta que salga del manual, y no puede acompañar a un alumno que quiere ir más lejos. No es un problema del docente: es un problema de cómo se diseñó su formación.
Cuarto: el costo de refinanciar. Cambiar de enfoque en el año cuatro es mucho más caro que haber empezado distinto. Hay equipamiento comprado, docentes formados, expectativas comunicadas y una narrativa institucional que sostener.
La alternativa no es más cara. Es distinta.
Este es el punto que más cuesta transmitir en una reunión con una dirección: trabajar con hardware abierto no cuesta más.
Un microcontrolador cuesta una fracción de lo que cuesta un kit cerrado por alumno. Los sensores y actuadores se compran sueltos, se reponen individualmente y no dependen de un proveedor único. Un componente quemado se reemplaza por unos pesos, no invalida el set completo.
Lo que sí es distinto es la exigencia sobre el docente. Con un kit cerrado, el docente sigue un manual. Con componentes abiertos, el docente tiene que entender el sistema.
Esa es la inversión real, y es la única que no se deprecia. Un docente que entiende cómo funciona un circuito y cómo se depura un sistema puede enseñar con cualquier equipamiento, este año y dentro de diez.
Qué preguntar antes de firmar
Si estás del lado de una institución evaluando un programa de tecnología, hay tres preguntas que ordenan la decisión mejor que cualquier presentación:
¿Qué va a poder hacer un alumno en el año tres que no puede hacer en el año uno? Si la respuesta es "modelos más complejos", es un catálogo. Si es "resolver un problema que no le planteamos nosotros", es un programa.
¿Qué pasa cuando un alumno quiere hacer algo que no está previsto? La respuesta a esa pregunta revela si el sistema tiene techo o no.
¿Qué queda si el proveedor desaparece? Con hardware abierto, queda todo: los componentes son estándar, el conocimiento es transferible y el docente formado sirve igual. Con un sistema propietario, queda un lote de plástico.
No es un problema de presupuesto
Hay escuelas con presupuestos modestos que forman alumnos capaces de diseñar sistemas propios, y escuelas con laboratorios costosos donde los chicos repiten secuencias.
La diferencia no está en el equipamiento. Está en si la propuesta fue diseñada para que el alumno progrese o para que la institución tenga algo que mostrar.
En Robot Academy Argentina trabajamos con instituciones educativas sobre esa base: hardware real, progresión declarada año por año, y formación docente que no queda atada a un producto.
La deuda técnica en software se paga con horas de refactor. Esta se paga con la promoción de chicos que creyeron que sabían algo. Es más cara y es más difícil de ver.
Leonardo Torres
Director Robot Academy Argentina
www.robotacademy.org
Top comments (0)