Zasady zarządzania projektem eLearningowym - Wprowadzenie, Planowanie
Moduł Zasady zarządzania projektem eLearningowym skupia uwagę na technikach prowadzenia projektów. W szczególności ukazuje różnice pomiędzy projektami prowadzonymi klasycznie (np. w obrębie organizacji) a podejściem do zarządzania projektami eLearninogowymi.
Określenie celu edukacyjnego modułu
Celem modułu jest ukazanie sposobów prowadzenia projektów eLearningowych, a także wskazanie najlepszych praktyk (best practice), które umożliwią proste i łatwe zarządzanie projektem.
Wiadomości zawarte w tym module przydadzą się podczas realizacji projektów eLearningowych. Skierowane sa zarówno do przyszlych i obecnych Managerów Projektu jaki jako programistów, planistów oraz testerów oprogramowania.
Plynne i sprawne zarzadzanie projektem to podstawa jego sukcesu.
Wiedza bazowa potrzebna do pracy nad modułem
wersja multimedialna | wersja do druku |
Projekt - (łac. Proiectus, czyli wysunięcie ku przodowi) wiedza podstawowa
Projekt, to sekwencja niepowtarzalnych, złożonych i związanych ze sobą zadań, mających wspólny cel, przeznaczonych do wykonania w określonym terminie bez przekraczania ustalonego budżetu, zgodnie z założonymi wymaganiami.
Standardy
Korzystanie ze standardów od początku pracy jest fundamentem
dobrego projektu. Standardy wskazują jakość, do której zobligowani są dążyć
członkowie zespołu projektowego.
Standardy projektowe czerpane są z dwóch głównych źródeł.
Pierwszym są wartości które będą stałe dla większości naszych projektów. Drugie
źródło pochodzi ze szczególnej specyfikacji konkretnego projektu i/lub klienta.
Przykład:
Standardem może być pisemne opracowywanie koncepcji rozwiązania, utrzymywane
w ustalonej w naszej firmie lub organizacji notacji.
Klient, któremu przedstawimy nasz standardowy dokument może sobie zażyczyć dodanie
informacji w nagłówku dokumentu dotyczącej ostatniej aktualizacji opracowania.
Dla tego klienta standardem staje się dokument odbiegający od naszych przyzwyczajeń.
Pamiętajmy jednak - klient - Nasz Pan.
Ewolucja projektu
Do przygotowanie dobrego produktu potrzebna jest stała współpraca z klientem. Aby nasze wyobrażenie produktu nie odbiegało od wizji naszego klienta potrzebne są okresowe spotkania (w świecie wirtualnym zastępują je NetMeeting, telefon, e-mail), akceptowanie ze strony klienta kolejnych naszych kroków oraz gotowych faz dokumentacji i oprogramowania. Zmianom mogą podlegać także nasze standardy, należy jednak pamiętać by wszyscy zaangażowani w projekt byli poinformowani nawet o najmniejszych zmianach standardów i ich przestrzegali.
Innym aspektem ewolucji projektu jest dbanie o jakość
samego produktu.
W tym celu należy pamiętać o procesie testowana półproduktów zanim scalimy je
w finalny produkt. Każdy półprodukt może podczas testowania ewoluować, może
też być w każdej chwili cofnięty do poprzedniej wersji.
Zarządzanie projektem
Jednym z najważniejszych atrybutów który potrzebny będzie do osiągnięcia sukcesu (zakończenia projektu) jest sposób, w jaki będziemy nim zarządzali. Zarządzali zasobami, pieniędzmi i czasem. Od początku do końca trwania życia projektu te trzy aspekty muszą być pod naszą kontrolą, w przeciwnym wypadku dość łatwo możemy popaść w nieład.
Podstawową kwestią jest zaplanowanie działań. Nigdy
nie należy lekceważyć ani bagatelizować tej czynności. Kolejną jest ciągłe i
stałe monitorowanie stanu realizacji wszystkich działań w stosunku do nakreślonego
planu. Trzecią ważną cechą dobrze zarządzanego projektu jest komunikacja.
Komunikacja wewnątrz zespołu projektowego a także komunikacja z klientem.
Często różnica pomiędzy sukcesem a porażką leży w sposobie zarządzania projektem,
dlatego też warto docenić tą czynność.
Analiza - wstęp
Pracę z projektem powinniśmy rozpocząć od analizy.
Na wstępie powinniśmy sobie odpowiedzieć na pytania:
Jaki jest cel projektu?
Jakie są szczegółowe wymagania projektu?
Jaki został określony czas zakończenia projektu?
Jaki jest budżet projektu?
Jakie są dostępne zasoby?
Postarajmy się skupić na słowach kluczowych zawartych w powyższych pytaniach.
Cel
Jak pamiętamy z definicji jedną z głównych cech projektu jest jeden - konkretny cel do którego dążymy. Celem może być nauka obsługi nowego programu do raportowania czasem, nauka gotowania oraz wiele innych.
Wymagania
Wymagania projektowe są najczęściej przedstawiane ze strony klienta. Wymagania to inaczej wyspecyfikowanie konkretnych życzeń. Szczególnym wymaganiem może być czas zakończenia projektu oraz budżet , w którym mamy się zmieścić. Te jednak specyfikujemy poniżej. Wymaganiem może być platforma systemowa, na której powinniśmy oprzeć naszą pracę. Wymaganiami może być także wyspecyfikowany zakres szkolenia, jego rodzaj, ilość testów i egzaminów dostępnych dla użytkownika.
Czas zakończenia
Jedną z podstawowych cech projektu jest określony, nie zmienny, czas jego zakończenia. Wszystkie kolejne działania w obrębie projektu muszą mieć zaplanowany czas rozpoczęcia oraz zakończenia. Jeśli jedno z działań zależne jest od innego, możemy ustalić czas potrzebny do wykonania zadania zaznaczając jednocześnie zależność rozpoczęcia nowej czynności od ukończenia innej.
Budżet
Budżetem w projekcie nie muszą być jedynie środki finansowe. Fundacje, Stowarzyszenia prowadzące projekty non-profit mogą w budżecie liczyć czas wolontariuszy, którzy zgodzili się na udzielenie wsparcia. W Budżecie możemy zawrzeć także czas pracy urządzeń, które zostały nam udostępnione, oraz inne zasoby, nad którymi otrzymujemy kontrole. Oczywiście w typowym projekcie w budżecie zawierać się będą także środki finansowe.
Dostępne zasoby
Zasoby to pracownicy oraz ich umiejętności. To także dostęp do wiedzy eksperckiej, źródeł, skryptów.
Zarządzanie projektem - fazy
Planowanie - wstęp
Faza planowania obejmuje następujące zagadnienia:
Zdefiniowanie zakresu pracy
Charakterystyka odbiorcy
Zagrożenia
Koszty
Styl projektu
(standard)
Określenie i zebranie zasobów
Projektowanie - wstęp
Faza Projektowanie to faza w której odbywa się przeniesienie pomysłu na papier, zrozumienie potrzeb w postaci rozwiązań projektowych, tworzenie zarysu programu, który odpowiada potrzebom odbiorcy. Faza Projektowanie, także produkcja dokumentacji.
Produkcja - wstęp
W Fazie produkcji będziemy precyzować mechanizmy zarządzania poszczególnymi działami projektowymi. Określimy dokumenty potrzebne do prawidłowego prowadzenie projektu, oraz te, które należy przygotować w celu przekazania produktu do klienta. Zwrócimy także uwagę na kwestie budżetu projektowego, wytłumaczymy jak zarządzać czasem pracowników i projektu. Na koniec opowiemy o sposobie przeprowadzania testów.
Ewaluacja - wstęp
Faza Ewaluacji odpowie nam na pytania dotyczące jakości dydaktycznej i pedagogicznej naszego szkolenia.
Planowanie
Pierwszą fazą budowy projektu e-learningowego jest faza planowania. W tej fazie musimy upewnić się, że rozumiemy, na czym polega nasz projekt jak również, jakie ograniczenia na nas czekają w drodze do celu. Prawidłowo wykonana faza planowania jest niezbędna do osiągnięcia sukcesu. Brak odpowiedniego zaplanowania poszczególnych etapów budowy projektu narazi nas na znaczne oddalenie się od planowanego czasu jego zakończenia. Ta zależność jest stała i dotyczy zarówno tworzenia projektów na potrzeby własne jak i dla klienta zewnętrznego.
Określenie zakresu projektu
Pierwszym krokiem w planowaniu jest upewnienie się czy znamy zakres projektu, którego się podejmujemy. Czy wiemy, kto i czego ma się nauczyć? Czy wiemy, jaką wiedzę podstawową musi posiadać by przejść nasz kurs? Czy wszyscy "uczący się" mają zapoznać się z materiałem w równym stopniu?
Możemy spotkać się z bardzo różnymi poziomami kompetencji
po stronie zamawiającego.
Podstawą będzie zrozumienie jego potrzeb oraz jakie cele mamy osiągnąć poprzez
nasze szkolenia. Musimy sobie także zdawać sprawę z tego, że często problem
opisany przez osobę wyznaczoną do kontaktów z nami ze strony sprzedającego,
może być źle zdiagnozowany lub opisany. Pamiętajmy, kursy przeznaczone są dla
użytkowników a nie klientów - dlatego aby
zachować równowagę i zadowolić obie grupy należy bardzo dokładnie zdiagnozować
zakres projektu.
Użytkownicy często dzielą się na podgrupy. Możemy
sobie wyobrazić szkolenie techniczne z zakresu nowego oprogramowania. W takim
szkoleniu mają uczestniczyć administratorzy systemu jak i sprzedawcy. W takim
przypadku szkolenie musimy przegotować tak, by te dwie, różne w swojej mentalności
grupy użytkowników, chętnie je zakończyły.
Zwróćmy uwagę, że sprzedawca będzie skupiał się na swojej profesji, będzie chciał
poznać mocne strony nowego produktu, raczej nie zainteresuje go wiedza techniczna
płynąca ze szkolenia. Administrator będzie zainteresowany wewnętrznymi procesami,
które wprowadza oprogramowanie, zwróci uwagę na sposób jego instalacji oraz
na scenariusze rozwiązywania problemów związanych z oprogramowaniem.
W innych przypadkach, gdy naszym użytkownikiem końcowym jest bliżej nieokreślona grupa użytkowników (np. wszyscy użytkownicy komputerów domowych) sami musimy zdecydować, jaką wartość chcemy zawrzeć w naszym szkoleniu.
W każdym z powyższych przypadków wszelkie decyzje i wątpliwości
powinniśmy konsultować z jednostkami decyzyjnymi. (Warto jest podczas rozmów
z klientem nie formalnie zweryfikować, kto siedzi "po drugiej stronie stołu"
i czy są tam przedstawiciele zarówno klientów jak i poszczególnych grup użytkowników).
Dzięki szerokim i częstym konsultacjom jesteśmy w stanie zbudować prawidłowy
zakres szkolenia, które zobligowaliśmy się stworzyć.
Podczas konsultacji warto prowadzić notatki, obrazować rozwiązanie na tablicach lub dużych arkuszach papieru.
Po zakończeniu pracy nad zakresem warto przygotować dokument, który będzie specyfikacją zakresu prac, jakie uzgodniliśmy się wykonać. Taki
dokument nie tylko pozwoli lepiej określić i zrozumieć nakreślone cele, ale także
będzie stanowił formę zabezpieczenia. Pozwoli, bowiem porównać zakres z gotowym
produktem.
Często podczas pracy nad produktem dochodzi do zmian decyzji po stronie klienta.
W takim przypadku mamy już narzędzie, które pomoże nam zdecydować, czy uwzględniamy
zmiany zaproponowane przez klienta, czy też kończymy produkt wcześniej już uzgodniony.
Możemy także przystąpić do renegocjacji warunków umowy.
Dokument stanowiący dokumentacje zakresu lub dokumentacja funkcjonalną należy podpisać z przedstawicielami klienta.
Zrozum swojego klienta
Prace nad projektem warto rozpocząć od poznania samego
klienta. Zbadać, jakie ma doświadczenie w dziedzinie e-learning'u, jakie są
jego przyzwyczajenia i oczekiwania. Oszacowanie czasu, jaki potrzebny jest na
przygotowanie i wdrożenie projektu bez wątpienia jest ściśle związane z doświadczeniem
strony zamawiającej produkt.
Możemy spotkać klienta, który rozpoczyna dopiero przygodę z e-learning'iem,
ma jednak bardzo dobrą znajomość technik multimedialnych. Czasami klient ma
problemy ze zrozumieniem zagadnień technicznych, ma jednak bardzo silną wizję
końcowego produktu, a to także może być bardzo pomocne.
W przypadku pracy z niedoświadczonym klientem warto delikatnie edukować klienta.
Można na przykład stworzyć dokument, który określi zasady prowadzenia projektu,
jaka jest w niej rola klienta, a jaka zleceniobiorcy.
W przypadku posiadania własnej firmy taki dokument może zawierać opis naszych
standardów i zasad, którymi się kierujemy. Warto przeprowadzić z klientem dyskusje,
dowiedzieć się, jakie są jego wymagania, co do stylu pracy.
Sytuacja, w której klient zdaje się na nasze doświadczenie, twierdząc, że ufa
nam bezgranicznie wydaje się być idealną, taką jednak nie jest. Klient MUSI
być świadomym podejmowanych decyzji oraz zakresu prac. Tylko w ten sposób możemy
go zadowolić. Zaangażowanie klienta pozwoli nam również wykazać naszą pracowitość
i profesjonalizm.
Charakterystyka odbiorcy
U podstawy wszystkich dobrych szkoleń leży prawidła ocena użytkownika końcowego. Kim będą uczący się? Czy pracują w specyficznym środowisku? Jakie posiadają kompetencje? Jakie mają wykształcenie? Odpowiedzi na te i inne pytania mogą determinować sposób, w jaki zaprojektujemy nasze szkolenie.
Na świecie roi się od szkoleń, które posiadają najnowsze
multimedialne nowinki, jednak nie osiągnęły podstawowego celu: nie pozwoliły
na edukację grupy użytkowników, dla której były przygotowywane.
Najczęściej popełniane błędy podczas projektowania szkoleń to: błędne oszacowanie
wiedzy podstawowej potrzebnej do odbycia szkolenia, brak kompatybilności środowiska
pracy użytkowników z naszymi wymogami. (oprogramowanie, moc komputera)
W celu lepszego poznania grupy docelowej warto jest przygotować dokument, dzięki
któremu bliżej poznamy poziom wiedzy i środowisko pracy użytkowników.
Pamiętajmy, użytkownicy będą różnić się od siebie. Naszym zadaniem będzie przygotować
szkolenie, które trafi do jak największej populacji grupy docelowej. Prawdopodobnie
nasze szkolenie będzie za trudne dla kilku procent populacji. Będzie także procent
użytkowników, których wiedza dotycząca tematu szkolenia będzie zdecydowanie
większa. Z takimi założeniami musimy się pogodzić. Naszym zadaniem jest edukacja
jak największej populacji użytkowników.
Młodzi projektanci mają ambicję trafić do wszystkich, przez co dużo czasu spędzają nad przygotowaniem materiałów dla grup mniejszości. Z reguły taka praca jest mało efektywna, gdyż pochłania wiele czasu, a nie przynosi dużej wartości. Nadmierne uproszczenie szkolenia może także zniechęcić dużą grupę użytkowników posiadających odpowiednią wiedzę.
Przykładowa ankieta znajduje się poniżej:
Słabi uczniowie |
Przeciętni uczniowie |
Silni uczniowie |
|
Wiek | |||
Poziom edukacji | |||
Motywacja | |||
Wiedza podstawowa | |||
Umiejętności podstawowe | |||
Obsługa komputera | |||
Znajomość obsługi Internetu | |||
Pisanie bezwzrokowe | |||
Dostępność komputera | |||
Dostępność Internetu |
|||
Dostępność czasu |
|||
Procent populacji | |||
Preferencje językowe.
Czy występują przypadki fizycznych upośledzeń? |
Zastanówmy się nad zawartością powyższego dokumentu. Większość z nich wydaje się być zrozumiała. Dzięki informacjom dotyczącym edukacji oraz posiadanej wiedzy podstawowej z interesującego nas zagadnienia możemy zaprojektować zawartość merytoryczną naszego szkolenia. Dzięki informacjom dotyczącym dostępu do internetu możemy zadecydować o formie szkolenia. Szkolenie może mieć przecież charakter aplikacji instalowanej na komputerze użytkownika, może być także programem klient - serwer - albo aplikacją WEB'ową.
Pozornie proste pytanie o wiek populacji niesie za sobą bardzo wiele informacji dodatkowych. Pamiętajmy, że różne grupy wiekowe posiadają różne preferencje co do języka prezentacji jak i jej szaty graficznej. Informacja o wieku użytkowników pozwoli nam także w przybliżeniu oszacować, kiedy zakończyli oni naukę albo jakie jest ich przygotowanie do pracy z komputerem.
Przykład:
Mamy za zadanie przygotować szkolenie z arkusza kalkulacyjnego.
Poniżej przedstawiamy charakterystyki użytkowników z prywatnej firmy komputerowej
oraz z urzędu państwowego.
Urząd Państwowy:
Słabi uczniowie |
Przeciętni uczniowie |
Silni uczniowie |
|
Wiek | 35-60 | 20-50 | 25-40 |
Poziom edukacji | Wykształcenie średnie | Wykształcenie średnie | Wykształcenie wyższe |
Motywacja | słaba | przeciętna | silna |
Wiedza podstawowa | Znajomość podstaw matematyki | Znajomość podstaw matematyki | Znajomość podstaw matematyki |
Umiejętności podstawowe | Niewielkie doświadczenie w dziedzinie pracy nad budżetem | Niewielkie doświadczenie w dziedzinie pracy nad budżetem | Niewielkie doświadczenie w dziedzinie pracy nad budżetem |
Obsługa komputera | bardzo słaba | słaba | dobra |
Znajomość obsługi Internetu | bardzo słaba | słaba | dobra |
Obsługa klawiatury | słaba | średnia | dobra |
Dostępność komputera | średnia | średnia | średnia |
Dostępność Internetu |
Brak w pracy. Część z użytkowników ma dostęp w domu | Brak w pracy. Część z użytkowników ma dostęp w domu | Brak w pracy. Część z użytkowników ma dostęp w domu |
Dostępność czasu |
8 godzin w następnym miesiącu | 8 godzin w następnym miesiącu | 8 godzin w następnym miesiącu |
Procent populacji | 70% | 20% | 10% |
Preferencje językowe.
Wszyscy pracownicy muszą znać biegle język polski w mowie i piśmie. Czy występują przypadki fizycznych upośledzeń? Część pracowników ma problemy ze słuchem. |
Prywatna firma komputerowa
Słabi uczniowie |
Przeciętni uczniowie |
Silni uczniowie |
|
Wiek | 55-60 | 20-25 | 25-40 |
Poziom edukacji | Wykształcenie wyższe | Wykształcenie wyższe | Wykształcenie wyższe |
Motywacja | słaba | przeciętna | silna |
Wiedza podstawowa | Znajomość podstaw matematyki | Znajomość podstaw matematyki | Znajomość podstaw matematyki |
Umiejętności podstawowe | Niewielkie doświadczenie w dziedzinie pracy nad budżetem | pewne doświadczenie w dziedzinie pracy nad budżetem | Duże doświadczenie w dziedzinie pracy nad budżetem |
Obsługa komputera | Dobra | Dobra | Bardzo dobra |
Znajomość obsługi Internetu | Dobra | Dobra | Bardzo dobra |
Pisanie bezwzrokowe | Słaba | Średnia | Dobra |
Dostępność komputera | Dobra | Bardzo dobra | Bardzo dobra |
Dostępność Internetu |
Dostęp w pracy. Część z użytkowników ma dostęp także w domu | Dostęp w pracy. Część z użytkowników ma dostęp także w domu | Dostęp w pracy. Część z użytkowników ma dostęp także w domu |
Dostępność czasu |
|||
Procent populacji | 5% | 30% | 65% |
Preferencje językowe.
Firma zatrudnia pracowników z Polski, Białorusi oraz Anglii. Podstawowe języki komunikacji to Polski i Angielski. Czy występują przypadki fizycznych upośledzeń? Nie występują. |
Omówienie przykładu:
Powyższy przykład pokazuje nam jak różne mógłbyć środowiska pracy jak i sama charakterystyka użytkowników. Oczywiście powyższe dane zostały uśrednione, czasami klient nie znał pełnych odpowiedź, dlatego wyniki były oszacowywane.
Dzięki tym danym dowiedzieliśmy się na przykład, że większość
pracowników urzędu to ludzie w podeszłym wieku, którzy pracują przy komputerze,
ale ich obsługa komputera jest słaba. W takim przypadku warto się zastanowić
czy szkolenie e-learningowe warto przeprowadzać. Warto także zastanowić się
nad formą szkolenia.
Ważna informacją jest także zatrudnianie przez Urząd osób z kłopotami słuchu.
Ta informacja wskazuje nam potrzebę budowy alternatywnych ścieżek prowadzenie
wykładów. Na pewno poza głosem lektora (ścieżka audio) potrzebujemy także wprowadzenie
wersji z napisami. Informacja o środowisku pracy wskazuje nam także konieczność
budowy aplikacji stanowiskowych, gdyż użytkownicy mają ograniczony dostęp do
internetu. Podaliśmy tu tylko kilka wniosków, oczywiście dane te przekazują
nam o wiele więcej informacji.
W drugim przypadku powinniśmy skupić się przede wszystkim na informacji o zatrudnianych pracownikach. Z danych wynika, że pracownicy firmy posługują się językiem angielskim, musimy zatem przyjąć, że nasze szkolenie odbywać się będzie po angielsku.
Często klient nie jest świadomy swojego nie typowego środowiska
pracy. Nie doprecyzowanie języka, w jakim mamy prowadzić szkolenie może wydać
się przykładem przejaskrawionym. Jest to jednak przykład "z życia"!!
Określenie zagrożeń dla projektu (budowa dokumentu)
Charakterystyka środowiska pracy
Znamy już charakterystykę użytkowników. Warto przyjrzeć
się teraz bliżej ich środowisku pracy.
Te informacje pozwolą nam wybrać platformę programistyczną z jakiej skorzystamy.
Dadzą nam także odpowiedź czy możemy pozwolić sobie na ścieżkę audio (karty
dźwiękowe), streaming video (przepustowość łączy) oraz zaawansowaną grafikę
(karty graficzne).
Zwróćmy uwagę, że czym większa jest korporacja tym więcej różnych platform,
typów komputerów i oprogramowania. Warto podczas badania środowiska pracy dowiedzieć
się czegoś o polityce bezpieczeństwa.
Korporacje często mają swoje wewnętrzne polityki bezpieczeństwa. Może zdarzyć
się, że nasze oprogramowanie zechce zainstalować dodatkowy plug-in na komputerze
użytkownika. Okazać się może, że czynność ta jest niedozwolona, przez co do
instalacji może w ogóle nie dojść, albo wymagać będzie obecności administratora
systemu - co znacząco podniesie koszty szkolenia.
Poniżej przedstawiamy dwa przydatne dokumenty, które pozwolą oszacować złożoność środowiska klienta.
Hardware |
|
Komputer klasy: PC |
Dane szczegółowe i komentarze: |
RAM: | |
Procesor: | |
Karta Dźwiękowa: | |
Słuchawki i mikrofon: | |
Sieć: | |
Wielkość dysku twardego: | |
CD-ROM: | |
Modem/Prędkość modemu: | |
Rozdzielczość Monitora: | |
Komputer klasy: Macintosh |
Dane szczegółowe i komentarze: |
RAM: | |
Procesor: | |
Karta Dźwiękowa: | |
Słuchawki i mikrofon: | |
Sieć: | |
Wielkość dysku twardego: | |
CD-ROM: | |
Modem/Prędkość modemu: | |
Rozdzielczość Monitora: | |
Komputer klasy: Inne |
Dane szczegółowe i komentarze: |
RAM: | |
Procesor: | |
Karta Dźwiękowa: | |
Słuchawki i mikrofon: | |
Sieć: | |
Wielkość dysku twardego: | |
CD-ROM: | |
Modem/Prędkość modemu: | |
Rozdzielczość Monitora: |
Jak już wcześniej wspomnieliśmy, duże firmy mogą posiadać bardzo
wiele środowisk pracy.
Warto jest zebrać dane dotyczące ilości poszczególnych typów komputerów oraz
przyszłej polityki firmy. Możliwy jest udział 30% komputerów klasy Macintosh,
jednak polityka inwestycyjna firma zakłada wymianę połowy PC'tów w najbliższym
roku.
Software |
|
Komputer klasy: PC |
Dane szczegółowe i komentarze: |
System operacyjny wraz z SP: | |
Przeglądarka Internetowa wraz z wersją: | |
Edytor tekstu wraz z wersją: | |
Arkusz kalkulacyjny wraz z wersją: | |
Sieć: | |
Oprogramowanie typu authorware wraz z wersją: | |
Inne: | |
Komputer klasy: Macintosh |
Dane szczegółowe i komentarze: |
System operacyjny wraz z SP: | |
Przeglądarka Internetowa wraz z wersją: | |
Edytor tekstu wraz z wersją: | |
Arkusz kalkulacyjny wraz z wersją: | |
Sieć: | |
Oprogramowanie typu authorware wraz z wersją: | |
Inne: | |
Komputer klasy: Inne |
Dane szczegółowe i komentarze: |
System operacyjny wraz z SP: | |
Przeglądarka Internetowa wraz z wersją: | |
Edytor tekstu wraz z wersją: | |
Arkusz kalkulacyjny wraz z wersją: | |
Sieć: | |
Oprogramowanie typu authorware wraz z wersją: | |
Inne: |
Budżet
Jeśli to tylko możliwe warto określić wysokość dostępnego budżetu. Jeśli tworzymy projekt na własne potrzebny, czynność tak jest prosta. Jeśli jednak szkolenie ma zostać przygotowane dla klienta zewnętrznego, a do konkursu staje wiele firm informacja ta z pewnością będzie trudno dostępna. Znajomość ograniczeń budżetowych jest świetną podpowiedzią podczas planowania złożoności oprogramowania. Podczas konkursu ofert cena zaproponowana przez konkurencje może znacząco odbiegać od naszych wyliczeń. Warto jest, więc doprecyzować koszty.
Przykład:
Duża korporacja poszukuje firmy, która stworzy szkolenie z zakresu zasad przestrzegania
BHP. W konkursie uczestniczy 3 oferentów. Różnica pomiędzy najtańszą a najdroższa
ofertą wynosi 20 tyś złotych.
Przyjrzyjmy się, zatem różnicom:
Oferta najtańsza | Oferta najdroższa | |
Grafika | Korzystanie z szerokiej gammy obiektów graficznych typu ClipArt | Własny projekt graficzny. |
Narracja | Tekst oraz narracja podczas odtwarzania animacji. | Narrator prowadzący szkolenie + opcjonalnie tekst dla osób niedosłyszących |
Animacja | Scenki animowane ukazujące przykładowe zagrożenia | Scenki z użyciem aktorów, obrazujących prawdziwe zagrożenia |
Platforma | HTML z użyciem przycisków nawigacyjnych | FLASH |
Oczywiście różnic pomiędzy projektami było o wiele więcej. Dotyczyły
one między innymi czasu wykonania oprogramowania, minimalnych potrzeb sprzętowych
itp.
W tym przypadku chcemy zwrócić jednak uwagę na różnice wynikające z obranej
techniki wykonania szkolenia (HTML versus FLASH) , jego złożoności (narrator,
scenki z użyciem aktorów) czy też oryginalności. (własny projekt graficzny).
Znajomość ograniczeń budżetowych może nam dodatkowo nakreślić oczekiwania klienta.
Który z konkurentów wygra? To zależy od preferencji klienta, czy oczekuje on
taniego szkolenia czy też chcąc przekonać pracowników do szkoleń e-learningowych,
potrzebuje on świetnie przygotowanego "flagowego" produktu szkoleniowego.
Harmonogram
W fazie projektu nie możemy podać jedynie daty wykonania wersji końcowej produktu, musimy koniecznie zaznaczyć wszystkie kroki milowe, jakie należy pokonać w celu jego budowy. Musimy także zaznaczyć zależności czasowe pomiędzy kolejnymi krokami. Wszystkie daty główne projektu (deadlines) powinniśmy ustalić z klientem. Warto jest doprowadzić do sytuacji, w której data końcowa jest w relacji z kolejnymi deadline'ami. Kolejne zaś deadline'y muszą być zaakceptowane przez klienta.
Harmonogram powinniśmy utrzymywać w formie dokumentu. Możemy korzystać ze zwykłego szablonu, w którym opiszemy kolejne czynności i daty ich wykonania. Dostępne są także specjalne oprogramowania, jak np. PROJECT czy WBS które mogą pomóc nam w zaplanowaniu i utrzymaniu harmonogramu. Niezależnie od wybranej formy dokument w formie papierowej warto dołączyć do dokumentacji, i postarać się o akceptację klienta w postaci podpisu na kopii dokumentu.
Zadania klienta
Dobrze opracowanych zadań i obowiązków leżące po stronie
klienta nie można przecenić. Klient powinien zostać przez nas uświadomionym
jak ważna jest jego dostępność i chęć współpracy. Ważne by do poszczególnych
zadań klient wyznaczył osoby kontaktowe. Klient powinien także wyznaczyć osobę,
która z jego ramienia będzie odpowiedzialna za podejmowanie decyzji. (SPoC -
Single Point of Conntact). Pamiętajmy o wcześniejszym wyedukowaniu klienta.
Musimy mieć pewność, że jest on świadomy swojego wpływu na wszystkie kroki milowe
i deadlines.
Jeśli klient nie jest w stanie zaproponować SpoC po swojej stronie, warto zaproponować
szablon, który wskaże nam osoby kompetentne w poszczególnych obszarach.
Zadania grupy klienckiej |
|
Członkowie zespołu | Dane osobowe kontaktu |
Negocjator kontraktu | |
Koordynacja projektu | |
Ekspert w danym temacie | |
Pomoc techniczna | |
Pomoc multimedialna | |
Księgowość | |
Wymagane czynności: | |
Przegotowanie materiałów: (skrypty, multimedia, osoby odpowiedzialne za potwierdzenie wykonania) | |
Materiał pierwszy | |
Materiał drugi | |
Materiał trzeci | |
Projekt | |
Interface | |
Skrypty | |
Baza Danych | |
Produkty/Czynności/daty wykonania | |
Podczas pracy nad projektem jesteśmy postawieni w bardzo niezręcznej sytuacji. Zleceniodawca oczekuje projektu na czas, a to wymaga pracy ściśle wg Harmonogramu. W związku z tym będziemy zmuszeni często przypominać klientowi o tym, że bez jego wiedzy nie możemy iść na przód, a przez to termin ustalony w kontrakcie przesunie się.
Warto jest poprosić klienta o deklarację, w której zobowiąże się do przestrzegania terminów i udzielania nam niezbędnej pomocy.
Zadania Grupy projektowej
Oczywiście najwięcej zadań przypadnie nam i naszej
grupie projektowej.
Ze swojej strony musimy zagwarantować osoby odpowiedzialne za poszczególne dziedziny
projektu.
Gdy w projekcie uczestniczy kilka osób, ich nazwiska mogą się powtórzyć, ważne
jednak byśmy zidentyfikowali odpowiedzialnych za wszystkie obszary. W dużych
projektach najczęściej osoby odpowiedzialne za obszary nie będą się powtarzały.
Zadania grupy projektowej |
|
Obszary projektowe | Dane osobowe kontaktu |
Kierownictwo projektu | |
Księgowość | |
Projektowanie | |
Zawartość | |
Tekst | |
Grafika | |
Audio | |
Video | |
Animacje | |
Implementacja | |
Pomoc Techniczna | |
Wymagana dokumentacja | |
Projekt | |
Interface | |
Skrypty | |
Bazy Danych | |
Produkty/Czynności/daty wykonania | |
Zagrożenia - Treść projektu
Szkic treści projektu (proszę zawrzeć główne
tematy oraz podtematy) |
Wymagania projektu graficznego (proszę zawrzeć
oczekiwaną ilość elementów graficznych, zarys stylu, bogactwo grafiki)
|
Zasady rejestracji, typ logowania: |
Test cząstkowe |
Egzaminy (proszę zawrzeć informacje o sposobie
egzaminowania. Egzamin z całości/ Egzaminy po każdej sekcji. Ilość i szczegółowość
pytań, typ egzaminu. Wymogi dot. Przechowywania danych egzaminowanych
i ich wyników.) |
Koszty
W fazie planowania ostatnim i jednocześnie niezmiernie ważnym punktem jest oszacowanie części kosztowej naszego projektu. Aby zrobić to prawidłowo musimy sobie odpowiedzieć na pytania: Ile czasu zajmie nam poszczególne zadanie lub czynność? Czy potrzebować będziemy jakiegoś szczególnego oprogramowania albo sprzętu hardware, aby rozpocząć pracę? Czy mamy wystarczające środki, aby wykonać przedsięwzięcie? Na te pytania możemy odpowiedzieć jedynie znając pełen obraz przedsięwzięcia. Musimy znać własne możliwości oraz potrzeby produktu, który chcemy wytworzyć.
Budżet warto stworzyć zawsze. Nie ma znaczenia czy pieniądze
fizycznie przejdą z ręki do ręki, czy też przepływ ich będzie jedynie w obrębie
naszej korporacji. Budżet warto zrobić nawet gdy odbiorcą oprogramowania jesteśmy
my sami.
Kiedyś, zapytani o "koszt" naszego projektu, będziemy mogli odpowiedzieć
konkretnie np. Ilością przepracowanych godzin.
W tej części zajmiemy się oszacowaniem wszystkich czynników, które wpływają na stworzenie produktu multimedialnego.
Formularz Kosztowy - przykład
Zapoznanie się z projektem |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt zapoznania się z projektem |
suma zł |
Przygotowanie standardów |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania standardów |
suma zł |
Przygotowanie ekranów szkolenia |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania ekranów szkolenia |
suma zł |
Przygotowanie standardów |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania standardów |
suma zł |
Przygotowanie skryptów |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania skryptów |
suma zł |
Przygotowanie ekranów szkolenia |
|
Ekrany łatwe x ekranów po y min/ekran = | |
Ekrany typowe x ekranów po y min/ekran = | |
Ekrany zaawansowane x ekranów po y min/ekran = | |
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania ekranów | suma zł |
Przygotowanie symulatorów porównawczych |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt symulatorów |
suma zł |
Grafika |
|
Projektowanie szaty graficznej x propozycji po h godzin = | |
Grafika prosta x ekranów po y min/ekran = | |
Grafika standardowa x ekranów po y min/ekran = | |
Grafika zaawansowana x ekranów po y min/ekran = | |
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = |
|
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania grafiki | suma zł |
Klipy Video | |
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Koszt produkcji: | |
Koszty gaży: | |
Koszty Edycji: | |
Koszty digitalizacji | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania klipów | suma zł |
Audio |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Koszt produkcji: | |
Koszty gaży: | |
Koszty Edycji: | |
Koszty digitalizacji: | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania audio | suma zł |
Interakcje |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania Interakcji |
suma zł |
Zbieranie danych | |
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt zbierania danych |
suma zł |
Struktura skrótów |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania struktury |
suma zł |
Przygotowanie panelu administracyjnego |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania panelu |
suma zł |
Przygotowanie panelu logowania |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania panelu |
suma zł |
Testowanie oprogramowania |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt testowania |
suma zł |
Zarządzanie projektem |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt zarządzania projektem |
suma zł |
Koszty administracyjno-biurowe |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt |
suma zł |
Dystrybucja |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt dystrybucji |
suma zł |
Instrukcja użytkownika |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt przygotowania instrukcji użytkownika |
suma zł |
Podróże | |
Hotel | |
Bilety lotnicze | |
Bilety kolejowe | |
Transport samochodowy | |
Taksówki | |
Parkingi | |
Diety | |
Całkowita suma godzin spędzonych w podróżach | suma godzin |
Całkowity koszt podróży | suma zł |
Inne koszty | |
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt |
suma zł |
Koszty stałe |
|
1. (nazwisko) x godzin po y zł = | |
2. (nazwisko) x godzin po y zł = | |
Całkowita suma godzin spędzonych nad sekcją | suma godzin |
Całkowity koszt |
suma zł |
Podatki | |
Suma składek podatkowych | |
Podsumowanie | |
Całkowita ilość spędzonych godzin | |
Całkowite wydatki bez pensji. | |
Całkowite wydatki na zatrudnienie z pensjami. | |
Całkowite wydatki stałe | |
KOSZT PROJEKTU | |
Budżet - opis sekcji
Zapoznanie się z projektem
Szacowana ilość godzin potrzebnych do zebrania informacji dotyczących podstawowych
informacji projektowych (w tym treści szkolenia) otrzymanych od klienta/ lub
zebranie ich na własną rękę.
Przygotowanie dokumentu dot.
Standardów projektu
Szacowana ilość godzin potrzebna do stworzenia dokumentu dot. Standardów, jakimi
będzie kierował się zespół projektowy.
Przygotowanie skryptów
Szacowana ilość godzin potrzebna do przygotowania skryptu zawierającego treść
szkolenia. Ten dokument powinien zostać zaaprobowany przez klienta. W przyszłości
posłuży jako podstawa dla programistów i projektantów podczas produkcji szkolenia.
Przygotowanie ekranów szkolenia
Oszacowanie ilości ekranów edycyjnych, jakie finalny produkt będzie zawierał.
Ekrany warto podzielić pod względem pracochłonności. Ekrany zawierające prosty
tekst są dużo mniej pracochłonne niż te, które zawierają grafikę, animację. Najtrudniejsze
będą prawdopodobnie ekrany interaktywne, testy, egzaminy.
Przygotowanie symulatorów porównawczych
W przypadku kursów, które mają za zadanie nauczyć pracy z szczególnym oprogramowaniem,
urządzeniem, a także z zaawansowanym system (np. bankowym, giełdowym) konieczne
stanie się zrozumienie przedmiotu nauki. W takich przypadkach będziemy potrzebowali
symulatorów, które wykorzystamy w kursie w celu odzwierciedlenia prawdziwych
urządzeń lub systemów.
Grafika
Szata graficzna jest częstym punktem spornym pomiędzy projektantami a klientem.
Klient często nie wie jak ma wyglądać jego wymarzony produkt. Najczęściej chciałby
abyśmy wielokrotnie zmieniali projekt, wracali do poprzednich koncepcji. Aby
tego uniknąć warto proponować klientowi kilka rozwiązań a następnie prosić go
o wybranie najbardziej mu odpowiadającej. Pamiętajmy, aby prosić o podpisanie
wybranego rozwiązania.
Czas pracy nad obiektami graficznymi warto podzielić na kilka pod rodzajów.
Z pewnością wiele obiektów będzie wymagało od nas nie wiele wysiłku. Do trudniejszych
możemy zaliczyć wszelkie animacje i duże grafiki.
Nasze oszacowanie pomoże także w rozmowie z klientem. W przypadku negocjacji
naszej oferty będziemy mogli np. zaproponować zmianę ilości ekranów bogatych
w grafiki, zastosowanie elementów typu clip art. Lub zrezygnowania z części
animacji.
Klipy Video
Koszt wyprodukowania dobrego materiału filmowego jest bardzo drogi. Warto dowiedzieć
się czy nasz klient nie posiada jużnagrań, które mógłby udostępnić. W przypadku
produkcji nowych klipów należy pamiętać o wycenie gaży, jaką zaproponujemy aktorom.
Niezależnie przy klipy tworzymy sami, czy też korzystamy z materiałów dostarczonych
przez klienta należ y pamiętać o dodaniu kosztów edycji i digitalizacji materiału
filmowego.
Audio
Dźwięk powinien być nieodzowną częścią większości prezentacji i szkoleń. Do
audio zaliczymy ścieżkę dźwiękową, którą możemy dodać do naszego szkolenia, wszystkie
odgłosy przycisków oraz głos lektora, który będzie prowadził szkolenie.
Interakcje
Do tej kategorii zaliczymy wszystkie fragmenty szkolenia w których program będzie
komunikował się bezpośrednio z uczącym. Przykładem takich zachowań będą: egzaminy
i testy, gry on-line, symulatory. Z reguły zaplanowanie i zbudowanie takich
obiektów zajmuje o wiele więcej czasu niż typowych ekranów graficznych. Często
nasz klient chciałby także znać statystykę poprawnych i błędnych odpowiedzi,
czasu wykonania zadania.
(patrz Zbieranie danych).
Kolektor Danych
Oszacowanie czasu potrzebnego na przygotowanie struktury za pomocą której będziemy
mogli generować dane dla klienta i użytkownika. Dane takie możemy chcieć pokazywać
użytkownikowi - wskazując na ilość poprawnych i błędnych odpowiedzi. Klientowi
- informując go o ilości osób które już odbyły szkolenie.
Struktura skrótów
Szacowana ilość godzin potrzebnych do zbudowania skrótów pomiędzy poszczególnymi
tematami, definicjami, testami i zadaniami.
Przygotowanie panelu administracyjnego
Szacowana ilość godzin potrzebnych do przygotowania centralnego panelu administratora,
przygotowania możliwości standardowego wydruku fragmentów szkolenia oraz sprawdzenia
spójności wszystkich części projektu.
Przygotowanie panelu logowania
Szacowana ilość godzin potrzebnych do stworzenia centralnego panelu logowania.
Nasz panel sterowania może być różnie zaprojektowany, zależnie od wymogów klienta.
Klient może posiadać scentralizowany dostęp do zasobów podczas pracy w Intranet.
W takim przypadku będziemy zobowiązani do powiązania naszego modułu z modułem
centralnym. W innych przypadkach możemy prosić o wypełnienie wniosku rejestracyjnego,
możemy także przygotować panel logowania z użyciem TOKEN'ów. Wymogiem szkolenia
może być także zbudowanie ograniczonego albo pełnego dostępu dla użytkowników
nie zarejestrowanych.
Testowanie oprogramowania
Szacowana ilość godzin potrzebnych do przeprowadzenia wszystkich faz testowania
oprogramowania. Począwszy od faz pośrednich, gdzie testowane są funkcjonalności
poszczególnych modułów, poprzez testy Alfa (wewnętrzne testy oprogramowania)
aż do finalnych Beta testów w których klient potwierdza wszystkie zamówione
funkcjonalności.
Pamiętajmy, aby nie doprowadzać do sytuacji, w której klient zetknie się ze szkoleniem
dopiero w fazie testów. Klient na bieżąco powinien sprawdzać i aprobować funkcjonalności.
Warto postarać się aby testy Beta były jedynie formalnością wieńczącą zakończenie
projektu.
Zarządzanie projektem
Szacowana ilość godzin które spędzimy nad szeroko pojętym zarządzaniem projektem.
W przypadku gdy koszty te ujęte zostaną w kosztach stałych możemy zostawić tę
sekcję pustą. Często organizację przeliczają koszty zarządzania projektem za
pomocą wskaźników procentowych. (np. po obliczeniu wszystkich kosztów projektów
dolicza się 30% wartości za prowadzenie projektu).
Koszty administracyjno - biurowe
W każdym projekcie zapewne będą koszty administracyjno
- biurowe. W przypadku gdy koszty administracyjne ujęte zostaną w kosztach stałych
możemy zostawić tę sekcję pustą.
Przygotowanie instalatora
Niezależnie od typu szkolenia powinniśmy zapewnić sobie czas na przygotowanie
instalatora. W przypadku aplikacji web'owej może to być moduł sprawdzający dostępność
wszystkich potrzebnych plug-in. W przypadku szkolenia w formie programu będzie
to typowy instalator. Przygotowanie instalatora może polegać także na dopasowaniu
rozdzielczości ekranu albo sprawdzenia posiadania odpowiednich komponentów hardware
potrzebnych do odbycia szkolenia.
Dystrybucja
Zależnie od typu szkolenia szeroko pojęta dystrybucja
może polegać na przygotowaniu 1000 kopi płyty DVD z przygotowanym i zatwierdzonym
szkoleniem. W przypadku projektów web'owych dystrybucja będzie polegała na monitorowaniu
procesu zamieszczenia w sieci szkolenia.
Instrukcja użytkownika
Poza dokumentami, które przygotujemy podczas pracy nad częścią techniczną projektu
nie wolno zapomnieć o jednym z podstawowych dokumentów jakim jest instrukcja
użytkownika. Instrukcja może być przygotowana w formie dokumentu papierowego,
może też być dokumentem elektronicznym z możliwością wydruku.
Inne koszty
Podczas pracy nad projektem może okazać się, że jakieś wydatki nie zostały przez
nas zabudżetowane. W tym celu warto wprowadzić trochę wolnych środków na niespodziewane
wydatki. (np. konsultacje z kolejnym ekspertem, zakup dodatkowego sprzętu lub
oprogramowania).
Koszty stałe
Wszelkie koszty, które zmuszony byłbyś ponieść nie
zależnie od projektu. Takimi kosztami są z reguły: zatrudnienie własnych pracowników,
świadczenia społeczne i emerytalne, abonament telefoniczny, wynajęcie biura.
W przypadku korporacji koszty stałe niosą nazwę "overhead" i są wyliczane
dla poszczególnych zaszeregowań. Koszty stałe możemy wpisać jako część kosztów
projektowych.
Podatki
Warto pamiętać o oszacowaniu kwoty którą powinniśmy
zwrócić Państwu w formie podatku.
Podsumowanie
W tej sekcji warto zsumować wszystkie wydatki które
zamierzamy ponieść. Warto podzielić sobie je na wydatki związane z zatrudnianiem
ludzi, oraz na wydatki na sprzęt, licencje i środki trwałe. Warto też policzyć
koszt projektu z zawarciem w nim kosztów stałych.
Szkice projektowe
We wstępnej fazie pracy nad projektem warto przygotować kilka projektów szkoleń.
Powinniśmy już mieć odpowiedzi na pytanie kim jest nasz użytkownik i czego według nas oczekuje.
Przygotowanie kilku wstępnych projektów wspomoże także klienta w podejmowaniu decyzji. Klienci często nie są w stanie dokładnie opisać swoich potrzeb a narzucenie odgórne naszej propozycji może w późniejszej fazie doprowadzić do konfliktów.
Co więc zrobić aby klient czuł, że brał udział w świadomym wyborze projektu? Jak doprowadzić do sytuacji, w której klient wybiera "nasz ulubiony" szkic?
W tym celu dobrze jest przygotować kilka szkiców projektowych. W każdym zawrzeć kluczowy dla klienta element. (ważne by nie były to wszystkie elementy). Wśród tych przykładowych projektów umieścimy nasz, który zgodnie ze wstępną specyfikacją powinien zawierać wiele kluczowych elementów. Podczas otwartej dyskusji z klientem będziemy wskazywać mocne i słabe strony każdego ze szkiców.
Klient prawie zawsze wskaże na nasz projekt podczas takiej sesji. Warto jednak zwrócić uwagę, że czasami klient zwraca nam uwagę na pewne elementy zawarte w pozostałych projektach i prosi o dodanie ich do wybranego przez siebie szkicu. Nie pozostaje nam wtedy nic innego jak delikatnie zmodyfikować projekt lub znaleźć dobry powód dla którego dane rozwiązanie nie powinno zostać wdrożone.
Określenie stylu projektu
Wraz z klientem możemy ustalić także formę w jakiej chcemy zwrócić się do użytkownika. (1 osoba, 3 osoba, liczba mnoga, liczba pojedyncza). W tym celu najlepiej określić dokładny styl językowy a w nim gramatykę i czasy.
Przypominamy także o określeniu języka, w jakim szkolenie ma zostać przeprowadzone.
Określenie i zebranie zasobów
Kolejnym elementem planowania projektu jest określenie i zebranie odpowiednich zasobów potrzebnych w czasie życia projektu. Zasoby możemy podzielić na trzy główne podgrupy:
Treść
Aby móc prawidłowo nauczać - czyli budować kursy e-learning'owe, musimy posiadać opowiednią wiedzę. Widza ta nie musi być w nas samych, musi być jednak dla nas dostępna.
Do prawidłowego operowania wiedzą potrzebujemy ekspretów oraz literaturę. Jeśli więc w naszym zespole nie ma osób, które w odpowiednim stopniu zgłębiły dziedzinę wiedzy która zamierzemy przekazać z pomoca kursu - należy takie osoby znaleść. W przypadku kiedy szkolenie jest na zamówienie klienta, możemy oczekiwać od niego przekazania nam kontaktu do espertów z poszczególnych dziedzin.
Drugim dobrym źródłem pozyskania treści jest literatura.
Innymi źródłami pozyskania treści mógłbyć: słuchowiska radiowe, programy telewizyjne, materiały treningowe, skrypty inne programy multimedialne, i wiele wiele innych.
Umiejętności projektowe
Podczas planowania złożoności projektu zwracaliśmy uwagę na wybór odpowiednich grafik, animacji, filmów. Do wszystkich tych czynności potrzebne są specyficzne umiejętności. Nasi programiści muszą posiadać odpowiednią wiedzę, by móc podczas fazy produkcji wytworzyć odpowiednie fragmenty szkolenia. Być może nie znamy wszystkich talentów naszych pracowników. Warto więc dowiedzieć się czegoś wiecej o posiadanych przez nich umiejętnościach. Ta wiedza pozwoli nam także minimalizować koszty. Dzięki niej będziemy wiedzieli które fragmenty szkolenia będziemy mogli przygotować w oparciu o swoją organizację, a które zamówić u zewnętrznej firmy.
Zasób technologiczne
Znamy już nasze umiejętności. Jednak czy wszystkie możemy
wykorzystać w pracy nad kursem e-learning'owym?
Nasze zasoby techonologiczne to przede wszystkim posiadane przez nas oprogramowanie
- które jesteśmy w stanie prawidłowo używać.
Oprogramowanie do przetwarzania grafik, video i dziwięku jest z reguły bardzo
drogie, dlatego decydując się na jego zakup powinniśmy sprawdzić czy posiadamy
odpowiednie umiejętności by się nim posługiwać. W tym celu możemy także dodatkowo
wyedukować naszych pracowników.
Wstępna burza mózgów
Burza mózgów jest procesem w którym możemy odkryć wiele
ciekawych pomysłów dotyczących naszego projektu. Podstawową cechą burzy mózgów
jest generowanie bardzo wielu pomysłów, nie zważając na ich jakość oraz możliwość
wykonania.
Wstępna burza mózgów powinna odbyć się w fazie planowania, ponieważ wierzymy,
że najlepsze pomysły zdecydowanie częściej przychodzą do głowy na początku trwania
projektu, niżeli na jego końcu.
Wstępną burzę mózgów warto odbywać nielicznych grupach. Cztery - pięć osób powinno być odpowiednią ilością. Warto w takich małych grupach mieszać pracowników posiadających różne kwalifikacje, zawody. Dobre efekty przynosi wprowadzenie do grupy aktorów, malarzy.
W późniejszej pracy projektowej poczas burzy mózgów będziemy kwalifikować i dzielić pomysły. Teraz naszym głównym celem jest stymulowanie zespołu do bardziej kreatywnej pracy. Takie działanie zabezpiecza nas przed koniecznością pracy nad prostymi i mało oryginalnymi pomysłami. Burze mózgów produkują zaskakującą ilość dobrych i oryginalnych pomysłów.
Burzę mózgu można rozpocząć w niewielkim pomieszczeniu, partycypanci mogą siedzieć np, na przeciwko siebie w około niewielkiego stolika. Pomysły warto zapisywać np. na dużej tablicy - tak by każdy miał ich graficzny obraz. Proces generowania pomysłów rozpoczyna się wraz z opowiedzeniem pierwszego pomysłu. Z czasem członkowie grupy zaczną przytaczać inne pomysły. Odwrotności, modyfikacje lub kompletnie nowe pomysły. Pomysł nie musi dotyczyć całego projektu, może dotyczyć realizacji jego pewnych aspektów, techonologii, interfejsów graficznych. Burzy mózgów nie należy kończyć zbyt wcześnie. Często zespól "rozgrzewa się" bardzo długo, by wygenerować najlepsze pomysły gwałtownie tuż pod koniec swojej pracy. Proces powinniśmy zakończyć w chwili, gdy przez kilka pomysłów dyskusja się już nie odbywa lub kolejne wypowiedzi są powtórzonymi poprzednimi.
Niniejszy dokument przybliża sposób prowadznia projektu eLearningowego, opisują fazę planowania projektu eLearningowego.
Zarządzenie Projektem |
Zarzadzanie projektem jest to zbiór czynności
wykonywanych w celu osiagnięcia wyznaczonych celów. Zawiera sie w nim
planowanie, harmonogramowanie i utrzymywanie postępów w czynnościach składających
się na projekt. Najprościej można także powiedzieć, iż jest to nauka o
utrzymywaniu ryzyka porażki na możliwie niskim poziomie w całym cyklu
życia projektu. Ryzyko to bierze się głównie z niepewności związanej z
przyszłymi wydarzeniami na każdym etapie przedsięwzięcia. Z innego punktu widzenia, zarzadzanie projektem można zdefiniować, jako
naukę o definiowaniu i osiąganiu celów przy jednoczesnej optymalizacji
użycia zasobów (np. czasu, pieniedzy, ludzi, itd.). Zarzadzanie projektem to pole działania i odpowiedzialności jednej osoby,
zwanej menadżerem projektu. Taka osoba rzadko uczestniczy bezposrednio
w czynnościach, które prowadzą do doprowadzenia projektu do celu, lecz
raczej sluży jako koordynator, którego zadaniem jest utrzymanie postepów
i współpracy pomiędzy członkami projektu w taki sposób, by zredukować
całkowite ryzyko porażki. W języku polskim przyjeły się głównie dwie nazwy okreslające tą samą
dziedzinę wiedzy, zarządzanie projektami (zamiast zarządzania projektem)
oraz zarządzanie przedsięwzieciami, z czego to pierwsze cieszy się największą
popularnością. Wsród osób zajmujących sie tą nauką zawodowo dużym powodzeniem
cieszy się także angielskojęzyczne sformułowanie Project Management. |
Standard
|
Wspólnie ustalone kryterium, które okresla powszechne, zwykle najbardziej pożadane cechy czegoś, np. wytwarzanego przedmiotu (np. standardem jest, ze każdy współczesnie wytwarzany telewizor wyświetla kolory) czy ludzkiego zachowania (norma kulturowa). Standard to czasem takze podstawowa, najprostsza wersja produktu.
Standard w tym ujeciu jest kryterium, którego nie można zmierzyć (można zmierzyć pewne cechy kryterium, jak np. dopuszczalna dlugość telefonu komórkowego itp., ale samego standardu dokładnie zmierzyć sie nie da), jest płynna granica ustalana na bieżąco zarówno przez grupy konsumenckie, jak i osobnych odbiorców.
|
Organizacja wirtualna | Nowy typ organizacji charakterystyczny dla wielkich korporacji charakteryzujacy sie tym, ze nie posiadają one własnych srodków produkcji w postaci zakładów produkcyjnych czy nawet pracowników, natomiast wynajmują zewnętrznych podwykonawców, którzy realizują cele organizacji. Zazwyczaj są to organizacje dysponujące znacznym kapitałem i mające już
duże uznanie na rynku. Jej działanie ogranicza się do nadawania produktom
swojej marki, przy czym proces produkcji nie jest przez tego typu organizację
kontrolowany. Charakterystyczna dla tego typu organizacji jest elastycznośc
przy wyborze podwykonawców w skali globalnej i stosunko łatwa delokalizacja
kapitału. Zazwyczaj dla potanienia kosztów produkcji organizacje tego
typu poszukują coraz tańszej siły roboczej w różnych regionach świata,
bardzo często lokując w końcu fabryki w krajach Trzeciego Świata. Naomi
Klein w swojej pozycji No Logo ostro skrytykowała tego typu organizacje,
między innymi firmy Reebok, Nike, czy Microsoft za brak odpowiedzialności
za warunki pracy oferowanych przez podwykonawców wynajmowanych przez te
firmy. |
Planowanie | Faza projektu w której badamy własne zasoby, przygotowujemy ofertę, nakreślamy budżet. |
Klient |
Osoba lub organizacja dla której świadczona jest usługa. Klient wewnętrzny - to osoba lub organizacja zamawiająca usługę znajdująca się w tej samej firmie. W przypadku gdy oprogramowanie tworzymy dla siebie, stajemy się klientem wewnętrznym. Klient jest osobą opłacającą projekt. |
Użytkownik
|
Osoba lub grupa osób, które finalnie będą użytkowały oprogramowanie. Użytkownikem szkolenia eLearningowego może być wyspecjalizowana grupa ludzi, lub też bliżej nieokreślona. Np. segment rynku lub "wszyscy studenci" |
Nauka w trybie mieszanym (blended-learning) |
Ten terminy zamiennie opisują podejście do kształcenia, w którym łączy się metodę w klasie i metodę na odległość, w której instruktor lub tutor spotyka się ze swoimi uczniami (albo metodą twarzą w twarz, albo przy użyciu środków technicznych), a baza zasobów zawierająca materiały i ćwiczenia jest udostępniana uczniom. Dodatkowo mógłbyć wykorzystywane niektóre z metod eLearning. |
System Zarządzania Uczeniem się (Learning Management System) |
Zestaw narzędzi eLearningowych dostępnych poprzez wspólny administrowany interfejs. System zarządzania uczeniem się może być traktowany jako platforma na której zbiera się i używa kursów on-line i komponentów kursów. |
Komunikacja synchroniczna |
Komunikacja w czasie rzeczywistym (np. chat). |
Komunikacja asynchroniczna |
Komunikacja w czasie opóźnionym (np. email). |
Literatura podstawowa i poszerzająca
Portal Wikipedia - www.wikipedia.pl |
Alessi Stephen M., Trollip Stanley R. (2001) "Multimedia for Learning - Methods and Development" |
Rosenberg Marc J. (2001) "E-Learning - Building successful online learning in Your organization - strategies for delivering knowladge in the digital age" |
Schank, Roger C. (2002) "Designing World-Class E-learning" |
Kitaoka Vance,Shea Andrea,Uehara Randal (1998) "Creating a Storyboard for Video Production" www2.hawaii.edu/~ricky/etec/storyboarding.html |
Oprogramowanie do tworzenia
Storyboard |
Kruse Kevin "Creating
Scripts and Storyboards for e-Learning" |
Czym różni się prowadzenie zwykłego projektu od projektu eLearningowego?
Jak mierzyć koszty projektu eLearningowego przygotowywanego na własne potrzeby?