Program edukacyjny jako produkt — od discovery do skalowania

Program zajęć może być zbiorem prezentacji przygotowanych przez prowadzącego. Może też być produktem: odpowiadać na rozpoznaną potrzebę, mieć określoną grupę odbiorców, plan rozwoju, kryteria jakości, dokumentację i cykl zmian wynikających z rzeczywistego użycia. W ten drugi sposób zaprojektowałem program nauki programowania dla dzieci z wykorzystaniem Minecrafta, ComputerCraftEdu i języka Lua.

W ciągu czterech lat materiały wykorzystano podczas zajęć dla ponad 2 000 dzieci w Warszawie i okolicach. Program działał w dziesiątkach placówek i był prowadzony przez innych instruktorów, dlatego jego jakość nie mogła zależeć od stałej obecności autora.

Discovery: cztery perspektywy jednego produktu

Przed zaprojektowaniem materiałów analizowałem nie tylko temat zajęć, ale cały kontekst ich użycia. Potrzeby różnych grup nie były identyczne:

dzieci potrzebowały szybkiej informacji zwrotnej, widocznego efektu i stopniowego wzrostu trudności;
rodzice oczekiwali zrozumiałej wartości edukacyjnej, bezpieczeństwa i ciągłości programu;
placówki potrzebowały formatu możliwego do realizacji w określonym czasie, przestrzeni i warunkach technicznych;
instruktorzy potrzebowali scenariuszy, które da się poprowadzić bez dodatkowego wyjaśnienia autora.

Discovery obejmowało analizę lokalizacji i warunków organizacyjnych, bezpośrednie działania w terenie, obserwację zajęć, rozmowy z odbiorcami oraz weryfikowanie pomysłów podczas realnej pracy z grupami.

Cel produktu i kryteria sukcesu

Celem nie było samo „użycie Minecrafta na zajęciach”. Produkt miał umożliwić dzieciom przejście od pierwszych poleceń do samodzielnego rozwiązywania problemów za pomocą tekstowego języka programowania. Jednocześnie musiał być powtarzalny organizacyjnie i możliwy do prowadzenia przez kilka osób.

Praktyczne kryteria jakości były następujące:

każda jednostka zajęć kończy się widocznym rezultatem działania kodu;
kolejne tematy wynikają z wcześniej poznanych pojęć;
instruktor rozumie cel, przebieg i typowe trudności bez kontaktu z autorem;
materiały działają w przewidzianym czasie zajęć i na dostępnym sprzęcie;
rozwiązanie można wykorzystać ponownie dla kolejnych grup bez tworzenia programu od zera.

Roadmapa i rozwój zakresu

Zakres został podzielony na serie tematyczne i etapy trudności: od pierwszych komend, przez pętle i warunki, po bardziej samodzielne zadania i automatyzację działań w świecie gry. Roadmapa nie była listą technologii do omówienia, lecz planem rozwoju umiejętności uczestnika.

Backlog materiałów obejmował nowe scenariusze, przykładowe programy, ćwiczenia, poprawki wynikające z zajęć oraz instrukcje dla prowadzących. Priorytet otrzymywały zmiany, które usuwały blokadę wielu grup albo upraszczały pracę instruktorów, a nie tylko te, które były najciekawsze technicznie.

Iteracja na podstawie rzeczywistego użycia

Zajęcia były jednocześnie sposobem dostarczenia produktu i źródłem informacji zwrotnej. Obserwowałem miejsca, w których dzieci traciły kontekst, zadanie wymagało zbyt wielu nowych pojęć naraz albo instruktor potrzebował dodatkowego wyjaśnienia. Następnie zmieniałem kolejność, przykłady, opis lub zakres ćwiczenia.

To różni rozwijany produkt od jednorazowego materiału: publikacja scenariusza nie zamyka pracy. Liczy się jego zachowanie w realnym procesie, z różnymi grupami, instruktorami i warunkami technicznymi.

Skalowanie przez dokumentację i standard

Najważniejszą decyzją produktową było przyjęcie zasady: scenariusz musi działać bez obecności autora. Materiały zawierały kontekst, cel, kolejne kroki, przykłady i informacje potrzebne prowadzącemu. Wspólna struktura ograniczała czas przygotowania zajęć i różnice między grupami.

Program został połączony z bazą wiedzy, standardem konfiguracji komputerów, szkoleniami instruktorów i procesem utrzymania materiałów. Produkt obejmował więc nie tylko treść dla uczestnika, ale cały system potrzebny do jej niezawodnego dostarczenia.

Rezultat

ponad 100 scenariuszy oraz powiązanych materiałów do nauki programowania;
wykorzystanie podczas zajęć dla ponad 2 000 dzieci w ciągu czterech lat;
możliwość prowadzenia programu przez wielu instruktorów i w wielu lokalizacjach;
wielokrotne wykorzystanie tych samych aktywów bez kosztu tworzenia programu dla każdej grupy od początku;
rozwój produktu na podstawie obserwacji, informacji zwrotnej i zmian w środowisku technicznym.

Jakie kompetencje pokazuje ten projekt

Projekt potwierdza praktykę w product discovery, rozpoznawaniu potrzeb różnych grup, definiowaniu celu i kryteriów jakości, tworzeniu roadmapy i backlogu, priorytetyzacji, iteracyjnym rozwoju, testach w rzeczywistym środowisku, dokumentacji oraz zarządzaniu całym cyklem życia produktu. Formalny tytuł stanowiska nie był potrzebny, ponieważ odpowiedzialność produktowa wynikała z faktycznie wykonywanej pracy — od pomysłu i analizy po użycie, utrzymanie i rozwój.