Witam,

[..]
> Ależ ja korzystam. Ale najpierw podcinam gardło :))) Za grzebanie w nie
> swoim kodzie. A kompozycja (format) kodu, to temat - morze. Jeden lubi
> nawiasy w osobnej linii, a inny w tej samej.
[..]

Sry, ale od tego to chyba jest coding standard wypracowany w teamie,
firmie lub wraz z klientem. O to chyba biega zeby burdelu nie bylo?

>> Nad takim zespołem często też czuwa ktoś(tu chodzi o poszczególne
>> aplikacje), kto kontroluje co gdzie i kiedy było zrobione i se zapisuje
>> co
>> w danej wersji aplikacji jest zrobione. A jak to u was wygląda, chętnie
>> się
>> dowiem.
>
> Moduły programu są ściśle podzielone z absolutnie minimalnym i
> niezmienialnym interfejsem pomiędzy nimi. Ja siedzę nad komunikacją z
> urządzeniami, kolega nad interfejsem użytkownika, jeszcze inny nad bazą,
> jeszcze inny nad interfejsami wymiany danych z innymi programami itp...
> każdy odpowiada za swój kawałek.

Oki ale jak rozwiazesz sytuacje gdy jeden modul jest nie do napisania przez
jedna osobe,
lub rownolegle masz delvelopment i maintenance? Wtedy ktos musi zagladac i
poprawiac
Twoj kod?

> Nad tym wszystkim stoi szef projektu, który określa:
> - interfejsy pomiędzy programistami (to tylko na samym początku projektu)
Czy to nie task dla architekta?

Oki, glownie dziwie sie "podcinaniu gardla".

Pozdro,
yig

do góry

On Nov 27, 10:10 am, glos <g...@p...onet.pl> wrote:
> On 27 Lis, 09:22, Herakles <h...@b...pl> wrote:
>
>
>
> > 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. Kilka postów temu została wysnuta teoria, z którą się nie
> > zgadzam w żadnym aspekcie, a mianowicie:
>
> > > Skąd taki pomysł, żeby dobry inżynier zostawał, w imię "awansu",
> > > kiepskim kierownikiem?
>
> > Wynikałoby z tego, że dobry inżynier nie powinien budować całego samolotu, a
> > jedynie hamulec. A dokładniej pomagać przy budowie hamulca. Bo tam też
> > będzie szef budowy hamulca i kilku młodych którzy mu będą pomagać.
>
> > W odniesieniu do programowania, nie jest sztuką zakodować coś, sztuką jest
> > to zaprojektować, a następnie przeciągnąć projekt w satysfakcjonująco
> > krótkim czasie do końca tak, żeby był zrobiony porządnie. A tego z reguły
> > się nie da samemu nie rozciągając tego w czasie, natomiast mając zespół
> > ludzi, którzy pomagają w realizacji projektu robota idzie kilka razy
> > szybciej.
>
> > Kolejnym aspektem jest to, że kierowanie projektem wcale nie wyklucza się z
> > byciem programistą, podobnie jak z tym samolotem i jego hamulcem.
>
> czym innym jest sytuacja, w ktorej senior developer pelni funkcje
> mentora na juniorow, a czym innym - gdy zabiera sie za managerowanie.

Chyba mylisz szefa projektu z pracownica HRu.

> W pierwszym przypadku jego wiedza i umiejetnosci sa wykorzystywane
> sensownie (o ile umie i chce przekazywac wiedze), w drugim - startuje
> zupelnie od podstaw w nowej dla niego dziedzinie ("gdzie znajde
> javadoca do tego gantta?").

A gdzie ty informatyke studiowales, ze nie miales nic o zarzadzaniu
projektami?

do góry

> Fajny tekst, ale nie tłumaczy, dlaczego powszechnie uważa się, że bycie
> kierownikiem jest bardziej ambitnym zadaniem, niż programistą.

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?

Pozdrav,
yig

do góry

On 28 Lis, 17:18, Bart Ogryczak <B...@g...com> wrote:
> > > Kolejnym aspektem jest to, że kierowanie projektem wcale nie wyklucza się z
> > > byciem programistą, podobnie jak z tym samolotem i jego hamulcem.
>
> > czym innym jest sytuacja, w ktorej senior developer pelni funkcje
> > mentora na juniorow, a czym innym - gdy zabiera sie za managerowanie.
>
> Chyba mylisz szefa projektu z pracownica HRu.

ja? chyba dosyc pobieznie przeczytales zarowno moja wypowiedz, jak i
te, do ktorych sie odnioslem.

> > W pierwszym przypadku jego wiedza i umiejetnosci sa wykorzystywane
> > sensownie (o ile umie i chce przekazywac wiedze), w drugim - startuje
> > zupelnie od podstaw w nowej dla niego dziedzinie ("gdzie znajde
> > javadoca do tego gantta?").
>
> A gdzie ty informatyke studiowales, ze nie miales nic o zarzadzaniu
> projektami?

ja mialem.

Ale osoby lekkomyslnie rzucajace teoriami, jak to programista moze z
powodzeniem programowac i do tego zarzadzac projektem - najwyrazniej
nie. Z wielu powodow, z ktorych sprzecznosc interesow developera i
managera jest najbardziej oczywista.

--

Pozdrawiam,

glos

do góry

O czasie 2007-11-27 10:10, taki ktos jak glos napisac raczyl:
> [...]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). Praca
> programisty nie przygotowuje tez do pelnienia funkcji "dwustronnego
> zderzaka", a tym de facto jest manager.

Pozwolę sobie się nie zgodzić, w dodatku - zdecydowanie.

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
- łatwość zmanipulowania.
- .... vide www.dilbert.com

Owszem, solidny i dobry manager bez doświadczenia jako programista ma
świadomość swojej niewiedzy i pozwoli się ludziom w sensownym zakresie
samoorganizować. W praktyce jednak często jest inaczej - miałem
nieszczęście użerania się z takim laikiem i nie życzę tego nikomu.

Pozdrawiam,
Waldek

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?


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

do góry

On 28 Lis, 22:02, "Waldek M." <w...@l...localdomain> wrote:
> O czasie 2007-11-27 10:10, taki ktos jak glos napisac raczyl:
>
> > [...]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). Praca
> > programisty nie przygotowuje tez do pelnienia funkcji "dwustronnego
> > zderzaka", a tym de facto jest manager.
>
> Pozwolę sobie się nie zgodzić, w dodatku - zdecydowanie.
>
> 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
> - łatwość zmanipulowania.
> - .... videwww.dilbert.com
>
> Owszem, solidny i dobry manager bez doświadczenia jako programista ma
> świadomość swojej niewiedzy i pozwoli się ludziom w sensownym zakresie
> samoorganizować. W praktyce jednak często jest inaczej - miałem
> nieszczęście użerania się z takim laikiem i nie życzę tego nikomu.
>

czy Ty masz jakiekolwiek pojecie jakie sa zadania PM'a? Co to jest
budzet projektu i w jaki sposob powstaje? Co to jest i po co jest
harmonogramowanie? I czy slyszales kiedys termin "good enough"?

Na koniec - zastanow sie, jaki jest cel projektu i kto za ten projekt
placi.

Na koniec zastanow sie, czy zaakceptujesz sytuacje, w ktorej po
wynajeciu ekipy do remontu mieszkania i rozgrzebaniu dokumentnym
wszystkiego, uslyszysz od nich, ze masz sie od nich teraz uprzejmie
odp*przyc, beda pracowac jak sami uwazaja, wynik ich pracy bedzie taki
jak sami uznaja za stosowne (bo oni sie znaja), a remont zostanie
skonczony wtedy, kiedy zostanie skonczony, przy czym placisz im
oczywiscie od dniowki. Wczesniejsze zas uzgodnione z nimi harmonogramy
mozesz sobie wsadzic.

--

Pozdrawiam,

glos

do góry

O czasie 2007-11-28 22:09, taki ktos jak Any User napisac raczyl:
> Ja mam jedno pytanie. Tylko jedno.
>
> Po co się robi projekty informatyczne (czy projekty w ogóle) - jaki jest
> cel, niekoniecznie ten bezpośredni?

Spodziewałem się Twojego zainteresowania. Tak, oczywiście że dla
zysku. Tylko, że dobry manager widzi na tyle daleko, żeby zapewnić
długodystansowy zysk przy minimalnych długodystansowych kosztach.
Jeśli ktoś chce jak najwięcej wydusić "na teraz" - może liczyć się
z tym, że za rok - dwa nie będzie już miał z kogo wyduszać, bo pozbędzie
się i klientów, i pracowników.

Pozdrawiam,
Waldek

do góry

O czasie 2007-11-28 22:25, taki ktos jak glos napisac raczyl:
> czy Ty masz jakiekolwiek pojecie jakie sa zadania PM'a? Co to jest
> budzet projektu i w jaki sposob powstaje? Co to jest i po co jest
> harmonogramowanie? I czy slyszales kiedys termin "good enough"?

> Na koniec - zastanow sie, jaki jest cel projektu i kto za ten projekt
> placi.

A wyobraź sobie, że wiem - i to raczej niemało :-)

> Na koniec zastanow sie, czy zaakceptujesz sytuacje, w ktorej po
> wynajeciu ekipy do remontu mieszkania i rozgrzebaniu dokumentnym
> wszystkiego, uslyszysz od nich, ze masz sie od nich teraz uprzejmie
> odp*przyc, beda pracowac jak sami uwazaja, wynik ich pracy bedzie taki
> jak sami uznaja za stosowne (bo oni sie znaja), a remont zostanie
> skonczony wtedy, kiedy zostanie skonczony, przy czym placisz im
> oczywiscie od dniowki. Wczesniejsze zas uzgodnione z nimi harmonogramy
> mozesz sobie wsadzic.

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".
Potem odpowiedz sobie na pytania:
- Czy kiedy właściciel przyjdzie odebrać taki "remont" - będzie
Ci wdzięczny i zapłaci za wykonane dzieło?
- Co pomyślą sobie i co zrobią wykonawcy, których zmusiłeś do spełnienia
Twojego "widzimisię", za które potem nie dostaną zapłaty? A jeśli
nawet dostaną, to kto będzie tak głupi, żeby zlecić takiej
ekipie następny remont?

Jasne, sytuacja wyolbrzymiona. Ale dlatego właśnie uważam, że kierownik
projektu powinien mieć jakieś doświadczenie techniczne, żeby ocenić
konsekwencje swoich decyzji i żeby ani nie dać się wpuścić swoim
podwładnym w maliny (równie częsta sytuacja), ani nie torpedować
projektu głupimi decyzjami w sprawach technicznych, jednak oderwanymi od
technicznych realiów.

Cytując jeszcze Ciebie:
> wynik ich pracy bedzie taki jak sami uznaja za stosowne (bo oni sie
> znaja)

Również właśnie dlatego kierownik powinien "się znać" - aby nie dać
sobie wmówić bzdur.

Uff... ale mam wrażenie, że bardzo, bardzo daleko zboczyliśmy
z tematu wątku.

Pozdrawiam,
Waldek

do góry

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ę...

--
Paweł Goleń
mailto:p...@k...onet.pl
"Wszyscy przecież wiemy, że nikt nie dostaje żadnych spamów" - mój trol
UGVybCBTVUNLUw==

do góry