Co jest najbardziej skandalicznym marnotrawstwem pieniędzy, jakie widziałeś i co z tym zrobiłeś? [Zamknięte]

Często jako programiści widzimy, jak duże organizacje marnują ogromne sumy pieniędzy na rozdęte i nieefektywne rozwiązania problemów. Bardzo mnie to boli, ponieważ lubię organizacje, które korzystają z najlepszych rozwiązań rasowych. Jednak moje umiejętności programistyczne są ograniczone, jeśli chodzi o wpływanie na kluczowych decydentów i często moje spojrzenie na tę sprawę jest ograniczone do mojego małego technicznego świata.

Więc moje pytanie brzmi: Po napotkaniu rażącego marnotrawstwa pieniędzy na oprogramowanie i / lub sprzęt, który naprawdę dostał twoją kozę, co zrobiłeś z tym, aby to naprawić lub czy byłeś skazany na ugryzienie kuli i mruczenie na zawsze pod nosem? Chciałbym poznać twoje ogólne doświadczenia, a zwłaszcza to, czego nauczyłeś się, jak radzić sobie z tego rodzaju problemami w przyszłości . Nie wymieniajmy nazw, doświadczenie w rozwiązywaniu problemu jest ważniejsze niż faktyczny produkt.

Płacenie za duże, nieporęczne, komercyjne produkty komercyjne w zakresie:

• Serwery aplikacji;
• Narzędzia do testowania;
• Środowiska programistyczne.

gdy alternatywy typu open source lub lekkie są oczywiście lepsze.

Moje kroki to zazwyczaj:

1. ustanowić alternatywę jako odniesienie - np. „Będę eksperymentować z serwerem aplikacji X zamiast z serwerem aplikacji Y. Miałem z tym dobre doświadczenie, ponieważ (...).”;
2. sprzedaj tę propozycję moim kolegom - „Rozwijam się teraz szybciej, ponieważ serwer X uruchamia się znacznie szybciej i nie marnuję cały ten czas”;
3. sprzedaj to bezpośredniemu kierownikowi - „Nasz zespół rozwija się teraz szybciej, ponieważ używamy serwera X. Wszystko zaczęło się od małego eksperymentu, ale wszystkim się to podoba”.

Widziałem zbyt wiele przykładów, aby wymienić ulubionego, ale zauważyłem kilka ogólnych trendów w mojej głównej dziedzinie, rozwoju stron internetowych:

1. Witryny próżności . Są to strony internetowe, które nie służą żadnemu pożytecznemu celowi nikomu spoza małej organizacji, która je zleca, i są zbudowane wokół obsesyjnego przymusu z logo, własnymi zdjęciami i pobłażliwym gofrem. Najgorsze jest to, że są one zazwyczaj finansowane i zlecane przez sektor publiczny przez osoby, które nie mają pojęcia o sieci. (Na przykład kiedyś miał zaufanie szpitala NHS, który chciał opracować mini-wersję Facebooka dla własnego intranetu dla pracowników).

2. Zapłacono za najlepsze . Sposób myślenia, zgodnie z którym opłacone oprogramowanie musi z natury być lepsze niż oprogramowanie typu open source. W końcu jest opłacone, prawda? Widziałem tak wielu klientów, którzy nalegają na dokonywanie głupich wyborów po prostu dlatego, że pracują w kulturze, która automatycznie dyskontuje wszelkie otwarte oprogramowanie ze względu na zasady.

3. Projekt komitetu. W tym miejscu ogromna grupa ludzi przeżywa „burzę mózgów”, a następnie stara się włączyć do projektu każdą ideę crack-potu, co nieuchronnie prowadzi do przemyślanego bałaganu, który idzie na kompromis we wszystkim na korzyść próby zadowolenia wszystkich ( i przez wszystkich mają na myśli komitet podejmujący decyzje, a nie osoby, które muszą korzystać z aplikacji).

4. Konsultanci. W tym miejscu płacisz środkowemu człowiekowi (który nie zna ani praktyk biznesowych, ani tworzenia oprogramowania), aby stanąć na drodze i pozbyć się pieniędzy, przeciągając proces programowania z mylącym bełkotem techno i mówieniem biznesowym.

Nie widzę, żeby ktoś jeszcze o tym wspominał.

Buduj własne rozwiązanie, kiedy możesz je kupić.

Odmiany tego wzoru:

• nawet nie biorąc pod uwagę kompromisu kupno-budowanie
• znaczny zakres pełzania rozwiązania wewnętrznego
• ograniczony zakres, ale także ograniczona użyteczność rozwiązania wewnętrznego

Moje dwie ulubione:

1. Zatrudnianie konsultantów (freelancerzy) tylko po to, aby zwiększyć moce produkcyjne , a zamiast tego powinni inwestować we własnych pracowników , zatrudniając konsultantów, którzy przynoszą nową wiedzę i szkolą swoich obecnych pracowników.

2. Zatrudnianie kierowników projektów, którzy zarządzają innymi kierownikami projektów, którzy zarządzają innymi kierownikami projektów, którzy w końcu (myślą) zarządzają zespołem programistów. Powinni natomiast pozwolić zespołowi na samodzielne zarządzanie i skupienie się na biznesie. Widziałem projekty oprogramowania, w których mieli więcej menedżerów projektów niż programistów. Wyobraź sobie spotkania.

Ograniczanie długoterminowych podwyżek i bonusów

Myślę, że nauczono w Business 101, aby nie dawać pracownikom podwyżek. Drugi przypadek to ograniczenie pensji gwiazdorów, ponieważ muszą mieścić się w pewnym przedziale wynagrodzeń.

W końcu pracownicy zdadzą sobie sprawę, że ich skala płac nie jest zgodna z ich branżą (lub produkcją). Ludzie, którzy mają CV i umiejętności, w końcu odejdą i zabiorą ze sobą całą swoją wiedzę oraz prawdopodobnie kilku znajomych. Pozostali ludzie (którzy są najsłabszymi wykonawcami) będą musieli odebrać luz, a następnie poświęcić więcej czasu na zatrudnienie nowej osoby (według stawki rynkowej). Tak więc firma właśnie wymieniła gwiazdowego pracownika na pierwszy poziom JR i po prostu straciła wszystkie „oszczędności” związane z utrzymaniem niskich wynagrodzeń.

W tym czasie zespół programistów będzie walczył o utrzymanie się na równi i prawdopodobnie będzie coraz gorzej, dopóki nie zostanie zrobione coś drastycznego.

Ta odpowiedź jest nieco inna niż większość: nie wypalania pracownika wystarczająco szybko, albo podano inaczej, będąc zbyt tolerancyjna pracownika błędom nawyków . To były rzeczy, które obserwowałem i nie mogłem wiele zrobić jako konsultant.

• Twórca, który źle podjął decyzje projektowe projektu, które doprowadziły do ​​jego ostatecznego przepisania (był to kompletny bałagan).

• Twórca, który wysłał wrażliwe, niezaszyfrowane dane do Google Chart, ponieważ uważał, że fajnie byłoby wyświetlić wykres kołowy (czy wykres kołowy był wymagany? Nie!).

• Twórca, który w przeszłości konsultował się z firmą i bezpośrednio przyjął jej stanowisko. Zrobił coś na temat twarzy i zmienił się w prima donnę, która szukała stanowiska Leadera Technicznego i posunęła się nawet do rozmowy z kierownikiem Leadera, twierdząc, że sądzą, że dobrze będzie, gdyby przejął stanowisko Leadera. Mów o śmiałości! Wielu deweloperów już nie lubi faceta, a on spalił wiele mostów w ciągu pierwszych 2 tygodni pracy. Podsumowując, jest bardzo zielonym deweloperem, który ukończył szkołę zaledwie 2 lata temu, ale uważa, że ​​jest niesamowity.

Kilka błędów jest zrozumiałych, ale kiedy wielu deweloperów zgadza się co do czyjejś postawy lub poziomu umiejętności, firmy powinny raczej się ich pozbyć wcześniej niż później.

Kilka razy byłem świadkiem, jak zarząd przyprowadzał konsultantów wyłącznie w celu wydawania pieniędzy . Przez większość czasu działo się to pod koniec roku, kiedy gorączkowo starali się wydać pieniądze. Zazwyczaj ci konsultanci otrzymywali setki dolarów za godzinę i spędzali tygodnie na prezentacji PowerPoint, która nigdy nie byłaby wykorzystana.

W grze jest o wiele większy problem.

Wiele firm ma jeden cel - zwiększenie zamożności akcjonariuszy. To, co produkują, jest nieistotne. To, jak je wytwarzają, nie ma znaczenia. Ilość wytwarzanych przez nich odpadów jest nieistotna. Koszt dla społeczeństwa i planety jest nieistotny.

Więc - idź do pracy lub załóż firmę, która robi coś pożytecznego dla społeczeństwa / planety.

Płacenie dużym firmom programistycznym nie tylko za ich produkt, ale także za „wsparcie”.

Pracowałem w agencji rządowej dla zespołu, który był głęboko w łóżku z Oracle. Przez wiele lat otrzymywali bajliony dolarów za swoje oprogramowanie. Pochodzenie ze środowiska startowego nie miało dla mnie sensu - „dlaczego nie użyć MySQL lub Postgres?” Powiedziano mi, że dzieje się tak głównie dzięki wsparciu Oracle, jeśli coś pójdzie nie tak, pomogą ci szybko znaleźć rozwiązanie.

Wsparcie było absolutnym żartem. Wystąpił problem polegający na tym, że jedna aplikacja internetowa powodowała awarię całego systemu. Wydawało się, że jest to wynik powolnego zapytania do bazy danych z kombinacją okropnie napisanego kodu (napisanego przez zespół konsultantów, co powinno być zupełnie inną odpowiedzią). Zgrupowano „grupę zadaniową” (jęk), aby wskazać problem i go naprawić. W skład grupy zadaniowej wchodził członek wsparcia Oracle. Każdego dnia w EOB odbywałoby się połączenie konferencyjne, podczas którego członkowie grupy zadaniowej informowali resztę zespołu o ustaleniach. To było wystarczająco długie połączenie, że nikt nie chciał być na czarno, zaczęło się o 5, a osoba Wyroczni pogorszyła to. Dlaczego? Cóż, powiedzenie „osoba” nie jest nawet poprawne. To było wiele osób. Wyglądało na to, że co dwa lub trzy połączenia konferencyjne przedstawiciel Oracle byłby kimś nowym, który wyjaśnił, że ich poprzednik był na innym projekcie lub wyjechał na wakacje. Nowi ludzie nigdy nie zostali poinformowani przez Oracle, więc za każdym razem, gdy pojawiał się ktoś nowy, musieliśmy tracić dziesięć minut na rozmowę konferencyjną, tłumacząc ponownie problem. Ichwkład byłby wtedy z prośbą o pliki dziennika J2EE, które nie tylko mogą odczytać małpy, ale były również bezużyteczne, ponieważ okropnie napisany kod robił takie rzeczy, jak zgłaszanie wyjątków IndexOutOfBounds, gdy programista znalazł błędy w analizie XML.

Posiadanie programistów do wsparcia telefonicznego na pierwszej linii.

Zaproszenie programistów do testowania.

Wiem, że to stare pytanie i będę miał szczęście, jeśli 3 osoby przeczytają tę odpowiedź, ale opowiedzieć zabawną historię, więc do diabła.

Przyszedłem do projektu (systemy osadzone, oprogramowanie krytyczne dla bezpieczeństwa, bardzo duże ryzyko) i byłem przerażony tym, co znalazłem. Ludzie używający C (szczególnie wskaźników) niepoprawnie, bez analizy statycznej, bez recenzji kodu, bez testów innych niż „zintegruj to razem, uruchom, pobij, zobacz, co się psuje”.

Mój pierwszy tydzień napisałem tam bardzo długi e-mail (jako konsultant). Było to trudne, ponieważ zasadniczo mówiłem, że było źle zarządzane, programiści byli nad ich głowami, nie śledzono żadnych procesów itp. Powinien był udać się do wiceprezesa korporacyjnego, ale zamiast tego wysłałem go do kierownika ds. Rozwoju, który zatrudnił mnie. Nie był do tego całkowicie defensywny, w rzeczywistości przyznał się do wielu niedociągnięć i powiedział mi, że nie jako pierwszy ich zwróciłem (bez żartów, prawda?)

Aby odpowiedzieć na sedno pierwotnego pytania: zaproponowałem, że spędzę NAJBARDZIEJ 1 osobo-tydzień na skonfigurowaniu i uruchomieniu narzędzia analizy statycznej Gimpel Lint (PC-Lint / Flexelint) na ich platformie oraz na przeprowadzeniu pełnego raportu o wszystkim, co zostało znalezione . Powiedziałem im, że jestem absolutnie pewien, że w rezultacie znajdziemy kilka czających się „bomb czasowych”.

Obliczyli moją stawkę godzinową, pomnożili ją przez 40 i stwierdzili, że „było to zbyt drogie”. Krótko mówiąc, wyjechałem tam w ciągu 60 dni. Około 3 lata później dowiedziałem się o wycofaniu produktu, koszt zbliżył się do 9 cyfr (100 mln USD), nie wspominając już o szkodzie dla reputacji firmy.

Nie będę wspominał o firmie, produkcie ani branży, ale nadal utrzymuję kontakt z jednym z inżynierów, a kiedy wyjaśnił mi, co spowodowało wycofanie, wywróciłem oczami - to był problem, który miałby został złapany nawet przez podstawowe narzędzie do analizy statycznej (dostęp do tablicy poza granicami). Szczerze mówiąc, nie mogę z całą pewnością stwierdzić, że problem tkwił w kodzie, kiedy tam byłem, ale jestem pewien, że gdyby wydali pieniądze na jakieś narzędzie do analizy statycznej, ten błąd nie uciekłby.

Zaoszczędzili więc 295 USD, nie kupując PC-Lint (OK, zaoszczędzili też co najwyżej tydzień płacenia mi) - ale nigdzie nie jestem wystarczająco dobry, by pobierać 100 mln USD za tydzień.

To właśnie nazywam cholernie dużą stratą pieniędzy.

Przypomina mi żart, o którym wielu z was mogło już słyszeć:

Czy słyszałeś kiedyś historię o ogromnym silniku statku, który zawiódł? Właściciele statku próbowali jednego eksperta po drugim, ale żaden z nich nie był w stanie przewidzieć, jak naprawić silnik. Potem przyprowadzili starca, który naprawiał statki, odkąd był młodszy. Nosił ze sobą dużą torbę narzędzi, a kiedy przybył, natychmiast zabrał się do pracy. Bardzo dokładnie sprawdził silnik, od góry do dołu.

Byli tam dwaj właściciele statku, obserwując tego człowieka, mając nadzieję, że będzie wiedział, co robić. Po obejrzeniu rzeczy starzec sięgnął do torby i wyciągnął mały młotek. Delikatnie postukał w coś. Silnik natychmiast ożył. Ostrożnie odłożył młot. Silnik został naprawiony! Tydzień później właściciele otrzymali rachunek od starca za 10.000 $.

"Co?!" zawołali właściciele. „Prawie nic nie zrobił!”

Napisali więc starcowi notatkę: „Proszę, wyślij nam wyszczególniony rachunek”.

Mężczyzna wysłał rachunek z napisem:

  Tapping with a hammer ........ $ 2.00

  Knowing where to tap ......... $ 9998.00

Wysiłek jest ważny, ale wiedza o tym, co robisz, robi różnicę.

Rozdęte zespoły programistyczne i straszna produktywność w firmach programistycznych.

Jest to konsekwencja powszechnego schematu w świecie biznesu: znaczenie menedżera mierzy się liczbą podwładnych, dlatego najważniejszą kwestią menedżera nie jest produktywność, ale wręcz przeciwnie: gorsza produktywność jest najlepszym uzasadnieniem dla zatrudnienia większej liczby osób .

W firmie, która sprzedawała oprogramowanie ... dając sprzedawcom pełną prowizję od wszystkich sprzedawanych niestandardowych modów, więc sprzedaż czegoś, co już istniało i na którym moglibyśmy po prostu zarobić, nie była dla nich tak opłacalna jak sprzedaż jednorazowa. Było to połączone z przeniesieniem pracowników sprzedaży w połowie kraju z personelu technicznego.

Oznaczało to również, że my w Dziale Rozwoju nie mogliśmy dotrzymać terminów sprzedaży, co spowodowało, że klienci byli niezadowoleni, i mieliśmy ogromne trudności z wykonaniem jakiejkolwiek podstawowej pracy, która poprawiłaby produkt dla wszystkich. Zwiększona presja spowodowała obniżenie jakości kodu i zaszkodziło morale, szczególnie gdy usłyszeliśmy historie o biurze sprzedaży (czego nigdy nie potwierdziłem).

Wielu z nas było oburzonych Sprzedażą, ale tak naprawdę to nie była ich wina. Wychodzili i sprzedawali tyle, ile mogli, robiąc to, za co zostali nagrodzeni zgodnie z ograniczeniami, które zostały na nich nałożone. To złe zarządzanie spowodowało wszystkie te problemy.

Są dwa, których doświadczyłem.

1. Anulowanie projektu o dużym ROI dla firmy, który został ukończony w około 80%, a następnie przekazanie 100 grawerowanych i pozłacanych iPodów wyższemu kierownictwu.

2. Zwolnienie kilkuset osób, a następnie następnego dnia ogłoszenie znacznych podwyżek i premii dla wyższej kadry kierowniczej.

Nie są one całkowicie związane z programowaniem, ale z pewnością zmarnowały dużo pieniędzy, a także zapewniły uderzenie w twarz wszystkim zaangażowanym.

Nie zostałem zwolniony, ale nie dostałem też podwyżki ani iPoda ...

Widziałem kilka okropnych projektów outsourcingowych, którym udało się znacznie zwiększyć koszty, jednocześnie nie zwiększając ani nie zmniejszając wydajności.

W najgorszym przypadku nowy zespół outsourcingowy został powołany i wyszkolony, ale istniejący zespół on-shore pozostał na miejscu, ponieważ zespołowi outsourcingowemu nie ufano, że faktycznie wykona jakąkolwiek krytyczną pracę.

W tym momencie logiczną rzeczą byłoby oczywiście zaakceptowanie niepowodzenia i zamknięcie zespołu outsourcingowego, ale ponieważ kierownictwo nie było skłonne publicznie przyznać, że nie działało, oba zespoły pozostały na miejscu (przy znacznym wzroście kosztów bez wzrostu wydajności lub użytecznej pojemności), dopóki wszystko nie zostanie zakopane.

W innym przypadku rozwój został zlecony na zewnątrz i pierwotny zespół zwolniony. Dwa lata później zdali sobie sprawę, że nie zadziałało i nie sprowadzono całego domu ponownie, ale okazało się, że oprócz bardzo znacznych kosztów kolejnego przekazania, wpływ utraconej wiedzy, opłat rekrutacyjnych, wypowiedzenia umów itp. dalej organizacja outsourcingowa straciła znaczną część kodu źródłowego.

(Uwaga: nie mówię, że outsourcing nie może działać, tyle że zbyt wiele razy ludzie są kuszeni potencjalnymi oszczędnościami i nie biorą pod uwagę realiów swojego nowego świata, zmiany w procesach i praktykach pracy itd., Co prowadzi do poważnie spieprzone projekty)

Dług techniczny

Widziałem chroniczne „bicie martwego konia” ze starego kodu. Lub bardziej konkretnie, z punktu widzenia okopów, niezliczone godziny spędzone w trybie konserwacji, kiedy cały zespół wie, że powinniśmy być w trybie zastępczym.

To, co zrobiliśmy ... wciąż trwa. Próba wywołania pozytywnej zmiany od wewnątrz

Test wydajności

Po prostu nie rób tego. Znów nadal pracuję nad pozytywną zmianą od wewnątrz.

Współpracowałem z kilkoma instytucjami państwowymi i są one niesamowite w marnowaniu pieniędzy na IT. Od zakupu rozdętego oprogramowania pośredniego do rozwiązania niezwykle prostych problemów, po zapłacenie tysiącom dolarów dostawcy, aby utworzyli CSV. Bez wewnętrznych pracowników z wystarczającym doświadczeniem wydaje się, że albo dostaną flotę na poczet kosztów wstępnych, albo na utrzymanie.

W firmach niezwiązanych z oprogramowaniem (banki, ubezpieczenia) z wewnętrznym IT, pieniądze pochodzą z różnych grup biznesowych. Grupy biznesowe bezpośrednio otrzymują ofertę sprzedaży od dostawców i przekazują ją do działu IT. Płacą za oprogramowanie / sprzęt i twoją pensję, więc twoje protesty nie pójdą gdziekolwiek.

• Płacenie za rozdęte aplikacje i oprogramowanie pośrednie, które kosztują średnio pięć cyfr i nawet nie mieszczą się w istniejącej architekturze systemu
• Korzystanie z drogiego oprogramowania, takiego jak HP QualityCenter, BMC Remedy, HP LoadRunner itp., W którym dostępne są lepsze i tańsze opcje
• W zespołach z wielu miast wiele kosztów podróży, czasami tylko na kilka godzin spotkania
• Płacenie za licencję na Windows 7, która pojawia się na nowych komputerach, a następnie ponowna opłata za przejście na Windows XP, ponieważ nowe SOE (zaprojektowane w 2010 roku) to nadal XP
• Ponad pojemność sprzętu

Pracuję w zawodzie zajmującym się testowaniem wydajności i jestem świadkiem (dosłownie) milionów dolarów rocznie wyrzucanych przez organizacje z czterech powodów

1. Zatrudnienie outsourcera w oparciu o samą cenę, brak umiejętności kwalifikacyjnych i regularne kontrolowanie umiejętności testerów wydajności. Zatrudnianie amatorskiego testera wydajności przypomina zatrudnienie hydraulika-amatora lub elektryka-amatora. Zajmie im to znacznie więcej czasu, wykonując podstawowe zadania, stracisz wiele kontroli i równowagi w procesie, a kiedy dowiesz się, jak to zrobić złe, że naprawianie ich (w produkcji) było strasznie drogie. Jako moderator pół tuzina forów w tej dziedzinie regularnie obserwuję osoby, które nie mają podstawowych umiejętności w zakresie testowania, komunikacji, zarządzania projektami, rozwoju, analizy systemów itp. I po prostu zostały rzucone na narzędzie. Dla osoby, która wcześniej zauważyła LoadRunner jako stratę pieniędzy, jeśli rzucisz głupca na narzędzie, jest tylko jeden wynik, którego możesz się spodziewać.

2. Nie zbieranie wymagań dotyczących wydajności. Ma to wpływ na całą organizację, ponieważ będziesz mieć inne spojrzenie na wydajność w architekturze, inżynierii platform, inżynierii aplikacji, funkcjonalnej kontroli jakości i kontroli jakości, z których żadna z nich może nie odpowiadać interesariuszom biznesowym (a często nie). Jest to problem procesowy w wielu organizacjach, w których zespół ds. Testów wydajności jest proszony zarówno o zbieranie wymagań dotyczących wydajności, jak i testowanie ich. W celu zapewnienia prawidłowej kontroli i równowagi powinieneś zrobić jedno, a nie drugie. W odniesieniu do 1 powyżej z niedojrzałym personelem będziesz mieć ludzi, którzy nie mogą nawet rozpoznać odpowiedniego wymagania wydajności, nie mają punktu pomiarowego do sprawdzenia z profilem obciążenia, a jednak nadal budują „skrypty do uruchomienia”. Jest to marnotrawstwo czasu i wysiłku, które w niewielkim stopniu poprawia jakość. Wydajność wymaga wspólnej perspektywy w całej organizacji i nie jest czymś, co można rozwiązać na końcu, jeśli nie zostało zaprojektowane na początku.

3. Zarządzanie środowiskiem testu wydajności. Nie mogę powiedzieć, ile organizacji opóźnia się w testowaniu środowisk, które nie są gotowe do uruchomienia w momencie, gdy organizacja testowa jest gotowa do kontynuacji. Tylko u jednego klienta widzę to jako problem o wartości wielu milionów dolarów, jeśli chodzi o liczbę godzin straconych podczas oczekiwania

4. Kierownicy projektów, którzy nie rozumieją, czym jest testowanie wydajności, jakie zadania są zaangażowane lub jaki jest nakład pracy, ale którzy decydują o tym, jak długo powinny być wykonywane działania. Prowadzi to do rozbieżności w harmonogramie projektu, które są całkowicie związane ze sposobem planowania pozycji (i w wyniku przekroczenia kosztów). Jest to bezpośrednio związane z powyższym punktem 1, ponieważ niedojrzali testerzy nie są w stanie dokładnie przewidzieć ani liczby i rodzajów zadań, ani czasu ich trwania. Jest to aksjomat, że jeśli pozwolisz komuś, kto nie rozumie, co robisz i dlaczego to robisz, dyktuje ci, jak pracujesz i ile czasu zajmiesz, wtedy ta ścieżka doprowadzi do niepowodzenia. Zbyt często zdarza się to podczas testowania wydajności.

Zastrzeżone systemy kontroli wersji. Biorąc pod uwagę stan Git i Mercurial, nie rozumiem, dlaczego ludzie wybierają coś ze strażnikiem bram.

Nie tylko musisz płacić za VCS, ale także płacić za użytkownika. Dodatkowo twoja elastyczność zostaje zastrzelona w stopę. Równie dobrze możesz nosić koszulkę z napisem „I ♥ Vendor Lock In !!!”

Wydaje mi się, że w dzisiejszych czasach korzystanie z darmowego (D) VCS jest szalone. Jeśli chcesz, aby wiele dodatków do tego pasowało, dostępne są rzeczy takie jak Kiln.

Nie sądzę, żebym poszedł do pracy dla kogoś, kto nalegał na BitKeeper lub podobny.

Prawie powiedziałem to samo o emulatorach, ale produkty takie jak Simics nadal oferują znaczącą przewagę nad darmowymi alternatywami.

Status spotkania i cotygodniowe raporty

W organizacji, w której pracowałem, chodziło o cotygodniowe raporty o stanie - zebrane na 3 różnych poziomach. Deweloperzy i przewodnicy testowi dla każdego z 4-6 projektów w locie informują o swoich postępach w długim e-mailu, który następnie zostaje zebrany przez następnego menedżera, który z kolei zostaje arbitralnie podsumowany przez następny.

Następnego dnia roboczego wszyscy liderzy projektu zbierają się na 1-godzinnym spotkaniu, aby omówić raport.

Skutecznie jeden dzień w tygodniu jest wydawany na raportowanie postępów w tym tygodniu. Pamiętaj, że wszystko to jest oddzielone od codziennych pojedynków i cotygodniowych spotkań demonstracyjnych / retrospektywnych.

Pracuję dla organu publicznego. Naprawdę nie ma sposobu, aby odpowiednio wyjaśnić poziom marnotrawstwa, który może powstać, gdy miejsce pracy jest tak mocno uregulowane i zjednoczone, że zwolnienie kogoś jest praktycznie niemożliwe.

Menedżerowie grają z paskudnym personelem i mają nadzieję na usunięcie ich wszystkich naraz w ramach restrukturyzacji. Niektórzy źli pracownicy są awansowani, aby przenieść ich poza obszar, który wymaga poprawy. Każdy dobry personel musi nieustannie walczyć, aby zrekompensować jego pracę. Personel, którego nie zatrzymasz przez 3 miesiące, wykuwa 40-letnie kariery. Kwota, jaką marnują na takie kariery, jest astronomiczna.

Wcześniej pracowałem w sektorze prywatnym i widziałem dużo odpadów, ale odpady sektora publicznego to zupełnie inny sport, nie mówiąc już o grze w piłkę.

W komentarzu zasugerowano, że pomocne byłoby ustanowienie sinecures dla słabszych pracowników. Pomogłoby to w tym, że ograniczyłoby szkody, które mogą wyrządzić, ale nie wpłynęłoby na podstawowe przyczyny problemu. Myślę, że najlepszą rzeczą byłoby przyjęcie niektórych procedur zatrudniania i zarządzania w sektorze prywatnym oraz zmiany w ustawodawstwie, aby ułatwić organom publicznym wypuszczanie pracowników o gorszych wynikach. Związki powinny również zmienić swoją politykę w porozumieniu z rządem - ich rola w ochronie swoich członków jest ważna, ale powinni oni zdawać sobie sprawę z tego, że czasami ich członkowie są naprawdę poza swoją głębią i powinni przejść dalej

Jeden projekt, nad którym pracowałem z dużą instytucją finansową. Codziennie odbywały się ogromne ilości połączeń konferencyjnych i oszacowałem, że spaliły one około 100 000 USD dziennie podczas samych połączeń konferencyjnych. Projekt trwał około 2 lat. Mieli mnóstwo starszych systemów, a kiedy kilka lat temu wprowadzono zmiany w świetle dziennym, zapłacili Microsoftowi około pół miliona dolarów za opracowanie poprawki DST dla NT 3.51.

Mieliśmy niewielką ilość pracy i ledwo zarabialiśmy rachunki i listy płac w małym sklepie, w którym pracowałem. Rozwiązanie: zatrudnij konsultanta ds. Wydajności i osobistą sekretarkę dla szefa, aby mógł on wykonać więcej pracy z „mięsem i ziemniakami”.

Rozwiąż niedobór budżetu, zwiększając wydatki ... nie.

Na plus - ekspert ds. Wydajności dostarczył tablicę suchościeralną, w której śledziliśmy nasze rozliczane godziny i płaciliśmy godziny ... zgadnij, kto miał najmniejszą liczbę rozliczanych godzin.

Zobaczmy, że kiedyś wydaliśmy ponad pół miliona dolarów, wykonując pracę, aby wygrać kontrakt o wartości miliona dolarów. Tyle o zysku z tego. Niektórzy z nas w zespole ds. Opracowywania propozycji projektów próbowali to podkreślić, ale dumą stało się, że nasza mała firma wygrała z firmami z listy Fortune 500, z którymi konkurowaliśmy. Z tego i innych powodów wygraliśmy i przegraliśmy przekazanie pierwszej ręki, ale mieliśmy prawa do chwalenia się.

Jako wykonawca rządowy byłem kiedyś zmuszony do pracy w nadgodzinach za darmo, ponieważ umowa na to pozwalała, a wykonawca otrzymał wynagrodzenie za nadgodziny. Nie tylko byłem pochłonięty pracą i spędziłem 4 godziny w każdą niedzielę surfując po Internecie bez pracy. Nie trzeba dodawać, że przeszedłem bardzo szybko po tym, jak zaczęli bzdury.

Kupując Clarity jako nasz system zarządzania projektami, aplikację komercyjną, która jest tak zła, 100% osób, które z niej korzystają, błagało o powrót do naszego starego, domowego systemu (ten facet, który polubił i wybrał tę wersję, przeszedł na inną firma), ludzie nawet zgłosili się na ochotnika do pracy w swoim własnym czasie, aby dodać raport, który chcieli do naszego starego systemu. Ale zainwestowaliśmy pieniądze, więc utknęliśmy z nimi. Innymi słowy, odmowa porzucenia czegoś, co nie działa tylko dlatego, że było drogie.

Zwykłe marnotrawstwo. Wydatki na IT, które musiały zostać zmniejszone o wiele milionów. Tak więc sposobem na to było przylecieć informatyków z całego świata. Połóż je we flashowym hotelu na tydzień. Następnie w budynku, w którym odbywały się spotkania, położono nową podłogę. Marmur oczywiście. A z dnia na dzień, między spotkaniami każdego dnia, budynek został odnowiony. To każdego wieczoru przez tydzień.

Err ... priorytety ktoś?

Fantasyland.

Firma, za którą pracuję, zapłaciła 800 USD za licencję CHART FX - to nawet nie moje pieniądze, ale czuję się okradziona.

http://www.softwarefx.com/sfxNetProducts/ChartFX/

Tylko dla kopnięć, ich oprogramowanie będzie umieszczać pliki w dowolnym miejscu, w tym pliki rejestru i programów ... tak wszystko dla niektórych naff wyglądających wykresów.