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

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?

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.

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.

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.

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.

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.

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.

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)

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

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 ...

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.

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.

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!

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ć.

Znudzeni członkowie zespołu.

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

• 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 ).

Kowbojscy koderzy, wielkie ego i akceptacja zarządzania

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.”

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