Udział tasków deweloperskich i "domenowych"

Siedzę już w trzeciej firmie, za każdym razem w korpo (w jednej firmie byłem takim "udawanym" kontraktorem w rodzaju stażysty, ale i tak zostałem przeniesiony bezpośrednio do klienta).

Z moich obserwacji - za każdym razem dążyło się do tego, by pracownik firmy skupiał się na taskach związanych bardziej z domeną czy produktem niż na taskach deweloperskich (nawet jeśli kadra zarządcza zapewniała co innego). W tym momencie mam wrażenie, że większość moich obowiązków to dogadanie jakichś szczegółów z ludźmi, łatanie dziur w aplikacji, obsługa ticketów, a sama deweloperka to tylko względnie niewielka część pracy. Szczerze - nawet to lubię, chociaż z tyłu głowy cały czas lata myśl, że to doświadczenie niezbyt rozwojowe (no, może poza odnajdowaniem się w spaghetti - chociaż to może niewłaściwe słowo, bo większym problemem niż sama jakość kodu jest architektura z czapy, kod w przejętym przeze mnie systemie jest całkiem znośny, lepszy pewnie niż mój) w razie gdybym chciał kiedyś zmienić firmę i często mam okresy, gdzie kodzenia więcej zapominam niż się uczę mimo że teoretycznie warunki do nauki mam ;).

Jak wyglądało to u Was (bezpośrednio u Was bądź u innych osób, razem z którymi współpracowaliście w jednej firmie) i w jakiego typu firmach (firmy oferujące swoje produkty na zewnątrz, konsultingowe, tworzące oprogramowanie na swoje potrzeby itd.)?

@ToTomki: A mógłbyś podać definicje, czym są taski "developerskie", a czym "domenowe"?
Bo nie wiem, czy dobrze rozumiem, a nie chcę odpisywać bazując na swoim odgadywaniu.

Myślę, ze deweloperskie to takie, gdy masz dane wejściowe takie, masz napisać funkcję/serwis który robi to i tamto i zwraca coś.

Domenowe to takie, że masz się przegrzebać przez gigabajt dokumentacji branżowej projektu i dojść do tego, dlaczego coś nie działa tak jak powinno, po czym to naprawić, co się często będzie sprowadzało do zmiany gdzieś tam True na False.

jeśli developerskie to techniczne - niezwiązane z biznesem, ale np podbicie wersji języka, zmiana biblioteki, wdrożenie chmury, konteneryzacja itp - tego jest mało, bo tu przepala się pieniądze
domenowe - czyli implementacja biznesu - tego jest dużo, bo tu zarabia się pieniądze

To zależy od firmy i konfiguracji zespołu.

Byłem w projektach, gdzie "taski domenowe" robili analitycy biznesowi (BA) ze względu na skomplikowanie domeny i developerzy byli odpowiedzialni wyłącznie za implementację, a jak czegoś nie rozumieli lub było nie jasne to gadali z BA.

Byłem również w projektach, gdzie to developerzy byli odpowiedzialni za gadanie "z biznesem". Przez biznes mam na myśli oddelegowanych do projektu ekspertów domenowych zwanych czasem SME (Subject Matter Expert). Miało to jedną zaletę bo programiści rozumieli dziedzinę biznesową dla której pracowali. Z drugiej strony czy im to do czegoś się później przydało? Z rozmów z nimi wynikało, że nie, bo jak ktoś jest typem kontraktora i pracuje na zasadzie "body leasing" to dziś robi projekt dla bankowości, jutro dla automotive a po jutrze dla wojska i programiści woleli by aby robotę biznesową robił za nich ktoś inny. Ale to zależy od konkretnej osoby. Jedna będzie miała fun z możliwości gadania z biznesem i będzie się chciał specjalizować w jakiejś dziedzinie np. finanse czy bankowość, a druga będzie niezadowolona i będzie się dąsać bo chce robić wyłącznie robotę techniczną i nie obchodzi jej jak firma dla której pisze soft działa pod spodem.

Dlatego moim zdaniem trzeba sobie znaleźć taką pracę z takimi obowiązkami, które będą nam pasować i tyle. Nie ma jakiegoś złotego podziału.

Większość u mnie to praca jak to nazywasz 'domenowa' - my na to mówimy 'produktowa'. Tak generalnie no to o ile nie jesteś projektantem bibliotek czy jakiś 'frameworków' no to przeważnie implementujesz to czego chce biznes/system developerzy, więc musisz zdobyć wiedzę na temat tego co Twój kod dokładnie ma zrobić. Pewnie że każdy chciałby dostać dogadane solution - najlepiej na papierze a samemu pogrążyć się w szukaniu najlepszych bibliotek, struktur danych itp. ale tak dobrze to raczej nie ma - ludzie płacą za to żeby im kod rozwiązywał jakiś problem, nie za to żeby programista mógł sobie pokodzić :) Ja czasamie robię za router - bo wiem który człowiek zna się na której części systemu, i np. siedzę w wątku mailowym i dodaję ludzi którzy mogą odpowiedzieć na pytania.

chyba raz w życiu miałam takie przypadek że wszystko było podane na tacy i tylko dopisać ciała funkcji. na studiach na kolokwium. I tak niektórzy jęczeli że za trudno.
Analityk żeby wiedzieć jakie potrzebne są dane programiście żeby mógł se szukać tych struktur danych musi wiedzieć trochę o programowaniu bo inaczje przekazuje całość od klienta, albo jeszcze lepiej całość z pominięciem najistotniejszej informacji ;)
Przekazywaliście kiedyś podzadania innym? a opisaliście je tak żeby nie musieli o nic dopytywać ;) (gorzej jak nie dopytali i zrobili jakieś g**no)

Kompletnie nie rozumiem podziału. Co to niby jest task developerski, który nie ma nic wspólnego z domeną? Odwrócenie macierzy 100x100 nie wiadomo dlaczego i nie wiadomo po co?

Przecież nie zatrudnili cię raczej do pisania kodu na linie, tylko do rozwijania jakiegoś tam produktu, więc każdy task będzie "domenowy". Inna sprawa, że w zdecydowanej większości firm jest ostre przegięcie na rozwój produktu kosztem długu technologicznego i wielkie zaskoczenie, że w którymś momencie koszty obsługi tego długu rosną.

Pracowałem przez kontraktownię jeden rok w banku bez biznes analityka, gdzie miałem 100% tasków domenowych, dotyczyło to płatności SWIFT. Po godzinach nieraz w weekendy siedziałem i się dokształcałem z tego. Robiłem za dwie osoby jako Java Developer - za analityka i programistę. Swoje płacili, ale nie było to warte w sumie, bo kręgosłup zaczął mnie boleć wtedy pierwszy raz w życiu od ciągłego siedzenia dzień w dzień po 10h.

@ToTomki: w takim razie mam 100% tasków developerskich.

Ale też rozmawiam z ludźmi i też łatam bugi, te kwestie raczej nie zależą od tego, w jakim obszarze się pracuje.