Dnia 20-01-2013 o 12:58:29 PK <P...@n...com> napisał(a):

> W Polsce niezbyt powszechny jest zwyczaj dawania premii
> za jakiś konkretny konkretny projekt. Premie najczęściej są okresowe.

I to jest bez sensu, bo wtedy większość uważa, że się po prostu należy.
Powinny być za konkretne projekty, nawet jak nie trzeba przy nich zasuwać
na 120% normy.

--
Boguś
/Każdy skutek ma swoją przyczynę/

do góry

On 2013-01-20 12:58, PK wrote:
> On 2013-01-19, Roman W <b...@g...pl> wrote:
>> A dostał premie za ten kontrakt?
>
> Tak jak napisał yamma - nie rozumiesz sytuacji.
>
> Pensja pracownika jest funkcją m.in. obciążenia pracą
> i już uwzględnia to, że okazjonalnie trzeba będzie posiedzieć dłużej.
>
Co jest bezsensem typowym dla polski. Dlaczego? Bo jak jest zespol
pracownikow a nie tylko jedna osoba to nie ma chetnego aby posiedziec
dluzej, a jedyna motywacja jest mozliwosc "likwidacji stanowiska pracy".
Zupelnie inaczej to wyglada jak za extra prace sa 100% nadgodziny. Wsrod
chetnych mozna przebierac.

Pozdrawiam

Marek

do góry

On 2013-01-20, Bogusław Szczepanowski <n...@i...net> wrote:
> O ile przedmiotem umowy nie jest jakość (ogólnie pojęta: dostępność, czas
> reakcji na błędy) oprogramowania. Bo wtedy pewnie i prawnicy będą musieli
> powiedzieć pass, jeżeli IT powie, że się nie da.

Nie chodzi o to, na co opiewa umowa, bo to może napisać każda dobrze
poinformowana osoba.
Wyraźnie użyłem słowa "konstruować". Rolą prawników jest napisanie
umowy poprawnej i bezpiecznej, czyli:
a) zgodnej z obowiązującym prawem,
b) nie narażającej firmy na straty (tzn. bez jakichś poważnych "luk").

Jeśli Twój program będzie błedny, to w zdecydowanej większości
przypadków po prostu możesz go poprawić. Jeśli będzie duży błąd
w umowie, to tragedia, płacz i zwolnienia :).

Programiści w dużych firmach (a także różnej maści analitycy, badacze
itp.) mają tendencję do wpadania w samozachwyt, tzn. są świetnie
wykształceni i robią zaawansowane projekty najlepszymi metodami.
Szczególnie jeśli są otoczeni jakimiś sprzedawcami i marketingowcami.
Brutalne realia:
a) to sprzedawcy i marketingowcy zarabiają firmie pieniądze,
b) to prawnicy dbają, żeby firma nie miała dużych strat,
c) programiści i analitycy po prostu zamieniają input w output - są
trybikami w wielkiej maszynie.

Oczywiście sprawa ma się trochę inaczej, jeśli pracuje się w firmie
sprzedającej soft, ale to dotyczy de facto garstki profesjonalistów
z branży :).

pozdrawiam,
PK

do góry

On 2013-01-20, Marek Borowski <m...@...borowski.com> wrote:
> Co jest bezsensem typowym dla polski. Dlaczego? Bo jak jest zespol

Nie wiem, czy takim typowym dla Polski, bo np. w mojej firmie
wprowadziła do centrala grupy zza gór, lasów i ze 2 granic
międzypaństwowych.

> pracownikow a nie tylko jedna osoba to nie ma chetnego aby posiedziec

Marne masz doświadczenia (marnych współpracowników)?

> dluzej, a jedyna motywacja jest mozliwosc "likwidacji stanowiska pracy".
> Zupelnie inaczej to wyglada jak za extra prace sa 100% nadgodziny. Wsrod
> chetnych mozna przebierac.

Motywacja "możliwość likwidacji stanowiska pracy" jest całkiem niezła.
Niewiele gorsza jest "możliwość awansu lub podwyżki".

Firmy naprawdę sobie radzą - nie musisz się martwić za prezesów :).

Wyobraźmy sobie hipotetycznie, że w firmie pojawia się zupełnie kluczowe
zadanie, którego nie chce się podjąć żaden pracownik.
Np. masz zespół "Stachów K." gapiących się w Vima, a trzeba coś zrobić
w Visual Studio. Wszystkie Stachy mówią, że nie i już. Przeżyją brak
premii - zarabiają nieźle i nie będą się płaszczyć przed jakimś IDE
od Gatesa!

I co - system premii działa?

I tu z pomocą przychodzi system, któremu jesteś przeciwny (ładnie
opisany w wiadomej pozycji pana Sun Tzu):
Dyrektor: "Stachu_0 - jesteś liderem, Twój zespół nie chce robić
projektu. Ty go zrobisz."
Stachu_0: "Nie zrobię."
Dyrektor: "To znajdź sobie karton. Stachu_1 - teraz Ty jesteś liderem
zespołu. Ty zrobisz projekt."
Stachu_1: "Tak jest panie dyrektorze!"

I życie toczy się dalej.
:D

pozdrawiam,
PK

do góry

Dnia 20-01-2013 o 22:23:39 PK <P...@n...com> napisał(a):

> Nie chodzi o to, na co opiewa umowa, bo to może napisać każda dobrze
> poinformowana osoba.
> Wyraźnie użyłem słowa "konstruować". Rolą prawników jest napisanie
> umowy poprawnej i bezpiecznej, czyli:
> a) zgodnej z obowiązującym prawem,
> b) nie narażającej firmy na straty (tzn. bez jakichś poważnych "luk").
>
> Jeśli Twój program będzie błedny, to w zdecydowanej większości
> przypadków po prostu możesz go poprawić. Jeśli będzie duży błąd
> w umowie, to tragedia, płacz i zwolnienia :).

O ile mój błąd nie będzie miał wymiernych skutków finansowych etc., które
zostaną zauważone dopiero po wdrożeniu. Wtedy też, owszem mogę poprawić,
ale jest już po ptokach. Ja nie umniejszam roli prawników, chcę tylko
zauważyć, że prawnicy swoim "konstruowaniem" nic nie zdziałają, jeżeli nie
będą mieć solidnego zaplecza technicznego. Zaplecza, które się nie sypnie,
bo było robione na już.

> Programiści w dużych firmach (a także różnej maści analitycy, badacze
> itp.) mają tendencję do wpadania w samozachwyt, tzn. są świetnie
> wykształceni i robią zaawansowane projekty najlepszymi metodami.
> Szczególnie jeśli są otoczeni jakimiś sprzedawcami i marketingowcami.
> Brutalne realia:
> a) to sprzedawcy i marketingowcy zarabiają firmie pieniądze,
> b) to prawnicy dbają, żeby firma nie miała dużych strat,
> c) programiści i analitycy po prostu zamieniają input w output - są
> trybikami w wielkiej maszynie.

I niestety, cała reszta popada w taki sam samozachwyt. Do tego stopnia, że
potrafią wysycić łącze poprzez IO na chomika tak, że aplikacja dla
klientów przestaje działać. I nie można im nic powiedzieć, bo w końcu to
oni zarabiają pieniądze.

Była kiedyś taka bajka o dupie, która srać nie chciała. I nie, żebym był
tą dupą, i sabotował, ale cały biznes bez zaplecza technicznego nic nie
zdziała, jak i zaplecze techniczne nie jest bez biznesu nikomu potrzebne.

--
Boguś
/Każdy skutek ma swoją przyczynę/

do góry

On 20.01.2013 22:45, PK wrote:
> Wyobraźmy sobie hipotetycznie, że w firmie pojawia się zupełnie kluczowe
> zadanie, którego nie chce się podjąć żaden pracownik.
> Np. masz zespół "Stachów K." gapiących się w Vima, a trzeba coś zrobić
> w Visual Studio. Wszystkie Stachy mówią, że nie i już. Przeżyją brak
> premii - zarabiają nieźle i nie będą się płaszczyć przed jakimś IDE
> od Gatesa!

Bardzo dziwnie sobie dobrałeś pracowników ;) "Stado Stachów K." nie
nadaje się na koderów, co powinieneś był zauważyć dużo, dużo wcześniej
wcześniej. Ktoś, kto ich zatrudnił powinien wylecieć z HR.


>
> I co - system premii działa?

Masz niewłaściwych ludzi na niewłaściwym miejscu - dobrze jak cokolwiek
działa.

Poza tym jest to tylko kwestia "odpowiedniej" premii. Za umiejętności
się płaci, zawsze możesz sam odpalić to VS ;)

>
> I tu z pomocą przychodzi system, któremu jesteś przeciwny (ładnie
> opisany w wiadomej pozycji pana Sun Tzu):
> Dyrektor: "Stachu_0 - jesteś liderem, Twój zespół nie chce robić
> projektu. Ty go zrobisz."
> Stachu_0: "Nie zrobię."
> Dyrektor: "To znajdź sobie karton. Stachu_1 - teraz Ty jesteś liderem
> zespołu. Ty zrobisz projekt."
> Stachu_1: "Tak jest panie dyrektorze!"

A co jak Stachu_1 odpowie "nie"? A co jak Stachu_2 odpowie "Jak zwolnisz
Stacha i Stacha_1 to też sobie pójdę"? A Stachu_3 doda "i ja też"?
Zlecisz jednak zadanie dla koderów koderom, czy zwolnisz cały zespół?

>
> I życie toczy się dalej.

Manago nie są niezwalnialni zwłaszcza jak nie mają wyników a za to dużą
rotację personelu.

--
Pozdrawiam
Michoo

do góry

On 2013-01-12, PK <P...@n...com> wrote:
> On 2013-01-10, Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid>
wrote:
>> Okej, i niech używają. Ja pytałem o funkcje, które by mogły
>> rekompensować pewne braki *mnie*. Przypisywanie mi stanowiska, że IDE
>> się w ogóle nie nadają do pracy, jest grubym nadużyciem, co już
>> parokrotnie zaznaczałem.
>
> Ale my nie znamy *Ciebie* i nie wiemy, jak używasz oprogramowania.

Było trochę podane, wystarczyło się ustosunkować.

> No i nie bardzo widzę powody, żeby miał Ci udowadniać, jakie to IDE
> są świetne. Nie sprzedaję, nie reklamuję, a nawet ich nie tworzę.

To po co próbujesz (do tego nieudolnie) to robić?

> Po prostu radzę spróbować. Przy czym warto
> to zaznaczyć, że moim (ale nie tylko) zdaniem w świecie IDE jest
> Visual Studio, długo nic i kilka innych programów (np. Netbeans,
> jeśli nie przeszkadza Ci jego powolne tempo).

Ta, używałem tego Visual Studio. Edytor czasem wcina mi blok tekstu,
który wklejam, a czasem nie. Niech się, kurna, zdecyduje: albo pomaga
*zawsze*, albo nie pomaga *nigdy*.

Ale OK, zgoda, niech sobie będzie najlepszy. Może ja się nie umiem z nim
dogadać.

> Zresztą jeśli planujesz zawód programisty, to pewnie z dość dużym
> prawdopodobieństwem w końcu się na jakieś IDE natkniesz. Może nawet
> będziesz pracował pod Windowsem. Tworzenie sobie takich uprzedzeń
> w młodości nie jest najlepszym pomysłem :)

A skąd pomysł że teraz, po kilku latach pracy, będę się chciał nagle
przekwalifikowywać na programistę?

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-01-16, PK <P...@n...com> wrote:
> On 2013-01-16, Adam Wysocki <g...@s...invalid> wrote:
>> Ja bym chciał - jeśli naprawdę się zna, jest perfekcjonistą i wie co robi.
>> Bardzo nie lubię bylejakości.
>
> Co kończy się np. tak:
>
> Ty: "Stachu, na jutro potrzebujemy prostej aplikacji pod Windowsa,
> która będzie robiła cośtam"
> Stachu: "Na jutro się nie da. Jest już 17:00, a 2 godziny zajmuje
> mi otwarcie wszystkich programów w moim super modularnym środowisku".

To chyba tobie zajmuje tyle otwarcie wypasionego IDE.

Zresztą taki Stachu w pierwszym rzędzie nie daje się nabrać na posadę,
gdzie programu z terminem "na jutro" nie da się napisać inaczej niż
w IDE.

Ustaliliśmy już, że IDE dodaje trochę bardziej zaawansowane
znajdź/zamień (plus przeglądarka klas i parę innych rzeczy, które nie
mają wielkiego znaczenia podczas pisania na kolanie). Jeśli pisanie
programu "na jutro" IDE przyspiesza tak, że nie da się tego samego
zrobić bez IDE, to znaczy że program jest nudny, nieciekawy, powtarzalny
i w ogóle nie ma się czym chwalić. Od takich zadań są klepacze kodu
(nawet nie programiści), a nie administratorzy czy programiści
systemowi.

> Ty: "Stachu, ma być na Windowsa i ma być na jutro. Zrób to w Delphi."
> Stachu: "Delphi?! Nie ma mowy. Pamiętaj: naprawdę się znam, jestem
> perfekcjonistą i wiem, co robię. Ufasz mi."

Powinno stać: "Delphi?! Nie ma mowy. Jestem sysadminem, nie klepaczem
UI. Tu jest moje wypowiedzenie."

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-01-18, yamma <y...@w...pl> wrote:
>
> Użytkownik "Roman W" <b...@g...pl> napisał w
> wiadomości news:almarsoft.9197144111761122736@news.plus.net...
>> On 16 Jan 2013 19:13:37 GMT, PK <P...@n...com> wrote:
>>> Co kończy się np. tak:
>>> Ty: "Stachu, na jutro potrzebujemy prostej aplikacji pod Windowsa,
>>> która będzie robiła cośtam"
>>> Stachu: "Na jutro się nie da. Jest już 17:00, a 2 godziny zajmuje
>>> mi otwarcie wszystkich programów w moim super modularnym
>> środowisku".
>>> Ty: "Stachu, ma być na Windowsa i ma być na jutro. Zrób to w
>> Delphi."
>>
>> Jak ktos chce o 17.00 aplikację na jutro, to sam sie prosi o kłopoty.
>
> LOL! Jasssne... Powiesz to szefowi? Programiści zwykle zarabiają 1,5 do 2
> razy więcej niż reszta działu IT

Jakieś opracowania statystyczne na ten temat? Wyniki ankiet? Bo ile razy
ja patrzyłem w wynikach ankiet, sysadmini i DB-admini zarabiali średnio
tyle samo co programiści, z nieco wyższym maksimum.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-01-21, Michoo <m...@v...pl> wrote:
> On 20.01.2013 22:45, PK wrote:
>> Wyobraźmy sobie hipotetycznie, że w firmie pojawia się zupełnie kluczowe
>> zadanie, którego nie chce się podjąć żaden pracownik.
>> Np. masz zespół "Stachów K." gapiących się w Vima, a trzeba coś zrobić
>> w Visual Studio. Wszystkie Stachy mówią, że nie i już. Przeżyją brak
>> premii - zarabiają nieźle i nie będą się płaszczyć przed jakimś IDE
>> od Gatesa!
>
> Bardzo dziwnie sobie dobrałeś pracowników ;) "Stado Stachów K." nie
> nadaje się na koderów, co powinieneś był zauważyć dużo, dużo wcześniej
> wcześniej. Ktoś, kto ich zatrudnił powinien wylecieć z HR.

Michoo, przesadzasz. "Stado Stachów K." nie jest głupie i nie pakuje się
w robotę, którą będzie rzygać już za kwartał.

--
Secunia non olet.
Stanislaw Klekot

do góry