On 22-9-2011 21:44, Andrzej Jarzabek wrote:
> On 20/09/2011 10:30, Sarr. wrote:
>> On 17-9-2011 23:13, Andrzej Jarzabek wrote:
>>> On 05/09/2011 11:27, Sarr. wrote:
>>>>
>>>> oprogramowanie biznesowe nie jest moja silna strona, wiec ciezko
>>>> jest mi
>>>> sie wypowiadac na ten temat.
>>>
>>> A jednak się wypowiedziałeś.
>>
>> wiesz, juz na wstepie uzylem tez zwrotu 'mam wrazenie, ze [...]'
>
> No więc właśnie ten zwrot jest mylący, bo sugeruje, że masz jakąkolwiek
> orientację w temacie, z której mógłbyś takie wrażenie wynieść.

nigdy nie mowilem, ze dysponuje wiedza z pierwszej reki. w obejcnej
chwili mam wiedze w temacie na tyle na ile wiedza ta podziela sie
koledzy pracujacy w innych branzach. pozwala mi to formuowac pewne
przypuszczenia niecalkiem znowu takie bezpodstawne. a po to jest
przeciez grupa, zeby ta takie tematy podyskutowac i bez wzgledu na to na
ile kto dysponuje wiedza z pierwszej reki. napisalem co mialem do
napisania, zaznajomilem sie z wypowiedziami innych. chyba o to w tej
zabawie chodzi, prawda? nie ma sensu sie przekrzykiwac i przyczepiac do
pojedynczych zdan bo ten sub-watek nie wprowadza juz nic o samej dysksuji...

>> [wycietego przez ciebie z cytatu], ktory bynajmniej nie sugeruje ze
>> jestem ekspertem w tej dziedzinie. wypowiedzialem sie na tyle na ile
>> uwazalem za sluszne i na tyle na ile pozwala mi wiedza i doswiadczenie w
>> zakresie tego tematu. w tej chwili ciezko mo odpowiedziec sensownym
>> argumentem na twoje jedno krotkie zdanie, ktore raczej nie wnosi nic do
>> samej dyskusji.
>
> Ja bym powiedział, że to raczej mówienie o wrażeniach, które nie
> wynikają z jakiegokolwiek poinformowania w temacie, nie wnoszą nic do
> dyskusji. Ale cieszę się, że sobie to wyjaśniliśmy, bo możemy chyba w
> tym momencie zakończyć dalszą dyskusję o twoich wrażeniach na temat
> oprogramowania biznesowego, jako nie mających nic wspólnego z
> rzeczywistością?

powiedzialbym, ze to troszke za daleko idace podsumowanie. z twojej
strony tez raczej wiecej niz wrazenia i teoretyzacje nie padlo. bez
konkretnych przykladow popierajacych twoja teze, fakt, teoretyczne
dyskusje nie maja wiekszego sensu. przychyle sie wiec do postawienia
tutaj EOT-a.

>>>> trzeba by porownac ile bylo innoawcji w tych branzach w ciagu ostatnich
>>>> lat, ale nie czuje sie na silach tego zrobic bo nie mam wystarczajacej
>>>> wiedzy ani danych zeby zrobic to solidnie. moge sie jedynie
>>>> wypowiedziec
>>>> z punktu branzy gier komputerowych ale jak wspomnialem powyzej, troche
>>>> wydaje mi sie, ze odchodzimy od tematu i skupiamy sie na dyskutowaniu
>>>> wyzszosci motocykla nad samochodem i vice versa.
>>>
>>> Zrozumiałem że twoja odpowiedź na pytanie z tematu była taka, że
>>> programiści gier mniej zarabiają, bo w grach jest więcej innowacji (niż
>>> w branżach, gdzie programiści zarabiają więcej). Mój punkt był taki, że
>>> twoja opinia wynika z tego, że nie wiesz o czym mówisz, jeśli chodzi o
>>> innowacyjność w innych branżach.
>>
>> moja odpowiedz w rozwinieciu byla taka:
>> - w branzy gier czesciej niz w innych branzach stawia sie na innowacje,
>> wiecej sie ryzykuje - to jest zalozenie. z mojego skromnego
>> doswiadczenia wynika, ze tak jest. pracujac w grach trafilem na sporo
>> projektow, ktore z roznych powodow nie zostaly wydane. bylem swiadkiem
>> zamykania jednego i drugiego studia, bo produkt, nad ktorym pracowali,
>> nie sprzedal sie tak jak to bylo planowane [wspominalem juz, sam tez raz
>> znalazlem sie w takiej sytuacji]. natomiast zaden z moich znajomych
>> pracujacych w innych branzach niz gry, nie byl w stanie wspomniec tylu
>> [i w taki sposob] pogrzebanych projektow w ich firmach. wnioskuje, ze
>> ratio projektow rozpoczetych do ukonczonych, czy moze lepiej,
>> rozpoczetych to zakonczonych sukcesem finansowym w branzy gier jest
>> sporo nizsze. dygresja: do tego dochodzi jeszce kwestia wydawcy, ktorego
>> moze zabraknac [zbyt innowacyjny produkt, zbyt duze ryzyko dla wydawcy i
>> na koniec okazuje sie, ze nikt nie chce kupic i wydac twojej gry] albo
>> tez moze skutecznie pogrzebac produkt poprzez slaby marketing i
>> suppoprt. jesli chcesz obalic moje zalozenie, prosze o konkrety, a nie
>> odpowiedzi w stylu 'nie wiesz co mowisz'. w kwestii branzy gier, mimo,
>> ze bynajmniej wszystkich rozumow nie zjadlem, to jednak swoje wiem ;]
>
> Nigdy nie twierdziłem, że nie wiesz o branży gier. Tylko, żeby
> powiedzieć "w branży gier częściej niż w innych branżach" cokolwiek
> (wiedząc, co się mówi), nie wystarczy wiedzieć o branży gier, trzeba
> jeszcze wiedzieć o innych branżach. I tutaj właśnie twierdzę, że nie
> wiesz, co mówisz.

napisalem rozwiniecie tego co mialem na mysli i dlaczego tak mysle.
wczesniej podalem tez przyczyny z jakich branza gier wedlug mnie jest
bardziej podatna na innowacje. tutaj nie mam nic wiecej do dodania.
jezeli cos nie jest zrozumiale to chetnie wytlumacze.

posadzanie mnie o braki w temacie oprogramowania biznesowego nie zmienia
faktu, ze sam nie podajesz zadnych argumentow na poparcie twojej wersji.
jezeli czujesz sie na silach, i co najwazniejsze naprawde chcesz, zeby
pociagnac ten watek, to prosze zaproponuj definicje innowacyjnego
produktu na potrzeby naszej dyskusji i przygotuj zastawienie
innowacyjnych produkcji z branzy biznesowej. wtedy mozemy sie
zastanowic. bez tego, niestety sie nie da.

> Ja sam, nie wiedząc zbyt wiele o branży gier, mogę podzielić się takimi
> spostrzeżeniami:
> * W ogromnej większości wielkobudżetowe gry, które widzę, albo w które
> gram, są raczej mało innowacyjne. Ja rozumiem, że tych gier, które nie
> znajdują wydawcy bo są zbyt innowacyjne nie widzę w ogóle, a tych
> innowacyjnych, które się słabo sprzedają, mogę nie zauważać, ale też
> tych mało innowacyjnych, a nawet wręcz straszliwie wtórnych gier jest
> cała masa, i ktośtam przy nich pracuje, programiści również.
to dokladnie to co ja napisalem. zgadzamy sie w pewnych kwestiach.

> * W znanym mi niedawnym przypadku zamknięcia studia, gra, przez którą
> zostało zamknięte, raczej nie dlatego się słabo sprzedawała, że była
> zbyt innowacyjna, raczej wręcz przeciwnie.
bywa i tak. moze wiesz co na temat wynagrodzenia programistow tego studia?

> * Ogólnie jednak to te gry kosztują trochę za dużo, żebym mógł uwierzyć,
> że pieniądze na ich produkcję wyciągają entuzjaści z własnych kieszeni.
> W związku z tym raczej sądzę, że ci, co finansują tworzenie tych gier
> mają możliwość słabej sprzedaży wkalkulowaną w ryzyko i że per saldo im
> się ten cały biznes opłaca.
wiesz, nie kazda gra to produkcja AAA za ciezkie miliony. przeciez ja
nie mowie, ze programisci pracuja za darmo albo dokladaja sie do gier
ktore tworza w parcy. ja mowilem o prototypach, ktore sa finansowane
przez studio, ktore jednak nie maja gwarancji, ze produkt finalny
przyniesie zysk. niekiedy zespol jest tak mocno zaangazowany w projekt,
ze zeby go kontynuowac jest w stanie przymknac oko na same zarobki. i
studio czesto na to idzie. i nie, nie twierdze, ze jest to sytacja
nagminna. twierdze jednak, ze jest to pewne wytlumaczenie dlaczego w tej
branzy placi sie niekiedy mniej. jasne, ze nie tlumaczy to wszyskich
przypadkow. ot, dorzucilem tu swoje piec groszy.

> * W związku z tym sądzę, że kapitał, który finansuje studia po prostu
> liczy się z ceną rynkową wszystkich kosztów, w tym pensji programistów.
> Gdyby ta cena była wyższa, to kapitał na taką też cenę by przystawał -
> bo w to, żeby się przestało opłacać robić gry to raczej nie wierzę.
gdyby tak bylo, to studia by nie padaly ;] niekiedy studia zaciskajac
pasa inwestuja na tyle na ile moga we wlasne projekty [a nie prace
zlecone od wydawcow czy innych wiekszych koncernow] bo maja nadzieje, ze
to cos, co tworza sie dobrze sprzeda - i extrapolujac: odniosa sukces,
zacznie sie hossa, wieksze projekty, wieksze pieniadze, etc. niestety
czesto bywa tak, ze sie nie sprzedaje, mimo szczerych checi calego
zaspolu. wtedy okazuje sie, ze zainwestowane peniadze ciezko odzyskac
wykorzystujac kod w innych projektach bo jest on na tyle zorientowany
pod dany projekt, ze nigdzie indziej sie nie nadaje [albo relatywnie
malo daje sie odzyskac]. chodzi mi o to, ze takie zagrania vabank sa
czeste w branzy gier i oczywiscie moge podac kilka konketnych przykladow.

> * Tam, gdzie cena rynkowa pracownika jest odpowiednio wysoka, a dany
> pracownik godzi się na udział w ryzykownym przedsięwzięciu za pensję
> odpowiednio niższą, na ogół robi to w zamian za obietnicę wyrównania z
> odpowiednią nawiązką jeśli ryzyko się opłaci - w postaci
> zakontraktowanej premii powiązanej z wynikami firmy albo udziałów w tejże.
bardzo rzadko stosuje sie takie obietnice. programisci sami sobie
kalkuluja i jesli na takie warunki przystaja, znaczy im to odpowiada
[lubia projekt, chca nabrac doswiadczenia, albo z innych wzgledow nie
maja innego wyjscia]. wspominalem tez, ze duza role odgrywa bardzo
czesto fascynacja tym co sie robi. rzadko spotyka sie programistow gier,
ktorzy przychodzac rano 'podbijaja karte', 8h i ida do domu. nie wiem na
ile jest to popularne w innych branzach ale w grach czesto jest tak, ze
atmosfera i inne dodatki niematerialne przewazaja szale. zdaje sobie
sprawe z tego, ze niektorym ciezko jest zrozumiec dlaczego dorosli
ludzie godza sie na takie sytuacje, ale niektorym tez ciezko jest
zrozumiec, ze dorosli 35+ lat graja z 'glupie gierki'.

>> - bywa czesto tak, ze wiekszosc osob w studiu, ktore chce zabylsnac
>> nowoscia zdaje sobie sprawe, ze jesli produkt nie wypali, to bedzie
>> krucho, wiec kazdy ze swojej strony zaciska pasa i ma nadzieje, ze
>> jednak wypali, i wszyscy na tym skorzystaja;
>
> No więc normalnie by się to kalkulowało tak, że skoro gra powstaje
> powiedzmy 3 lata, szansa na powodzenie jest powiedzmy 50%, a programista
> pracujący przy niej zarabia powiedzmy 5k na rękę zamiast 10k, które
> mógłby zarobić gdzie indziej, to jeśli jednak gra się sprzeda, ten
> programista może oczekiwać na zarobek 360 000 w postaci premii, dochodów
> z udziałów itd. Moja mikra wiedza o branży gier daje mi wrażenie, że
> jednak nie może, ale może jednak się mylę?
>
duzo przyczyn sklada sie na to, ze jednak tak nie jest... podane przez
ciebie 3 lata to bardzo dlugo w grach... ogolnie jest tak, ze w trakcie
produkcji wyjdzie kilka innych tytulow, od ktorych trzeba bedzie byc
lepszym, wiec wymagania/featuresy nie sa stale a ewoluuja w czasie - w
grach praktycznie nie istnieje finalna wersja design dokumentu...
zalozenia wstepne, ze powiedzmy gra sie dobrze sprzeda jak zrobimy 'to i
tamto' sa bardzo szybko weryfiowane kiedy kto inny zrobi 'to i tamto'
lepiej w miedzyczasie [i szlag trafia hasla marketingowe ;], jesli sie
nie zainwestuje w to, zeby zrobic to jeszcze lepiej albo dorobi cos co
bedzie przyciagalo uwage - nie sprzeda sie tak jak by sie myslalo.
oczywiscie nie mozna dodawac features'ow i rozwijac projektu w
nieskonczonosc bo sa pewne sztywne ramy czasowe.

w tej branzy [pewnie mozesz sie przyczepic ze nie wiem jak jest w
innych] jest tak, ze czesto jesli bedziesz trzymac sie planu i zrobisz
100% to jestes skazany na porazke - taka specyfika. masz na przyklad
sytuacje gdzie pod koniec terminu masz gre, ktora nie obsluguje
multiplayera, bo nie bylo go w oryginalnym designie. okazuje sie, ze
pojawily sie inne konkurencyjne produkcje, ktore maja multiplayera.
jezeli tego nie dodasz to drastycznie zmniejszy to atrakcyjnosc twojego
produktu. wiec masz 2 wyjscia: uznac, ze nie potrzeba i probowac
sprzedac mimo wszystko nawet jezeli widac ze masz slabe szanse, albo
sprezyc sie, zaryzykowac, doinwestowac, sprobowac sprostac oczekiwaniom
i miec nadzieje, na wiekszy zysk [ktory w zalozeniu pokryje dodatkowe
koszty]. czesto wybierana jest ta druga opcja, ktora daje pewna szanse
na sukces, podczas gdy pierwsza prowadzi w prostej linii do porazki. to
sa bardzo trudne decyzje, ktore trzeba podjac niekiedy kilkukrotnie w
czasie produkcji, a ktore moga byc potencjalnie fatalne w skutkach i
bardzo wplywaja na efekt koncowy [sukces badz jego brak]. to jest
wlasnie to zwiekszone ryzyko, ktore sie podejmuje. premie i dodatki - to
w wiekszosci przypadkow marzenia. oczywiscie ciekaw jestem jak to
wyglada w branzy biznesowej, ale zaryzykuje stwierdzenie, ze chyba
jednak nie tak wlasnie.

>> - studio chcac pociagnac projekt jak najdluzej, doszlifowac go
>> jaknajlepiej, chce oszczedzac, wiec stara sie placic najmniej jak to
>> mozliwe, i do pewnego stopnia jest to rozumiane przez zaloge;
>
> To ci powiem tyle, że załoga jest naiwna, i ty jesteś naiwny, że tak
> myślisz. Produkcja gry wymaga kapitału i studio stara się płacić
> najmniej, żeby właściciel tego kapitału jak najwięcej zarobił.
> Oczywiście pod tym względem gry nie różnią się niczym od innych
> prgramów, jedyna różnica to pytanie, ile to jest "jak najmniej" - ile
> trzeba jednak zapłacić, żeby programista zgodził się w ogóle pracować.

dziekuje za podsumowanie. nie zapominaj jednak, ze wspomnialem, ze pewne
sytuacje sa zrozumiale dla zalogi do pewnego stopnia - nie wszyscy sa
'naiwni' do konca zycia. tu wlasnie wychodzi roznica miedzy seryjnym
koderem, ktory pisze to co mu zadano a programista gier, ktory ma szanse
pracowac nad projektem, ktory go naprawde interesuje. jedni chca 20%
podwyzki, inni wybieraja nawalanie w team fortress w czasie pracy. jedni
pracuja 8h i wychodza, inni doszlifowuja swoje algorytmy po czasie bo to
ich interesuje, jeszcze inni zagraja w pracy pare rundek na street
fighterze w piatek przy piwku. wiesz, cos za cos, co komu odpowiada. mi
osobiscie milo pracuje sie z fascynatami. problemy zaczynaja sie kiedy
te extrasy nie wyrownuja zalodze brakow w wynagrodzeniu, ale to juz
chyba jak wszedzie indziej.

>> stawac okoniem nie ma w takiej sytuacji sensu, bo studio
>> nie chce utopic worka pieniedzy w projekcie, ktory ma szanse sie nie
>> zwrocic i bedzie minimalizowac wydatki.
>
> Ale opowiadasz to tak, jakby te projekty, które się zwracają, zwracały
> się ledwo-ledwo, i jakby programistom zapłacić więcej, to już by się nie
> zwróciły. Moje wrażenie (może mylne) jest takie, że nawet jak projekt
> będzie hitem, to programiści i tak będą mieli z tego fistaszki, w
> porównaniu z tym, co by zarobili w innych branżach.

troche o tym dlaczego projekty jesli sie zwracaja to czesto zwracaja sie
ledwo-ledwo wspomnialem powyzej. do tego dochodzi wydawca i marketing,
ktory moze rozlozyc nawet najlepszy produkt. nie zdarzylo mi sie
pracowac w zadnej firmie, ktora wynagrodzenie uzaleznialaby od sukcesu
produktu - znasz moze przyklady firm, ktore placa pracownikom w
zaleznosci o odniesionego sukcesu?

>> stawianie sprawy na ostrzu noza
>> i wymaganie podwyzek moze skonczyc sie tym, ze programista zegna sie ze
>> studiem na wlasne zyczenie, a projekt, czesto prowadziony doslownie
>> przez kilka osob zostaje pogrzebany. programista, ktory spedzil nad gra
>> sporo czasu, wlozyl sporo wysliku i ceni prace kolegow, nie bedzie
>> sklonny do trak drastycznych posuniec;
>
> Ale to jest błąd w myśleniu takiego programisty: skoro ktoś wyłożył
> sporo pieniędzy na projekt, który w takiej sytuacji zostanie pogrzebany,
> to ten ktoś do pewnego momentu chętniej trochę dołoży albo przynajmniej
> zgodzi się podzielić zyskiem, niż zdecyduje się wszystko stracić.

i tu sie mylisz, bo bywa tak, ze studiu mniej zalezy na projekcie niz
samej zalodze. powiedzmy, ze trafia sie projekt, ktory wykorzystuje
jeden z wiodacych silnikow growych i jest to pewna odmiana dla
programistow. beda oni chcieli projekt ciagnac jaknajdluzej, zeby
jaknajwiecej skorzystac i nauczyc sie tego silnika, bo to moze im sie
przydac [jak beda sie starac o nowa posade na przyklad] - wiec
przymykaja oko, bo to co jest im placone mniej, moze sie zwrocic, kiedy
dzieki wiedzy nabytej podczas tego projektu, dostana lepiej platne
stanowisko gdzie indziej. pomijam tutaj to, ze po prostu moze ich to
bardzo intertesowac prywatnie. nie wszystko da sie w prosty sposob
przelozyc na wynagrodzenie.

czasem tez niestety chodzi o to, ze jak jednemu sie uda taka podwyzka to
wszyscy sie upomna a na tyle to juz na pewno pracodawca nie ma funduszy.
na to juz nie ma mocnych i w takiej sytuacji trzeba sie pozegrac.

>> w skrocie: oferuje sie inne warunki pracy i placi sie mniej, do pewnego
>> stopnia majac na to przyzwolenie zalogi.
>
> W skrócie: programiści zarabiają mniej, bo dają się dymać bez wazeliny.

powyzej juz ci napisalem, w odpowiedzi na zarzut o naiwnosci - podwyzka
vs team fortress. nie mierz innych swoja miara.

>>> Rendering pipeline może i nie (ale na tym się nie znam), ale przy takich
>>> rzeczach jest sporo pracy, gdzie wymaga się znajomości C++ i
>>> umiejętności pisania wydajnych programów. Więc to drugie to - wydaje mi
>>> się - raczej tylko racjonalizacja tego pierwszego.
>>
>> umiejetnosc pisania wydajnych programow to nie dokladnie o co mi
>> chodzilo.
>
> Nie mówię, że o to ci chodziło, tylko że programiści gier często to
> potrafią, a potrafiąc to można znaleźć dobrze płatną pracę w innych
> branżach. Tak że to, co pisałeś o certyfikacie Microsoftu to
> racjonalizacja: w innych branżach też jest tak, że jak się zmienia
> pracę, to część umiejętności staje się nieprzydatna. Mimo tego bywa też
> tak, że można znaleźć znacznie lepiej płatną pracę, chociaż taką, gdzie
> wiele posiadanych umiejętności będzie nieużywanych.

czesto potrafia i czesto znajduja. chcialem tylko zwrocic uwage na to,
ze przejscie z gier gdzie indziej, szczegolnie po dluzszym czasie, to
nie jest takie znowu hop-siup, i taki senior programmer moze okazac sie
mniej warty dla pracodawcy od juniora z adekwatnym doswiedczeniem. i to
powoduje pewne zgrzyty.

>> tu mialem na mysli znajomosc na wylot sprzetu i jego
>> mozliwosci, ktorych nijak nie da sie wykorzystac gdzie indziej. jest
>> sporo takich specyficznych zagadnien, jako przyklad moge podac nintendo
>> ds. kodujac pod ds, ktore o ile dobrze pamietam ma tylko 2 jednostki do
>> dzielenia i 1 do pierwiastkowania, trzeba pisac swoje funkcje w dosc
>> specyficzy sposob, tak zeby nie zawalic obu jednostek jednoczesnie i
>> czekac na wynik. jesli chcesz uzyc w pewnym momencie pierwiastka, to
>> wrzucasz jego liczenie w pierwszej lini, a wyniki wykorzystujesz w
>> ostatniej mozliwej. podobnie musisz porozrzucac dzielenia, poumieszczac
>> je 'najwyzej' jak to mozliwe, a wyniki wykorzystywac 'najnizej' jak to
>> mozliwe. jesli masz kilka dzielen i pierwiastkowan, to twoja funkcja ma
>> szaqnse wygladac naprawde 'ciekawie'. dla kogos kto nie zna specyfikacji
>> sprzetu, na pierwszy rzut oka taka funkcja to balagan. znam taka
>> ciekawostke, z doswiadczeniem ilosc takich znanych mi ciekawostek
>> rosnie, zaczynam sie specjalizowac - a gdzie ewentualnie moge pozniej ta
>> wiedze wykorzystac poza kodowaniem pod ds? ;]
>
> Ale to jest też taka specyficzna, powiedziałbym nawet że studencka,
> mentalność, że o twojej wartości jako pracownika stanowi znajomość
> tricków na Nintendo DS. Bo jak ktoś ma trochę dłuższą perspektywę, to
> może się zastanowić, co się z tą wartością stało kilka lat temu w
> przypadku programistów, którzy znali na wylot starego XBoxa albo
> Playstation 2.

bez przesady, zaczeli kodowac pod x360 i ps3 co bylo naturalnym krokiem
w ich karierze... dzieki temu moga sie dalej specjalizowac i robic to co
lubia... wbrew pozorom niektorzy lubia sie specjalizowac... chodzilo mi
o to, ze czasem ciezko jest porzucic specjalizacje ktora sie lubi w imie
samych pieniedzy, ot, tyle...

> Z drugiej strony mógłbym sobie pozwolić na dywagację, że ktoś, kto
> oprócz tego, że zna nintendo czy co tam na wylot jest jeszcze _dobrym_
> programistą, czyli takim, który znajdzie dobrze płatną pracę w innych
> branżach mimo braku certyfikatu MS, poradzi sobie z napisaniem kodu
> spełniającego powyższe wymagania tak, żeby nie wyglądał jak bałagan i
> żeby intencja była zrozumiała również dla kogoś nie znającego sprzętu.
> No ale tu z kolei nie będę podejmował dyskusji o konkretach, bo się nie
> znam na nintendo.

zalozylbym, ze sobie poradzi. ale nie bedzie sie do tego spieszyl.
bedzie wolal kodowac gry, niz klepac kod pod bazy danych, i bedzie to
chcial robic tak dlugo na ile rozwarstwienie wynagrodzen bedzie dla
niego pomijalne ;]

pozdrawiam
Marcin.