Bartłomiej Polakowski
Wpisy otagowane model
ADDIE – Evaluation
19 Kwiecień 2010
Po ukończeniu poprzedniego etapu – Implementacji, większość osób myśli, że projekt jest skończony. Szkolenie zostało stworzone i przekazane klientowi. Mimo to, jest jeszcze wartościowa praca do wykonania. Tak jak kiedyś powiedział jeden z Polskich polityków – „Mężczyznę poznaje się po tym jak kończy a nie po tym jak zaczyna”:) Zamknięcie projektu nie tylko kończy wszystkie czynności administracyjne, ale także jest miejscem wprowadzenia mechanizmów oceny efektywności projektu i jego produktów (które zdefiniowaliśmy na etapie analizy), które później pozwolą nam sprawdzić osiągnięte rezultaty.
Punktami obowiązkowymi zamknięcia projektu są:
- poinformowanie sponsorów projektu o zakończonych pracach – Project manager powinien poinformować zainteresowane osoby o realizacji projektu i jego ostatecznym zakresie. Od tego momentu wszelkie zmiany i rozszerzenia będą realizowane w ramach innych projektów. Dowodem akceptacji zakończenia projektu jest podpis sponsora na karcie projektu. Po jego uzyskaniu można zamknąć kontrakty z wykonawcami zewnętrznymi i wewnętrznymi oraz zapisać zdobytą podczas projektu wiedzę w bazie wiedzy. Z własnego doświadczenia wiem, że wiedza zdobyta podczas projektu potrafi uratować kolejny projekt:)
- stworzenie raportu zamknięcia projektu – raport ten powinien zawierać informacje o przyczynie zamknięcia, kto i kiedy je zatwierdził, harmonogram projektu, opis ryzyk i sposoby ich zapobiegania, opis użytych metod komunikacji itp.
- uruchomienie mechanizmów oceny produktów projektu – zależności od założeń z analizy będziemy badać ROI czyli zwrot nakładów poniesionych w związku z wdrożeniem projektu bądź ROE czyli zwrot naszych oczekiwań takich jak wzrost zadowolenia klientów lub skrócenie procesów obsługowych
- uczczenie zakończenia projektu – wielu PM o tym zapomina, ale warto podziękować osobom, z którymi współpracowaliśmy. Wspólne wyjście do restauracji doceni nie tylko IT:)
Od tego momentu do akcji wchodzą mechanizmy monitoringu i kontroli.
W ten sposób omówiliśmy wszystkie etapy metodologii ADDIE. Jednak ulega ona ciągłym przemianom dostosowując się do coraz to nowszych projketów. W moich opisach dołączałem elementy normalnie stosowane w metodyce PRINCE2. Także zwiększona popularność rozwiązań rapid e-learningowych powoduje, że ADDIE staje się mniej kaskadowa a bardziej iteracyjna. Postaram się Wam w przyszłych wpisach prezentować ciekawe wykorzytstania tej metodologii.
Poniżej znajdziecie linki do opisów pozostałych elementów ADDIE.
Analysis
Design
Develop
Implement
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.
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?
ADDIE – Design
20 Luty 2010
Pod koniec poprzedniego etapu otrzymujemy kompleksową analizę potrzeb szkoleniowych.
Na etapie projektowania musimy zdefiniować strukturę naszego programu, czas jego trwania, tempo, format i sposób dostarczenia go odbiorcom. W przypadku szkoleń e-learningowych tworzymy tzw storyboard czyli serię ekranów ułożonych w ustalonej sekwencji, która pokazuje jak będzie zbudowane ostateczne szkolenie. Im bardziej szczegółowy storyboard tym lepiej. Powinien on zawierać min. opisy interakcji do zaprojektowania, szkice lub propozycje ilustracji i sposób prezentacji treści szkolenia. Projektowany jest także interfejs, który będzie umożliwiał interakcję użytkownika ze szkoleniem.
Proces projektowania musi być ściśle powiązany i ukierunkowany na cel edukacyjny, który chcemy osiągnąć. Każda instrukcja lub interakcja, którą projektujemy powinna przed stworzeniem przejść analizę pod kątem wartości, którą przynosi.
Cały ten etap powinien być oczywiście podporządkowany wybranej metodyce, która naszym zdaniem najlepiej się sprawdzi w danym przypadku i pozwoli wywołać u użytkownika oczekiwane zachowania (poznawcze, emocjonalne, psychomotoryczne).
W niektórych przypadkach na etapie projektowania tworzony jest tzw. prototyp czyli funkcjonalny model naszego finalnego produktu, który możemy zaprezentować odbiorcom lub użytkownikom w celu zebrania opinii i sprawdzenia, czy nasz projekt odpowiada ich potrzebom.
W tej części projektu należy także uściślić metody i warunki oceny uczestników. Jest to najodpowiedniejszy czas na ustalenie w jaki sposób ocenimy program po wdrożeniu, jak będziemy zbierać dane do analizy, i jak będzie wyglądało raportowanie.