Aprendizaje orientado a productos

[lupomontero]

A la hora de tener que diseñar mallas curriculares, cursos, sprints o lecciones, normalmente empezamos por mapear todos los conceptos o temas que queremos cubrir, lo cual suele resultar en una estructura rígida categorizada por temas, que son conceptos teóricos. En este punto, se presenta el riesgo de perdernos tratando de solucionar el problema de cómo llevar esa estructura teórica secuencial a una serie de clases, y orientar éstas a la práctica.

Habiendo ya repetido este ejercicio varias veces, en ese punto normalmente nos encontramos con los siguientes problemas:

• cómo podemos hablar de a si todavía no hemos cubierto b?
• cómo hacemos para proponer proyectos por temas, cuando en la vida real todo proyecto incluye un montón de temas en paralelo?
• cómo evitamos dictar teoría por temas y dejar que las alumnas aprendan la teoría a través de la práctica?
• cómo hacemos para incluir buenas prácticas, metodología, flujo de trabajo
• deberíamos o no enseñar herramientas, y qué herramientas enseñar cuándo

Después de darle muchas vueltas creo que la solución no está en encontrar la forma de llevar un mapa conceptual teórico a la práctica si no al revés. Lo que necesitamos mapear no es una serie de temas, si no una serie de productos, que hilados uno detrás de otro permitan ir descubriendo la teoría de forma gradual, con temas en paralelo, e incluyendo metodología y herramientas, desde el principio.

No podemos esperar que alguien aprenda a programar tema a tema, por lo tanto, no debemos diseñar la enseñanza tema a tema.

Creo que debemos re-enfocar el proceso de aprendizaje de la siguiente manera:

• Todo curso debe de estar planteado en base a un producto (o entregable, no un proyecto).
• La complejidad y scope de los proyectos va aumentando gradualmente: continuous enhancement
• La teoría se va descubriendo a través de la práctica y reforzando a través de material self-paced, ayudantías y charlas concretas (de expertos y/o profesores) de duración limitada
• Todo proyecto debe incluir metodologías de trabajo que gradualmente nos llevan a funcionar nativamente en un entorno de "trabajo en equipo", "pair-programming", "forks", "branches", "pull request", "issues", "milestones"
• Debemos incluir como parte del proceso el tener que proponer ideas, desarrollar ideas en grupo y finalmente presentarlas (la comunicación es esencial)
• ... se me ocurren muchas cosas más

Todo esto para proponer que nos enfoquemos en imaginar una ruta de productos empezando por los "proyectos" de Introducción a la programación en JS, de ahí un site estático simple (pero completo), después un SPA, de ahí se le añade servidor, y así sucesivamente...

Creo que este tipo de enfoque reforzaría y complementaría el agile classroom, así como el self-paced y blended learning del que venimos hablando.

Food for thoughts

cc/ @chamodev @ivandevp

[chamodev]

100% aligned. Product-based learning es el camino!

[giancorzo]

@lupomontero me pidio que comente este issue.

Estoy de acuerdo que la mejor forma de aprender es hacer constantemente proyectos, pero croe que hay que estar atento a las siguientes variables.

1. Aprender teoría basado en la práctica hace a veces que aprendamos sólo lo justo para poder resolver el problema (me pasa constantemente) lo que genera que haya lagunas mentales cuando hablas con ellas... por ejemplo empiricamente saben poner funciones como variables pero no entienden el concepto y no saben en que casos aplicarlos...entocnes hay que tener cuidado desarrollar una forma de vincular el proyecto con los temas profundos que uno puede descubrir con él (forzando muchas veces a tener que investigar y documentar y profundizar en el tópico y no simplemente resolver el problema).

2. Los equipos son buenisimos pero tambien sirve para encubrir a las personas que se aprovechan de lo que otros investigan (hay que separar cosas comunes de cosas que uno mismo debe hacer) por ejemplo cuando hacemos trabajo grupal todas salen relativamente bien pero cuando pasas a hacer un examen por persona ahi empiezas a ver las fallas... creo que este tema podria estar atado al punto 1.

3. Un proyecto realmente útil sería uno que no tuviera restricción de tiempo pero si entregables porque a veces tener que entregar algo te hace tomar atajos, no investigar sino aplicar lo primero que encuentras etc etc.

4. Un Proyecto sin un lider técnico es como un barco sin motor, lo vemos seguido en los proyectos de la empresa...si el equipo no domina la tecnología el proyecto no avanza en ninguna dirección porque nadie sabe a donde ir (te la pasas leyendo y leyendo y muchas veces haces algo y luego lo tiras a la basura porque asi no era y vuelves a empezar...cosa que las chicas no podrían hacer si los proyectos tienen un constraint de tiempo). Sin embargo un proyecto con lider técnico que sepa que hacer y asigne tareas es un proyecto que se mueve hacia una dirección y por lo genera a buen puerto. Permitiendo que los otros miembros del equipo vayan aprendiendo poco a poco del lider técnico (claro que esta que él lider debe ser capaz de asignar tareas y responsabilidades adecuadamente). Para mi el lider técnico debería ser un mentor de laboratoria (Jedi - Padawans)

5. Seria interesante probar, proyectos personales / proyectos grupales / proyectos intersede / proyectos inter squads (varios squads de varios paises resuelven 1 solo problema sobre todo cuando hay experiencia... en la universidad pasabamos 6 meses haciendo un ERP entre 30 personas, era 6 squads de 5 personas cada una hacia un módulo del ERP, además nos auto organizamos habian un chapter de 6 lideres de squad del cual salia un lider de proyecto, habian 6 lideres tecnicos del cual salia un arquitecto habian developers que eran el resto y tambien documentadores etc etc)

Les dejo este TED talk buenisimo donde Cesar Harada enseña a chicos mediante proyectos
https://www.ted.com/talks/cesar_harada_how_i_teach_kids_to_love_science
https://www.youtube.com/watch?v=2TqxnoWWoRw

[lupomontero]

Gracias por el feedback @giancorzo ;-)

De tu comentario extraigo y suscribo lo siguiente:

1. Debemos incentivar auto-aprendizaje y auto-gestión
2. Tenemos que evaluar por separado el trabajo grupal e individual
3. El scope y complejidad de los productos y proyectos va a ser lo más delicado a la hora de diseñar la malla
4. Los profes y TAs deben adoptar un rol de líderes técnicos y mentores de los squads
5. Me parece un planteamiento interesante para el bootcamp. De hecho la propuesta actual está pensada como un producto que va evolucionando de static site a SPA, de ahí data driven, ...

[chamodev]

Team,

Un claro next step de esta conversación es documentar nuestros principios de aprendizaje en algún manifesto, o simplemente actualizando el blog del agile classroom. Yo puedo coordinar este esfuerzo, una vez que tengamos la contra-propuesta de @ivandevp sobre la malla del bootcamp (issue #5).

Mientras tanto, aquí voy a listar otros principios interesantes que debemos discutir para que no olvidarlos y para tenerlos presentes a la hora de (re)definir nuestra metodología:

1. Me gustaría que pensemos en la malla como un mapa i.e. una serie de nodos representando conocimiento, interconectados entre sí; en lugar de un path lineal y único, de un tema después de otro
2. Expandiendo el punto de auto-gestión, sería increíble poder brindar una especie de customized study plans para cada alumna, de acuerdo a la cantidad de horas que la alumna tiene disponible a la semana, su interés, etc.
3. Recordar la necesidad de tener el material on-the-go (app + descargable) que salió en el design sprint
4. De la conversación con Mariano: contextualize learning i.e. los problemas a resolver deben ser relevantes a las alumnas + tener una base de Q&As (en español) que sirva como punto de partida para fomentar el auto-aprendizaje
5. Personalized / adaptive / differential - learning
6. En cuanto a data analytics, la meta es tener real-time prediction of proficiency levels
7. Data privacy es un crucial

Iremos construyendo la comunicación a medida que vayamos madurando estas ideas y aterrizándolas. Por ahora se las dejo como food for thought.

Abrazo,
R

updated para incluir punto adicional

[lupomontero]

@chamodev: puedes añadir un nuevo heading al README.md, antes de la malla curricular, con un resumen del modelo de aprendizaje o enfoque (hasta dónde hemos llegado)?

@coloradomarin @ivandevp @CaroLaboratoria @lalogf @jpcode @rodrwan @indie-rok @merunga: comentarios sobre este issue?

[rodrwan]

En lo personal, y viniendo de una escuela mucho más científica como lo es la Universidad, considero que el aprender orientado a productos es super útil, sobre todo cuando la teoría es un poco más densa de lo normal. En la Universidad, en general se pasa mucha teoría y se aplica a la practica en las ayudantias y tareas. Estas tareas y proyectos dependen de la asignatura y de las unidades que se vean. Recuerdo que lo ramos más divertidos y útiles, sus actividades eran proyectos, proyectos grandes, en lo que se aplicaban conceptos del curso, e incluso algunos otros que no tenían nada que ver con la asignatura en sí, pero que permitían ir más allá de la materia de dicha clase. Ahora, no dejaría de lado lo teórico, por ningún motivo, ya que, en general, un proyecto no abarca todos los aspectos ni conocimientos sobre las materias bases de la informática.

Ahora bien, hacer un programa orientado al desarrollo va más de la mano, a mi parecer, con lo que necesita el mercado. Incluso trabajar sobre problemas reales, de empresas reales, también es una motivación extra para aprender cosas nuevas.

En cuanto a trabajar en grupos, es genial, se comparten ideas y todo ese tipo de cosas que uno habitualmente vive en un equipo de trabajo de profesionales, el único punto, es que cuando se está aprendiendo por lo general el "más" fuerte hace las cosas más difíciles, dejando a los más débiles en conocimiento de lado. Eso se podría trabajar, dividiendo las actividades, asignando responsabilidades y cómo sabemos si en una de esas encontramos a una lider innata.

A mi parecer, proponer proyectos con desafiaos concretos que permitan dar una pincelada a los conceptos más teóricos e incluso reforzarlos parece una buena alternativa, tomando en cuenta cuales son los tópicos que quisiéramos enseñar.

Por otro lado creo que las chicas aprenden mejor la teoría cuando la aplican y expresan los resultados de forma visual, les da sentido y no es sólo algo más que van aprender pero que quizás nunca van a utilizar. Esto pasa mucho en el mundo universitario, muchos de los romas jamás se utilizan pero sirven para formar mentes.

En resumen:

• Proyectos con alcance definido.
• Proyectos por partes (abarcando cada porción de contenido).
• Desafios.
• Trabajo distribuido.
• Trabajo guiado.
• Delegar.

Saludos.

[chamodev]

Otro comentario para la conversa:

Es importante aterrizar la "filosofía" educativa de Laboratoria en "comportamientos operativos" que se puedan poner el práctica dentro y fuera del aula. Por ejemplo, un comportamiento que hace realidad nuestra filosofía del auto-aprendizaje podría ser: las alumnas deben preguntar en el slack abierto y no 1:1 a los instructores. Si eso sucede, el instructor debe copiar y pegar la pregunta en el foro abierto.

Food for thought...

[lupomontero]

Una referencia que me parece super interesante, tanto a nivel de modelo de aprendizaje como a nivel de software:

https://www.altschool.com/lab-schools/approach

[chamodev]

Más comentarios...

1. Sobre el poder de las HSE: hoy un empleador de EEUU nos brindó feedback positivo de una egresada, haciendo énfasis en nuestro foco por las HSE. En específico, mencionó que la coder tiene:

la capacidad de anticipar dificultades y comunicarlas, planear bien para deadlines, y explicar su proceso de trabajo a los demás del equipo

2. Sobre trabajo en equipo: en EC un learning importante es que trabajo grupal debe ser durante el tiempo presencial. Coordinar fuera del aula es complicado
3. Office Hours para consulta son un gran recurso --- presencial vs online?

[CaroLaboratoria]

Dejo algunos pensamientos e ideas que pueden aportar:

1. Efectivamente desde Educación Continua hemos estado mirando bastante de cerca el trabajo en equipo: Si bien seguimos con la hipótesis que es de suma relevancia el fomentarlo, creemos que como dijo @chamodev las mismas alumnas nos sugirieron que fuera dentro del horario presencial de clases. Sumado a lo anterior, la evaluación del contenido aprendido, la queremos pilotear individual (para los cursos de EC que estamos por empezar), así evitamos que algunas chicas "escondan" su nivel real en el equipo.
2. Otro tema importante a definir es el de cómo vamos a responder las preguntas. Intentamos evitar las preguntas 1 a 1 en EC durante este tiempo pero no fue posible. Creo que deberíamos de trabajar en algún mecanismo de consultas claras y abierto a todos los participantes de ese curso.
3. Queremos trabajar en una metodología dentro de la sala de clases que nos identifique como Laboratoria. Que la experiencia que viva la coder dentro de nuestro espacio sea único y asegure un ambiente de colaboración y aprendizaje óptimo.
4. Sobre HSE es un tema importantisimo que el Bootcamp NO puede dejar de incluir. En EC? Estamos haciendo talleres anexos, pero me cuesta visualizar el trabajo dentro de la sala de clases al respecto.

[jpcode]

@lupomontero
Algunos comentarios:

• Un enfoque orientado a producto es bueno, pero hay que tener algunas consideraciones en cuenta:
  Cual es la diferencia actual, las chicas que trabajan se orientan al desarrollo de un producto ( su trabajo ), la experiencia nos dice que tienen un deficit conceptual notorio. Ensenhar la teoria con la practica "gradualmente", si no queda claro como se va hacer step by step, va ser algo que no podriamos medir adecuadamente. ( Generacion de contenido y metricas claras para solucionar esto )

• Coincido que explicar tema a tema podria ocasionar deficit, pero algo que no se menciona que cambiaria con sentido al uso de herramientas?, las clases deben ser mas dinamicas, contenidos mas amigables, videos cortos, lecturas de rapida lectura, la generacion de contenido es demasiado importante, asi como la creacion de herramientas, ejercicios guiados, practicos, capstones, cada cosa debe ser pensado al milimetro. El terminar el proyecto no dice que todas trabajaron igual, pero eso se podria volver insignificante si todo lo demas esta impecable.

• Considero que el primer 44 es muy importante: Js Deep Dive, al menos es el unico que veo como dependencia de todos los demas. Podriamos trabajar de atras a adelante, mejorando el Js Deep Dive. Asu vez veo necesario agregar cursos 44 como : Algorithms basic, Debug & performance, Interview Practice. Por otro lado, seria bueno intentar periodicamente hackaton mindset.

• Finalmente, ya que esto es un gran cambio, considero que debe ser testeable. Se podria para los siguientes cursos que se vienen y que inician en Junio, probar un profesor ( X ) que incluso podria ser un TA, para ver que tan buenos son los materiales y enfocar el esfuerzo en mejorar y crear? Seria interesante analizar, generar encuestas, ver metricas, hacer cambios rapidos. Mientras se pueden ir armando los demas cursos, considero que el disenho es importante y el profesor debe tener la capacidad de que con el material adecuado y su metodologia dar buenos resultados.

**Tildes omitidas

[merunga]

relacionado a este tema pero tb atado a cuestiones transversales, justo un amigo hacker me pasó este video que creo q aporta un caso de exito al enfoque. Es recontra-hacker, aviso

Para los q les da flojera ver el video, es sobre universidad 42, una academia de desarrolladores que:

• No tiene curriculas, ni titulos, ni profesores, ni prerrequisitos (solo completar unos ejercicios).
• Aprendizaje 100% peer-to-peer y basado en productos.
• Dura entre 3 y 5 anios, y puedes comenzar a estudiar inclusive sin haber terminado el bachiller.

que dicen los hackers, a quien no le hubiera gustado aprender asi? por que?

Y para sumar como idea extraida del video, q se puede usar en otros enfoques: proyectos que proponen las empresas y por los cuales los alumnos cobran si los completan

[indie-rok]

Hola.

En lo personal no entiendo el propósito.

Existen muchísimos cursos en linea (Incluso orientados a proyectos). Qué hacen exactamente eso. Hacer que alguien aprenda a programar.

Si no voy a tener profes, y todo lo voy a aprender yo por mi cuenta; ¿Cuál es el propósito de ir a la escuela en si?

¿Hacer contactos, conexiones? Probablemente. Pero en ese caso una universidad (incluse pública sería mucho mejor)

[MariPlaza]

@merunga Gracias por compartirlo. A mi me parece un concepto full interesante, aunque si existen los "profes", sólo que de una manera diferente porque son todos y cada uno de los compañeros de clase con los que a la vez estás haciendo networking. Lo que cambia es un poco el concepto de jerarquías, porque no tienes la "autoridad" sino la colaboración para aprender conjuntamente.

@indie-rok Te cuento mi experiencia y porque me parece interesante, en lo particular yo he aprendido de la parte de desarrollo para aplicar a la Ciencia de Datos con cursos en línea orientado a proyectos, y en efecto aprendí a desarrollar y he hecho cosas interesantes, pero me hacía falta la parte de peer to peer y el poder aprender con otras personas, por eso comencé a participar en MeetUps en la ciudad donde vivo y a buscar participar remoto con proyectos como Laboratoria.

Las universidades obviamente siguen siendo una excelente opción, pero creo que este tipo de mecanismos te pueden ayudar a identificar con quien también te sientes cómodo co-creando y quien pudiera ser un futuro socio de negocios.

Prometo pasar mi feedback más concreto de lo que he leído pero necesito tener un poco más de contexto sobre quien es el publico en el que quieren posicionar esta oferta de cursos. Los temas me parecen los correctos, quizas lo agruparía de otra manera pero como no tengo claro la audiencia, aún no se si mi feedback es realmente relevante.

Mañana converso con @chamodev y después que tenga claro el contexto comparto mi feedback en caso de que lo sea. Felicidades por los avances y me gusta poder aportar en proyectos como Laboratoria.

[lupomontero]

@merunga: el concepto de Universidad 42 me parece alucinante. Muy interesante. Me gusta mucho el concepto de que todos son profes, creo que hay mucho que podemos aprender on respecto a este punto. Quizás lo combinaría con mentores o un "help desk", pero el enfoque "self-paced" is "self-guided" me parece genial.