słyszałeś o znikającym magazynie? Pewnego dnia zniknął-nie z fizycznego widoku, ale z czujnych oczu zautomatyzowanego systemu dystrybucji znanego sprzedawcy detalicznego. Usterka oprogramowania w jakiś sposób wymazała istnienie magazynu, tak że towary przeznaczone do magazynu zostały przekierowane gdzie indziej, podczas gdy towary w magazynie osłabły. Ponieważ firma miała kłopoty finansowe i zamykała inne magazyny, aby zaoszczędzić pieniądze, pracownicy „zaginionego” magazynu milczeli. Przez trzy lata nic nie dotarło ani nie odeszło. Pracownicy nadal otrzymywali jednak wypłaty, ponieważ inny system komputerowy obsługiwał płace. Kiedy usterka oprogramowania w końcu wyszła na jaw, towar w magazynie został wyprzedany, a kierownictwo wyższego szczebla kazało pracownikom nic nie mówić o epizodzie.
ta historia krąży wokół branży informatycznej od 20-kilku lat. To prawdopodobnie apokryficzne, ale dla tych z nas w branży, jest to całkowicie prawdopodobne. Dlaczego? Bo takie epizody zdarzają się cały czas. Na przykład w październiku ubiegłego roku gigantyczny Brytyjski sprzedawca detaliczny żywności J Sainsbury PLC musiał odpisać 526 milionów dolarów na inwestycje w zautomatyzowany system zarządzania łańcuchem dostaw. Wydaje się, że towar utknął w magazynach i magazynach firmy i nie docierał do wielu sklepów. Sainsbury był zmuszony zatrudnić około 3000 dodatkowych urzędników, aby ręcznie zaopatrywać swoje półki .
to tylko jeden z najnowszych w długiej, ponurej historii nieudanych projektów IT . Większość ekspertów IT zgadza się, że takie awarie występują znacznie częściej niż powinny. Co więcej, niepowodzenia są powszechnie bezstronne: zdarzają się w każdym kraju; w dużych i małych firmach; w organizacjach komercyjnych, non-profit i rządowych; i bez względu na status lub reputację. Koszty biznesowe i społeczne tych niepowodzeń – w kategoriach zmarnowanych dolarów podatników i udziałowców, a także inwestycji, których nie można dokonać – są teraz w miliardach dolarów rocznie.
problem tylko się pogarsza, gdy staje się wszechobecny. W tym roku organizacje i rządy wydadzą około 1 bilion dolarów na sprzęt, oprogramowanie i usługi IT na całym świecie. Spośród zainicjowanych projektów IT od 5 do 15 procent zostanie porzuconych przed lub wkrótce po ich realizacji jako beznadziejnie niewystarczające. Wiele innych przybędzie z opóźnieniem i przekroczeniem budżetu lub wymaga masowych przeróbek. Niewiele projektów IT, innymi słowy, odnosi prawdziwy sukces.
największą tragedią jest to, że awaria oprogramowania jest w większości przewidywalna i możliwa do uniknięcia. Niestety, większość organizacji nie postrzega zapobiegania awariom jako pilnej sprawy, nawet jeśli ten widok może zaszkodzić organizacji, a może nawet ją zniszczyć. Zrozumienie, dlaczego ta postawa utrzymuje się, nie jest tylko ćwiczeniem akademickim; ma ogromne implikacje dla biznesu i społeczeństwa.
OPROGRAMOWANIE JEST WSZĘDZIE. To pozwala nam zdobyć gotówkę z bankomatu, zadzwonić i prowadzić samochody. Typowy telefon komórkowy zawiera teraz 2 miliony linii kodu oprogramowania; do 2010 roku prawdopodobnie będzie miał 10 razy więcej. General Motors Corp. szacuje się, że do tego czasu jego samochody będą miały po 100 milionów linijek kodu.
Przeciętna firma wydaje około 4 do 5 procent przychodów na technologie informatyczne, a te, które są w dużym stopniu zależne od IT—takie jak firmy finansowe i telekomunikacyjne-wydają na nią ponad 10 procent. Innymi słowy, jest to obecnie jeden z największych wydatków korporacyjnych poza kosztami pracowników. Znaczna część tych pieniędzy idzie na aktualizacje sprzętu i oprogramowania, opłaty licencyjne i tak dalej, ale duża część przeznaczona jest na nowe projekty oprogramowania mające na celu stworzenie lepszej przyszłości dla organizacji i jej klientów.
rządy też są wielkimi konsumentami oprogramowania. W 2003 R. Wielka Brytania miała ponad 100 głównych rządowych projektów informatycznych w toku, które wyniosły 20,3 mld USD. W 2004 r. rząd USA skatalogował 1200 cywilnych projektów informatycznych kosztujących ponad 60 miliardów dolarów plus kolejne 16 miliardów dolarów na oprogramowanie Wojskowe.
każdy z tych projektów może kosztować ponad miliard dolarów. Aby wziąć dwa obecne przykłady, projekt modernizacji komputera w amerykańskim Departamencie ds. weteranów ma kosztować 3,5 mld USD, podczas gdy automatyzacja dokumentacji medycznej brytyjskiej Narodowej Służby Zdrowia prawdopodobnie będzie kosztować ponad 14,3 mld USD na rozwój i kolejne 50,8 mld USD na wdrożenie.
takie projekty megasoftware, kiedyś rzadkie, są teraz znacznie bardziej powszechne, ponieważ mniejsze operacje IT są połączone w ” systemy systemów.”Kontrola ruchu lotniczego jest doskonałym przykładem, ponieważ opiera się na połączeniach między dziesiątkami sieci, które zapewniają komunikację, pogodę, nawigację i inne dane. Ale sztuczka integracji utrudnia wielu programistom IT, do tego stopnia, że naukowcy akademiccy coraz częściej wierzą, że sama Informatyka może wymagać ponownego przemyślenia w świetle tych ogromnie złożonych systemów.
kiedy projekt się nie powiedzie , zagraża to perspektywom organizacji. Jeśli awaria jest wystarczająco duża, może ukraść całą przyszłość firmy. W jednym z Gwiezdnych roztopów, źle wdrożony system planowania zasobów doprowadził FoxMeyer Drug Co., firma zajmująca się dystrybucją leków o wartości 5 miliardów dolarów w Carrollton w Teksasie, która upadła w 1996 roku.
to porażka w rządzie może zagrozić bezpieczeństwu narodowemu, jak pokazała fiasko wirtualnych akt sprawy FBI. System VCF wart 170 milionów dolarów, przeszukiwalna baza danych, która ma umożliwić agentom „łączenie kropek” i śledzenie różnych informacji wywiadowczych, zakończył się pięć miesięcy temu bez wdrożenia żadnego systemu .
niepowodzenia IT mogą również hamować wzrost gospodarczy i jakość życia. W 1981 roku Federalna Administracja Lotnictwa USA zaczęła rozważać modernizację swojego przestarzałego systemu kontroli ruchu lotniczego, ale wysiłek w celu zbudowania zamiennika wkrótce stał się pełen problemów . Do 1994 roku, kiedy Agencja ostatecznie zrezygnowała z projektu, przewidywane koszty potroiły się, wydano ponad 2,6 miliarda dolarów, a przewidywana data dostawy spadła o kilka lat. Każdy pasażer samolotu, który jest opóźniony z powodu zablokowanych skyways nadal czuje to odwołanie; skumulowany wpływ wszystkich tych opóźnień na tylko amerykańskie linie lotnicze (nieważne, że pasażerowie) zbliża się do 50 miliardów dolarów.
na całym świecie trudno powiedzieć, ile projektów oprogramowania zawodzi lub ile pieniędzy jest marnowanych w wyniku. Jeśli zdefiniujesz awarię jako całkowitą rezygnację z projektu przed lub krótko po jego dostarczeniu i jeśli zaakceptujesz konserwatywny wskaźnik niepowodzeń wynoszący 5 procent, co roku marnuje się miliardy dolarów na złe oprogramowanie.
rząd wydał 60 miliardów dolarów na oprogramowanie (nie licząc oprogramowania wbudowanego w systemy broni); wskaźnik awaryjności 5 procent oznacza, że prawdopodobnie zmarnowano 3 miliardy dolarów. Jednak po kilku dekadach jako konsultant IT jestem przekonany, że wskaźnik niepowodzeń wynosi od 15 do 20 procent dla projektów, które mają budżety 10 milionów dolarów lub więcej. Patrząc na całkowite inwestycje w nowe projekty programistyczne-zarówno rządowe, jak i korporacyjne—w ciągu ostatnich pięciu lat, szacuję, że niepowodzenia projektu prawdopodobnie kosztowały gospodarkę USA co najmniej 25 miliardów dolarów, a może nawet 75 miliardów dolarów.
oczywiście, że 75 miliardów dolarów nie odzwierciedla projektów, które przekraczają ich budżety – co robi większość projektów. Nie odzwierciedla to również projektów zrealizowanych z opóźnieniem—które są w większości. Nie uwzględnia również kosztów alternatywnych związanych z koniecznością rozpoczęcia Od Nowa, gdy projekt zostanie porzucony, ani kosztów systemów powodujących błędy, które muszą być wielokrotnie przerabiane.
wtedy też są koszty postępowania sądowego ze strony niezadowolonych klientów pozywających dostawców za źle wdrożone systemy. Po zsumowaniu wszystkich tych dodatkowych kosztów, roczna zakładka na uszkodzone i kłopotliwe oprogramowanie działa zachowawczo od 60 miliardów dolarów do 70 miliardów dolarów w samych Stanach Zjednoczonych. Za te pieniądze, można wystrzelić prom kosmiczny 100 razy, zbudować i wdrożyć cały 24-satelitarny globalny system pozycjonowania, i rozwijać Boeinga 777 od podstaw-i nadal ma kilka miliardów pozostało.
dlaczego projekty tak często zawodzą?
wśród najczęstszych czynników:
- nierealistyczne lub nieartykułowane cele projektu
- niedokładne szacunki potrzebnych zasobów
- źle zdefiniowane wymagania systemowe
- słabe raportowanie statusu projektu
- niezarządzane ryzyko
- słaba komunikacja między klientami, programistami i użytkownikami
- wykorzystanie niedojrzałych technologii
- niezdolność do radzenia sobie ze złożonością projektu
- niechlujne praktyki programistyczne
- złe zarządzanie projektami
- Polityka interesariuszy
- presja komercyjna
oczywiście projekty IT rzadko niepowodzenie z jednego lub dwóch powodów. Projekt VCF FBI cierpiał na wiele problemów wymienionych powyżej. W rzeczywistości większość błędów można przypisać połączeniu decyzji technicznych, zarządzania projektami i decyzji biznesowych. Każdy wymiar współdziała z innymi w skomplikowany sposób, który zaostrza ryzyko i problemy związane z projektem oraz zwiększa prawdopodobieństwo niepowodzenia.
rozważ prosty program: system zakupów, który automatyzuje zamawianie, fakturowanie i wysyłkę części, dzięki czemu sprzedawca może wprowadzić zamówienie klienta, automatycznie sprawdzić je pod kątem wymagań cenowych i umownych oraz zorganizować wysłanie części i faktury do klienta z magazynu.
wymagania dla systemu określają cztery podstawowe kroki. Po pierwsze, jest proces sprzedaży, który tworzy rachunek sprzedaży. Rachunek ten jest następnie przesyłany w procesie prawnym, który sprawdza warunki umowne potencjalnej sprzedaży i zatwierdza je. Trzeci z kolei jest proces dostarczania, który wysyła zamówione części, a następnie proces finansowy, który wysyła fakturę.
powiedzmy, że podczas pisania pierwszego procesu sprzedaży Programiści traktują każde zamówienie tak, jakby zostało złożone w głównej lokalizacji firmy, mimo że firma ma oddziały w kilku stanach i krajach. Ten błąd z kolei wpływa na sposób obliczania podatku, rodzaj umowy i tak dalej.
im szybciej pominięcie zostanie wykryte i poprawione, tym lepiej. To jak robienie swetra na drutach. Jeśli zauważysz brakujący ścieg zaraz po jego wykonaniu, możesz po prostu rozwikłać trochę przędzy i przejść dalej. Ale jeśli nie złapiesz błędu do końca, być może będziesz musiał rozwikłać cały sweter, aby przerobić ten jeden ścieg.
jeśli programiści nie złapią swojego pominięcia do czasu ostatecznego testowania systemu – lub co gorsza, do czasu wdrożenia systemu-koszty poniesione na naprawienie błędu będą prawdopodobnie wielokrotnie większe niż gdyby złapali błąd podczas pracy nad początkowym procesem sprzedaży.
i w przeciwieństwie do pominiętego szwu w swetrze, problem ten jest znacznie trudniejszy do zidentyfikowania; Programiści zobaczą tylko, że pojawiają się błędy, a te mogą mieć kilka przyczyn. Nawet po naprawieniu oryginalnego błędu będą musieli zmienić inne obliczenia i dokumentację, a następnie ponownie przetestować każdy krok.
w rzeczywistości badania wykazały, że specjaliści od oprogramowania spędzają około 40 do 50 procent swojego czasu na możliwych do uniknięcia przeróbkach, a nie na czymś, co nazywają pracą o wartości dodanej, która jest zasadniczo pracą wykonaną dobrze za pierwszym razem. Gdy oprogramowanie znajdzie się w terenie, koszt naprawienia błędu może być 100 razy wyższy niż na etapie rozwoju.
jeśli pojawią się błędy, przeróbka może zacząć bagno projektu, jak ponton w burzy. Co gorsza, próby naprawienia błędu często wprowadzają nowe. To tak, jakbyś ratował ponton, ale też tworzysz przecieki. Jeśli powstaje zbyt wiele błędów, koszt i czas potrzebny na ukończenie systemu stają się tak wielkie, że dzieje się nie ma sensu.
w najprostszych słowach, Projekt IT Zwykle zawodzi, gdy przeróbka przekracza wartość dodaną pracy, która została budżetowana. Tak właśnie stało się z Sydney Water Corp., największym dostawcą wody w Australii, gdy w 2002 r .próbowano wprowadzić zautomatyzowany system informacji o klientach i rozliczeń. Według dochodzenia przeprowadzonego przez australijskiego audytora Generalnego, wśród czynników, które skazały projekt były nieodpowiednie planowanie i specyfikacje, co z kolei doprowadziło do licznych wniosków o zmiany i znacznych dodatkowych kosztów i opóźnień. Sydney Water przerwało projekt w połowie drogi, wydając 61 mln AU (33,2 mln USD).
to wszystko prowadzi nas do oczywistego pytania: dlaczego pojawia się tak wiele błędów?
awarie projektów oprogramowania mają wiele wspólnego z awariami samolotów. Tak jak piloci nigdy nie zamierzają zawieść, programiści nie dążą do porażki. Gdy samolot komercyjny rozbija, badacze spojrzeć na wiele czynników, takich jak pogoda, rekordy konserwacji, dyspozycja pilota i szkolenia, i czynniki kulturowe w linii lotniczej. Podobnie, musimy spojrzeć na środowisko biznesowe, Zarządzanie techniczne, zarządzanie projektami i kulturę organizacyjną, aby dotrzeć do korzeni awarii oprogramowania.
głównymi czynnikami biznesowymi są konkurencja i potrzeba cięcia kosztów. Coraz częściej menedżerowie wyższego szczebla oczekują, że działy IT zrobią więcej za mniej i zrobią to szybciej niż wcześniej; postrzegają Projekty oprogramowania nie jako inwestycje, ale jako czyste koszty, które muszą być kontrolowane.
wymagania polityczne mogą również siać spustoszenie w harmonogramie, kosztach i jakości projektu IT. Kiedy Międzynarodowy port lotniczy w Denver próbował wdrożyć swój zautomatyzowany system obsługi bagażu, stanowi i lokalni przywódcy polityczni utrzymywali projekt według jednego nierealistycznego harmonogramu po drugim. Niedostarczenie systemu na czas opóźniło otwarcie w 1995 r.lotniska (wówczas największego w Stanach Zjednoczonych), co znacznie zwiększyło skutki finansowe.
nawet po ukończeniu systemu nigdy nie działał niezawodnie: żuł bagaż, a Wózki używane do przewozu bagażu często wykolejały się. Ostatecznie United Airlines, główny najemca lotniska, pozwał wykonawcę systemu, a epizod stał się świadectwem zagrożeń związanych z celowością polityczną.
brak wsparcia wyższego kierownictwa może również doprowadzić do powstania przedsiębiorstwa informatycznego. Prowadzi to od braku alokacji wystarczającej ilości pieniędzy i siły roboczej do nie wyraźnego ustalenia związku projektu IT z biznesem organizacji. W 2000 roku, Detalista Kmart Corp., w Troy, Mich., uruchomił 1 Dolar.4 miliardy działań modernizacyjnych IT mających na celu połączenie systemów sprzedaży, marketingu, dostaw i logistyki, aby lepiej konkurować z konkurencyjnym Wal-Mart Corp., w Bentonville, Ark. Wal-Mart okazał się jednak zbyt groźny, a 18 miesięcy później Kmart z gotówką ograniczył modernizację, odpisując 130 milionów dolarów, które już w nią zainwestował. Cztery miesiące później ogłosiła upadłość; firma nadal walczy do dziś.
często kierownicy projektów IT chcą uzyskać finansowanie uciekając się do formy kłamliwego pokera, przeceniając to, co zrobi ich projekt, ile będzie kosztował i kiedy zostanie ukończony. Wiele, jeśli nie większość, projektów oprogramowania zaczyna się od zbyt małych budżetów. Kiedy tak się dzieje, programiści muszą jakoś nadrobić niedobór, zazwyczaj próbując zwiększyć produktywność, zmniejszyć zakres wysiłku lub podjąć ryzykowne skróty w fazie przeglądu i testowania. Wszystko to zwiększa prawdopodobieństwo błędu i ostatecznie niepowodzenia.
najnowocześniejszy system rezerwacji podróży prowadzony przez konsorcjum Budget Rent-A-Car, Hilton Hotels, Marriott i AMR, spółkę dominującą American Airlines, jest przykładem. W 1992 roku, trzy i pół roku i 165 milionów dolarów na projekt, grupa porzuciła go, powołując się na dwa główne powody: zbyt optymistyczny harmonogram rozwoju i niedocenianie związanych z tym trudności technicznych. Była to ta sama grupa, która wcześniej zbudowała niezwykle udany system rezerwacji Sabre, udowadniając, że dotychczasowe wyniki nie są gwarancją przyszłych wyników.
po tym, jak śledczy uważają pogodę za czynnik katastrofy lotniczej, patrzą na sam samolot. Czy w konstrukcji samolotu było coś, co spowodowało katastrofę? Za duży ciężar?
w przypadku niepowodzeń projektu IT niezmiennie pojawiają się podobne pytania dotyczące komponentów technicznych projektu: sprzętu i oprogramowania używanego do rozwoju systemu oraz samych praktyk programistycznych. Organizacje są często uwodzone przez syreni śpiew imperatywu technologicznego-niekontrolowaną chęć korzystania z najnowszych technologii w nadziei na uzyskanie przewagi konkurencyjnej. Dzięki szybkiej zmianie technologii i obiecującym fantastycznym nowym możliwościom łatwo jest ulec. Ale użycie niedojrzałej lub niesprawdzonej technologii to pewna droga do porażki.
w 1997 roku, po wydaniu 40 milionów dolarów, Stan Waszyngton zamknął projekt informatyczny, który miał przetwarzać prawa jazdy i rejestracje pojazdów. Urzędnicy z branży motoryzacyjnej przyznali, że zamiast koncentrować się na wdrożeniu systemu spełniającego ich wymagania, zaplątali się w pogoń za technologią. Klęska informatyczna, która doprowadziła do upadku leku FoxMeyer rok wcześniej, wynikała również z przyjęcia najnowocześniejszego systemu planowania zasobów, a następnie przesunięcia go poza to, co może zrobić.
sama wielkość projektu to źródło porażki. Badania wskazują, że projekty na dużą skalę zawodzą trzy do pięciu razy częściej niż małe. Im większy projekt, tym większa jest złożoność zarówno jego elementów statycznych (dyskretne elementy oprogramowania, sprzętu itp.), jak i elementów dynamicznych (sprzężenia i interakcje między sprzętem, oprogramowaniem i użytkownikami; połączenia z innymi systemami itp.). Większa złożoność zwiększa możliwość błędów, ponieważ nikt tak naprawdę nie rozumie wszystkich oddziałujących części całości ani nie ma możliwości ich przetestowania.
otrzeźwiające, ale prawdziwe: nie da się dokładnie przetestować systemu informatycznego dowolnej wielkości. Roger S. Pressman wskazał w swojej książce Software Engineering, jeden z klasycznych tekstów w tej dziedzinie, że ” wyczerpujące testy przedstawiają pewne problemy logistyczne….Nawet mały 100-liniowy program z niektórymi zagnieżdżonymi ścieżkami i pojedynczą pętlą wykonującą mniej niż dwadzieścia razy może wymagać wykonania 10 do potęgi 14 możliwych ścieżek.”Aby przetestować wszystkie te 100 trylionów ścieżek, zauważył, zakładając, że każda może być oceniona w milisekundzie, zajęłoby 3170 lat.
wszystkie systemy informatyczne są z natury kruche. W dużym ceglanym budynku musisz usunąć setki strategicznie rozmieszczonych cegieł, aby zawalić ścianę. Ale w 100 000-liniowym programie, potrzeba tylko jednej lub dwóch złych linii, aby wytworzyć poważne problemy. W 1991 roku część sieci telefonicznej ATandamp;T została wyłączona, pozostawiając 12 milionów abonentów bez usługi, wszystko z powodu jednego źle wpisanego znaku w jednej linii kodu.
niechlujne praktyki programistyczne są bogatym źródłem niepowodzeń i mogą powodować błędy na każdym etapie projektu IT. Aby pomóc organizacjom w ocenie ich praktyk programistycznych, USA Software Engineering Institute w Pittsburghu stworzył model dojrzałości zdolności (ang. Capability Maturity Model, CMM). Ocenia praktyki firmy na pięć poziomów rosnącej dojrzałości. Poziom 1 oznacza, że organizacja stosuje doraźne i ewentualnie chaotyczne praktyki rozwojowe. Poziom 3 oznacza, że firma scharakteryzowała swoje praktyki i teraz je rozumie. Poziom 5 oznacza, że organizacja ilościowo rozumie różnice w procesach i praktykach, które stosuje.
w styczniu prawie 2000 organizacji rządowych i komercyjnych dobrowolnie zgłosiło poziomy CMM. Ponad połowa przyznała, że jest na poziomie 1 lub 2, 30 procent było na poziomie 3, a tylko 17 procent osiągnęło poziom 4 lub 5. Procenty są jeszcze bardziej ponure, gdy zdajesz sobie sprawę, że jest to grupa self-selected; oczywiście, firmy z najgorszymi praktykami IT nie poddadzą się ocenie CMM. (CMM jest zastępowana przez CMM-Integration, która ma na celu szerszą ocenę zdolności organizacji do tworzenia systemów intensywnie programujących.)
niedojrzałe praktyki it skazały USA na porażkę. Internal Revenue Service 'S $ 4 miliardowy wysiłek modernizacyjny w 1997 roku, a oni nadal plaga IRS’ s bieżącego $ 8 miliard modernizacja. Tłumaczenie kodeksu podatkowego na kod oprogramowania może być po prostu niemożliwe—prawo podatkowe jest skomplikowane i oparte na często niejasnych przepisach i ciągle się zmienia. Z punktu widzenia programisty IT jest to koszmar wymagań. Ale IRS nie pomógł przez otwartą wrogość między wewnętrznymi i zewnętrznymi programistami, Śmieszne niedocenianie pracy i wiele innych złych praktyk.
działania pilota tuż przed katastrofą samolotu zawsze cieszą się dużym zainteresowaniem badaczy. To dlatego, że pilot jest ostatecznym decydentem, odpowiedzialnym za bezpieczną eksploatację jednostki. Podobnie kierownicy projektów odgrywają kluczową rolę w projektach oprogramowania i mogą być głównym źródłem błędów, które prowadzą do awarii.
w 1986 roku Londyńska Giełda Papierów Wartościowych postanowiła zautomatyzować swój system rozliczania transakcji giełdowych. Siedem lat później, po wydaniu 600 milionów dolarów, porzucił rozwój systemu Taurus, nie tylko dlatego, że projekt był zbyt skomplikowany i uciążliwy, ale także dlatego, że zarządzanie projektem było, używając słowa jednego z własnych menedżerów, ” urojone.”Jak ujawniły badania, nikt nie chciał znać prawdziwego statusu projektu, nawet gdy pojawiało się coraz więcej problemów, brakowało terminów, a koszty rosły .
najważniejszą funkcją kierownika projektu IT jest alokacja zasobów na różne działania. Ponadto kierownik projektu jest odpowiedzialny za planowanie i szacowanie projektu, kontrolę, organizację, zarządzanie kontraktami, zarządzanie jakością, Zarządzanie ryzykiem, komunikację i zarządzanie zasobami ludzkimi.
złe decyzje kierowników projektów są prawdopodobnie największą przyczyną awarii oprogramowania. Natomiast złe zarządzanie TECHNICZNE może prowadzić do błędów technicznych, ale można je ogólnie wyizolować i naprawić. Jednak zła decyzja o zarządzaniu projektami-taka jak zatrudnienie zbyt małej liczby programistów lub wybranie niewłaściwego rodzaju umowy-może siać spustoszenie. Na przykład twórcy skazanego na zagładę systemu rezerwacji podróży twierdzą, że zostali pokuśnięci częściowo przez zastosowanie umowy o stałej cenie. Taka umowa zakłada, że praca będzie rutynowa; system rezerwacji okazał się niczym innym.
decyzje w zakresie zarządzania projektami są często trudne właśnie dlatego, że wiążą się z kompromisami w oparciu o rozmytą lub niepełną wiedzę. Szacowanie, ile będzie kosztował Projekt IT i ile potrwa, to tyle samo sztuki, co nauki. Im większy lub bardziej nowatorski projekt, tym mniej dokładne szacunki. To żart w branży, że szacunki projektów IT są w najlepszym przypadku w granicach 25 procent ich prawdziwej wartości w 75 procentach czasu.
istnieją inne sposoby, że złe zarządzanie projektami może przyspieszyć upadek projektu oprogramowania. Badanie przeprowadzone przez Project Management Institute, w Newton Square, Pa., pokazał, że zarządzanie ryzykiem jest najmniej praktykowane ze wszystkich dyscyplin zarządzania projektami we wszystkich sektorach przemysłu i nigdzie nie jest ono tak rzadko stosowane jak w branży IT. Bez skutecznego zarządzania ryzykiem twórcy oprogramowania mają niewielki wgląd w to, co może pójść nie tak, dlaczego może pójść nie tak i co można zrobić, aby wyeliminować lub złagodzić ryzyko. Nie ma również sposobu na określenie, jakie ryzyko jest dopuszczalne, co z kolei sprawia, że decyzje projektowe dotyczące kompromisów są prawie niemożliwe.
złe zarządzanie projektem przybiera wiele innych form, w tym złą komunikację, która tworzy niegościnną atmosferę, która zwiększa obroty; nie inwestuje w szkolenie personelu; i nie przegląda postępów projektu w regularnych odstępach czasu. Każdy z nich może pomóc wykoleić projekt oprogramowania.
ostatnim obszarem, który badacze sprawdzają po katastrofie lotniczej, jest środowisko organizacyjne. Czy linia lotnicza ma silną kulturę bezpieczeństwa, czy też kładzie nacisk na spełnienie rozkładu lotów przede wszystkim? W projektach IT organizacja, która ceni otwartość, uczciwość, komunikację i współpracę, jest bardziej skłonna do znajdowania i rozwiązywania błędów na tyle wcześnie, że przeróbki nie stają się przytłaczające.
jeśli istnieje temat, który biegnie przez udręczoną historię złego oprogramowania, to jest to niepowodzenie w konfrontacji z rzeczywistością. Przy wielu okazjach Generalny Inspektor Departamentu Sprawiedliwości USA, zewnętrzny panel ekspertów i inni mówili szefowi FBI, że system VCF jest niemożliwy do zdefiniowania, a mimo to projekt był kontynuowany. Te same postawy istniały wśród osób odpowiedzialnych za system rezerwacji podróży, System Taurus na Londyńskiej Giełdzie Papierów Wartościowych i projekt kontroli ruchu lotniczego FAA-wszystko to wskazuje na kulturę organizacyjną napędzaną strachem i arogancją.
w ostatnim raporcie National Audit Office w Wielkiej Brytanii stwierdzono, że wiele przypadków rządowych projektów informatycznych jest zalecanych, aby nie iść do przodu, a mimo to kontynuować. Wielka Brytania ma nawet departament rządowy, którego zadaniem jest zapobieganie awariom IT, ale jak zauważono w raporcie, ponad połowa agencji nadzorowanych przez Departament rutynowo ignoruje jego porady. Nazywam tego typu zachowanie irracjonalną eskalacją projektu-niezdolność do zatrzymania projektu nawet po tym, jak oczywiste jest, że prawdopodobieństwo sukcesu szybko zbliża się do zera. Niestety, takie zachowanie nie jest w żaden sposób wyjątkowe.
w ostatecznym rozrachunku, Duże awarie oprogramowania przypominają najgorszą możliwą katastrofę lotniczą, w której pilot był niedoświadczony, ale niezwykle pochopny, wleciał w burzę lodową niesprawdzonym samolotem i pracował dla linii lotniczych, które świadczyły usługi bezpieczeństwa, jednocześnie ograniczając szkolenia i konserwację. Jeśli przeczytasz raport śledczego później, kręcisz głową i pytasz :”czy taki wypadek nie był nieunikniony?”
przyczyny niepowodzenia projektów oprogramowania są dobrze znane i zostały obszernie udokumentowane w niezliczonych artykułach, raportach i książkach . A jednak, awarie, prawie awarie i zwykłe stare złe oprogramowanie nadal nękają nas, podczas gdy praktyki znane z unikania błędów są unikane. Wydaje się, że uzyskanie wysokiej jakości oprogramowania na czas i w ramach budżetu nie jest pilnym priorytetem w większości organizacji.
, in Trumbull, Conn., w 1997. Zautomatyzowany system bilingowy firmy był kluczowy dla jej wyników finansowych, a jednak menedżerowie wyższego szczebla byli bardziej zainteresowani rozszerzeniem działalności Oxford niż zapewnieniem, że system bilingowy może zaspokoić obecne potrzeby . Nawet gdy pojawiły się problemy, takie jak faktury wysyłane z wielomiesięcznym opóźnieniem, menedżerowie nie zwracali uwagi. Kiedy system rozliczeniowy skutecznie upadł, firma straciła dziesiątki milionów dolarów, a jej akcje spadły z 68 do 26 dolarów na akcję w ciągu jednego dnia, wymazując 3,4 miliarda dolarów wartości korporacyjnej. Akcjonariusze wnieśli pozwy sądowe, a kilka agencji rządowych zbadało firmę, która ostatecznie została ukarana grzywną w wysokości 3 milionów dolarów za naruszenia przepisów.
nawet organizacje, które zostają spalone przez złe doświadczenia oprogramowania, wydają się niezdolne lub niechętne do uczenia się na swoich błędach. W raporcie z 2000 roku Amerykańska Rada Naukowa ds. obrony (U. S. Defense Science Board), organ doradczy Departamentu Obrony, zauważyła, że różne badania zlecone przez DOD zawierały 134 zalecenia dotyczące poprawy rozwoju oprogramowania, ale tylko 21 z nich zostało zrealizowanych. Pozostałe 113 były nadal ważne, Zarząd zauważył, ale były ignorowane, nawet jak DOD skarżył się na zły stan rozwoju oprogramowania obronnego!
niektóre organizacje dbają o jakość oprogramowania, o czym świadczy doświadczenie firmy programistycznej Praxis High Integrity Systems z Bath w Anglii. Praxis wymaga od swoich klientów zaangażowania w projekt, nie tylko finansowego, ale także aktywnego uczestnictwa w tworzeniu systemu informatycznego. Firma poświęca również ogromną ilość czasu na zrozumienie i zdefiniowanie wymagań klienta, a także rzuca klientom wyzwanie wyjaśnienia, czego chcą i dlaczego. Przed napisaniem pojedynczej linii kodu zarówno klient, jak i praktyka uzgadniają, co jest pożądane, co jest wykonalne i jakie ryzyko jest związane z dostępnymi zasobami.
następnie Praxis stosuje rygorystyczne podejście do rozwoju, które ogranicza liczbę błędów. Jedną z wielkich zalet tego modelu jest to, że odfiltrowuje on wielu potencjalnych klientów, którzy nie chcą przyjąć odpowiedzialności za sformułowanie swoich wymagań IT i poświęcenie czasu i pieniędzy na ich właściwe wdrożenie.
pewien poziom awarii oprogramowania zawsze będzie z nami. Rzeczywiście, potrzebujemy prawdziwych niepowodzeń – w przeciwieństwie do możliwych do uniknięcia błędów—aby nadal czynić postęp techniczny i gospodarczy. Ale zbyt wielu niepowodzeń, które mają miejsce dzisiaj, można uniknąć. A ponieważ nasze społeczeństwo opiera się na systemach informatycznych, które są coraz większe, bardziej zintegrowane i droższe, koszty awarii mogą stać się katastrofalnie wysokie.
nawet teraz można obstawiać, gdzie nastąpi kolejna wielka porażka oprogramowania. Jednym z moich wiodących kandydatów są systemy informatyczne, które będą wynikiem amerykańskiej społeczności informacji o zdrowiu rządu USA, współpracy publiczno-prywatnej, która ma na celu zdefiniowanie standardów danych dla elektronicznej dokumentacji medycznej. Chodzi o to, że po zdefiniowaniu standardów zostaną zbudowane systemy informatyczne, aby umożliwić pracownikom służby zdrowia w całym kraju cyfrowe wprowadzanie danych pacjentów, dając lekarzom, szpitalom, ubezpieczycielom i innym specjalistom w dziedzinie opieki zdrowotnej natychmiastowy dostęp do pełnej historii medycznej pacjenta. Eksperci w dziedzinie opieki zdrowotnej uważają, że taki system systemów poprawi opiekę nad pacjentami, obniży koszty o około 78 miliardów dolarów rocznie i zmniejszy liczbę błędów medycznych, ratując dziesiątki tysięcy istnień ludzkich.
ale takie podejście jest zwykłym marzeniem, jeśli praktyki oprogramowania i wskaźniki awaryjności pozostają takie, jakie są dzisiaj. Nawet według najbardziej optymistycznych szacunków stworzenie elektronicznego systemu dokumentacji medycznej będzie wymagało 10 lat wysiłku, 320 miliardów dolarów kosztów rozwoju i 20 miliardów dolarów rocznie kosztów operacyjnych-zakładając, że nie ma awarii, przekroczeń, poślizgów harmonogramu, problemów z bezpieczeństwem lub tandetnego oprogramowania. Nie jest to realistyczny scenariusz, zwłaszcza że większość ekspertów IT uważa społeczność medyczną za najmniej doświadczoną komputerowo ze wszystkich profesjonalnych przedsiębiorstw.
pacjenci i podatnicy w końcu zapłacą cenę za rozwój, lub niepowodzenie takich głupstw. Biorąc pod uwagę dzisiejsze praktyki IT, porażka jest wyraźną możliwością i byłaby stratą o bezprecedensowej skali. Ale kraje na całym świecie rozważają lub już pracują nad wieloma inicjatywami o podobnej wielkości i wpływie-między innymi w lotnictwie, bezpieczeństwie narodowym i wojsku.
podobnie jak elektryczność, woda, transport i inne krytyczne części naszej infrastruktury, szybko stają się nieodłącznym elementem naszej codziennej egzystencji. W ciągu kilku dekad awaria informatyczna na dużą skalę stanie się czymś więcej niż tylko kosztowną niedogodnością: to narazi nasz styl życia. W przypadku braku tego rodzaju przemysłowych zmian, które złagodzą awarie oprogramowania, jak wiele z naszej przyszłości jesteśmy gotowi zaryzykować na tych ogromnie kosztownych i złożonych systemach?
wiemy już, jak dobrze zrobić oprogramowanie. Może wreszcie nadszedł czas, aby działać na tym, co wiemy.