Caso real · Fundador
Cómo anticiparte a las observaciones de tu profesor antes de entregar
En resumen
- Entregué un avance de proyecto a la 01:16 de la madrugada: 166 MB, cuatro archivos y un enunciado de 55 páginas con 60 subsecciones obligatorias. Saqué 16.5 de 20.
- No fue por correr. El plazo cerraba a las 10 de la mañana. Es que verificar 60 secciones a mano no se puede, tengas ocho horas o dos.
- Mi profesor dejó cuatro observaciones. Fui a buscarlas: tres estaban en el enunciado y la cuarta era, casi literal, un criterio de la rúbrica. Ninguna era una sorpresa.
- El problema no es que la información falte. Es que vive repartida entre un PDF y una pantalla de Blackboard que casi nadie abre, y nadie cruza las dos a las once de la noche.
Revisándolo a mano, de madrugada
- Un enunciado de 55 páginas con 60 subsecciones obligatorias
- Una rúbrica de 8 criterios que vive en otra pantalla
- Cuatro archivos, cada uno con su nomenclatura exacta
- 166 MB por subir
Entregado 01:16 a. m. · 16.5 de 20
Preguntándole a Campus
¿Mi avance cumple lo que piden el enunciado y la rúbrica de este curso?
Faltan tres cosas: el Anexo A del Student Outcome no tiene una subsección por integrante, los archivos no siguen la nomenclatura upc-pre-202610-… y hay segmentos con menos de 3 entrevistas.
1 pregunta · antes de entregar, no después
Este es un caso mío, con la nota y el feedback reales. No lo cuento porque salió bien: saqué 16.5 de 20 y me interesa la parte que perdí.
Qué pedía en realidad ese avance
El curso era Diseño de Experimentos de Ingeniería de Software, y el entregable era el primer avance del proyecto final. El enunciado tiene 55 páginas. La parte que corresponde a ese avance define 60 subsecciones numeradas, desde 1.1.1 Descripción de la Startup hasta 5.3 Video About-the-Product, repartidas en cinco capítulos.
Además pide cuatro entregables distintos: el informe, la presentación, un reporte de participación por integrante y un archivo comprimido con el material complementario. Cada uno con su propio patrón de nombre, y varios en dos formatos.
La entrega cerraba a las 10:00 de la mañana, porque en ese curso los avances vencen 24 horas después del inicio de la clase. La subí a la 01:16 de la madrugada: 166 MB.
Quiero detenerme aquí, porque es la parte que se malinterpreta. No entregué al filo. Tenía casi nueve horas de margen. El problema no era el tiempo: era que nadie revisa sesenta secciones contra un PDF de 55 páginas al final de un trabajo de meses. No es indisciplina. Es que esa tarea, hecha a mano, no sale bien.
Las cuatro observaciones
Cuando salió la nota, el profesor dejó cuatro comentarios:
- Revisar el Anexo A, la sección del Student Outcome (ABET Student Outcome 4).
- La nomenclatura de los archivos de la entrega.
- Para cada segmento se requieren de 3 a 5 entrevistas.
- La documentación del API, que debe incluir descripción y ejemplo para todos los tipos de request.
Leídas así parecen detalles menores. Son 3.5 puntos.
El experimento
Meses después hice esto: tomé solo el enunciado, sin la corrección y sin el feedback del profesor, y busqué qué podía faltar en una entrega de ese tipo.
Salieron dos de las cuatro de inmediato:
El Anexo A. El enunciado dedica una sección entera a explicar que debe haber una subsección por cada alumno, donde cada uno describa por escrito la relación entre el outcome, sus dimensiones y el trabajo que hizo, con las acciones desglosadas por entrega. Es un requisito con una forma muy específica y aparece al final, en los anexos, que es donde nadie llega.
La nomenclatura. El enunciado define cuatro patrones de nombre distintos, uno para el informe, otro para la presentación, otro para el reporte de participación y otro para el video. Todos con la misma estructura larga, y varios pidiendo dos formatos. Es un requisito de la página 3 que se aplica al terminar, semanas después.
Las otras dos no salieron leyendo el enunciado. Y ahí está lo interesante.
La tercera vive en el enunciado, pero enterrada
«Para cada segmento se requiere de 3 a 5 entrevistas» está escrito, literal, en dos lugares distintos del PDF. No es ambiguo ni interpretable: es un número.
Ese tipo de requisito es el más traicionero, porque no se te olvida por difícil sino por contable. Nadie termina un capítulo de entrevistas y vuelve a contar cuántas hizo por segmento. Y es exactamente el tipo de cosa que una revisión automática detecta sin esfuerzo.
La cuarta no estaba en el enunciado
Estaba en la rúbrica. Y esto es lo que más me sorprendió al reconstruirlo.
El enunciado solo lista la sección 5.2.7 RESTful API documentation, sin decir qué tiene que contener. La rúbrica del curso, que vive dentro de Blackboard y es otra pantalla, sí lo dice: hay un criterio que vale 3 puntos, el 15 % de la nota, y para el puntaje completo pide que la documentación del API incluya descripción y ejemplo para todos los tipos de request del Sprint.
El comentario de mi profesor decía, en esencia, eso mismo: que faltaban la descripción y el ejemplo para todos los tipos de request.
No es una coincidencia de tema. Es el mismo criterio, redactado casi igual, y llevaba publicado todo el ciclo. Mi profesor no estaba aplicando una exigencia personal: estaba leyendo la rúbrica.
El hallazgo real
Las cuatro observaciones estaban escritas antes de que yo entregara. Ninguna era sorpresa, ninguna era interpretación, ninguna dependía del ánimo de quien corrige.
Lo que pasa es que estaban en dos documentos distintos. Tres en un PDF de 55 páginas que descargas al inicio del ciclo. La cuarta en una rúbrica que está a tres clics dentro de Blackboard, en una pantalla que mucha gente no sabe que existe.
Y esa rúbrica, cuando la abres, no es vaga. Son ocho criterios con su peso exacto:
- Product Design (diagramas de arquitectura, clases y base de datos): 15 %
- Prototyping (user flows y wireframes): 12.5 %
- Product Backlog con User Stories: 15 %
- Software Development Configuration: 7.5 %
- RESTful API desplegada y documentada: 15 %
- Testing Suite: 15 %
- Evolution (mejora continua sobre entregas anteriores): 10 %
- Communication (comunicación escrita y estructura pedida): 10 %
Cada criterio con tres niveles descritos en detalle. La columna satisfactoria no es una descripción: es una lista de condiciones que se pueden verificar una por una.
Nadie hace ese cruce a las once de la noche. Y no hace falta que lo haga una persona.
Lo que esto no resuelve
Vale la pena decirlo con claridad, porque es donde este tipo de revisión se sobrevende.
Esto no evalúa si tu trabajo es bueno. Detecta ausencias y desviaciones respecto de criterios escritos. Puedes tener las 60 secciones presentes, los nombres perfectos, las entrevistas contadas, y aun así entregar un análisis flojo. Eso lo juzga tu profesor, y hace bien.
Tampoco adivina criterios que no estén publicados. Si tu profesor pide algo en clase y no está ni en el enunciado ni en la rúbrica, no hay nada que cruzar.
Lo que sí hace es cerrar la brecha barata: los puntos que se pierden por cosas que ya estaban escritas y nadie alcanzó a verificar. En mi caso, esa brecha eran 3.5 puntos sobre 20.
Cómo hacerlo tú, con o sin herramientas
La rutina es la misma aunque la hagas a mano:
- Junta las dos fuentes. El enunciado y la rúbrica. Si solo revisas una, te falta la mitad.
- Convierte el índice en casillas. Cada subsección numerada es una línea. Marca las que existen de verdad, no las que están solo como título.
- Caza los números. Cuántas entrevistas, cuántos endpoints, cuántas horas por tarea. Son verificables y son los que más se incumplen.
- Compara los nombres de archivo uno por uno. Es lo más tonto y lo más caro.
- Lee la columna satisfactoria de cada criterio como una lista de condiciones.
Toma tiempo, y por eso casi nadie lo hace en el momento en que serviría.
Cómo lo hace Campus
Campus conecta tu Aula Virtual con el asistente de IA que ya usas, así que las dos fuentes llegan solas: el enunciado desde el contenido del curso y la rúbrica desde el libro de calificaciones, sin que descargues ni subas archivos a mano. Le pides que revise tu avance contra ambas y te dice qué falta, sección por sección.
La diferencia no es que la revisión sea posible. Siempre lo fue. La diferencia es que ahora ocurre antes de entregar, que es el único momento en que sirve.
Hay dos formas de usarlo, según dónde trabajes: desde tu asistente, con el servidor Blackboard MCP para conectar el Aula Virtual con tu IA; o desde la terminal, con Blackboard CLI para consultar cursos, tareas y notas por comandos.
Preguntas frecuentes
- ¿Esto no es que la IA haga mi trabajo?
- No, porque no escribe el trabajo: lo compara con lo que pidieron. El insumo es tu propio documento ya escrito y dos documentos que el profesor publicó para que los leas. Lo que devuelve es qué falta según esos criterios, que es la misma revisión que harías tú con el enunciado al lado y tiempo de sobra.
- ¿Por qué se pierden puntos en algo tan básico como el nombre de un archivo?
- Porque un enunciado largo puede definir cuatro convenciones de nombre distintas, en una página que leíste semanas antes de entregar. No es desconocimiento: es que verificar decenas de requisitos a mano, al final de un trabajo de meses, no es algo que la gente haga bien.
- ¿Dónde está la rúbrica en Blackboard?
- En el libro de calificaciones, entrando a la actividad y abriendo el enlace que dice que el elemento está calificado con una rúbrica. Es una pantalla distinta de la del enunciado, y por eso mucha gente nunca la abre: cada criterio trae su peso y la descripción del nivel satisfactorio.
- ¿Sirve si la entrega es grupal?
- Sirve más. En un trabajo grupal cada integrante escribe su parte y nadie lee el documento completo contra el enunciado. Además, varios cursos califican de forma individual dentro de una entrega grupal, así que los requisitos que piden evidencia por integrante son justo los que se olvidan.