Najgorszy ukończony projekt

Jaki był wasz najgorszy projekt, z którego nie odeszliście przed jego ukończeniem albo porzuceniem? Ten warunek tak specjalnie, bo projektów, które były powodem do ucieczki z firmy, może być sporo ;) . Chodzi mi o projekty, które były strasznym bagnem a mimo to wytrwaliście do końca albo kilka lat, jeśli był nieskończony (w sensie nieskończoności a nie wykonalności).

Podniesienie mikrokodow na maszynie AIX. Sprzęt od wielu lat nieaktualizowany, taki typowy blackbox w firmie. To zadanie padło na mnie, wtedy stazyste ;) Pamietam, ze bylo kilkanascie rzeczy do upgradu osobno, manualnie. Zbyt duzy upgrade jednej rzeczy powodowal brak widocznosci dla innego komponentu. Program do obslugi upgradow rowniez musial byc w kilku krokach upgreadowany; To bylo 10 lat temu, a jak dzisiaj pamiętam te presje ;\

Migracja całej firmy(domena, systemy, użytkownicy, serwery, sap, hostlisty, proxy, dostepy.. no wszystko). Praktycznie sam.

@PerlMonk:

Jaki był wasz najgorszy projekt, z którego nie odeszliście przed jego ukończeniem albo porzuceniem?

Własny... Ba dum tsss.

Raczej nie uciekałem od projektów - po paru latach w zawodzie nauczyłem się dryfować na każdym szambie - raczej od ludzi i firmy. No i oczywiście za kasą.

Taka pierwsza myśl - dla mnie najgorsze są projekty, które nie mają się skończyć. Zazwyczaj cele to wrzutki od wszystkich i zewsząd... Witamy w CI :)

A ukończony... jeśli można tak powiedzieć to duży portal do wizualizacji testów w Jenkinsach gdzieś na obrzeżach telekomunikacji. Kombajn napisany w Python/Django z dostawką do MongoDB i częścią rzeczy w PostgreSQL a na froncie JS, JQuery, Vue.JS, Mustache.Js... zależy komu się w czym w danym roku (projekt > 10 lat) pisało najlepiej. Generalnie, "odszedło" mi się stamtąd i uznaję za skończony :)

Moja inżynierka. Była do d**y, wstyd.

Projekt pobierający dużą liczbę danych z zewnętrznego źródła i udostępniający go na własnym endpoint'ie.

• Dev leadem był gość o niedodatnich umiejętnościach technicznych. Kazał nam przepisywać kod na statyczne stany, bo tak kiedyś robił w C++
• Każdy sprint to jedno wielkie kłamstwo, gdzie fałszowane były testy, żeby mr devlead nie zotał wy..... za brak postępów
• Mieliśmy architekta z taką siłą przebicia, że jak zabraknie dla niego miejsca w IT, to będzie mógł robić jako sztuczna pochwa. Poziom wiedzy taki, że postawiliśmy "mikroserwisy" skalowane pionowo instancjami VM'ek, bo o konteneryzacji nie słyszał. Wszystko się waliło, bo ani service discovery, adresy usług hardkodowane, parametry podobnie (tak, hasła też). Jak zaprojektował cache, to nie dość, że kosztowało to kilkadziesiąt tysięcy USD miesięcznie za redisa, to jeszcze wszystko działało wolniej, bo nie wpadł na to, że nie wiadomo kiedy go unieważniać, więc był invalidowany za każdym razem jak do niego sięgano.
• Test lead kąpany w Gangesie, traktował wszystkich testerów jak kłamców, żądając screen szotów jako "dowodów testów". Trochę to nawet rozumiem, bo skoro wyniki były fałszowane, to lepiej mieć jakąś podkładkę.
• Projekt nie miał absolutnie żadnego uzasadnienia biznesowego. Nie, że za głupi jestem, żeby je dostrzec, szukałem przez rok, nie znalazłem nic poza "trzeba dotrwać emerytury".
• Część ludzi zatrudnianych do projektu uciekała zanim IT dało im dostępy do repo, bo wszystko działo się absurdalnie woooooolno.
• Repo było... ale nie był to żaden ogólnie znany system kontroli wersji. Założenie nowego repozytorium trwało tydzień, bo był jeden korpo-specjalista, który musiał dogrzebać się do maila z prośbą.
• Częste, transatlantyckie rozmowy o niczym do późnego wieczora.
• Dodatkowy zespół programistów z SE Azji z poziomem angielskiego "- How are you? -Yes"

Osobisty sukces - nauczyłem się mieć wywalone. Od czasu tego projektu, naprawdę bardzo ciężko mnie zdenerwować. Skończyło się tym, że nasz zespół wycofano z projektu ze względu na brak umiejętności miękkich :D

Ale chodzi o projekt, który tworzyłem od początku do końca, a potem gdzieś zniknął?
Czy liczą się takie, do których dołączyłem w trakcie?
A takie, które ciągle żyją? No bo skoro wciąż coś jest w nich rozwijane, to nie są "ukończone".
Istnieje w ogóle coś takiego jak ukończony projekt?

"Art is never finished, only abandoned." [podobno Leonardo, ale też podobno apokryf]

Czy liczy się projekt, z którego nie zdążyłem uciec, bo firma mnie wprzedziła i wcześniej zbankrutowała?

Nie mogę za dużo napisać, bo da się wyśledzić. Miałem kiedyś bingo patologii:

• Pato scrum,
• (ale taki naprawdę totalne pato - cała udawana ceremonia,
• siedzone daily po 1.5 godziny dziennie,
• zadania i tak wyestymowane i wstawione w ms project na 6 miesiecy do przodu,
• w kolejności, która nie miała najmniejszego sensu z punktu widzenia architektury,
• zresztą typowe estymaty były na 2 - 4 godziny - w sytuacji, gdzie człowiek często przez cały dzień próbował sie dowiedzieć co w ogóle jest do zrobienia, jednokrotne testowanie ręczne gotowego komponentu zajmowało nieraz więcej czasu niż te szacunki na wykonanie,
• niemiecki architekt trzymający krytyczne częsci kodu w prywatnym repo (nie mieliśmy dostępu do źródeł, żeby hołota z Polski nie zadawała pytań) - to było mistrzostwo,
• mikro managier (tez z niemiec) - potrafiący 20 minut dopytywac się (publicznie opierdalać po prawdzie) programisty dlaczego zadanie wyestymowane na 2 godziny robił przez 4 godziny (przy 15tu osobach na zebraniu...,),
• cms w javie... ,
• gdzie aby poprawić style lub js, trzeba było skopiować CSS z repo i wrzucić na konkretne środowisko z użyciem toola zrobionego w Swingu (UI wyglądało po niemiecku, trzeba mieć było miske na rzygowiny zawsze w pogotowiu),
• jeden niemiecki architekt, mający dostęp do bazy (i mogący coś zmieniać w schemacie), kilkunastu Polaków w kolejce - próbujący wyprosić zmiany, aby mogli zrobić swoje zadania,
• krytyczne komponenty od firmy trzeciej, która miała tak skonstruowany kontrakt, że NIE OPŁACAŁO im się oddawać czegokolwiek w jakimkolwiek czasie,
• spring,
• praca na maszynach wirtualnych, w czasach kiedy to naprawdę była mordęga,
• nieprzekraczalny termin pójścia na produkcję, który od razu (day 0) wszyscy uznawali za niemożliwy do dotrzymania,
• specyfikacja (i estymacja) była zrobiona z założeniem, że robi to zespół, który robił pierwszą wersję systemu i wie co się dzieje, ten pierwszy zespół odwalił coś, po czym zostały zgliszcza i wypisał się z firmy (przypadek? nie sądze),
• dużo zadań wyestymowanych na 0 (nix zu tun) - w ramach zemsty za 1.IX.1939 udało mi się przesunąć wszystkie te zadania na niemiecki zespół - jedno z nich miało później zaraportowane 3 miesiące.
• testy testujące Mockito,

To ja powiem od siebie o pewnym projekcie, w ktorym mialem "przyjemnosc" uczestniczyc.

Pseudo scrum - daily, planning, grooming, retrospective, sprint review, release preparation, release planning, release. Połowe czasu zajmuja w/w meetingi bezuzyteczne, realna praca to moze 8h w ciagu 2 tyg sprintu. Należy tutaj wspomniec fakt, że meetingi prowadzone w sposób chaotyczny, Architekt, PM i biznes analityk przekrzykują sie czesto ze soba wzajemnie odbiegajac czesto od glownych watkow).

Pomijajac żałosny stack technologiczny projektu to najbardziej irytująca rzecz to biznes analityk rozpisujacy taski biznesowo nie majacy zielonego pojecia jak dziala aplikacja i co w danym tasku trzeba zrobic. Taski rozpisane na 5 stron w Jirze tak ze jak sie to czyta robi sie nie dobrze a zarazem ciezko i jednoznacznie zrozumiec o co chodzi. Po zrozumieniu co typ chcial przekazac mozna dostrzec przynajmniej 5 bledow logicznych w opisie wymagan taska - rzeczy sprzecznych samych ze sobą. Taski na groomingu maja byc estymowane przez developerow na podstawie 2 minutowego spojrzenia w wypociny typa ktore napisał, bo typo nie wie czy to jest task backendowy czy frontendowy. Nieraz bywa tak ze typ sam nie do konca rozumie co napisal i co chce osiagnac a jak zadaje sie konkretne pytanie o dany use case to zaczyna sie mieszac. No ale najwazniejsze to zeby jira sie zgadzała i wyestymowac task, w ktorym tak naprawde nie wiadomo o co chodzi.

Architekt teoretycznie jest ale zamiast rozpisac taski zajmuje się łataniem syfu ktory w ostatnim release zepsuł produkcję (tak wlasnie w swietnie zaplanowanym release, w ktorym defakto nikt nie dba o zaleznosci i impakt wzajemny taskow na aplikacje, zero jakichkolwiek testow regresji, trzymania wersji srodowiska specific per dany rilis, wszystko pchane na test a potem wyrywkowo na produkcje w/g widzimisie PMa a potem wychodza kwiatki).

Drugi biznes analityk ktory ma lepsze pojecie techniczne jak ten pierwszy ale slabiutkie jakims cudem uzyskal wyzsze dostepy do bazy produkcyjnej i testowej i robi raz na jakis czas "manual adjustmenty"....

Oczywiscie nie ma dnia zeby cos sie nie wysypało na produkcji itd...

Zostałem zatrudniony jako programista Java (pierwsza praca) i w pierwszym miesiącu rzeźbiłem w ASP/IIS/MSSQL (pewnie pracodawca chciał sprawdzić jak radzę sobie w sytuacjach beznadziejnych i czy jestem wytrwały). Jako świeżak popełniłem masę błędów i przed upływem pierwszego miesiąca myślałem o rzuceniu roboty. Projekt dowiozłem.

Java przewinęła się w projekcie (wersja 1.1 i klasy rejestrowane jako obiekty COM, które były z tego ASP wołane...) Dla juniora to był majstersztyk architektoniczny i byłem zachwycony jak to ktoś połączył.

Nigdy nie zrezygnowałbym z realizacji podjętego zadania tylko dlatego, że "projekt mi się nie podoba", jest źle napisany itp... Moim zdaniem to dziecinne i niepoważne podejście do pracy. Czasem wdepnie się w g...o ale trzeba umieć się z tego wygrzebać a nie uciekać, a najlepiej nauczyć się pracować tak aby za g...o się nie łapać.

yarel napisał(a):

Zostałem zatrudniony jako programista Java (pierwsza praca) i w pierwszym miesiącu rzeźbiłem w ASP/IIS/MSSQL

Ja kiedyś zostałem zatrudniony jako programista Java (miałem doświadczenie tylko w C++) a wylądowałem w projekcie, w którym był tylko Oracle i jego narzędzia pochodne. Czasy były ciężkie (kryzys 2008) to spędziłem tam 3 lata. Plus był taki, że poznałem masę fajnych ludzi.

Taki o którym nie mogę mówić bez prawnika. Na szczęście pierwsza instancja wygrana, a druga podobno miało być ale nic nie widać na horyzoncie.

Nigdy nie uczestniczyłem w projekcie który miał się skończyć. W programowaniu raczej soft jest ciągle utrzymywany / rozwijany. Gdy przestaje być rozwijany to jest uważany za porzucony i szybko staje się przestarzały i zastąpiony przez coś nowego. Sam omijam szerokim łukiem biblioteki/projekty które na githubie mają ostatni commit 3 lata temu, albo programy które mają "copyright 2008-2013" w stopce. Nawet gry mające po 10 lat nadal otrzymują aktualizacje jeśli ktoś w nie gra.
Więc nie za bardzo pojmuję pytanie jaki projekt może się skończyć - chodzi o jakieś proste strony wizytówki dla kogoś?

Mi się zdarzyło uczestniczyć w migracji COBOL -> Java. Pliki w COBOL'u po 500-800 tysięcy linijek, klient sam nie wiedział jak działa ten system, więc jedynym wymaganiem było: "ma działać tak samo jak stary", całą analize biznesową trzeba było sobie zreversować z kodu. Przez prawie pierwsze pół roku nie mieliśmy dostępu do środowiska, na którym można byłoby porównać output nowej i starej apki (bo klient nie za bardzo mógł udostępnić środowisko dev), więc 20~ programistów klepało pół roku na ślepo, w nadziei że jakoś to będzie; no i jakoś to było. Po otrzymaniu środowiska, okazało się, że pomyliliśmy się w swoich założeniach o kolejne pół roku pracy dla tej samej liczby osób.

A jeszcze bym zapomniał, że kod COBOL'a został wygenerowany przez jakiś plugin IBM'u więc procedury, zmienne czy stałe nazywały się mniej więcej tak: HDBC-00012-L13SFA-HHDEW-LES321-DDWA

Generalnie mimo wszystko miło wspominam, kupa śmiechu i powstały przy okazji ciekawe narzędzia do parsowania COBOL'a : D

Wszystkie, które ukończyłem były dobre, a ten którego nie ukończyłem i był najgorszy to projekt nie dość, że legacy to jeszcze chłop sobie wymyślił wszystko nadziergać xmlami, generatorami kodu i generatorami xmli.
Do dziś się zastanawiam czy serio tak jest łatwiej utrzymać potem taki legacy projekt czy może gość robił to po to by firma potem nie była w stanie znaleźć nikogo na jego miejsce.

Chyba gdzieś pisałem, ale najgorsze projekty to takie gdzie miałem to co napisałem poniżej

• sprawdzanie ile linii kodu napisałem, a następnie sprawdzanie ile relatywnie do tego zalogowałem czasu na tasku
• logowanie wszystkich czynności z dokładnością do do każdej minuty, np jak rozmawiałem 15 minut z kolegą to miałem to zalogować
• jeżeli zrobiłem jakąś zmianę i przez nią wysypało się to leciały kur... w moim kierunku że przeze mnie ktoś jest zablokowany
• zastraszanie nadgodzinami w przypadku niewyrobienia się
• zastraszanie nadgodzinami w przypadku gdy przez moją zmianę coś się wysypie na devie
• mikromanagement, manager sam do mnie pisał i pospieszał kiedy coś zrobię i tak dalej, przez co się stresowałem że robiłem jeszcze dłużej xD
• projekt w którym byłem ja i jeszcze jeden programista, czyli dwóch devow, a nad nami był jakiś Senior Uber Architect który nic nie robił, Senior Master Manager który nas poganiał, Senior Scrum master który tylko pytał jak idą nam taski, do tego biznes analityk i jeszcze jakoś jeden manager. Wyszło z tego że oni nic nie robili tylko uprawiali korpo-mowe a my we dwójkę mało co się wyrabialismy ze wszystkim
• praca w zespole gdzie byli studenci oraz absolwenci informatyki, którzy nieszanowali swojego czasu i robili darmowe nadgodziny, bo myśleli że mało umieja, przez co normy w projekcie były większe niż robią niektórzy Polscy za granicą

Wspólny mianownik wszystkich tych projektow to długie daily i inne spotkania.
Najgorsze jest, ze jak powiesz:
No, może róbmy to krócej i rzadziej, może dajmy ludziom pracować i niech komunikują się miedzy sobą gdy maja problem?
To odpowiedz PM jest w stylu „Po to są Daily, żebyś wiedział co masz robić i byśmy znali status zadania”

Wiec codziennie niczym 1.5h msza z rana trzeba tracić czas i słuchać co inne 10 osób będzie dziś robić.