slyšeli jste ten o mizejícím skladu? Jednoho dne to zmizelo-ne z fyzického pohledu, ale z bdělých očí automatizovaného distribučního systému známého maloobchodníka. Softwarová závada nějak vymazala existenci skladu, takže zboží určené pro sklad bylo přesměrováno jinam, zatímco zboží ve skladu chátralo. Protože se firma dostala do finančních potíží a kvůli úspoře peněz zavírala další sklady, zaměstnanci „chybějícího“ skladu mlčeli. Tři roky nic nedorazilo ani neodešlo. Zaměstnanci však stále dostávali výplaty, protože výplatní listinu zpracoval jiný počítačový systém. Když se konečně objevila softwarová závada, zboží ve skladu bylo prodáno, a horní vedení řeklo zaměstnancům, aby o epizodě neřekli nic.
tento příběh se vznáší kolem odvětví informačních technologií po dobu 20-několik let. Je to asi apokryfní, ale pro ty z nás v oboru je to zcela věrohodné. Proč? Protože takové epizody se dějí pořád. Například loni v říjnu musel obří britský prodejce potravin J Sainsbury PLC odepsat svou investici ve výši 526 milionů USD do automatizovaného systému řízení dodavatelského řetězce. Zdá se, že zboží uvízlo ve skladech a skladech společnosti a nedostalo se do mnoha jejích obchodů. Sainsbury byl nucen najmout asi 3000 dalších úředníků, aby zásobili své police ručně .
toto je jen jeden z nejnovějších v dlouhé, skličující historii IT projektů, které se zhoršily . Většina IT odborníků souhlasí s tím, že k takovým selháním dochází mnohem častěji, než by měly. A co víc, selhání jsou všeobecně neodsuzovaná: stávají se v každé zemi; velkým společnostem a malým; v komerčních, neziskových a vládních organizacích; a bez ohledu na status nebo pověst. Obchodní a společenské náklady těchto selhání—pokud jde o zbytečné dolary daňových poplatníků a akcionářů, jakož i investice, které nelze provést-jsou nyní dobře do miliard dolarů ročně.
problém se jen zhoršuje, protože roste všudypřítomně. Letos organizace a vlády utratí odhadem 1 bilion dolarů za IT hardware, software a služby po celém světě. Z iniciovaných IT projektů bude 5 až 15 procent opuštěno před nebo krátce po dodání jako beznadějně nedostatečné. Mnoho dalších dorazí pozdě a přes rozpočet nebo vyžadují masivní přepracování. Jen málo IT projektů, jinými slovy, skutečně uspěje.
největší tragédií je, že selhání softwaru je z větší části předvídatelné a lze se mu vyhnout. Bohužel většina organizací nevidí prevenci selhání jako naléhavou záležitost, i když tento pohled může poškodit organizaci a možná ji dokonce zničit. Pochopení, proč tento postoj přetrvává, není jen akademické cvičení; má obrovské důsledky pro podnikání a společnost.
SOFTWARE JE VŠUDE. To je to, co nám umožňuje získat hotovost z bankomatu, telefonovat, a řídit naše auta. Typický mobilní telefon nyní obsahuje 2 miliony řádků softwarového kódu; do roku 2010 bude mít pravděpodobně 10krát tolik. General Motors Corp. odhaduje, že do té doby budou mít její vozy každý 100 milionů řádků kódu.
průměrná společnost utrácí asi 4 až 5 procent příjmů za informační technologie, přičemž ty, které jsou vysoce závislé na IT—jako jsou finanční a telekomunikační společnosti-na it utrácejí více než 10 procent. Jinými slovy, je to nyní jeden z největších firemních výdajů mimo náklady na zaměstnance. Hodně z těchto peněz jde do vylepšení hardwaru a softwaru, licenčních poplatků za software atd., ale velký kus je pro nové softwarové projekty, které mají vytvořit lepší budoucnost pro organizaci a její zákazníky.
vlády jsou také velkými spotřebiteli softwaru. V roce 2003 mělo Spojené Království více než 100 hlavních vládních IT projektů, které činily 20, 3 miliardy dolarů. V roce 2004 americká vláda katalogizovala 1200 civilních IT projektů v hodnotě více než 60 miliard dolarů plus dalších 16 miliard dolarů na vojenský software.
každý z těchto projektů může stát více než 1 miliardu dolarů. Abychom si vzali dva současné příklady, předpokládá se, že úsilí o modernizaci počítače na americkém ministerstvu pro záležitosti veteránů bude mít 3,5 miliardy dolarů, zatímco automatizace zdravotních záznamů britské Národní zdravotnické služby bude pravděpodobně stát více než 14,3 miliardy dolarů na vývoj a dalších 50,8 miliardy dolarů na nasazení.
takové megasoftwarové projekty, kdysi vzácné, jsou nyní mnohem častější, protože menší IT operace jsou spojeny do “ systémů systémů.“Řízení letového provozu je ukázkovým příkladem, protože se spoléhá na spojení mezi desítkami sítí, které poskytují komunikaci, počasí, navigaci a další data. Trik integrace však zmařil mnoho vývojářů IT do té míry, že akademičtí vědci stále více věří, že samotná Informatika bude možná muset být přehodnocena ve světle těchto masivně složitých systémů.
když projekt selže, ohrožuje vyhlídky organizace. Pokud je selhání dostatečně velké, může ukrást celou budoucnost společnosti. V jednom hvězdném zhroucení vedl špatně implementovaný systém plánování zdrojů FoxMeyer Drug Co., velkoobchodní společnost zabývající se distribucí drog ve výši 5 miliard dolarů v Carrolltonu v Texasu, která se v roce 1996 propadla do bankrotu.
it selhání ve vládě může ohrozit národní bezpečnost, jak ukázal debakl virtuálního spisu FBI. Systém VCF ve výši 170 milionů dolarů, Prohledávatelná databáze, která má agentům umožnit „spojit tečky“ a sledovat různorodé kousky inteligence, místo toho skončila před pěti měsíci, aniž by byl nasazen jakýkoli systém .
selhání IT může také zastavit ekonomický růst a kvalitu života. V roce 1981 se americký Federální úřad pro letectví začal zabývat modernizací svého zastaralého systému řízení letového provozu, ale snaha o vybudování náhrady se brzy stala prošpikovanou problémy . Do roku 1994, kdy se agentura konečně vzdala projektu, se předpokládané náklady ztrojnásobily, bylo vynaloženo více než 2, 6 miliardy dolarů a očekávané datum dodání se o několik let snížilo. Každý cestující v letadle, který je zpožděn kvůli zablokovaným skyways, stále cítí toto zrušení; kumulativní ekonomický dopad všech těchto zpoždění jen na americké aerolinky (nevadí pasažérům) se blíží 50 miliardám dolarů.
celosvětově je těžké říci, kolik softwarových projektů selže nebo kolik peněz je v důsledku toho zbytečné. Pokud definujete selhání jako úplné opuštění projektu před nebo krátce po jeho doručení, a pokud přijmete konzervativní míru selhání 5 procent, pak se každý rok plýtvá miliardami dolarů na špatný software.
například v roce 2004 USA vláda utratila 60 miliard dolarů za software (nepočítaje vestavěný software ve zbraňových systémech); 5% míra selhání znamená, že 3 miliardy dolarů byly pravděpodobně zbytečné. Po několika desetiletích jako IT konzultant jsem však přesvědčen, že míra selhání je 15 až 20 procent u projektů, které mají rozpočty 10 milionů dolarů nebo více. Při pohledu na celkové investice do nových softwarových projektů—vládních i firemních-za posledních pět let odhaduji, že selhání projektů pravděpodobně stálo americkou ekonomiku nejméně 25 miliard dolarů a možná až 75 miliard dolarů.
samozřejmě, že 75 miliard dolarů neodráží projekty, které převyšují jejich rozpočty – což většina projektů dělá. Neodráží ani projekty dodané pozdě—což je většina. Rovněž nezohledňuje náklady na příležitost, které budou muset začít znovu, jakmile bude projekt opuštěn, nebo náklady na systémy s chybami, které musí být opakovaně přepracovány.
pak jsou tu také náklady na soudní spory od rozzlobených zákazníků žalujících dodavatele za špatně implementované systémy. Když sečtete všechny tyto dodatečné náklady, roční karta pro neúspěšný a problémový software konzervativně běží někde od 60 miliard do 70 miliard dolarů pouze ve Spojených státech. Za tyto peníze byste mohli spustit raketoplán 100krát, postavit a nasadit celý globální polohovací systém 24 satelitů a vyvinout Boeing 777 od nuly—a ještě zbývá pár miliard.
proč projekty selhávají tak často?
Mezi nejčastější faktory:
- nerealistické nebo neartikulované cíle projektu
- nepřesné odhady potřebných zdrojů
- špatně definované systémové požadavky
- Špatné hlášení stavu projektu
- nespravovaná rizika
- špatná komunikace mezi zákazníky, vývojáři a uživateli
- použití nezralé technologie
- neschopnost zvládnout složitost projektu
- nedbalé rozvojové postupy
- špatné řízení projektů
- politika zúčastněných stran
- obchodní tlaky
samozřejmě, že IT projekty zřídka selhat jen z jednoho nebo dvou důvodů. Projekt FBI VCF trpěl mnoha výše uvedenými problémy. Většinu selhání lze ve skutečnosti vysledovat kombinací technických, projektových a obchodních rozhodnutí. Každá dimenze interaguje s ostatními komplikovanými způsoby, které zhoršují rizika a problémy projektu a zvyšují pravděpodobnost selhání.
zvažte jednoduchou softwarovou práci: nákupní systém, který automatizuje objednávání, fakturace a expedice dílů, takže prodejce může zadat objednávku zákazníka, nechat ji automaticky zkontrolovat podle cenových a smluvních požadavků a zařídit, aby byly díly a faktura zaslány zákazníkovi ze skladu.
požadavky na systém specifikují čtyři základní kroky. Za prvé, existuje proces prodeje, který vytváří prodejní doklad. Tento účet je poté zaslán právním procesem, který přezkoumá smluvní podmínky potenciálního prodeje a schválí je. Třetí v řadě je proces poskytování, který rozesílá smluvní díly, následovaný procesem financování, který odešle fakturu.
řekněme, že jak se píše první proces prodeje, programátoři zacházejí s každou objednávkou, jako by byla umístěna na hlavním místě společnosti, přestože společnost má pobočky v několika státech a zemích. Tato chyba zase ovlivňuje způsob výpočtu daně, jaký druh smlouvy je vydán a tak dále.
čím dříve je opomenutí detekováno a opraveno, tím lépe. Je to něco jako pletení svetru. Pokud si všimnete zmeškaného stehu hned poté, co to uděláte, můžete jednoduše rozluštit trochu příze a jít dál. Ale pokud nechcete chytit chybu až do konce, budete muset rozluštit celý svetr jen předělat, že jeden steh.
pokud softwarové kodéry nezachytí své opomenutí až do konečného testování systému – nebo ještě hůře, až po zavedení systému-náklady vynaložené na opravu chyby budou pravděpodobně mnohonásobně vyšší, než kdyby chybu zachytili, když stále pracovali na počátečním prodejním procesu.
a na rozdíl od zmeškaného stehu ve svetru je tento problém mnohem těžší určit; programátoři uvidí pouze to, že se objevují chyby, které mohou mít několik příčin. I po opravě původní chyby budou muset změnit další výpočty a dokumentaci a poté každý krok znovu otestovat.
ve skutečnosti studie ukázaly, že softwaroví specialisté tráví asi 40 až 50 procent svého času na přepracování, kterému se lze vyhnout, spíše než na to, čemu říkají práce s přidanou hodnotou, což je v podstatě práce, která se provádí hned napoprvé. Jakmile se kus softwaru dostane do terénu, náklady na opravu chyby mohou být 100krát vyšší, než by byly ve fázi vývoje.
pokud se vyskytnou chyby, může přepracování začít zaplavovat projekt, jako člun v bouři. Co je horší, pokusy o opravu chyby často zavádějí nové. Je to, jako byste zachraňovali ten člun, ale také vytváříte úniky. Pokud se vytvoří příliš mnoho chyb, náklady a čas potřebný k dokončení systému se stanou tak velkými, že to nedává smysl.
zjednodušeně řečeno, IT projekt obvykle selže, když přepracování překročí práci s přidanou hodnotou, která byla rozpočtována. To se stalo Sydney Water Corp., největšímu poskytovateli vody v Austrálii, když se v roce 2002 pokusil zavést automatizovaný informační a fakturační systém pro zákazníky . Podle šetření australského generálního auditora, mezi faktory, které odsoudily projekt, bylo nedostatečné plánování a specifikace, což zase vedlo k četným žádostem o změnu a významným přidaným nákladům a zpožděním. Sydney Water přerušila projekt uprostřed, poté, co utratila 61 milionů AU (33,2 milionu USD).
to vše nás vede ke zjevné otázce: proč se vyskytuje tolik chyb?
selhání softwarových projektů má mnoho společného s haváriemi letadel. Stejně jako piloti nikdy nehodlají havarovat, vývojáři softwaru nemají za cíl selhat. Když komerční letadlo havaruje, vyšetřovatelé se dívají na mnoho faktorů, jako je počasí, záznamy o údržbě, dispozice a výcvik pilota, a kulturní faktory v letecké společnosti. Podobně se musíme podívat na podnikatelské prostředí, technické řízení, řízení projektů a organizační kulturu, abychom se dostali ke kořenům selhání softwaru.
Hlavní mezi obchodní faktory patří konkurence a potřeba snížit náklady. Vyšší manažeři stále častěji očekávají, že IT oddělení budou dělat více s méně a dělat to rychleji než dříve; softwarové projekty nepovažují za investice, ale za čisté náklady, které je třeba kontrolovat.
politické požadavky mohou také způsobit zmatek v plánu, nákladech a kvalitě IT projektu. Když se mezinárodní letiště Denver pokusilo zavést svůj automatizovaný systém manipulace se zavazadly, státní a místní političtí vůdci drželi projekt jednoho nerealistického plánu za druhým. Nedodání systému včas zpozdilo otevření letiště (tehdy největšího ve Spojených státech) v roce 1995, což mnohonásobně zhoršilo finanční dopad.
ani poté, co byl systém dokončen, nikdy nefungoval spolehlivě: žvýkal zavazadla a vozíky používané k přepravě zavazadel kolem často vykolejily. Nakonec, United Airlines, hlavní nájemce letiště, žaloval dodavatele systému, a epizoda se stala důkazem nebezpečí politické účelnosti.
nedostatek podpory vyššího managementu může také zatracovat it podnik. To vede k tomu, že se nepodařilo přidělit dostatek peněz a pracovních sil, aby se jasně nestanovil vztah IT projektu k podnikání organizace. V roce 2000, prodejce Kmart Corp., v Troy, Mich., zahájila $1.4 miliardy úsilí o modernizaci IT zaměřené na propojení svých prodejních, marketingových, dodavatelských a logistických systémů, aby lépe konkurovaly konkurenční společnosti Wal-Mart Corp. v Bentonville v ARKu. Wal-Mart se však ukázal jako příliš impozantní a o 18 měsíců později Kmart omezil modernizaci a odepsal 130 milionů dolarů, které do něj již investoval. O čtyři měsíce později vyhlásila bankrot; společnost pokračuje v boji i dnes.
často, it projektoví manažeři touží dostat financované uchýlit k formě lhář pokeru, overpromising co jejich projekt udělá, kolik to bude stát, a když to bude dokončeno. Mnoho, ne-li většina, softwarové projekty začít s rozpočty, které jsou příliš malé. Když k tomu dojde, vývojáři musí tento nedostatek nějak vyrovnat, obvykle tím, že se snaží zvýšit produktivitu, snížit rozsah úsilí nebo přijmout riskantní zkratky ve fázi kontroly a testování. To vše zvyšuje pravděpodobnost chyby a nakonec selhání.
příkladem je nejmodernější cestovní rezervační systém vedený konsorciem rozpočtových Rent-A-Car, Hilton Hotels, Marriott a AMR, mateřské společnosti American Airlines. V roce 1992, tři a půl roku a 165 milionů dolarů do projektu, skupina opustila, citovala dva hlavní důvody: příliš optimistický plán rozvoje a podcenění technických obtíží. Byla to stejná skupina, která dříve vybudovala nesmírně úspěšný rezervační systém Sabre, což dokazuje, že minulá výkonnost není zárukou budoucích výsledků.
poté, co vyšetřovatelé havárie považují počasí za faktor havárie letadla, podívají se na samotné Letadlo. Bylo v konstrukci letadla něco, co způsobilo havárii? Nesla příliš velkou váhu?
při selhání it projektu se vždy objevují podobné otázky týkající se technických komponent projektu: hardwaru a softwaru použitého k vývoji systému a samotných vývojových postupů. Organizace jsou často sváděny sirénovou písní technologického imperativu-nekontrolovatelným nutkáním používat nejnovější technologie v naději, že získají konkurenční výhodu. S technologií, která se rychle mění a slibuje fantastické nové schopnosti, je snadné podlehnout. Ale použití nezralé nebo nevyzkoušené technologie je jistou cestou k selhání.
v roce 1997, po utrácení 40 milionů dolarů, stát Washington ukončil it projekt, který by zpracoval řidičské průkazy a registrace vozidel. Úředníci motorových vozidel připustili, že se chytili honit technologii místo toho, aby se soustředili na implementaci systému, který splňoval jejich požadavky. Debakl v oblasti IT, který o rok dříve snížil drogu FoxMeyer, také pramenil z přijetí nejmodernějšího systému plánování zdrojů a jeho posunutí nad rámec toho, co by mohl udělat.
pouhá velikost projektu je pramenem selhání. Studie ukazují, že velké projekty selhávají třikrát až pětkrát častěji než malé. Čím větší je projekt, tím větší je složitost jak v jeho statických prvcích (diskrétní části softwaru, hardwaru atd.), tak v jeho dynamických prvcích (vazby a interakce mezi hardwarem, softwarem a uživateli; připojení k jiným systémům atd.). Větší složitost zvyšuje možnost chyb, protože nikdo opravdu nerozumí všem interakčním částem celku nebo nemá schopnost je testovat.
vystřízlivění, ale pravda: je nemožné důkladně otestovat IT systém jakékoli skutečné velikosti. Roger S. Pressman ve své knize Softwarové inženýrství, jeden z klasických textů v oboru, poukázal na to, že “ vyčerpávající testování představuje určité logistické problémy….Dokonce i malý 100řádkový program s některými vnořenými cestami a jednou smyčkou provádějící méně než dvacetkrát může vyžadovat 10 až 14 možných cest, které mají být provedeny.“Otestovat všechny tyto 100 bilionů cest, poznamenal, za předpokladu, že každý by mohl být vyhodnocen v milisekundě, bude trvat 3170 let.
všechny IT systémy jsou vnitřně křehké. Ve velké cihlové budově byste museli odstranit stovky strategicky umístěných cihel, aby se zeď zhroutila. Ale v softwarovém programu 100 000-line, to trvá jen jeden nebo dva špatné linky produkovat velké problémy. V roce 1991 část telefonní sítě ATandamp;T zhasla a 12 milionů předplatitelů zůstalo bez služby, a to vše kvůli jedinému chybně napsanému znaku v jednom řádku kódu.
nedbalé vývojové postupy jsou bohatým zdrojem selhání a mohou způsobit chyby v jakékoli fázi IT projektu. Pomoci organizacím posoudit jejich postupy vývoje softwaru, USA. Software Engineering Institute, v Pittsburghu, vytvořil Capability Maturity Model, nebo CMM. Hodnotí praktiky společnosti proti pěti úrovním rostoucí zralosti. Úroveň 1 znamená, že organizace používá ad hoc a možná chaotické vývojové postupy. Úroveň 3 znamená, že společnost charakterizovala své praktiky a nyní jim rozumí. Úroveň 5 znamená, že organizace kvantitativně rozumí změnám v procesech a postupech, které uplatňuje.
od ledna téměř 2000 vládních a komerčních organizací dobrovolně hlásilo úrovně CMM. Více než polovina uznala, že je na úrovni 1 nebo 2, 30 procent bylo na úrovni 3, a pouze 17 procent dosáhlo úrovně 4 nebo 5. Procenta jsou ještě skličující, když si uvědomíte, že se jedná o Samostatně vybranou skupinu; společnosti s nejhoršími it postupy se samozřejmě nebudou podrobovat hodnocení CMM. (CMM je nahrazena integrací CMM, jejímž cílem je širší posouzení schopnosti organizace vytvářet systémy náročné na software.)
nezralé it praktiky odsoudily USA k zániku. Internal Revenue Service je úsilí o modernizaci ve výši 4 miliard dolarů v roce 1997 a nadále trápí současnou modernizaci IRS ve výši 8 miliard dolarů. Může být jen z podstaty nemožné převést daňový řád do softwarového kódu-daňové právo je složité a založené na často vágní legislativě a neustále se mění. Z pohledu it developera Je to noční můra. Finančnímu úřadu však nepomohlo otevřené nepřátelství mezi interními a externími programátory, směšné podcenění práce a mnoho dalších špatných praktik.
akce pilota těsně před pádem letadla jsou pro vyšetřovatele vždy velkým zájmem. Je to proto, že pilot je konečným rozhodovacím orgánem odpovědným za bezpečný provoz plavidla. Podobně projektoví manažeři hrají klíčovou roli v softwarových projektech a mohou být hlavním zdrojem chyb, které vedou k selhání.
v roce 1986 se Londýnská burza rozhodla automatizovat svůj systém pro vypořádání akciových transakcí. O sedm let později, poté, co utratil 600 milionů dolarů, zrušil vývoj systému Taurus, a to nejen proto, že návrh byl příliš složitý a těžkopádný, ale také proto, že řízení projektu bylo, použít slovo jednoho z jeho vlastních vedoucích pracovníků, „klamný.“Jak odhalilo vyšetřování, zdálo se, že nikdo nechce znát skutečný stav projektu, i když se objevovalo stále více problémů, chyběly termíny a náklady stoupaly .
nejdůležitější funkcí it projektového manažera je alokace zdrojů na různé činnosti. Kromě toho je projektový manažer zodpovědný za plánování a odhad projektů, kontrolu, organizaci, řízení smluv, řízení kvality, řízení rizik, komunikaci a řízení lidských zdrojů.
špatná rozhodnutí projektových manažerů jsou dnes pravděpodobně největší příčinou selhání softwaru. Špatné technické řízení naproti tomu může vést k technickým chybám, ale ty lze obecně izolovat a opravit. Špatné rozhodnutí o řízení projektů—například najímání příliš málo programátorů nebo výběr nesprávného typu smlouvy—však může způsobit zmatek. Například vývojáři rezervačního systému doomed travel tvrdí, že byli částečně omezeni použitím smlouvy s pevnou cenou. Taková smlouva předpokládá, že práce bude rutinní, rezervační systém se ukázal jako něco jiného než.
rozhodnutí o řízení projektů jsou často složitá právě proto, že zahrnují kompromisy založené na nejasných nebo neúplných znalostech. Odhadovat, kolik bude IT projekt stát a jak dlouho to bude trvat, je stejně umění jako věda. Čím větší nebo více nový projekt, tím méně přesné odhady. Je to běžící vtip v průmyslu, že odhady IT projektů jsou v nejlepším případě v rámci 25 procent jejich skutečné hodnoty 75 procent času.
existují i jiné způsoby, jak špatné řízení projektů může urychlit zánik softwarového projektu. Studie Institutu projektového řízení na Newtonově náměstí, Pa., ukázalo, že řízení rizik je nejméně praktikováno ze všech oborů projektového řízení ve všech průmyslových odvětvích a nikde se nepoužívá častěji než v IT průmyslu. Bez efektivního řízení rizik mají vývojáři softwaru malý přehled o tom, co se může pokazit, proč se může pokazit a co lze udělat pro odstranění nebo zmírnění rizik. Neexistuje ani způsob, jak určit, jaká rizika jsou přijatelná, což činí projektová rozhodnutí týkající se kompromisů téměř nemožnými.
špatné řízení projektů má mnoho dalších forem, včetně špatné komunikace, která vytváří nehostinnou atmosféru, která zvyšuje obrat, neinvestuje do školení zaměstnanců a v pravidelných intervalech nekontroluje pokrok projektu. Kterýkoli z nich může pomoci vykolejit softwarový projekt.
Poslední oblastí, kterou vyšetřovatelé zkoumají po letecké havárii, je organizační prostředí. Má letecká společnost silnou bezpečnostní kulturu, nebo zdůrazňuje především splnění letového řádu? V IT projektech je organizace, která si cení otevřenosti, poctivosti, komunikace a spolupráce, vhodnější najít a vyřešit chyby dostatečně brzy, aby přepracování nebylo ohromující.
pokud existuje téma, které prochází mučenou historií špatného softwaru, je to selhání konfrontace s realitou. Při mnoha příležitostech generální inspektor amerického ministerstva spravedlnosti, vnější panel odborníků a další řekli šéfovi FBI, že systém VCF je podle definice nemožný, a přesto projekt pokračoval. Stejné postoje existovaly mezi osobami odpovědnými za cestovní rezervační systém, Systém Taurus na londýnské burze, a projekt řízení letového provozu FAA-to vše svědčí o organizačních kulturách poháněných strachem a arogancí.
nedávná zpráva Národního kontrolního úřadu ve Velké Británii zjistila, že se doporučuje, aby vládní IT projekty nepokračovaly, a přesto pokračovaly. Spojené království má dokonce vládní oddělení pověřené prevencí jeho selhání, ale jak uvádí zpráva, více než polovina agentur, na které ministerstvo dohlíží, běžně ignoruje jeho rady. Tomuto typu chování říkám iracionální eskalace projektu-neschopnost zastavit projekt i poté, co je zřejmé, že pravděpodobnost úspěchu se rychle blíží nule. Bohužel, takové chování není v žádném případě jedinečné.
v konečném důsledku se velké softwarové selhání podobá nejhorší myslitelné havárii letadla, kdy pilot byl nezkušený, ale mimořádně zbrklý, letěl do ledové bouře v netestovaném letadle a pracoval pro leteckou společnost, která poskytla bezpečnost při snižování výcviku a údržby. Kdybyste si pak přečetli zprávu vyšetřovatele, kroutili byste hlavou a ptali se: „nebyla taková havárie nevyhnutelná?“
důvody, proč softwarové projekty selhávají, jsou dobře známy a byly dostatečně zdokumentovány v nesčetných článcích, zprávách a knihách . A ještě, selhání, téměř selhání, a obyčejný starý špatný software nás stále trápí, zatímco praktiky, o nichž je známo, že odvracejí chyby, se vyhýbají. Zdá se, že získání kvalitního softwaru včas a v rámci rozpočtu není ve většině organizací naléhavou prioritou.
nezdálo se, že by to bylo v Oxford Health Plans Inc., v Trumbull, Conn., v roce 1997. Automatizovaný fakturační systém společnosti byl životně důležitý, a přesto tamní vrcholoví manažeři měli větší zájem o rozšíření podnikání Oxfordu než o zajištění toho, aby jeho fakturační systém splňoval jeho současné potřeby . I když se objevily problémy, jako například rozesílání faktur s měsíčním zpožděním, manažeři nevěnovali pozornost. Když se fakturační systém účinně zhroutil, společnost ztratila desítky milionů dolarů a její akcie klesly z 68 na 26 dolarů na akcii za jeden den, čímž vymazala firemní hodnotu 3,4 miliardy dolarů. Akcionáři podali žaloby a několik vládních agentur vyšetřovalo společnost, která nakonec dostala pokutu 3 miliony dolarů za porušení předpisů.
zdá se, že i organizace, které se spálí špatnými softwarovými zkušenostmi, se nemohou nebo nechtějí poučit ze svých chyb. Ve zprávě z roku 2000 americká rada pro vědu o obraně, poradní orgán Ministerstva obrany, poznamenala, že různé studie zadané DOD učinily 134 doporučení pro zlepšení vývoje softwaru, ale pouze 21 z těchto doporučení bylo jednáno. Zbylých 113 bylo stále platných, poznamenala rada, ale byly ignorovány, i když si ministerstvo obrany stěžovalo na špatný stav vývoje obranného softwaru!
některé organizace se starají o kvalitu softwaru, jak dokazuje zkušenost firmy pro vývoj softwaru Praxis High Integrity Systems v Bath v Anglii. Praxe požaduje, aby se její zákazníci do projektu zapojili nejen finančně, ale i jako aktivní účastníci tvorby IT systému. Společnost také tráví obrovské množství času pochopením a definováním požadavků zákazníka a vyzývá zákazníky, aby vysvětlili, co chtějí a proč. Před napsáním jediného řádku kódu se zákazník i praxe dohodnou na tom, co je žádoucí, co je proveditelné a jaká rizika jsou s ohledem na dostupné zdroje spojena.
poté praxe uplatňuje přísný vývojový přístup, který omezuje počet chyb. Jednou z velkých výhod tohoto modelu je, že odfiltruje mnoho potenciálních klientů, kteří nejsou ochotni přijmout odpovědnost za formulování svých požadavků na IT a trávení času a peněz na jejich správnou implementaci.
určitá úroveň selhání softwaru bude vždy s námi. Skutečně potřebujeme skutečná selhání – na rozdíl od chyb, kterým se lze vyhnout—, abychom mohli pokračovat v technickém a hospodářském pokroku. Ale příliš mnoha selháním, ke kterým dnes dochází, se lze vyhnout. A jak se naše společnost spoléhá na IT systémy, které jsou stále větší, integrovanější a dražší, náklady na selhání mohou být katastrofálně vysoké.
i nyní je možné sázet na to, kde nastane další velký softwarový debakl. Jedním z mých předních kandidátů jsou IT systémy, které budou výsledkem americké vlády Americké zdravotnické informační komunity, spolupráce veřejného a soukromého sektoru, která se snaží definovat datové standardy pro elektronické lékařské záznamy. Myšlenka je, že jakmile budou definovány standardy, budou vybudovány IT systémy, které umožní lékařům po celé zemi digitálně zadávat záznamy o pacientech, což lékařům, nemocnicím, pojišťovnám a dalším zdravotnickým specialistům okamžitý přístup k úplné anamnéze pacienta. Odborníci ve zdravotnictví věří, že takový systém systémů zlepší péči o pacienty, sníží náklady odhadem o 78 miliard dolarů ročně a sníží lékařské chyby, což ušetří desítky tisíc životů.
ale tento přístup je pouhým snem, pokud softwarové postupy a míry selhání zůstanou tak, jak jsou dnes. I podle nejoptimističtějších odhadů bude vytvoření elektronického systému lékařských záznamů vyžadovat 10 let úsilí ,320 miliard dolarů v nákladech na vývoj a 20 miliard dolarů ročně v provozních výdajích-za předpokladu, že nedochází k poruchám,překročení, plánům, bezpečnostním problémům nebo chatrnému softwaru. To je stěží realistický scénář, zejména proto, že většina IT odborníků považuje lékařskou komunitu za nejméně počítačově zdatnou ze všech profesionálních podniků.
pacienti a daňoví poplatníci nakonec zaplatí cenu za vývoj nebo selhání takových boondoggles. Vzhledem k dnešním IT praktikám je neúspěch zřetelnou možností a byla by to ztráta nebývalého rozsahu. Ale pak, země po celém světě uvažují nebo již pracují na mnoha iniciativách podobné velikosti a dopadu—mimo jiné v letectví, národní bezpečnost, a armáda.
stejně jako elektřina, voda, Doprava a další kritické části naší infrastruktury se rychle stává nedílnou součástí naší každodenní existence. Za několik desetiletí se rozsáhlé selhání IT stane více než jen nákladnou nepříjemností: ohrozí to náš způsob života. Při absenci druhu oborových změn, které zmírní selhání softwaru, kolik z naší budoucnosti jsme ochotni vsadit na tyto nesmírně nákladné a složité systémy?
už víme, jak dělat software dobře. Možná je konečně čas jednat podle toho, co víme.