Bez kategorii

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?