1. Brak zaangażowania klienta
Wdrażanie technologii informatycznych ma na celu wniesienie wartości biznesowej dla klienta. Może nią być oszczędność czasu w dostępie do informacji (np. różnego rodzaju kartoteki), usprawnienie procesu planistycznego (aplikacje do zarządzania magazynami i spedycją), poprawienie nadzoru (programy do rozliczania czasu pracy), zwiększenie sprzedaży (sklepy internetowe), usprawnienie etapu wytwórczego (programy do projektowania CAD, CAM) czy choćby tak proste czynności jak automatyzacja pracy (mailing, raportowanie).
Klient rzadko wie czego tak naprawdę potrzebuje, a jeszcze rzadziej potrafi to opisać w sposób na tyle jasny i precyzyjny aby powstał z tego dobry produkt. Tak naprawdę, oczekiwania klienta klarują się w pierwszych tygodniach używania produktu (jeżeli jest dostarczany wg. metodyk kaskadowych) lub po pierwszych sprintach, gdy dostarczane są mu kolejne działające moduły (wg. metodyk zwinnych).
Jeżeli klient nie weźmie na siebie części odpowiedzialności za produkt (w szczególności za wyjaśnianie rozbieżności interpretacyjnych wymagań oraz ich priorytetyzowanie) – istnieje duże prawdopodobieństwo, że pomimo dobrych intencji po stronie wykonawcy – może otrzymać coś zupełnie innego niż oczekiwał. Rolą project managera jest nakreślenie tego ryzyka klientowi oraz racjonalne przekonanie go do aktywnego udziału w projekcie (oczywiście w akceptowalnym dla klienta zakresie czasowym).
2. Nierealne terminy
Nierealność terminu może zależeć od wielu czynników: dostępności zasobów po stronie wykonawcy (ludzie, narzędzia), poziomu komplikacji wytwarzanego produktu („Jedna kobieta urodzi dziecko w 9 miesięcy, ale 9 kobiet nie urodzi dziecka w miesiąc” – szybkość wytwarzania nie wzrasta liniowo w stosunku do zwiększania zasobów projektowych) oraz czynników zewnętrznych (np. realności zaistnienia ryzyk projektowych, dostępności zewnętrznych systemów z którymi nastąpi integracja, uzyskania niezbędnych certyfikatów lub dostępów).
Podejmowanie projektów o nierealnych terminach, może świadczyć o:
- niedokładnej analizie wymagań, a co za tym idzie niezrozumieniu tego co powinno zostać wykonane w ramach projektu
- autorytarnym szacowaniu czasochłonności w oderwaniu od rzeczywistych możliwości wytwórczych
- niewykonaniu analizy ryzyka przy ocenie projektu
Warto tu przytoczyć żelazny trójkąt projektów IT, którego boki to odpowiednio: zasoby, funkcjonalności do wykonania oraz czas na realizację projektu. Zmiana dowolnego z tych parametrów, wpływa na pozostałe dwa. Konkluzja jest taka, że nie da się wytworzyć tyle samo w krótszym czasie bez utraty jakości lub zwiększenia zasobów. W tym temacie polecam ciekawy wpis – tutaj.
3. Błędne szacowanie czasochłonności
Szacowanie czasochłonności jest jedną z najtrudniejszych czynności w fazie planowania projektu i jest czynnikiem najbardziej zależnym od doświadczenia. Istnieją techniki ułatwiające szacowanie czasochłonności, np. metoda punktów funkcyjnych, jednak według mnie najbliższe prawdy jest szacowanie bazujące na doświadczeniu (podobnie jak to ma miejsce w SCRUM`ie).
Błędne szacowanie może wynikać z:
- braku przyjętej stałej metody szacowania,
- braku zrozumienia tego, co powinno zostać wykonane,
- przesadnego optymizmu osoby szacującej.
Przy szacowaniu czasochłonności, należy pamiętać o:
- ocenie całości projektu oraz przełożeniu tego na rzeczywisty czas kalendarzowy (z uwzględnieniem świąt, dni wolnych, okresów urlopowych – również po stronie klienta),
- uwzględnieniu dostępności zasobów projektowych (programista A może pracować dwa razy wydajniej niż programista B, więc szacujemy pod konkretny zespół projektowy),
- wyliczeniu średniej dostępności osób w przeliczeniu na dzień roboczy – jeżeli programista pracuje tylko nad jednym projektem, rozsądnie jest przyjąć około 6 godzin jako jeden dzień roboczy,
- warto stworzyć proste listy kontrolne dla szacunków czasochłonności, uwzględniające np. proces analizy, projektowania, produkcji, testów, poprawek, retestów, wdrożenia, wytworzenia dokumentacji, zamknięcia projektu.
Należy pamiętać, że osoba która szacuje projekt/funkcjonalność – deklaruje w ten sposób, że jest w stanie ją dostarczyć w tym terminie..
4. Niska jakość analizy wymagań/specyfikacji wymagań
Istnieje taka zasada: „Garbage In, Garbage Out” – oznacza nie mniej, nie więcej niż to, że wyniki przetwarzania błędnych danych będą błędne nawet wtedy, gdy procedura przetwarzania była poprawna.
Skutkiem kiepskich wymagań jest produkt, który nie spełnia oczekiwań klienta. Przyczynami mogą być: niskie kompetencje analityka, brak pisemnej dokumentacji wymagań, brak akceptacji dokumentacji wymagań przez klienta,pomijanie wymagań niefunkcjonalnych.
Działaniami jakie możemy podjąć to: zmiana analityka lub ściślejsza kontrola nad jego pracą, opracowanie firmowego wzoru specyfikacji wymagań (do wykorzystywania w kolejnych projektach), zaangażowanie klienta w proces tworzenia specyfikacji wymagań, zaangażowanie testerów w proces analizy dokumentu zawierającego wymagania (dzięki czemu łatwo zidentyfikują niemierzalne/nietestowalne wymagania).
5. Pomijanie/niedocenianie testowania
Wiele osób uważa, że testowanie w procesie tworzenia oprogramowania ma miejsce po tym, jak produkt zostaje wytworzony. Nic bardziej mylnego. Udział testerów konieczny jest już na etapie analizy wymagań. Wynika to z faktu, że cechą naturalną testera jest sprawdzanie zgodności funkcjonalności ze wzorcem. Specyfikacja wymagań jest wzorcem. A co jeżeli wzorzec jest niemożliwy do przetestowania?
Mając przed sobą zapis „System posiada ładny interfejs użytkownika”, następujące pytania zostaną zadane:
- manager: „Jak to zrobić, żeby zdążyć z terminem?”
- grafik/designer: „Użyć koloru szafirowego czy kobaltowego?”
- tester: „Czy da się to przetestować?”
Testerzy szybko wychwycą tego typu kruczki i ustrzegą nas przed nimi, proponując zastąpienie ich wartościami mierzalnymi. Dzięki temu unikniemy problemów podczas odbioru systemu.
6. Brak zarządzania zmianą
Brak zarządzania zmianą oznacza, że nie mamy dokumentu/metodyki która powie nam, co zrobić jeżeli zmiana wystąpi. Zmiana może dotyczyć: sposobu działania danej funkcjonalności, kolejności realizacji modułów w projekcie, zmiany części zespołu projektowego. Warto pamiętać, że każda czynność, która nie przybliża nas do celu – na pewno nas od niego oddala. Zarządzanie zmianą to również analiza skutków podejmowania decyzji o zmianie. Przykładem może być pozornie niewielka modyfikacja kodu, która początkowo dla programisty wydaje się być niegroźna -
a finalnie, np. w wyniku nieuwzględnienia specyfiki projektu (co zrobiłby architekt), może spowodować konieczność dołożenia 2 tygodni pracy.
Co możemy zrobić? Utworzyć prosty dokument, w którym opisujemy podejście do zmian (tzw. „change request”), format rejestrowania żądań zmiany oraz procedury postępowania (szacowania wpływu, podejmowania decyzji). Dobrym rozwiązaniem jest również edukacja zespołu projektowego w kontekście identyfikacji tego, co jest przedmiotem projektu a co żądaniem zmiany.
7. Brak doświadczonych pracowników
Skutkiem niedopasowania kompetencji zespołu do projektu, będzie przekraczanie terminów wykonywania zadań oraz etapów projektowych, prawdopodobna praca po godzinach, a co za tym idzie dodatkowy spadek wydajności zespołu. Przyczyną może być brak udziału project managera w planowaniu projektu (w tym jego zasobów), brak wsparcia kierownictwa wyższego szczebla, brak dokładnej analizy wymagań (przez co zasoby zostały nieodpowiednio dobrane) lub po prostu brak wykwalifikowanych pracowników na lokalnym rynku pracy.
Co możemy zrobić:
- przygotować listę osób oraz ich kompetencji, które są konieczne do wykonania projektu w terminie oraz uwzględnić ją podczas planowania projektu,
- zdobyć odpowiednie osoby, ponownie przydzielić zadania oraz renegocjować termin umowy (w fazie realizacji projektu – działania zaradcze).
8. Brak kontroli postępu projektu
Jedną z najbardziej niedopuszczalnych sytuacji dla project managera jest brak możliwości odpowiedzenia na pytanie: „Na jakim etapie projektu jesteśmy oraz ile czasu potrzebujemy, żeby go zakończyć?”.
Skutki braku kontroli:
- niemożliwość wykrycia ryzyka przekroczenia terminu a co za tym idzie, podjęcia działań zaradczych lub minimalizujących jego skutki,
- prawdopodobieństwo przekroczenia terminu,
- prawdopodobieństwo rozbieżności pomiędzy tym co jest opisane wymaganiach a tym co jest wytwarzane,
- duże prawdopodobieństwo, że harmonogram projektu nie będzie w ogóle realizowany.
Kontrola realizacji projektu powinna składać się z dwóch rodzajów działań: analizy danych zbieranych automatycznie (np. z bugtrackerów lub innych aplikacji do obsługi zadań lub projektów) w kontekście odpowiedzi na pytanie „Na którym etapie projektu jesteśmy?” oraz weryfikacji prawdziwości tych danych w kontekście odpowiedzi na pytania „Czy dane, które posiadamy są prawidłowe?”. Weryfikacja prawidłowości danych ma na celu wykluczenie niezrozumienia lub celowego, wprowadzania złych danych (np. zamykanie ticketów, które nie zostały wykonane lub zostały wykonane częściowo). Do kontroli postępu przydadzą się narzędzia takie jak wykres Gantta lub wykres wypalania.
9. Brak komunikacji w zespole
Jest wiele skutków braku komunikacji, zaczynając od niezrozumienia wymagań, poprzez brak eskalacji ryzyk i blokad projektowych
a skończywszy na niedokładnym raportowaniu. Rolą project managera jest zadbanie o prawidłowy przepływ komunikacji. W tym celu, można utworzyć prosty dokument lub wyjaśnić członkom zespołu: kto jest odpowiedzialny za udzielanie informacji, jakie informacje powinny być udzielane, jaki powinien być stopień szczegółowości informacji w stosunku do odpowiednich odbiorców, w jaki sposób informacje powinny być przekazywane (ustnie/pisemnie), jak często powinny być one przekazywane oraz kto powinien inicjować przekazanie informacji.
