Serwis korzysta z plików cookies.
        LOGOWANIE  /  REJESTRACJA      

10+3 główne powody, dla których projekty systemów się nie udają. Część I

Paul Dorsey

20 wrzesień 2015 roku

Trzynaście lat temu napisałem artykuł zatytułowany “10 powodów dlaczego projekty systemów się nie udają”. To był mój najbardziej oczekiwany artykuł. Został wykorzystany na Harvardzie, co doprowadziło do tego, że moja firma stworzyła budżet i system finansowy dla rządu Etiopii. Dziesiątki profesjonalistów, absolwentów i pracowników naukowych wielokrotnie prosiło mnie o jego napisanie. Ostatnio polska organizacja zajmująca się zarządzaniem projektami poprosiła mnie o zgodę na przedrukowanie go w swoim czasopiśmie. Pomyślałem, że będzie to dobra okazja do powrotu do tego tematu i ponownego jego przejrzenia.

Jestem zaskoczony niezmienną aktualnością tego artykułu. Projekty IT nadal nie udają się w podobny sposób, w jaki nie udawały się dekadę temu. Jednakże sądzę, że artykuł zasługuje na aktualizację z dwóch powodów. Po pierwsze, kolejna dekada mojej obecności w biznesie, to uczestnictwo w większej ilości (i większych) projektach. Po drugie, świat zmienił się od czasu, kiedy napisałem ten artykuł. Wtedy architektura sieci internetowej była w fazie szybkiego wzrostu, lecz jeszcze nie nastała jej era.

Streszczenie

Projekty z dziedziny systemów informacyjnych często kończą się niepowodzeniem. W zależności od źródła badań, współczynnik niepowodzenia dużych projektów wynosi pomiędzy 50 a 80%. Z powodu naturalnej ludzkiej skłonności do ukrywania złych wiadomości, prawdziwe statystyki mogą być wyższe. To jest katastrofa. Jako gałąź przemysłu, ponosimy porażkę w swojej pracy.

W oparciu o przeszłe doświadczenia, rozpoczynając duże,
złożone projekty systemów, realistycznie powinniśmy oczekiwać niepowodzenia projektu. Szczególnie projekty dotyczące reengineeringu procesu biznesowego (BPR) mają nawet wyższy współczynnik niepowodzenia z powodu ich rozszerzonego zakresu. Wynajmowanie dużej, uznanej firmy konsultingowej nie jest gwarancją sukcesu; nie jest nią także kupno zapakowanego oprogramowania i wdrożenie go.

Projekty zwykle buduje się, używając strategii, która prawie że gwarantuje porażkę. Inżynieria oprogramowania jest rodzajem inżynierii. Budowanie dużego systemu informacyjnego jest jak konstruowanie 20–piętrowego biurowca. Jeśli gromada elektryków, hydraulików, stolarzy i podwykonawców spotyka się w terenie, rozmawia przez kilka godzin, a potem zaczyna budować, budynek będzie niestabilny, o ile zostanie w ogóle wybudowany. Na którejś z moich prezentacji, jeden ze słuchaczy podzielił się dowcipem mówiącym, że „Jeśli inżynierowie budowlani budują budynki z taką samą starannością, z jaką inżynierowie oprogramowania budują systemy, to pierwszy dzięcioł, który się pojawi będzie końcem cywilizacji, jaką znamy”. Gdybyśmy tylko pamiętali, że budowanie oprogramowania jest jak budowanie biurowca, to większość problemów mielibyśmy z głowy.

Zanim biurowiec zostanie zbudowany, architekt rysuje szczegółowe plany, buduje modele i tworzy fotokopię. Na każdym etapie plany są wielokrotnie dokładnie przeglądane. W trakcie budowania konstrukcji każdy etap jest testowany i wnikliwie sprawdzany.

W przypadku projektów software’owych, jeśli nie rozpoczęliśmy pisania kodu przez trzy miesiące, błędnie sądzimy, że coś musi być nie tak.

Czy nie widzimy bezsensowności rzucania się głową naprzód bez starannego planu?

Oto przykład: W jednym z projektów, w który byłem zaangażowany, kierownik projektu zażądał, żeby zespół ds. dokumentacji technicznej zaczął pisać instrukcje szkoleniowe jeszcze przed osiągnięciem stabilności interfejsu użytkownika. To jest mniej więcej tak mądre, jak wprowadzanie malarzy przed wybudowaniem ścian.

Tak więc, co tak naprawdę powoduje, że projekty systemów kończą się niepowodzeniem? Czy chodzi o jakiś techniczny sekret, którego większość inżynierów systemów nie zna? Czy projekty software’owe są tak drastycznie złożone, że tylko najbardziej utalentowane zespoły mają szansę na sukces? Osobiście byłem zaangażowany zarówno w projekty zakończone sukcesem, jak i projekty, które spaliły na panewce. Smutnym faktem jest, że projekty software’owe ponoszą porażkę, ponieważ nie doceniamy, że dobre zasady inżynierskie powinny być stosowane do projektów software’owych tak, jak są stosowane do budowania biurowców. Próbujemy bronić się, mówiąc, że budowanie oprogramowania jest “inne”.

Kiedy Peter Koletzke i ja opublikowaliśmy The Designer/2000 Handbook, przemyciliśmy tam całkiem sporo materiału o inżynierii oprogramowania. Próbowaliśmy pisać o tym, jak najlepiej powinno się budować system, używając produktu Designer. Sposób, w jaki przyjęto ten materiał w społeczeństwie jest interesujący, a czasami negatywny. Jeden czytelnik zażartował, że “Ja już wiem, jak budować systemy. Muszę tylko wiedzieć, co kliknąć w narzędziu”. Inny narzekał, że zabrakło w książce wnikliwości i że była to tylko przeróbka “śmieci SDLC, które kazali mi czytać w szkole.” Bardziej doświadczeni inżynierowie systemu, którzy byli zaangażowani w wiele projektów, dostrzegli wartość książki i byli całkiem podatni na jej treść.

Ja jednak sądzę, że najbardziej interesujący komentarz na temat książki pochodzi od mojego brata Walta. Walt jest “prawdziwym” inżynierem, który zajmował się jakością w kilku dużych technicznych przedsiębiorstwach. Powiedział mi, że książka mu się podobała i że rady w niej udzielone w dużym stopniu odzwierciedlały sposoby zarządzania projektami w firmach, w których on pracował. Był zaskoczony, że ten rodzaj metody developmentu nie jest częścią normalnego podejścia do budowania systemów.

Robiłem wiele prezentacji na konferencjach Oracle. Jeśli mówię o udoskonalaniu designu baz danych, zwykle przyciągam 30–50 słuchaczy. Jeśli mówię o udoskonalaniu środowiska programistycznego Javy, mam 300–500 słuchaczy. Sądzę, że ten brak zainteresowania metodyką leży u źródła naszych problemów. Wielu z nas błędnie wierzy, że jedynym prawdziwym wkładem w projekt jest napisanie kodu. Korzystając ponownie z przykładu biurowca, jest to jak mówienie, że jeśli nie masz młotka lub pędzla w ręku, twój wkład w biurowiec nie jest istotny.

Proszę nie oczekiwać żadnych błyskotliwych spostrzeżeń w tym artykule. Podzielę się z wami moimi sukcesami, porażkami i prawie–katastrofami. Moja ostateczna konkluzja brzmi, że najlepszym sposobem na sukces projektu jest używanie własnej głowy.

Jak możemy uniknąć robienia błędów, które prowadzą projekt do niepowodzenia? Zaskakujące jest to, że odpowiedzią na to pytanie jest najczęściej po prostu zachowanie zdrowego rozsądku. Naszym problemem jest to, że w projektach systemów zdrowy rozsądek często jest ignorowany.

3 klucze do sukcesu projektu
Wygląda na to, że istnieją trzy czynniki, które są wspólne dla projektów kończących się sukcesem Każdy z tych czynników jest kluczem do sukcesu każdego projektu.
Każdy projekt jest jak trójnogi statyw. Wszystkie trzy nogi muszą być na właściwym miejscu, aby trójnóg pewnie stał. W projekcie systemów te “nogi” lub krytyczne czynniki sukcesu składają się z następujących elementów:

  • Wsparcie najwyższej kadry zarządzającej
  • Właściwa metodyka
  • Solidne techniczne przywództwo kogoś, kto z sukcesem zakończył podobny projekt.

Bez tych „nóg”, umiejscowionych pewnie i właściwie, trójnóg przewróci się, a projekt padnie.

Wsparcie najwyższej kadry zarządzającej

Jakiekolwiek badanie dotyczące sukcesu lub porażki systemu wskazuje na wsparcie najwyższej kadry zarządzającej jako krytyczny czynnik sukcesu. Bez pełnego zaangażowania ze strony top managementu, w momencie pojawienia się problemów w projekcie (co jest nie do uniknięcia), projekt upadnie. Personel zarządzający w jakiejkolwiek organizacji, która podejmuje się projektów systemów powinien mieć z góry na uwadze, że projekt napotka poważne utrudnienia. Będą musieli być przygotowani na to, aby pokazać, że widzialnie i słyszalnie stoją murem za projektem, pomimo tych utrudnień, albo projekt będzie skazany na porażkę.

Byłem zaangażowany w pewien system, w którym wdrażanie szło słabo. Szeregowi użytkownicy byli o krok od buntu. Jednakże najwyższa kadra wspierała projekt i zakończył się on w końcu sukcesem. Gdyby kadra zarządzająca nie była zaangażowana, projekt na pewno by upadł.

W innym przypadku projekt szedł świetnie, ale przyszedł nowy menedżer i projekt zniknął w ciągu jednej nocy. Właściwie to kilka z tych upadłych projektów zostało skasowanych przez kogoś, kogo development team nigdy nie poznał. Oznacza to, że projekt nie zakończy się sukcesem, jeśli kadra zarządzająca nie uważa, że zakończy się sukcesem. Konieczne jest szkolenie kadry zarządzającej z procesu, który jest używany, i zarządzanie ich oczekiwaniami.

Istnieje prawdziwa różnica między projektami systemów i biurowców. Kiedy budynek jest w połowie gotowy, jest już co oglądać. Kiedy projekt oprogramowania jest w połowie gotowy, jest niewiele (jeśli w ogóle cokolwiek) do oglądania. Menedżerowie powinni wiedzieć, czego mogą się spodziewać i kiedy. Jeśli założą, że w projekcie 50% systemów będzie działało, kiedy wydane zostanie 50% budżetu, prawdopodobnie zaczną się zastanawiać nad wyciągnięciem wtyczki z projektu, który idzie zgodnie z harmonogramem.

Strzeżcie się wykwalifikowanego developera, który sądzi, że przewodzi projektowi. Doświadczony developer z kilkoma latami doświadczenia może nie rozumieć designu systemu. Jednakże mogą oni jedną ręką uciąć projektowi głowę, kiedy ich opinia trafi na podatny grunt. Menedżerowie często nie rozumieją designu systemu. Polegają na opiniach wykwalifikowanych doradców. Kluczem do zarządzania menedżerami jest przyprowadzenie obiektywnych audytorów wysokiego szczebla. Skąd kadra zarządzająca ma wiedzieć, że nie oszukuje się ich, czy projekt jest dobrze zarządzany? Nie mają kwalifikacji do oceny sytuacji. Kadra zarządzająca może po prostu zakończyć projekt z powodu niezrozumienia działań zespołu developerów. W takich przypadkach audyt techniczny może uzasadnić działania zespołu i dostarczyć kadrze zarządzającej informacje wymagane do podtrzymania ich wsparcia dla projektu.

Metodyka rozwoju

Wiele systemów buduje się bez poświęcenia wystarczającej ilości czasu na przemyślenie procesu. Zespół zbiera się i rozpoczyna działania. Jak tylko zbierze się wystarczającą ilość informacji, zaczyna się kodowanie. Ten brak uwagi dla procesu może zabić system. Łatwo jest zauważyć rezultat braku uwagi dla procesu po tym, jak system już zawiedzie. Zwykle największe fragmenty wymagań użytkownika są ignorowane. Duże ilości kodu muszą być napisane ponownie, ponieważ za pierwszym razem nie spełniają wymagań użytkownika.

Jeśli system jest ukończony, jest on wdrażany bez odpowiednio dokładnego przetestowania. Bez dobrze przemyślanego procesu jest mała szansa na to, że projekt systemu zostanie ukończony. Jeśli projekt jednak zakończy się sukcesem, to tylko dzięki dużym ilościom przeróbek i poprawek oraz przekroczeń kosztów.

Zaskakująca może być myśl, że wybrana metodyka nie ma znaczenia, ale właściwie jest to prawda. Liczy się, że jest JAKAŚ metodyka. Nie ma precyzyjnych badań wskazujących, że dana metodyka jest lepsza niż inna. Ważne jest, aby utrzymać projekt na pewnym poziomie zorganizowania w sposób konsekwentny i skoncentrowany oraz aby przemyśleć proces dokładnie już na samym początku. Różne metodyki zbierają te same informacje, ale organizują je w inny sposób. Jedna może mieć dodatkowe, niepotrzebne etapy. Inna może pomijać pewne etapy, które wymagają od developerów powrotu tą samą trasą do wcześniejszych etapów. Ważne jest użycie jakiejś metodyki z sukcesem. Jeśli proces ma wadę, zwykle nie jest to poważna wada. Jedna metodyka może być bardziej efektywna od drugiej, ale jakiś proces jest lepszy niż żaden.

Jest wiele sposobów podejścia do rozwoju systemu – zorientowanie na cel, szybkie prototypowanie, kaskadowy, itd. Korzystają one z różnych narzędzi, aby wykonać te same zadania. Podejście zorientowane na cel wykorzystałoby do analizy przypadki użycia, podczas gdy profesjonalista–tradycjonalista z Oracle użyłby hierarchii funkcyjnej.

Jeśli dana organizacja jest utalentowana w jednej konkretnej dziedzinie, nie ma powodu, aby nie korzystać z jej wiedzy i doświadczenia. Na przykład, jest masz pewną liczbę developerów zorientowanych na cel, podejście zorientowane na cel będzie oczywistym wyborem. Podobnie, sklep wyspecjalizowany w Oracle Designer może korzystać z metodyki CADM.

Jak już wcześniej wspomniałem, dobrym pomysłem może być, żeby wybrana metodyka była ściśle zintegrowana z wybranymi narzędziami developmentu, ponieważ mniej wysiłku pójdzie na marne. Jednakże nie zagwarantuje to sukcesu projektu. Projekt może być tańszy lub droższy, ale nie zakończy się sukcesem lub porażką tylko z powodu metodyki lub narzędzi.

Przywództwo techniczne

Tak, jak do budowania potrzeba architekta, tak do systemu oprogramowania potrzeba technicznego prowadzenia. Aby osiągnąć sukces, architekt lub technical lead musi być tym, który kontroluje “architekturę” projektu, a konkretnie model danych i design aplikacji. Ten poziom kontroli musi być uznany za obowiązujący i akceptowany przez wszystkich uczestników projektu. W przeciwnym wypadku każdy fragment systemu może być konstruowany niezależnie przez fragment zespołu i koniec końców części nie będą do siebie pasowały.

Technical lead musi mieć doświadczenie w budowaniu systemów dla konkretnej dziedziny biznesu, dla której bieżący system jest budowany. Na przykład, każdy system zawierający w sobie funkcje finansowe musi zwykle być sprzężony z istniejącą funkcjonalnością księgową. Oznacza to, że technical lead musi rozumieć podstawowe zasady działania księgowości.

Z własnego doświadczenia pamiętam, że proszono mnie o przegląd projektów zakończonych niepowodzeniem, które zawierały funkcje finansowe, gdzie poprzedni projektanci systemów i technical leadowie nie rozumieli podstaw dotyczących debetów i kredytów.

Współzależne czynniki w sukcesie projektu

W każdym projekcie systemów istnieją cztery współzależne czynniki:

  1. Koszt
  2. Jakość
  3. Szybkość
  4. Ryzyko

Nie jest możliwe osiągnięcie najkorzystniejszego stanu w każdym z tych czterech czynników. A konkretnie, nie możesz zbudować systemu niedrogo, zachowując wysoką jakość, zbudować go szybko i z niskim lub zerowym ryzykiem niepowodzenia. Większość dyskusji na temat tych czynników skupia się tylko na pierwszych trzech. Jest możliwe zbudowanie wysokiej jakości systemu szybko, na relatywnie niskim poziomie kosztowym dzięki pójściu na skróty i testując mało lub wcale. Jednakże ryzyko niepowodzenia takiego systemu wzrasta dramatycznie.

Spośród tych czterech czynników, dwa zawsze da się osiągnąć z sukcesem, zarządzając pozostałymi dwoma. Spośród tych czterech czynników dwa najważniejsze to ryzyko i jakość. System musi działać i skutecznie spełniać wymagania użytkownika. Kwestie szybkości (czas) i kosztu (pieniądze) pozostawia się do wyregulowania. Jeśli nalegasz na szybki czas developmentu lub niski koszt, wtedy jakość i ryzyko odpowiednio się zmienią.

Miałem wiele sprzeczek z menedżerami na temat tej zasady. Mówiono mi, że “jeśli użyjemy Produktu X i Metodyki Y, możemy zbudować system szybko i po kosztach.” Nie jest to stanowisko ani realistyczne, ani możliwe do obrony. Możesz nalegać na niskie ryzyko i wysoką jakość, uznając jednak fakt, że kwestie czasu i pieniędzy będą musiały zostać tak dopasowane, aby te cele osiągnąć.

Migracja danych i wdrożenie

Dwa dodatkowe czynniki w określaniu sukcesu lub porażki projektu, o których się często zapomina, to migracja danych i samo wdrażanie systemu.

Migracja danych powinna być zaplanowana na wczesny etap projektu. Migracja danych powinna być właściwie uważana za osobny projekt i rządzić się swoimi prawami.

Analogicznie, nawet kunsztowny, dobrze udokumentowany i dokładnie zaprojektowany system nadal w 10–20% przypadków może zakończyć się porażką z powodu niewłaściwego wdrażania. Może to być skutek nieprawidłowego szkolenia użytkowników, słabego przejścia ze starego do nowego systemu i brak wsparcia dla użytkownika w obchodzeniu się z nowym systemem.

 

Paul Dorsey

Założyciel i prezes Dulcian, Inc. (http://www.dulcian.com/), firmy konsultingowej doradzającej użytkownikom produktów Oracle. Dulcian specjalizuje się w hurtowniach danych, budowie systemów webowych i klienckich, oraz w produktach wspierających środowisko Oracle. Jest współautorem książek z serii Oracle Press, zatytułowanych Oracle Designer Handbook, Oracle Developer Forms and Reports: Advanced Techniques and Development Standards – razem z Peterem Koletzke, oraz Oracle8 Design Using UML Object Modeling – z Josephem Hudicka. Jest także zastępcą redaktora naczelnego SELECT Magazine i prezesem nowojorskiej Oracle Users’ Group. Prowadzi również blog pod adresem http://dulcian.com/category/blog/. Kontakt emailem (pdorsey@dulcian.com)

 

Tłumaczenie: Jacek Kobiela

 

Artykuł publikowany w magazynie „Zarządzanie Projektami” Nr 3(3)/2013

Komentarze

Brak komentarzy. Bądź pierwszy!

Podobne





Logo w stopce
KONTAKT

Portal zarzadzanieprojektami.org, Gdański Park Naukowo-Technologiczny
ul. Trzy Lipy 3, 80-172 Gdańsk
E-mail: biuro@e-zp.org
tel.: (+48) 501 794 318
Copyright © 2016. Wszystkie prawa zastrzeżone.
Projekt i wykonanie Interaktywna PIQUA