Cómo medir empíricamente los resultados de cambios en formatos de README y la curricula, de cara a estudiantes

[unjust]

Que podemos hacer para obtener feedback/verificar que los cambios de un README o proyecto son buenos para las estudiantes?

Hay algunos cambios que nos parecen mejor pero seria bueno tener algun data o testeo de usabilidad para verificarlo.

@diegovelezg @mfdebian

[mfdebian]

Una de las primeras cosas que se me ocurre es poder levantar feedback de nuestras usuarias, en ese caso tendríamos que preparar algún tipo de formulario que preguntara cosas con respecto a su experiencia en el proyecto, qué feedback podemos obtener del README, con respecto a la claridad de la información, a la utilidad de esta, etc... y contrastar las respuestas de aquellas que tuvieron la "versión anterior" con las que tuvieron la nueva.

También se me ocurre preguntar a lxs coaches que hayan pasado por cohorts con ambas versiones, a ver si notaron alguna diferencia en primer lugar (las estudiantes de demoran menos en hacer el proyecto? por ejemplo) y en segundo qué feedback podrían entregarnos.

¿Qué opinan?

[unjust]

SI - quiza podemos hacer un formulario tambien para los coaches para hacerlo asinc?

[diegovelezg]

De acuedo con pedir feedback a estudiantes. El problema es que ¿cómo sabes lo que no sabes?. Es decir, ¿qué feedback espero de quien ha viso solamente UNA versión? (la cavern de Platón). Yo opino que habría que pensar alrededor de:

• Una cantidad fija (coparable) de estudiantes que ya ANTES hiieron el rproyecto (antiguedad no mayor a 6 meses).
• Una cantiad fija de coaches que ya ANTES coachearon Y DIERON project feedback.
• Comparar tiempo de paso por el propyecto
• Comparar sprint y project checkout
• Comparar OAs (este es el de menos valor en mi opinión)

[diegovelezg]

Notas de weekly devs:

• Definamos una lista pequeña de indicadores que podemos comenzar a monitorear.
• Definamos un período de "observación" para intentar sacar conclusoines y decidir con cuáles nos quedamos (indicadores) y de qué manera podríamos estar impactando en ellos con los cambios.
• Las posibles "entrvistas" y/o pedidos de feedback a estudiantes podrían servirnos como "indicios" o para complementar pero lo fundamental es definir observaciones objetivas, concretas y medibles (cuantificables).
• Pedir consejería de "técnicas" para pedir feedback al team de UXD

[unjust]

Estoy retomando esta conversación.

Pedi consejos de UX para técnicas de feedback - estoy esperando respuesta.
Mientras eso creo indicadores objetivos que podemos usar:

• cantidades de sprints para pasar el proyecto (viendo que porcentajes pasa # de sprints recomendado)
• cantidades de auxilio de SCO en el proyecto particular
• comparasion de porcentajes "stuck" de SCO en el proyecto particular
• algo de project checkout?

Puedo intentar a crear un dashboard para comparar proyectos entre cohort. O crees que podemos sacar estes numeros mas o menos facil con los dashboards que hay?
Pense inicialmente en los graficos de comparison de "Indicadores: distribución de respuestas de sprint checkout" en Bootcamp Dashboard v1.0. Dice que este dashboard reemplaza pero tengo que ver si tiene la misma informacion como antes.

Un periodo de observacion puede ser entre 3/4 cohorts (no se si este es 2 meses).

@mfdebian @diego

[unjust]

De UX (Astrid me comento su proceso de feedback)

En mi caso yo he pedido feedback sobre los OAs y el entendimiento que tienen las estudiantes. Agendé una hora con todas y les pedí que se dividan en salas, 7 estudiantes por sala. En cada sala les daba una categoría de OAs para que respondan las preguntas:
Qué entendemos de esta categoría?
Qué OA no estamos considerando?
Qué sugerencias tenemos para optimizar el entendimiento de la categoría o los OAs?
(En una pestaña de excel)
Y luego con coaches pululábamos por las salitas a ver si necesitaban ayuda.
Al final analizaba la info.
Otra opción es añadirlo a la retro del proyecto. En un figjam poner una categoría de proyectos y las típicas preguntas:
Proyectos: qué hicimos bien? Podemos mejorar? Nuevo a implementar?
Selfpaced: qué hicimos bien? Podemos mejorar? Nuevo a implementar?
Etc.

En verdad no se si tenemos los recursos hacer algo tan presencial. Quiza podemos agregar algunas cosas a Project Checkout o pedir algunos retros cortos.

[unjust]

Un método propuesto

Para Issues que tiene cambios de contenido, pensamos en la problema, hipótesis, resultados esperados y como medirlos. Agregamos eso en la descripción de issue para podemos trackear el experimento. Seguimos un poco de este formato.

Ideas para feedback "objetivo" con data:

Usando el dashboard SCO detail, comparamos un cohort anterior (antes de los cambios a un proyecto) con un cohort que tiene un readme / proyecto con cambios, y aislamos el proyecto afectado (por ejemplo Nivel 1 Card Validation)

• Comparamos el sentimiento entre mismo sprints de los dos cohorts - % de auxilio o stuck (quiza enfocando en 1o y 2o sprints donde entra mas confusión)
• Comparamos la cantidad de sprints ellas tomaron para cumplir el proyecto, para ver el % que pasa en el tiempo recomendado
• Con las que tomamos mas sprints que normal (ej > 3), comparamos los sentimientos de los stuck o auxilio para entender mejor sus dificultades

Usando los dashboards de OAs en Project Feedback:

• Aislar algunos OAs o temas donde vamos preparar guias y la data de auto/pareja/coach evaluaciones de los OAs para comparar si estan mejorando lograrlos (aqui deberiaos indicar a los coaches cual queremos ver para ellos estan muy precisos si marcan si o no) ( dejamos porque mucho variación entre coaches)

Para feedback qualitativa:

Viendo el metodo de UX, dudo si tenemos el tiempo para hacer retros en bootcamp y obtener feedback. Otros ideas:

• Preguntas (agregado a Project Checkout, o encuesta aparte?) para ver cual parte de readme / proyecto fue mas ayudo y mas confuso
• Preguntas / encuesta sobre guias que agregamos (cual parte fue clara, que falta)
• Aislar algunos OAs o temas donde vamos preparar guias y preguntamos a ellas calificar su aprendizaje de este OA (ej. Promesas) con la guia.

Un periodo de observación puede ser entre 3 cohorts (o max un mes ?).

[diegovelezg]

Hola @unjust !!!

• De acuerdo con que lo cualitativo tomaría demasiado esfuerzo y tiempo que ahora no tenemos.
• Me parece bien tomar los datos de SCO.
• Dudo de los OAs porque hay demasiada sipersión y diferencia entre coaches.

Podemos ahcer una matriz de validación de hipótesis para cada expderimento, indicando la versión (¿hay versión @mfdebian ?) y cómo se valida o refuta la hipótesis. Acá un ejemplo de algo que hemos estado (desde hace meses de meses) pensando que sea el modo default para todo este tipo de experimentaciones: https://github.com/Laboratoria/dashboards/tree/main/studies

[mfdebian]

así es! los proyectos que crean las coaches para las estudiantes ahora incluyen información de cuál es la versión del proyecto de Bootcamp con la cual se está creando.

estoy de acuerdo con que nos ayudará a hacer las mediciones, siempre y cuando efectivamente las coaches que creen esos proyectos, tengan su rama main al día.

[unjust]

@mfdebian @diegovelezg
Donde deberiamos guardar este matrices para experimentos. No creo en un repo.
Una Coda de experimentos de contenido y curricula?

Piensan es buen idea hacer encuestas como parte de PCO tambien? O solo usar SCO data?

[unjust]

Aqui es la recomendacion por ahora https://github.com/Laboratoria/bootcamp/issues/1242#issuecomment-1494627738