Jakie są sygnały ostrzegawcze o nadchodzącym losie, na które należy uważać przy projekcie? [Zamknięte]

66

Praca nad nieudanym projektem jest jedną z niewielu rzeczy, które łączy większość programistów, niezależnie od używanego języka, branży lub doświadczenia.

Projekty te mogą być świetnymi doświadczeniami edukacyjnymi, katastrofami miażdżącymi dusze (lub obydwoma!) I mogą wystąpić z wielu powodów:

  • zmiana kierownictwa górnego serca
  • zespół niedostatecznie wykwalifikowany / niedofinansowany
  • pojawienie się lepszego konkurenta podczas cyklu deweloperskiego
  • nad / pod zarządzaniem

Czy po opracowaniu kilku takich projektów można wcześnie rozpoznać, kiedy projekt jest skazany na porażkę?

Dla mnie dużym znakiem jest twardy i szybki termin zewnętrzny w połączeniu z pełzaniem funkcji . Widziałem projekty, które zostały dobrze zaplanowane i postępowały zgodnie z harmonogramem, strasznie zjeżdżają z szyn, gdy późne prośby o funkcje zaczęły się pojawiać i dodawać do ostatecznego „rezultatu”. Wnioskodawcy tych wniosków zasłużyli na przydomek Columbo , ponieważ rzadko wychodzili z pokoju bez pytania o „jeszcze jedną rzecz”.

Jakie znaki ostrzegawcze, na które zwracasz uwagę, wywołują w twojej głowie dzwonki alarmowe o zbliżającej się zagładzie?

ConroyP
źródło
Robert Glass napisał „Universal Elixir and Other Computing Projects Failed”. Wydana w 1977 r. Książka była zbiorem wcześniej napisanych przez siebie kolumn, z których każda dotyczyła projektu, który się nie powiódł, i szukała przyczyn niepowodzenia. Książka tworzy DOSKONAŁĄ listę znaków ostrzegawczych.
John R. Strohm,
Dwa artykuły - Patologia projektu i (przesadny) Raport Chaosu . Daj Marsz Śmierci dobrą lekturę, jeśli szukasz książki.

Odpowiedzi:

70

Heroiczne kodowanie

Kodowanie do późnych godzin nocnych, długie godziny pracy i długie nadgodziny są pewnym znakiem, że coś poszło nie tak. Co więcej, moje doświadczenie jest takie, że jeśli zobaczysz kogoś pracującego do późna w którymkolwiek momencie projektu, to tylko pogorszy się. Może robi to tylko po to, by przywrócić swoją jedyną funkcję zgodnie z harmonogramem i może mu się to uda; jednak takie kodowanie kowboja jest prawie zawsze wynikiem niepowodzenia planowania, które nieuchronnie spowoduje więcej tego wkrótce. Tak więc, im wcześniej zobaczysz projekt, tym gorzej będzie w końcu.

Fishtoaster
źródło
12
Jedynym usprawiedliwieniem dla pociągnięcia wszechstronnego jest zajęcie się problemem SZCZEGÓŁOWYM dla NIEZWYKŁEGO sztywnego terminu. Może to tylko ja, ale kod, który piszę o trzeciej nad ranem, kiedy jestem zrzędliwy i pozbawiony snu, wygląda na cholernie okropny, oglądany w okrutnym świetle dnia.
BlairHippo,
5
Cóż, druga wymówka to bycie studentem. Nieodpowiednie planowanie projektu jest wówczas równoznaczne z kursem. :)
Fishtoaster,
20
Och, Chrystusie. Szkoła Wyższa. Pamiętam, jak siedziałem przed terminalem, gdy wstało słońce, pchając *i &mniej więcej przypadkowo przed zmiennymi w moim kodzie C ++ w nadziei, że to cholerstwo zacznie działać. Nie tęsknię za college'em.
BlairHippo,
2
Na początku tego roku mieliśmy taki projekt - jeden facet pracował regularnie do 2 nad ranem, a ja zaczynałem od 4 nad ranem. Wykonaliśmy jednak zadanie, pomimo narzuconych nam absurdalnych ram czasowych (zobowiązaliśmy się do ich ukończenia w terminie ustawodawczym). Wciąż sprzątamy i refaktoryzujemy teraz!
Chris Buckett,
3
Narażę moją karmę na niebezpieczeństwo tutaj i wskażę, że „heroiczne kodowanie” jest późnym wskaźnikiem. Projekty mają kłopoty na długo przed przejściem do fazy, w której zaczyna się „heroiczne kodowanie”. Zazwyczaj istnieje wiele wczesnych wskaźników problemów, które pojawiają się na długo przed rozpoczęciem kodowania. Niestety są zbyt często ignorowane. Robert Glass napisał obszernie na ten temat, w „The Universal Elixir” oraz w innych książkach. Zignoruj ​​go na własne ryzyko.
John R. Strohm,
44

Gdy programiści zaczynają wygrywać argument „Kod jest okropny, musimy zacząć od nowa”. na każdej dojrzałej aplikacji.

Możesz myśleć, że możesz go lepiej zbudować lub lepiej zrozumieć problem, ale tak naprawdę nie. Aha, i te wszystkie brzydkie łaty? Są to poprawki rzeczywistych problemów, które prawdopodobnie ponownie wprowadzisz w przepisywaniu.

Ponadto, pewnego dnia będziesz musiał wyjaśnić kierownikowi projektu, dlaczego po 6 miesiącach pracy masz prawie do 85% możliwości i 150% błędów, które aplikacja miała na początku.

rev JohnFx
źródło
9
Czy to nie jest tylko podsumowanie niesławnego przepisywania Netscape?
Jasarien
4
Nie zgadzam się. Istnieją pewne niebezpieczeństwa związane z przepisywaniem (np. Syndrom drugiego systemu), ale jeśli wiesz o nich, przepisywanie nie jest bardziej niebezpieczne niż jakikolwiek inny projekt typu green-field.
nikie
4
Czasami musisz amputować i zastąpić czymś, co sprawi, że aplikacja będzie silniejsza, lepsza, inteligentniejsza. Ale kluczowym słowem jest amputacja, a nie zabijanie i wskrzeszenie.
Erik Reppen
2
Może to być w dużej mierze prawda, ale nie do końca prawda. Przeszedłem taki projekt około 9 miesięcy temu i był to sukces. Spędziłem ponad połowę czasu na opracowywaniu testów, aby udowodnić, że jest poprawne i że stare / nowe błędy nie zostały wprowadzone do nowej wersji, a tymczasem znalazłem kilka nowych błędów w istniejącej. (Chociaż przypuszczam, że to sprawia, że ​​ta odpowiedź jest prawdziwa jako znak ostrzegawczy )
Izkata
41

Nowe narzędzie jako narzędzie do rozwiązywania problemów.

Kiedy ludzie zaczynają planować używać nieznanych narzędzi, nie mam nic przeciwko, ale mam na to oko. Kiedy zaczynają planować wszystkie reklamowane zalety tych narzędzi w harmonogramie, martwię się. Zabawne przykłady:

  • Możemy ogolić miesiąc harmonogramu, ponieważ spróbujemy użyć języka obiektowego (mimo że mamy tylko programistów c).
  • Wypróbujemy tę nową funkcję Scrum - która rozwiąże wszystkie nasze problemy z procesem!
  • Wiem, że trwa to w połowie projektu, ale co, jeśli zmienimy ORM na coś nowego?

Nowe technologie i praktyki są świetne, ale prawie nigdy nie uzyskasz wszystkich korzyści z bramy.

Fishtoaster
źródło
3
Byłem kiedyś przy projekcie, który miał dwa widelce dzięki dwóm interfejsom - komputerowemu i przenośnemu gadżetowi. Szacunki czasowe opierają się na założeniu, że moglibyśmy użyć tych nowych, błyszczących elementów „EJB” do ponownego wykorzystania kodu warstwy modelu między nimi. Niestety baza danych była tak przerażającym gniazdem szczurów, że wszystkie wyciągnięte z niej dane musiały pochodzić ze ściśle skonstruowanych zapytań SQL; pełne zapełnienie fasoli byłoby zbyt brutalnym hitem. Kiedy okazało się, że (niespodzianka!) Wersja komputerowa potrzebuje więcej danych niż wersja podręczna, oś czasu poszła prosto do piekła.
BlairHippo
2
„Cudownie! Teraz, gdy uratowaliśmy platformę testów jednostkowych, możemy zacząć skracać czas od tej długiej fazy kontroli jakości!”
Arkaaito,
hahaha. Doskonały. +1 za nowe narzędzie rozwiąże wszystkie moje problemy.
szybko_now
40

Dla mnie największym pojedynczym problemem, który można od razu dostrzec, jest to, że firma uznaje pisemne wymagania za stratę czasu.

Zasadniczo; Brak pisemnych wymagań

To pocałunek śmierci.

John MacIntyre
źródło
3
Lub gorzej, pisemne wymagania, których nikt nie czyta. W rzeczywistości brałem udział w projektach, w których napisano obszerne wymagania i nigdy nie pokazano programistom.
JohnFx,
1
@Adolf Garlic - Pisemne wymagania nie zapewnią Ci terminowości ani budżetu, ale nigdy nie spełnisz oczekiwań, jeśli oczekiwania nie zostaną przekazane, nie będziesz mieć wszystkich szarych obszarów przybranych i ciągle się zmieniają (twoje mentalne pomysły się zmienią ).
John MacIntyre
5
Kiedyś miałem analityka biznesowego, który powiedział mi, że wymagania nie są potrzebne. Jaka jest znowu praca analityka biznesowego? O tak, aby napisać wymagania! Otrzymalibyśmy takie wymagania, aby działał tak jak hkjk.com.
HLGEM
1
Jeśli szukasz niestandardowego produktu dla jednego klienta, na pewno. Ale jeśli piszesz następną wersję programu Powerpoint lub następną wersję wewnętrznego oprogramowania, nie widzę sensu. Zawsze będziesz uczyć się więcej o wymaganiach podczas programowania (np. Że niektóre wymagania nie są przydatne, a inne nie są możliwe). Wolę wykorzystać tę wiedzę i zmienić wymagania podczas opracowywania niż wypuszczać gorszy produkt.
nikie
1
@nikie - Nie mówię, że wymagania powinny być statyczne i nigdy się nie zmieniać. Mówię, że powinieneś zapisać to, aby zapobiec błędnej komunikacji i zapobiec zmianie pomysłów u ludzi z czasem. Jeśli wymagania powinny ulec zmianie, zmień je, ale zachowaj aktualne wymagania. Czy to ma sens?
John MacIntyre,
33

Zarządzanie rozłączeniem

Kiedy osoby odpowiedzialne za terminy, funkcje, personel itp. Zostają odłączone od osób odpowiedzialnych za realizację projektu. To może prowadzić do:

  • Pełzanie funkcji, gdy klient rozmawia z kimś, kto nie rozumie kosztów funkcji
  • Syndrom miesiąca miesiąca, w którym nowi programiści są wrzucani do projektu na tyle późno, aby być bardziej przeszkodą niż pomocą
  • Nierealistyczne terminy, tworzone przez ludzi, którzy muszą radzić sobie z konsekwencjami biznesowymi decyzji o terminie, ale nie konsekwencjami ich wdrożenia.
  • Produkty, które nie rozwiązują problemu, gdy zarządzanie pomiędzy klientami jest utrudnione przez kierownictwo.
  • Słabe zarządzanie ryzykiem, gdzie potencjalne problemy nie są komunikowane wystarczająco wcześnie między deweloperami a zarządem.

Kiedy więc wygląda na to, że zarządzanie jest niezainteresowane projektem, źle komunikuje się, nie słucha klientów lub nie słucha zespołu deweloperów, biegnij na wzgórza.

Fishtoaster
źródło
+1 za pierwszy przedmiot. Byłem klientem w scenariuszu, o którym wspomniałeś, i jest to złe dla wszystkich (nikt nie chce nieoczekiwanego rachunku i nikt nie chce spierać się o jego zapłacenie).
terroroffours
+1 amen. Byłem tam, zrobiłem to, nie dbam o to, aby znów być w tej pozycji.
Evan Plaice,
+1 za to, że żyję z tymi wszystkimi pociskami (może z wyjątkiem czwartego).
AShelly
Świetna odpowiedź. Nawet jeśli nie zawracasz sobie głowy opracowaniem i po prostu wstawisz „Management Disconnect”, Twoja odpowiedź byłaby warta +10.
Jim G.
25
  1. Kiedy kluczowi programiści odchodzą, a zarządzanie nie ma znaczenia

  2. Kiedy kluczowi programiści odejdą, a żadnego z pozostałych programistów nie obchodzi

Numer jeden zwykle wskazuje na menadżerów, którzy są w dużym stopniu pozbawieni kontaktu z dynamiką zespołu (kim jest „10-krotna supergwiazda”, którzy są przyzwoitymi programistami i jak współdziałają ze sobą itp.).

Numer dwa zwykle wskazuje na poważny brak zainteresowania ze strony pozostałych programistów.

MrDatabase
źródło
24

Gdy ktoś po raz pierwszy, zwykle kierownictwo, mówi „nie mamy czasu na…”

Zwykle poprzedzające coś, czego nie mamy czasu, na przykład przegląd dokumentacji lub kodu (które statystycznie znajdują i naprawiają więcej błędów niż cokolwiek innego, w tym wszelkie formy testowania)

Mawg
źródło
8
masz na to referencje? byłoby świetną amunicją do użycia ...
Alex Feinman
1
Nazwij to „pierwszą zasadą zarządzania oprogramowaniem przez
Mawga
1
@Alex Feinman: Kod IIRC Complete zawiera wiele odniesień do takich statystyk.
nikie
21

Pozwól klientowi, marketingowi lub zarządowi wybrać datę, a następnie spróbować wrócić do wyobrażonego harmonogramu

Mawg
źródło
dzięki. Na pewno pamiętaj, możesz mieć to szybko, tanio lub pracując ... wybierz dowolne dwa
Mawg
21

Gdy kierownictwo jest zbyt słabe, aby powiedzieć „nie” firmie.

Prowadzi to do nieprzekraczalnych terminów, co prowadzi do braku zaufania do działu IT, co prowadzi do tworzenia przez hakerów hakerów (tj. Dostępu do bazy danych uruchomionych na czyimś komputerze… gdzieś), co prowadzi do koszmaru dla IT, gdy „ system krytyczny ”należy migrować, co prowadzi do ...

czosnku Adolf
źródło
Nic nie sprawia, że ​​zakres pełzania jest gorszy niż „funkcje koncesyjne”, ponieważ premier spieprzył się, kiedy ustalił daty kamienia milowego.
Evan Plaice,
21

Pierwszym złym znakiem, jaki przychodzi mi do głowy, jest to, że kierownictwo nie chce przekazywać złych wiadomości w górę łańcucha lub do klienta w nadziei, że zniknie - tj. Zarządzanie poprzez pobożne życzenie. Nie mogę sobie wyobrazić, ile razy deweloperzy udowodnili, że nie mogą dotrzymać terminu przed upływem tygodni, a nawet miesięcy, a jednak nikt nie chce powiedzieć klientowi. Rzadko widuję klienta, który nie dotrzymałby terminu, gdy istnieje prawdziwy powód, aby wyjaśnić potrzebę z dużym wyprzedzeniem; Często widywałam wkurzonego klienta, gdy mówiła mu w dniu, że termin ten nie zostanie spełniony i że nie zostanie spełniony następnego dnia, ale dwa miesiące później. W tym momencie, słusznie mogę dodać, kwestionują twoje procesy - dlaczego nie wiedziałeś o tym wcześniej.

Kolejnym pewnym znakiem, że nadchodzi niepowodzenie, jest przydzielenie nowych programistów do najtrudniejszej, najbardziej skomplikowanej i najbardziej krytycznej części procesu, a nie osób, które już rozumieją obecny system. Nie oglądaj ich uważnie, aby zobaczyć, czy naprawdę dobrze wykonują pracę lub mają pytania (DUŻA DUŻA FLAGA, jeśli nie ma pytań). Nowi pracownicy muszą być monitorowani, dopóki nie dowiesz się, że naprawdę mają umiejętności, o których mówili. Wciąż pamiętam jedno bolesne lato na przerabianie pracy (już po upływie terminu, kiedy ją dostałem) nowego pracownika, który dostał krytyczny kawałek projektu i powiedział wszystkim, że wszystko jest w porządku przez miesiące, a potem zrezygnował bez powiadomienia tydzień po terminie i nic, co zrobił, nie było użyteczne.

Kolejnym pewnym znakiem niepowodzenia jest to, że programiści pracują nad częściami, które zależą od innych rzeczy, które zostaną wykonane w pierwszej kolejności, a te rzeczy nie są zrobione, a nawet się nie rozpoczęły. Jeśli kierownictwo nie może przypisać pracy we właściwej kolejności, zejdziesz na dół.

Oczywiście pełzanie funkcji bez przesuwania terminu za każdym razem jest jednym z najczęstszych znaków, że wszystko pójdzie źle. Dodajesz do mojej płyty 20 godzin pracy, termin zostaje przesunięty o 20 godzin. Jeśli tak się nie stanie, projekt się nie powiedzie, to gwarantowane.

HLGEM
źródło
Tak, wiadomości stają się coraz lepsze, gdy idzie w górę :)
Hans Westerbeek,
18

Pewnym znakiem, który widziałem w mojej karierze, jest to, że kierownictwo zaczyna mówić o zaangażowaniu większej liczby organów, aby nadrobić czas w harmonogramie. Tak naprawdę nigdy nie widziałem więcej ciał przy pomocy projektu.

Walter
źródło
6
Kiedyś miałem menedżera, który chciał wprowadzić koder front-end do projektu (właściwa decyzja), ale ponieważ ktoś inny w projekcie odszedł na długi czas, chciał znaleźć hit zapisany w umowie nowego faceta, którego nie wolno mu było zachorować.
Jon Hopkins,
1
@Jon - To smutne ... śmieszne, ale bardzo smutne!
Walter,
16

Kiedy menedżerowie nietechniczni zaczynają nalegać na podejmowanie decyzji technicznych, których nie są w żaden sposób kwalifikowani. Duża, duża czerwona flaga!

Grandmaster B.
źródło
16

Najbardziej oczywistym znakiem jest duża rotacja personelu. Kiedy wszyscy szukają nowej pracy, zapewne też powinieneś.

Innym bardzo oczywistym znakiem jest brak postępu. Jeśli minął rok i nie wydaje się, że jesteś bliżej celu, jesteś skazany. Dzieje się tak zwłaszcza, gdy wymagania zmieniają się szybciej, niż można je wdrożyć.

użytkownik 281377
źródło
1
Najwyższe obroty, jakie widziałem, dotyczyły dwóch projektów. Jeden był stabilnym projektem, który trwał, a drugi był znanym skazanym na upadek projektem w banku. Nigdy nie byłem tak szczęśliwy, że jestem bezrobotny jak ci dwaj.
David Thornley,
13

Znudzeni członkowie zespołu.

Ashalynd
źródło
11

Jesteś w 90% gotowy, dostawa jest w przyszłym tygodniu, ale jest w porządku, ponieważ pozostało ci tylko „testowanie”.

Scott Whitlock
źródło
2
Wydaje się to bardzo śmieszne, kiedy to mówisz. Stało się jednak dla mnie. W tym czasie nie było śmieszne.
+1000 dzieje się tam, gdzie cały czas pracuję T_T
Songo
1
To zabawne, że każdy harmonogram ma testy jako ostatni krok, jakby testowanie nie znalazło żadnych błędów. Jeśli nie, po co zawracać sobie głowę testowaniem?
JohnFx,
Nie martw się, „klient przetestuje to dla nas” :-(
Mawg,
10
  • Wszyscy są fizycznie i psychicznie wyczerpani
  • Klienci / użytkownicy są wyraźnie niezadowoleni z powodu terminów lub tego, co widzą
  • Oryginalnie piękny design jest teraz kompromitujący
  • Zrezygnowałeś z wysyłania kilku stosunkowo istotnych błędów, które naprawdę wolisz naprawić, ale nie będziesz w stanie tego zrobić
  • Pozostajesz dumny z tego, że wysyłasz, a nie z tego, co wysyłasz - bliżej mentalności ocalałego niż dumy zawodowej
  • Zespół boi się, że są pewne rzeczy, które nie działają i ignorują te sekcje i mają nadzieję na najlepsze, ponieważ boją się tego, co może tam być
  • Wszyscy są przekonani, że wykroczyli poza (i mają rację)
  • Ludzie wykazują oznaki wypalenia zawodowego (ogólny pesymizm, brak zainteresowania, gniew)

(Źródło: Dynamics of Software Development Jima McCarthy'ego ).

Jon Hopkins
źródło
+1 za „Pozostajesz dumny, a nie to, co wysyłasz”. To taka prawda (chociaż widziałem to tylko u moich menedżerów. My, programiści, wiedzieliśmy, co wychodzi za drzwi ... najpierw stopy)
10

Kowbojscy koderzy, wielkie ego i akceptacja zarządzania

Mawg
źródło
Co to jest kowbojski programista?
Creative Magic
Wikipedia jest twoim przyjacielem en.wikipedia.org/wiki/Cowboy_coding
Mawg
Nie wiedziałem, że to termin, dzięki! Welp, wracam do mojego rancho ...
Creative Magic
9

Jeśli plan projektu wymaga jednej iteracji projektu, rozwoju, testowania i wdrożenia - klasycznego wodospadu - dla projektu dłuższego niż 1 miesiąc, przebiegłbym milę.

Nie musisz być w pełni sprawny, ale krótkie cykle programowania pozwalają zademonstrować postęp wszystkim (klientom, kierownictwu i samym programistom) i poradzić sobie ze zmienionymi wymaganiami, gdy zajdzie nieuniknione.

ChrisF
źródło
6
Nie ma nic złego w wodospadzie, gdy jest prawidłowo używany. Niestety nigdy nie jest używany poprawnie :)
czosnek Adolf
@adolf - Myślałem o pojedynczym przejściu przez wodospad. Wiele mini wodospadów jest prawdopodobnie OK.
ChrisF
imo, Agile to tylko seria wodospadów. Bardzo niewielu potrafi poprawnie wykonać wodospad, ergo ..
Mawg 10.10
@mawg - miałem na myśli to, że pojedyncza długa iteracja jest zła, podczas gdy seria krótkich iteracji (jakkolwiek są one zarządzane) jest lepsza.
ChrisF
1
Przypomina mi projekt rozwijający elektroniczne rzeczy, w których nie ma żadnych prototypów zaplanowanych na ... Pewny znak zbliżającej się katastrofy.
szybko_now
9

Deweloperzy działający dziko w zakresie

Stało się tak, gdy zdajesz sobie sprawę, że inni programiści (lub, niestety, ty) opracowali komponent, który różni się znacznie od projektu, i że nie jest on wychwytywany aż do dokładnego przetestowania systemu / UAT. Nie mówię o błędach; Mówię o znaczących komponentach systemowych, które nie mają funkcji lub zostały zadeklarowane pod kątem funkcjonalności i nigdy nie przejdą UAT bez znacznej przeróbki. Ten problem wskazuje, że:

  • Twój system jakości jest zepsuty; dlaczego zainteresowany deweloper nie podniósł problemu na etapie projektowania / wdrażania. Czy kod nie był sprawdzany / sprawdzany? Dlaczego testy jednostkowe i integracyjne tego nie wykryły? Jeśli nie masz jakiegoś spójnego testu jednostkowego / integracyjnego, masz problemy.
  • Twój kierownik projektu / kierownik techniczny nie kontroluje swojego zespołu programistów. Jeśli nie będą w stanie zmusić programistów do dostarczenia wymaganego oprogramowania, nigdy nie będą w stanie dostarczyć kompletnego rozwiązania.
MagicAndi
źródło
8

Gdy kluczowy programista w projekcie nie wpisał żadnego kodu od tygodni i nadchodzi poważny kamień milowy.

Była to praca polegająca na kontraktowaniu, a bardziej zaawansowany programista i menedżer ds. Zarządzania zadaniami zdecydowali, że chcą połączyć siły w celu uzyskania większego cięcia, aby drugi programista trzymał 3 tygodnie krytycznego zakładnika kodu. W końcu zwolniliśmy niekompetentnego premiera (który spędził 6 miesięcy na zrujnowaniu projektu) i rozmawialiśmy z deweloperem.

Wystarczy powiedzieć, że reszta projektu była masochistycznym marszem śmierci, zamrożenie specyfikacji opóźniło się, klient otrzymał szereg funkcji koncesyjnych, aby zrekompensować okropne planowanie premiera, który opuścił projekt, a jakość projektu ucierpiała dookoła z tego powodu.

Premier miał nawet odwagę polecieć na CDR (Critical Design Review) tylko po to, by porzucić spotkanie z klientem i syczeć. Kiedy zażądał zwrotu kosztów podróży w ramach projektu, uprzejmie kazano mu się rozprawić ze sobą.

Potrafię łatwo zidentyfikować co najmniej 5 innych znalezionych tutaj odpowiedzi, które miały wpływ na ten projekt. Krótko mówiąc, nauczyłem się wielu trudnych lekcji na temat mojego pierwszego poważnego projektu kodowania.

Evan Plaice
źródło
8

Mój pierwszy znak był na jednym z nich, kiedy zapytali, ile godzin nadliczbowych każdy z nas zobowiązałby się na następne dziesięć tygodni i zaoferowali wynagrodzonym pracownikom premię za pracę, o której mowa w nadgodzinach w oparciu o sukces projektu i dotrzymanie terminów.

Inne główne znaki, które widziałem: Definicja wymagań przebiega zgodnie z harmonogramem i data zakończenia nie jest przenoszona. Byliśmy w tyle, zanim jeszcze zaczęliśmy. Poświęcili trochę czasu na projektowanie, więc zaczęliśmy od braku projektu bazy danych i projektu, ale spodziewaliśmy się terminowej dostawy, między innymi poprzez importowanie do tabel jeszcze nie zaprojektowanych i utworzonych.

Gdy przedmioty na ścieżce krytycznej są wykonywane jednocześnie zamiast w kolejności. (Jeśli muszę użyć narzędzia X, a programista A dopiero zaczyna go budować, opóźni to moje zadanie).

Gdy menedżerowie zatwierdzają kod w Święto Dziękczynienia.

Gdy zaczniesz otrzymywać wiadomości e-mail z datownikiem późniejszym niż 23:00 i wcześniejszym niż 6:00.

Kiedy każde pytanie dotyczące sposobu radzenia sobie z pewną złożonością napotyka tę samą odpowiedź: „Nie martw się o to jeszcze”.

Kiedy wciąż wprowadzają zmiany wymagań, dzień wcześniej przejdź do kontroli jakości lub rozpocznij transmisję na żywo.

Kiedy zaczniesz organizować codzienne spotkania, które zajmą kilka godzin, aby omówić brak postępów. Och, to dlatego, że cały dzień jestem na zebraniach. Codzienne 5 minutowe spotkanie w porządku, codzienne spotkanie, które trwa ponad godzinę, a nie w porządku.

Gdy zespół bazy danych i zespół aplikacji nie rozmawiają ze sobą.

Gdy klient nie może dostarczyć obiecanych informacji na czas. Zwłaszcza, gdy są to pliki importu danych i potrzebujesz tych danych w bazie danych, aby sprawdzić, jak działa kod.

Kiedy rozważasz zainstalowanie światła stopu poza biurem jakiegoś kierownika, abyś wiedział, czy bezpiecznie jest do niego podejść tego dnia.

HLGEM
źródło
2
Najważniejsze w pierwszym akapicie jest to, że jeśli kierownictwo to czyni, terminy są już prawdopodobnie skazane, a premie nieosiągalne.
David Thornley,
1
@David Thornley, tak to jest dokładnie to.
HLGEM,
6

Myślę, że generalnie łatwo jest dostrzec nieudany projekt, gdy zbliża się termin. Jak już powiedziałeś, pełzanie funkcji w połączeniu z ostatecznym terminem jest pewnym sposobem na zabicie projektu.

Kluczem jest jednak wcześniejsze wykrycie nieudanego projektu. Myślę, że jedynym prawdziwym „znakiem zagłady” w tym przypadku byłby kompletny brak definicji „kiedy skończymy”. O ile nie znamy tego z przesunięcia, jesteśmy skazani na niepowodzenie IMO.

Jaco Pretorius
źródło
1
aka „definicja ukończenia”, zgodnie z ustaleniami zarówno IT, jak i Biznesu
czosnek Adolf
6

Byłem na trzech marszach śmierci w ciągu ostatnich pięciu lat. Oto kilka rzeczy, które przyczyniły się do mojego przeczucia zbliżającego się losu.

  • Firma postanawia, że ​​młodsi programiści będą projektować i rozwijać nowe funkcje, i wyznacza droższych starszych programistów, aby naprawiali swoje błędy.
  • Firma zleca krytyczne komponenty oprogramowania firmom z trzeciego świata, które nie posiadają wymaganej wiedzy specjalistycznej w tej dziedzinie.
  • Cykle chrupnięcia są tak blisko siebie, że zdrowie ludzi się psuje.
  • Pigułki, którymi kieruje twój zespół, zabijają się do snu każdego wieczoru.
  • Klient wysyła zlecenia zmian szybciej niż można je analizować.
  • Powinieneś dostarczyć kilka lat pracy w ciągu kilku tygodni, ale kierownictwo nie chce zawiesić funkcji.
  • Dostawcy sprzętu najwyraźniej mają problemy z dostarczeniem sprawnego produktu zgodnie z harmonogramem, a decydenci w Twojej firmie nie rozważą żadnych alternatyw.
  • Prototypowi urządzeń potrzebują programiści, aby mieć szansę na spełnienie prawdopodobnie nierealistycznego harmonogramu. Są one odbierane i przekazywane kierownictwu, aby czuli się dobrze.
  • Tydzień pierwszy: „Cholera, kod jest błędny. Wszyscy przestali robić nowe funkcje i naprawiać błędy”. Tydzień drugi: „Cholera, nie dotrzymamy harmonogramu funkcji. Wszyscy przestają naprawiać błędy i piszą nowe funkcje”. Powtarzaj w nieskończoność.
  • Rozwój odbywa się w jednym kraju, a kontrola jakości odbywa się w innym kraju w połowie drogi na całym świecie, więc komunikacja w sprawie błędu w obie strony zawsze wymaga 24 godzin, a przynajmniej jedna z zaangażowanych osób omawia skomplikowane problemy techniczne w języku, w którym nie są biegli.
Bob Murphy
źródło
Dałbym ci milion za ten ostatni punkt.
HLGEM,
5

Dla mnie to wtedy, gdy osoby odpowiedzialne za zestaw funkcji (czyli menedżerowie, właściciele produktów, klienci ...) przestają się przejmować lub wydają się mieć beznadziejną opinię na temat swoich odpowiedzi. Pytania dotyczące funkcji spotykają się z apatią i zniechęceniem. Oczywiste jest, że stracili oni inwestycję lub zaufanie do projektu.

Stało się to dla mnie, gdy realizowałem projekt, w którym uderzyła „zmiana kierownictwa wyższego kierownictwa”. Zadawałem pytania o to, jak to powinno działać i nagle nikt nie miał prawdziwej opinii.

Niedługo potem projekt został anulowany, a cały piękny kod, który napisałem, został skasowany.

Vaccano
źródło
5

Kilka lat temu Paul Vick napisał znakomity post na temat projektów z czarną dziurą . Myślę, że wszystkie porady są istotne. (Edytowałem elementy i podsumowania na długość).

  • Absurdalnie wspaniałe cele . Jak „gruntownie zmień sposób, w jaki ludzie pracują z komputerami”.
  • Całkowicie nierealne terminy . Zazwyczaj dzieje się tak, ponieważ wierzą, że mogą przepisać oryginalną bazę kodu w znacznie, dużo krótszym czasie niż początkowo.
  • Nierealistyczne przekonania o zgodności . Podobnie jak wiara, możesz przepisać i zachować wszystkie małe dziwactwa bez dodatkowego wysiłku.
  • Zawsze „sześć miesięcy” od głównego terminu, który zdaje się nigdy nie nadchodzić . Lub, jeśli to nastąpi, na końcu projektu dodawany jest kolejny kamień milowy, aby to zrekompensować.
  • Musi zużywać ogromne ilości zasobów . Zwykle przez wyssanie krwi z jednego lub więcej uznanych produktów.
  • Zaangażuj się przy użyciu zupełnie nowej technologii, która nie została jeszcze udowodniona . W związku z tym mogą oni usunąć wszystkie problemy ze skalowalnością dzięki nowej technologii.
Chris Smith
źródło
4

Tłumaczę mentalnie: „Wszystko w porządku. Nie mamy się czym martwić”. do „Wszyscy jesteśmy pieprzeni” za każdym razem, gdy słyszę, jak kierownictwo to mówi. Zwykle słyszysz, jak menedżerowie rzucają go przypadkowo na niepowiązane spotkania („A tak przy okazji, wszystko idzie dobrze. Nie ma powodu się martwić!”), Ale to jeszcze większa czerwona flaga, aby spotkanie było specjalnie zwołane.

Muszę jeszcze usłyszeć, jak kierownik mówi coś podobnego i nie okazuje się, że to kłamstwo.

Jason Baker
źródło
Lolx! Tak prawdziwe; spotkanie „być może słyszałeś rumo (u) rs ...”).
Mawg
4

kilka punktów z martwego projektu, w którym uczestniczyłem:

  • Kierownictwo podwaja zespół, aby szybciej skończyć.
  • programiści zaczynają „chować” błędy, aby dotrzymać terminów, i chociaż jest to oczywiste, jest ignorowane podczas przeglądania kodu.
OKAN
źródło
3

Gdy kierownictwo ciągnie projekt w różnych kierunkach jednocześnie, a karetka pozostaje nieruchoma.

Byłem kiedyś zaangażowany w projekt zarządzany przez dwóch facetów. Albo ze sobą nie rozmawiali, albo każdy ma jakieś ego do rozwiązania, ale co tydzień dowodzili naszą pracą w przeciwnym kierunku. Nie trwało długo, zanim zdałem sobie sprawę, że nigdy nie będzie żadnych rezultatów. Cieszę się, że mój udział trwał tylko kilka miesięcy.


źródło
LOL, pracowałem nad badaniem siły roboczej w ten sposób, chociaż jeszcze gorzej, ponieważ obaj prowadzący próbowali mieć romans z tą samą kobietą. Jeśli Bill powiedział „tak”, to Bob powiedział „nie” i odwrotnie, najgorszy projekt, nad jakim kiedykolwiek pracowałem. Błagałem o przeniesienie.
HLGEM,
3

Zobacz ten zwięzły artykuł: Kiedy projekty IT idą w prawo .

Brak któregokolwiek z elementów wymienionych w artykule powinien ustawić dzwonienie dzwonków alarmowych:

Upewnij się więc, że Twój projekt ma wszystkie poniższe elementy, jeśli nie, powinieneś się martwić:

(zacytować powyższy artykuł :)

  1. „Po pierwsze, opierają się na jasnej wizji tego, co należy osiągnąć”.

  2. „Druga cecha dotyczy wsparcia i zaangażowania różnych stron zaangażowanych w działalność, w szczególności kierownictwa wyższego szczebla”.

  3. „Po trzecie, rozumienie problemów, które należy rozwiązać”.

  4. „Ostatnią wspólną cechą jest udostępnienie wystarczających zasobów i umiejętności.”

therobyouknow
źródło
Świetny artykuł! Lubię podejście „kiedy wszystko idzie dobrze”.
user8865
3

Statystycznie rozpoczęcie projektu oprogramowania jest uczciwym znakiem, że się nie powiedzie, ponieważ zdecydowana większość z nich ...

Nitsan Wakart
źródło
1
Myślę, że to statystyka początkowa, niekoniecznie ogólna statystyka projektu oprogramowania.
Erik Reppen
2
Oto jedno odniesienie losowo Googled, które wydaje się sugerować, że nie ogranicza się to do start-upów. Zobacz także doskonały Rapid Development pana McConnela, aby uzyskać dalsze klejnoty na ten temat.
Nitsan Wakart