Program edukacyjny jako produkt: od discovery do skalowania
Discovery: cztery perspektywy jednego produktu
Zanim zabrałem się za materiały, przyjrzałem się nie samemu tematowi zajęć, tylko wszystkiemu dookoła. Każda grupa chciała czego innego:
- 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;
- szkoły potrzebowały formatu, który zmieści się w ich godzinach, salach i sprzęcie;
- instruktorzy potrzebowali scenariuszy, które da się poprowadzić bez dodatkowego wyjaśnienia autora.
Żeby to ustalić, jeździłem po lokalizacjach, sprawdzałem warunki, siedziałem na zajęciach, rozmawiałem z ludźmi i próbowałem swoich pomysłów na żywo, na prawdziwych grupach.
Cel produktu i kryteria sukcesu
Nie chodziło o to, żeby użyć Minecrafta na zajęciach. Chodziło o to, żeby dziecko przeszło od pierwszych komend do samodzielnego rozwiązywania problemów w tekstowym języku programowania. Przy okazji kurs musiał dać się powtarzać i prowadzić przez kilka różnych osób.
Praktyczne kryteria jakości były następujące:
- każde zajęcia kończą się czymś, co widać na ekranie;
- 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
Podzieliłem materiał na serie tematyczne i poziomy trudności: od pierwszych komend, przez pętle i warunki, po samodzielne zadania i automatyzację w świecie gry. Roadmapa opisywała, co dziecko ma po kolei umieć, a nie jakie technologie zdążę omówić.
W backlogu leżały nowe scenariusze, przykładowe programy, ćwiczenia, poprawki po zajęciach i instrukcje dla prowadzących. Najpierw brałem to, co odblokowywało wiele grup naraz albo ułatwiało życie instruktorom, a nie to, co było 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.
Tym właśnie różni się rozwijany produkt od jednorazowego materiału. Wypuszczenie scenariusza niczego nie kończy. Liczy się, jak sprawdza się później, przy różnych grupach, instruktorach i sprzęcie.
Skalowanie przez dokumentację i standard
Najważniejsza decyzja brzmiała: scenariusz musi działać, kiedy autora nie ma w pobliżu. Dlatego w materiałach był kontekst, cel, kolejne kroki, przykłady i wszystko, czego potrzebuje prowadzący. Wspólna struktura skróciła przygotowanie zajęć i zmniejszyła różnice między grupami.
Kurs spiąłem z bazą wiedzy, standardem konfiguracji komputerów, szkoleniami instruktorów i sposobem odświeżania materiałów. Poza treścią dla dziecka trzeba było zbudować wszystko, co pozwala tę treść regularnie dowieźć.
Co z tego wyszło
- ponad 100 scenariuszy oraz powiązanych materiałów do nauki programowania;
- wielokrotne wykorzystanie materiałów podczas rzeczywistych zajęć;
- możliwość prowadzenia programu przez wielu instruktorów i w wielu lokalizacjach;
- te same materiały używane wiele razy, bez pisania kursu dla każdej grupy od nowa;
- kurs poprawiany na podstawie obserwacji, uwag i zmian w sprzęcie.