Crunch w pigułce

Każda branża zawodowa ma swoje cienie i blaski. Przy jednej działalności cienie dominują w postrzeganiu tematu przez postronnego obserwatora (na przykład polityka), przy innej wprost przeciwnie – blaski tak oślepiają, że postronny obserwator o cieniach dowiaduje się dopiero w momentach prasowego skandalu. Branża gier wideo należy zdecydowanie do tej ostatniej kategorii.

Praca w gamedevie dla zupełnego laika lub niedoświadczonej zawodowo osoby (dziecko, młodzież) wydaje się nieprzerwanym ciągiem grania w gry. Człowiek bardziej dojrzały emocjonalnie i życiowo wie, że w czasie tworzenia gier nie może być tak, że wszyscy cały czas grają, bo kto wtedy ten produkt by tworzył, rozwijał i nieprzerwanie testował. Jest to bardziej racjonalne podejście. Nie zmienia jednak to faktu, że i tak większość osób przeciera oczy ze zdumienia, gdy okazuje się, że w procesie powstawania gry miały miejsce permanentne nadgodziny. Postronni widzowie nie mogą zrozumieć, dlaczego ludzie wyzywają się od najgorszych i pragną dochodzić sprawiedliwości w sądach. I dlaczego w post mortem projektu nie pojawia się świat z bajek i snów, a panorama z koszmarów lub co najmniej z mało wesołej rzeczywistości.

Takie przecieranie oczu ze zdumienia przez graczy odbywa się cyklicznie. Ostatnią głośną aferą w tym temacie był konflikt wokół powstawania „L.A. Noire” i współpracy między Team Bondie i Rockstar. Inny słynny skandal związany był z blogiem EA Spouse prowadzonym przez pracownika Electronic Arts Erin Hoffman, który doprowadził nawet do powstania organizacji GameWatch. Jednak afery aferami, częściej czy rzadziej mają miejsce w każdej branży i przy każdej działalności. Lepiej zastanowić się, czy nadgodziny są czymś częstym w branży gier, czym są spowodowane, jakie mają konsekwencje i jakie są jej ekstremalne postacie (bardziej w formie przerażającej ciekawostki niż analizy zjawiska).

 

Zrozumieć crunch

Zacznijmy od definicji. Crunch time, czyli pojęcie pracy w nadgodzinach w celu nadrobienia zaległości lub rozwiązania różnych problemów w kluczowym momencie powstawania projektu, nie jest absolutnie związany tylko z grami, ale etymologicznie pochodzi i obowiązuje głównie w światku gier. Można pracować wiele lat przy programowaniu czy projektowaniu systemów informatycznych i się z nim nie spotkać. Tam, jak i w wielu innych dziedzinach zawodowych, pojawiają się po prostu swojskie nadgodziny (czy angielski odpowiednik overtime) albo bliskie skojarzeniowo: deadline, milestone, release etc. etc. Dla uproszczenia jednak pozostańmy przy dźwięcznym crunch.

Żeby zrozumieć powody, dla których crunch jest zjawiskiem praktycznie nie do wyeliminowania, należy zrozumieć samo pojęcie projektu informatycznego. Gra wideo jest bez wątpienia podtypem projektu informatycznego, choć bardzo specyficznym i wyjątkowym. Zacznijmy od tego, że informatyczne środowiska akademickie bardzo lubią posługiwać się pojęciami zaczerpniętymi z inżynierii jako takiej, typu: inżynieria oprogramowania, architektura, wzorce projektowe, wytwórstwo oprogramowania i mnóstwo innych. W ogólności są to bardzo ważne zagadnienia i metodologie pracy, ale ich powiązania z prawdziwą inżynierią są miejscami złudne. Pobawmy się w przykłady: budownictwo domów czy dróg. Jeżeli nie wchodzą w grę patologiczne zjawiska typu kradzież materiałów (vide budowa autostrad na Euro 2012), są to inżynieryjne projekty, które dość ściśle można zaplanować, zaprojektować i precyzyjnie wykonać. Jeżeli są pracownicy, są plany, środki i harmonogram, to projekty takie mają małą szansę się nie udać. Co więcej, do pewnego stopnia można je elastycznie modyfikować i stosować w najróżniejszych miejscach, dzięki czemu powstaną drogi w różnych częściach kraju albo osiedla budynków jednorodzinnych w różnych zakątkach miasta. Na tym polega piękno inżynierii i nauk ścisłych. Niestety z projektami informatycznymi nie jest już tak przyjemnie.

Problem pojawia się głównie dlatego, że projekt informatyczny w większości przypadków przekracza wszelkie akceptowalne dla człowieka stopnie złożoności. Nie ma co zagłębiać się w teorię układów złożonych czy teorii chaosu, ale po prostu trzeba wiedzieć, że w systemach złożonych (a takim jest projekt informatyczny) zmiana w jednym miejscu może wygenerować niezliczone zmiany w miejscach skrajnie odległych, co więcej zmiany  nieprzewidywalne. Projektanci i programiści znają dzisiaj setki sposobów, żeby ograniczać skalę takiego zjawiska, ale wyeliminować go zupełnie się po prostu nie da. Stąd jest duża szansa, że ratując w pewnym momencie harmonogram projektu trzeba będzie posiedzieć w nadgodzinach, aby coś poprawić czy zmodyfikować.

Dla przeciętnego człowieka związanego w jakiś sposób z projektami informatycznymi jest to po prostu prawda zawodowa, którą trzeba zaakceptować. Nie dostanie się na tego rodzaju stanowisko ktoś, kto na rozmowie kwalifikacyjnej będzie twardo obstawał, że pracuje tylko 8 godzin i ani minuty dłużej. Tym samym okazjonalny crunch jest tolerowany przez przeważającą większość osób. Życie jednak nie cierpi monotonii i prostoty, tak więc i crunch niejedno ma imię. W pewnym momencie pojawia się w takiej postaci, że przestaje obowiązywać jakakolwiek tolerancja.

 

Poczuć crunch

Gra wideo jest projektem informatycznym, ale wchodzącym na jeszcze wyższy stopień złożoności. W odróżnieniu na przykład od oprogramowania do wspomagania księgowości (nic nie umniejszając tego rodzaju projektom), w proces powstawania gry nie wchodzi wyłącznie programowanie i projektowanie (zresztą bardzo zaawansowane), ale też tworzenie oprawy audiowizualnej, animacji i efektów specjalnych. A żeby jeszcze wszystko miało ręce i nogi, trzeba to skoordynować z równie ważnymi zagadnieniami, jak game design, level design, marketing i wieloma innymi. Tym samym prawdopodobieństwo występowania cruncha (i jego częstości) zaczyna jeszcze bardziej rosnąć w odróżnieniu od przeciętnego projektu informatycznego. Scenariuszy, które trzeba przetestować i które mogą wygenerować zaskakujące problemy, jest znacznie więcej niż w przypadku programu wspierającego księgowość.

Ale przechodząc do meritum tego rozdziału – jak działa crunch? Wiadomo, że jest tolerowany w swojej podstawowej formie i ludzie, którzy podejmują się pracy w grach wideo mają świadomość, że mogą spotkać go tu częściej niż zwykle. Stąd na początku crunch jest paradoksalnie bardzo przyjemnym doświadczeniem. Ludzie wiedzą, że podejmują walkę z czasem i swoimi słabościami. Przeszkody stają się wyzwaniami, a możliwość ich pokonania wydaje się bardzo ekscytująca. Jeżeli crunch będzie trwał dni albo tygodnie, to często pozostaje wręcz miłym wspomnieniem, które pojawia się w wielu późniejszych anegdotach przy piwie. Ludzie czują, że razem stanęli na wysokości zadania i sprawnie uporali się z niespodziewanymi problemami.

Crunch działa więc na podobnej zasadzie jak przypływ adrenaliny w niebezpiecznych sytuacjach. Cały organizm mobilizuje się tylko do jednego – rozwiązania problemów projektowych, wszystkie zmysły są pobudzone i nadproduktywne. Oszukany umysł człowieka czerpie nawet z tego specyficzną przyjemność i ogarnia go świadomość, że jest nadnaturalnie potężny. Ale co dzieje się, gdy zostanie przekroczona magiczna, ciężka do ustalenia granica? Mamy do czynienia ze ścisłym sprzężeniem zwrotnym. Cały jeszcze przed chwilą przyśpieszony organizm odczuwa wszechogarniające i nieprzerwane wyczerpanie.

Miesiące cruncha (nie mówiąc już o tych absurdalnych crunchach liczonych w latach – które pojawiają się w kontekście wspomnianych na początku afer) są druzgocące dla relacji występujących między osobami zaangażowanymi w projekt. Ludzie warczą na siebie o byle co, wszyscy są zdenerwowani i podminowani, relacje podwładny – przełożony z sympatii czy neutralności szybko przeradzają się w czystą nienawiść. Zmęczony organizm, który pracuje po kilkanaście godzin dziennie, często bez weekendów, zamienia efektywne tworzenie na wbijanie gwoździ, aby ordynarnie działało. Projekt gry wideo złożonością różni się poważnie od położenia płyt chodnikowych, i wykonywany bez odpowiedniej koncentracji jest szalenie błędogenny. Nigdy nie dostarczy wtedy rozwiązań, które można wykorzystać w przyszłości. Cały projekt potrafi wtedy przypominać uszkodzoną tamę, gdzie zasłaniamy szmatą jedną dziurę, a w tym samym czasie, w innym miejscu tworzy się następny otwór i wystrzeliwuje kolejny strumień wody.

 

Wykorzystany przez crunch

W swej zwykłej, okazjonalnej i nieprzesadnie długiej postaci crunch jest tolerowany przez pracowników niższego szczebla, z przyczyn, które zostały wymienione wcześniej. Czasami jednak pracodawcy i pracownicy wyższego szczebla posługują się tymi oczywistymi dla wszystkich powodami, aby ukryć drugie dno. Nie wynikające z samej złożoności projektu jako takiego, ale aby zrealizować polityczne albo biznesowe założenia.

Jednym z typowych przypadków jest podejmowanie się projektów, które nie mają najmniejszych szans zostać zrealizowane na czas (częste zachowanie w megakorporacjach, aby zaimponować szefom, awansować, mieć cokolwiek do roboty i  z wielu innych, mało racjonalnych, ale politycznych powodów). Wtedy crunch jest wpisany (domyślnie, niejawnie) w harmonogram projektu. Jest to z góry skazana na problemy ścieżka, bo wiadomo, że pojawi się też zwykły, normalny crunch. Czyli crunche się spotęgują, będą dłuższe, częstsze i jeszcze bardziej druzgocące dla całego projektu oraz relacji pracownik – pracodawca.

Inny, jeszcze bardziej negatywny crunch to crunch, który jest sposobem na prowadzenie biznesu (kiedyś w światku gier wideo częsta strategia). Zatrudnia się najczęściej jedną, dwie bardzo doświadczone osoby plus mnóstwo młodych osób, często studentów, nieobytych zawodowo, wolnych jeżeli chodzi o stan cywilny. Dzięki czemu ma się kadrę może mało doświadczoną, ale z której można wyciskać ósme poty. Nie stworzą nigdy nic trwałego (choć czasami znajdują się tam osoby utalentowane i które opanowały bardzo dobrze dany warsztat), ale też specyfika danego projektu nie jest zbyt wymagająca. Trzeba po prostu wydać cokolwiek co pewien czas i musi działać jako tako. Oczywiście nawet ci niedoświadczeni pracownicy, przemęczeni i psychicznie wyczerpani w końcu zwalniają się, ale wtedy zatrudnia się następnych dziewiczo nieuświadomionych i tani biznes może się nawet kręcić całkiem długo.

Warto też dodać, że cały czas poruszamy się w kategoriach nadgodzin, za które nikt nie płaci. Niektóre megakorporacje potrafią częstować permanentnym crunchem, ale dostarczając też marchewki, czyli płacą (wcześniej czy później) za wszystkie nadgodziny (obok premii). To jest trochę inny przypadek, bo są osoby, którzy z tego czerpią zysk i pracę w nadgodzinach przyjmują z zadowoleniem. Pozwala im wygenerować roczną drugą pensję (obok premii), co ich jak najbardziej satysfakcjonuje. Natomiast wykorzystywanie w skrajnej postaci pojawia się, gdy pracownik nie otrzymuje wynagrodzenia za nadgodziny i nie dostrzega problemu (jest młody, naiwny, zapalony i entuzjastycznie nastawiony do projektu albo zapewniony – bardzo często stosowana metoda – że nadgodzinny zostaną oddane w formie bardzo obfitej premii, co oczywiście rzadko ma miejsce). Dość istotne jest, że część pracodawców wykorzystuje pojęcie cruncha do zupełnie nieetycznych praktyk (czy nawet mocniej – nielegalnych), aby zrealizować projekt, płacąc pracownikom równowartość połowy lub ćwierci pensji w stosunku do tego, co zrobili.

 

Zgwałcony przez crunch

Bywają też ekstremalne postacie cruncha, które przekraczają już wszystkie możliwe granice. Najczęściej występują w przypadku azjatyckich firm (japońskich czy koreańskich), gdzie na czysto zawodową płaszczyznę nakłada się płaszczyzna specyficznej kultury i wychowania. Ludzie pracują w systemie kilkunastogodzinnym i weekendowym przez wiele lat, a czasami nawet całe swoje zawodowe życie. W tym przypadku dochodzi do całkowitego odwrócenia proporcji – crunch staje się normalnym trybem, a normalny tryb crunchem (czyli normalny tryb występuje tylko sporadycznie). Wszystkie projekty są zawsze w niedoczasie i tak planowane, aby nie dało się ich stworzyć w zwykłym trybie. Ludzie wykorzystują każdą okazję do snu, śpiąc w toaletach czy przy biurkach. Czasami mają zamontowane przy biurkach łóżka, aby nie trzeba było w ogóle odwiedzać swoich mieszkań.

A że ludzka wyobraźnia nie ma granic, są i inne pomysły, aby wycisnąć z człowieka 500% normy. Azjatycka myśl organizacyjna wymyśliła tzw. VIP roomy. Zamyka się kilka osób w małym mieszkanku na tzw. krytyczny etap projektu, najczęściej kilka miesięcy. Na miejscu mają wszystko, co potrzeba do egzystencji – toaletę, lodówkę z dowożonym jedzeniem, łóżka i przede wszystkim sprzęt do pracy. Realizacje ściśle kontroluje się za pomocą Internetu i dodatkowego oprogramowania. Jest to nic innego jak praca na galerach, tylko że w XXI wieku.

 

Zaakceptować crunch

Obiektywnie rzecz biorąc, crunch w grach wideo był, jest i będzie. Skala i częstotliwość zjawiska zależy jednak od mnóstwa czynników, w skład których wchodzą zarówno nieprzewidywalne sytuacje, jak i działania zaplanowane w wyrachowany sposób. Pracownik częstokroć będzie skalę zjawiska powiększał, pracodawca przeważnie trywializował i zręcznie omijał temat. Ich cele bowiem nie zawsze bywają zbieżne. Nie pozostawia złudzeń i nie podlega dyskusji jedynie to, że każdy crunch, który naśladuje w zawoalowany sposób system pracy niewolniczej, powinien spotykać się z aktywnym sprzeciwem i krytyką. Jego efektem ubocznym jest zawsze degeneracja projektu i uszkodzenie delikatnej tkanki relacji pracownik – pracodawca.

20 odpowiedzi do “Crunch w pigułce

  1. Bartłomiej Nagórski

    Nie zgadzam się. Projekty software’owe to takie same projekty inżynieryjne jak i inne wymienione w tekście i stosują się do nich takie same zasady. Czasem wyskakują rzeczy nieprzewidziane (przy budowach również, zdziwiłby się autor), czasem nie. Tworzenie gier wcale nie jest tu jakimś nie wiadomo jakim wyjątkiem.

    Złe zarządzanie ryzykiem i kiepska estymacja czasu zadań projektowych powodują, że wymusza się potem crunch na deweloperach – niemniej jednak jest to pochodna złego kierowania projektem. Przykro mi słyszeć, że deweloperzy z branży, jak widać po autorze, dali sobie wmówić, że crunch jest absolutnie nieodzowną składową procesu powstawania oprogramowania. Nie jest.

    Sam jestem PMem dla dwóch zespołów tworzących software, a przy projektach związanych z programowaniem pracuję od około sześciu lat. Bywały momenty, że trzeba było coś na szybko załatać lub poprawić, ale to były okresy liczone w dniach/godzinach i dotyczyły oprogramowania produkcyjnego (miałem szczęście do PMów i managerów, sam też bardzo staram się nie dopuścić do żyłowania zespołu).

    W dobrze kierowanych zespołach zjawisko crunchu można bardzo ograniczyć, a w formie opisywanej przez autora oraz znajomych z branży growej – jest on patologią. I dobrze by było, gdyby świadomość tego była, zwłaszcza u nas w Polsce, większa, a temu niestety nie sprzyjają artykuły, które autorytatywnie twierdzą, że „Obiektywnie rzecz biorąc, crunch w grach wideo był, jest i będzie.

    Odpowiedz
  2. Otton Laskowski

    Też się nie zgadzam. Tekst nie jest świetny – jest tendencyjny. Owszem pokazuje „czarne strony” crunchu ale autor też opisuje jak to fajnie przy piwie opowiadać jak to „razem przezwyciężyliśmy trudne chwile”, jak to crunch może być przyjemny, jednocześnie pisząc, że cruch to jest wtedy jak pracodawca nam nie płaci za nadgodziny czyli nas po prostu wykorzystuje. No to ja przepraszam – dla mnie to pachnie promowaniem braku szacunku dla własnej pracy i w ogóle dla siebie.

    Pracuje w gamedevie od dawna i zawsze uważałem crunch za efekt problemów z zarządzaniem lub jak autor wspomniał zbyt ambitnie podpisanych kontraktów (brak doświadczenia tu jest winą a nie chęć zysku) lub nawet odgórnych założeń biznesowych danej firmy (a to już czysty wyzysk). Ale to NIE PRAWDA, że crunch jest zawsze i że musi być. Myślę że w dużej mierze jest to jest też kwestia dojrzałości zespołów developerskich i w ogóle dojrzałości branży. To naprawdę da się ocenić czy coś się da wykonać w założonym terminie, tylko zarządzać zespołem musi ktoś kto umie to zrobić i ktoś kto umie powiedzieć „nie” pomysłom designerskim typu „to doróbmy tutaj jeszcze takie ukryte przejście to kolejnej lokacji – będzie fajniej” albo powiedzieć „nie” wydawcy jak ten każe przyspieszyć produkcję albo powiedzieć „nie” na samym początku jak ma wziąć w swoje ręce projekt który nie ma szansy realizacji w terminie. Na szczęście tacy ludzie są – wystarczy pracować z nimi i już… pozbyliśmy się crunchy ;)

    Co do autorytarnych stwierdzeń to tu jest jeszcze jedno z którym nie mogę się zgodzić:
    „Nie dostanie się na tego rodzaju stanowisko ktoś, kto na rozmowie kwalifikacyjnej będzie twardo obstawał, że pracuje tylko 8 godzin i ani minuty dłużej”. Ja powiem tak – lubię swoją pracę i dlatego pracuje w tej branży i pewnie w każdej innej branży jest tak samo – jak inżynier projektuje most to też mu się pewnie śni on po nocach. Trudno zatem mówić o tym, że pracuje się tylko przez 8 godzin jak ktoś lubi swoją pracę. Ale jak pracodawca zakłada że pracownicy będą pracować dłużej niż normalnie powinni to nic dziwnego że potem wychodzi „crunch time”. Skoro takie jest podejście pracodawcy na samym początku to jasne że pod koniec projektu nie będzie fajnie…. A jak ktoś jest świetnym specjalistą ale może pracować tylko 6 godzin to co nie warto go przyjąć zamiast takiego który posiedzi w pracy godzin 12 ale przepracuje efektywnie 4?

    Odpowiedz
  3. mrrruczit

    Wnioski wnioskami, ale fakty faktami – crunch jest obecny, możliwe że nawet zakorzeniony. Jeśli nie wszędzie – super, ale dobrze by było, żeby „młoda przyszłość narodu” miała świadomość, jak to może (i prawdopodobnie będzie) wyglądać jak się załapią na tą świetlaną, gejdevovą przyszłość.
    A opisy crunchu jako fajnej, motywującej w pewnym sensie rzeczy i tematu do śmiechów w barze jest (w moim przypadku przynajmniej) jak najbardziej prawdziwe. Można by jeszcze dopisać o pizzy na koszt pracodawcy (napoje energetyczne rozwalające organy wewnętrzne we własnym zakresie) i konieczności ruszania się po pracy żeby w miesiąc nie przytyć 20 kg ;)

    Odpowiedz
    1. Otton Laskowski

      Mrrruczit – ok crunch jest zakorzeniony ale nie zmienia to faktu, że jest to w duzym skrócie efekt kiepskiego zarządzania – czyli można tego uniknąć (przynajmniej w takiej skali w jakiej to występuje). I dobrze żeby „młoda przyszłość narodu” z tego zdawała sobie sprawę a nie z tego, że „bez crunchu nie ma gry” a taki jest wydźwięk artykułu i to jest nieprawda.

      Odpowiedz
  4. Tomasz Ilnicki

    Polecam zakup sierpniowego numeru Neo Plus, w którym znajduje się 6-stronicowy artykuł dotyczący crunchu. Składa się on głównie z wypowiedzi polskich twórców gier, którzy również utrzymują, podobnie jak autor powyższego wpisu, że crunch jest czymś normalnym. Pytanie brzmi: Czy rzeczywiście jest czymś normalnym, czy po prostu deweloperzy dali sobie dawno temu zamydlić oczy?

    Wydaje mi się, że crunch powinien być marginalny w tym zawodzie, a obecna sytuacja jest pokłosiem chęci coraz szybszego powiększania zysków przez wydawców, którzy wolą wydać kilka gorszych gier w ciągu roku, niż jedną wspaniałą, której produkcja nie wymagałaby zostawania dłużej w pracy. Dodatkowo te gorsze muszą oczywiście pewien poziom jakości utrzymać, więc ekipy są przemęczone poprzez zbyt długi okres nadgodzin.

    Niestety, to wydawcy (ignoranci mający w oczach monety pięciozłotowe) podejmują tego typu decyzje i chyba niespecjalnie ich obchodzi zdanie speców. Szkoda, że wiele podpisywanych kontraktów stoi w sprzeczności z szacunkiem do ludzi tworzących gry.

    PS. Nie mam zielonego pojęcia o programowaniu i procesie tworzenia tego typu projektów, powyższa opinia to tylko moje domysły.

    Odpowiedz
  5. Roman Książek

    Ja bym bronił tego tekstu. Oczywiście wyjątkowość złożoności procesu przygotowywania gry wideo jest jednak – z całym szacunkiem – czymś przesadzonym. Sam podczas pierwszej lektury przeoczyłem ten wątek i po prostu uznałem, że Autorowi chodzi o różne systemy złożone. Takich „wyjątkowych” jest wiele. Koordynując wprowadzenie kilkudziesięciu tytułów w ramach jednej serii (ta sama data premiery), częściowo tłumaczonych z obcego języka (żeby było „prościej” dla szeregowych tłumaczy: w kodzie UXML), częściowo autorskich, jednocześnie przekładanych na inny język (tworzenie nowego zespołu za granicą), doświadczam czegoś, co można podsumować nazwą pewnego projektu muzycznego: Incredible Expanding Mindfuck. Ale to nic wyjątkowego. Tego samego doświadczałem jako belfer w szkole i osoba organizująca egzaminy wstępne na uczelni (prawdziwy hardcore: zdający plus kadra). Proszę to sobie porównać z przygotowaniami do operacji w szpitalu i samą operacją trwającą np. kilkanaście godzin. Projekt z wieloma zmiennymi – bez możliwości przesunięcia „daty premiery” czy wprowadzenia „łatek” – w którym stawką jest prawdziwe GAME OVER!
    Pomijając powyższą kwestię, artykuł Marka Pańczyka uważam za bardzo ważny. W dyskusji (także na FB) pojawiły się głosy, że to przecież tylko kwestia organizacji pracy: „złe zarządzanie, złe zaplanowanie i tyle”. Problem w tym, iż każdy przełożony
    zakładanie nadgodzin na początku realizacji projektu i brak wynagrodzenia za dodatkowy czas pracy uzna za rzecz niedopuszczalną. Jednocześnie zaś nie przeszkodzi mu to później w akceptacji takiego rozwiązania (lub nawet w negowaniu ewentualnych nadgodzin). Taka jest po prostu logika korporacji. Kiedy więc Bartek pisze: „sam też bardzo staram się nie dopuścić do żyłowania zespołu” (w co, rzecz jasna, wierzę, chodzi o symboliczną deklarację), z punktu widzenia zespołu może wyglądać to zupełnie inaczej. Zgadzam się z Autorem, że w określonych sytuacjach nadgodziny są nieuniknione. W moim przypadku, tuż przed oddaniem książek do druku w zasadzie nie ma innej możliwości (właśnie ze względu na złożoność całego procesu). Warto jednak samemu wiedzieć, gdzie należy postawić granicę (kilka lat temu znajomi wręcz zmusili mnie do wyjścia z redakcji o 12 w nocy w niedzielę – na swoje usprawiedliwienie dodam, że agentowi 007 się nie odmawia…).

    Odpowiedz
  6. Marek Pańczyk Autor tekstu

    Żeby była jasność. Błędnie odebraliście moje intencje (i szokujące jest, że pomimo mnóstwa drastycznych przykładów stałem się paradoksalnie zwolennikiem nadgodzin). Nie promuję, nie zachęcam i nie usprawiedliwiam cruncha. Wręcz przeciwnie – tekst jest manifestem mającym zniechęcić do takich praktyk. Ale bez zaklinania rzeczywistości, na podstawie bezpośrednich obserwacji, wrażeń i faktów, z najróżniejszych projektów i najróżniejszych firm. Bez stawania uproszczonych wyroków i ukazywania tylko jednej strony problemu. Musicie mi wierzyć na słowo, ale sam jestem chodzącym przykładem walki z projektami opartymi tylko i wyłącznie na nadgodzinach.

    Jak najbardziej w przypadku większości crunchy w projektach informatycznych winne jest po prostu złe zarządzanie. Bez wątpliwości. Ale też uznawanie, że jest to jedyny powód wszystkich potencjalnych crunchy w historii tworzenia oprogramowania to delikatnie mówiąc bardzo naiwne podejście. Poruszamy się też w temacie okropnie złożonym, z różnymi punktami siedzenia i gdzie można odwołać się do najróżniejszych wyjątków wspierających nasz punkt widzenia. Przykładowo – pracowałem kiedyś w firmie specjalizującej się w programach związanych z księgowością, finansami etc. etc. Z dziesięć projektów prowadzonych równocześnie przez niezależne, około dziesięcioosobowe zespoły. Do tego – co bardzo ważne – produkty nie robione na zamówienie dla jakiegoś konkretnego zleceniodawcy, ale wydawane własnym sumptem, na własnych zasadach. W ciągu trzech lat pracy w tej firmie crunch napotkałem raz i były to 3 godziny (jakbym śmiał coś takiego nazwać crunchem przy pracowniku Team Bondi to zupełnie zasłużenie otrzymałbym fangę w nos :) ). Gdyby tak wyglądało całe moje doświadczenie zawodowe, to pewnie nadal wierzyłbym bezkrytycznie w inżynierię oprogramowania, precyzyjne zaplanowanie harmonogramu, idealnie przewidzianą ścieżką ryzyka etc. etc. Cały powyższy artykuł byłby po prostu śmieszny i nieprawdziwy.

    Niemniej poznałem też innego rodzaju projekty, inne warunki i inne poziomy złożoności. Projekt, gdzie zaangażowane jest dobrze ponad sto osób z najróżniejszych specjalizacji, z wielu krajów, gdzie wchodzi równocześnie projektowanie software’u i hardware’u, nakładają się polityczne i korporacyjne anomalie. Projekt robiony na nieprzekraczalne po żadnym pozorem deadline typu Mistrzostwa Świata w Piłce Nożnej. Wreszcie gry wideo, gdzie wchodzi ogromny obszar kreatywności, którego po prostu nie zawsze da się opisać idealnie w MS Project, excelowych tabelkach i przewidzieć wszystkie pułapki. Można oczywiście zakładać, że po prostu światek gier wideo jest światem złożonym w 100% z projektanckich dyletantów i ignorantów (bowiem prawie zawsze występują tam mniejsze lub większe crunche), a świat oprogramowania dla księgowości posiada najbardziej elitarną grupę specjalistów od zarządzania projektem. Można. Tylko po co bawić się w bajki? Lepiej zrozumieć z czym mamy do czynienia i starać się minimalizować zjawisko oraz odpowiednio gratyfikować zaangażowane w projekt osoby.

    Odpowiedz
  7. Roman Książek

    @Błędnie odebraliście moje intencje (i szokujące jest, że pomimo mnóstwa drastycznych przykładów stałem się paradoksalnie zwolennikiem nadgodzin).

    Mnie też zszokował taki odbiór Twojego tekstu…

    Odpowiedz
  8. Otton Laskowski

    He he… mamy tu piękny przykład tego jak jedna osoba coś mówi z uwagą i starając się a słuchający rozumie to zupełnie inaczej – to jest dopiero bolączka przy projektach ;)

    Ale tak naprawdę mi chodziło tylko o jedno – ja po prostu nie zgadzam się z tym że nie da się zrobić gry bez crunchu. A wydawało mi się, że tekst coś takiego właśnie sugeruje. Ponadto za definicję crunchu (na podstawie tekstu) przyjąłem długie nadgodziny przepracowywane za darmo. Jasne, że czasem trzeb posiedzieć te 2 -3 dni dłużej w roku ale tu trudno mówić o crunchu. No i rzeczywiście, nie do końca odczułem to negatywne nastawienie autora do crunchu, raczej takie miałem odczucie że: „owszem to bardzo złe, no ale tak jest i trudno a czasem można w tym znaleźć też coś miłego”. Ale może nieuważnie czytałem, tak jak wszyscy czytający dokumenty design doc i autor się potem denerwuje, że to nie tak miało być ;)

    Odpowiedz
  9. Marcin

    Nie wnikam w to, co napisano tu o gamedevie, natomiast powoływanie się na szeroko pojętę projekty informatyczne jest bez sensu. Dlaczego?

    W przeciwieństwie do projektów informatycznych w ogóle, gry nie muszą spełniać zbyt wielu konkretnych wymagań, ot, mają działać i dostarczać rozrywki. Przeprowadźmy eksperyment myślowy – gdy ucina się czas z projektu gamedev’owego, to powstające dzieło składa się z mniejszej liczby poziomów, posiada mniej detali artystycznych, widać szwy fabularne, itp… owszem wychodzi z tego gra obiektywnie gorsza, ergo przypuszczalnie mniej zarabiająca – ale wciąż publikowalna gra. Z projektami informatycznymi natomiast jest tak, że większość tego, co się podczas nich wytwarza jest faktycznie niezbędne, więc jak już występują nadgodziny, to przecież nie bezpłatne :->

    Odpowiedz
    1. Marek Pańczyk Autor tekstu

      Za przeproszeniem, ale raczysz żartować. Prawie każdy projekt informatyczny może być dokładnie tak samo wzbogacony w większą lub mniejszą ilość opcji wychodzących poza bazową funkcjonalność. Od twórców oprogramowania zależy jak ma to ostatecznie wyglądać i ile poświęcają na to czasu. Wyobraźmy sobie jakiś prosty przykład – program do odtwarzania mp3. Bazowa funkcjonalność – odgrywanie mp3. Ale czy ma wspierać listy utworów, streamowanie, skórki, różne formaty, przewijanie fast-forward, teksty (lyrics) etc. etc. Wszystko to można dodać lub z tego zrezygnować. Tak więc odrzucam bezzasadność porównywania do zwykłych projektów informatycznych :)

      Odpowiedz
      1. Marcin

        Żartem jest podawanie jako reprezentatywnego przykładu komercyjnego projektu informatycznego programu do odtwarzania mp3.

        Oczywistością jest, że każde oprogramowanie można wzbogacić ponad bazową funkcjonalność. Ale to już jest coś ekstra, za co dodatkowo zapłaci klient. Bo jednak większa część komercyjnych projektów informatycznych powstaje na zamówienie płacącego klienta (a nie w celu wydania własnym sumptem, czy też z zamiarem szukania wydawców na własną rękę, jak to bywa w branży gier).

        Odpowiedz
        1. Marek Pańczyk Autor tekstu

          Mój przykład był dobry jak każdy inny, ale w tym lepszy od innych, że trywialny. To co mówisz o projektach informatycznych to taki ideał, który rzadko w praktyce ma miejsce. Nawet pomimo zatwierdzonej specyfikacji i warunków zlecenia, powstawanie projektów to ciągłe przeciąganie liny między zleceniodawcą, a twórcą oprogramowania. Zleceniodawca próbuje wytargować jak najwięcej dodatkowych funkcjonalności, które inaczej rozumiał w specyfikacji, albo kontrowersje pojawiły się dopiero przy implementacji funkcjonalności, albo jeszcze klient uznaje brak danej funkcjonalności za bug, a nie extra feature. Oczywiście, że do zarządzających projektem należy, aby odbijać tego rodzaju rzeczy, ale nie zawsze jest to możliwe co do wszystkich spraw. Czasami klient jest zbyt ważnym klientem i potrafi stawiać poważne ultimatum, a projekt na przykład dotyczy urządzeń + oprogramowania liczonego w setkach tysięcy lub kilku milionach egzemplarzy. Jak nie zgodzisz się na te dodatkowe funkcjonalności (o których klient zapomniał, inaczej zrozumiał etc. etc.) to klient zrezygnuje z kontraktu (nawet tracąc wadium), ale pójdzie do konkurencji, z którą ściśle walczysz i na przykład stracisz rynek w danym kraju czy nawet na danym kontynencie.

          Są też bardziej skomplikowane układy. Na przykład masz klienta, który zleca dany projekt. Ale nie będzie jego bezpośrednim odbiorcą, a ciałem, które zweryfikuje czy spełniasz obszerną liczbę wymagań. Natomiast później twój produkt będzie już przez twoich pośredników sprzedawany w sklepie. Czyli z jednej strony musisz zadowolić klienta co do wszystkich bazowych wymagań, ale z drugiej strony musisz zrobić produkt, który będzie sprzedawany w sklepie i będzie wyróżniał się bogactwem funkcjonalności z pośród produktów konkurencji stojących na półkach obok ciebie. Jest tak choćby z dekoderami telewizji cyfrowej w Holandii.

          Odpowiedz
          1. Marcin

            Cieszę się, że się zgadzamy, że projekty informatyczne są tak różnorodne, że przypisywanie im tego, co się dzieje w gamedevie, jest niezbyt trafne :-)

  10. artpoz

    Ja całkowicie zgadzam się z autorem artykułu. Crunchu nie da się wyeliminować, można go jedynie ograniczyć do możliwie krótkiego okresu tuż przed oddaniem projektu. Pozostaje pytanie, dlaczego ludzie się godzą na pracę w takich wydawałoby się nieludzkich warunkach. Myślę, że dochodzą tu pewne czynniki psychologiczne, kwestia silnego zaangażowania emocjonalnego w projekt, gamedev jako styl życia, rodzaj sportu ekstermalnego, działanie na granicy chaosu, spełnianie dziecięcych marzeń i pasji, satysfakcja z robienia czegoś niezwykle kreatywnego, przełomowego, rewolucyjnego itp.. itd.. Pamiętajmy o specyfice tej branży: gamedev to branża rozrywkowa, gdzie przychodzą rozrywkowi ludzie. Niekiedy praca połączona jest z zabawą, są wypożyczalnie gier, stoły do tenisa, flipery, piłkarzyki, wspólne granie sieciowe, siłownie, chillout roomy… Czasem szefowie nie proszą o zostanie w pracy dłużej, lecz wręcz z niej wyganiają. Więc jest też druga jaśniejsza strona medalu. Podsumowując cytatem z Seksmisji „Zostaw, zostaw. Tamtego świata się nie da uratować.”

    Odpowiedz
  11. RCL

    Jest duża różnica pomiędzy typowym „projektem informatycznym” a grą – gamedev nie jest częścią branży IT, lecz raczej częścią branży filmowej. Oprócz technologii, która coraz częściej jest licencjonowana, a nie tworzona od zera, o postępie prac i ostatecznie o sukcesie gry decydują tzw. „kontenciarze” – artyści, graficy, LDsi oraz game designerzy („reżyserzy”).

    Nie dosyć, że tacy ludzie są zazwyczaj o wiele mniej zdyscyplinowani niż programiści, to jeszcze ich pracę jest trudniej zaplanować i ocenić obiektywnie – najważniejsze kryteria (grywalność, fun, piękno) są subiektywne. Nie pasuje tutaj ani podręcznikowy SCRUM, ani wodospad, de facto pod każdy zespół trzeba tworzyć customizowaną mieszankę tych metod zarządzania.

    Jeśli zaś chodzi tylko i wyłącznie o programistyczną składową gier, to ją daje się w obecnych czasach w miarę dobrze rozplanować (o ile „sprzężenie zwrotne” z artystami – np. tworzenie nowych narzędzi pod realizację ich pomysłu – nie dominuje całości pracy).

    Odpowiedz
  12. terminator

    Czytam artykuł i czytam komentarze i widzę, że problem jest opisywany od tylnej strony. Każdy projekt, zaczyna się od fazy planowania, której najistotniejsza częścią jest budżetowanie. Jest bardzo osobliwą sprawą, że tam gdzie amerykańska firma planuje budżet na 100 tys. dolarów, polska firma planuje konkurencyjny projekt za 100 tys złotych. Rynek AAA to samo albo śmieszniej: Amerykanie przeznaczają setki milionów dolarów, Polacy usiłują ograniczyć się w kilkudziesięciu milionach złotych. Jak to jest koledzy możliwe? Ano jest jeśli się kreatywnie księgowo zakłada, że efektywność pracy przekroczy 200% przy minimalnych stawkach, bez uwzględniania w budżecie wydatków socjalnych, premii motywacyjnych oraz nadgodzin właśnie. Jeśli dorzucić jeszcze oszczędność na sofcie – M.Miąsik publicznie przyznał, że większość polskich gier powstała na pirackim oprogramowaniu – co zgodnie z prawem jest przestępstwem – to mamy ładną optymalizację. Co myśleć o zarządzie, który taki budżet przyjmuje? W Polsce wszystko wolno, jeśli się odnosi sukces. Wiadomo bowiem, że taki budżet nie jest do utrzymania, co oznacza, że „etaty”, a właściwie kontrakty, czyli tak naprawdę śmieciówki – także są nie do utrzymania. Stąd promuje się kreatywnych PM, którzy wprowadzają struktury elastyczne, czyli tak planują projekt, żeby np. po zamknięciu określonego kamienia milowego przeprowadzić redukcję. To nie jest przypadek, że większość ludzi, którzy odbili się od game devu ma paromiesięczne epizody w dużej firmie – to było planowe, żeby ich zatrudnić „na próbę” (czyli za stawkę minimalną), zagonić do roboty (nieraz sami z siebie zostają po godzinach, żeby się wykazać), a jak się wypalą i zaczną ciskać – „sami odejdą, nakłoni się ich do odejścia, a czasem wyrzuci na zbity pysk” jak powiedział Stan Just. W każdej firmie gdzie przestrzega się prawa pracy duża redukcja to budżetowa katastrofa. Ale nie w game devie, gdzie można zwolnić dowolną ilość osób w czasie i koszcie wystarczającym do napisania i wysłania SMSa. To wszystko PM i zarząd wiedzą już na starcie projektu i crunch nie jest żadną niespodzianką, tylko efektem fałszywych założeń budżetowych. Praca w game devie jest stresująca ponieważ pracownicy uprawiają klasyczny „soldiering” czyli usiłują pracować tylko tyle, by ich nie wywalono za brak efektów, odkładają robotę na ostatnią chwilę, kolejkują zadania żeby wyglądać na ważnych dla firmy i obronić posadę i walczą o pozycję w grupie. Natomiast management dokręca śrubę nie mając nawet podstawowych narzędzi motywacyjnych i tylko szuka kogo by tutaj „zoptymalizować”. Gorzej niż w fabryce z XIX wieku.

    Odpowiedz
    1. Bartłomiej Nagórski

      Dziękuję bardzo za ten głos. Powiedziałbym wręcz: głos rozsądku. Sam kieruję projektami informatycznymi, co prawda o nieco innej specyfice (bankowość inwestycyjna), ale również łączących pracę specjalistów z różnych dziedziń (UI/UX design, deweloperzy, business users, subject matter experts i tak dalej) – i jakoś dziwnym trafem udaje się uniknąć crunchu na finiszu, oczywiście za wyjątkiem przypadków szczególnych (np. regulatory requirements, czyli wymagania narzucone przez ustawodawcę, więc nie da się zmienić ani zakresu, ani daty końcowej, a na przykład wychodzi problem z technologią w trakcie projektu). Zawsze kiedy wygłaszam opinię, że crunch nie jest nieuniknionym elementem pracy nad grą wideo, tylko patologią, słyszę, że nie pracowałem w branży, więc się nie znam. Cóż, może jeszcze kiedyś popracuję i wtedy się zobaczy. Póki co, raczej przychylam się do opinii takich jak Twoja.

      Odpowiedz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *