Interesuje mnie praca na stanowisku analityka IT. W chwili obecnej mam ukończone studia Informatyka i ekonometria (specjalność: Informatyka ekonomiczna). Przez jakiś czas pracowałam w Deloitte Audyt, a później jako konsultant systemów ERP. W planach mam zdawanie egzaminu ITILv3 Foundation. Co jeszcze można zrobić, aby we własnym zakresie przygotować się do pracy na takim stanowisku oraz, żeby być atrakcyjnym dla potencjalnego pracodawcy? Proszę o rade.

Dorota Imiela:
Interesuje mnie praca na stanowisku analityka IT. W chwili obecnej mam ukończone studia Informatyka i ekonometria (specjalność: Informatyka ekonomiczna). Przez jakiś czas pracowałam w Deloitte Audyt, a później jako konsultant systemów ERP. W planach mam zdawanie egzaminu ITILv3 Foundation. Co jeszcze można zrobić, aby we własnym zakresie przygotować się do pracy na takim stanowisku oraz, żeby być atrakcyjnym dla potencjalnego pracodawcy? Proszę o rade.

To nie ma zabrzmieć złośliwie ale należy zacząć pracować na takim stanowisku, ew. zbliżonym, w zespole gdzie jest taka osoba - i bacznie obserwować wyciągając właściwe wnioski, analizując zwycięstwa i porażki.
Samo zdawanie egzaminów nic ci nie da jak nie będziesz miała praktyki. Nawet jeśli cię ktoś zatrudni (bo spodobają mu się twoje papierki) to po 3 miesiącach wylecisz.

Zdaję sobie sprawę, że najlepiej człowiek się uczy przez praktykę. W chwili obecnej poszukuje pracy i zastanawiałam się jakie umiejętności powinien mieć analityk. W wielu ogłoszeniach jak zauważyłam położono nacisk np. na modelowanie procesów biznesowych czy wymiarowanie programowania.

Dobry analityk IT potrafi poniekad programowac. Nauka systemow analitycznych malo daje, bo kazda firma uzywa innych. Analitykie przewaznie staje sie przez awans. Przynajmniej ja tak zauwazylem

Jakub Boski:
Dobry analityk IT potrafi poniekad programowac. Nauka systemow analitycznych malo daje, bo kazda firma uzywa innych. Analitykie przewaznie staje sie przez awans. Przynajmniej ja tak zauwazylem

Zgadzam się z Tobą w 100% być analitykiem to:
1. Sztuka postawienia się po stronie zarówno użytkownika jak i osoby przygotowującej system
2. Spędzenie trochę czasu podczas prac nad systemami zarówno od strony czysto technicznej (tu czas może nie być długi) i analitycznej - brać udział w projektach, zapoznawac się ze sposobem analizy.
3. Zaglądnąć do pozycji i poczytać conieco o analizie, np. funkcjonalenj.

Bo jak dla mnie analityków to można na szybko wymienić 3 rodzaje: biznesowy, funkcjonalny i techniczny. Praca każdego wiąże się z innymi obowiązkami.

Jakub Boski:
Dobry analityk IT potrafi poniekad programowac. Nauka systemow analitycznych malo daje, bo kazda firma uzywa innych. Analitykie przewaznie staje sie przez awans. Przynajmniej ja tak zauwazylem

To mocno zależy od profilu pracy. Analityk IT to bardzo ogólne pojęcie. W moim odczuciu ścieżka kariery analityka systemowego i analityka biznesowego są zupełnie różne. Zgodnie z moją wiedzą nawet lepiej by było, gdyby analityk biznesowy (mam tutaj na myśli osobę tworzącą specyfikację wymagań i model analityczny systemu) nie miał wiele wspólnego z programowaniem. To ogranicza, a techniczny wybór rozwiązań winien leżeć po stronie architekta/projektanta. Tzn. dużo lepiej gdy analityk w SWS "system powinien być dostępny online" niż "system powinien być obsługiwany przez przeglądarkę" to analiza wymagań funkcjonalnych i niefunkcjonalnych winna wykazać, czy bardziej z punktu widzenia zarządzania projektem (spełnienie wymagań funkcjonalnych, niefunkcjonalnych; zarządzanie ryzykiem; budżet) opłaca się budować interfejs przeglądarkowy, czy jakieś natywne rozwiązanie. Moje doświadczenie natomiast jak również czytane przeze mnie opracowania stwierdzają, że analityk/programista ma silne tendencje do definiowania JAK zamiast CO.
Jeśli chodzi o analityka systemowego - tutaj droga jest różna. Podstawą jest doskonała znajomość systemu. Ścieżka tej kariery często zaczyna się w helpdesku danego rozwiązania.

Jakub Boski:
Dobry analityk IT potrafi poniekad programowac. Nauka systemow analitycznych malo daje, bo kazda firma uzywa innych. Analitykie przewaznie staje sie przez awans. Przynajmniej ja tak zauwazylem

No to mamy różne odczucia :)

Na początek odróżnijmy pojęcie dobrego analityka od tego mniej dobrego a popatrzmy na popatrzmy na wymaganą wiedzę lub jej nadmiar:
- znajomość programowania często ogranicza analityka do poziomu wiedzy komplementacyjnej a analiza to nie programowanie, analityk ma zrozumieć i opisać problem, architekt go rozwiązać a programista zaimplementować
- analityk zajmuje się opisaniem firmy (biznesu) zamawiającego a wiec MUSI znać takie zagadnienia jak zarządzanie i marketing, finanse i rentowność projektów
- jeżeli pod pojęciem "system analityczny" rozumiemy oprogramowane CASE to moim zdaniem na dzisiaj analityk używający do pracy MSOfice'a jest jak programista piszący w Assemblerze, cenna umiejętność ale praca benedyktyńska (by stwrzyć coś spójnego bez błędów). czyli STRASZNIE kosztowna.

Proponuje popatrzeć od końca a ma powstać:
- specyfikacja wymagań
- model danych
- model procesów biznesowych
- biznesowe uzasadnienie projektu
i tego trzeba się nauczyć :) robić dobrym narzędziem podobnie jak architekci którzy od dłuższego czasu używają ATOCADa a nie deski kreślarskiej.

Jarek Żeliński:
- znajomość programowania często ogranicza analityka do poziomu wiedzy komplementacyjnej a analiza to nie programowanie, analityk ma zrozumieć i opisać problem, architekt go rozwiązać a programista zaimplementować

Jarku,
masz tu na pewno rację. Spaczenie programowaniem może być zgubna. Niemniej jednak analityk funkcjonalny (nie biznesowy) powinien znać przynajmniej wg. mnie niektóre możliwości techniczne. Bez nich może wspaniale opisać kawałek systemu, którego w danej technologii zrobić sie nie będzie dało.
Współpraca na linii techniczni -> funkcjonalni -> biznesowi powinna być moim zdaniem przez cały okres projektowania i analizy systemowej. Wtedy jest przynajmniej większa szansa na system taki, jakiego oczekuje klient, a nie taki jak wymyswlą ludki z IT :) Co niestety zdarza się.

Paweł Janusz:
Jarku,
masz tu na pewno rację. Spaczenie programowaniem może być zgubna. Niemniej jednak analityk funkcjonalny (nie biznesowy) powinien znać przynajmniej wg. mnie niektóre możliwości techniczne. Bez nich może wspaniale opisać kawałek systemu, którego w danej technologii zrobić sie nie będzie dało.

To prawda, analityk, który opisuje wymagania musi rozumieć czego wymaga i zna ograniczenia jakie wiążą się z programowaniem (wykonywalność pewnych wymagań jak i ich potencjalna pracochłonność) co nie znaczy, że sam musi umieć dobrze programować (nawet w przeszłości).

osobiście uważam, że specyfikowanie pracy dla programistów jest najskuteczniejsze jeżeli przekażemy im model danych, zarys architektury oraz przypadki użycia ale z prototypami ekranów i scenariuszami z perspektywy architektury. jeżeli autor modelu dziedziny zawarł w niej klasy Faktura oraz Fakturzysta i WzórFaktury to powinien pokazać jak sobie wyobraża powstanie nowej faktury z pomocą tych klas diagramem sekwencji. Aby to zrobić nie trzeba umieć programować, wystarczy posługiwać się metodami obiektowymi w opisywaniu tych rzeczy np.z pomca UML.

Tak więc moja rada młodych adeptów analizy biznesowej: analiza i modelowanie procesowe organizacji, analiza i projektowanie obiektowe.

Osobiście nei widze żadnej potzreby zaliczania np. ITIL.

Współpraca na linii techniczni -> funkcjonalni -> biznesowi powinna być moim zdaniem przez cały okres projektowania i analizy systemowej. Wtedy jest przynajmniej większa szansa na system taki, jakiego oczekuje klient, a nie taki jak wymyswlą ludki z IT :) Co niestety zdarza się.

Ano :)

Paweł Janusz:
Bo jak dla mnie analityków to można na szybko wymienić 3 rodzaje: biznesowy, funkcjonalny i techniczny. Praca każdego wiąże się z innymi obowiązkami.

Jakie produkty oddaje każdy z nich?

Jarek Żeliński:
Jakie produkty oddaje każdy z nich?

hehe czuję się jak na egzaminie :D
1. Biznesowy oddaje założenia wymagań biznesowych i opis procesów biznesowych. Dostarcza projekt High Level Design.
2. Funkcjonalny projektuje system od strony funkcjonalności, czyli proponuje ekrany, identyfikuje encje biznesowe biorące udział w procesach, definiuje ich atrybuty. Oczywiście uszczegóławia i spaja wizję biznesową z tym o czym wspomniałem wcześniej. Produktem pracy jest dokument analizy funkcjonalnej jak i wymagań funkcjonalnach.
3. Techniczny - projektant/architekt buduje model relacyjny danych lub obiektowow relacyjny. Projektuje klasy, opisuje interakcję pomiędzy nimi a encjami. Przedstawia algorytmy działania poszczególnych funkcjonalności.

Jarek Żeliński:
co nie znaczy, że sam musi umieć dobrze programować (nawet w
przeszłości).

A to jest prawda :) Zgadzam się w zupełności.

Jarek Żeliński:
Tak więc moja rada młodych adeptów analizy biznesowej: analiza i
modelowanie procesowe organizacji, analiza i projektowanie
obiektowe.

Z tym rozumieniem obiektowości to czasami duży problem, ale masz słuszność.

Jarek Żeliński:
powinien pokazać jak sobie wyobraża powstanie nowej faktury z
pomocą tych klas diagramem sekwencji. Aby to zrobić nie trzeba
umieć programować, wystarczy posługiwać się metodami obiektowymi
w opisywaniu tych rzeczy np.z pomca UML.

Zgadza się. Diagramy: klas, sekwencji, przypadków użycia i aktywności to wg mnie podstawowe narzędzia dla funkcjonalnych i projektantów low-level.

Paweł Janusz:

Jarek Żeliński:
Jakie produkty oddaje każdy z nich?

hehe czuję się jak na egzaminie :D
1. Biznesowy oddaje założenia wymagań biznesowych i opis procesów biznesowych. Dostarcza projekt High Level Design.

Wybacz, czym tu jest projekt High Level Design :)

2. Funkcjonalny projektuje system od strony funkcjonalności, czyli proponuje ekrany, identyfikuje encje biznesowe biorące udział w procesach, definiuje ich atrybuty. Oczywiście uszczegóławia i spaja wizję biznesową z tym o czym wspomniałem wcześniej. Produktem pracy jest dokument analizy funkcjonalnej jak i wymagań funkcjonalnach.

A kto, po zrozumieniu tego czym się zajmuje klient i na grzyba mu ten system ustala zakres projektu? Innymi słowy: z map procesów mamy 200 czynności realnie wykonywanych a w zakres projektu wchodzi 60 use-case, kto ustala które to będę?

3. Techniczny - projektant/architekt buduje model relacyjny danych lub obiektowow relacyjny. Projektuje klasy, opisuje interakcję pomiędzy nimi a encjami. Przedstawia algorytmy działania poszczególnych funkcjonalności.

Jak skutecznie przekazać z analizy biznesowej takie informacje jak relacje faktura-zamówienie, algorytm naliczenia VAT, liczebność zamówień pod fakturę, itp.? Bo opis procesu nie koniecznie to przekaże...(zakładam, ze procesy to nie algorytmy)

Z tym rozumieniem obiektowości to czasami duży problem, ale masz słuszność.

nie wyobrażam sobie dziś dobrego analityka, które nie kuma obiektowości.... bo w zasadzie bez tego nie ma on żadnego wspólnego języka z developerami...

Zgadza się. Diagramy: klas, sekwencji, przypadków użycia i aktywności to wg mnie podstawowe narzędzia dla funkcjonalnych i projektantów low-level.

dlaczego low-level, :) koncepcyjny opis przypadku użycia (w tym jego scenariusz) i prosty prototyp ekranu to zapis wymagań, projekt go uszczegółowi.....

Pytam z ciekawości innych metodyk, z moich doświadczeń i metodyki jaką stosuję wynika, ze:
- model procesów daje zrozumienie firmy
- model dziedziny daje zrozumienie tego jakimi informacjami (atrybuty klas) operuje klient i jakimi regułami biznesowymi (metody klas) operuje

i to jest analiza biznesowa

- model Use-Case (UC) daje zakres projektu
- model dziedziny wzbogacony o klasy wykonawcze wynikające ze scenariuszy UC dają model koncepcyjny architektury (pełniejszy model dziedziny)

i to jest analiza wymagań i ich specyfikacja

kolejny etap to już architekt systemu i programiści, którzy to uszczegóławiają i implementują.

Po ładnych kliku latach doświadczeń wydaje mi się, że najskuteczniej wymagania określa się tworząc logiczny prototyp programu, który inżynier stworzy podobnie jak w budownictwie: architekt tworząc dokumentację określa wymagania na to co ma stworzyć developer (bo ten nie jest inżynierem wykonawca a nie projektantem).

Analizy dla systemu ERP kończą się na etapie specyfikacji czynności i modelu dziedziny zakwalifikowanych do wdrożenia bo system już istnieje a należy go dopasować (co nie musi być prostsze od stworzenia systemu dedykowanego :)))

Jarek Żeliński:

- znajomość programowania często ogranicza analityka do poziomu wiedzy komplementacyjnej a analiza to nie programowanie

Poniewaz pracowalem (niejako w "poprzednim zyciu") na paru duzych projektach IT moge potwierdzic, ze najlepsi analitycy nie potrafili programowac. Mieli za to rozne inne umiejetnosci i zdolnosci, ktorych z reguly programisci nie posiadali. Tym niemniej bardzo czesto sie zdarza, ze analityk to "byly programista"..;)

Jarek Żeliński:
Wybacz, czym tu jest projekt High Level Design :)

Ogólny opis funkcjonalny od strony biznesu, czyli jak my chcialibyśmy aby to działało, na co pozwalało.

A kto, po zrozumieniu tego czym się zajmuje klient i na grzyba mu ten system ustala zakres projektu? Innymi słowy: z map procesów mamy 200 czynności realnie wykonywanych a w zakres projektu wchodzi 60 use-case, kto ustala które to będę?

Jak dla mnie to zadanie funkcjonalnego. On Okresl use casy i model domenowy.

Jak skutecznie przekazać z analizy biznesowej takie informacje jak relacje faktura-zamówienie, algorytm naliczenia VAT, liczebność zamówień pod fakturę, itp.? Bo opis procesu nie koniecznie to przekaże...(zakładam, ze procesy to nie algorytmy)

Model domenowy. Jest to częśc analizy funkcjonalnej, przynajmneij moim zdaniem :)

nie wyobrażam sobie dziś dobrego analityka, które nie kuma obiektowości.... bo w zasadzie bez tego nie ma on żadnego wspólnego języka z developerami...

:) pozostawię bez komenrtarza :)

dlaczego low-level, :) koncepcyjny opis przypadku użycia (w tym jego scenariusz) i prosty prototyp ekranu to zapis wymagań, projekt go uszczegółowi.....

Racja

Wiesz, jestem projektantem, raczej mowię to co myślę i ze swoich doświadczeń. Widać, że mam jeszcze braki jeśli chodzi o analizę biz/fun. Oczywiście wynika to z tego, że najlepiej człowiek się na czymś zna, jak się tym zajmuje :) A moja domena to jednak projekty teczniczne.

Andrzej Pieniazek:
Poniewaz pracowalem (niejako w "poprzednim zyciu") na paru duzych projektach IT moge potwierdzic, ze najlepsi analitycy nie potrafili programowac. Mieli za to rozne inne umiejetnosci i zdolnosci, ktorych z reguly programisci nie posiadali. Tym niemniej bardzo czesto sie zdarza, ze analityk to "byly programista"..;)

Racja, jestem "skażony" programowaniem, czasami ciężko uciec od dostosowywania rozwiązania do ewentualnego projektu i technicznego rozwiązania. Ramy i możliwości są potrzebne, trzeba mieć ich świadomość, ale z drugiej strony, nie może to ograniczać całego spojrzenia. W końcu najpierw jest "CO" a potem "JAK" :)

Paweł Janusz:
Wiesz, jestem projektantem, raczej mowię to co myślę i ze swoich doświadczeń. Widać, że mam jeszcze braki jeśli chodzi o analizę biz/fun. Oczywiście wynika to z tego, że najlepiej człowiek się na czymś zna, jak się tym zajmuje :) A moja domena to jednak projekty teczniczne.

wiesz, nie w tym rzecz czy ktokolwiek tu ma braki bo nie sądzę byś je miał ;) a by usystematyzować pojęcia, bo mam wrażenie że wiemy o czym tu mówimy ale poszczególne role nazywamy rożnie... drążę ten tema od dość dawna i nabieram przekonania, że:
- brakuje usystematyzowanego nazewnictwa ról w projektach IT
- sposobem częściowego rozwiązania problemy jest chyba nazywanie produktów etapów analizy zamiast nazywanie kto ma coś robić...

dlatego chyba zasadne będzie wskazanie etapów pracy poprzez ich produkty:
- model biznesowy i cel projektu
- model procesów biznesowych
- model dziedziny
- dyskusja i opis definicja zakresu projektu programistycznego
- specyfikacja przypadków użycia wraz z ograniczeniami (czyli wymagania poza funkcjonalne)
- opracowanie logicznej architektury oprogramowania
- IMPLEMENTACJA (i tu kupa roboty) daje działające oprogramowanie

dla mnie wszystko poza implementacją to analiza i projektowanie i jest to zadanie dla analityka biznesowego projektanta. Mając tak opisane wymagania można wykonać analizę wykonywalności i po ewentualnych korektach opracować dokumentacje implementacyjną i
wytworzyć oprogramowanie.

Oczywiście nazewnictwo ról: analityk biznesowy, systemowy, architekt, koder itp.... jest w zasadzie dość płynne, wiele zależy od tego co każda z tych osób potrafi i jakie ma w tym doświadczenie ale nie ukrywam, że dla mnie ideałem podziału na role jest mające tysiące lat historii budownictwo. Biuro architekta daje kompletną dokumentację wykonawczą a developer odpowiada za wprowadzenie jej w życie. Architekt nie musi miec lat pracy jako kierownik budowy ale musi być bardzo dobrym analitykiem, inżynierem i projektantem.

Tak wiec na pytanie koleżanki: Jak zostać dobrym analitykiem odpowiem: poza tym że trzeba do końca życia dużo czytać i pracować na początek trzeba określić samemu sobie jakie dokumenty projektowe chce się samemu przygotowywać :)

P.S.
Ostatni raz programowałem 1991 roku :)Jarek Żeliński edytował(a) ten post dnia 18.01.10 o godzinie 13:31

Najlepiej przejrzeć oferty dostępne na rynku pracy i zapoznać się z wymaganiami na to stanowisko. Jest to najbliższe celu.

Piotr Tomasz Piotrowski:
Najlepiej przejrzeć oferty dostępne na rynku pracy i zapoznać się z wymaganiami na to stanowisko. Jest to najbliższe celu.

niestety z reguły w ogóle nie jest to nawet daleko:)
nie warto spatrzyć Sobie poglądu tak na początku...
z reguły to masz być w ogłoszniech złotą rączką:)
a jak ktoś jest od wszystkiego to jest od... :)

Piotr Tomasz Piotrowski:
Najlepiej przejrzeć oferty dostępne na rynku pracy i zapoznać się z wymaganiami na to stanowisko. Jest to najbliższe celu.

z całym szacunkiem ale wiele ofert pracy bardziej rozśmiesza niż uczy... oferty pracy (wymagane kompetencje) na dane stanowisko raczej odzwierciedlają metodyki stosowane w danej firmie - znaczy się najczęściej jest "wszystkorób za półdarmo" czyli tragedia...

Paweł Janusz:

Jarek Żeliński:
Wybacz, czym tu jest projekt High Level Design :)

Ogólny opis funkcjonalny od strony biznesu, czyli jak my chcialibyśmy aby to działało, na co pozwalało.

To dostaję od klienta w zapytaniu ofertowym/zaproszeniu do przetargu

A kto, po zrozumieniu tego czym się zajmuje klient i na grzyba mu ten system ustala zakres projektu? Innymi słowy: z map procesów mamy 200 czynności realnie wykonywanych a w zakres projektu wchodzi 60 use-case, kto ustala które to będę?

Jak dla mnie to zadanie funkcjonalnego. On Okresl use casy i model domenowy.

to przepraszam z jakiej wielkości projektami masz do czynienia skoro rozbijasz tego typu zadania, jak dla mnie podstawę analizy biznesowej na jakieś nowe stanowiska

Jak skutecznie przekazać z analizy biznesowej takie informacje jak relacje faktura-zamówienie, algorytm naliczenia VAT, liczebność zamówień pod fakturę, itp.? Bo opis procesu nie koniecznie to przekaże...(zakładam, ze procesy to nie algorytmy)

Model domenowy. Jest to częśc analizy funkcjonalnej, przynajmneij moim zdaniem :)

Absolutnie. Co ma określanie domeny do funkcjonalności systemu? Toć to tylko sposób opisania środowiska dla istniejących biznesowo procesów.

nie wyobrażam sobie dziś dobrego analityka, które nie kuma obiektowości.... bo w zasadzie bez tego nie ma on żadnego wspólnego języka z developerami...

:) pozostawię bez komenrtarza :)

developerzy nie mają tu nic do rzeczy; model na wprost składa się z obiektów; czy implementacja będzie obiektowa czy nie to już inna brocha

dlaczego low-level, :) koncepcyjny opis przypadku użycia (w tym jego scenariusz) i prosty prototyp ekranu to zapis wymagań, projekt go uszczegółowi.....

Racja

Wiesz, jestem projektantem, raczej mowię to co myślę i ze swoich doświadczeń. Widać, że mam jeszcze braki jeśli chodzi o analizę biz/fun. Oczywiście wynika to z tego, że najlepiej człowiek się na czymś zna, jak się tym zajmuje :) A moja domena to jednak projekty teczniczne.

low-lewel to porjektowanie algorytmów przetwarzania danych pod określoną wydajność a nie definiowanie scenariuszy usecasow.