On 28 Lis, 23:12, Paweł Goleń <p...@k...onet.pl> wrote:
> Waldek M. wrote:
> > A Ty wyobraź sobie, że ktoś wynajął do remontu domu ekipę remontową,
> > a Ty jako kierownik ekipy - laik każesz im cyklinować sufity, malować
> > instalację elektryczną, tynkować boazerie, tapetować okna gazetami i
> > oklejać ściany brokatem. Na wszystkie pytania i obiekcje odpowiadasz,
> > że taka jest decyzja biznesowa, tak jest najtaniej i "good enough".
>
> Od tego, to są eksperci. Manager jest raczej od tego, by zarządzać.
> Zapewniać zasoby, kontrolować postępy. Staczać polityczne boje. Od spraw
> technicznych ma ekspertów i musi ich słuchać, bo inaczej rzeczywiście
> będzie cyklinowanie sufitów. A jeszcze gorsza jest sytuacja, jak
> managerem/kierownikiem projektu zostaje osoba będąca jednym z głównych
> "zasobów merytorycznych" i wykonawców przy okazji. Zaczyna nadzorować
> sam siebie. Po prostu miodzio. Że nagle pracuje na dwóch etatach już nie
> wspomnę...
>

napisales dokladnie to, co ja chcialem wlasnie napisac. Niewiele
zostalo do dodania - chyba tylko podkreslilbym ponownie, ze z natury
rzeczy interesy developerow i managera (jak rowniez klienta i
managera) sa sprzeczne - manager jest "kierownikiem budowy", z jednej
strony rozliczajacym bezposrednich wykonawcow z zuzycia zasobow i
nadzorujacym ich, z drugiej strony - jest rozliczany z postepow i
kosztow przez klienta. Absurdalne jest wiec pelnienie przez
bezposredniego wykonawce funkcji managera. Team/Tech Leadera - tak,
managera - zdecydowanie nie. Niestety, "techniczni" najczesciej nie
rozumieja tego, wydaje im sie, ze jakosc przede wszystkim, a reszte
"jakos sie zalatwi".

--

Pozdrawiam,

glos

do góry

O czasie 2007-11-29 07:26, taki ktos jak glos napisac raczyl:
> napisales dokladnie to, co ja chcialem wlasnie napisac. Niewiele
> zostalo do dodania - chyba tylko podkreslilbym ponownie, ze z natury
> rzeczy interesy developerow i managera (jak rowniez klienta i
> managera) sa sprzeczne - manager jest "kierownikiem budowy", z jednej
> strony rozliczajacym bezposrednich wykonawcow z zuzycia zasobow i
> nadzorujacym ich, z drugiej strony - jest rozliczany z postepow i
> kosztow przez klienta. Absurdalne jest wiec pelnienie przez
> bezposredniego wykonawce funkcji managera. Team/Tech Leadera - tak,
> managera - zdecydowanie nie. Niestety, "techniczni" najczesciej nie
> rozumieja tego, wydaje im sie, ze jakosc przede wszystkim, a reszte
> "jakos sie zalatwi".

No pięknie. Tylko ja dalej nie widzę, w czym managerowi ma przeszkadzać
doświadczenie techniczne. Ja widzę przynajmniej trzy zalety takiej
sytuacji:
- manager ma wyczucie, które z jego decyzji wysokopoziomowych
mogą mieć zbyt dużą szkodę dla projektu, a które może swobodnie
podejmować bez szkody
- manager jest w stanie zrozumieć, o czym mówią jego podwładni,
bo zna ich język
- co za tym idzie, jest w stanie ocenić przynajmniej ogólnie
ocenić postęp pracy i zrozumieć, czym zajmują się jego pracownicy;
ma też wyczucie, czy proponowany przez nich harmonogram jest
realistyczny.

Oczywiście, od samego początku piszemy o *doświadczeniu technicznym*
managera, a nie o łączeniu tej funkcji - nie wiem, skąd nagle
pojawił się ten temat :-)

Pozdrawiam,
Waldek

do góry

On 29 Lis, 08:17, "Waldek M." <w...@l...localdomain> wrote:

> No pięknie. Tylko ja dalej nie widzę, w czym managerowi ma przeszkadzać
> doświadczenie techniczne. Ja widzę przynajmniej trzy zalety takiej
> sytuacji:
> - manager ma wyczucie, które z jego decyzji wysokopoziomowych
> mogą mieć zbyt dużą szkodę dla projektu, a które może swobodnie
> podejmować bez szkody
> - manager jest w stanie zrozumieć, o czym mówią jego podwładni,
> bo zna ich język
> - co za tym idzie, jest w stanie ocenić przynajmniej ogólnie
> ocenić postęp pracy i zrozumieć, czym zajmują się jego pracownicy;
> ma też wyczucie, czy proponowany przez nich harmonogram jest
> realistyczny.
>
> Oczywiście, od samego początku piszemy o *doświadczeniu technicznym*
> managera, a nie o łączeniu tej funkcji - nie wiem, skąd nagle
> pojawił się ten temat :-)
>

bynajmniej - fragment postu Heraklesa z 27 Lis, 09:22, do ktorego sie
odnioslem:
"Kolejnym aspektem jest to, że kierowanie projektem wcale nie wyklucza
się z
byciem programistą, podobnie jak z tym samolotem i jego hamulcem. "

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.

Skadinad - tak samo, jak dyrektorem szpitala nie powinien byc lekarz,
dyrektorem szkoly - nauczyciel, dyrektorem firmy softwareowej -
programista, a - w kazdym przypadku - specjalista od zarzadzania.
Inaczej - konczy sie to zwykle nieciekawie - upadkiem firmy albo - w
przypadku firm panstwowych - wpadaniem w gigantyczne dlugi.

--

Pozdrawiam,

glos

do góry

> Kwestionuje laczenie funkcji managerskich z technicznymi, a nie sprawe
Skoro programista(a w szczególności projektant) musi być:
1) Księgowym(bo jak napisze/zaprojektuje program księgowy). Rozwinę ten
punkt. To nie księgowy liczy słupki tylko programista a dokładniej jego
program.
2) Agentem nieruchomości.
3) Magazynierem.
4) Fakturzystą.
5) Handlowcem.
6) Szefem produkcji(w kwestii wyjaśnień, to program programisty planuje
produkcje).
7) Chyba wszystkie zawody można tu wymienić, przy których pracuje się na
komputerze.

To skąd to przekonanie, że nie może być dobrym managerem, a do tego sobie w
wolnym od managerowania czasie jeszcze poprogramować?

Obalam teorię!

do góry

On 29 Lis, 10:27, Herakles <h...@b...pl> wrote:
> > Kwestionuje laczenie funkcji managerskich z technicznymi, a nie sprawe
>
> Skoro programista(a w szczególności projektant) musi być:
> 1) Księgowym(bo jak napisze/zaprojektuje program księgowy). Rozwinę ten
> punkt. To nie księgowy liczy słupki tylko programista a dokładniej jego
> program.
> 2) Agentem nieruchomości.
> 3) Magazynierem.
> 4) Fakturzystą.
> 5) Handlowcem.
> 6) Szefem produkcji(w kwestii wyjaśnień, to program programisty planuje
> produkcje).
> 7) Chyba wszystkie zawody można tu wymienić, przy których pracuje się na
> komputerze.

Pomylily Ci sie role w projekcie.

Analitycy (biznesowy i systemowy) poznaja merytoryke systemu i
przeklada je na zalozenia, architekt i projektant na podstawie zalozen
tworza projekt. Programista tworzy kod, majac z gory zdefiniowane
efekty. Jako dokumentacja i podstawa do prac sluzy (rosnacy) projekt,
zwykle w UML.

Gdzie wiec potrzeba, zeby programista interesowal sie biznesowa strona
przedsiewziecia? Tylko w malutkich firmach i u freelancerow, gdzie
wszystkie w/w opisane role (i pare innych na dokladke) pelni jeden
czlowiek.

> To skąd to przekonanie, że nie może być dobrym managerem, a do tego sobie w
> wolnym od managerowania czasie jeszcze poprogramować?

przykro mi, ale po prostu nie masz elementarnego pojecia o temacie.
Rownie dobrze moglbys sugerowac, zeby architekt (w sensie tradycyjnym)
w czasie wolnym od tworzenia projektow, nosil cegly i mieszal cement
na budowie.

Zacznij pracowac przy projekcie wartym x mln zl/usd/eur, to
zrozumiesz.

> Obalam teorię!

nic podobnego.

--

Pozdrawiam,

glos

do góry

> Pomylily Ci sie role w projekcie.
>
> Analitycy (biznesowy i systemowy) poznaja merytoryke systemu i
> przeklada je na zalozenia, architekt i projektant na podstawie zalozen
> tworza projekt. Programista tworzy kod, majac z gory zdefiniowane
> efekty. Jako dokumentacja i podstawa do prac sluzy (rosnacy) projekt,
> zwykle w UML.
>
> Gdzie wiec potrzeba, zeby programista interesowal sie biznesowa strona
> przedsiewziecia? Tylko w malutkich firmach i u freelancerow, gdzie
> wszystkie w/w opisane role (i pare innych na dokladke) pelni jeden
> czlowiek.

Np. jedno z większych towarzystw ubezpieczeniowych na świecie, a
konkretnie jego miejscowy oddział w moim rodzinnym mieście, zawsze
preferowało programistów (VBA+Excel+Access+PHP+MySQL), którzy znali
tematykę ubezpieczeniową, a najlepiej po prostu posiadali certyfikat
PUNU. Tacy po prostu najbardziej byli w stanie wczuć się w tworzone
projekty.


--
Czy każdy powinien mieć prawo głosu w wyborach?
http://pracownik.blogspot.com

do góry

On 29 Lis, 12:16, Any User <u...@a...pl> wrote:

> Np. jedno z większych towarzystw ubezpieczeniowych na świecie, a
> konkretnie jego miejscowy oddział w moim rodzinnym mieście, zawsze
> preferowało programistów (VBA+Excel+Access+PHP+MySQL), którzy znali
> tematykę ubezpieczeniową, a najlepiej po prostu posiadali certyfikat
> PUNU. Tacy po prostu najbardziej byli w stanie wczuć się w tworzone
> projekty.

A zdajesz sobie sprawe, ze "lokalny informatyk" niewiele ma do
powiedzenia w sprawie firmowej IT? Jest od pisania makr w Excelu i
drobnych pomocniczych lokalnych baz danych, dublujacych oficjalny
system, jesli przechowuja istotne biznesowo dane. Caly core'owy
personel IT pracuje zawsze w centrali, a departament/dzial IT podlega
bezposrednio pod zarzad (prezesa/wiceprezesa), bez jakichkolwiek
zaleznosci sluzbowych od oddzialow lokalnych. Podobnie jest w bankach.
Tego typu firmy nie moga sobie po prostu pozwolic na brak kontroli nad
podstawowym "narzedziem pracy".

--

Pozdrawiam,

glos

do góry

glos wrote:

> On 29 Lis, 10:27, Herakles <h...@b...pl> wrote:
>> > Kwestionuje laczenie funkcji managerskich z technicznymi, a nie sprawe
>>
>> Skoro programista(a w szczególności projektant) musi być:
>> 1) Księgowym(bo jak napisze/zaprojektuje program księgowy). Rozwinę ten
>> punkt. To nie księgowy liczy słupki tylko programista a dokładniej jego
>> program.
>> 2) Agentem nieruchomości.
>> 3) Magazynierem.
>> 4) Fakturzystą.
>> 5) Handlowcem.
>> 6) Szefem produkcji(w kwestii wyjaśnień, to program programisty planuje
>> produkcje).
>> 7) Chyba wszystkie zawody można tu wymienić, przy których pracuje się na
>> komputerze.
>
> Pomylily Ci sie role w projekcie.
>
> Analitycy (biznesowy i systemowy) poznaja merytoryke systemu i
> przeklada je na zalozenia, architekt i projektant na podstawie zalozen
> tworza projekt. Programista tworzy kod, majac z gory zdefiniowane
> efekty. Jako dokumentacja i podstawa do prac sluzy (rosnacy) projekt,
> zwykle w UML.
>
> Gdzie wiec potrzeba, zeby programista interesowal sie biznesowa strona
> przedsiewziecia? Tylko w malutkich firmach i u freelancerow, gdzie
> wszystkie w/w opisane role (i pare innych na dokladke) pelni jeden
> czlowiek.
>
>> To skąd to przekonanie, że nie może być dobrym managerem, a do tego sobie
>> w wolnym od managerowania czasie jeszcze poprogramować?
>
> przykro mi, ale po prostu nie masz elementarnego pojecia o temacie.
> Rownie dobrze moglbys sugerowac, zeby architekt (w sensie tradycyjnym)
> w czasie wolnym od tworzenia projektow, nosil cegly i mieszal cement
> na budowie.
>
> 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. Otóż mylisz się sromotnie,
standard tworzenia projektów, nie zależy od jego budżetu, tylko od innych
czynników. Nikt nie będzie szczegółowo dokumentował małej aplikacji nawet
za te x mln, tylko dlatego, że ma duży budżet, tym bardziej jeśli jest to
jakaś pierdoła nie wpływająca na działanie firmy, natomiast jak aplikacja
ma duży wpływ na funkcjonowanie przedsiębiorstwa to nawet jeśli kosztuje
dużo mniej i tak będzie szczegółowo udokumentowana. A to o czym piszesz to
jest właśnie ta struktura:
Architekt/projektant/szef projektu - sztucznie rozbicie jednego stanowiska,
po to, żeby zapewnić chłopakom jakąś ścieżkę rozwoju, no i dlatego, że
jeden się może nie wyrabiać, do tego jest to dublowanie stanowisk.
Analityk, to jest po prostu praca z klientem, który nie wie czego chce.
Zazwyczaj duzi klienci sami mają swoich Analityków byznesowych i oni
doskonale wiedzą czego chcą i czego firma potrzebuje. Więc stanowisko jest
zbędne, oczywiście można zatrudnić kogoś żeby efekty rozmowy zapisał na
karteluszkach, ale nie zawsze jest po co.
Pomyśl jak to ładnie brzmi: "Awansowałem na Architekta Aplikacji", kurde
normalnie sama propaganda ha ha, chodzi o to, żebyś czuł się psychicznie
dobrze i lepszy od innych, sam się posłuchaj: "Zacznij pracowac przy
projekcie wartym x mln..." nie widzisz tu tej psychologii?
Często ludziom dają stanowisko "manager czegoś tam" co z menagerką nie ma
nic wspólnego, do tego dają tam człowieka emocjonalnego, który na managera
by się nigdy nie nadał, no ale stanowisko jest, człowiek jest zmotywowany,
więc lepiej pracuje, proste jak drut.
Aha pisałem kiedyś UMLe i jakbym miał pod to klepać kod, to bym się chyba
popłakał. To rzeczywiście jak zasuwanie na budowie z workiem cementu, a
może i gorzej, tyle tylko, że mięśnie nie bolą i kasa lepsza, ale
satysfakcji nie maił bym żadnej?



>
>> Obalam teorię!
>
> nic podobnego.
>
> --
>
> Pozdrawiam,
>
> glos

do góry

On 30 Lis, 07:58, Herakles <h...@b...pl> wrote:
> > przykro mi, ale po prostu nie masz elementarnego pojecia o temacie.
> > Rownie dobrze moglbys sugerowac, zeby architekt (w sensie tradycyjnym)
> > w czasie wolnym od tworzenia projektow, nosil cegly i mieszal cement
> > na budowie.
>
> > 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. Otóż mylisz się sromotnie,
> standard tworzenia projektów, nie zależy od jego budżetu, tylko od innych
> czynników. Nikt nie będzie szczegółowo dokumentował małej aplikacji nawet
> za te x mln, tylko dlatego, że ma duży budżet, tym bardziej jeśli jest to
> jakaś pierdoła nie wpływająca na działanie firmy, natomiast jak aplikacja
> ma duży wpływ na funkcjonowanie przedsiębiorstwa to nawet jeśli kosztuje
> dużo mniej i tak będzie szczegółowo udokumentowana. A to o czym piszesz to
> jest właśnie ta struktura:
> Architekt/projektant/szef projektu - sztucznie rozbicie jednego stanowiska,
> po to, żeby zapewnić chłopakom jakąś ścieżkę rozwoju, no i dlatego, że
> jeden się może nie wyrabiać, do tego jest to dublowanie stanowisk.
> Analityk, to jest po prostu praca z klientem, który nie wie czego chce.
> Zazwyczaj duzi klienci sami mają swoich Analityków byznesowych i oni
> doskonale wiedzą czego chcą i czego firma potrzebuje. Więc stanowisko jest
> zbędne, oczywiście można zatrudnić kogoś żeby efekty rozmowy zapisał na
> karteluszkach, ale nie zawsze jest po co.
> Pomyśl jak to ładnie brzmi: "Awansowałem na Architekta Aplikacji", kurde
> normalnie sama propaganda ha ha, chodzi o to, żebyś czuł się psychicznie
> dobrze i lepszy od innych, sam się posłuchaj: "Zacznij pracowac przy
> projekcie wartym x mln..." nie widzisz tu tej psychologii?
> Często ludziom dają stanowisko "manager czegoś tam" co z menagerką nie ma
> nic wspólnego, do tego dają tam człowieka emocjonalnego, który na managera
> by się nigdy nie nadał, no ale stanowisko jest, człowiek jest zmotywowany,
> więc lepiej pracuje, proste jak drut.
> Aha pisałem kiedyś UMLe i jakbym miał pod to klepać kod, to bym się chyba
> popłakał. To rzeczywiście jak zasuwanie na budowie z workiem cementu, a
> może i gorzej, tyle tylko, że mięśnie nie bolą i kasa lepsza, ale
> satysfakcji nie maił bym żadnej?
>
>


przykro mi to pisac, ale znow pokazujesz, ze Twoje pojecie o
przedmiocie jest bardzo umiarkowane. Z calym szacunkiem, ale jestes
zywym dowodem, dlaczego nawet bardzo dobry programista, z wylacznie
technicznymi umiejetnosciami, nie powinien dotykac sie spraw
biznesowych w firmie.

Nie masz pojecia (zeby wziac tylko przykladowe):
- skad sie bierze budzet projektu i czego jest funkcja
- po co stworzono pojecie cyklu zycia projektu, jego fazy i metody
zarzadzania.
- po co rozdziela sie funkcje osob zaangazowanych w projekt i czym
roznia sie role od osob
- co to jest UML, po co go wymyslono i dlaczego sie go uzywa

Nie zamierzam Cie jednak edukowac. Podpowiem Ci jedynie, ze odpowiedzi
na wszystkie w/w pytanie nierozerwalnie wiaza sie z biznesem, a nie z
IT.

--

Pozdrawiam,

glos

do góry

> > Mnóstwo problemów w projektach wynika właśnie z tego, że manager
> > nie jest w stanie zrozumieć, czym zajmują się podlegające mu
> > zespoły programistów. Prowadzi to potem do błędnych decyzji
> > i postaw z rodzaju:
> > - "nie musimy poprawiać zbyt wielu błędów, skoro wszystko się jakoś
> > trzyma kupy"
> > - wyobrażenie, że skoro 1 osoba będzie coś robiła przez 10 dni,
> > to 10 osób zrobi to w dzień (a 100 w kwadrans)
> > - kierowanie się przede wszystkim kosztami
> > - niechęć do zmian
> > - ciągłe rotacje osób w projekcie i między projektami ("sztuka to
> > sztuka, każdy zasób ludzki będzie równie dobry na dowolnym stanowisku")
> > - przekonanie co do nieomylności "estymat"
> > - bezrefleksyjny wybór funkcjonalności, które mają zostać zaprogramowane
>
> 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ź. 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.
Generalnie każdy dąży do zmaksymalizowania swojego zysku i jeśli słysze ,że ktoś
zatrudnia programistę za 1400 brutto to oznacza ,że jedna ze stron jest złym
negocjatorem gdyż mamy do czynienia z programistą ,który się nie ceni lub z
pracodawcą ,który zbytnio przedkłada koszty nad kompetencje pracowników.

oczywiscie to tylko moje skromne zdanie.


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

do góry