Projekty informatycznie znacznie się różnią od innych projektów. To powoduje, że zarządzanie projektami IT przez osoby nie mające pojęcia o programowaniu i technicznych zawiłościach ich utrzymywania jest tak bardzo trudne. Ilość stosowanych obecnie metodyk i ich kuriozalne założenia, powstawanie kolejnych języków modelowania oraz odsetek projektów IT, które kończą się niepowodzeniem zdaje się to tylko potwierdzać.
Uwielbiam Informatykę właśnie za to – że jest tak niedostępna dla nie-informatyków a zarządzenie projektami, które w swoim założeniu ma to naprawić paradoksalnie – jeszcze bardziej to komplikuje 🙂 Żeby była jasność, nie krytykuję PM ale próba ujarzmienia projektów IT za pomocą kolejnych metodyk i „zbioru zasad” którzy mają stosować programiści nie posiadający „matematycznej dyscypliny” o której mówi Uncle Bob Martin nie ma za bardzo sensu.
#1: Początkowe fazy projektu są najbardziej kosztowne
W projektach IT kontakt z interesariuszami i zarządzenie wymaganiami jest wyjątkowo istotne. Większość niepowodzeń w projektach informatycznych jest wynikiem niedostatecznego zrozumienia klienta. W projektach nie-IT ten problem jest zazwyczaj mniejszy. To powoduje że rola planowania i rozwoju samego projektu zajmuje najwięcej pracy a implementacja jest de facto trywialna.
W przypadku nieinformatycznych projektów (np. budowlanych) to implementacja jest najdroższym etapem realizacji projektu zaś planowanie i projekt pochłania znacznie mniej kosztów.
#2: Testowanie
W przypadku projektów informatycznych (a tym bardziej projektów dotyczących wytworzenia oprogramowania), wiele uwagi poświęca się testowaniu. Istnieją nawet metodyki (mowa o Test-Driven Development) które polegają najpierw na pisaniu testu dla nieistniejącej funkcjonalności a dopiero potem przystępuje się do jej implementowania i refaktoryzacji kodu.
W projektach nieinformatycznych testowanie oczywiście występuje ale nie jest punktem wyjściowym rozwoju projektów lub nie pochłania tak znacznych środków.
#3: Złożoność
Potrzeba planowania jest wynikiem dużo większej złożoności projektów informatycznych od innych. Poziom skomplikowania projektów polegających na wytworzeniu oprogramowania powoduje, że utrudnione jest harmonogramowanie i kosztorysowanie. Pojawiające się w trakcie realizacji projektu nowe i z pozoru mało znaczące wymagania mogą wymagać sporych nakładów pracy. Bardzo trudno jest dokładnie określić szczegółowe wymagania dotyczące projektów oprogramowania przed rozpoczęciem realizacji. Z tego powodu podejście adaptacyjne (Agile) najlepiej sprawdza się przy dalszym opracowywaniu szczegółowych wymagań dla projektu w trakcie jego realizacji zamiast próbować definiować je z góry.
W przypadku projektów nieinformatycznych (które dużo łatwiej jest zaplanować) łatwiej jest zapanować i określić wpływ poszczególnych wymagań na cały projekt.
#4: Unikalność
Projekty informatyczne są unikalne. W praktyce oznacza to, że ciężko jest wykorzystać doświadczenia i efekty prac powstałe w skutek tworzenia projektu dla jednego klienta by potem móc je wdrożyć w projekcie dla kolejnego klienta.
Automatyzacja i tworzenie niejako szablonów i matryc jest łatwiejsze w przypadku projektów nieinformatycznych.
#5: Niepewności i konieczność zarządzania ryzykiem
Złożoność i unikalność poruszana w poprzednich punktach powoduje, że projekty informatyczne są obarczone znacznie większym ryzykiem niż inne projekty i zwiększonym poziomem niepewności.
W projektach nieinformatycznych możliwość zaplanowania daje większą kontrolę nad projektem a to powoduje zazwyczaj mniejsze ryzyko i prawdopodobieństwo poniesienia nieprzewidzianych strat.
#6: Nienamacalność postępów i niematerialny efekt końcowy
To co wyraźnie odróżnia projekty informatyczne od innych to brak możliwości zaprezentowania wyraźnych i namacalnych postępów realizacji. W projektach informatycznych istnieje coś takiego jak wdrożenie. Dopiero po wdrożeniu można zaprezentować postęp prac.
W przypadku np. projektu budowlanego widzimy jak budynek stopniowo powstaje i znacznie łatwiej jest określić postępy osobom nie zaangażowanym bezpośrednio w realizację projektu.
#7: Elastyczność rozwiązań, upgrade i kolejne wersje
Od projektów informatycznych wymaga się pewnego rodzaju elastyczności. Potrzeba integracji z innymi usługami i systemami oraz możliwość wykonania w przyszłości dodatkowych funkcjonalności musi być „wbudowana” w projekt.
W przypadku projektów informatycznych nie ma potrzeby wykonywania i wdrażania nowych wersji.
#8: Utrzymanie i brak wyraźnego punktu zakończenia pracy nad projektem
Utrzymanie jest charakterystycznym etapem projektów informatycznych. W projektach nieinformatycznych nie ma potrzeby utrzymywania zrealizowanych projektów lub jest ono znacznie mniej istotne.
Odpowiedz lub skomentuj