Temat: Analityk IT vs Projektant IT

Roman F.:
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...

Jeśli chodzi o same metodyki, to w PRINCE2, PMI, RUP, Crystal i Scrum na samym początku jest mowa o tym, że metodykę trzeba dostosować do potrzeb przedsiębiorstwa i projektu. W tej liście XP nie wymieniałem, bo samo XP jest zbiorem 12 dobrych praktyk do ułożenia w konkretnym projekcie.

Optymistyczny morał jest taki, że rady które się znajdują w opisach metodyk mają korzenie sięgające tak głęboko jak sięga sztuka wojenna --- tysięcy lat ;)

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

No i tutaj mamy 100% zgodności.
Warunkiem koniecznym i mającym (pewnie więcej, ale co tam) 90% wpływu na powodzenie projektu jest poprawnie wykonana analiza biznesowa. Cała reszta to przetwarzanie / tłumaczenie jej na system komputerowy, co przy pewnej architekturze, jest właściwie czynnością mechaniczną.

Problem polega na tym, że mało kto w tym momencie zdaje sobie z tego sprawę. Management i inne ludki zachowują się trochę jak początkujący programiści tzn. wydaje im się (a przynajmniej takie odnoszą wrażenie) że technologią załatwi to, że nie wiedzą co chcą zrobić.

Że, TDD, RUP, Agile, "motywacja" , "zaangażowanie" etc .. w jakiś magiczny sposób wyręczy ich od precyzyjnego opisu wymagań.
Nie uwolni, a jedynie sprawi dodatkowe problemy.

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

no i właśnie mamy tego efekty. Z resztą, całe to IT to imho komedia ... pytanie - jak obliczono czas / kosz wykonania projektu. Bo może metodyki realizacji są dobre a tylko metody szacowania - złe ;)

Ślepy prowadzi niemego ... I ja mam w takim środowisku zarabiać na życie ;)Jakub Wojt edytował(a) ten post dnia 18.07.12 o godzinie 10:25

Temat: Analityk IT vs Projektant IT

No i tutaj mamy 100% zgodności.

ze mną także :)

Warunkiem koniecznym i mającym (pewnie więcej, ale co tam) 90% wpływu na powodzenie projektu jest poprawnie wykonana analiza biznesowa. Cała reszta to przetwarzanie / tłumaczenie jej na system komputerowy, co przy pewnej architekturze, jest właściwie czynnością mechaniczną.

zaryzykuje tezę, że 100% logiki biznesowej to produkt analizy biznesowej a 100% jakości implementacji (wymagań poza-funckjonlanych) to developer...

Problem polega na tym, że mało kto w tym momencie zdaje sobie z tego sprawę. Management i inne ludki zachowują się trochę jak początkujący programiści tzn. wydaje im się (a przynajmniej takie odnoszą wrażenie) że technologią załatwi to, że nie wiedzą co chcą zrobić.

ukłon.... właśnie mam taki projekt....

Że, TDD, RUP, Agile, "motywacja" , "zaangażowanie" etc .. w jakiś magiczny sposób wyręczy ich od precyzyjnego opisu wymagań.
Nie uwolni, a jedynie sprawi dodatkowe problemy.

ukłon...

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

no i właśnie mamy tego efekty. Z resztą, całe to IT to imho komedia ... pytanie - jak obliczono czas / kosz wykonania projektu. Bo może metodyki realizacji są dobre a tylko metody szacowania - złe ;)

Ślepy prowadzi niemego ... I ja mam w takim środowisku zarabiać na życie ;)

kolejny ukłon :)

Temat: Analityk IT vs Projektant IT

Nie ma to jak konstruktywna wymiana poglądów (przyglądałem się całej dyskusji od początku) ;) I ostateczny konsenus... Mnie już by czoło bolało od bicia takiej ilości pokłonów... Ale cóż - za takie słodzenie pewnie bym i czoło poświecił ;)

Wracając do głównego wątku/tematu: Analityk vs Projektant: Bilans - to słowo klucz. Zbilansowane kompetencje to klucz do sukcesu jakiekolwiek projektu. Do bilansu wliczam również i zarządzanie i całą społeczność biznesową a nie tylko praworządnych i sumiennych analityków, projektantów i programistów. Metodyka to pochodna powyższego.

Z drugiej strony, pewnie większość z nas ma ambiwalentne uczucia.... Robiąc projekt w dobrze zarządzanej organizacji w miarę poukładanymi procesami zrobisz go w 6-9 miesięcy... w innych organizacjach...24...36...;)

No ale zarabianie w takim środowisku na życie... to rzeczywiście katorga ;) Pozdrawiam.

Temat: Analityk IT vs Projektant IT

Warunkiem koniecznym i mającym (pewnie więcej, ale co tam) 90% wpływu na powodzenie projektu jest poprawnie wykonana analiza biznesowa. Cała reszta to przetwarzanie / tłumaczenie jej na system komputerowy, co przy pewnej architekturze, jest właściwie czynnością mechaniczną.

zaryzykuje tezę, że 100% logiki biznesowej to produkt analizy biznesowej

true :)
jak sama nazwa wskazuje :)
trudno sobie wyobrazić coś innego.

a 100% jakości implementacji (wymagań poza-funckjonlanych) to developer...

bez dobrej analizy biznesowej - produkt nie powstanie
bez dobrej architektury - produkt być może powstanie, ale będzie "nierozwijalny".

Problem polega na tym, że mało kto w tym momencie zdaje sobie z tego sprawę. Management i inne ludki zachowują się trochę jak początkujący programiści tzn. wydaje im się (a przynajmniej takie odnoszą wrażenie) że technologią załatwi to, że nie wiedzą co chcą zrobić.

ukłon.... właśnie mam taki projekt....

ukłon ;)
ja raz takiego nie miałem :) a jego efektem był produkt "za dobry" ;) Metodyki nikt nie nazywał ale, wnioskuję, że był to waterfall (który jak "wiadomo" - nie działa). Tzn. projekt (analiza), implementacja, testy....

Ale może nie będę używać tej nazwy, bo zaraz pewnie ktoś się będzie na nią snobować nie mając żadnego pojęcia, co się pod nią kryje ;)

Że, TDD, RUP, Agile, "motywacja" , "zaangażowanie" etc .. w jakiś magiczny sposób wyręczy ich od precyzyjnego opisu wymagań.
Nie uwolni, a jedynie sprawi dodatkowe problemy.

ukłon...

Arigato :)

Niestety fakty są takie, że większość PM'ów w to (TDD etc.) wierzy; miałem ostatnio kilka rozmów z takimi osobnikami i estymując - nie ma innej opcji.

Pozostaje rozstrzygnąć - skąd się biorą PM'y i dlaczego tak bardzo wierzą w słowo pisane i "zaplotkowane" ;) ... pewnie dlatego, że nie mają swojego zdania, a jest tak dlatego, ponieważ (imho) się nie znają;

no i właśnie mamy tego efekty. Z resztą, całe to IT to imho komedia ... pytanie - jak obliczono czas / kosz wykonania projektu. Bo może metodyki realizacji są dobre a tylko metody szacowania - złe ;)

Ślepy prowadzi niemego ... I ja mam w takim środowisku zarabiać na życie ;)

kolejny ukłon :)

i kolejny ukłon :)
ale tak na prawdę - to wcale nie jest śmieszne.
Jedynym sposobem na wybrnięcie z tego jest wymyślenie trochę mniejszej głupoty; i opublikowanie jej.Jakub Wojt edytował(a) ten post dnia 18.07.12 o godzinie 22:41

Temat: Analityk IT vs Projektant IT

Nie ma to jak konstruktywna wymiana poglądów (przyglądałem się całej dyskusji od początku) ;) I ostateczny konsenus... Mnie już by czoło bolało od bicia takiej ilości pokłonów... Ale cóż - za takie słodzenie pewnie bym i czoło poświecił ;)

? :)
a wiesz w ogóle o czym była dyskusja ? (oprócz pokłonów - naturalnie).

może idź sobie zarządzać gdzieś indziej, co ? ;)

Wracając do głównego wątku/tematu: Analityk vs Projektant: Bilans - to słowo klucz. Zbilansowane kompetencje to klucz do sukcesu jakiekolwiek projektu. Do bilansu wliczam również i zarządzanie i całą społeczność biznesową a nie tylko praworządnych i sumiennych analityków, projektantów i programistów. Metodyka to pochodna powyższego.

mów mi tak jeszcze ... :D

Z drugiej strony, pewnie większość z nas ma ambiwalentne uczucia.... Robiąc projekt w dobrze zarządzanej organizacji w miarę poukładanymi procesami zrobisz go w 6-9 miesięcy... w innych organizacjach...24...36...;)

och, jakie fajne, ambiwalentne, estymacje.

No ale zarabianie w takim środowisku na życie... to rzeczywiście katorga ;) Pozdrawiam.

yhm ..
Pozdrawiam.Jakub Wojt edytował(a) ten post dnia 18.07.12 o godzinie 22:47

Temat: Analityk IT vs Projektant IT

Nie ma to jak konstruktywna wymiana poglądów (przyglądałem się całej dyskusji od początku) ;) I ostateczny konsenus... Mnie już by czoło bolało od bicia takiej ilości pokłonów... Ale cóż - za takie słodzenie pewnie bym i czoło poświecił ;)

mój znajomy profesor filozof mawia: "gdy dwóch mówi to samo to nie jest to samo"

Wracając do głównego wątku/tematu: Analityk vs Projektant: Bilans - to słowo klucz. Zbilansowane kompetencje to klucz do sukcesu jakiekolwiek projektu. Do bilansu wliczam również i zarządzanie i całą społeczność biznesową a nie tylko praworządnych i sumiennych analityków, projektantów i programistów. Metodyka to pochodna powyższego.

jednej rzeczy nie rozumiem: tak wielu ludzi, szczególnie tych od Agile, jak mantrę powtarza "user". Analogicznie jak sprzedawcy "Klient nasz pan"... a w moich oczach i nie tylko to totalna bzdura. od kiedy to klient jest moim panem? Każe mi buty sznurować to zrobię to? A może każe mi każe bombę zaprojektować i podłożyć pod własną firmę (niektóre projekty IT tak wyglądają)... biznes to "zgraja" ludzi, którzy dostają od pracodawcy narzędzia pracy i mają się brać do roboty, w jakiej to firmie pracownik decyduje o tym jaki samochód dostanie, jakie biurko, jaki komputer, jaki fax, a może biuro w najfajniejszej części miasta? To dlaczego niby w "softłerze" miałby mieć więcej do gadania????? Skąd się biorą "listy pobożnych życzeń i nierealizowanych wymagań"?

oprogramowanie to kolejne narzędzie pracy, dokładnie takie jak system operacyjny na którym zostanie zainstalowane (kto u klienta kastomizuje windowsy?????)

Z drugiej strony, pewnie większość z nas ma ambiwalentne uczucia.... Robiąc projekt w dobrze zarządzanej organizacji w miarę poukładanymi procesami zrobisz go w 6-9 miesięcy... w innych organizacjach...24...36...;)

to inna para kaloszy, projekt IT powinien się zaczynać po stwierdzeniu, że firma jest uporządkowana, jak jest bałagan to porządkowanie powinna poprzedza projekt IT. A jak ktoś uważa, że "Klient nasz pan" to ładuje się w bagno w rodzaju "no nie wiem co ten Pan w systemie może, może niech może wszystko?". Mam właśnie klienta, któremu mam opisać wymagania na system wspierający sprzedaż, a szanowny Pan dyr. handlowy (jego ludzi i cała firma) w zasadzie nie ma ani zakresów obowiązków ani wymaganych kompetencji, to jakie wymagania? "Każdy może wszystko ale do końca nie wiadomo jak bo handlowcy mogą robić jak chcą byle byli skuteczni"......

to jest bardzo duża i poważna firma ....

Moim zdaniem projekty IT mają te 80% porażek, bo to jedyne projekty gdzie przyszły użytkownik ma najwięcej do gadania...