Dlaczego duże projekty IT zwykle kończą się niepowodzeniem lub mają duże przekroczenia kosztów / harmonogramu? [Zamknięte]

Zawsze czytam o dużych projektach transformacji lub integracji, które są totalną lub prawie całkowitą katastrofą. Nawet jeśli uda im się jakoś odnieść sukces, koszty i harmonogram wypalenia są ogromne. Jaki jest prawdziwy powód, dla którego duże projekty są bardziej podatne na niepowodzenia. Można stosować zwinne w tego typu projektach lub tradycyjne podejście jest nadal najlepsze.

Jednym z przykładów z Australii jest projekt listy płac w Queensland, w którym zmieniono kryteria sukcesu testu w celu dostarczenia projektu.
Zobacz więcej nieudanych projektów w tym pytaniu SO ( na Wayback Machine )

Czy masz jakieś osobiste doświadczenia, którymi możesz się podzielić?

Głównym powodem jest zwiększenie zakresu , które książka „The Pragmatic Programmer” opisuje jako:

• nadyma się
• pełzający featuryzm
• pełzanie wymagań

Jest to aspekt zespołu gotowanej żaby.

Ideą różnych metod „zwinnych” jest przyspieszenie informacji zwrotnych i - miejmy nadzieję - skorygowanie ewolucji projektu w czasie.

Ale drugim powodem jest zarządzanie wydaniami : jeśli nie jesteś nastawiony na wydanie projektu (jakkolwiek może być niedoskonały), istnieje prawdopodobieństwo, że się nie powiedzie (ponieważ został wydany zbyt późno, ze zbyt wieloma błędnymi funkcjami i trudniej go naprawić / zaktualizować / Aktualizacja).

Nie oznacza to, że musisz mieć ustaloną datę wydania, ale oznacza to, że musisz być w stanie zbudować działającą wersję programu, aby go przetestować / ocenić / wydać.

Wpis na blogu „ Spóźnione projekty są spóźnione jeden dzień na raz ” zawiera wiele innych przykładów:

Wiem, że prawdziwą sprawą byłoby uelastycznienie zakresu i utrzymanie stałej daty premiery, ale to nie działa, jeśli uzgodniono funkcjonalność, której nie można ukończyć na czas.

Dlatego nie opowiadamy się za specyfikacjami ani „uzgodnioną funkcjonalnością”. To jest podstawa problemu - mówiąc, że wiesz wszystko o tym, czego potrzebujesz i w jaki sposób zostanie on wdrożony, nawet zanim zostanie namalowany pierwszy piksel lub napisany wiersz kodu. .

Kiedy przewidujesz sztywną przyszłość elastycznego prezentu, masz kłopoty. Sztywna przyszłość jest jedną z najbardziej niebezpiecznych rzeczy. Nie pozostawiają miejsca na odkrycia, pojawienie się i błędy, które otwierają nowe drzwi.

Zwykle złożoność projektu jest niedoceniana .

Steve McConnell (sławny „Code Complete”) ma listę klasycznych błędów .

Wiele nieefektywnych praktyk rozwojowych jest wybieranych przez tak wielu ludzi z tak przewidywalnymi, złymi wynikami, że zasługują na miano „klasycznych błędów” ...

W tej sekcji wymieniono trzy tuziny klasycznych błędów. Osobiście widziałem każdy z tych błędów co najmniej raz i sam popełniłem wiele z nich ...

Wspólnym mianownikiem na tej liście jest to, że niekoniecznie będziesz musiał szybko się rozwijać, jeśli unikniesz błędu, ale na pewno dostaniesz powolny rozwój, jeśli go nie unikniesz ...

Dla ułatwienia lista została podzielona wzdłuż wymiarów szybkości rozwoju ludzi, procesów, produktów i technologii.

Ludzie

# 1: Podważona motywacja ...

# 2: Słaby personel ...

# 3: Niekontrolowani problematyczni pracownicy ...

# 4: Heroika ...

# 5: Dodawanie ludzi do późnego projektu ...

# 6: Głośne, zatłoczone biura ...

# 7: Tarcie między deweloperami a klientami ...

# 8: Nierealne oczekiwania ...

# 9: Brak skutecznego sponsoringu projektu ...

# 10: Brak wpisu interesariuszy ...

# 11: Brak danych wprowadzanych przez użytkownika ...

# 12: Polityka umieszczona nad treścią ...

# 13: Myślenie życzeniowe ...

Proces

# 14: Zbyt optymistyczne harmonogramy ...

# 15: Niewystarczające zarządzanie ryzykiem ...

# 16: Awaria wykonawcy ...

# 17: Niewystarczające planowanie ...

# 18: Porzucenie planowania pod presją ...

# 19: Zmarnowany czas podczas rozmytego frontu. „Rozmyty interfejs” to czas przed rozpoczęciem projektu, czas zwykle poświęcony na proces zatwierdzania i budżetowania ...

# 20: Krótkie działania upstream ... Znany również jako „skok w kodowanie” ...

# 21: Niewłaściwy projekt ...

# 22: Krótkotrwała kontrola jakości ...

# 23: Niewystarczające kontrole zarządzania ...

# 24: Przedwczesna lub zbyt częsta konwergencja. Na krótko przed planowanym wydaniem produktu pojawia się nacisk na przygotowanie produktu do wydania - poprawa wydajności produktu, wydrukowanie ostatecznej dokumentacji, włączenie ostatecznych haków systemu pomocy, dopracowanie programu instalacyjnego, wyeliminowanie funkcjonalności, która nie będzie gotowe na czas i tak dalej ...

# 25: Pominięcie niezbędnych zadań w szacunkach ...

# 26: Planuje nadrobić zaległości później ...

# 27: Programowanie przypominające piekło. Niektóre organizacje uważają, że szybkie, luźne kodowanie na bieżąco jest drogą do szybkiego rozwoju ...

Produkt

# 28: Wymagania pozłacanie. Niektóre projekty mają od samego początku więcej wymagań niż potrzebują ...

# 29: Pełzanie funkcji ...

# 30: Pozłacanie programistów. Programiści są zafascynowani nową technologią i czasami chcą wypróbować nowe funkcje ... - niezależnie od tego, czy jest to wymagane w ich produkcie ...

# 31: Popchnij mnie, pociągnij mnie do negocjacji ...

# 32: Rozwój zorientowany na badania. Seymour Cray, projektant superkomputerów Cray, mówi, że nie próbuje przekraczać ograniczeń technicznych w więcej niż dwóch obszarach jednocześnie, ponieważ ryzyko awarii jest zbyt wysokie (Gilb 1988). Wiele projektów oprogramowania może wyciągnąć naukę z Cray ...

Technologia

# 33: Zespół Silver-Bulleta ...

# 34: Przeszacowane oszczędności wynikające z nowych narzędzi lub metod ... Szczególny przypadek zawyżonych oszczędności powstaje, gdy projekty ponownie wykorzystują kod z poprzednich projektów ...

# 35: Przełączanie narzędzi w trakcie projektu ...

# 36: Brak automatycznej kontroli kodu źródłowego ...

Większy projekt = większa złożoność
większa złożoność = większa niepewność
większa niepewność = trudniejsza do oszacowania
trudniejsza do oszacowania = złe oszacowanie
złe oszacowanie = przekroczenie kosztów

Obwiniam proces licytacji. Nagradza grupę, która może sprawić, że umowa będzie wyglądać najtaniej / najszybciej na papierze.

Ludzie składający oferty nie chcą tracić czasu, jeśli nie mają szans na wygraną, więc ich normalne szacunki zostają zawieszone. Znam ludzi, którzy wybrali normalne przełączniki zamiast przełączników POE, aby zaoszczędzić 80 USD. Ale projekt potrzebował POE, ponieważ miał kamery IP. 80 dolarów trzeba wydać, ale teraz jest to poza specyfikacją.

Jestem głęboko przekonany, że 2-miesięczny projekt o wartości 2 000 000 USD będzie nadal trwał 2 miesiące 2 000 000 USD bez względu na liczbę otrzymanych ofert. Jeśli uważasz, że robienie tego dobrze jest drogie, poczekaj i zobacz, jak drogie jest zrobić to źle.

Jednym z możliwych powodów jest to, że szacunki opierają się na mniejszych projektach, zakładając liniowy wzrost kosztów wraz z wielkością projektu, podczas gdy w rzeczywistości wzrost kosztów jest np. Kwadratowy ze względu na rosnącą złożoność, dłuższy czas trwania projektu (więcej czasu na zmiany wymagań) itp. Szacowanie jest trudny, a im większy projekt, tym trudniej jest go poprawnie oszacować.

Innym powodem są uprzedzenia optymistyczne: Aby wygrać licytację, do obliczenia ceny stosuje się szacunki oparte na najlepszych przypadkach. Im większy projekt, tym mniej prawdopodobny jest najlepszy scenariusz. Reguły licytacji sprawiają, że najbardziej optymistyczny oferent otrzymuje akceptację, więc nawet jeśli 5 sprzedawców dokona realistycznego oszacowania, a szósty jest zbyt optymistyczny, optymistyczny wygrywa licytację, a później zawiedzie. Jest to więc rodzaj selekcji negatywnej.

Koszt nie wyklucza harmonogramu w oczach „kierownictwa”, co jest ważnym rozróżnieniem. Jak wiemy, „dziewięć kobiet nie może urodzić dziecka w ciągu jednego miesiąca” , ale zdziwiłbyś się, jak wiele osób uważa, że ​​problemy zmniejszają się dogłębnie w stosunku do wyrzucanych im pieniędzy. Złe zarządzanie projektami, często objawiające się w postaci mikro zarządzania, jest główną przyczyną większości projektów tankowania (z mojego doświadczenia). Mikro zarządzanie rozpoczyna się, gdy „zarządzanie” zdaje sobie sprawę, że coś wymyka się spod kontroli i nie mają pojęcia, dlaczego.

Kiedy nie jest to przyczyną, początkowo oczekiwany wynik projektu był prawdopodobnie nie do utrzymania. Z mojego doświadczenia wynika, że ​​jeśli ramy czasowe projektu są zbyt krótkie, ludzie tak bardzo boją się popełniać błędy, które skutkują „podwójną pracą”, że w ogóle nic nie robią.

Dlatego zarząd powinien być zapełniony doświadczonymi programistami, którzy mają historię wiodących zespołów, które wyprodukowały udane projekty. Taka osoba mogłaby powiedzieć „Nie ma możliwości, abyśmy zrobili to odpowiedzialnie” pomimo możliwych przychodów i nie zajmowałaby się zarządzaniem przez długi czas, i dlatego wielu z nas (ostatecznie) odpowiada na MBA zamiast na doktorantów.

Straciłem rachubę liczby firm, w których pracowałem, gdzie nie-programista był odpowiedzialny za zatrudnianie programistów. Miałem kiedyś wywiad, w którym kierownik ds. Rekrutacji nie chciał robić nic innego, jak tylko omówić ostatnie wydarzenie sportowe (myślę, że to był mecz piłki nożnej). Jeśli osoba, którą rządzisz, czerpie więcej inspiracji od trenera NFL niż Knuth, projekt trafi do czołgu.

Od czasu do czasu napotykasz coś, co było dobrze zaplanowane, zrozumiałe, realistyczne i pozornie proste. Z jakiegokolwiek powodu, sześć miesięcy po opracowaniu, wszystko się odwróciło. Zdarza się. Rzadko jednak zdarza się, że podstawową przyczyną projektu jest uwielbiona beczka wieprzowa.

Mimo to muszę przyznać, że… jeśli oglądasz wiadomości, możesz od czasu do czasu zdarzyć się wypadek motocyklowy lub wrak pociągu. Nigdy nie słyszysz o milionach motocykli lub pociągów, które przyjeżdżają codziennie na czas bez żadnych incydentów. To samo dotyczy projektów. Jasne, interesujące jest publiczne oględziny sekcji, która poszła naprawdę, bardzo źle, ale prawie nigdy nie słyszysz o rzeczach, które poszły naprawdę, bardzo dobrze. Myślę, że projekty tankowane są nadal wyjątkiem, a nie normą.

Przez większość czasu połączenie dwóch lub więcej z poniższych:

• problem współpracy między działami
• polityka ... za dużo polityki ...
• zły zespół
• nierealistyczne planowanie
• zmiana zakresu bez odpowiedniej metodologii
• brakujące informacje

Ładna książka na ten temat: Marsz Śmierci .

Ludzie myślą, że tworzenie oprogramowania jest procesem predykcyjnym, próbując zmierzyć i oszacować sytuację na następny rok. To jest niemożliwe! Oprogramowanie do budowania nie jest produkcją śrub.

Podążając za tym samym „trendem”, próbują przeprowadzić ogromną analizę (ponownie za rok), myśląc, że wykorzystają wszystkie możliwości, a później zamieniają programistę w zwykłych maszynistek. Jak myślisz, że to może zadziałać? Tego rodzaju zachowanie prowadzi tylko do złych szacunków i dużej biurokracji.

Im większy projekt, tym większe prawdopodobieństwo, że pracujesz dla dużej organizacji. Im większa organizacja, tym więcej warstw zarządzania. Im więcej warstw zarządzania, tym trudniejsze są złe wieści („nie możemy mieć tego, czego chcemy, na to, na co nas stać”), aby stworzyć łańcuch dowodzenia. Im mniej prawdopodobne złe wiadomości mogą zaliczyć łańcuch dowodzenia, tym bardziej prawdopodobne jest, że plan fantasy zostanie zaakceptowany, a następnie utrzymany na długo po tym, jak wiadomo, że jest nie do zrealizowania.

Projekty oprogramowania wszystkich rozmiarów „mają tendencję do niepowodzenia” lub „przekroczenia kosztów”. Nie słychać o przekroczenia kosztów w branży za rogiem, ale trzeba zrobić usłyszeć o rzeczach takich jak FBI systemu wirtualnej przypadek, czy system obsługi bagażu Denver Airport. Będę więc twierdził, że nie wszystkie duże systemy ulegają awarii, a wszystkie duże systemy nie mają przekroczenia harmonogramu.

Natknąłem się na duże systemy, które pojawiły się na czas (harmonogram przesunął się raz i tylko raz podczas projektu) i zgodnie ze specyfikacją (nie miałem dostępu do informacji budżetowych, ponieważ byliśmy tylko jednym z wielu dostawców). Tym, co nadal mnie imponuje (a pisałem o tym trochę na tej stronie), był duży zintegrowany system zarządzania klientami dla dużego (w pierwszej 100 z fortuny 500) klienta finansowego. Szacuję, że wydali około 100 tysięcy dolarów dziennie (przez ponad rok) na wynagrodzenia ludzi podczas połączeń konferencyjnych.

W przypadku systemu obsługi bagażu menedżerowie oprogramowania stwierdzili, że „w oparciu o projekty tej wielkości i złożoności zbudowanie i debugowanie tego systemu zajmie 4 lata”. Menedżerowie ds. Sprzedaży i kierownictwa powiedzieli: „lotnisko zostanie otwarte za 2 lata, powiedzieliśmy klientowi, że zajmie to 2 lata, więc masz 2 lata na zrobienie tego”. Test mający na celu sprawdzenie, czy jesteś programistą czy sprawcą niewłaściwego zarządzania, jest prostą odpowiedzią na następujące pytanie: „czy system obsługi bagażu był spóźniony czy spóźniony?”

Jeśli klient dokładnie wie, czego chce (a niewielu to robi), będzie bardzo daleko na drodze do kontrolowania kosztów i czasu (i to są ludzie, którzy mają tendencję do całkiem dobrego offshoringu). Jeśli Twój projekt musi spełniać każdą możliwą funkcję, którą mogą wymarzyć Twoi klienci, a każdy dział ma prawo weta, gdy dodawane są do niego ich złote klocki, to od początku jesteś skazany na całkowitą porażkę (jak FBI Projekt VCF).

Postrzeganie rzeczywistości

Oto najlepszy opis tego problemu, jaki kiedykolwiek znalazłem. Tree Swing Od businessballs.com

Koncepcję „Percepcji rzeczywistości” zapoznałem się wcześnie w mojej karierze programisty. Za to jestem naprawdę wdzięczny. Uważam, że jest to największy powód niepowodzenia każdego projektu, nie tylko projektów informatycznych .

Jednym z powodów niepowodzenia jest to, że duży projekt jest zwykle głośnym, ważnym dla biznesu projektem. Kiedy projekty i zadania są głośne, zachęca to ludzi do kłamstwa.

Twój szef chce, abyś oszacował swój status ukończenia po wysokiej stronie. Chce oszacować przekroczenia i opóźnienia po niskiej stronie. Kiedy napotkasz problem, nie chce słyszeć, że zwiększy to zadanie o trzy tygodnie; chce usłyszeć, że możesz dziś wieczorem przepracować kilka godzin.

I tak dalej i tak dalej.

Kilka lat temu pracowałem nad jednym projektem dla klienta. Zostałem przywieziony po zakończeniu oferty i planu projektu. Stała presja, aby iść szybciej, szybciej i śmieszne decyzje o obniżeniu kosztów, duże przeciążenie personelu, brak zasobów dla nich; żadnych biurek, komputerów, niczego.

W końcu odkryłem, że oferta została złożona na 7 miesięcy i 16 milionów dolarów. Oszacowałem na odwrocie koperty, że powinna ona wynosić 24 miesiące i 50 do 100 milionów. Umówiłem się z moim menadżerem i jego menadżerem, przedstawiłem moją sprawę i to, jak NIE zbliżaliśmy się do osiągnięcia terminowości lub budżetu; bagatelizowali wszystkie problemy. Pod koniec spotkania CIO zadzwonił i powiedział obu menedżerom zasadniczo to, co powiedziałem, z wyjątkiem wady w pierwotnej ofercie.

Miałem okazję wycofać się z projektu, kiedy zmienili technologie na takie, w których nie miałem umiejętności. Rozmawiałem z kimś znacznie później. Projekt został ostatecznie anulowany, kiedy był w połowie ukończony ... w 12 miesięcy i 35 milionów dolarów.

Znane duże projekty zniechęcają ludzi do mówienia „to błąd”. Błędy nie są tolerowane.

Opracowując trochę odpowiedzi VonC:

Te duże projekty mają zazwyczaj mentalność „wszystko albo nic”. Projekt zgodnie z definicją musi zostać wydany za jednym razem - często jest to zmiana w stosunku do istniejącego systemu.

Oznacza to, że problemy związane z pełzaniem funkcji / wymagań są trudniejsze do rozwiązania, więc kiedy projekt zostanie zrealizowany, często postrzega się go jako niespełniający wymagań. Można to zaostrzyć, jeśli istniejący system został zaktualizowany lub w międzyczasie nastąpił rozwój technologii.

Jakie jest na to rozwiązanie?

Naprawdę nie wiem, ponieważ nikt nie chce, aby dwa systemy działały równolegle ze zmieniającym się zestawem funkcji podzielonych między nimi.

Złożoność dużego projektu może gwałtownie zaostrzyć zewnętrzne naciski polityczne. Jeden dział może mieć bardzo jasne, skoncentrowane wyobrażenie o tym, czego chcą w nowym systemie, ale potem powiązane działy pojawiają się z dziesiątkami zapytań w stylu „Cóż, dopóki to robisz, dlaczego nie czy to małe zadanie dla nas też? ” Możesz zacząć od powiedzenia „Nie, to nie wchodzi w zakres.”, Ale wtedy zaczyna się walka polityczna między rozczarowaniami, a budżet projektu jest zagrożony, chyba że wszyscy dostaną kawałek ciasta.

Przez lata nasza lokalna policja nie mogła wyszukiwać częściowych tablic rejestracyjnych w systemie samochodowym, co wydaje się absurdalnie proste. Zapytałem przyjaciela, co do cholery było tak trudne w dodaniu tej funkcji, i powiedzieli, że za każdym razem, gdy proponowali przejście na nowoczesną bazę danych, każdy inny departament w stanie, który miał jakiekolwiek interakcje z systemem pojazdów silnikowych, chciał uzyskać swoją część system też został naprawiony. Rezultatem była kompletna blokada w modernizacji IT. Wreszcie państwo zebrało wystarczającą ilość kapitału, aby przeprowadzić szeroko zakrojone prace modernizacyjne, które następnie przerodziły się, ponieważ były tak strasznie złożone.

Czynnik, który został poruszony, ale nie został jeszcze uwzględniony:

Prawie wszystkie dramatyczne porażki dotyczą przetargów, które zostały wylicytowane. Co dzieje się z kompetentną firmą w takiej sytuacji? Dokonują realistycznych szacunków i dlatego prawie na pewno są zbyt słabe od kogoś, kto dokonał złej oceny.

Jeśli firma nie jest w stanie właściwie oszacować, czy nie jest zaskakujące, że nie może również poprawnie zbudować systemu?

Michael Krigsman z ZDNet ma blog poświęcony „Awariom projektu IT ”, który może być tutaj interesujący.

Inną kwestią jest to, że przy długich projektach, które trwają lata, zazwyczaj będą albo aktualizacje do rozważenia, albo alternatywne rozwiązania, np. Czy projekt mógłby być teraz wykonany w chmurze w porównaniu z lokacją, aby coś zaczynało pojawiać się coraz bardziej, biorąc pod uwagę nie było to dane w momencie rozpoczęcia projektu. Na przykład, chociaż można rozpocząć, gdy coś jest w wersji 6.0, do czasu ukończenia pierwszej fazy może pojawić się wyjście 6.3 lub 6.4 i pojawia się pytanie, kiedy uaktualnić. Zmiany zakresu i pożądanej funkcjonalności, ponieważ albo wymagania nie zostały poprawnie zebrane, albo ktoś zmienił zdanie, to kolejna kwestia, o której już sporo mówiono.

Można stosować zwinne w tego typu projektach lub tradycyjne podejście jest nadal najlepsze.

Powód, dla którego dobrze stosowane zwinne procesy nie cierpią z powodu tego problemu, jest prosty. Nie możesz uruchomić dużego projektu w zwinny sposób. Możesz wybrać jedno lub drugie.

Dzięki zwinnemu procesowi nigdy tak naprawdę nie patrzysz w przeszłość jednej lub dwóch iteracji w przyszłość projektu. nie ma „planu” na następne 2 lata, tylko na kolejne dwa tygodnie. Kiedy twój pogląd jest tak krótki, musisz zrobić kilka kompromisów. Nigdy nie możesz zacząć od planu stworzenia „Ostatniego słowa w widżetach” dla dowolnego rodzaju projektowanego widgetu. Co najwyżej możesz zacząć od „Widżetu, który może frobować”, ponieważ dotyczy to najwięcej pracy, jaką możesz wykonać w jednej lub dwóch iteracjach.

Dobrą rzeczą jest to, że po kilku iteracjach masz już gotowy, działający produkt, który ktoś może uznać za przydatny, szczególnie ten jeden klient, który rozpaczliwie potrzebuje widżetu, który może frobować i zortować.

Zasadniczo duże projekty mogą zawieść, ponieważ ich celem jest rozwiązanie wszystkich problemów wszystkich potencjalnych klientów. Zwinny projekt nigdy nie ma tego celu, zamiast tego w każdej wersji rozwiązuje tylko jeden krytyczny problem, który może mieć pojedynczy klient. Jednak po długim czasie zwinny projekt może rozwiązać wiele krytycznych problemów dla wielu klientów.

• Brak wysyłki do rzeczywistych użytkowników

Duże projekty mają od lat nieprzyjemną tendencję do przechodzenia w tryb „infrastruktury” i zapominają o tworzeniu prawdziwych funkcji dla użytkowników końcowych i wysyłaniu ich. Do czasu wysyłki jest bardzo kosztowna zmiana, a zwykle po największych prawdziwych testach beta pojawiają się największe zmiany koncepcyjne.

• Brak dokładnego oszacowania kosztów

Jeśli wydaje się, że projekty przekroczą zwrot z inwestycji, zostaną anulowane.

• Brak kontroli jakości

Przy wystarczającej liczbie wad moment pędu może spaść do zera lub poniżej. Bez żadnego postępu trudno argumentować za dalszym istnieniem.

Zapomnieli Prawa Hofstadtera: zawsze trwa dłużej, niż się spodziewasz, nawet jeśli weźmiesz pod uwagę Prawo Hofstadtera.

Rzeczy, które widziałem w rozwoju sieci:

• Zbyt wielu kucharzy - główny detalista B&M, gdzie nacisk nagle przesunął się na sieć. Nagle 20 szefów departamentów stara się dogonić każdą inicjatywę, aby zrobić wrażenie na nowym serze. Kiedyś musiałem wdrożyć nowe ikony, ponieważ legalne nie podobały się stare.

• Nadmierna koncentracja na dopasowywaniu specyfikacji w stosunku do osiągania celów - „Ikony IE6 są nieco wyblakłe w porównaniu do IE7. Porzuć krytyczną datę premiery i zajmij się 0,05% naszej bazy klientów, aby robić okropne rzeczy, które potrwają kilka dni aby jeszcze bardziej zaimplementować i spowolnić korzystanie z IE ”.

• Złe narzędzia wybrane przez nie-deweloperów, którzy nie mogli nawet zadać sobie trudu, aby poprosić o pomoc swoich wewnętrznych programistów.

• Źli deweloperzy wybrani przez narzędzia - „Po co płacić 20 kompetentnym programistom Java przyzwoitą pensję, skoro możemy zlecić 200 słabo znającym się na kodowaniu facetów, którzy wiedzą za mało, aby używać kontroli wersji?” ponieważ jednocześnie i z ludźmi z różnych krajów, pracują na zapleczach przede wszystkim dla 3 dużych aplikacji.

• Zła / zepsuta architektura - Warstwy po warstwach spanikowanego, wykonanego wczoraj kodu, przez osoby, które zostały zwolnione lub są menedżerami.