Laravel vs Symfony - zarobki i łatwość znalezienia pracy

Odpowiedz Nowy wątek
2019-09-13 16:44
0

Witajcie.
Mam takie nietypowe pytanie.
W którym frameworki Waszym zdaniem łatwiej znaleźć pracę (Laravel vs Symfony)?
W serwisach typu justjoin.it, nofluffjobs.com widzę że w PL to głównie wykorzystuje się Symfony?
Finansowo wydaje mi się że Laravel stoi troszkę niżej niż Symfony - jakie są Wasze opinie w tym temacie?

edytowany 1x, ostatnio: lukmopy, 2019-09-13 16:49

Pozostało 580 znaków

2019-09-18 11:21
0

@czysteskarpety: to o czym piszesz to projekty-szambo, poprawiałem takie, tam się nie podaje "jak długo" tylko "czy jest wykonalne" xd no ale mając mix laravel + wp prędzej poradzi sobie laraverowiec niż wordpresowiec, a ktoś kto niewiele wie o obu tych systemach polegnie na starcie chyba, że jest mega wymiataczem.

Pozostało 580 znaków

2019-09-18 11:25
0

Dlatego ja już od dawna pracuje za stawkę godzinową, wyceny "za projekt" robiłem w czasach klepania stron o firmie dla pana Janusza.


Pozostało 580 znaków

2019-09-18 11:27
0

@mr_jaro: ale to jest super, bo płacą ci, że w ogóle spróbowałeś, pościemniasz kilka tygodni, zrobisz kilka pushy, co tam pozmieniasz i kaska leci :)


Pozostało 580 znaków

2019-09-18 23:57
0

@TomRZ: większość z nas pracuje za stawkę godzinową no i co to zmienia? Jak przychodzi klient to chce znać orientacyjną kwotę.

Pozostało 580 znaków

2019-09-19 13:28
1

@mr_jaro: jasne zawsze podaje się mniej więcej widelki, jednocześnie zatrzegając, że to się może zmienić w trakcie. Oczywiście wszelkie zmiany powodujące wydłużenie uzasadniasię klientowi. I tu jest najwiekszy problem, bo większość klientów tego nie rozumie, przy czym kiedyś był większy problem niż teraz.

Dlatego stała współpraca z kilkoma podmiotami, gdzie Ty nauczyłeś się klienta, a klient Ciebie jest sprawniejsza, niż praca nad wieloma małymi projektami, których nie da się maszynowo/taśmowo wykonać, bo to oznacza często nerwy, stracony czas, i pieniądze.

Przyszłość małych prostych stron dla Pana/Pani która mało styka się z komputerami i informatyką, to rozwiązania typu wix.com


Pozostało 580 znaków

2019-09-19 15:00
0
TomRZ napisał(a):

Przyszłość małych prostych stron dla Pana/Pani która mało styka się z komputerami i informatyką, to rozwiązania typu wix.com

wix to w zasadzie usługa saas, więc nawet ciężko sprzedać coś czego nie jesteś właścicielem, a klient zwykle chce stronę, pocztę, wsparcie, mało która firma chce tylko wizytówkę obecnie


Pozostało 580 znaków

2019-09-19 16:09
1

Klient się na tym wszystkim nie zna albo ma prawo się nie znać a ponadto to nie ma worka bez dna. Według tego modelu to w zasadzie jakakolwiek realizacja to powinna się odbywać jak najszybciej. Tylko ja się właśnie zastanawiam jak to wygląda w praktyce, kiedy to realizacja projektu się przeciąga ale nie przez nowe funkcjonalności ale np. gdybyście popełnili jakiś błąd projektowy (i musieli potem wrócić i dokonać poprawek)? A nawet przez nowe funkcjonalności które błędnie wyestymowaliście, miało być w ciągu tygodnia, wychodzi w ciągu dwóch.

Pójdźmy dalej, automatyzacja procesów. Ja np. miałem takie prace kiedy to nawet przez kilka godzin główną robotę wykonywał odpalony specjalizowany skrypt do jakiegoś importu/eksportu większej liczby danych a na jego napisanie przeznaczyłem może godzinę albo i mniej. Ciekaw jestem jak to może kontrolować klient? No bo już o ewentualnym słabym sprzęcie albo nieoptymalnie napisanych zapytaniach SQL nie ma co pisać. A więc co to za projekty i jakie to warunki że dużo lepszy jest model rozliczenia na godziny?

Co do projektów szambo, też typowy przykład. Miałem np. wykryć i poprawić kilka błędów w CMS-ie, niestety kod który pisał ktoś inny był na tyle trudny do zrozumienia że udało mi się dojść co i jak dopiero po kilku godzinach. Tymczasem pierwotny autor tego projektu jako że zna kod doszedłby dość szybko. A co w przypadku tego modelu gdyby się okazało że nie udało Wam się naprawić błędu? Też za to weźmiecie kasę?

edytowany 1x, ostatnio: drorat1, 2019-09-19 16:11
1. Obsuwa: U nas mamy call z klientem co 2 dni żeby się wyrównać i ewentualnie zadać pytania wprost + mamy slacka więc klient jest informowany w momencie znalezienia powodu obsuwy, że dłużej to potrwa (i skalę godziny/dni) i podejmujemy decyzję co robimy i jak ważny jest feature. 2. Automatyzacja: Jak mam zadanie typu export danych i trwa 4-5h to nie puszczam tego lokalnie tylko biorę EC2 i tam to odpalam, a komp mam wolny do robienia innych zadań. Takie rzeczy przewidujesz na etapie planowania sprintu - OtoKamil 2019-09-19 17:52
3. Nieukończone zadania: Na takie zadania poświęcasz czas pod nazwą "research". Nie obiecujesz naprawienia błędu, a próbę zlokalizowania przyczyny informując klienta, że może się nie udać bo [i tu wymieniasz powody że nie znasz projektu, nie znasz aż tak dobrze technologii, itd]. Na samą próbę zakładasz deadline np. 4-5h, jak nie znajdziesz to olewacie jeśli to nie jest uber ważne dla biznesu. Jeśli jest ważne to klient może stracić więcej hajsu na biznesie niż wyda na kilka dni devsa. Wtedy klient wie, że wyda na ciebie x$ i że to nie jest strata jak nic nie znajdziesz - OtoKamil 2019-09-19 17:56

Pozostało 580 znaków

2019-09-19 16:13
0

@drorat1 na dzień dzisiejszy też tylko godzinowo robię, a w jaki sposób? rozliczanie etapami, estymacja max na 2 tyg do przodu i określenie co będzie gotowe do odbioru przez klienta z określeniem, że całość może wynieść +20%, w krytycznych miejscach zastrzeżenie że jeśli czas na te miejsce się skończy to bedziemy dalej rozmawiać jak ciągnąć temat.

Co do szambo tak oczywiście, że wezmę kasę za pracę.

edytowany 1x, ostatnio: mr_jaro, 2019-09-19 16:14

Pozostało 580 znaków

2019-09-19 17:35
0

Zdarzało się i to nie jeden raz że za nic nie robienie wpadała mi całkiem ekstra kaska i gdyby to przeliczyć na stawkę godzinową i czas pracy to by wyszło czasem nawet 600 zł na godzinę pracy. Ostatnio nawet w elektronice za wylutowanie i wlutowanie trzech diód LED tak w przeliczeniu na stawkę godzinową to mi wyszło ze 200 zł na łapkę a niewiele się prawdę mówiąc przy tym napracowałem. Tylko że to na ogół małe zlecenia. We wszystkich przypadkach zapłata była bardziej za wiedzę niż za ilość pracy, stąd nie do końca rozumiem zarzuty co do rozliczeń fixed price. Przy większych to estymując tak z kilka mies. pracy nad jakimś portalem to miałem kamienie milowe i rozliczenie w kilku równych miesięcznych transzach (dzieląc wycenę na ilość miesięcy). Oczywiście miąłem propozycję rozliczania tygodniowego, z czego jednak kiedyś zrezygnowałem, były więc miesięczne transze, to ze względu na estymacje czasowe a chodziło o rezultat.

Pozostało 580 znaków

2019-09-19 17:38
0

bo nie rozmawiamy o hot projektach na szybkie coś co wiesz, że się uda i po prostu masz zrobić bo ktoś inny nie ogarnia, tylko o czyms co zajmuje więcej czasu

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0