O czasie 2007-11-29 10:01, taki ktos jak glos napisac raczyl:
> Kwestionuje laczenie funkcji managerskich z technicznymi, a nie sprawe
> backgroundu technicznego (lub jego braku) u managera - choc to rowniez
> sprawa dyskusyjna. Imo manager powinien byc specjalista od
> zarzadzania, a od spraw technicznych powinien miec zaufanych
> ekspertow. Dobrze jest, oczywiscie, jesli pojecie o przedmiocie
> posiada, ale nie powinny go interesowac szczegoly.

No, no - przeczysz teraz sobie :-)

"Tak sie bowiem sklada, ze manager
potrzebuje calkowicie innych umiejetnosci niz projektant/programista i
*wczesniejszy background techniczny* czesto moze wylacznie szkodzic (np
dostosowywanie harmonogramu projektu do "fajnej" biblioteki). "

To z kolei Twój post z 10:10, 27 listopada.

Ale wnioskuję z tego, że jednak się - przynajmniej częściowo - zgadzamy.

Pozdrawiam,
Waldek

do góry

On 30 Lis, 07:58, Herakles <h...@b...pl> wrote:
> glos wrote:
> > Zacznij pracowac przy projekcie wartym x mln zl/usd/eur, to
> > zrozumiesz.
>
> Widzę, że Ci wbili do głowy, że projekt warty jest ileś mln i zadowolony
> jesteś, że przy nim pracujesz, a twoje zadowolenie mierzy się według
> jednego parametru jakim jest budżet projektu.

Easy.
"glos" nie wydaje sie byc z takich, ktorym cos "wbili do glowy" i jak
sie im pokaze zagadnienie od innej strony to przejrzy na oczy. Z
pewnoscia slyszal juz on nie raz to wszystko co napisales, ale ten
punkt widzenia w dyskusji z calym szacunkiem zignoruje. A powody, dla
ktorych tak jest nierozerwalnie wiaza sie z biznesem.

pozdrawiam,
Marcin Stefaniak

do góry

On 30 Lis, 19:03, "Waldek M." <w...@l...localdomain> wrote:
> > Kwestionuje laczenie funkcji managerskich z technicznymi, a nie sprawe
> > backgroundu technicznego (lub jego braku) u managera - choc to rowniez
> > sprawa dyskusyjna. Imo manager powinien byc specjalista od
> > zarzadzania, a od spraw technicznych powinien miec zaufanych
> > ekspertow. Dobrze jest, oczywiscie, jesli pojecie o przedmiocie
> > posiada, ale nie powinny go interesowac szczegoly.
>
> No, no - przeczysz teraz sobie :-)

a gdzie dostrzegles sprzecznosc? Ja jej nie widze.

>
> "Tak sie bowiem sklada, ze manager
> potrzebuje calkowicie innych umiejetnosci niz projektant/programista i
> *wczesniejszy background techniczny* czesto moze wylacznie szkodzic (np
> dostosowywanie harmonogramu projektu do "fajnej" biblioteki). "
>
> To z kolei Twój post z 10:10, 27 listopada.
>
> Ale wnioskuję z tego, że jednak się - przynajmniej częściowo - zgadzamy.

jak slusznie zauwazyles, tylko czesciowo ;)

--

Pozdrawiam,

glos

do góry

On 30 Lis, 15:40, "PawelW" <p...@a...pl> wrote:
> > Ja mam jedno pytanie. Tylko jedno.
>
> > Po co się robi projekty informatyczne (czy projekty w ogóle) - jaki jest
> > cel, niekoniecznie ten bezpośredni?
>
> Wiesz to jest ciekawe pytanie ponieważ zależnie komu je zadasz otrzymasz inną
> odpowiedź.

w przypadku wiekszosci osob bedzie ona bledna, odzwierciedlajac w ten
sposob jedynie podrzedna role tych osob w projekcie.

> Wiadomo ,że z punktu widzenia klienta projekt informatyczny zakończy
> się sukcesem jeśli otrzyma doskonały produkt przy minimalnym koszcie , dostawca
> osiągnie sukces jeśli dostrczy na tyle dobry produkt który zapewni mu
> ciągłagłość zleceń, reklamę , markę itd. i jednocześnie otrzyma za to jak
> największe wynagrodzenie, zaś dla pracownika projekt końćzy sie sukcesem gdy
> otrzyma swoje maksymalne wynagrodzenie ,rozwinie własne umiejętności i wzbogaci
> swoje referencje.

daruj, ale nie sa cele. To sa srodki.

> Generalnie każdy dąży do zmaksymalizowania swojego zysku

Bingo! To jest wlasnie cel kazdego przedsiewziecia biznesowego -
sklepu warzywnego, linii lotniczej, prywatnej uczelni i projektu
informatycznego.

--

Pozdrawiam,

glos

do góry

On 30 Lis, 19:21, matmis <m...@g...com> wrote:
> Easy.
> "glos" nie wydaje sie byc z takich, ktorym cos "wbili do glowy" i jak
> sie im pokaze zagadnienie od innej strony to przejrzy na oczy. Z
> pewnoscia slyszal juz on nie raz to wszystko co napisales, ale ten
> punkt widzenia w dyskusji z calym szacunkiem zignoruje. A powody, dla
> ktorych tak jest nierozerwalnie wiaza sie z biznesem.
>

hmmm.... Prorok jaki czy co? ;)

--

Pozdrawiam,

glos

do góry

Herakles na pl.praca.dyskusje:
>
> Może i macie rację, natomiast ja uważam, że dobry inżynier powinien
> nadzorować pracę młodych inżynierów, mających zadatki na dobrych
> inżynierów. Dzięki takiej formule i odpowiednim zaangażowaniu Ci młodzi
> inżynierowie uczą się jak być dobrym inżynierem, a dodatkowo ich
> młodzieńcza i pełna kiepskich pomysłów praca w skonfrontowaniem z wielkim
> doświadczeniem dobrego inżyniera daje efekty pracy właśnie dobrego
> inżyniera.

tylko, że kierownik a mentor to trochę różne sprawy.
A jeszcze inną kwestią jest menager vs team leader (czytaj: facet który
jest, jak to Paweł Goleń obok ujął, ekspertem od danej tematyki, z
wieszym doświadczeniem i jego rolą jes tmerytoryczne prowadzenie
projektu, itp).


> Kolejnym aspektem jest to, że kierowanie projektem wcale nie wyklucza się z
> byciem programistą, podobnie jak z tym samolotem i jego hamulcem.

częściowo wyklucza. To znaczy bardzo utrudnia robienie obu rzeczy naraz
równolegle. Im głębiej w las tym więcej drzew a mniej lasu :). Są ludzie
którzy potrafią znaleźć dobry balans między szczegółówością pracy kodera
i ogólnością architekta i/lub managera zespołu programistów. Ale to
wyjątki.

--
Ziemek

do góry

> On 30 Lis, 15:40, "PawelW" <p...@a...pl> wrote:
> > > Ja mam jedno pytanie. Tylko jedno.
> >
> > > Po co się robi projekty informatyczne (czy projekty w ogóle) - jaki jest
> > > cel, niekoniecznie ten bezpośredni?
> >
> > Wiesz to jest ciekawe pytanie ponieważ zależnie komu je zadasz otrzymasz inną
> > odpowiedź.
>
> w przypadku wiekszosci osob bedzie ona bledna, odzwierciedlajac w ten
> sposob jedynie podrzedna role tych osob w projekcie.

Wiesz można by rzec iż owa odpowiedź będzie jak najbardziej poprawna z punktu
widzenia osoby ,która ci odpowie. W ogłoszeniach(przynajmniej w większości)
pracodawcy nie napiszą ,że dają pracownikowi szansę zmaksymalizowania zysku
owego pracodawcy czy klienta ,ale raczej odwołają się do jego subiektywnych
celów jakim jest wysoka pensja, możliwość rozwoju i tym podobne. Ostatnio
pojawia się coraz więcej koncepcji typu "Humanistyczna inżynieria
oprogramowania" , które pragną zauważać ludzi tworzących produkt w ramach danego
projektu informatycznego jako jedną z integralnych części. Mam skromną nadzieję
iż pewnego dnia przestaną być po prostu ciekawostkami.
Na pytanie ,"Po co się robi projekty informatyczne" , można więc odpowiedzieć
,że by dostarczyć klientowi produkt z którego będzie zadowolony , można również
odpowiedzieć że po to aby dostarczyć klientowi produkt z którego będzie
zadowolony maksymalizując swój zysk jako właściciela firmy-dostawcy a można
równie dobrze odpowiedzieć ,że po to aby obydwie strony (wliczając w to
wszystkich pracowników) były zadowolone z osiagniętego celu.

Jak już wspominałem jest to moja osobista opinia.

> > Wiadomo ,że z punktu widzenia klienta projekt informatyczny zakończy
> > się sukcesem jeśli otrzyma doskonały produkt przy minimalnym koszcie , dostawca
> > osiągnie sukces jeśli dostrczy na tyle dobry produkt który zapewni mu
> > ciągłość zleceń, reklamę , markę itd. i jednocześnie otrzyma za to jak
> > największe wynagrodzenie, zaś dla pracownika projekt końćzy sie sukcesem gdy
> > otrzyma swoje maksymalne wynagrodzenie ,rozwinie własne umiejętności i wzbogaci
> > swoje referencje.
>
> daruj, ale nie sa cele. To sa srodki.

Z pewnego punktu widzenia masz rację ale to co dla jednej strony jest środkiem
dla innej może być celem i vice versa.

> > Generalnie każdy dąży do zmaksymalizowania swojego zysku
>
> Bingo! To jest wlasnie cel kazdego przedsiewziecia biznesowego -
> sklepu warzywnego, linii lotniczej, prywatnej uczelni i projektu
> informatycznego.

Zgadza się

> --
>
> Pozdrawiam,
>
> glos
>
>
>


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On 1 Gru, 17:55, "PawelW" <p...@a...pl> wrote:
> > w przypadku wiekszosci osob bedzie ona bledna, odzwierciedlajac w ten
> > sposob jedynie podrzedna role tych osob w projekcie.
>
> Wiesz można by rzec iż owa odpowiedź będzie jak najbardziej poprawna z punktu
> widzenia osoby ,która ci odpowie. W ogłoszeniach(przynajmniej w większości)
> pracodawcy nie napiszą ,że dają pracownikowi szansę zmaksymalizowania zysku
> owego pracodawcy czy klienta ,ale raczej odwołają się do jego subiektywnych
> celów jakim jest wysoka pensja, możliwość rozwoju i tym podobne. Ostatnio
> pojawia się coraz więcej koncepcji typu "Humanistyczna inżynieria
> oprogramowania" , które pragną zauważać ludzi tworzących produkt w ramach danego
> projektu informatycznego jako jedną z integralnych części.

Ich celem jest powiekszenie produktywnosci pracownikow, poprzez
wyzwolenie ich pelnego potencjalu, a przez to maksymalizacja zysku
firmy. (np http://www.gazeta-it.pl/2,16,16,index.html, sekcja
'Korzysci' punkt 2). Korzysc pracownikow jest niejako zamierzonym
efektem ubocznym.

Jesli naukowcy pewnego dnia odkryja, ze chodzenie nago po firmie
powoduje 7.3% wzrost wydajnosci, to wkrotce niektore firmy beda
zachecac do naturyzmu, a niektore wrecz wprowadza nowy wzor "uniformu
sluzbowego" - i nie sadzisz chyba, ze bedzie sie tak dzialo z
altruistycznej potrzeby czynienia dobra przez prezesow tych firm?

> Z pewnego punktu widzenia masz rację ale to co dla jednej strony jest środkiem
> dla innej może być celem i vice versa.

Owszem. Tyle, ze dla projektu informatycznego najwazniejszy jest punkt
widzenia jego wlasciciela=sponsora, a dla niego ostatecznym celem
prowadzenia projektu jest maksymalizacja zysku. Zwiekszenie
wydajnosci, zmniejszenie strat, przestojow, itp itd - to (jak pisalem)
- tylko srodki, prowadzace do tego celu. A dlaczego najwazniejszy jest
punkt widzenia wlasciciela projektu? Bo to on finansuje projekt i w
jego rekach jest wladza dot. projektu.


--

Pozdrawiam,

glos

do góry

On 28 Lis, 21:18, "yig" <y...@o...pl> wrote:
> Moze to nasza polska smykalka do szpanu - wieksza wladza wieksza estyma...
>
> Normalna sciezka kariery dla programisty wydaje sie byc: zostac architektem.
>
> Z drugiej jednak strony architektow zazwyczaj wystarczy mniej niz pl-i do
> kontroli
> sporego projektu, wiec sila rzeczy stanowisko PL-a jest bardziej eksponowane
> do tego w/w element sumuje sie na wspomniane zjawisko.
>
> Ciekawe jaki sa inne powody?

to, ze kwalifikacje architekta sa bardzo latwo i szybko weryfikowane
przez programistow, a kwalifikacje PM ciezko zweryfikowac? Rozliczany
jest w koncu z efektow projektu, a na sukces projektu sklada sie nie
tylko jego praca...

--

Pozdrawiam,

glos

do góry