Pięknego dnia Tue, 1 Nov 2005 20:29:31 +0100, Dariusz Sznajder
<d...@b...tu.kielce.pl> zakodował:

>Dnia 01.11.2005 Kaizen <x...@c...sz> napisał/a:
>> motywowanie go), kontrolowanie postępu prac, zapewnienie zespołowi
>No, do tego: ^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
>to jednak pewna wiedza merytoryczna też się przydaje.

Do czego?
Zbierasz tylko informacje, czy prace są wykonywane zgodnie z
opracowanym przez zespół harmonogramem. Informacje na ten temat też
otrzymujesz od członków zespołu.
Jak sobie wyobrażasz, żeby PM sprawdzał postępy? W przypadku programu
komputerowego ma czytać kod programu? Sprawdzać ilość linii? Testować,
czy działa? To jest nierealne.
--
Pozdrawiam,
Kaizen x...@c...sz zanim zapytasz odwiedź www.google.com
GG 2122; ICQ#: 64457775 e-mail Rot13 coded
If you cannot make sth good, make it looking good. - Bill Gates

do góry

> > motywowanie go), kontrolowanie postępu prac, zapewnienie zespołowi
> No, do tego: ^^^^^^^^^^^^^^^^^^^^^^^^^^
> to jednak pewna wiedza merytoryczna też się przydaje.
>

Niekoniecznie. Zalatwiaja to odpowiednio uzgodnione, ustandaryzowane raporty
skladane okresowo przez projektantow, programistow, testerow, wdrozeniowcow,
przedstawicieli klienta itd w zaleznosci od charakteru projektu.
--
Jackare
Bytom

do góry

Dnia 01.11.2005 Kaizen <x...@c...sz> napisał/a:
>>> motywowanie go), kontrolowanie postępu prac, zapewnienie zespołowi
>>No, do tego: ^^^^^^^^^^^^^^^^^^^^^^^^^^
> [...]
>>to jednak pewna wiedza merytoryczna też się przydaje.
>
> Do czego?
> Zbierasz tylko informacje, czy prace są wykonywane zgodnie z
> opracowanym przez zespół harmonogramem. Informacje na ten temat też
> otrzymujesz od członków zespołu.
Do ułatwienia ww. zbierania. Wspólna baza pojęciowa (jak to już ktoś
gdzies w tym watku napisał) ułatwia po prostu komunikację.

--
Dariusz Sznajder
DSZ1-RIPE

do góry

> > > motywowanie go), kontrolowanie postępu prac, zapewnienie zespołowi
> > No, do tego: ^^^^^^^^^^^^^^^^^^^^^^^^^^
> > to jednak pewna wiedza merytoryczna też się przydaje.
> >
>
> Niekoniecznie. Zalatwiaja to odpowiednio uzgodnione, ustandaryzowane raporty
> skladane okresowo przez projektantow, programistow, testerow, wdrozeniowcow,
> przedstawicieli klienta itd w zaleznosci od charakteru projektu.

Z twoich wypowiedzi wynika, ze nie prowadziles zadnych (wiekszych niz
wdrozenie sklepu internetowego do sprzedazy papuzek) projektow. Nawet ksiazek
o nich nie czytales.

Opowiesz cos wiecej o 80/20? (Sledze nowosci i nie chce by mnie ominelo The
Next Big Thing, znaczy sie rewolucja IT z Bytomia rodem).

A.


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Pięknego dnia Tue, 1 Nov 2005 23:06:39 +0100, Dariusz Sznajder
<d...@b...tu.kielce.pl> zakodował:

>Do ułatwienia ww. zbierania. Wspólna baza pojęciowa (jak to już ktoś
>gdzies w tym watku napisał) ułatwia po prostu komunikację.

Dokładnie - to jest jedyne, do czego może przydać się znajomość
merytoryczna problemu. Ale czy żeby rozmawiać o piłce nożnej trzeba w
nią grać?
--
Pozdrawiam,
Kaizen x...@c...sz zanim zapytasz odwiedź www.google.com
GG 2122; ICQ#: 64457775 e-mail Rot13 coded
If you cannot make sth good, make it looking good. - Bill Gates

do góry

Nie rozumiecie o co chodzi z tym 80/20 ? Przecież to proste, PM uważa że
jego praca zajęła 80% czasu, choćby w tym czasie dubał w nosie przeglądając
strony xxx - więc mu się należy 80% kasy. No oczywiście można by jeszcze
wziąć poprawke na to że jego czas jest cenniejszy.....
A programowanie? Skoro on nie wie o co w tym chodzi to pewnie jest łatwizna
jak mówił szef Dilberta.

do góry

>
> Z twoich wypowiedzi wynika, ze nie prowadziles zadnych (wiekszych niz
> wdrozenie sklepu internetowego do sprzedazy papuzek) projektow. Nawet
ksiazek
> o nich nie czytales.
>
> Opowiesz cos wiecej o 80/20? (Sledze nowosci i nie chce by mnie ominelo
The
> Next Big Thing, znaczy sie rewolucja IT z Bytomia rodem).
>
W latach 2000-2002 kierowałem wdrożeniem systemu utrzymania sieci (System
informatyczny + system pomiarowy) przeznaczonego dla scentralizowanego biura
napraw TPSA objmującego 5 dawnych wojewodztw - w momencie startu ponad 1,5
mln abonentow. ( wdrożony w terminie i mieszczący się w budżecie + projekt i
wdrozenie nowych elementów nie przewidzianych w momencie startu projektu)

W 2001 r ten sam system - wdrozenie na mniejsza skale - na terenie jednego
województwa- ok 150 tys abonentow

Na przełomie 2001/2002 kierowałem logistyką dostaw sprzetu i oprogramowania
klienckiego w projekcie Komputerowego Systemu Paszportyzacji sieci (KSP) dla
TPSA toczącego się w 28 największych miastach Polski jednocześnie. Moja
część projektu zakończona przed czasem (w ciągu 3 dni dostarczono ponad 600
stacji roboczych, w ciągu kolejnego tygodnia zainstalowano 6 serwerów SUN
Fire 3800, zmieszczona w zaplanowanym budżecie).

Na przelomie 2003/2004 wdrozylem system FK/KP w jednym z warszawskich domow
towarowych (ponad 120 osób zatrudnionych, srednio księgowanych ok 600
dokumentów- nie operacji). Wdrożenie obejmowało instalacje sprzętu i softu,
migrację danych i integrację z istniejacym systemem magazynowymi oraz
systemami rozliczeniowymi

Plus kilka mniejszych systemów i kilka nieinformatycznych.

Do tego od 2001 roku kierowałem działem- najpierw produkcyjnym, potem
produkcyjno-wdrożeniowym.

Nie jestem zawodowym programistą - potrafię programować na podstawowym
poziomie- jakię wprawki ze studiów i proste rzeczy na własne potrzeby
(jakieś proste aplikacje w delphi, VB i accessie).

Podział prac 80/20 wynika z biznesowego punktu widzenia. Ktoś kto wykłada
pieniądze na projekt oczekuje konkretnych efektów w konkretnych terminach i
im więcej pracy zostanie poświęcone na planowanie prac, budżetu etc. tym
mniej nieprzewidzianych sytuacji nastąpi w trakcie realizacji. Samo
planowanie także oczywiście nie może trwać w nieskończoność (tu piję do
Twojego określenia "tyle ile potrzeba" ) bo za to także ktoś płaci i nie
zamierza płacić za proces który nie przynosi efektów w postaci realizacji.

Dobrze opracowany i rygorystycznie przestrzegany (łącznie ze zwalnianiem z
pracy za jego nieprzestrzeganie) proces raportowania i rozliczania
zaplanowanych efektów przynosi cuda. Cuda są oczywiście wspierane
odpowiednio satysfakcjonującym systemem wynagradzania (żeby się komuś nie
wydawało że to tylko terror). Wszystko albo prawie wszystko o czym
napisałem wynika z moich osobistych doświadczeń zebranych na stanowisku
kierownika projektów oraz kierownika działu w firmie rodem z Bytomia. Firma
zatrudniała od 10 na pocżatku do ponad 100 pracowników w szczytowym okresie.

Pozdrawiam
--
Jackare
Bytom

do góry

Jackare <j...@i...pl> napisał(a):

[ciach opisy]

No wiec dobra (jak sadze) rada: wypowiadajac swe zdanie nt prowadzenia
projektow informatycznych musisz doklejac nastepujacy disclaimer "to o czym
pisze dotyczy projektow wdrozeniowych". Wtedy unikniesz oskarzen o pieprzenie
bez sensu, bo tak sie sklada, ze "projekt informatyczny" czesciej dotyczy
czegos zupelnie innego - _tworzenia_ oprogramowania mianowicie.

>
> Podział prac 80/20 wynika z biznesowego punktu widzenia. Ktoś kto wykłada
> pieniądze na projekt oczekuje konkretnych efektów w konkretnych terminach i
> im więcej pracy zostanie poświęcone na planowanie prac, budżetu etc. tym
> mniej nieprzewidzianych sytuacji nastąpi w trakcie realizacji.

Moze tak jest we wdrozeniach. W kontekscie innych projektow informatycznych
to piramidalna bzdura.


A.

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

, bo tak sie sklada, ze "projekt informatyczny" czesciej dotyczy
> czegos zupelnie innego - _tworzenia_ oprogramowania mianowicie.
>
we wszystkich projektach w których uczestniczyłem i które prowadziłem było
tworzone oprogramowanie w całości lub w części i było to po prostu jedno z
zadań w projekcie podlegające zarzadzaniu przez kierownika całości projektu
i nie traktowane inaczej niz inne zadania.
Myślę że najistotniejsza róznica leży w charakterze projektu- inaczej bedzie
wyglądala realizacja projektu "szytego na miare: dla konkretnego klienta i
do
konkretnego zastosowania a inaczej realizacja projektu tworzenia
oprogramowania "na półke" które ma być sprzedawane jako skończony produkt na
rynku ogólnym.

>
> Moze tak jest we wdrozeniach. W kontekscie innych projektow
informatycznych
> to piramidalna bzdura.
>
Tak jak napisałem wyżej- byćmoże decyduje charakter projektu, ale w firmie w
której pracowałem stosowało się tą
zasadę i mozna powiedzieć że z wyjątkeim ułamkowego odsetka- sprawdzała się-
dlatego też mam planowstręt chyba jak mało która osoba.
--
Jackare
Bytom

do góry

Jackare <j...@i...pl> napisał(a):

>
> , bo tak sie sklada, ze "projekt informatyczny" czesciej dotyczy
> > czegos zupelnie innego - _tworzenia_ oprogramowania mianowicie.
> >
> we wszystkich projektach w których uczestniczyłem i które prowadziłem było
> tworzone oprogramowanie w całości lub w części i było to po prostu jedno z
> zadań w projekcie podlegające zarzadzaniu przez kierownika całości projektu
> i nie traktowane inaczej niz inne zadania.
> Myślę że najistotniejsza róznica leży w charakterze projektu- inaczej bedzie
> wyglądala realizacja projektu "szytego na miare: dla konkretnego klienta i
> do
> konkretnego zastosowania a inaczej realizacja projektu tworzenia
> oprogramowania "na półke" które ma być sprzedawane jako skończony produkt na
> rynku ogólnym.

Tu nie chodzi tylko o to, tylko o zlozonosc powstajacego oprogramowania.
Wdrozenie zwykle polega (choc moge sie mylic) na sklejeniu kilku roznych
klockow w jakas calosc. Jest to zadanie, w ktorym ciezar "biznesowy" jest dosc
spory, a zlozonosc "technologiczna" czesto marginalna. (Z punktu widzenia IO
jest to upiornie nudne zajecie, dlatego tez tylko ciezki glod na rynku pracy
zmusi odrobine ambitniejszego inzyniera do takiej pracy).
Tam gdzie tworzone oprogramowanie jest nieco bardziej zlozone, podzial 80/20
jest kompletnym nieporozumieniem - z wielu, wielu wzgledow. A pomysl "najpierw
80% czasu na analize/projekt, pozniej 20% na implementacje" to doskonala
recepta na kleske. Istotny jest tutaj efekt skali. Sredniego rozmiaru soft to
kilka tysiecy klas - kilkaset tysiecy linii kodu. Circa
kilkanascie-kilkadziesiat osobolat na sama implementacje. To pare lat w
kilkunasto-kilkudziesiecio osobowym zespole. Chcesz powiedziec, ze nalezy
najpierw 8 lat projektowac, a pozniej 2 lata implementowac? Czy moze chodzi o
to, ze jak przez 2 lata sie tworzy szczegolowy projekt, to pozniej to co sie
zwykle pisze pare lat powstanie w zaledwie 6 miesiecy?
Niezaleznie od proporcji (80/20 czy 50/50 czy nawet 10/90) podejscie takie
(szczegolowa analiza, szczegolowy projekt, nastepnie implementacja) skutkuje
zazwyczaj w zjawisku znanym jako Big Bang Integration - czyli pod sam koniec
projektu (i budzetu), gdy sie zaczyna implementowac, zaczynaja wylazic bledy w
projekcie i analizie, ktorych zwykle jest bardzo duzo, bo rzeczy skomplikowane
sa podatne bledy. A im dluzszy jest cykl
(planowanie/analiza/projektowanie/implementacja/test
owani/...) tym drozsze sa
bledy popelnione w poczatkowych fazach. O tym pisal jeszcze w '81 B. Boehm w
"Software Engineering Economics".
Jesli twoja firma skutecznie pisze zlozone oprogramowanie w modelu 80/20, to
powinienes szybko napisac o tym ksiazke i zbijac kokosy na consulting'u.


A.

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry