To jest 292 . Odcinek podcastu Porozmawiajmy IT W ramach naszego cyklu . Wraz z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT Solid Jobs , tak tego , który mam przyjemność współtworzyć rozmawiamy o byciu liderem i zarządzaniu zespołem IT . Będzie trochę poważnie , trochę z przymrużeniem oka , ale zawsze na temat . Zapraszamy do słuchania i komentowania . Startujemy , cześć Łukasz , cześć Krzysztof . Kontynuujemy nasze podcastowe spotkania w ramach serii dla lidera i menadżera IT . Dzisiaj będziemy mówić o tym , że lider IT nie tylko mikro-managementem żyje , ale czasami też musi błysnąć wiedzą . I to wiedzą nie byle jaką , bo związaną z domeną i z produktem w którym się porusza . Ale żeby sobie poukładać tutaj te różne rodzaje , różne fragmenty wiedzy bo o niejednej już powiedzieliśmy , to może Łukasz zacznijmy od takiego rozróżnienia i krótkiego zdefiniowania czym właściwie jest i czym się różni wiedza techniczna , domenowa i produktowa .
ŁukaszTak jak powiedziałeś , możemy zakwalifikować wiedzę ogólnie w takie trzy kubełki . I tak , wiedza techniczna , czyli to jest ta wiedza którą mamy , my osoby techniczne , która mówi nam jak dobrze budować produkty , to jest też cała ta wiedza związana z rozwojem oprogramowania . Niekoniecznie ona musi być taka stricte techniczna , może to być pewna metodyka rozwijania oprogramowania , na przykład także testerzy mają swoją wiedzę techniczną , jak w sposób efektywny i systematyczny walidować i weryfikować oprogramowanie . Drugi taki obszar wiedzy , to jest wiedza produktowa , czyli to jest wiedza konkretnie związana z naszym produktem , czyli np , jeśli mamy dwa konkurujące ze sobą produkty , no , to pewne czynności mogą być wykonywane . Te same czynności , jakby prowadzące do tego samego celu , mogą być wykonywane w różny sposób . I tutaj posiadamy tą wiedzę produktową związaną np z naszym oprogramowaniem , czyli wiemy , jak coś zrobić u nas . No , i jest ta wiedza domenowa o której dzisiaj będziemy rozmawiać , czyli wiedza związana z całym obszarem tematycznym .
ŁukaszCzyli jeśli na przykład rozwijamy produkt , który służy do wystawiania faktur , to byłaby to wiedza z zakresu finansów W przypadku , na przykład , produktu medycznego . Na przykład , jaka to wiedza z zakresu finansów W przypadku np . Produktu medycznego ? np . Jakaś wiedza na temat wystawiania recept albo zasad refundacji leków ?
KrzysztofWłaśnie , i dlaczego to jest istotne w kontekście lidera i menadżera IT ? No , bo można by było powiedzieć że w końcu z definicji jest to rola raczej związana z zarządzaniem , rozwojem zespołu . A my tutaj mówimy , wspominamy o wiedzy domenowej , która gdzieś tak może się wielu słuchaczom jednak podskórnie kojarzyć z product ownerem , product managerem , być może jakimś tutaj managementem wyższego szczebla , który zajmuje się właśnie rozwojem produktu . My to wspominamy w kontekście takiego engineering menadżera , czyli osoby , która na co dzień jednak zajmuje się i skupia na zarządzaniu zespołem jako takim , czy też tą działką właśnie techniczną . No , i wymieniliśmy sobie tutaj czy wskazaliśmy dwa takie obszary na które to może wpływać właśnie to , czy menedżer posiada jakąś wiedzę związaną z tą domeną , czy też jej nie posiada . I takim pierwszym pewnie obszarem jest to ,
że po prostu wpływa to na produkt , na jakość pracy , na to , co ten zespół dowozi . Co byś tutaj mógł , łukasz , wymienić właśnie w tym kontekście wpływu wiedzy domenowej na produkt czy też na efekt pracy zespołu ?
ŁukaszTak , ja jestem w ogóle zwolennikiem takiej teorii , że wiedza domenowa jest takim fundamentem efektywnego nie tylko zarządzania produktem , ale też właśnie rozwijania produktu . To znaczy , że to , że nasz zespół posiada tą wiedzę domenową po prostu pozwala tworzyć lepszy produkt , pozwala unikać błędów , pozwala lepiej zrozumieć problemy użytkowników , pomaga definiować wymagania , ale też na przykład priorytety pewnych funkcji , nowych funkcji w systemie , pozwala też w pewien sposób na ogarnięcie zlotu ptaka całości systemu i na przewidzenie po prostu jak pewne na przykład nowe funkcje wpłyną na inne części systemu , czyli też jakby pozwala nam na to , że widzimy ten system w całości i rozumiemy też lepiej użytkownika .
KrzysztofMyślę , że tu by taką analogię można było wystosować . Jak to ma odniesienie do , na przykład , bycia programistą ? Jeśli mówimy , że programista ma tylko jakiś określony swój wycinek , tylko zajmuje się tym obszarem , na przykład tym sławetnym już klepaniem kodu , ale już raczej aspekty utrzymania , wdrożenia czy też testowania go w ogóle nie interesują , no , to oczywiście ta jakość czyjej pracy będzie mniejsza . Ale jeśli ta sama osoba zainteresuje się właśnie wszystkim tym , co jest związane z całym tym etapem czy też procesem wytwórczym , no , to oczywiście będzie to miało bezpośrednie przełożenie na jakość pracy i też na jakość wynikową . I myślę , że identycznie tutaj jest w przypadku menedżera IT , który oczywiście powinien zajmować się i powinien znać się na zarządzaniu jako takim , na rozwoju zespołu , ale również mieć właśnie tą wiedzę związaną z domeną . Tu się pojawia pytanie , czy powinien być ekspertem domenowym , tak zwanym , czy też wystarczy , żeby jako tako rozeznał temat . Co myślisz ?
ŁukaszTak jak ja wspominałem , moją taką tutaj autorską tezą jest to , że cały zespół powinien dążyć do tego , żeby stać się właśnie takim ekspertem domenowym . No , i tutaj znowu mogę tą anegdotę opowiedzieć , którą już pewnie nasi co pilniejsi słuchacze już słyszeli , czyli w przypadku na przykład systemu medycznego mieliśmy taki przypadek , że pewne procedury czy pewne refundacje procedur są dostępne na przykład tylko dla kobiet , które są w ciąży , są dostępne na przykład tylko dla kobiet , które są w ciąży . No , i tego typu wiedza może pomóc uniknąć błędów , uniknąć tego ,
że właśnie te refundacje odpowiednio zostaną przypisane , nawet jeśli gdzieś tam w wymaganiach w ticketzie ktoś się pomyli , w TIC-ecie ktoś się pomyli . To , jeśli wiemy , że teraz robimy specjalne case'y dla jakiejś docelowej grupy odbiorczej , to dzięki tej wiedzy unikniemy błędów , lepiej zrozumiemy system i będziemy mogli naszym analitykiem rozmawiać tak jak równy z równym i tutaj też dochodzić do tego , o co rzeczywiście chodzi użytkownikowi .
KrzysztofTak , no , i tutaj , jak gdyby idąc tym tropem , że menedżer bardzo często jest przykładem , albo przynajmniej powinien świecić przykładem , no , to pewnie powinien najpierw wymagać od siebie tej wiedzy , dopiero później od zespołu , albo wręcz inicjować właśnie takie przekazywanie wiedzy czy też to , że zespół też rozwija , się te swoje kompetencje rozwija , nie tylko w kierunkach technicznych , ale również związanych z domeną . Moje zdanie jest takie , że oczywiście tutaj bycie ekspertem nie jest pewnie wymagane . To oczywiście też zależy od organizacji . Miałem okazję pracować w mniejszych startupach , gdzie często ta rola związana z zarządzaniem zespołem i rola związana z zarządzaniem produktem to właściwie się łączyła , i to była jedna osoba , która była menadżerem i jednocześnie jakimś powiedzmy product ownerem czy też project menadżerem Idąc w kierunku jakichś większych organizacji .
KrzysztofTam bardzo często mamy już takie rozróżnienie na osobę , która się specjalizuje w zarządzaniu zespołów IT i w zarządzaniu produktem . Często są to , powiedzmy różne wręcz osoby . Pewnie wówczas ma to sens W takim wydaniu manager IT nie musi być ekspertem domenowym , ponieważ bardzo często ma osoby w swoim zespole albo w firmie , które lepiej się wręcz na tym znają , i to jest ich zadanie . No , ale im gdzieś tam głębszą tą wiedzę posiądzie , to zdecydowanie tylko na plus . Bardzo często też widzę takie układanie tej kariery właśnie związanej z zarządzaniem , że osoba , która powiedzmy już zostanie . Tutaj w tym obszarze , dajmy na to finansów gdzieś się wyspecjalizowała to później idąc do kolejnej firmy , no , również szuka tego typu właśnie organizacji . No , bo zwyczajnie lepiej się tutaj na tym obszarze zna i wręcz myślę , że to może być taka naprawdę duża przewaga na rozmowie kwalifikacyjnej czy też właśnie w rekrutacji , jeśli mamy już taką wieloletnią , gdzieś tam praktykę związaną z danym obszarem tematycznym . No , to zdecydowanie takie połączenie kompetencji zarządczych oraz związanych właśnie z tą domeną jest na plus . Kompetencji zarządczych oraz związanych właśnie z tą domeną jest na plus .
ŁukaszTak . Natomiast osobiście jakbym zatrudniał kogoś , to nie szukałbym jakby tej wiedzy u tego kogoś . Wydaje mi się że jest coś co powinniśmy zadbać w firmie , żeby ta wiedza była i żebyśmy umieli ją wymienić i nauczyć ludzi . Osobiście nie uważam że to jest powód żeby kogoś skreślić , na przykład na rekrutacji , albo wybrać tego kandydata albo drugiego . Ja bym raczej wybrał jednak tego który jest lepszy technicznie . Natomiast na pewno jest to atut w rekrutacji i jakaś przewaga nad innymi . No , i tutaj jeszcze chciałbym , podsumowując jakby tą pierwszą część , to chciałbym określić jakby że ta wiedza pozwala nam nie tylko wiedzieć co robimy , ale też dlaczego coś robimy , i to jest jakby ta kluczowa przewaga , czyli zaczynamy jakby od dlaczego .
KrzysztofBardzo klasyczne , ale pewnie ciągle słuszne podejście . Tak wiesz , ja może tutaj dopowiem do tego rekrutowania i dodatkowych punktów dla osoby , która ma już jakieś doświadczenie związane z daną domeną . To oczywiście zależy , jak zawsze . Natomiast , jeśli szukamy kogoś na tu i teraz , kto ma dosyć sprawnie i szybko wskoczyć w jakąś domenę , no to pewnie , jeśli poszukamy kogoś , kto już ma określone doświadczenia , to ten start może być szybszy , ten onboarding może być krótszy . No , można byłoby powiedzieć , że oczywiście to nie zawsze jest dobra rzecz , ponieważ ktoś przynosi pewne jakieś swoje naleciałości , doświadczenia już uformowane . No , ale tak to musimy tutaj zważyć . Jaka jest specyfika tego projektu i tej roli , na którą kogoś rekrutujemy .
ŁukaszChciałem tutaj właśnie ciebie trochę podpytać , jak twoim zdaniem właśnie ta wiedza domenowa , jak nią zarządzać w zespole , jakie byłoby twoje podejście tutaj ?
KrzysztofTak wskazałbym dwa tutaj obszary Przede wszystkim rozwój menadżera w tym temacie . No , i też pewnie jeden z obowiązków takiego menadżera , którym jest zarządzanie tą wiedzą domenową wśród osób z jego lub jej zespołu . Myślę , że , tak jak już tutaj wspomniałem , trzeba świecić przykładem , i nie byłoby dobrym takie podejście , gdzie wymagamy czegoś od naszego zespołu , aby specjalizowali się w tej domenie , a my w tej domenie się jakoś tam nie rozwijamy . Więc od tego zdecydowanie bym zaczął . Myślę , że tutaj takie powolne włączanie i siebie i członków zespołów różnego typu , chociażby spotkania z tym przysłowiowym biznesem , produktem , coraz bliższy styk , zmniejszanie tego styku do klienta , do realnych problemów , które użytkownik może mieć , to jest taki naturalny sposób do tego , żeby tą wiedzę gdzieś tam zdobywać i ją nasiąkać . Natomiast , jeśli mówimy o jakichś konkretnych narzędziach czy praktykach , to oczywiście klasyczne tworzenie bazy wiedzy , coś , co jest bardzo przydatne kiedy nowa osoba dołącza do naszego zespołu . To może być wręcz taka wspólna praca całego teamu nad tym , żeby tę bazę wiedzy utrzymywać i rozszerzać . Myślę , że takie produkowanie treści też służy oczywiście temu , żeby sobie tę wiedzę układać . Jak najbardziej może to być przydatne . Jeśli mówimy czy też przechodzimy troszkę bliżej już produktu , no , to można powiedzieć , że też udział i nas jako menadżera i poszczególnych członków zespołu w tworzenie instrukcji , tutoriali dla użytkowników końcowych , no , to też jest doskonały sposób na to , żeby tą wiedzę gdzieś tam nabywać , żeby przynajmniej sobie to wszystko poukładać , przemyśleć , zastanowić się , czy to ma sens .
KrzysztofKlasyczne szkolenia jak najbardziej możemy tutaj też wymienić . Oczywiście chodzi tutaj o szkolenia związane z tą domeną , z tym obszarem tematycznym . Jak najbardziej możemy , układając jakiś plan tych szkoleń czy rozwoju takiego zespołu , uwzględnić tego typu szkolenia , które są związane właśnie z tą materią na której pracujemy . Bardzo często też okazuje się , że w tych organizacjach mamy już ekspertów domenowych . Tutaj myślę , że właśnie księgowość i obszar finansowy jest takim dobrym przykładem . Tam często pracują również osoby , które na tym obszarze się doskonale znają , są takimi ekspertami domenowymi . Więc jak najbardziej można tutaj że tak powiem w cudzysłowie wykorzystać te osoby , żeby podzieliły się również tą swoją wiedzą wśród członków naszego zespołu .
ŁukaszChciałbym nadmienić kilka punktów . Po pierwsze bardzo fajnie , jeśli tworzymy produkt , z którego sami możemy korzystać w firmie , to wtedy jesteśmy też użytkownikami i też
mamy inny obraz . Ja też właśnie zauważam , jak mam okazję korzystać z naszego systemu , to znajduję jakieś niedoskonałości albo jakieś rzeczy , które można by zrobić sprawniej i szybciej , i udaje się wtedy np wdrożyć takie poprawki . Ja jako lider zespołu miałem taką metodę , że po prostu raz w tygodniu albo raz na dwa tygodnie robiliśmy takie dziesięciominutowe szkolenie , i to było tak , że każdy członek zespołu po prostu w takim randrobinie na zmianę opowiadał o czymś , na czym się znał , i w ten sposób tutaj się wymienialiśmy wiedzą .
ŁukaszNa przykład programista , który akurat robił coś związanego z receptami , za tydzień tutaj był prelegentem i innym osobom opowiadał coś o tych receptach . Ktoś , kto zajmował się jakimiś uprawnieniami pacjentów , na przykład EW7 , na przykład tester , który to testował , to też za tydzień miał kilka minut żeby opowiedzieć , co tam się dowiedział , na co natrafił . No , i tu nie chodziło , żeby to były nie wiadomo jak szczegółowe długie szkolenia , właśnie takie 10 minut raz w tygodniu , raz na dwa tygodnie . Też nauczanie jest najlepszą formą tego , żeby samemu się uczyć .
ŁukaszI jeszcze ostatnia rzecz do Twojej długiej wypowiedzi się odniosę także długą wypowiedzią , czyli reużywanie tej wiedzy , tak jak mówiłeś , tworzenie na przykład w to nasze zdobywanie wiedzy , czyli nie tylko teraz my użyjemy tego wewnętrznie , żeby czegoś się dowiedzieć . No , ale powstanie jakiś artykuł na przykład na bloga naszego , albo jakiś tutorial wewnętrzny w systemie , może jakaś po prostu instrukcja dla użytkownika w formie PDF-a albo w jakiejś innej formie , no , i to wszystko po prostu można reużywać na różne sposoby . Też materiały , które są zewnętrzne można spróbować użyć wewnątrz naszej organizacji , albo materiały , które są wewnątrz zaadaptować na to , żeby nadały się do tego , żeby gdzieś tam na zewnątrz je pokazać . To tutaj kończę moją wypowiedź . Natomiast chciałbym jeszcze kontynuować .
KrzysztofJasne .
ŁukaszPonieważ natomiast chciałbym jeszcze kontynuować , ponieważ powiedzieliśmy tutaj o tym , ja może powiedziałem , że cały zespół powinien być ekspertem domenowym , to chciałbym rozszerzyć to cała firma powinna być ekspertem domenowym . Nie wyobrażam sobie , żeby dział sprzedaży albo dział marketingu także nie był super zaznajomiony z tą domeną w której jesteśmy . Dzięki temu łatwiej jest właśnie rozmawiać z klientem , łatwiej mu jest po prostu sprzedać ten nasz produkt , jeśli rozmawiamy tym samym językiem i jeśli rozumiemy problemy naszych klientów , jeśli nawet sami zaczniemy od tego , że tu są takie problemy i my je rozwiązujemy tak i tak . I nieraz już tak miałem , że zdarzyło się , że klient powiedział o właśnie wybiorę was , bo tutaj mamy ten niś porozumienia i rozmawiamy tym samym językiem .
KrzysztofTak , to jest też , myślę , istotna przewaga dla firmy , która ma taką kulturę , można powiedzieć organizacyjną , gdzie inwestuje w rozwój tej wiedzy domenowej wśród pracowników , również technicznych , również osób zajmujących się zarządzaniem , że te osoby z taką wiedzą zwyczajnie mogą uczestniczyć w różnego typu spotkaniach , np przykład z klientami , z potencjalnymi klientami , tak zwani pre-sellersi , którzy łączą tę wiedzę właśnie i domenową i techniczną , i wówczas budują tego typu zaufanie ze strony tego potencjalnego klienta , że o tam pracują ludzie którzy się na temacie znają , którzy potrafią gdzieś odpowiedzieć na pytania , którzy wiedzą , z jakimi problemami się zmagamy .
Krzysztofwięc to jest zdecydowanie na plus I to jest , myślę , też taka odpowiedź na zarzut , który gdzieś można tutaj usłyszeć w tym temacie , że okej , no , jesteśmy osobami technicznymi , więc de facto tą naszą główną korową umiejętnością powinny być właśnie te skille techniczne . Powinniśmy dostawać dobrze zdefiniowany zbiór wymagań i go implementować , niekoniecznie wnikając w to , jak to się tam przełoży na sposób użytkowania przez użytkowników końcowych i tak dalej . Myślę , że to można bardzo łatwo zbić , mówiąc właśnie o tym , że nie da się tak w pełni tego odseparować i po prostu ta wiedza domenowa powinna krążyć , ponieważ każdy może też mieć jakiś swój wkład , prawda , również osoby techniczne jak najbardziej mogą mieć swój wkład w rozwój produktu , i ta wiedza domenowa jest przydatna .
ŁukaszNic , tylko się zgodzić .
KrzysztofDobrze , jak wobec tego tutaj byś rozróżnił , albo czy w ogóle jest potrzebne takie rozróżnienie w pracy menedżera na te obowiązki tak bym to może nazwał związane z produktem , z wiedzą domenową , versus właśnie zarządzanie . Czyli czy gdzieś jest , czy w ogóle musi być jakaś taka granica pomiędzy , powiedzmy rolą product ownera a menadżera IT , czy też nie ma w tym nic złego , aby jakaś jedna osoba łączyła te dwie odpowiedzialności ?
ŁukaszJa zawsze twierdzę , że to zależy , i każda organizacja jest inna , w każdej firmie jest inna dynamika , zespół jest no , inne są możliwości tutaj , jeśli chodzi o rozmiar zespołu . Są firmy w których właśnie każdy ma dwie czapki na głowie , są firmy , gdzie jedną drobną pierdołą się zajmują trzy osoby . Także to w dużej mierze zależy , i chyba nie chciałbym tutaj tak stawiać jakiejś granicy , cenzury między jednym a drugim . Natomiast tak mi się wydaje , że powinniśmy dążyć do tego właśnie , żeby tak jak za jakość odpowiada cały zespół , to tak samo właśnie za to , żeby ta wiedza domenowa była , to powinniśmy tutaj wszyscy odpowiadać .
ŁukaszJeszcze jedną taką krótką anegdotę mogę powiedzieć na przykład szczepionki I tutaj między podaniem jednej a drugiej szczepionki na przykład powinniśmy mieć jakiś okres przerwy , czyli na przykład między jedną a drugą 4 tygodnie co najmniej odstępu . I teraz w wymaganiach pojawia się tak , że między szczepionką A a szczepionką B ma być te 4 tygodnie . Natomiast nic nie było w wymaganiach
o tym , że między szczepionką B a A powinna także zostać taka przerwa ujęta . A dla nas tutaj jako logicznie myślących osób czy wiedzących , jak po prostu szczepionki działają , no , to jest oczywiste , że taka zależność powinna być dwustronna . No , i tego typu nawet prostsze spostrzeżenia , czyli to nie musi być taka wiedza stricte , gdzieś tam zdobyta , to może być . Taki też zdrowy rozsądek pozwala uniknąć pewnych błędów .
ŁukaszI po prostu , ktoś , kto pisał wymagania , no , to się spodziewał , że skoro pierwsza szczepionka należy ją podać między drugim a czwartym tygodniem życia , a drugą między czwartym a szóstym . Załóżmy to , ta kolejność powinna być zachowana . Ale okazuje się że niekoniecznie , bo na przykład dziecko mogło przyjechać z innego kraju , gdzie są jakieś inne szczepionki , albo czasami są też łączone tam też 6 w 1 , itd . I wtedy ten 6 w 1 w jednym kraju może być np czymś innym niż w drugim . Sytuacje są różne .
KrzysztofNo tak , bo można by też tutaj powiedzieć o przynajmniej dwóch takich sytuacjach , kiedy nadmiar tej wiedzy domenowej może przeszkadzać i szkodzić . Pierwszą jest taka zbyt duża pewność siebie ze strony menadżera , który już tutaj tak obrócł w piórka , że wydaje mu się , że tym ekspertem domenowym jest może kwestionować .
ŁukaszTak , i to może powodować to , że nie słuchamy wtedy naszych użytkowników .
KrzysztofWłaśnie , właśnie .
ŁukaszTo może być źle .
KrzysztofDokładnie . To się też może przełożyć na właśnie mikrozarządzanie naszym zespołem . No , bo wydaje nam się , że jesteśmy tutaj już takimi ekspertami , że tylko my najlepiej wiemy jak powinny być sprawy rozwiązane . No , jedna i druga sytuacja jest oczywiście szkodliwa dla zespołu . Dobrze , łukasz , to jeszcze może tutaj . Na koniec powiedzmy , jakie są sposoby zdobywania tej wiedzy domenowej . Wspomniałem już o tym , że taki udział w różnego typu spotkaniach związanych z produktem czy spotkaniach z użytkownikami , klientami , może być dobrym sposobem , żeby można powiedzieć takim żywym organizmie albo z pierwszej ręki dostawać informacje , jak ta domena działa . Jakie są problemy , oczywiście z jakimś tam wyważeniem jeśli chodzi o liczbę tych spotkań w przypadku osób technicznych Czy o jeszcze jakichś innych metodach pozyskiwania wiedzy domenowej ?
mógłbyś powiedzieć Oczywiście najcenniejszym źródłem wiedzy są nasi klienci , osoby które korzystają z naszego systemu . Jeśli możemy z nimi porozmawiać , no , to jest to zawsze super okazja żeby się czegoś dowiedzieć . Co jeszcze No ? różnego typu konferencje , szkolenia , takie właśnie dziedzinowe . Na przykład naszego analityka możemy wysłać na takie szkolenie , które jest stricte związane Znowu będę tutaj się poruszam w tym przykładzie medycznym . Ale załóżmy , że mamy rozliczenia z NFZ-em i jest jakieś szkolenie na temat jakichś tam rozliczeń , nie wiem , usług stomatologicznych . Możemy naszego analityka wysłać na takie szkolenie a potem liczyć na to , że tą wiedzą się podzieli w zespole ?
KrzysztofJa bym do tego może dorzucił jakiś już pewnie skrajny przypadek , ale ciągle możliwy , i znam takie , mianowicie pójście na jakieś studia podyplomowe związane z tym obszarem . To jak najbardziej też daje nam solidną podstawę . Oczywiście jest wymagające i może czasowo być tutaj dużym obciążeniem . Aczkolwiek jest to z pewnością mocna rzecz .
ŁukaszNatomiast u mnie na studiach na Politechnice Poznańskiej , na dodam , informatyce mieliśmy SMS finansów , i to właśnie było stricte zrobione pod to że po prostu , żebyśmy byli programistami systemów związanych z tą domeną finansową , ponieważ jest to tak jakby popularna i częsta domena która występuje w wielu systemach . Wystawianie faktur . tak , Kto nigdy nie wystawiał faktur , Ten ma szczęście . Tak , to , chyba nie znam takich osób .
KrzysztofTakże po prostu na studiach może być taki kierunek czy taki przedmiot , z pewnością jakiś taki efekt kumulacji , jeśli jest systematycznie , regularnie powtarzana . Obtoczenie się jakimiś podcastami , youtubami i tak dalej związanymi z daną domeną też z pewnością pomaga , bo łatwiej nam chłonąć tą wiedzę z różnych źródeł niż tylko z jednego . Więc otoczenie się tymi różnymi źródłami wiedzy związanej z tą naszą domeną jest pewnie najprostszym rozwiązaniem . Dobrze , łukasz , myślę , że tutaj jasno pokazaliśmy , że wiedza domenowa w przypadku menadżera IT przynajmniej pomaga , o ile nie jest niezbędna . Przekłada się na to , że jakość wynikowa pracy zespołu jest lepsza , to , że również sam zespół się lepiej rozwija . To wszystko oczywiście wpływa na satysfakcję z pracy . Więc warto również tą nogę rozwoju swojego budować , żeby tutaj mocno i stabilnie stać w przypadku rozwoju kariery .
ŁukaszCo może . Spróbujemy podsumować tradycyjnie Jasne . Nasze tutaj różne rozmowy obracają się często wokół tego , że pewne rzeczy są narzędziami . I tak bym właśnie traktował tą wiedzę domenową jako pewnego rodzaju narzędzie , które pozwala nam właśnie na efektywne zarządzanie produktem , na to , żeby w pewien sposób przeciwdziałać pewnym błędom , na przykład logicznym , i zrozumieć właśnie użytkownika , tworzyć lepszy , bardziej dostosowany do użytkownika system . Idea jest taka , żeby cały zespół jak najwięcej tej wiedzy domenowej miał , żebyśmy mieli też to zorganizowane w jaki sposób przechowujemy tę wiedzę , w jaki sposób
zdobywamy , w jaki sposób się dzielimy tą wiedzą , żeby to był po prostu proces w naszej firmie , w naszym zespole , a nie coś , co się dzieje incydentalnie . Ostatni punkt podsumowania no to pamiętajcie też , że to nie jest tak , że narzędzia są zawsze dobre . Też uważajcie na pułapki , na przykład tą nadmierną pewność siebie . Starajcie się też słuchać użytkowników , niech popadajcie w samozachwyt .
KrzysztofTak jest , i to był odcinek podcastu z cyklu dla Lidera i Manager IT o wiedzy domenowej a waszych , z cyklu dla Lidera i Manager IT o wiedzy domenowej A waszej uwadze również . polecamy pozostałe odcinki z tej serii , których już wcześniej było siedem , ale również te wcześniejsze serie , które dedykowaliśmy może bardziej technicznym tematom . Natomiast może to też być ciekawy materiał do przesłuchania , a oczywiście niezmiernie . również odsyłamy na Solid Jobs , gdzie możecie znaleźć oferty pracy , zawsze z widełkami wynagrodzeń , jak również wystawić ogłoszenie w przypadku poszukiwania menedżera bądź innego specjalisty technicznego w obszarze IT .
ŁukaszJeszcze raz zachęcam do tego , żeby odsłuchać też archiwalne odcinki , bo wydaje mi się że wybieramy takie tematy i tak staramy się tutaj je omawiać , żeby były takimi evergreenami i raczej nie traciły na aktualności . Także , jeśli nie słuchaliście takich poprzednich odcinków czy w ogóle nie słuchaliście , to zachęcam żeby odnaleźć je i odsłuchać .
KrzysztofZapraszamy serdecznie . A to był Kasz . Dzięki za dzisiejsze spotkanie .
ŁukaszDzięki , krzysztof , pewnie zobaczymy .