Zmieniacie pracę co kilka lat - a co z wiedzą domenową?

0

Klepię sobie dedykowanego ERPa dla klienta od podstaw w małej firmie od ponad 3 lat, pierwsza praca na/po studiach, a że w "teamie" jest nas 3 to każdy musi wiedzieć wszystko o systemie.

Przychodziłem kompletnie zielony - jakieś podstawy programowania + nawet nie wiedziałem, że to co tworzę to się nazywa system ERP :)
Zero wiedzy o obiegu dokumentów czy innych, księgowych sprawach.

Po tych paru latach, kiedy już dobrze odnajduje się w temacie, widzę, że samo kodowanie nie jest problemem.
Problemem jest wiedza domenowa, żeby ogarnąć co system robi, jak to robi, dlaczego to robi i czego user chce. Zakodowanie tego to już mniejszy problem.

I tak patrzę na te posty ludzi, którzy zmieniają pracę/projekty co rok/dwa lata, dobrze na tym wychodząc finansowo i się zastanawiam - czy faktycznie firmy są skłonne płacić więcej za samą umiejętność programowania?
Przecież gdybym teraz zmienił projekt i poszedł rozwijać - powiedzmy - system do zarządzania rezerwacji lotniczych - to znowu jestem kompletna zielonka.

Co z tego, że koduję niczym mid-level jak w temacie wiedzy domenowej jestem juniorem i potrzebuję zapewne paru lat, żeby powiedzieć, że dobrze czuję temat/działanie systemu jako całości. Tak, żeby projektując jakiś element, mieć jakiś obraz całości, żeby wiedzieć co może mieć jaki wpływ na inne elementy systemu.

A może te zmiany pracy to są w ramach jednego obszaru działalności - ktoś robił CMSy dla firmy A i idzie po paru latach robić CMSy dla firmy B?

Oświećcie mnie jeżeli o czymś nie wiem.

1

O ile się orientuję, to osoby rozwijające systemy ERP są osadzone blisko biznesu i można je pozycjonować pomiędzy technicznymi programistami, a osobami z biznesu. Stąd Twoje dylematy. Jeżeli stracisz wiedzę domenową, to spadnie Twoja wartość jako pracownika.

Natomiast doświadczenie zostaje-widziałeś pewne rozwiązania, komunikowałeś się z ludźmi, rozwiązywałeś konflikty, poznałeś metodyki projektowe etc. to także się liczy. No i w nowym biznesie nie jesteś wypalony.
Nikt też nie zaproponuje Ci, patrząc na Twoje CV (3 lata w ERP) większej kasy na stanowisku programisty C++ czy Angulara.

1

W małych firmach często musisz ogarniać wiele rzeczy, od których w dużych firmach są dedykowane osoby, wiec pewnie w jakimś stopniu to umożliwia tym osobom w miarę łagodną aklimatyzacje w nowych miejscach.

2

Nie muszę znać domeny by kodować o ile mam przygotowana dokumentację, a zawsze powinna być. Mam dokumentacje wiem, co potrzeba więc to koduje. Ewentualnie można robić sesje ostatnio popularnych spotkań z klientem w postaci event stormingu i wtedy "szybko i łatwo" wszyscy zapoznają się z systemem i potrzebami, a mając to wiadomo co kodować. Zazwyczaj w danej domenie robię max kilka miesięcy.

5

Jakbym chciał się przejmować wiedzą domenową to chyba bym nigdy nie zmienił pracy. Jakkolwiek brutalnie to zabrzmi, to uważam, że w interesie pracodawcy / twojego TL, PO, a szczególnie BA jest to, żebyś wiedział co masz zakodować. Jeżeli ww. osoby nie są w stanie sformułować wymagań to jest w głównej mierze problem podmiotu, który wykłada na Ciebie pieniądze. Ty się powinieneś martwić o rozwój i o to, żeby pieniądze się zgadzały.

2
mr_jaro napisał(a):

Nie muszę znać domeny by kodować o ile mam przygotowana dokumentację, a zawsze powinna być. Mam dokumentacje wiem, co potrzeba więc to koduje. Ewentualnie można robić sesje ostatnio popularnych spotkań z klientem w postaci event stormingu i wtedy "szybko i łatwo" wszyscy zapoznają się z systemem i potrzebami, a mając to wiadomo co kodować. Zazwyczaj w danej domenie robię max kilka miesięcy.

Takie rzeczy to chyba tylko w jakichś zabawkowych projekcikach i dotyczą zwykłych klepaczy kodu a nie dojrzałych programistów. Właściwie to już nie programistów tylko inżynierów oprogramowania. Przy dużych i poważnych projektach wiedza domenowa jest dużo bardziej istotna niż umiejętności programistyczne. Dokumentacja? Jest dla klientów, nie dla inżynierów. Inżynierowie to ją tworzą, przynajmniej koncepcyjnie, to znaczy decydują jak ma wyglądać.

1

I tak patrzę na te posty ludzi, którzy zmieniają pracę/projekty co rok/dwa lata, dobrze na tym wychodząc finansowo i się zastanawiam - czy faktycznie firmy są skłonne płacić więcej za samą umiejętność programowania?

Czasem liczy się ogólne doświadczenie i ogarnięcie. Jak ktoś trochę popracował, to szybko się wdroży do nowego projektu, a wiedzę domenową będzie opanowywał w międzyczasie, ale i tak będzie produktywny. Czasem firmy też mają ciśnienie i potrzebują ludzi, a domena może być tak niszowa, że jakby chcieli wybrzydzać i brać tylko ludzi z doświadczeniem w pracy nad tą domeną, to by szukali w nieskończoność.

Kiedyś jak pracowałem w firmie outsourcingowej, to domenę zmieniałem kilkukrotnie w ramach jednej firmy, ale taka była tam po prostu specyfika pracy ;). W kolejnej firmie była już wąska działka większej domeny przez cały czas.

Co z tego, że koduję niczym mid-level jak w temacie wiedzy domenowej jestem juniorem i potrzebuję zapewne paru lat, żeby powiedzieć, że dobrze czuję temat/działanie systemu jako całości. Tak, żeby projektując jakiś element, mieć jakiś obraz całości, żeby wiedzieć co może mieć jaki wpływ na inne elementy systemu.

A może te zmiany pracy to są w ramach jednego obszaru działalności - ktoś robił CMSy dla firmy A i idzie po paru latach robić CMSy dla firmy B?

Czasem tak, a czasem nie :-).

Wiedza domenowa jest niewątpliwym atutem w pracy, ale z drugiej strony nie można sobie też zamykać drogi do pracy w innych działkach. To samo dotyczy innych aspektów (np. język programowania, framework, etc.).

3

Wiedza domenowa ułatwia programowanie ale nie jest warunkiem koniecznym.
W mojej 18 letniej praktyce programistycznej miałem do czynienia z różnymi domenami (hazard, telekomunikacja, energetyka, prawo) i nie miałem problemu z przystosowaniem się. Ba, poznanie nowej domeny, to fajna sprawa :)

1

Mam taką samą sytuację i sam często mam takie myśli (co prawda miałem okazję zmieniać zespół na taki, który zajmuje się czym innym, ale utknąłem w pierwszej firmie póki co). Najprawdopodobniej większość osób tak swobodnie zmieniająca pracę to właśnie klepacze (nie mówię, że wszyscy. Poza tym nie chcę tu też nikogo obrazić - w klepaniu potrzebna jest też wiedza jak robić to dobrze, sprawnie, zgodnie ze standardami, czasem trzeba odkopywać czyjś kod (dla mnie to osobiście dramat), mieć umiejętność rozumienia skomplikowanych mechanizmów). Czym dalej jesteś od hard-kodowania, tym pewnie jest trudniej przeskoczyć na inny kwiatek.
Doszedłem do tego, że to jest grubsza kwestia. W tym momencie pensje programistyczne są dość mocno napomowane (jeszcze) przez różnicę w zarobkach krajów zachodnich i Polski (outsourcing), natomiast się to zmienia i nie wiadomo jak to będzie wyglądało w dłuższej perspektywie czasowej. Zastanawiałem się nad odejściem w stronę bardziej techniczną, ale szczerze to się boję, że standard życia opartego na kodzeniu może nie być do utrzymania przez więcej niż kilka lat. Raczej przymierzam się, by sięgać po coś bliżej biznesu, chociaż nie ukrywam, że to pociąga mnie znacznie mniej.

3

@ToTomki no niestety źle mówisz bo jak sobie poczytasz wiele innych tematów to ci najbardziej doświadczeni zalecają zmiany projektów na inne (a zmiana często wiąże się ze zmianą firmy) bo inaczej się zasiedzisz, a jak się zasiedzisz to się nie rozwijasz. Utrzymywanie raz napisanej aplikacji przez całe życie tylko dlatego, że się nic innego nie potrafi jest po prostu złe.

1

Zależy o jakiej domenie mówimy. W Polsce ogromna większość projektów IT funkcjonuje wokół szeroko pojętych finansów (głównie 2 domeny - ubezpieczenia i bankowość). Jeżeli pracujesz w jednej z nich to faktycznie znajomość produktów i niuansów z nimi związanych zapłaci więcej niż wiedza czysto techniczna. Tak jak ktoś już napisał, jak jesteś klepaczem to takich problemów nie masz. Robisz projekt praktycznie tylko według dokumentacji, ewentualnie po małych konsultacjach. Domenowa wiedza ekspercka nie jest wtedy potrzebna. Jeżeli pracujesz bardziej jako konsultant-programista to wtedy warto się zastanowić nad zmianą domeny. Technicznie będziesz zapewne rozwijał się szybciej, ale trzeba liczyć się wtedy ze spadkiem pensji (często znaczącym). Projekty tak czy tak warto zmieniać, przecież mogą być z tej samej domeny produktowej - nawet w innej firmie.
Tak w skrócie - nie patrz na to czy to system ERP czy nie. Ważne, żeby rozumieć problemy, które występują w danej branży i uświadamiać klientów o tym, że mogą się pojawić oraz jakie mamy możliwości poradzenia sobie z nimi. Programowanie to tylko rzemiosło. Znajomość narzędzi wiadomo, że pomaga, ale w pewnym momencie stanowi to dla Ciebie coraz to mniejszy problem. W dużych firmach IT i biznes bardzo się ze sobą obecnie zazębiają i jeżeli chcesz faktycznie dużo zarabiać (mówię tu cały czas o polskich realiach) to warto to brać pod uwagę.. Mi to odpowiada, siedzenie tylko brzy biurku bywa nudne :)

1

wychodzę z założenia że jak szefowi będzie zależało na zatrzymaniu mojej wiedzy domenowej w firmie to podejmie odpowiednie działania żeby mnie w tej firmie zatrzymać.

4

Widocznie w większości firm nie jest na tyle istotna, ja też mam to w gdzieś. To pracodawcy powinno zależeć, żeby pracownika z taką wiedzą zatrzymać, jeżeli jest dla niego ważna. Jednak z tego co się słyszy to tak nie jest.

5

Co z tego, że koduję niczym mid-level jak w temacie wiedzy domenowej jestem juniorem i potrzebuję zapewne paru lat, żeby powiedzieć, że dobrze czuję temat/działanie systemu jako całości.

To trochę przesada, nie wiem w co chciałbyś wdrażać sie kilka lat. Zwykle to kwestia kilku miesięcy, a cokolwiek więcej jest niemożliwe do utrzymania w głowie ;) Zresztą czy w ogóle jest sens? Na przykład od roku nie było żadnych zmian w jakimś module/serwisie i raczej nie zapowiada się żeby były potrzebne, a już na pewno nie na poziomie architektury, może co najwyżej jakiś prosty bugfix w jednej czy dwóch klasach. Więc czy jest sens siedzieć i się w niego "wdrażać"? YAGNI. Jak będzie trzeba to się wdrożysz.

Tak, żeby projektując jakiś element, mieć jakiś obraz całości, żeby wiedzieć co może mieć jaki wpływ na inne elementy systemu.

Tak to chyba nigdy sie nie da, no chyba że jesteś twórcą i jedynym architektem i głównym developerem tego kodu. W prawdziwym życiu jak kilka miesięcy nie zaglądałeś do jakiegoś serwisu to:

  • już nie pamiętasz dokładnie jak to było zrobione i musisz sobie przypomnieć
  • doszło tyle zmian od innych developerów że i tak to działa inaczej niż pamiętasz

Przecież gdybym teraz zmienił projekt i poszedł rozwijać - powiedzmy - system do zarządzania rezerwacji lotniczych - to znowu jestem kompletna zielonka.

To nie do końca tak jest. Jasne, na rezerwacjach sie nie znasz, ale czym się niby różni stuknięcie do webserwisu getReservationDetails od stukniecia do jakiegoś zupełnie innego serwisu w zupełnie innej domenie? Niczym! Jak dam ci jakiegoś klienta z jasnym interfejsem to jaką ci zrobi różnicę co dokładnie ten klient robi "biznesowo"? To jest trochę jak z wzorcami projektowymi -> pewne mechanizmy pasują wszędzie i nie ma znaczenia że raz masz Factory które tworzy warzywa, a drugi raz masz Factory które robi parsery brainfucka.

Wyobraź sobie że masz poprawić skalowalność robienia tych twoich rezerwacji lotniczych. Przychodzą requesty ale czasem jest spike i serwis nie wyrabia i się dławi. Załóżmy że serws po prostu dostaje jakiegoś POSTa a potem woła sobie jakiegoś klienta który przekazuje tą rezerwacje dalej, ale ta operacja trwa długi. No to nic trudnego, stawiasz jakąś kolejkę, kontroler wrzuca eventy do kolejki a potem N nodów czyta z tej kolejki i wykonuje te "długie" operacje asynchronicznie.
A co jeśli zamiast zrobienia rezerwacji lotniczej te requesty to zupełnie co innego? Czy ma to jakieś specjalnie znaczenie? Bardzo mozliwe że nie ma ;)

Generalnie twoje obserwacje są dobre -> na poziomie mida czy seniora nie ma w zasadzie czegoś takiego jak "wdrożenie technologiczne", bo niby jakie nowinki ktoś tam może mieć? ;) Wszystko już pewnie widziałeś, a nawet jak mają bibliotekę X a ty znasz Y, to idea jest pewnie taka sama a interfejsy i tak są opakowane "firmowymi wrapperami", więc w zasadzie to bez znaczenia. Główny problem stanowi ogarnięcie domeny. Ale tak jak pisałem wyżej, robi sie to na zasadzie "co potrzebujesz" i zdobywasz tą wiedzę w trakcie pracy.
Zmiana dziedziny to oczywiście konieczność nauki nowej, ale czy to taki problem? To jest przecież właśnie ciekawe! Wielu ludzi właśnie dlatego zmienia pracę, bo są znudzeni tym co robią.

Są domeny gdzie jest masa procedur i standardów i faktycznie znajomość dziedziny to spory plus (np. systemy krytyczne, space, defence, czasem też finanse i banki) ale nie jest to reguła i nie jest to raczej "must have" tylko "nice to have". Zresztą co zrobisz jeśli zwyczajnie nie ma na rynku takiego unicorna którego szukasz? :)

1

Problemem jest wiedza domenowa, żeby ogarnąć co system robi, jak to robi, dlaczego to robi i czego user chce.

Ja myślę, że w tym przypadku nabycie wiedzy dziedzinowej to często efekt końcowy całego procesu, a nie coś co się "ma" i rozporządza.

żeby ogarnąć co system robi, jak to robi,

Może mam takie a nie inne doświadczenia, ale zwykle trudność z ogarnięciem "co system robi" polegała na tym, że systemy były słabo napisane pod kątem kodu/architektury kodu, a nie na skomplikowanej dziedzinie. Może nie programowałem jeszcze w super skomplikowanych dziedzinach, ale przypuszczam, że projekty pisane w skomplikowanych działkach biznesu mogą być napisane jeszcze gorzej pod kątem kodu (bo trudną dziedzinę ciężej jest ogarnąć rozumem, więc można przypuszczać, że jeszcze więcej byłoby spaghetti i haków. Jak coś jest łatwe pod kątem dziedziny czy wymagań biznesowych jako takich, np. kolejny CRUD bez udziwnień, to się kod pisze łatwo, korzystając ze wcześniejszych doświadczeń).

dlaczego to robi i czego user chce.

Ale, żeby się tego dowiedzieć są potrzebne: wyczucie biznesowe, empatia, umiejętność komunikacji z innymi, a także krytyczne, refleksyjne i empiryczne podejście... Czyli skille miękkie i świadome dążenie do tego, żeby zrozumieć temat. To nie jest tak przecież, że wchodzisz do projektu, kodzisz sobie coś i z samego kodu i dokumentacji wyczytujesz wiedzę dziedzinową i po kilku miesiącach zagrzebania się w kodzie jesteś jakimś ekspertem dziedziny. No chyba nie.

1

Tu chyba jest rozjazd między tym co kto uważa za wiedzę domenową.
"Problemem jest wiedza domenowa, żeby ogarnąć co system robi, jak to robi, dlaczego to robi i czego user chce." - to chyba jest bardzo uboga część wiedzy domenowej, pozostaje jeszcze masa pytań typu "co jeśli zmieni się w systemie x na y, z, a, b, c, d, w prawie zmieni się g, h lub c, a jeszcze w grupie, do której należy firma ktoś wprowadzi standard prawa międzynarodowego l, a tak w ogóle to wprowadzenie y i h powinno skutkować poprawką q, ale bez wiedzy o p nie można o tym wiedzieć. Te kilka pytań z cytatu wyglądają mi trochę jak pytania kierowane przez osobę typowo przepisującą dokumentację na kod zrozumiały dla komputera, ale ja nie mam komercyjnego doświadczenia w stricte programowaniu tylko siedzę z boku, więc ciężko mi powiedzieć jak to jest i trochę strzelam na oślep. Fajnie by było zobaczyć więcej wiadomości od osób, które bywały mocno i w biznesie w korpo, i w dziale technicznym.

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