Jakie są najgorsze fałszywe oszczędności w tworzeniu oprogramowania? [Zamknięte]

Jakie są najgorsze fałszywe ekonomie (czyli sposoby oszczędzania pieniędzy, które ostatecznie kosztują więcej niż oszczędzają) powszechne w branży oprogramowania i jak z nimi walczyć?

Dług techniczny

tzn. „Po prostu zrób to szybko, dokonamy refaktoryzacji później”. Po pierwsze dlatego, że jeszcze nie widziałem, żeby ktoś zaangażowany w takie zachowanie faktycznie zreformował później. Po drugie, ponieważ robienie rzeczy w szybki sposób, zamiast w dobry sposób, utrudnia dodawanie przyszłych funkcji lub rozwiązywanie przyszłych błędów, aby w dłuższej perspektywie stracić czas.

Niestety wielu nadal uważa, że oszczędza to cykli programistów, aby mogli zrobić coś szybko. Myślę, że to możliwe, ale jeszcze nie widziałem tego w praktyce.

Zatrudnienie 2 tanich programistów zamiast 1 naprawdę świetnego. (za tę samą cenę)

Mój przykład byłby całkowitym przeciwieństwem przykładu NimChimpsky'ego , a mianowicie:

Próba opracowania w domu czegoś, co można kupić z półki.

Zwykle dzieje się tak z powodu braku faktycznego sprawdzenia rynku, aby sprawdzić, czy coś już istnieje, co rozwiąże problem. Mogą to spotęgować programiści, którzy lubią „zanurzać się” w kodowaniu przed rozpoczęciem jakichkolwiek badań, oraz kierownicy projektów, którzy nie uwzględniają w tym czasie = pieniędzy.

Jednym z najczęstszych przykładów, jakie widziałem w mojej dziedzinie, tworzenie stron internetowych, są firmy próbujące opracować i wewnętrzny system CMS. Te niezmiennie zaczynają się od małych, ale wkrótce stają się wzdęte i wymykają się spod kontroli, ponieważ funkcje są włączone, podczas gdy przez cały czas istnieje wiele bezpłatnych produktów i ram, które byłyby znacznie lepiej dostosowane.

Brak dedykowanych zasobów do zarządzania projektami

Kilkakrotnie doświadczyłem, kiedy zatrudniono kilku programistów, a ktoś, kto ma już wymagającą pracę dzienną, powinien był zarządzać projektem, ale w rzeczywistości był zbyt zajęty innymi zadaniami, więc projekt nigdy nie nabrał rozpędu. Programiści tworzyli „prototypy” i takie tam, ale bez przewodnika większość z nich biegała w kółko, aby wyglądać na zajętą.

Zły sprzęt dla nowych programistów

Kiedyś spotkałem firmę, w której obowiązywała zasada: „nowi programiści muszą pracować na naprawdę starym komputerze z małym ekranem, dopóki nie udowodnią, że są godni”. Nic dziwnego, że taka polityka spowodowała negatywną selekcję, która wyparła dobrych ludzi, którzy zawsze mają wybór do pracy w bardziej zdrowym środowisku.

Możemy zaoszczędzić pieniądze, mając programistów pełniących funkcje testerów / pisarzy technicznych

Jeśli płacisz programistom wynagrodzenie za pracę testera / pisarza technicznego, to marnujesz pieniądze i prawdopodobnie dostajesz pracę niższej jakości niż ktoś, kto poświęcił swoją karierę temu zadaniu. Ponadto, gdy programiści stoją w obliczu napiętych terminów, testy i dokumentacja najprawdopodobniej zostaną porzucone lub zrobione na wpół, by je spełnić.

BTW: Deweloperzy ZAWSZE mają napięty termin.

Badanie / czytanie / pisanie kodu niezwiązanego z rozwojem produktu jest marnotrawstwem zasobów.

W to wierzą niektórzy programiści, a nawet menedżerowie. Zwykle po prostu programują w oparciu o wiedzę w ich głowach, szukają odpowiedzi i szukają odpowiedzi, gdy napotykają problemy. Nie stale aktywnie poszerzają swoją wiedzę. Moim zdaniem powinniśmy zawsze być na bieżąco, a zgromadzona przez nas wiedza byłaby dla nas przydatna w rozwiązywaniu istniejących i przyszłych problemów. Oczywiście musisz mądrze poświęcić na to swój czas.

Jest to również podobne do odpowiedzi Dana . Niektórzy menedżerowie chcą po prostu, aby programiści szybko zanurkowali i opracowali produkt zgodnie z wymaganiami bez badania istniejących produktów na rynku.

W wielu przypadkach offshoring kosztuje więcej pieniędzy. W mojej firmie bardzo trudno jest znaleźć nowe stanowiska dla pracowników, jesteśmy mocno naciskani na outsourcing. Trudno też znaleźć kontrahentów na miejscu; istnieje stosunek 3: 1 offshore do brzegu, które mają utrzymać. W związku z tym wiele zespołów po prostu wynajmuje kilkanaście jednostek offshore i prawie z nich nie korzysta, tylko po to, aby uzyskać 4 kontrahentów na miejscu.

Długie pętle zwrotne!

Zdarza się każdemu: budujesz coś, co uważasz za niesamowite, i okazuje się, że się myliłeś. To nie jest problem. Problemem jest to, ile czasu spędzasz na budowaniu, zanim dowiesz się, że powinieneś przestać.

Na wysokim poziomie widzisz ten problem z długimi cyklami uwalniania. Jeśli budujesz przez rok bez opinii, uprawiasz hazard przez cały rok. Im częściej wypuszczasz, tym mniejsze są twoje gry i tym lepiej radzisz sobie z hazardem.

Ale dzieje się to również na najniższych poziomach. Jako programista bardzo lubię częste przeglądy kodu (lub, lepiej, programowanie parami), ponieważ ogranicza to czas, w którym mogę robić coś głupiego, zanim ktoś powie: „Hej, istnieje prostszy sposób!” Z tego samego powodu lubię, aby moje testy jednostkowe działały szybko i często, dzięki czemu mogę wychwytywać i zabijać błędy, zanim będą rosły.

Gdy zaczniesz zauważać znaczenie krótkich pętli sprzężenia zwrotnego, zobaczysz je wszędzie. Np. Wojskowe pojęcie pętli OODA .

Nie moja własna anegdota, ale kiedyś usłyszałem o sklepie, który przestał dostarczać bezpłatną kawę swoim twórcom, mówiąc im, że za każdym razem, gdy chcą dostać kawę, mogą swobodnie iść do najbliższej kawiarni (około dziesięciu minut podróż w jedną stronę) i kup niektóre.

Prawie definicja fałszywej gospodarki.

Udostępnianie stacji roboczych z jednym ekranem, ponieważ drugi monitor jest zbyt drogi . Nawet jeśli oszczędza to tylko godzinę pracy każdego roku, drugi ekran jest nadal dobrą inwestycją. Wiem na pewno, że mój zaoszczędził mi wiele, wiele godzin pracy.

Konfiguracja wielu monitorów może sprawić, że prawie każde zadanie będzie bardziej wydajne, nie tylko zadania programistyczne. Trzy monitory są nawet lepsze niż dwa, ale efekt staje się mniej wyraźny z każdym dodatkowym ekranem.

Konfiguracje dla wielu monitorów:

• zmniejszyć narzut przełączania okna
• pozwalają mieć oko na rzeczy działające w tle (poczta, kompilacja itp.).
• dać ci poczucie wolności. To jak bycie w atrium vs. bycie w szafie na miotły.
• itp...

Najtańszy sprzęt podany konsultantowi, gdy kosztuje on ponad 150 $ / godzinę .

Ujmując to z perspektywy czasu, lepszy sprzęt może przynajmniej zwiększyć wydajność pracy o 30 minut dziennie. To dałoby 30min * 20 dni pracy na miesiąc = 600min / miesiąc = 10 godzin / miesiąc> więcej niż 1 dzień pracy = 10 godzin * 150 $ / godzina = 1500 $

Czy konsultant nie byłby bardziej wydajny, gdyby miał komputer za 1500 $? Czy sprawiłoby to, że konsultant byłby mniej zirytowany?

Teraz wydaje się, że problem polega na tym, że istnieją dwa budżety, jeden dla konsultanta i jeden dla sprzętu komputerowego.

Miesiące pracy oszczędzają dni planowania

(Niewystarczająca ilość czasu na planowanie)

Podejrzewam, że najbardziej rozpowszechnionymi są menedżerowie, którzy po prostu nie zapewniają programistom narzędzi potrzebnych do wydajnego wykonywania pracy.

Zasadniczo punkt 9 w teście Joela .

Niestety, w niektórych miejscach wciąż można stosować „rzucanie (wystarczającą) ilością ciał” . Prawo Brook'a przeczy temu w The Mythical Man-Month , choć niektórzy wymagają doświadczenia, aby nauczyć się tej lekcji. Zasadniczo nie mogę tego powstrzymać, ponieważ kierownictwo może wierzyć w fałszywe oświadczenie o dodawaniu ludzi i niepłaceniu za to ceny.

Codzienne spotkania :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...  

Kupowanie gotowego oprogramowania zamiast rozwijania go wewnętrznie.

Mam doświadczenie w zakresie systemów zarządzania na skalę przedsiębiorstwa, koncentrujących się zarówno na HR, jak i na laboratoriach biologicznych.

Gotowe rozwiązanie kosztowało 50-100 tys. Funtów i wymagało dalszego rozwoju i dostosowywania do wymagań biznesowych.

Opracowanie wewnętrznego rozwiązania zajęło (<6) miesięcy, a równolegle pracowano nad innymi projektami i wykorzystano już zatrudnionego programistę.

Przeszedłem z sektora publicznego, w którym uruchomiliśmy wewnętrznie opracowany LIMS (system zarządzania informacjami laboratoryjnymi), do dużego międzynarodowego farmaceutyka, w którym wdrożenie gotowego rozwiązania zajęło ponad rok i nie było kompletne.

(6 miesięcy już zatrudnionego programisty pracującego równolegle nad innymi projektami. Więc około 10 tys. A to nie obejmuje kosztów wsparcia związanych z gotowym rozwiązaniem). Najważniejsze jest to, że faktycznie opracowano wewnętrznie opracowany system! Masz więc dodatkowe korzyści związane z kosztami, których nie mogę obliczyć.

Zgodziłbym się na podstawowe strony internetowe itp., Po co zawracać sobie głowę tworzeniem własnych. Ale dla każdego dużego złożonego systemu i jeśli masz już umiejętności domowe, zbudowałbym go sam .

Kupowanie drogich, gotowych produktów, gdy alternatywy open source są lepsze i bezpłatne.

Ile firm używa git? Ile firm korzysta z jakiejś gównianej, przedsiębiorczej kontroli wersji?

Używanie „prostych” języków bez dużej ekspresji

Tak, łatwiej jest znaleźć programistów do obsługi kodu, ale trudniej jest znaleźć dobrych programistów, którzy nie tylko uczą się najnowszego modnego hasła, które ich zatrudni. Tak, ułatwia zrozumienie kodu poszczególnych bitów, ale czyni go tak sztywnym jak 2x4 i zwiększa objętość kodu, który należy zrozumieć. Tak, jest wspierany przez wielką korporację, ale powiedział, że ogromna korporacja wprowadza innowacje powoli i biurokratycznie.

Zli kierownicy projektów / kierownicy zespołu.

Ponieważ jedna niekompetentna osoba ma moc zrujnowania pracy grupy ludzi. Ostatecznie projekt byłby o wiele lepszy bez decyzji kierownictwa wyższego szczebla (kierownika projektu / zespołu).

Dozuj decyzję „Po prostu zrób to szybko, dokonamy refaktoryzacji później”.

Brak wymagań użytkownika

Ważnym i trudnym krokiem przy projektowaniu oprogramowania jest określenie, co tak naprawdę chce klient.

Wierzcie lub nie, czasem brakuje tej części lub jest ona nieaktualna. Koszt polega na tym, że tworzy się funkcje, o które użytkownik końcowy nigdy nie prosił.

Wydajność jest warta więcej niż kreatywność

Kreatywność jest trudna do zmierzenia i najczęściej niemożliwa do zaobserwowania, nie wspominając o pomiarze, jeśli chodzi o rozwój oprogramowania. Z drugiej strony produktywność można zmierzyć (często słabo) i można ją zaobserwować.

W rezultacie programiści, którzy potrafią (pisać więcej linii kodu | pisać kod szybciej | recytować technobabble szybciej w odpowiedzi na pytania | są bardziej widocznie produktywni), są zwykle cenieni bardziej niż ci, którzy (używają mniej linii kodu, aby rozwiązać ten sam problem | więcej czasu zajmuje napisanie kodu, ale stworzenie bardziej niezawodnego produktu | zrozumienie tematu wystarczająco dobrze, aby odpowiedzieć na pytania w prosty, łatwy do zrozumienia, angielski | twórczo rozwiązać problemy).

Wszystkie poniższe informacje mogą być złe, jeśli są używane lub nie są używane niewłaściwie

• oprogramowanie zewnętrzne vs wewnętrzne

• Zgodność z ISO 9001 (oszczędność - ograniczenie ryzyka utraty MSS w przypadku spadku jakości produktu)

• outsourcing rozwoju / kontroli jakości

• procedury rozwoju / kompilacji / wydania / wsparcia

Posiadanie zbyt wielu menedżerów dostaw niepodlegających rozliczeniu.

Kilka lat temu w naszej firmie mieliśmy kilka dużych projektów budżetowych, a rekrutacja była na szczycie. W tym czasie nasza firma zatrudniła zbyt wielu kierowników dostaw (wielu z nich nie było IT!) I bardzo mało programistów / testerów. Stosunek menedżera do programisty wynosił dosłownie 1: 2. Później, po zakończeniu tych projektów, mieliśmy sytuację, w której wielu z tych menedżerów (niektórzy z nich byli prawdziwymi zwolennikami) siedzieli na ławce i nic nie robili. Mieliśmy jeden cykl oceny, w którym wszyscy otrzymywali niewielkie / żadne podwyżki (nawet nas, pracowitych programistów, westchnienie), aby firma nie musiała nikogo zwalniać! Na szczęście firma zdała sobie sprawę z tej sytuacji i przeprowadziła RIGHTSIZING w pierwszym kwartale tego roku!

Optymalizacja przed profilowaniem (inaczej przedwczesna optymalizacja).

Zbyt wiele razy widziałem, jak ktoś sięgał po sprytne rozwiązanie, które niepotrzebnie komplikuje konserwację i czytelność, ponieważ jest szybsze. Oczywiście kod nie został oznaczony (nawet w przypadku mikro-testów), więc szybko staje się „szybszy w oparciu o bardziej przekonujący argument” w części kodu, która najprawdopodobniej nie wpłynęła na ogólną wydajność całego aplikacja znacznie.

Jako taka, jest to bardzo fałszywa ekonomia i rodzaj fałszywej ekonomii, która czasami uwikłuje nawet doświadczonych profesjonalistów.

Ograniczony lub brak dostępu do Internetu

Ponieważ oczywiście Twoi pracownicy będą korzystać z Internetu do grania w gry na Facebooku, nie szukając odpowiedzi na pytania techniczne dotyczące Stackoverflow.

W rzeczywistości Internet jest ogromnym wzrostem wydajności i chociaż może być właściwe użycie pewnego rodzaju filtru strony dla naprawdę podejrzanych stron, jest coś nie tak, jeśli blokuje plik readme ze studia wizualnego lub blokuje strony rządu Telford z jakiegoś powodu „turystyka seksualna”

Zmuszenie programistów do korzystania z 15-calowego monitora i komputera o niskiej specyfikacji, ponieważ jest to standard korporacyjny.

Monitory o rozsądnych rozmiarach są tanie, szybkie w instalacji i zwiększają produktywność programistów, a także sprawiają, że programiści myślą, że ci na nich zależy.

Zbyt wielu licencjatów administracji biznesowej (lub im podobnych), hierarchicznie zorganizowanych, którzy starają się zastosować to, co ich zdaniem dotyczy współczesnego zarządzania: przeszkadzanie ludziom z „kluczowymi wskaźnikami wydajności”, „umowami SLA” i tym, co nie, wymagające „raportów” (bez, oczywiście, dbając o infrastrukturę, aby je wygenerować), aby programiści marnowali swoje dni na wypełnianie fantazyjnych arkuszy EXCEL, raportów z czwartego kwartału i tego, co nie, i kopiowanie z jednego wspaniałego nowego narzędzia do zarządzania i wklejanie do innego (wydaje się, że regułą jest narzędzia te nigdy nie są zintegrowane ani integrowane ze sobą) i biorą udział w spotkaniach, na których prezentowane są raporty i dane liczbowe (i wszyscy czują się winni, że nie wypełnili tego lub innego KPI).