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