20 powodów, dla których Projekty oprogramowania zawodzą
każdy projekt oprogramowania zaczyna się od wielkich marzeń i wielkich wizji. Gdzieś w alternatywnym wszechświecie istnieje projekt, który spełnia każde marzenie, ale zbyt często projekty programowe w naszym wszechświecie potykają się o linię mety i czasami ją przekraczają.
oczywiście, z definicji, niepowodzenie projektu oprogramowania nie jest rzeczą binarną. Możesz skończyć z kodem, który działa dobrze, ale nikt nie używa. Albo możesz skończyć z kodem, który nawet się nie skompiluje. Czasami można uratować coś użytecznego z płonącego wraku, a czasami najlepiej uciec, zanim wybuchnie.
kiedy tlący się bałagan ochładza, zaczynają się autopsje, ponieważ ludzie chcą wiedzieć, co poszło nie tak. Oto najczęstsi winowajcy.
zbyt mało członków zespołu
próba zrobienia zbyt wiele z zbyt małą liczbą programistów jest częstym problemem. Programiści mogą tylko szlifować tyle kodu, zanim się wypalą. Kiedyś pracowałem w zespole, w którym menedżer pomyślał, że właściwym sposobem na wyciśnięcie większej ilości pracy ze zwinnych zespołów jest zaplanowanie każdego” sprintu”, więc rozpoczął się natychmiast po poprzednim. Brak przemyślanych przerw, aby dowiedzieć się, co działa, a co nie. Sprint 42 zakończył się w środę o 13:59, a Sprint 43 rozpoczął się w środę o 14: 00. Spotkania z analizą retrospektywną zaplanowano już po rozpoczęciu kolejnego sprintu. Jakiś sprytny facet zasugerował, że zostaną przemianowani na „maratony” i wkrótce znalazł inną pracę.
oczywiĹ ” cie trudno wiedzieÄ ‡ ilu programistăłw wystarcza. Czasami przeszkody i problemy stają na drodze. To nie może być wina kierownika, że praca podwaja rozmiar, ale jeśli nie masz wystarczająco dużo ludzi na pracy, Twój projekt jest prawdopodobnie skazany na zagładę.
zbyt wielu członków zespołu
jeśli zbyt mało programistów może być złych, zbyt wielu może być potencjalnie gorszych, ponieważ efekty sieciowe mogą zniszczyć projekt oprogramowania. Więcej osób oznacza większą koordynację, a to oznacza więcej spotkań, co zabiera czas na pisanie kodu. Ale jeśli nie zorganizujesz wystarczającej liczby spotkań, wkrótce odkryjesz, że interfejs API zespołu A nie łączy mikrousług zespołu B.
byłoby miło, gdybyśmy mogli po prostu rzucić pieniądze na problem, przeceniając projekt, ale nie można.
zbyt duża komunikacja
pisanie oprogramowania to samotna Sztuka. Ludzie mogą pracować razem, ale tylko w ograniczonych atakach. Wielu programistów nienawidzi spotkań, ponieważ muszą zmienić swoje umysłowe biegi z głębokiej, wciągającej logicznej myśli w bardziej otwarty, społeczny tryb. To wymaga czasu. Niektórzy liderzy zespołów próbują walczyć z porażką, organizując więcej spotkań, aby wszyscy byli zsynchronizowani. To szlachetny wysiłek, ale słychać szlifowanie kół zębatych. Zespół musi dzielić się wystarczającą ilością informacji, aby pozostać zsynchronizowanym, ale każdy więcej po prostu marnuje cykle mózgowe.
podstawowe zmiany funkcji
w teorii Programiści lubią uważać się za zwinnych. Dlatego przyjmują to słowo. Ale czasami zwinność może wyrzucić wszystkich z równowagi. Wszystko zależy od tego, czy zmiana ta wymaga zasadniczych zmian w podstawowych ramach. Łatwo jest być zwinnym podczas przesuwania przycisku lub zmiany koloru. Ale gdy wymaga to przeróbki schematu bazy danych lub obijania się o sharding i replikację, nie ma łatwego sposobu na wdzięczne obracanie.
wybór niewłaściwej technologii do pracy
nawet jeśli starannie zaplanujesz i sporządzisz właściwą listę funkcji, może się nie udać, jeśli użyjesz złej technologii. Na przykład bazy danych są zaprojektowane tak, aby były ogólne i elastyczne, ale mają ograniczenia architektoniczne. Popchnij je, aby dostarczały coś, do czego nie są przeznaczone, i zwolnią do Wirtualnego zatrzymania, gdy poproszą o skalowanie. Albo możesz zacząć od bazy danych NoSQL, ponieważ brzmią fajnie tylko po to, aby później odkryć, że naprawdę potrzebujesz transakcji klasy ACID, aby zachować spójność, a baza danych ich nie oferuje. UPS.
słaba priorytetyzacja
dobrzy planiści sporządzają listę funkcji i ustalają ich priorytety. Ale czasami priorytety nie zgadzają się z rzeczywistością ich realizacji. W najgorszych przypadkach najtrudniej jest stworzyć najważniejsze funkcje.
co mają zrobić twoi Programiści? Jeśli skupią się na najważniejszej funkcji, nie zrobią żadnych postępów i mogą nie dostarczyć żadnej funkcjonalności. Ale jeśli zaczną niszczyć te łatwe, mogą skończyć z czymś, co jest bezwartościowe.
dobre planowanie wymaga więcej niż listy kontrolnej. Wizja architektoniczna musi uwzględniać potrzeby i koszty ich realizacji.
okno na rynku zamyka się
czasami to nie wina programisty. Jednym z moich projektów było przekształcenie bestsellerowego podręcznika w aplikację. Książka sprzedawała się jak ciepłe bułeczki w latach przed internetem. Plan zakładał wykorzystanie tego zapotrzebowania i stworzenie interaktywnej wersji, która pozwoliłaby ludziom sortować i przeszukiwać dane. Zespół programistów dostarczył oprogramowanie, które zawierało wszystko w książce, ale było szybsze, ładniejsze i znacznie lżejsze niż sama książka. Ale nikt już tego nie chciał. Było wystarczająco dużo innych źródeł i nikt nie potrzebował innej aplikacji, która robiła to samo, co serwisy informacyjne robią wszędzie.
czasami pomysł wydaje się świetny, ale rynek ruszył dalej.
złe decyzje architektoniczne
w jednym projekcie dostałem zadanie zmiany jednego numeru w jednym wierszu w bazie danych. Kiedy użytkownik zakończył rejestrację, miałem dodać numer id użytkownika do ostatniego zamówienia. Brzmi prosto, prawda? Ale system został zbudowany na architekturze mikroserwisów i nie mogłem tego rozwiązać pisząc jedną linię kodu, która kazałaby bazie danych zaktualizować tę kolumnę. Nie. Plan architektoniczny zakładał dodanie nowego wywołania mikroserwisu do istniejącego stosu, a nawet to było trudne, ponieważ moje pierwsze wywołanie mikroserwisu wymagało uruchomienia kolejnego wywołania mikroserwisu i tak dalej.
w końcu architekt, który stworzył tę sieć mikroserwisów, powiedział mi, że wszystko jest bardzo proste i nakreślił serpentynową ścieżkę przez pięć warstw architektury. Moim zadaniem było dodanie pięciu nowych wywołań API do pięciu różnych mikroserwisów, co oznaczało również dodanie pięciu zestawów automatycznych testów dla każdej warstwy. Każde API zostało opracowane przez inny zespół na przestrzeni lat, co wymagało ode mnie zrozumienia i naśladowania pięciu różnych stylów kodowania. Wszystko po to, by zmienić jeden numer.
decyzje architektoniczne mogą trwać całe życie — zwłaszcza jeśli twoje ego jest w nie gruntownie zainwestowane i nie możesz ich zmienić. Kierownicy projektów muszą być gotowi zauważyć, kiedy główny plan architektoniczny nie działa, więc można podjąć duże decyzje.
konflikty polityczne
obwinianie czynników politycznych za awarię techniczną może wydawać się złośliwe, ale coraz bardziej prawdziwe. W miarę jak projekty rozrastają się i obejmują wiele organizacji, nie powinno być zaskoczeniem, że pojawiają się frakcje, a grupy rywalizują o kontrolę, zasoby i ostatecznie władzę.
frakcje polityczne różnią się od rzeczywistych różnic technicznych. Często istnieją standardy techniczne lub podstawy kodu, które robią to samo na różne sposoby. Weź XML i JSON. Teraz, gdy już to napisałem, czuję, że fani albo spieszą się, aby wyjaśnić, dlaczego nie są tacy sami, a ich ulubiony wybór jest właściwy. Ale kiedy jedna część zespołu kocha jeden wybór, a druga ma konkurencyjną frakcję w najwyższym poważaniu, cóż, tarcie rozerwie ich na strzępy.
stało się to jeszcze bardziej powszechne, ponieważ architekci dzielą aplikacje na wiele mniejszych usług i interfejsów API. Różne grupy będą je kontrolować i nie zawsze będą się dogadywać. Jeśli Grupa A lubi JSON, a grupa B przylega do XML, cóż, Twój zespół będzie musiał zaimplementować oba lub zmusić jeden z nich do zmiany. Wszystkie trzy są uciążliwe dla każdego zespołu, który musi pracować zarówno z grupą A, jak i grupą B.
stawianie na technologię, która nie jest gotowa do produkcji
Programiści uwielbiają najnowsze narzędzia i frameworki. Chcą wierzyć, że nowe podejście zmiecie wszystkie brudy, które niszczą poprzednie pokolenie.
ale często następna generacja nie jest gotowa do użycia w produkcji. Nowe funkcje mogą wydawać się doskonałe, ale często występują luki, które nie są od razu oczywiste. Czasami kod obsługuje tylko kilka typów plików lub interfejsy z tylko kilkoma bazami danych. Inne pojawią się wkrótce, zapewniają, ale twój projekt musi zostać wysłany w tym miesiącu, a „wkrótce” może oznaczać sześć lub więcej miesięcy, zanim potrzebne funkcje zostaną ukończone.
obstawianie technologii, która wkrótce się zdezaktualizuje
z mojego doświadczenia wynika, że stare rzeczy są zwykle bardziej niezawodne i sprawdzone w walce, ale to nie znaczy, że stara technologia jest idealna. Może brakować funkcji, które są niezbędne dla projektu oprogramowania po jego uruchomieniu. Co gorsza, obstawianie starych technologii może spowodować, że stracisz przyszłe możliwości w oparciu o zmiany w przyszłości. Pojawiają się nowe pomysły, protokoły i formaty plików, które mogą zostać niezrealizowane. A jeśli ktoś z konkurencyjnej drużyny upiera się, że popierasz jakiś nowy protokół, to stara technologia będzie bolała.
nierealne terminy
terminy są trudne. Wiele projektów musi trafić na rynek w określonym sezonie lub wydarzeniu. Jednak kiedy terminy są po raz pierwszy zapisywane, twoi programiści nie zaczęli odkrywać przeszkód i przeszkód na swojej drodze. Następnie, jeśli projekt się ześlizgnie i Zdarzenie przejdzie bez uruchamiania oprogramowania, cały projekt jest postrzegany jako awaria, nawet jeśli kod ma działać płynnie. Terminy pomagają wszystkim skupić się i zebrać razem, ale także tworzą oczekiwania, które mogą być nierealne.
nieprzewidziana konkurencja
dobry menedżer produktu bada konkurencję przed nurkowaniem, ale nikt nie może przewidzieć, jaka konkurencja może pojawić się znikąd. Jeśli nowi konkurenci wprowadzają nowe funkcje, które musisz zduplikować, zobacz sekcje dotyczące zmian funkcji i niedopasowania priorytetów powyżej.
przyspieszanie procesu
wiele projektów programistycznych zaczyna się jako wizja osoby lub zespołu, który chce coś naprawić. Wymyślają zdanie takie jak ” Snapchat dla Y „lub” Uber Dla Y”, a następnie oczekują, że zespół produktu będzie tak responsywny, jak Snapchat lub Uber. Problem polega na tym, że ustalanie zakresu projektu, szkicowanie przepływów danych i wyobrażanie sobie interfejsu użytkownika to często dziesięć razy więcej pracy niż pisanie kodu. Ale imagineers chcą przejść od pomysłu do kodu od razu.
szkielety, Schematy baz danych i historie użytkowników to nie tylko machanie ręką, ale istotna część pracy. Ale większość ludzi chce wierzyć, że projekt oprogramowania to tylko pisanie kodu, aby wdrożyć pomysł.
fałszywa wiara w moc oprogramowania
marzyciele często mają nierealistyczne przekonania w moc oprogramowania, które może zmienić świat. Wielu wyobrażało sobie, że media społecznościowe nas zjednoczą, ale w jakiś sposób jest to po prostu odsłonięte linie uskoków, które zawsze były oczywiste. Projekty programistyczne często zaczynają się od slide deck ’ ów, które obiecują zrewolucjonizować jakiś zakątek świata. Kiedy wrzucanie bitów do bazy danych nikogo nie zmienia, ludzie denerwują się, nudzą, dezorientują lub gorzej. Mówią, że oprogramowanie jest zepsute, ponieważ nie dostarcza magicznej transformacji, której wszyscy oczekiwali.
wiele projektów programistycznych może skompilować, przekazać QA, wysłać, a nawet uzyskać przyzwoite recenzje, ale ostatecznie nie udaje się osiągnąć żadnej z obietnic na pokładzie slajdów, ponieważ, cóż, te obietnice zmiany świata są niemożliwe.
Evil subcontractors
kochamy dostawców, którzy produkują biblioteki i narzędzia, które pozwalają nam tworzyć magię za pomocą zaledwie kilku linijek kodu. Od czasu do czasu porywają swoją moc i używają jej do zniszczenia projektu. Arkusz budżetu dla wersji 1.0 był tak dobry, że kierownictwo nie zawahało się zatwierdzić wersji 2.0. Następnie sprzedawca decyduje się wycisnąć nas przez potrojenie lub pięciokrotność ceny.
ten efekt można odczuć nawet wtedy, gdy dostawcy nie robią tego celowo. Darmowe poziomy mogą sprawić, że projekt będzie wyglądał bardzo tanio. Wtedy, gdy popyt rośnie, a druga wersja rozszerza popyt, realne ceny kopią.
Sea change
w ciągu roku z pandemiami i protestami nic nie zmieniło się szybciej niż zeitgeist. Czy projekt sprawił, że silna ochrona prywatności stała się główną cechą? UPS. Pandemia zainteresowała wszystkich śledzeniem kontaktów. Czy ktoś chciał się skupić na podróżach służbowych? UPS. Przemysł hotelarski upadł. Większe projekty oprogramowania, które mogą trwać rok lub dłużej, ryzykują, że zostaną zniszczone przez kataklizmiczne wydarzenia. To, co na początku wydawało się wspaniałym pomysłem, może wydawać się beznadziejnie zagubione i odłączone, gdy nadszedł czas, aby przejść na żywo.
zmiany techniczne
to nie tylko zmiany na świecie. Zmiany pływowe w społeczności technologicznej mogą mieć ten sam efekt. NoSQL był kiedyś genialnym pomysłem, który uwolniłby nas od schematu relacyjnego. Wtedy ktoś zdał sobie sprawę, że pliki nadmuchują, ponieważ każdy rekord nosił lokalny schemat. Dobry zwinny zespół programistów może się zmienić, gdy zmiany technologiczne zmieniają postawy liderów i klientów. Ale nawet najbardziej zwinne zespoły nie radzą sobie z dużymi zmianami, które wysysają całe powietrze z ich planów architektonicznych. System został zbudowany przy założeniu, że X był świetnym pomysłem i nagle X jest brudem. Czasami najlepiej jest wysadzić go w powietrze i zagrać ponownie.
zbyt wiele dodatków
niektóre projekty oprogramowania zaczynają się dobrze, a nawet wysyłają z powodzeniem. Następnie ktoś dodaje dodatkową funkcję lub trzy, wszczepiając nowy kod do istniejącej wersji w taki sposób, że kod nadal kuleje. Heroiczni deweloperzy mogą to zrobić kilka razy, zwłaszcza jeśli początkowy architekt dobrze zaplanował. Ale w pewnym momencie Fundacja rozpada się. Może baza danych nie poradzi sobie z ładunkiem. Może jest zbyt wiele połączeń potrzebnych do zaspokojenia różnych zapytań. Dobre oprogramowanie może stać się zbyt grube, czasami dzięki niewielkim ulepszeniom, które zepchnęły go na margines.
przenoszenie słupków celów
początkowe plany wymagały bazy danych do śledzenia wydatków klientów, aby pomóc w planach marketingowych. Następnie jakiś geniusz dodał funkcję, która wykorzystuje sztuczną inteligencję do korelowania wydatków z prognozą pogody. Lub ktoś inny chciał, aby oprogramowanie automatycznie licytowało reklamy w wyszukiwarkach. Zmiana miejsca docelowego może upend projektu.
rzadko zdarza się, że zmiany same psują rzeczy. Ale nowe cele mogą ujawnić słabości i wyzwalać awarie. Być może zespół jest teraz zbyt mały, aby pomyślnie zakończyć projekt. Może fundamenty techniczne są szalenie nieefektywne dla nowego podejścia. Trudno jest wszystkim przewidzieć niepokojące kombinatoryki, gdy podejmowana jest decyzja o zmianie celów.