Jakie są przyczyny upadania projektów programistycznych?
Dlaczego projekty IT kończą się fiaskiem? Czemu tak się się dzieje? I jak temu zapobiec? Ile statystycznie projektów informatycznych nie dobiega do końca, a ile przechodzi kompletną metamorfozę? Na te i wiele innych pytań postaram się odpowiedzieć w dzisiejszym artykule. Jeśli więc jesteście ciekawi to zapraszam do lektury.
Fot: pixabay.com, CC0 License.
Na początek może trochę danych statystycznych, przede wszystkim czy ktoś wie jak dużo projektów informatycznych odniosło sukces, porażkę lub napotkało poważne problemy podczas ich realizacji? Według raportu Standish Group w 2014 roku tylko 16,2% projektów informatycznych zostało zakończonych sukcesem (zgodnie z harmongramem, budżetem oraz zakresem). Co ciekawe aż 52,7% odniosło częściowy sukces spełniając jeden lub kilka następujących warunków: przekroczony harmongoram, przekroczony budżet, zmieniony zakres. Zastanawiający jest jednak fakt, że 31,1% projektów IT zostało przerwanych przed ukończeniem prac.
Pewnie zaskoczyły was te dane? Po części są one trochę szokujące, ale kiedy popatrzymy na nie z innej perspektywy to bardzo łatwo dojść do wniosku, że w sumie tak naprawdę nie ma w tym nic dziwnego. To czy dany projekt odniesie sukces czy też nie, jest zależne od wielu czynników. My jako programiści jesteśmy tylko małym trybikiem w tej wielkiej machinie. Kto zatem ponosi największą odpowiedzialność?
Na pierwszym miejscu stawia się przede wszystkim wsparcie kierownictwa na kolejnej pozycji zaangażowanie użytkownika oraz doświadczenie kierownika. Ważne jest również to aby jasno i precyzyjnie zdefiniować cel projektu, jego zakres oraz odpowiednio długie harmonogramy i kamienie milowe. Na samym końcu możemy wyróżnić dobrze zdefiniowany proces zarządzania projektem oraz dostępną na jego potrzeby infrastrukturę.
Dlaczego więc projekty IT upadają? W większości największy wpływ na taki stan rzeczy ma szefostwo firmy. Jeżeli prezes stwierdzi, że nie robimy czegoś bo to nam się nie opłaca, albo to porzucamy i idziemy pracować przy czymś innym to w zasadzie reszcie pracowników pozostaje się tylko dostosować. Tak samo sytuacja wygląda z zaangażowaniem klienta, jeśli ten myśli, że spotka się z kierownikiem projektu na kilka godzin i powie czego oczekuje, a potem za kilka miesięcy przyjdzie odebrać gotowy produkt, to może być raczej pewny, że nie otrzyma tego co sobie wymarzył.
Na dalszy plan schodzą tutaj takie aspekty jak doświadczenie kierownika projektu, jasno zdefiniowane cele, zakres prac, odpowiednio dobrany harmonogram oraz kamienie milowe. Na sukces lub porażkę, wszystkie te czynniki mają istotny wpływ, zgodnie z kolejnością w jakiej je wymieniałem.
Pamiętacie może trójkąt projektowy?
Powyższa ilustracja może nie jest wybitnym dziełem artystycznym ale znakomicie pokazuje to, że decydowanie o jakości projektu wpływa na jego koszt, czas oraz zakres. Jak wiadomo, każdy chce mieć wszystko jak najlepsze, w najkrótszym czasie i za cenę paczki ciastek kupionych w sklepiku osiedlowym. Nic z tych rzeczy! Aby projekt się udał przynajmniej dwa parametry (znajdujące się na wierzchołkach trójkąta) muszą być modyfikowalne. Klient musi określić czy ma więcej czasu i jest wstanie zmniejszyć zakres projektu czy może woli dołożyć więcej pieniędzy na zatrudnienie dodatkowych programistów. Warto sobie więc zapamiętać następujący wzór: JAKOŚĆ = KOSZT * CZAS * ZAKRES (jeśli któryś z parametrów zmniejszamy, to automatycznie musimy zwiększyć drugi).
Wydaje mi się, że na powodzenie projektu oraz jego jakość, koszt i czas ma wpływ też dług techniczny. Pod tym pojęciem kryje się coś co od strony programistycznej decyduje często o przyszłości danego projektu.
Pisząc ten artykuł opierałem się na sytuacji w której startujemy z zupełnie nowym projektem od przysłowiowego „zera”. Na temat długu technicznego pewnie napiszę jakiś osobny artykuł, bo warto o tym również wspomnieć.
Faktycznie szokujące dane. Miejmy nadzieję, że sytuacja będzie się poprawiać z roku na rok.