Bartłomiej Polakowski
Archiwum dla Marzec, 2010
ADDIE – Implementacja
29 Marzec 2010
Po zakończeniu poprzednich etapów mamy stworzone szkolenie, instrukcje dla uczestników i administratorów, mechanizmy oceny uczestników i efektów projektu.
Kolejnym krokiem jest implementacja naszego szkolenia. Na pierwszy rzut oka może się wydawać, że jest to najprostszy i najkrótszy etap. Mamy gotowy produkt, materiały szkoleniowe i informacyjne, przewidzieliśmy czas na wdrożenie, zarezerwowaliśmy potrzebne zasoby, pilnowaliśmy aby nasze szkolenie było kompatybilne ze standardami i wykonywaliśmy po drodze testy. Często jednak się zdarza, że tak jak w przypadku prezentacji Microsoftu w kluczowym momencie pojawia się „niebieski ekran”:)
Implementacja szkolenia powinna się składać z minimum trzech etapów:
1) Techniczne wdrożenie szkolenia – stworzenie „paczki” i zaimportowanie jej na docelowym systemie. Jeżeli system zawiera mechanizm testowania poprawności paczki to mamy jeden krok z głowy. Jeżeli nie, to musimy użyć dodatkowego narzędzia lub bardziej skupić się na testach. Jeżeli nasze szkolenie składa się z kilku modułów (lekcji i testów) warto je zintegrować używając narzędzi takich jak Reload Editor. Ułatwi nam to znacznie import i pomoże zapanować nad projektami.
2) Testy treści szkolenia – sprawdzenie czy animacje są zgrane z lektorem, czy wyświetlają się wszystkie grafiki, czy działają interakcję, czy szkolenie się nie zawiesza. Najlepiej aby content był przetestowany przez możliwie dużą liczbę osób w różnych konfiguracjach sprzętowych. Należy także sprawdzić czy prawidłowo przesyłane są dane ze szkolenia do docelowego LMS – czy zapisują się wyniki i historia nauki, czy zapisywane są odpowiedzi na testy, czy można wrócić do miejsca gdzie się opuściło szkolenie itp.
3) Przygotowanie administratorów – jakbyśmy się nie przygotowali zawsze znajda się osoby, które będą potrzebowały wsparcia. Z tego powodu należy zapoznać administratorów z naszym szkoleniem i zwrócić ich uwagę na elementy, które według naszego doświadczenia mogą sprawić najwięcej problemów. Czasami jakaś interakcja może wymagać określonego zachowania, którego użytkownik nie zna (czytanie instrukcji to dla wielu osób zmarnowany czas:)
W czasie implementacji może się okazać, że będziemy musieli coś zmienić w naszym szkoleniu dlatego nie warto żegnać się z developerami:) Z mojego doświadczenia wynika, że nawet korzystając z narzędzi rekomendowanych przez producenta platformy zdarzają się nieprzewidziane sytuacje. Dla mnie ten etap kończy się dopiero, gdy pierwsza grupa użytkowników przejdzie szkolenie bez żadnych problemów.
Rencenzja książki – Project Managing E-learning
16 Marzec 2010
Jak zostać profesjonalnym twórcą szkoleń
13 Marzec 2010

ADDIE – Develop
10 Marzec 2010
Po krótkiej przerwie spowodowanej wzrostem popularności moich usług w biurze:) wracamy do omawiania modelu ADDIE. Opisałem już dwie pierwsze części, w których analizujemy dokładnie potrzebę, którą stoi za naszym nowym szkoleniem, określiliśmy dokładnie zakres projektu, stworzyliśmy harmonogram i zarezerwowaliśmy niezbędne zasoby oraz uzgodniliśmy projekt szkolenia. Czas na development czyli wytworzenie finalnego produktu.
Jako wzorzec i szkielet naszego szkolenia, traktujemy stworzony w fazie projektowania scenariusz (storyboard). Wypełniamy go materiałami audio&video, tworzymy i umieszczamy interakcje, wstawiamy materiał tekstowy etc. Pamiętajcie o zasadzie KIS (Keep It Simple!) Dogrywanie ścieżki dźwiękowej polecam zostawić na sam koniec gdy reszta elementów będzie na swoim miejscu. Niestety tworzenie szkoleń tak jak inne projekty musi uwzględniać zmiany, które prędzej czy później się pojawią. O ile zmiana ilustracji nas za bardzo nie zaboli to poprawa ścieżki lektorskiej jest już bardziej skomplikowanym zadaniem.
Aby lepiej pokazać zmienność projektu na etapie developmentu przyjrzymy się się metodzie rapid prototyping. Kiedyś tworzenie szkoleń miało charakter kaskadowy – projektant spotykał się na początku projektu z ekspertem (SME), z którym omawiał zakres powstającego szkolenia i kształt finalnych materiałów a następnie działał samodzielnie. Powodowało to często stworzenie szkolenia, nie spełniającego wymagań klienta. Z pomocą przyszła iteracyjna metoda rapid prototyping i wspierające ją narzędzia. Ten sposób tworzenia materiałów polega na cyklicznych spotkaniach z ekspertem i przedstawicielem klienta. Po każdym spotkaniu wprowadzane są korekty do powstającego szkolenia. W ten sposób unikamy zaskoczenia ze strony klienta. Dzięki narzędziom takim jak Articulate, Captivate albo Lectora możemy błyskawicznie reagować na zmiany.
Przy częstych zmianach w dużym projekcie warto pomyśleć o zarządzaniu zmianami (change management) czyli ustaleniu w jaki sposób, i w jakiej formie powinny być zgłaszane poprawki, a także jak i przez kogą będą realizowane.
Na co jeszcze powinniśmy zwrócić szczególną uwagę na etapie developmentu? Na pewno musimy mieć na oku budżet. Jego przekroczenie jest poza niedotrzymaniem harmonogramu najczęstszą przyczyną niepowodzeń projektów. Należy także nieustannie "chuchać" na naszego sponsora i osoby lobbujące nasz projekt:) Warto informować ich na bieżąco o postępach w projekcie (bez zbytecznych informatycznych szczegółów;), aby nie tracili zainteresowania naszą "produkcją". To ważne, bo bez odpowiedniego wsparcia nasz projekt, nawet po pozytywnym zakończeniu może trafić do szuflady, a tego byśmy nie chcieli:)
Na koniec chciałbym zwrócić Waszą uwagę na dwa zagrożenia.
Istotnym czynnikiem, który często jest zaniedbywany, a powoduje opóźnienia w harmonogramie i wytworzenie produktów niezgodnych z oczekiwaniami jest brak komunikacji w zespole. Przed rozpoczęciem szkolenia powinniśmy dokładnie zaplanować kto z kim, kiedy i w jaki sposób powinien się skontaktować. Warto także zorganizować spotkanie wprowadzające poza biurem gdzie członkowie zespołu mogą się osobiście poznać.
Drugą częstą przyczyną niepowodzeń projektów jest przyjęcie na etapie projektowania nierealnych założeń przy ustalonym harmonogramie. Niestety przy mniej doświadczonym kierowniku projektu może się zdarzyć, że przewidział zbyt krótki czas lub małe zasoby do wdrożenia wszystkich zaplanowanych elementów.
Bądźcie czujni!
A jakie są Wasze developerskie doświadczenia?