Wiedza domenowa w dużych i rozbudowanych projektach

Witajcie, czytałem ostatnio jeden temat "Zmieniacie pracę co kilka lat - a co z wiedzą domenową?" i patrząc na to co dzieje się u mnie w ostatnich latach pomyślałem nad utworzeniem nieco innego tematu.

W skrócie przez ostatnie ~3 lata pracowałem w firmie A (2 lata) i B (aktualna), które były związane z zupełnie odmienną dziedziną biznesu. W pierwszej firmie dotarłem do takiego momentu, że moje braki wiedzy "domenowej", a dokładnie tego co jak działa bardzo mocno ograniczały moją produktywność i po prostu musiałem się zwolnić.

W skrócie wyglądało to tak: Przychodzę do nowej firmy A, zostaje wrzucony do zespołu i przydzielony do jednego konkretnego projektu za który jestem odpowiedzialny w 80%. Po części poznaję co i jak działa w firmie ale wszystko głównie kręci się wokół tego projektu. Reszta zespołu poświęca czas na inne zadania. Po 1-1.5 roku takiej pracy, mój projekt dorósł już do odpowiedniego poziomu gdzie zadań było coraz mniej. Zostałem przydzielony do zadań w obszarze, w którym cała reszta zespołu pracowała przez ostatni rok. W tym momencie dostaje mocnego kopa w dupe, bo wszyscy już śmigają, świetnie rozumieją całą architekturę, a ja pomimo podobnego stażu w firmie zaczynam czuć się jak junior. Ciężko jest mi wejść w nowe zadania bo przez cały rok byłem pochłonięty kompletnie inną pracą, a rzeczy dla innych z pozoru proste, dla mnie są kompletnie niezrozumiałe. Frustracja rośnie, na standupach przewija się masa niezrozumiałych dla mnie skrótów itd. Nadszedł moment, że bez sensu się z tym męczyć i zmieniłem prace.

W nowej firmie jest bardzo spoko, jednak pojawia się podobny problem. Mamy spory zespół, przez pierwsze kilka msc pracowałem niejako nad oddzielnym projektem, który przejmowałem od innego zespołu. Teraz natomiast trzeba wrócić do rzeczywistości i zacząć realizować zadania z backlogu nad którymi pracuje cały zespół. Znów zaczynam odczuwać zaległości. Mamy również dyżury gdzie trzeba reagować na errory z projektów, w których często nawet nie miałem okazji pogrzebać.

Jak to wygląda u Was? Mieliście podobne sytuacje?

moo44 napisał(a):

Nadszedł moment, że bez sensu się z tym męczyć i zmieniłem prace.

Czy wiedza domenowa jest doceniana na rynku czy specyficzna dla tamtej firmy?
To samo pytanie o wiedzę domenową w nowej firmie.

Bo za nietypową, rzadką wiedzę domenową dodatkowo dużo się płaci.
Jest też drugie - janusz-biznesowe - wmawianie pracownikowi, że musi siedzieć i zarabiać mało bo nie opanował jeszcze wiedzy specyficznej dla tego biznesu.

To brzmi jak normalna praca programisty. Praca programisty (i pewnie nie tylko) to ciągła nauka i nie tylko technologi, ale też wiedzy domenowej. I im szybciej będziesz w stanie reagować poprawnie i działać w sytuacjach niedostatecznych informacji, tym lepiej będziesz zarabiał. Klepacze kodu, którzy potrafią dopisać kilka ifów i forów są łatwo zatapialni przez młodych, tańszych przedstawicieli tego zawodu.
A co do strasu jest to normalna sytuacja w życiu człowieka.

Nie chcę się nawet zastanawiać jakby wyglądało moje CV gdybym się zwalniał za każdym razem gdy nie rozumiem biznesu :)
A tak serio, zrozumienie domeny przychodzi z każdym kolejnym wykonanym taskiem. Grunt to zadawać pytania, szczególnie product ownerom, analitykom, biznesowi. Im też zależy, żebyś to zrozumiał i dobrze wykonał task.

moo44 napisał(a):

W pierwszej firmie dotarłem do takiego momentu, że moje braki wiedzy "domenowej", a dokładnie tego co jak działa bardzo mocno ograniczały moją produktywność i po prostu musiałem się zwolnić.

Ale ktoś co kazał się zwolnić czy po prostu sam uznałeś że jesteś niegodny? W rezultacie zamiast Ciebie zatrudnili osobę która jeszcze mniej zna domenę.

W tym momencie dostaje mocnego kopa w dupe, bo wszyscy już śmigają, świetnie rozumieją całą architekturę, a ja pomimo podobnego stażu w firmie zaczynam czuć się jak junior.

To że nie znasz wewnątrz firmowych terminologii nie znaczy że jesteś juniorem. Jakby tak było to każda senior który się zwalnia stawałby się na powrót juniorem

Mam wrażenie że szukasz problemów gdzie ich nie ma. No chyba że ktoś faktycznie zwrócił Ci uwagę. BTW jak przychodzisz nowy do projektu (nie ważne czy całkiem z zewnątrz, czy z innego projektu) to powinieneś dostać chociażby podstawowe szkolenie z tego projektu. Jak szkolenie jest niewystarczające to należy starać się o kolejne doszkolenie

@moo44:
To o czym piszesz to mi nie wygląda na wiedzę domenową, tylko wiedzę projektową.
Wiedzę projektową nadrobić stosunkowo prosto. Najpierw prosi się kogoś (scrum mastera, team leadera) o wprowadzenie, i od początku jasno stawia sprawę: "słuchajcie, byłem w innym projekcie, mogę nie znać wszystkich pojęć, których używacie, będę się dopytywał".
Wiedza domenowa to coś dużo szerszego, coś co nie jest nawet specjalnie związane z programowaniem - to mogą być zagadnienia finansowe, telekomunikacyjne, medyczne, przetwarzanie sygnałów, itp - zależy w jakim sektorze działa firma. Zazwyczaj jak ją masz to nawet zmiana firmy w obrębie sektora nie powinna przeszkadzać.

Gdyby wiedza domenowa była ważna, pracodawcy nie dawaliby podwyżek rzędu 10% co drugi rok, a średnia długość pracy programisty w jednej firmie nie wynosiłaby 2 lata. Osoby biznesowe są zwykle tak zarobione, że trzeba wyciągać z nich wiedzę siłą bo marudzą na próby spotkania się na spotkania a odpowiedzi dają zdawkowe, byleby nie wyjść z inicjatywą w kwestiach o których wiedzą, że mogą być problematyczne. Oczywiście mówię o polskich warunkach bo w zagranicznych firmach sytuacja wygląda zupełnie inaczej.

KamilAdam napisał(a):

Mam wrażenie że szukasz problemów gdzie ich nie ma.
[...] jak przychodzisz nowy do projektu (nie ważne czy całkiem z zewnątrz, czy z innego projektu) to powinieneś dostać chociażby podstawowe szkolenie z tego projektu. Jak szkolenie jest niewystarczające to należy starać się o kolejne doszkolenie

Może OP trafił na firmę w której praktykuje się dołowanie pracownika, często spotykane już na etapie rekrutacji:

• Ale na 30% szczegółowych pytań specyficznych dla naszego projektu nie potrafił pan odpowiedzieć, więc ostatecznie, po wielkich namysłach, ewentualnie i na próbę, za zgodą szefa... możemy pana przyjąć ale co zrozumiałe, nie możemy panu zaoferować widełek minimalnych z oferty bo jak pan rozumie, nie ma pan wiedzy z naszego projektu co wyszło na rekrutacji...

GutekSan napisał(a):

@moo44:

To o czym piszesz to mi nie wygląda na wiedzę domenową, tylko wiedzę projektową.
Wiedzę projektową nadrobić stosunkowo prosto. Najpierw prosi się kogoś (scrum mastera, team leadera) o wprowadzenie, i od początku jasno stawia sprawę: "słuchajcie, byłem w innym projekcie, mogę nie znać wszystkich pojęć, których używacie, będę się dopytywał".
Wiedza domenowa to coś dużo szerszego, coś co nie jest nawet specjalnie związane z programowaniem - to mogą być zagadnienia finansowe, telekomunikacyjne, medyczne, przetwarzanie sygnałów, itp - zależy w jakim sektorze działa firma. Zazwyczaj jak ją masz to nawet zmiana firmy w obrębie sektora nie powinna przeszkadzać.

Racja, wiedza projektowa bardziej tutaj pasuje. Chyba właśnie mam złe podejście, bo mam w głowie wrażenie, że skoro pokazałem się z dobrej strony przy jednym projekcie to już głupio mi się pytać o trywialne sprawy w nowym projekcie (trywialne dla innych, dla mnie niezrozumiałe i nowe). Przez co za dużo czasu poświęcam potem na zamartwianie się i rozkminianie rzeczy samemu, zamiast zapytać.

Druga sprawa to taka, że często niektóre zagadnienia przydają się wyłącznie w firmie X i mam małą motywacje co by uczyć się rzeczy nie przydatnych gdzie indziej. (ale niestety bez tego ciężko daleko w danej firmie zajść)

moo44 napisał(a):

mam w głowie wrażenie, że skoro pokazałem się z dobrej strony przy jednym projekcie to już głupio mi się pytać o trywialne sprawy w nowym projekcie (trywialne dla innych, dla mnie niezrozumiałe i nowe).

No właśnie niestety, ale złe podejście ;p to jest absolutnie normalne, że rzeczy trywialne dla jednego, są niezrozumiałe dla drugiego. I tu nie ma znaczenia staż i bycie juniorem czy seniorem - ten i ten nie zna skrótów z innych projektów i szczegółów ich domeny. Natomiast to co ich odróżnia, to to, że senior nie boi się zapytać o te skróty - dzięki temu, kolejnego dnia już wie więcej. Dzięki temu szybciej się uczy.

Druga sprawa to taka, że często niektóre zagadnienia przydają się wyłącznie w firmie X i mam małą motywacje co by uczyć się rzeczy nie przydatnych gdzie indziej.

Stawiałbym raczej żeby jednak się uczyć tej domeny, nawet jeśli chce się za pół roku opuścić firmę - w nowej firmie nie wykorzystasz wiedzy samej w sobie, ale cały czas podtrzymujesz i trenujesz umiejętność uczenia się. Spróbuj przez 2 lata absolutnie niczego się nie uczyć - zobaczysz, że potem przerobienie nawet prostego tutoriala będzie trudne.

Ja zawsze na rozmowach pytam jak wygląda wdrożenie, czy mają dokumentację, wiki, analityka biznesowego czy jak go akurat nazywają, jakiekolwiek żywe lub nieożywione źródło wiedzy domenowej. Jeśli zmyślają albo reagują śmiechem, to wiadomo, że lekko nie będzie. W obecnej pracy, jako że jestem nowy, to mam osoby, które mogę męczyć pytaniami. Czasem może zadaję głupie pytania z punktu widzenia domeny, bo się nie znam, ale uważam, że lepiej pytać niż udawać że się wie o co chodzi.

Zamiast być konsumentem jakiegoś języka/dialektu zacznij być twórcą. Kreatywni zawsze mają dodatkową premię bo wnoszą coś nowego.

często mam wrażenie, że pewne rzeczy są trywialne (mimo ze ich nie rozumiem) i nie dopytuje aby nie wyjść na głupiego, a potem męczę się drążąc samemu temat.

Ja nauczyłem się w życiu, że nie ma rzeczy oczywistych oraz że dużo ludzi wstydzi się pytać, bo myśli, że coś jest oczywiste. Bardzo często zadaję pytanie rozmówcy "co przez to rozumiesz? co masz na myśli?" i zwykle otrzymuję jasną odpowiedź. Bardzo rzadko zdarza się, że ktoś mi odpowie, że to przecież oczywiste co powiedział. Wówczas mówię, że skoro oczywiste, to nie powinien mieć problemu z rozwinięciem tej wypowiedzi :D
Nie wstydźmy się swojej niewiedzy, bo to nie wstyd przyznać, że się czegoś nie wie. Wstyd może być, jeśli się udaje, że się wie, a przyłapią nas na udawaniu, najczęściej gdy coś się spieprzy.
Ja w moim zespole uczulam, głównie nowych pracowników, żeby nie wstydzili się pytać gdy czegoś nie wiedzą, bo lepiej jeśli będą pytali zawczasu, niż potem naprawiać ich błędy.

Mała anegdotka:

Kiedyś w pracy przyszedł do nas student na miesięczny staż - dawałem mu wskazówki jak wygląda u nas proces, co się po kolei robi itp, no i powiedziałem żeby swoją zmianę wrzucił do code review. Na co on oburzony odpowiedział no ale to tylko builder, to co tu może pójść źle? (nie był to lombokowy builder tylko ręcznie pisany). Oczywiście na code review wyszło sporo uwag xd Nie zaproponowaliśmy mu potem współpracy.