Pensamiento computacional
Resolver un problema con una computadora no empieza escribiendo código: empieza pensando el problema de una forma que la computadora pueda ejecutar. Eso se llama pensamiento computacional, y se apoya en cuatro operaciones que se usan todo el tiempo, incluso sin programar.
| Operación | En qué consiste | Ejemplo |
|---|---|---|
| Descomposición | Partir un problema grande en problemas más chicos que se puedan resolver por separado. | "Hacer un sistema de inventario" se parte en: cargar herramientas, registrar retiros, consultar qué hay. |
| Reconocimiento de patrones | Detectar qué situaciones se parecen entre sí, para resolverlas una sola vez. | Registrar un retiro y registrar una devolución son casi la misma operación con el signo cambiado. |
| Abstracción | Quedarse con lo importante y descartar el detalle que no afecta la solución. | Para el inventario no importa el color de la herramienta, sí en cambio su código y su ubicación. |
| Algoritmo | Escribir los pasos de la solución de forma ordenada, precisa y finita. | El procedimiento de retiro: leer el código, verificar que esté disponible, registrar quién lo lleva. |
Las etapas del método
El método de resolución de problemas más difundido es el que publicó el matemático George Polya en 1945, pensando en problemas de matemática. Funciona igual de bien para cualquier problema, y tiene cuatro etapas.
El error de saltear la primera etapa
En la práctica, las etapas que se saltean son siempre las mismas: la 1 y la 2. La tentación es pasar directo a ejecutar, porque es la parte que se ve y la que da la sensación de estar avanzando.
El resultado es predecible: se construye algo durante semanas y al final se descubre que no era lo que hacía falta. Las etapas de pensar son las más baratas —cuestan tiempo, no materiales— y son las que más ahorran. Cambiar de idea antes de construir algo sale casi gratis; cambiarla después de construirlo, no.
Entender el problema
Entender no es leer el enunciado: es poder explicarlo con tus propias palabras y saber qué se pide exactamente. Mientras eso no pase, cualquier cosa que se construya es una apuesta.
Qué hay que averiguar
- Cuál es el problema real, más allá de cómo lo contó quien lo trajo. Casi siempre hay que preguntar dos veces para llegar.
- Qué datos hay disponibles. ¿Existe un listado de las herramientas? ¿De qué años? ¿En qué formato?
- Qué resultado se espera, expresado de forma que se pueda comprobar.
- Qué restricciones existen. Tiempo, presupuesto, materiales, personas, normas de la institución.
- Qué es lo que no se sabe. Las dudas se preguntan al principio, no se resuelven inventando.
La prueba de que se entendió
Una sola: se puede explicar el problema en dos o tres frases, sin mencionar ninguna tecnología, y la otra persona está de acuerdo con esa descripción. Si hace falta un párrafo largo y lleno de "y también", el problema todavía no está delimitado.
Planificar la solución
Planificar es decidir cómo se va a resolver antes de empezar a construir. Es la etapa que más tiempo ahorra y la que más cuesta justificar, porque no produce nada visible.
Los pasos
- Dividir la solución en partes. Cada parte tiene que poder construirse y probarse por separado.
- Definir qué entra y qué sale de cada parte. Es lo que permite que se construyan en cualquier orden y que las haga gente distinta.
- Elegir la herramienta de cada parte, y justificarla. "Usamos una planilla porque el volumen es bajo y ya la conocen" es una decisión; "usamos una planilla" no.
- Escribir el algoritmo. En pseudocódigo o en diagrama de flujo, para poder revisarlo antes de programarlo.
- Decidir cómo se va a probar cada parte, y con qué datos.
- Calcular los tiempos. Un plan sin fechas no es un plan: es una lista de deseos.
Ejecutar y probar
Ejecutar es construir: conseguir los materiales, armar, programar, cargar los datos. Es la etapa más larga en horas de trabajo, y la que menos decisiones nuevas requiere, porque ya se tomaron en el plan.
Construir por partes y probar cada una
Si el plan está bien hecho, cada parte se puede probar sola. Eso es lo que evita el escenario más frustrante de todos: armar todo, y al encender no saber cuál de las diez piezas está fallando.
La regla es simple: nunca se integra una parte sin haberla probado antes.
Cómo se prueban las cosas
Probar no es "abrir y ver si anda". Un buen juego de pruebas incluye:
- El caso normal: la situación habitual. Es el único que casi todos prueban.
- Los casos límite: el valor más grande, el más chico, el cero. Son los que revelan errores.
- Los datos inesperados: un campo vacío, un texto donde va un número, dos veces el mismo registro.
- El caso que no debe funcionar: comprobar que el sistema rechaza lo que tiene que rechazar. Un validador que acepta todo parece funcionar perfecto.
Conviene además anotar qué se probó y qué resultado dio. En un proyecto de varias semanas, nadie recuerda si un caso se probó o no.
Revisar y mejorar
Revisar es comparar lo construido con lo que se había pedido, y hacerse las preguntas incómodas. Es la etapa que decide si el proyecto sirve o si es solo algo que funciona.
Las preguntas de la revisión
- ¿Resuelve el problema? No "¿funciona?", sino si cierra la brecha que se había identificado al principio. Hay que volver al problema formulado y comparar.
- ¿Cumple los requisitos acordados? Uno por uno, incluidos los no funcionales, que son los que se olvidan.
- ¿Lo usa quien tenía que usarlo? Si la respuesta es no, el proyecto no está terminado, por más que funcione.
- ¿Qué mejoraría? Lo que se deja afuera no se pierde: se registra para la próxima versión.
- ¿Qué aprendimos? Lo que salió mal es la información más valiosa del proyecto.
De la revisión sale documentación: cómo se usa el sistema, qué decisiones se tomaron y por qué, qué quedó pendiente. Sin eso, el próximo que lo toque tiene que adivinar todo de nuevo.
Detectar problemas y conflictos
En todo proyecto aparecen obstáculos, y la diferencia entre un proyecto que termina bien y uno que se traba no está en no tenerlos, sino en detectarlos temprano. Un conflicto descubierto en la planificación se resuelve con una conversación; el mismo conflicto descubierto en la entrega final no tiene solución.
Los cuatro tipos
| Tipo | En qué consiste | Ejemplo |
|---|---|---|
| Problema técnico | Algo no funciona, o funciona peor de lo esperado. | El sistema anda en la computadora del aula pero no en el celular de los alumnos. |
| Conflicto de requisitos | Dos cosas que se piden se contradicen entre sí. | "Que el robot sea liviano" y "que la batería dure ocho horas" no se pueden cumplir al mismo tiempo. |
| Conflicto de recursos | No alcanza el tiempo, el dinero o los materiales para lo que se planificó. | Faltan dos semanas y queda la mitad del trabajo. |
| Conflicto de expectativas | Las personas esperan cosas distintas del mismo proyecto. | El docente espera un sistema para enseñar; los alumnos necesitan uno para consultar rápido. |
Las señales que avisan antes
Los conflictos casi nunca aparecen de golpe: avisan. Estas son las señales que hay que aprender a leer:
- Un requisito que nadie sabe cómo verificar. Si no hay forma de comprobarlo, en realidad no es un requisito: es un deseo.
- Una tarea que se posterga dos veces. Casi siempre está postergada porque hay algo sin resolver que no se dijo.
- Respuestas distintas a la misma pregunta. Si dos personas describen el objetivo de forma diferente, hay un conflicto de expectativas esperando.
- Un "sí, pero…" cada vez que se propone algo. El desacuerdo existe y no se está discutiendo.
- Avance que no se puede mostrar. Si al final de una semana no hay nada concreto para ver, el plan tiene un problema.
Qué hacer cuando aparece
- Registrarlo por escrito. Un conflicto que no está anotado no existe hasta que explota, y entonces ya es tarde.
- Decidir si es un conflicto real o una duda. Muchas veces la respuesta está en alguien que no se consultó.
- Priorizar. Cuando dos requisitos se contradicen, hay que elegir. No se puede tener todo, y postergar la decisión es la peor forma de tomarla.
- Volver a la etapa que corresponda. Un problema técnico puede resolverse en la ejecución; un conflicto de requisitos obliga a volver a planificar.
- Dejar constancia de la decisión y de por qué se tomó. Es lo que permite entender después por qué el proyecto quedó así.
Resumen
| Concepto | La idea que hay que recordar |
|---|---|
| Pensamiento computacional | Descomponer, reconocer patrones, abstraer y escribir el algoritmo. |
| Las cuatro etapas | Entender, planificar, ejecutar y revisar. Es un ciclo, no una línea recta. |
| Entender | Se comprueba cuando se puede explicar el problema en dos frases, sin nombrar tecnología. |
| Planificar | El plan está bien cuando otra persona puede ejecutarlo sin preguntar nada. |
| Ejecutar | Se prueba cada parte sola, y nunca se integra algo sin haberlo probado. |
| Revisar | Se vuelve al problema formulado y se compara. Lo que se deja afuera se registra. |
| Los cuatro conflictos | Técnicos, de requisitos, de recursos y de expectativas. |
| Detectarlos temprano | Señales: tareas postergadas, respuestas distintas y avance que no se puede mostrar. |