Projekty biznesowe, w tym projekty informatyczne, służą
wprowadzaniu zmian w firmie.
Z tego powodu ich realizacja wymaga należytego traktowania w
przedsiębiorstwie i jest zagadnieniem szczególnie ważnym -
oddziałuje bowiem na zasoby firmy przeznaczone do projektu
i ma wpływ na późniejsze działanie firmy po zakończeniu
projektu (wprowadzeniu zmiany).
Rola projektów winna być w odpowiedni sposób umiejscowiona
w strategii przedsiębiorstwa, tak, aby wychodząc z tej strategii,
planować, organizować i realizować projekty biznesowe, czyli
skutecznie wprowadzać zmiany w przedsiębiorstwie.
PROJEKT
(definicja wg British Standards 6079):
niepowtarzalny zestaw skoordynowanych działań o określonych punktach początkowym i końcowym, podejmowanych przez jednostkę lub organizację dla zrealizowania określonych celów, przy określonych parametrach, odnoszących się do czasu, kosztów i efektów.
Projekt powinien mieć ściśle określone:
cele do osiągnięcia,
zakres (produkty i usługi),
czas realizacji wraz harmonogramem,
budżet,
inne zasoby (m.in. ludzkie), niezbędne do realizacji,
jakość,
analizę ryzyka.
Klasyczne standardy zarządzania obejmujące:
planowanie,
organizowanie,
delegowanie,
kontrolę,
motywowanie i szkolenie,
nie spełniają wprost wymogów projektów.
ZARZĄDZANIE PROJEKTEM
(definicja wg British Standards 6079):
jest to planowanie, monitorowanie i nadzorowanie wszelkich aspektów projektu oraz motywowanie wszystkich osób, zaangażowanych w przedsięwzięcie, z wykorzystaniem wiedzy odpowiednich narzędzi i technik w celu osiągnięcia założonych celów projektu terminowo i zgodnie z założonymi kosztami, jakością i skutecznością.
Projekt informatyczny ma dwa wymiary:
zarządczy (procesy kierownicze),
produkcyjny (procesy wytwórcze).
Za pierwszy odpowiadają kierownicy projektu,
za drugi kierownicy zespołów informatyków.
Procesy kierownicze:
Planowanie projektu
Kosztorysowanie projektu
Tworzenie harmonogramu
Organizowanie zespołów
Przygotowanie kontraktu
Zarządzanie zmianami
Zarządzanie jakością
Zarządzanie ryzykiem
Zarządzanie komunikacją
Procesy produkcyjne:
Specyfikacja wymagań
Specyfikacja architektury
Analiza wymagań
Projektowanie systemu
Implementacja
Integracja i testowanie
Instalacja
Szkolenia i wdrożenie
Pielęgnacja systemu
Rodzaje projektów informatycznych:
Produkcja oprogramowania
Integracja systemowa
Usługi instalacyjne
Usługi serwisowe (serwis sprzętu i pielęgnacja oprogramowania)
Usługi wdrożeniowe
...
jakie jeszcze?
Cykl życia projektu
(procesy produkcyjne)
określenie wymagań
projektowanie
implementacja
testowanie
eksploatacja
Projekt informatyczny zawsze oznacza nową sytuację, nieznane warunki realizacji, a także bardzo ograniczony zakres i przydatność doświadczeń.
Sformalizowane gromadzenie, analizowanie i wykorzystywanie najlepszych praktyk projektowych - najlepszy sposób na wypracowanie i twórcze zastosowanie własnej metodyki produkcji oprogramowania, jego wdrożenia i pielęgnowania.
Czynniki ryzyka:
- brak zaangażowania zarządu,
- niejasne określenie wymagań przez użytkownika
(słabo zdefiniowany zakres prac),
- klient nie przygotowany do swojej roli,
- brak oceny ryzyka i planów awaryjnych,
- niewłaściwy proces wprowadzania zmian i brak
marginesu bezpieczeństwa (budżet na zmiany: 5...25%),
- zmieniająca się struktura organizacyjna,
- zmieniające się przepisy prawne,
- nieumiejętność wybrania odpowiedniej technologii
informatycznej,
- niezadawalający przebieg procesu tworzenia systemu,
- niedostateczne wytestowanie.
Największym zagrożeniem projektów informatycznych są ludzie:
- informatycy wszystko
wiedzą,
- użytkownicy cudu
oczekują.
Elementy dobrej praktyki:
Dokumentacja inicjująca projekt powinna zawierać co najmniej:
- określenie celu biznesowego projektu wraz z uzasadnieniem,
- opis organizacji zespołu projektowego,
- definicję zakresu przedsięwzięcia (produkty i usługi),
- dokumentację koncepcji technicznej,
- plan projektu,
- plan zapewnienia jakości,
- procedury kontroli i raportowania przebiegu prac,
- ocenę ryzyka.
Dokumentacja musi objąć cztery główne wymiary projektu: zakres, czas, budżet i jakość.
Typowa struktura organizacyjna:
- Sponsor Projektu,
- Komitet Sterujący,
- Szef Projektu,
- Zespoły techniczne,
- Komitet Kontroli Zmian.
Zależnie od skali i potrzeb danego projektu zaleca się rozważenie potrzeby określania dalszych ról:
- Szef Projektu ze strony klienta,
- Szefowie zespołów technicznych,
- Komitet Akceptacyjny i zespoły do spraw testów akceptacyjnych,
- Szef Jakości,
- Biuro Projektu.
W projektach mniejszych, nie wymagających licznej obsady kadrowej, należy dążyć do maksymalnego uproszczenia struktury organizacyjnej.
W dużych projektach koszty zarządzania projektem mogą osiągać nawet 20-50% łącznego budżetu projektu.
Komitet Sterujący Projektu:
- przewodniczący Ktoś z zarządu,
- sponsor Ktoś z zarządu (odpowiedzialny za budżet projektu),
- członkowie Dyrektorzy najważniejszych departamentów Dyrektor departamentu informatyki, przedstawiciele Wykonawcy.
Szef Projektu
pełni kluczową rolą w całym przedsięwzięciu.
Co raz częściej powołuje się dwóch Szefów: ze strony dostawcy i klienta. Wspólnie tworzą oni Zarząd Projektu - operacyjną komórkę, kierującą pracą wszystkich zespołów.
Według British Standard (BS 4335:1987)
Szefem Projektu jest osoba, której przekazano uprawnienia i odpowiedzialność w celu ogólnego zarządzania zasobami projektu (w aspektach technicznych i kosztowych) oraz motywowania wszystkich zainteresowanych.
Elementy dobrej praktyki:
W metodyce PRINCE 2 dokument inicjująca projekt ang. PID - Project Initiation Document ma następującą strukturę:
1. Cel dokumentu
Co projekt ma osiągnąć?
Dlaczego osiągnięcie tych celów jest istotne?
Kto będzie realizował zarządzanie projektem (role i zakresy odpowiedzialności)?
Jak i kiedy omówione tu przygotowania zostaną zrealizowane?
2. Tło projektu
Wszelkie źródła przedsięwzięcia, poprzednie raporty czy dokumentacja, jakie mogą wpływać na prace projektowe, inne powiązane projekty.
3. Cele projektu
Konkretnie i mierzalne. Warto rozdzielić cele projektu (np. oczekiwane daty, profil wydatków) i jego wyniki (co ma być rezultatem produktów końcowych projektu podczas ich użytkowania po zakończeniu prac)
4. Zakres, wyłączenia, interfejsy
Zakres to główne obszary, funkcje, procesy itp., jakie mają być objęte projektem. Wyłączenia i interfejsy opisują, co znajduje się w projekcie, a co pozostaje poza nim. Interfejsy to logiczne powiązania z innymi działaniami, np. sposób wykorzystania tworzonych informacji, dalszy rozwój powstałych produktów itp.
5. Produkty
Lista oczekiwanych i pożądanych produktów, rezultatów, wyników, jakie projekt winien stworzyć lub uzyskać.
6. Korzyści biznesowe
Powody podjęcia projektu - z punktu widzenia osób finansujących działania. Projekt powinien być mierzony również w zakresie korzyści biznesowych, do czego niezbędna jest Analiza Kosztów i Korzyści.
7. Ograniczenia i zagrożenia
Ograniczenia pod względem czasu, zasobów, funduszy i akceptacji. Jest to określenie zasobów projektu, do których nie może on sięgnąć. Uzupełnienie ograniczeń i wyłączeń, szczególnie odnośnie sfery biznesowej. Wszelkie inne założenia przyjęte w związku z realizacją projektu.
8. Organizacja projektu
Wskazanie osób tworzących Zespół Zarządzania Projektem - Szefa Projektu, Komitetu Sterującego, Audytora-Szefa Jakości, Szefów Zespołów. Dla każdej z tych ról koniecznie trzeba wskazać zakresy odpowiedzialności.
9. Plan Jakości
Opis podejścia stosowanego przez zespół wykonawczy dla dostarczenia produktów spełniających oczekiwania jakościowe użytkowników. Często wskazuje się tu standardy jakościowe dostawcy.
10. Kryteria akceptacji
Zdefiniowanie w kategoriach mierzalnych wszystkiego, co ma powstać jako rezultaty projektu.
11. Plan Projektu
Zestawienie głównych produktów, działań i zasobów niezbędnych dla uzyskania oczekiwanych wyników projektu. Plan Projektu jest podstawą nadzorowania postępu i kosztów w każdym etapie prac.
12. Sposoby Kontroli Projektu
Częstotliwość oczekiwanych przeglądów przez Kierownictwo. Przeglądy te w postaci Ocen Zakończenia Etapów mają na celu przegląd projektu w jego ważnych momentach (ang. milestones) dla zatwierdzenia już wykonanych prac i przyznania zasobów na kolejny etap. Trzeba też opisać organizację raportowania bieżącego (format, przeznaczenie, częstotliwość): wykonawców dla klienta/użytkownika, zespołów wykonawczych dla Szefa Projektu itd.
13. Obsługa problemów i zarządzanie zmianami Wskazanie dopuszczalnej tolerancji projektu, opis Procedury Obsługi Problemów do stosowania przy wystąpieniu odchyleń od przyjętego planu. Zalecane jest też przygotowanie szczegółowej procedury Kontroli Zmian.
14. Plany awaryjne.
Określenie planów awaryjnych, jakie zostały przewidziane w planach projektu. Powinny one być uzupełnione Analizą Ryzyka.
Tutaj:
Podpis Szefa Projektu: ....
Podpis Klienta/Użytkownika: ...
Podpis Przewodniczącego Komitetu Sterującego .......
Data: ...
PLANOWANIE.
Bywa, że zarządzanie projektem sprowadza się po prostu do obsługi jego planów. Takie zwężenie zagadnienia jest fatalnym błędem, o opłakanych skutkach dla powodzenia przedsięwzięcia.
Planowanie istotnie jest niezwykle ważną częścią pracy Szefa Projektu - dlatego niezbędne jest nabycie przez niego odpowiedniej wiedzy, zagadnień, technik i problemów z obszaru planowania projektu.
Plan projektu to:
- racjonalny opis zadania i sposobu jego wykonania,
- narzędzie do osiągania celu (pomiar, korekty),
- „mapa przyszłości” - obraz tego, czego należy oczekiwać
w projekcie,
- narzędzie „kupowania” sponsora i zespołu - sposób
pozyskiwania zaufania i współpracy.
Od strony technicznej planowanie stanowi:
- narzędzie koordynacji działań zespołu i podwykonawców,
- sposób koordynowania posiadanych zasobów,
- podstawę mierzenia postępu i kontrolowania projektu,
- podstawę kontroli zmian,
Plan służy do:
-Planowania zasobów
-planowania kosztów
-kontroli postępu
-rozliczenia się z pracy
Techniki planowania
Najbardziej znanym wymiarem planowania jest planowanie działań i czasu. Wykonuje się to przy użyciu rozmaitych technik, z których najbardziej popularne to:
- WBS - struktura działań (ang. Work Break- Down Structure),
- Sieć PERT - schemat powiązanych działań,
- Wykres Gantta.
Diagram PERT
Przy pomocy tej techniki wygodnie jest prowadzić analizę tzw. ścieżki krytycznej, czyli zestawu kolejnych czynności, których łączny czas realizacji daje najdłuższy przebieg w projekcie. Sieć daje również przejrzysty obraz zależności między poszczególnymi działaniami.
Planowanie Według Produktów
polega na rozpoczęciu planowania od określenia produktów projektu: najpierw produktów głównych/końcowych (zwykle wymienianych w kontrakcie lub innych dokumentach projektu), następnie produktów pośrednich (niezbędnych do wytworzenia produktów końcowych), ewentualnie również produktów technicznych, nie wymaganych przez klienta/odbiorcę.
Z kolei dla każdego produktu określa się zestaw czynności i działań prowadzących do jego wytworzenia. Po ustaleniu działań
- w postaci prostej listy - należy wzbogacić ją o zależności
i przekształcić w listę hierarchiczną, a następnie umieścić ją
w kalendarzu projektu, uzupełnić o zasoby realizacyjne,
skorygować harmonogram o dostępność zasobów itd.
Szacowanie projektu.
Oszacowaniu w projekcie informatycznym podlega wiele rzeczy - począwszy od najbardziej naturalnych, takich jak: pracochłonność, wydajność pracownika, wielkość zatrudnienia w każdej fazie projektu, koszty w różnych przekrojach i czasie, zasoby materialne potrzebne do realizacji projektu (urządzenia i ich obciążenie, materiały, itp.), aż po mniej oczywiste: straty czasu na działania nieprodukcyjne, kwalifikacje pracowników, jakość dostaw i obsługi, zagrożenia realizacji projektu. Nawet takie elementy, jak założenia, według których realizowany jest projekt, są w wielu przypadkach jedynie szacunkiem. Szacuje się ponadto czas pracy w firmie (nie zawsze jest to równo osiem godzin), liczbę podróży służbowych do klienta, czas dojazdu, itp.
Metody szacowania projektów
Szacowanie zasobów w projektach informatycznych jest kombinacją dobrych danych historycznych (doświadczeń) i metod ich wykorzystania w nowych przypadkach. Metody są różne i zwykle wykorzystywane są łącznie, tj. do oszacowania zasobów projektu wykorzystuje się równocześnie dwie metody lub więcej. Można wyróżnić następujące możliwe sposoby szacowania zasobów projektów informatycznych:
poprzez analogię,
metody dekompozycyjne,
ekstrapolacja przy pomocy różnych empirycznych modeli parametrycznych:
model „linii kodu” firmy IBM,
metoda punktów funkcyjnych (ang. FPs - Function Points) i jej liczne modyfikacje,
model COCOMO.
Typowe straty czasu związane z realizacją projektu to:
podróże,
spotkania,
komunikacja w zespole,
problemy z dostępem do projektu wspólnych zasobów,
powtórne wykonywanie prac,
bezwładność pracowników (np. krzywa uczenia się)
brak motywacji pracowników.
Pamiętaj o regule 40-20-40:
- 40% czasu projektu powinno zajmować planowanie, analiza wymagań i projekt systemu,
- 20% czasu - kodowanie,
- a pozostałe 40% - testowanie i pielęgnacja.
Nie kieruj nowych pracowników do spóźnionego projektu, bo zakończy się on jeszcze później.
(prawo Brooksa - przyczyn należy szukać w zwiększeniu strat czasu na komunikację pomiędzy członkami zespołu z jednej strony i niepodzielnością pewnych prac - z drugiej)
Procedury kontroli i moment ich wystąpienia w projekcie powinny być opisane w Planie Projektu.
Ustanowienie procedur kontroli to opisanie:
kto i kiedy uruchamia procedurę kontroli,
kto i kiedy zatwierdza wyniki kontroli,
kto, kiedy i jak wprowadza zmiany w projekcie, wynikające z wniosków z przeprowadzonej kontroli.
Kontrola postępu prac, poprzez:
raporty okresowe:
tygodniowe, miesięczne, kwartalne, z zakończenia fazy/etapu, notatki ze spotkań Zarządu Projektu i Komitetu Sterującego
raporty z przeglądów (przewidzianych w Planie Projektu):
z testowania, z przeglądu dokumentacji,
z Przeglądu Jakości, raporty z Audytu itd.
raporty problemowe (nie przewidziane w planie)
notatki ze spotkań roboczych
Kontrola produktu.
Przeglądy produktów projektu na różnych etapach jego realizacji:
- wyników analizy,
- projektu systemu,
- kodu programów,
- procesu testowania,
- instalacji,
- wdrożenia systemu i szkolenia użytkownika,
- pielęgnacji systemu.
Testowanie oprogramowania (oczywiście opis wymagań użytkownika stanowi podstawę do testowania):
- iteracyjne,
- wstępujące i zstępujące,
- funkcyjne (śledzenie wymagań),
- testowanie regeneracji (symulowanie awarii)
- efektywności (wielkość zbiorów, czas odpowiedzi)
- wyczerpujące (wszelkie możliwe dane i sytuacje), ale jest niewykonalne! Wojny Gwiezdne
Plan testów oprogramowania zawiera:
- Cel testowania (co jest testowane i po co?)
- Miejsce i termin testu (gdzie i kiedy?)
- Opis testu (opis danych testowych wejść i wyjść)
- Procedury testowania (jak przeprowadzić test?)
a Raport z testów zawiera:
- Protokół z decyzjami (do uzupełnienia, do poprawy, brak funkcji) wraz z werdyktem
- Listę problemów wymagających uwagi
Jakość w projekcie
Nie może zapewnić jakości
w projekcie bez efektywnego zarządzania
Poul Beynon-Davies.
Cechy opisujące jakość SI nie są i nie mogą być jednorodne.
Model jakości oprogramowania MacCalla:
1. Działanie (funkcjonowanie) programu
2. Modyfikowalność programu
3. Mobilność programu
Innym modelem jest drzewo jakości wg Brinkwortha:
1. Cechy funkcjonalne
1.1. Widoczne dla użytkownika
- funkcjonalność
- raportowanie działań
- słownictwo
- samokontrola
- odporność na błędy
- zrozumiałość
1.2. Ukryte przed użytkownikiem
- jakość modelu danych
- integralność danych
- testowalność
- gotowość
2. Cechy niefunkcjonalne
2.1. Widoczne dla użytkownika
- wydajność
- pojemność
- interfejs
- wspomaganie
- dostępność
- archiwizowalność
- zabezpieczenia
2.2. Ukryte przed użytkownikiem
- przenośność
- wydajność
- bezpieczeństwo
- rozszerzalność
- konfigurowalność
- modyfikowalność
- możliwość ponownego użycia
Normy jakości oprogramowania
Norma międzynarodowa ISO 9000-3: „The Application of ISO 9001 to Software”
Wytyczne do stosowania normy ISO-9001 podczas opracowywania, dostarczania i obsługiwania oprogramowania
(PN-ISO 9000-3: 1994)
Plan Jakości
za jego realizację odpowiedzialni są WSZYSCY członkowie
zespołu projektowego - zarówno po stronie klienta,jak i dostawcy.
Zgodnie z teorią TQM (kompleksowe zarządzanie jakością, ang. Total Quality Management) jakość dotyczy kultury CAŁEJ organizacji.
Jednym z elementów tej metody jest ciągłe usprawnianie procesów - na pierwszym planie znajdują się nie stanowiska zajmowane przez pracowników, lecz realizowane przez nich działania. W. Edwards Deming zaproponował, żeby wprowadzać ciągłe zmiany w firmie, nakierowane na jakość, zgodnie z cyklem PDCA (ang. Plan-Do-Check-Act, tzw. KOŁO DEMINGA). Zarządzanie procesami rozumiane jest jako systematyczne, strukturalne podejście do analizy ciągłego usprawniania i kontroli działań w celu zwiększenia jakości produktów i usług.
Plan Jakości powinien zawierać m.in.:
opis sposobu realizacji polityki jakościowej klienta,
opis systemu zapewnienia jakości, czyli jego struktury, podziału odpowiedzialności, procedur i potrzebnych zasobów,
zestaw przyjętych kryteriów jakości i metryk, służących do monitorowania i oceny,
przyjęte standardy, normy, wytyczne itp.
plan działań weryfikacyjnych i walidacyjnych w trakcie projektu
plan przeglądów projektu
ustalenie kryteriów jakościowych dla wszystkich produktów projektu, tzw. quality gates
plan obsługi sytuacji wyjątkowych i losowych
opis warunków współpracy z poddostawcami, gwarantujących wysoką jakość
Szef Jakości - zarządzanie jakością.
Szef Jakości powinien być mianowany przez Komitet Sterujący i jemu też podlega. Jego praca nie ma charakteru kontrolera Szefa Projektu. W poprawnie zdefiniowanych projektach obaj Szefowie ściśle współpracują ze sobą, wspólnie przyczyniając się do sukcesu przedsięwzięcia.
Kompetencji Szefa Jakości podlegają wszystkie zagadnienia związane z projektem w kontekście jakości: plany i wszelka dokumentacja zarządcza, tworzone produkty i ich testy, praca zespołów technicznych i kontakty z poddostawcami, gospodarka finansowa i zarządzanie ryzykiem. Mimo tak szerokiego opisania roli Szefa Jakości nie jest to zwykle praca „na pełny etat”.
Każde wprowadzanie zmian, czyli realizacja projektu, jest ryzykowne - może być szansą lub stać się zagrożeniem.
Ta oczywista prawda musi przekładać się na pragmatykę zarządzania przedsięwzięciami - jeżeli uzna się występowanie zagrożeń, to należy uwzględnić dotychczasowe doświadczenia projektowe i nie rozpoczynać przedsięwzięcia bez analizy ryzyka.
Typowy proces zarządzania ryzykiem wyróżnia zwykle fazy:
IDENTYFIKACJI, ANALIZY I KONTROLI RYZYKA.
W procesie identyfikacji ryzyka posługujemy się najczęściej następującymi narzędziami:
wywiady z udziałowcami,
kwestionariusze kontrolne (ang. checklists),
przeglądy i audyty produktów oraz procesów,
zgłoszenia indywidualne,
dotychczasowe doświadczenie i baza wiedzy.
Analiza ryzyka
dostarcza informacji (ilościowego oszacowania niepożądanych skutków), pozwalających na podjęcie decyzji, co do sposobu ograniczenia ryzyka.
Powszechnie używaną miarą ryzyka jest spodziewana wartość kosztowa, jako iloczyn:
ryzyko = prawdopodobieństwo * skutek
Kontrola ryzyka w projekcie to proces nieustannego:
sprawdzania i korygowania odstępstw od planów projektu,
wykrywania pierwszych symptomów ryzyka,
doskonalenie procesów zarządzania.
Przede wszystkim należy jednak zaakceptować fakt istnienia ryzyka niepowodzenia projektu.
Nie ma też prostej metody na 100% osiągnięcie sukcesu w projekcie
- istnieją jedynie sposoby na zmniejszenie prawdopodobieństwa porażki.
Najważniejszym z nich jest zastosowanie sprawdzonej metodyki realizacji projektów. Zasada ta dotyczy każdego większego projektu, w każdej branży.
Nowy system zrealizuje tylko te wymagania, które wcześniej wykryli i opisali analitycy.
Informatycy i użytkownicy skazani są na współpracę.
Przeprowadzone wiosną 1995 roku - w ramach projektu ESPITI - badania ankietowe 10 tys. europejskich firm produkujących oprogramowanie wykazały, że 65 % swoich problemów firmy upatrują w specyfikacji
i zarządzaniu wymaganiami klienta.
Dowodzi to niezbicie, że pod koniec XX wieku głównym problemem jest nie to, jak budować systemy informatyczne, ale to, jak i od kogo dowiedzieć się, jakie są rzeczywiste potrzeby, wymagania i oczekiwania przyszłego użytkownika.
Elementy dobrej praktyki:
Realizacja przedsięwzięć informatycznych powinna być poprzedzona analizą potrzeb użytkownika, której produktem jest dokument określający wymagania na system informatyczny.
Norma PN-ISO 9000-3:1994: pkt 5.3
Należy dotrzeć do wszystkich kluczowych przyszłych użytkowników systemu !!!
Inżynieria oprogramowania jest praktycznym zastosowaniem odpowiedniego zestawu technik do całego procesu opracowania oprogramowania.
Typowe modele produkcji oprogramowania:
- Model kaskadowy,
- Rapid Application Development (RAD)
- Model sekwencyjny,
- Prototypowanie,
- Model spiralny,
Trzy najważniejsze zasady inżynierii oprogramowania to:
1. Zestaw technik jest użyty w celu poprawienia jakości i produktywności.
2. Techniki te są stosowane w sposób zdyscyplinowany, a nie dowolny.
3. Techniki te są stosowane do całego procesu opracowania oprogramowania.
INŻYNIERIA WYMAGAŃ JEST KLUCZOWYM ELEMENTEM INŻYNIERII OPROGRAMOWANIA !
Jakość pracy analityka
Inżynieria wymagań jest określeniem, pod którym kryją się wszystkie działania zmierzające do wypracowania i przeprowadzenia racjonalnych i systematycznych procedur:
pozyskiwania,
analizy,
specyfikacji i weryfikacji wymagań.
Pojęcie to odnosi się do ogólnej metodyki zdobywanie wszelkich informacji, mających charakter wymagań, a w szczególności do etapu analizy wymagań oprogramowania, który jest naturalnym rozwinięciem fazy ogólnego opisu systemu (patrz: inicjacja projektu).
Pozyskiwanie wymagań od użytkownika:
wywiad jest metodą zdobywania informacji przez bezpośrednie stawianie pytań wybranym osobom,
ankieta jest metodą pośredniego zdobywania informacji przez pytania stawiane wybranym osobom za pośrednictwem drukowanej listy pytań, zwanej kwestionariuszem,
warsztat jest metodą zdobywania informacji przez bezpośrednie stawianie pytań grupie osób, prowadzenie dyskusji i generowanie rozwiązań bezpośrednio podczas spotkania (można wykorzystać metodę burzy mózgów).
Istnieje wiele gotowych inżynierskich metod pozyskiwania, analizy i specyfikacji wymagań, takich jak JAD, RAD, analiza strukturalna, analiza obiektowa, prototypowanie, Oracle CASE, UML itd.
Metody te oferują sprawdzone w praktyce rozwiązania szczegółowych działań, prowadzących do pomyślnego określenia wymagań użytkownika oraz odwzorowania ich na specyfikację pozwalającą na realizację systemu.
Zarządzanie Zmianami.
rys
Zarządzanie Zmianami.
Przed podjęciem decyzji o wprowadzeniu zmian do projektu analizuje się:
- rozmiar i zakres zmian,
- złożoność,
- ograniczenia czasowe,
- wpływ na bieżący stan projektu (prace skończone i przyszłe),
- zasoby wymagane do realizacji,
- koszt,
- ryzyko niepowodzenia,
- politykę firmy, produktu, projektu,
- wymagania udziałowców,
- alternatywne sposoby realizacji zmian.
Przed podjęciem decyzji należy rozważyć następujące aspekty wprowadzenia zmiany:
- Czy zmiana nie jest na tyle poważna, że bardziej opłaca się stworzyć
nowy produkt?
- Czy lepiej zmienić istniejące fragmenty systemu, czy też dobudować
nowy moduł, komponent?
- Czy zmiana ma dotyczyć wszystkich klientów korzystających z
systemu, czy jedynie ich części, a więc czy z jednego produktu robią
się dwa produkty?
- Jak zmiana wpłynie na wydajność systemu: poprawi ją, pogorszy czy
pozostawi bez zmian?
- Jaki jest konieczny zakres modyfikacji elementów towarzyszących
programowi, a więc w dokumentacji technicznej, w dokumentacji
użytkowej, w programach szkoleń itp.?
Komitet Kontroli Zmian - zarządzanie zmianami.
Podstawą prac i rozliczania postępu jest tzw. Linia Główna Projektu, którą stanowią: plan i wszystkie zatwierdzone później zmiany. Na początku jest to pierwszy plan zatwierdzony przez Komitet Sterujący do realizacji.
Komitet Kontroli Zmian składa się z przedstawicieli obu stron: dostawcy i klienta, gdyż jest ciałem mediacyjnym. Często, choć nie jest to konieczne, w Komitecie uczestniczą obaj Szefowie Projektu, zwykle wspomagani przez najważniejszych specjalistów technicznych (np. projektanta systemu, architekta, szefa testów itp.)
Zamknięcie projektu
poprawa procesów w zarządzaniu projektami jest możliwa, jeżeli zespół ma okazję na refleksję nad swoją dotychczasową pracą i uczy się w ten sposób na swoich błędach, ale i sukcesach.
Ewaluacja zrealizowanego projektu możliwa jest, jeżeli wcześniej zaplanujemy zbieranie i archiwizowanie informacji na temat projektu - zgromadzona wówczas baza wiedzy posłuży do oceny i porównania.
Ewaluacja:
Co planowaliśmy osiągnąć?
Co osiągnęliśmy i dlaczego?
Czego nie osiągnęliśmy i dlaczego?
Co poszło dobrze i sprawnie?
Co mogliśmy zrobić lepiej?
Jakie wskazówki płyną na przyszłość?
NIE SZUKAMY WINNEGO !
ZAPISUJEMY WNIOSKI !
SKUPIAMY SIĘ NA OBSZARACH, NA KTÓRYCH MOŻNA UZYSKAĆ NAJWIĘKSZĄ POPRAWĘ
Opublikować wyniki i wdrożyć wyniki ewaluacji.
LIST OTWARTY DO ZESPOŁÓW PROJEKTOWYCH:
opis projektu
co zrobiono dobrze
co zrobiono źle
I DYSKUSJA
Szef Projektu pełni kluczową rolą w całym przedsięwzięciu.
Szefem Projektu jest osoba, której przekazano uprawnienia i odpowiedzialność w celu ogólnego zarządzania zasobami projektu (w aspektach technicznych i kosztowych) oraz motywowania wszystkich zainteresowanych.
Pierwotnie stanowisko „kierownika projektu” zostało utworzone przy złożonych i dynamicznie zmiennych pracach (projektach) w przemyśle obronnym i farmaceutycznym.
Działalność Szefa Projektu:
Po pierwsze, kierownik projektu musi posiadać wiedzę techniczną (inżynierską), aby rozwiązywać napotykane problemy.
Po drugie, kierownik projektu musi rozumieć sposób, w jaki ludzie postrzegają otoczenie, definiują preferencje i korzystają z wyposażenia. Dlatego też wymagana jest pewna wiedza w zakresie psychologii, socjologii i ergonomii.
Po trzecie, kierownicy projektów muszą posiadać dobrze rozwinięte umiejętności planowania i koordynowania różnych zadań.
Jednocześnie muszą oni umieć świetnie komunikować się z klientami, dostawcami, ich zwierzchnikami i podwładnymi.
Jak widać oczekiwania w stosunku do kierowników projektów są wyjątkowo wysokie ...
Rola Kierownika Projektu
Potrzeba pracy zespołowej - Kierownik projektu musi pamiętać o prawidłowych relacjach z zespołem projektowym - od umiejętności zbudowania przedsiębiorczego zespołu zależy sukces projektu. Zespół realizuje wspólne cele, przy pomocy ustalonych przez Szefa Projektu standardów działania.
Konflikty w zespole, wynikające z dużego stresu, napiętych harmonogramów, błędów i porażek pojawiających się w trakcie pracy, muszą być przez Szefa Projektu rozpoznawalne i w porę usuwane.
Konflikt między ludźmi jest to proces antagonizmu, który pojawia się zawsze, gdy jedna osoba lub jednostka organizacji podważa osiągnięcia drugiej [Johns Istota i natura konfliktu, 1992].
Szef Projektu powinien pamiętać, że:
- konflikt zawsze związany jest z działaniami ludzi,
- nie można go wyeliminować,
- gdy jest nierozpoznany staje się zagrożeniem,
-/+ jeśli się go bada i analizuje
-/+ można mu zapobiec,
-/+ jeśli zna się naturę konfliktu,
+ można nim sterować
+i uzyskiwać lepsze efekty tych samych działań.
W zasadzie można wyróżnić trzy drogi prowadzące do poprawy zachowań przywódczych:
- Poprzez doświadczenie - learning by doing
- Poprzez obserwację - learning from others
- Poprzez edukację - learning in the classroom or on your own
J. Adair sformułował Krótki kurs budowania zespołu dla menedżera:
Sześć ważnych słów:
Jaką masz na ten temat opinię?
Pięć ważnych słów:
Czy mógłbyś to zrobić, proszę?
Cztery ważne słowa:
Przepraszam, że popełniłem błąd ...
Trzy ważne słowa:
Świetnie się spisałeś ...
Dwa ważne słowa:
Dziękuję Ci ...
Jedno ważne słowo:
My ...
Najmniej ważne słowo:
Ja ...
Szef Projektu powinien zwracać uwagę na etapy rozwoju grupy i dążyć do jej ewolucji w kierunku wysoce efektywnego zespołu, w którym występuje efekt synergii - to znaczy wynik uzyskiwany przez zespół jest większy od sumy wyników indywidualnych członków zespołu. Aby to osiągnąć należy:
pozwolić ludziom pracować razem,
promować kult jakości (rób dobrze od samego początku),
w miarę możliwości zmniejszać kontrolę,
skutecznie rozładowywać konflikty,
rozsądnie korzystać z nacisku,
przeprowadzać częste podsumowania,
kreować poczucie przynależności do elit,
nagradzać tych, którzy podejmują ryzyko,
wyrażać uznanie,
celebrować sukcesy, podtrzymywać ducha projektu.
sobie i innym wysoko ustawiaj poprzeczkę,
oczekuj od ludzi to co najlepsze,
zachęcaj do sukcesów, wskazując dobre wzorce,
okazuj zaufanie i często chwal osiągnięcia,
zachowaj równowagę pomiędzy motywowaniem pozytywnym i negatywnym,
nie przesadzaj ze współzawodnictwem,
nagradzaj współpracę,
pozwól, aby czasem na zespołem przetoczyła się „burza”,
własną motywację utrzymuj na wysokim poziomie.
(wg. A. L. McGinnisa)
Delegować to:
1. Jasno określić zadania i cele.
2. Użyć narzędzi motywujących.
3. Opisać zakres uprawnień.
4. Udzielić pomocy i szkolenia.
5. Określić TERMIN wykonania zadania
6. Zachęcać do udzielania informacji zwrotnej.
7. Ustalić harmonogram sprawozdawczości.
8. Zwięzłość przekazu.
9. Dobór słownictwa.
10. Użycie słów kluczowych.
Poniższe zalecenia (best practices) i ostrzeżenia (worst practices) pochodzą od największych autorytetów w dziedzinie zarządzania projektami i produkcją oprogramowania, którzy tworzą grupę opracowującą narzędzia do doskonalenia procesów wytwarzania oprogramowania dla Departamentu Obrony USA.
Grupa ta zorganizowana jest pod nazwą Software Program Managers Network (www.spmn.com)
Zalecenia (best practices):
Formalne zarządzanie ryzykiem projekt
Dopracowanie interfejsów przez rozpoczęciem projektowania
Formalne przeglądy projektu i produktów faz projektowych
Zarządzanie projektem, oparte na wiarygodnych metrykach
Stosowanie binarnego kryterium walidacji i weryfikacji zadań
Powszechna dostępność informacji o stanie projektu
Formalne śledzenie defektów
Zarządzanie konfiguracją projektu
Troska kierownictwa o zasoby ludzkie
Ostrzeżenia (worst practices):
Stosowanie nowych technologii w celu skrócenia terminów
Specyfikowanie sposobów implementacji w fazie formułowania wymagań
Stosowanie nie sprawdzonych technik i metodyk
Próby nadrobienia dużych opóźnień projektowych bez istotnego ograniczenia funkcjonalności systemu
Umieszczenie zadań wymykających się spod kontroli na ścieżce krytycznej
Fałszywe założenia co do możliwości uzyskania od zespołu projektowego wysokiej produktywności
Opieranie całej złożoności systemu wyłącznie na oprogramowaniu
Konstruowanie architektury systemu bez właściwego doświadczenia w produkcji oprogramowania
Poleganie jedynie na formalnych przeglądach projektu, jako wskaźnikach jego bieżącego stanu
Tom DeMarco i Timothy Lister
zwracają ogromną uwagę na „miękkie” aspekty zarządzania informatykami, podkreślając, że produktywność zespołów może różnić się o rzędy wielkości, nie z powodu różnic w wyszkoleniu, czy stosowaniu odmiennych technik, ale właśnie z powodu sposobu, w jakim członkowie zespołu informatyków komunikują się ze sobą i ze światem użytkownika na poziomie wymiany informacji, a zwłaszcza emocji.
„Peopleware: Productive Projects and Teams”