Temat: Analityk IT vs Projektant IT

Moim zdaniem stale rośnie...

Temat: Analityk IT vs Projektant IT

Tomasz Tomaszewski:
...
A złożoność projektów IT rośnie, maleje, jest stała?

Problem jest właśnie z tym, że złożoność cały czas rośnie. Jest to jeden z głównych powodów utrzymywania się stałego trendu projektów nieudanych.

Temat: Analityk IT vs Projektant IT

Jeśli tak, to nie ma przesłanek by z tego raportu wyciągać wnioski n/t (nie)"skuteczności" stosowanych metodyk.

Tak, ale tylko przy założeniu, że zaledwie 1/3 -1 /4 (udane) projektów IT jest realizowana w jakieś metodyce.

Podejrzewam, że tak nie jest.

A złożoność projektów IT rośnie, maleje, jest stała?

Nie jestem pewny w jakim celu zadajesz to pytanie -załóżmy, że realizujemy jakiś złożony (cokolwiek by to miało być) projekt w zadanej metodyce; projekt nie wypala - co jest winne, metodyka czy złożoność ?

Poza tym - proste projekty nie potrzebują metodyki.

Temat: Analityk IT vs Projektant IT

A złożoność projektów IT rośnie, maleje, jest stała?

Nie jestem pewny w jakim celu zadajesz to pytanie -załóżmy, że realizujemy jakiś złożony (cokolwiek by to miało być) projekt w zadanej metodyce; projekt nie wypala - co jest winne, metodyka czy złożoność ?

hm...winne mogą być:
- wykonawca (znajomość narzędzia, jego posiadanie, używanie, to odrębne rzeczy)
- dana metodyka może nie przystawać do konkretnego projektu
- super metodyka i super ludzie ale narzędzia do kitu (także język kodowania)

co do złożoności i prostoty:
- PESEL i założenie, że struktura nie zmieni się przez 20 lat: projekt trywialny
- mała firma usługowa na szybkkozmieniającym się ryku: projekt złożony

dla mnie projekt złożony to złożona logika oprogramowania a nie ilość przetwarzanych danych (czy elektroniczna książka adresowa wszystkich polaków to złożony czy trywialny projekt?????)

Poza tym - proste projekty nie potrzebują metodyki.

w rozumieniu powyższym zapewne nie ale zły wybór narzędzia (języka) może z projekty prostego uczynić złożone... ;), po trzecie jak ktoś raz zainwestował i nauczył się jeździć rowerem z przerzutkami, amortyzatorami z tytanu, to wcale nie znaczy, że ma trzymać i używać na krótkich dystansach do pobliskiego sklepu starego składaka z ostrym kołem tylko dlatego, ze blisko...

Temat: Analityk IT vs Projektant IT

Jakub Wojt:

Jeśli tak, to nie ma przesłanek by z tego raportu wyciągać wnioski n/t (nie)"skuteczności" stosowanych metodyk.

Tak, ale tylko przy założeniu, że zaledwie 1/3 -1 /4 (udane) projektów IT jest realizowana w jakieś metodyce.

Podejrzewam, że tak nie jest.

A złożoność projektów IT rośnie, maleje, jest stała?

Nie jestem pewny w jakim celu zadajesz to pytanie -załóżmy, że realizujemy jakiś złożony (cokolwiek by to miało być) projekt w zadanej metodyce; projekt nie wypala - co jest winne, metodyka czy złożoność ?

Jeśli przeciętna złożoność realizowanych systemów rośnie, a poziom sukcesów projektów jest stały to znaczy że potrafimy projekty robić coraz lepiej (czyli prawdopodobnie też nimi zarządzać). Jeśli nie robilibyśmy ich coraz lepiej, to poziom sukcesów by spadał.

Pisząc obrazowo - to tak jak z hakerami i zabezpieczeniami. To że niebezpieczeństwo włamania nie obniża się, nie znaczy że nie mamy coraz lepszych zabezpieczeń. Mamy. Tylko hakerzy też są coraz lepsi.

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
...

A złożoność projektów IT rośnie, maleje, jest stała?

Nie jestem pewny w jakim celu zadajesz to pytanie -załóżmy, że realizujemy jakiś złożony (cokolwiek by to miało być) projekt w zadanej metodyce; projekt nie wypala - co jest winne, metodyka czy złożoność ?

Jest kilka ważnych kwestii:
1. Jeśli ktoś mówi, że wdrożył u siebie metodykę, to najpewniej spaprał co tylko było możliwe a wdrożenie polegało na kopiuj-wklej z podręcznika i internetu. Metodykę się dostosowuje ogólnie do potrzeb przedsiębiorstwa a szczegółowo do projektu.
2. Pewne metodyki kompletnie się nie nadają do określonego rodzaju projektów: np. Scrum kompletnie się nie nadaje do projektów związane z finansami (mam na myśli np. systemy rozliczeń międzybankowych) czy z projektami bezpośrednio związanymi z życiem i zdrowiem ludzi (np. znakomita większość projektów DoD chociażby systemy sterowania myśliwców).
3. Żeby mówić o klęsce metodyki wypadałoby po zakończeniu projektu zweryfikować czy zawiodła metodyka czy jest to wynik pójścia na skróty, bo się nie rozumie metodyki. To tak jakby mechanik samochodowy z lekkim zmieszaniem i uśmiechem stwierdziłby że w sumie złożył wszystko z powrotem, ale zostało mu tu kilka części --- pewnie niepotrzebnych.

Dopiero po tym wszystkim można by było zastanawiać się czy złożoność nie przerosła wykonawców: czyli wszystko zrobili zgodnie ze sztuką, ale coś zawiodło. Najpewniej byłby to brak doświadczenia (np. nigdy nie robiliśmy hurtowni, ale teraz spróbujemy) lub wiedzy (np. nie projektowaliśmy systemów rozproszonych, ale ten projekt jest świetną okazją by się nauczyć). Najpewniej taka chęć zarobku przyćmi zdrowy rozsądek i wyjdzie na jaw jeden z 3. powodów wcześniej opisanych.

Poza tym - proste projekty nie potrzebują metodyki.

Proste projekty się skończyły w latach 80., chyba że masz na myśli polskie start-upy, które się ciągną w gronie dwuosobowym przez trzy lata.

Temat: Analityk IT vs Projektant IT

Nie jestem pewny w jakim celu zadajesz to pytanie -załóżmy, że realizujemy jakiś złożony (cokolwiek by to miało być) projekt w zadanej metodyce; projekt nie wypala - co jest winne, metodyka czy złożoność ?

"Cokolwiek by to miało być" jest złym określeniem, tak na prawdę chodziło mi o "cokolwiek miało by to znaczyć".

Jeśli przeciętna złożoność realizowanych systemów rośnie, a poziom sukcesów projektów jest stały to znaczy że potrafimy projekty robić coraz lepiej (czyli prawdopodobnie też nimi zarządzać). Jeśli nie robilibyśmy ich coraz lepiej, to poziom sukcesów by spadał.

co to ma wspólnego z tematem dyskusji (ewentualnie z rzeczywistością) ?Jakub Wojt edytował(a) ten post dnia 11.07.12 o godzinie 23:54

Temat: Analityk IT vs Projektant IT

A złożoność projektów IT rośnie, maleje, jest stała?

Nie jestem pewny w jakim celu zadajesz to pytanie -załóżmy, że realizujemy jakiś złożony (cokolwiek by to miało być) projekt w zadanej metodyce; projekt nie wypala - co jest winne, metodyka czy złożoność ?

Jest kilka ważnych kwestii:

ym, ym; jest tylko jedna - kto zawiódł.

PM realizował RUP'a od początku do końca (i oczywiście dobrze go dopasował do wymagań firmy), programiści programowali a testerzy testowali; wszystko w szablonie np. RUP.

Projekt nie wypalił...

Kto zaniedbał swoje obowiązki ? :)

Temat: Analityk IT vs Projektant IT

Jakub Wojt:

Nie jestem pewny w jakim celu zadajesz to pytanie -załóżmy, że realizujemy jakiś złożony (cokolwiek by to miało być) projekt w zadanej metodyce; projekt nie wypala - co jest winne, metodyka czy złożoność ?

"Cokolwiek by to miało być" jest złym określeniem, tak na prawdę chodziło mi o "cokolwiek miało by to znaczyć".

Jeśli przeciętna złożoność realizowanych systemów rośnie, a poziom sukcesów projektów jest stały to znaczy że potrafimy projekty robić coraz lepiej (czyli prawdopodobnie też nimi zarządzać). Jeśli nie robilibyśmy ich coraz lepiej, to poziom sukcesów by spadał.

co to ma wspólnego z tematem dyskusji (ewentualnie z rzeczywistością) ?

Hmm... obala Twoje argumenty opierające się na tym że nic w projektach się nie zmieniło od 1996 roku?Tomasz Tomaszewski edytował(a) ten post dnia 12.07.12 o godzinie 00:24

Temat: Analityk IT vs Projektant IT

Jakub Wojt:

A złożoność projektów IT rośnie, maleje, jest stała?

Nie jestem pewny w jakim celu zadajesz to pytanie -załóżmy, że realizujemy jakiś złożony (cokolwiek by to miało być) projekt w zadanej metodyce; projekt nie wypala - co jest winne, metodyka czy złożoność ?

Jest kilka ważnych kwestii:

ym, ym; jest tylko jedna - kto zawiódł.

PM realizował RUP'a od początku do końca (i oczywiście dobrze go dopasował do wymagań firmy), programiści programowali a testerzy testowali; wszystko w szablonie np. RUP.

Projekt nie wypalił...

Kto zaniedbał swoje obowiązki ? :)

Nie ma takiej możliwości ;)

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
...

Jeśli chcesz mojej szybkiej reakcji na pytanie proponowałbym nie obcinać w komentarzu autora posta. Wydawało mi się to oczywistą regułą dla "wprawionego" oponenta :)

Temat: Analityk IT vs Projektant IT

Jakub Wojt:
...
ym, ym; jest tylko jedna - kto zawiódł.

PM realizował RUP'a od początku do końca (i oczywiście dobrze go dopasował do wymagań firmy), programiści programowali a testerzy testowali; wszystko w szablonie np. RUP.

Projekt nie wypalił...

Kto zaniedbał swoje obowiązki ? :)

No właśnie... Czy dobrze dopasował? Jeśli pierwotny plan projektu dla RUP zakłada 6 miesięczny projekt, to powinno być np. 5 5. tygodniowych cykli, a faza Rozpoczęcia ma trwać 2,5 dnia i ma dać odpowiedź co mamy w ogóle robić oraz czym się zajmiemy w tym cyklu. Jeśli się przekroczy ten termim bodaj o godzinę, to są przesłanki by podejrzewać niedoszacowanie czasu projektu. Ponadto w przypadku takiego projektu możliwy byłby 3 tygodniowy poślizg lub/i standardowe okreslienie 80% progu absolutnie niezbednych przypadków użycia do zrealizowania.

A jak budujesz dom i zostanie Ci 3 cegły to jest już klęska ;) ? Tylko nie mów, że pośliźnijmy się o 50% zakresu lub miesiąc lub wydajmy x2 więcej kasy. Trzeba pamiętać o tym by przed rozpoczęciem projektu określić kryteria sukcesu i to niezależnie od metodyky. Nie jest to "księgowość kreatywna", Scrum stosuje te same reguły :)

Temat: Analityk IT vs Projektant IT

Jeśli przeciętna złożoność realizowanych systemów rośnie, a poziom sukcesów projektów jest stały to znaczy że potrafimy projekty robić coraz lepiej (czyli prawdopodobnie też nimi zarządzać). Jeśli nie robilibyśmy ich coraz lepiej, to poziom sukcesów by spadał.

Pisząc obrazowo - to tak jak z hakerami i zabezpieczeniami. To że niebezpieczeństwo włamania nie obniża się, nie znaczy że nie mamy coraz lepszych zabezpieczeń. Mamy. Tylko hakerzy też są coraz lepsi.

nie łączył bym tego, złożoność projektów rośnie ale rośnie jakość narzędzi, bibliotek itp. Jeżeli 20 lat temu trzeba było napisać "od zera" lekko licząc połowę kodu tak teraz pisze się ledwie kilkanaście procent więc obawiam się rośnie złożoność systemów a 'programiści" stoją w miejscu (np. pisanie systemu ERP z pomocą Pascala z lat 90tych.....) tego jest na prawdę dużo..... jest źle,,,,

Temat: Analityk IT vs Projektant IT

Tomasz Tomaszewski:

Jakub Wojt:

>

co to ma wspólnego z tematem dyskusji (ewentualnie z rzeczywistością) ?

Hmm... obala Twoje argumenty opierające się na tym że nic w projektach się nie zmieniło od 1996 roku?

Ja jedynie twierdzę, że powstanie RUP'a nic nie zmieniło w kwestii skuteczności realizacji projektów. Z kolei z tego wynika, że RUP jest co najwyżej tak dobry jak inne popularne metodyki, a ponieważ tylko 1/4 - 1/3 projektów wypala, to można spokojnie stwierdzić, że "popularne metodyki" po prostu nie działają.

A jeśli chodzi o złożoność (cokolwiek to znaczy) - stwierdzenie "failujemy tak samo, ale przy bardziej złożonych projektach" jest chyba słabym pocieszeniem, prawda ? Zwłaszcza, że tych "prostych" chyba nikt nie realizuje (nie ma przełożenia na statystyki).Jakub Wojt edytował(a) ten post dnia 12.07.12 o godzinie 21:33

Temat: Analityk IT vs Projektant IT

Aleksander Olszewski:

Jakub Wojt:
...
ym, ym; jest tylko jedna - kto zawiódł.

PM realizował RUP'a od początku do końca (i oczywiście dobrze go dopasował do wymagań firmy), programiści programowali a testerzy testowali; wszystko w szablonie np. RUP.

Projekt nie wypalił...

Kto zaniedbał swoje obowiązki ? :)

No właśnie... Czy dobrze dopasował? Jeśli pierwotny plan projektu dla RUP zakłada 6 miesięczny projekt, to powinno być np. 5 5. tygodniowych cykli, a faza Rozpoczęcia ma trwać 2,5 dnia i ma dać odpowiedź co mamy w ogóle robić oraz czym się zajmiemy w tym cyklu.

A jeśli nie da ? A co jeśli "wizja" powstanie w ciągu jednego dnia ?
IMHO to absurdalne podejście do sprawy - definiowanie procesu przez czas trwania.
Równie dobrze lekarzem może być każdy, kto nosi biały fartuch albo ma na szyi stetoskop.

Jeśli się przekroczy ten termim bodaj o godzinę, to są przesłanki by podejrzewać niedoszacowanie czasu projektu. Ponadto w przypadku takiego projektu możliwy byłby 3 tygodniowy poślizg lub/i standardowe okreslienie 80% progu absolutnie niezbednych przypadków użycia do zrealizowania.
A jak budujesz dom i zostanie Ci 3 cegły to jest już klęska ;)

no jak masz dziurę w ścianie ...

? Tylko nie mów, że pośliźnijmy się o 50% zakresu lub miesiąc lub wydajmy x2 więcej kasy. Trzeba pamiętać o tym by przed rozpoczęciem projektu określić kryteria sukcesu i to niezależnie od metodyky. Nie jest to "księgowość kreatywna", Scrum stosuje te same reguły :)

Ok, wierzę na słowo.Jakub Wojt edytował(a) ten post dnia 13.07.12 o godzinie 09:38

Temat: Analityk IT vs Projektant IT

PM realizował RUP'a od początku do końca (i oczywiście dobrze go dopasował do wymagań firmy), programiści programowali a testerzy testowali; wszystko w szablonie np. RUP.

Projekt nie wypalił...

Kto zaniedbał swoje obowiązki ? :)

Nie ma takiej możliwości ;)

To jak rozumiem, te 60% porażek bierze się z tego, że ludzie nie potrafią stosować danej metodyki.
Jeśli tak - te metodyki muszą być na prawdę dobre. Właściwie nie da się ich zastosować, a mimo to, ludzie wciąż próbują to zrobić.

Temat: Analityk IT vs Projektant IT

To jak rozumiem, te 60% porażek bierze się z tego, że ludzie nie potrafią stosować danej metodyki.
Jeśli tak - te metodyki muszą być na prawdę dobre. Właściwie nie da się ich zastosować, a mimo to, ludzie wciąż próbują to zrobić.

hm... jest prosta prawidłowość nie tylko w projektach, które obserwowałem: im mniej planowania tym większa porażka, nazwa metody i metodyki ma znaczenie drugorzędne, każda przewiduje poprzedzanie pracy jej planowaniem, zaznaczam, że modelowanie i projektowanie przed implementacją to także planowanie....

gdyby mnie ktoś chciał przekonywać, że planowanie jest zbędne, że można od razu "brać się za robotę", to z całym szacunkiem, ale praktyka jasno pokazuje, że brak planowania to klęska projektu (nie licząc może, cytując Yourdona, zbijania budy dla psa ...)

Temat: Analityk IT vs Projektant IT

Jarek Żeliński:

To jak rozumiem, te 60% porażek bierze się z tego, że ludzie nie potrafią stosować danej metodyki.
Jeśli tak - te metodyki muszą być na prawdę dobre. Właściwie nie da się ich zastosować, a mimo to, ludzie wciąż próbują to zrobić.

hm... jest prosta prawidłowość nie tylko w projektach, które obserwowałem: im mniej planowania tym większa porażka, nazwa metody i metodyki ma znaczenie drugorzędne, każda przewiduje poprzedzanie pracy jej planowaniem, zaznaczam, że modelowanie i projektowanie przed implementacją to także planowanie....

gdyby mnie ktoś chciał przekonywać, że planowanie jest zbędne, że można od razu "brać się za robotę", to z całym szacunkiem, ale praktyka jasno pokazuje, że brak planowania to klęska projektu (nie licząc może, cytując Yourdona, zbijania budy dla psa ...)

Panie Jarku, to pokazuje nie tylko doświadczenie, ale mnóstwo badań (w Polsce choćby: 44% klęsk projektów bez metodyk, względem "tylko" 12% przy ich stosowaniu)... no i zdrowy rozsądek. Wdrażanie jakiejkolwiek metodyki już zmusza do zastanowienia się co i jak będziemy robić. A to fundament sukcesu. Zresztą, tylko głupiec nie korzysta z doświadczeń innych. Już samo to, że nad RUPem, PRINCem, SCRUMem i każdą inną znaną metodyką pracowali ludzie mający za sobą lata doświadczeń i mnóstwo projektów sprawia, że warto się nad nimi pochylić i... uczyć się różnych podejść do projektów, uczyć się na pewno od ludzi (ode mnie przynajmniej) lepszych.Tomasz Tomaszewski edytował(a) ten post dnia 14.07.12 o godzinie 01:33

Temat: Analityk IT vs Projektant IT

stara wojskowa zasada mówi: najgorszy plan jest lepszy od braku planu, to powiedzenie ma tysiące lat... rzecz w tym, by każde działanie poprzedzić choć odrobiną refleksji nad skutkami naszych prac... "cokolwiek czynisz czyń rozsądnie i patrz końca..." (autora nie znam)

Temat: Analityk IT vs Projektant IT

Jak już wtrącono wojsko... Mój niezapomniany wykładowca WAT, ISI niejaki dr Stanik zawsze mawiał - że "naczelną i pierwszą zasadą stosowania jakiejkolwiek metodydyki - jest... dostosowanie jej do własnych potrzeb" ;) Tak dla refleksji...