czy praca w dużej korporacji ma pozytywny skutek na szukanie pracy w przyszłości?

Tak się zastanawiam, bo pracuję od niedawna w Comarchu, ale nie nad tym co jest moim najgłębszym przedmiotem zainteresowań - strony internetowe. Tak się złożyło, że zostałem jednocześnie poinformowany niedawno, że zostałem wybrany przez małą firmę, ale zajmującą się stronami www, w której byłem na rozmowie kwalifikacyjnej 3 tygodnie temu i że mam za tydzień przyjechać i podpisać z nimi umowę. Tylko, że ja już podpisałem umowę z Comarchem - lol - i teraz głupio by było się zwalniać, a myślę, że w CV fajnie byłoby mieć wpis o pracy w takiej korporacji, poza tym wiele można się nauczyć o tym jak wygląda praca w korporacji itp. więc myślę żeby zostać i dopiero po jakimś czasie wrócić do stron internetowych, co radzicie?

W Comarchu też robią strony internetowe, możesz spróbować przenieść się do takiego działu.

Moje wrażenia po pracy w korpo i małych firmach jest takie, że w korpo zazwyczaj jesteś małym trybikiem. Ciężko jest dostać projekt, który wykonasz samodzielnie od początku do końca. Zazwyczaj masz do zrealizowania jakiś wycinek funkcjonalności większego systemu.

Z kolei w małej firmie masz okazję realizować projekt zajmując się różnymi jego aspektami, mając szansę zdobyć doświadczenie w dziedzinach, gdzie nie miałbyś szansy tego zrobić w korpo.

Przykładowo będąc programistą aplikacji webowych w małej firmie możesz poszerzyć swoją wiedzę również z zakresu administracji serwerem, baz danych, frontendu itd. Tymczasem programista aplikacji webowych w korpo jest bardziej wyspecjalizowany i zajmuje się głównie swoją działką. Z drugiej strony tylko w korpo masz szanse realizować bardzo duże projekty dla prestiżowych klientów oraz zdobyć wiedzę biznesową z zakresu bankowości, ERP czy analityki biznesowej.

Jaki to ma wpływ na karierę zawodową? To zależy jaki masz cel. Jeżeli będziesz aplikował do dużej firmy to docenią bardziej doświadczenie w korpo. Z kolei w małej firmie doświadczenie z korpo może okazać się nieprzydatne i niedocenione, ponieważ zamiast specjalisty w jednej działce, będą szukali kogoś bardziej uniwersalnego, który poza kodowaniem, jak będzie trzeba postawi też serwer, zoptymalizuje bazę danych, poprawi frontend, pojedzie na wdrożenie albo odbierze telefon od klienta.

AdamPL napisał(a):

Z drugiej strony tylko w korpo masz szanse realizować bardzo duże projekty dla prestiżowych klientów oraz zdobyć wiedzę biznesową z zakresu bankowości, ERP czy analityki biznesowej.

Chyba nie do końca. Nie mam doświadczenia zawodowego w IT, ale wiem, że są w Polsce mniejsze firmy ~50 pracowników, które robią projekty dla naprawdę dużych graczy i zarabiają na tym nieźle. Of course, nie są to projekty olbrzymich rozmiarów.

@AdamPL, nie uogólniam, chodzi mi właśnie o różnice w wydajności pracy między różnymi firmami/zespołami. Chyba nie powiesz mi, że każdy programista pracuje tak samo sprawnie w każdej technologii.

Na czas realizacji projektu mają wpływ takie kwestie:

1. Specyfikacja - jeśli kierownik jest słaby, nie dogada się z klientem, nie zrozumie jego potrzeb, to system nawet jeśli powstanie będzie do przerobienia.
2. Metodyka - np. starożytna kaskadowa (wiążę się to z powyższym punktem), w której najpierw zbiera się wymagania, a potem po roku przywozi klientowi produkt, który zupełnie nie spełnia jego wymagań. Stosując umiejętnie agile z prototypowaniem i krótkimi iteracjami prawidłowy system powstanie pewno szybciej.
3. Zarządzanie zadaniami - słaby kierownik, źle przydziela zadania, każe pracownikom zajmować się mało istotnymi detalami - to wszystko wydłuża tworzenie projektu.
4. Ludzie w projekcie - jeśli dopiero poznają technologię, nie mają w niej doświadczenia, wynajdują koło na nowo, bo nie wiedzą, że coś jest już gotowe, to będą pracowali wolniej.
5. Wykorzystanie technologii - użycie ORM zamiast pisania wszystkich SQL ręcznie, framework do GUI zamiast tworzenia w WinAPI, itd.
6. Organizacja pracy - wiem, że to dziwne, ale są jeszcze firmy, które nie używają kontroli wersji i bugtrackerów. Komunikacja mailami i ściąganie poprawek z udziału sieciowego nie usprawnia pracy. :)
   Oczywiście to dotyczy zarówno małych jak i dużych firm, w jednych i drugich mogą być szybsze i wolniejsze zespoły. Dlatego właśnie liczba osób i czas trwania projektu więcej mówią o jego koszcie niż o rozmiarach.

Co do zmierzenia rozmiaru projektu - myślę, że dość sensowne są metryki punktów funkcyjnych czy przypadków użycia, które można z grubsza określić liczbą typów użytkowników, dostępnych dla nich opcji w menu i ekranów aplikacji oraz stopniem ich trudności. (Czy ekran odpowiada rekordowi w bazie, czy nie, jak skomplikowana jest walidacja, czy wymaga dodatkowych obliczeń/transformacji?). Wiadomo, że większy system przechowuje więcej rodzajów danych oraz przeprowadza bardziej skomplikowane obliczenia/transformacje, itd.
Do tego istotną kwestią jest wielkość bazy danych (liczba tabel zwykłych, liczba słowników, ale też np. miesięczny przyrost danych). Co za tym idzie, np. kwestia tego, czy raporty mogą być generowane bezpośrednio z tabel, czy wymagają widoków czy już hurtowni.
Liczba użytkowników mówi w sumie o tym, czy trzeba położyć nacisk na wydajność, czy można to po prostu olać, bo i tak zadziała na każdej maszynie. Ale to też poniekąd określa rozmiar projektu, bo oznacza, że trzeba mieć ludzi, którzy się na tym znają.
Z liczbą danych i użytkowników wiążę się też kwestia np. wydzielenia logiki biznesowej od GUI i wsadzenia jej w webserwisy - w małej aplikacji jest to zbędne, duża bez tego może nie działać sprawnie.
Liczbą linii kodu raczej nie da się porównać dwóch projektów, no chyba, że byłyby napisane w tych samych językach przy użyciu tych samych technologii.
Liczba bugów? Nie ma czegoś takiego, są tylko nieścisłości w specyfikacji. ;P

No tak, mam teraz iść do szefa i powiedzieć żeby pogadał z szefem innego działu, bo ja chcę się tam przenieść i nic mnie nie obchodzi, że rekrutował mnie na stanowisko na którym pilnie potrzebny jest programista, a rekrutacja trwała miesiąc. :P Nie no popracuję już na obecnym stanowisku, zawsze będę mieć ładny wpis w CV, a i w przyszłości doświadczenie z tym związane może się przydać.

Zawsze się możesz dogadać w drugiej firmie, że zaczniesz pracę kiedy Ci się skończy okres próbny w CA. Odejścia po okresie próbnym nie są niczym niezwykłym, to jest czas również dla pracownika aby stwierdzić czy praca w firmie mu pasuje.
A jeżeli chodzi o wpływ na karierę to największy wpływ na karierę mają Twoje umiejętności a nie czy pracowałeś w korpo czy w 10 osobowej firemce. Jeżeli w korpo trafisz na dobry projekt to możesz zdobyć więcej wiedzy niż w małej firmie przy słabym projekcie.

Czy ktoś z Was pracuje w korporacjach, a wcześniej pracował w mniejszych firmach? Mógłby jakoś porównać możliwość rozwoju / warunki pracy? Wiadomo, że w mniejszych firmach ma się większy wpływ na rozwój produktów, można czasem samemu podjąć decyzję na temat tego jak ma to być zbudowane / stworzone, na temat architektury systemu, natomiast jak to wygląda w korporacjach ?

@emfałsi: ja pracowałem najpierw w firmie 20 osobowej (3 osoby w teamie), później 200 osobowej (6 osób w teamie), następnie 500 osobowej off-shore (4 osoby lokalnie + 20 w UK), teraz pracuję w 40.000 molochu (7 osób lokalnie, 20 rozproszonych po całym świecie).
Generalne zasady (oczywiście są wyjątki - jak zawsze, wszystko zależy od firmy).

• im mniejsza firma tym więcej robisz, wpływ na projekt w małej firmie sprowadza się czasem do tego, że przychodzi szef mówi: "Chcę ładny produkt" a Ty musisz się martwić o wszystko - kod C,C++,HTML,JS,CSS, source control etc.
• małe firmy są zwinniejsze - skupiają się na osiąganiu celu - wymusza to na nich rynek, są mali, więc nie mogą sobie pozwolić na ociężałość bo ich na to nie stać po prostu. Często sprowadza się to do crunchy i robienia wszystkiego, czy się więcej przy tym nauczysz? I tak i nie - kwestia jak w projekty trafisz pod kątem swoich oczekiwań.
• im większa firma tym większa biurokracja - małe firmy często wychodzą z założenia że nie mają kasy na całe to zarządzanie projektami, biurokrację, podczas gdy im większa firma, tym większa biurokracja (i w projekcie pod kątem IT i pod kątem środowiska pracy ogólnie)
• im większa firma, tym większe zarobki - często prawda, więksi mogą więcej i stać ich na specjalistów. Z drugiej strony czasem podchodzą do sprawy "jesteśmy duzi, więc strata/nie uzyskanie jednego człowieka nas nie zaboli". W małej firmie prędzej się potargujesz i dogadasz z szefem.
• w małej musisz się szybciej rozwijać technicznie, podczas gdy w dużej możesz rozwijać karierę (wiadomo im większa drabinka, tym łatwiej się wcisnąć gdzieś na bok albo na górę)
• w dużej firmie rotacje pracowników są większe - w małych firmach często panuje rodzinna atmosfera, ludzie osiągają jakiś poziom i jest im tam wygodnie, podczas gdy w korporacjach ludzie często nie mają poczucia "patriotyzmu" względem firmy i projektów.

Moim zdaniem - szukasz hobby - znajdź sobie małą firmę pasującą do Twoich upodobań i zestarzej się tam. Szukasz pracy, żeby zarobić na życie - idź do korporacji - większe perspektywy finansowe, lepszy socjal, szkolenia soft-skillowe i inaczej rekruterzy na to patrzą.