Death March „Marsz śmierci”. Jeśli jesteś programistą to wcześniej, czy później spotkasz się z tą definicją.
Lepiej znać tylko definicję tego słowa, ale w tym biznesie czasem trafiają się genialne pomysły. Pomysły, które mogą utrwalić pozycję firmy na rynku, bądź uratować ją od np. bankructwa (czyli wszystko albo nic).
Istnieje tylko jeden problem, mianowicie stworzenie samego projektu i wdrożenie klienta do systemu wymaga to czasu, przynajmniej 7 miesięcy. Niestety, by wygrać z konkurencją, której jeszcze nie ma trzeba być pierwszym, bez względu na jakość stworzonego programu . Jest to pewna złota zasada marketingowa.
Jakby tego było mało, to jeszcze powód zakupu stworzonego systemu – np. ustawa prawna, wejdzie w życie za 2 miesiące. Czyli oprogramowanie ma być gotowe za 2 miesiące.
I tak w ten sposób, mały zespół 4-osobowy, w tym ja musieliśmy stworzyć projekt w ciągu 2 miesięcy, co w praktyce i tak wydłużyło się do trzech.
W międzyczasie specyfikacja systemu urosła wielokrotnie i zaczęły powstawać nierealne terminy funkcjonalności, które trzeba było zrobić na wczoraj.
Nierealne terminy. Praca po godzinach, w weekendy oraz w nocy. Niskie morale całego zespołu. Chwiejna nadzieja na sukces projektu. Brak obietnic zapłaty za nadgodziny (nie ma pieniędzy, dopóki projekt się nie skończy). A na koniec sukces albo porażka, które wykażą, czy te wszystkie poty i łzy miały sens.
Czy pod koniec tej ścieżki dostaniesz wyższe wynagrodzenie, czy tobie może już podziękują?
Czy w ogóle projekt się uda?.
Zwykle takie historię źle się kończą,e na szczęście u mnie było inaczej.
To jest właśnie, mniej więcej „marsz śmierci”. Teraz gdy jest już po fakcie inaczej na to patrzę.
Definitywnie to istnieją dwie strony „ marszu śmierci”. Ludzie zwykle znają tę gorszą.
Mam znajomych, którzy pracowali dla pewnych firm. Łatwo zatrudnić studenta, za nieduże pieniądze i wysysać z niego siły, po czym mu podziękować i wziąć następnego.
Marsz śmierci, to nie tylko egzamin dla programistów, to także egzamin dla zarządzających.
Jest to pewien test zaufania dla obydwu stron. Jeśli któraś ze stron nadużyje tego zaufania, to na pewno nikomu to nie wyjdzie na dobre. Plotki roznoszą się szybko. Na jednej z rozmów kwalifikacyjnych, nawet udało mi uzyskać potwierdzenie tej teorii, gdy powiedziałem pewnej firmie, dlaczego nie chcę u nich pracować. Powiedziano mi, że od roku stosują już inne praktyki ,ale grzechy firmy pozostawiły ślad. Nikt nie chce pracować w firmie, która ma złą opinię.
Jesteś programistą, to możesz wybierać miejsca pracy.
Możesz jednak zadać sobie pewne pytania.
Czy projekty firmowe zawsze są takie?
Każdy programista wcześniej, czy później będzie miał bagaż takiego doświadczenia.
Czy jest to dobra wiadomość?.
Aby zrozumieć co znaczy "wypalenie" najpierw trzeba poczuć coś takiego na własnej skórze. Mając takie doświadczenie łatwiej będzie ci wykazać, czy angaż w dany projekt w ogóle ma sens?.
Co jest życiową szansą, a co jest stratą twojego czasu i zdrowia. Pieniądze pieniędzmi i zaufanie zaufaniem, ale zawsze musi istnieć granica, której nie może nikt przekroczyć.
„Projekty śmierci” zawsze zaczynają się niewinnie.
Wygląda to więc jak gotowanie wody w garnku, która początkowo jest zimna. Nikt przecież do ciebie nie przyjdzie i nie powie ci, słuchaj mamy taki projekt, chcesz się przyłączyć do marszu śmierci.
Dzieje się to powoli, robi się coraz cieplej i cieplej. Będąc w takim garnku oczywiście wyskoczyłbyś z niego od razu, gdyby temperatura powodowała wrzenie wody, ale to zaczyna się to powoli.
Z naszym projektem było tak samo. Wymagań było tak mało, że racjonalnie projekt mógłby być zrobiony w 2 miesiące. Jednak specyfikacja projektu powstała w trakcie jego tworzenia. Trzy tygodnie później projekt urósł trzykrotnie.
Racjonalnie w takich chwilach większość osób mówi "do widzenia, to nie jest już mój problem". Mam w swojej skrzynce 10 innych ofert pracy.
Nawet być może i słusznie - świat nie jest piękny - istnieje wiele takich historii, które źle się kończą.
Po co, więc się angażować. Ufasz pracodawcy, że <kiedyś> ci zapłaci za nadgodziny? Jeśli firma to nie ty, to dlaczego niby miałby cię interesować jej los.
Możesz przyszedł czas, by pomyśleć o "sobie".Czy firma, po fakcie nie zastąpi cię kolejnym studentem? Czy jesteś niezastąpiony na tyle, by stawiać warunki, gdy projekt się skończy?
Powstaje więc pytanie.
Jako programista, dlaczego chciałbyś wziąć udział w tym przedsięwzięciu, w którym racjonalnie 90% osób spakowałaby swoje torby.
Jeśli chodzi o mnie, to przyznam się, że miałem przygotowane swoje CV (nie jestem idiotą) ale z drugiej strony wiedziałem, że to jest to, co chciałbym zrobić.
Na pewno wielki wpływ na moje zachowanie miał fakt, że jestem młody.
Nie mam jeszcze rodziny, o którą musiałbym się troszczyć.W tamtym momencie pomyślałem sobie: Muszę udowodnić sobie i światu, że jestem w stanie podołać takie sytuacji.
To jest ten moment, w którym po prostu nie da się uciec, bo sytuacja jest niewygodna.
Wiele osób, czy to w szkole, czy na studiach starało się mi wmówić, że jestem poniżej przeciętniej i raczej niczego ciekawego nie osiągnę.
Brzmi jak klasyczna motywacja. Większość menadżerów o tym wie, dlatego do takich projektów biorą młodych programistów. Co oznacza, że zawsze warto mieć plan "B" dla siebie. Łatwo popaść w łapy manipulacji psychologicznej.
Obietnice, obietnicami, ale nikt nie wie, czy to się uda i ty też powinieneś zawsze mieć ten cień wątpliwości.
Masz śmierci jest straszny. Jednak nagroda może być bardzo cenna.
W takich chwilach naprawdę poznajesz ludzi - jacy są. W takich chwilach poznajesz prawdziwą moralność etyczną swojej firmy. Kto wie, być może w takiej chwili łączysz się z innymi osobami, ponieważ macie wspólny cel, bo 70% czasu będziesz spędzał z nimi, 30% czasu będziesz spał.
Zaufanie do zespołu, z którym pracuję wzrosło. Gdyby nie to zaufanie, to nie wytrwałbym do końca. Możesz naprawdę udowodnić sobie i światu, że możesz więcej. Możesz dostać podwyższę bądź awansować.
Osobiście, po tym projekcie nauczyłem się lepiej zarządzać swoim czasem. Doświadczenie to zmieniło mnie. Chociaż blizny są. Sam nie mogę uwierzyć w to, że się udało, ale udało się.
Moja historia skończyła się dobrze. W innym przypadku zapewne bym o tym nie pisał.
Obietnice wydawały się bez pokrycia, ale zostały dotrzymane.
Uwaga na programistyczny Syndrom sztokholmskim
Nie napisałem jednak jeszcze o programistycznym "Syndromie sztokholmskim", który jest powiązany z projektem śmierci.
Syndrom sztokholmski polega na zakochaniu się we własnym oprawcy. Co w definicji oprogramowania znaczy to, że masz pracę, nienawidzisz jej, jest dla ciebie koszmarną torturą i wiesz, że jesteś w pułapce.
Po jakimś czasie uświadamiasz sobie, że jedyne odkupienie znajdziesz pomiędzy osobami, które zgotował ci ten los.
Żyjesz dla swoich menadżerów i żyjesz dla marszu. Wiesz, że umrzesz, ale mimo tego idziesz. Dlatego, dla swojego dobra, musisz to sobie uświadomić i mieć plan "B". To tylko praca.
Najważniejsze jest to, aby nie mieć pretensji do siebie.
Z punktu widzenia kariery. Odpowiedź na marsz śmierci zależy od sytuacji.
Czasami trzeba uciec, gdy praca szkodzi twojemu życiu (jeśli nie jesteś szczęśliwy, to dlaczego robisz to, co robisz) - czasami trzeba wziąć się w garść i złapać byka za rogi.
Czasami bierzesz trudny projekt, a po jego skończeniu bierzesz się za mniejszy z lepszym zapleczem.
Gdybyś miał dostać pracę w np. firmach : "Google", "Facebook", "Microsoft", to idź na ten marsz śmierci. Nawet dla samego kształtowania swojego charakteru. Jak dzieciak z "Karate Kid" będziesz lepszy i lepszy.
Wraz z doświadczeniem będziesz mógł łatwiej określić, czy dany projekt ma sens i czy dana firma nie robi cię „w konia”. Życie jest jak surfowanie. W wodzie istnieje dużo zmiennych - fala, wiatr. Nie da się wszystkiego przewidzieć.
Niektórzy lubią duże fale i chcą sobie coś udowodnić, inni wolą sprawdzać się w bezpieczniej wodzie, na niższych falach.
Jest ryzyko, istnieje też duża nagroda. Niektórzy po prostu czują, że muszą się sprawdzić na co ich stać. Lubisz zastrzyk adrenaliny.
Jeśli interesuje ciebie podobna tematyka polecam książkę Edward Yourdon “Death March”. W książce istnieje taki wykres, który pozwoli ci określić typ “marszu śmierci” jako menadżer i jako programista.
Oś “Y” pokazuje stan zadowolenia zespołu. Oś “X” pokazuje szanse sukcesu danego projektu. Jeśli zdarzy ci się spotkać z projektem śmierci mam nadzieje, że przynajmniej trafi ci się najlepszy typ “Mission Impossible”, w który zdrowy zespół daje z siebie wszystko naprzeciw przeciwnościom losu.
Mój marsz śmierci się skończył, ale potem czekała mnie walka z najgorszym bug-iem, jakiego spotkałem. O tym jednak w innym wpisie 
