Krzysztof:
[0:00] 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.

Łukasz:
[0:25] Cześć Krzysztof.

Krzysztof:
[0:26] 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.

Łukasz:
[1:00] Tak 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.

Łukasz:
[1:55] I tutaj posiadamy tą wiedzę produktową związaną na przykład 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. Obszarem tematycznym, czyli 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 jakaś wiedza na temat wystawiania recept albo zasad refundacji leków.

Krzysztof:
[2:31] Wł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ń 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. I 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?

Łukasz:
[3:50] Tak, 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.

Krzysztof:
[4:46] Myś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ą, to oczywiście ta jakość jego czy jej 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?

Łukasz:
[5:52] Tak 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. 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 tikecie ktoś się pomyli. 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 dochodzić do tego, o co rzeczywiście chodzi użytkownikowi.

Krzysztof:
[7:09] Tak, 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.

Krzysztof:
[7:43] 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.

Krzysztof:
[8:02] Idąc w kierunku jakichś większych organizacji, no tam 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 menedżer IT nie musi być ekspertem domenowym, ponieważ bardzo często ma osoby w swoim zespole albo w firmie, Niektó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 również szuka tego typu 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, no nie?

Łukasz:
[9:24] Tak, natomiast osobiście jakbym zatrudniał kogoś, to nie szukałbym jakby tej wiedzy u tego kogoś. To wydaje mi się, że jest coś, co powinniśmy zadbać w firmie, żeby jakby 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ć np. 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.

Krzysztof:
[10:24] Bardzo 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.

Łukasz:
[11:14] Chciał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?

Krzysztof:
[11:24] Tak, no 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, żeby 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.

Krzysztof:
[12:13] Coraz bliższy 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ć.

Krzysztof:
[12:29] 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, 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. No i klasyczne 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, żeby 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.

Krzysztof:
[13:56] 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ż tam swoją wiedzą wśród członków naszego zespołu.

Łukasz:
[14:16] Chciałbym nadmienić kilka właśnie punktów. Po pierwsze bardzo fajnie, jeśli tworzymy produkt, z którego sami możemy korzystać właśnie 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ś

Łukasz:
[14:39] Powiedzmy niedoskonałości albo jakieś rzeczy, które można by zrobić sprawniej i szybciej i udaje się wtedy na przykład wdrożyć takie poprawki. Natomiast jeszcze powiedziałeś tutaj o tych szkoleniach, to także chciałbym tutaj nadmienić, 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ą. Na przykład programista, który akurat robił coś związanego z receptami za tydzień tutaj miał, był prelegentem i innym osobom opowiadał coś O tych receptach. Ktoś, kto zajmował się jakimiś uprawnieniami pacjentów np. EW8, np. tester, który to testował, to też za tydzień miał kilka minut, żeby opowiedzieć, co tam się dowiedział, co ciekawego, 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

Łukasz:
[16:03] Najlepszą formą tego, żeby samemu się uczyć, także to i jeszcze ostatnia rzecz do twojej długiej wypowiedzi odniosę także długą wypowiedzią czyli reużywanie tej wiedzy tak jak mówiłeś, tworzenie na przykład instrukcji dla użytkowników to jakby to można gdzieś tam wpleść

Łukasz:
[16:21] W to nasze zdobywanie wiedzy, czyli nie tylko teraz my użyjemy tego wewnętrznie, żeby czegoś się dowiedzieć, ale powstanie jakiś artykuł na przykład na bloga naszego albo jakiś tutorial wewnętrzny w systemie, może jakieś po prostu instrukcje 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ć.

Krzysztof:
[17:04] Jasne.

Łukasz:
[17:06] Ponieważ powiedzieliśmy tutaj o tym, czy ja może powiedziałem, że jakby cały zespół tutaj powinien być tym ekspertem domenowym, to chciałbym rozszerzyć to. Cała firma powinna być ekspertem domenowym. Na przykład nie wyobrażam sobie, żeby tutaj 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 niść porozumienia i rozmawiamy tym samym językiem.

Krzysztof:
[18:03] Tak, to jest też myślę istotna przewaga dla firmy, która ma taką kulturę, można powiedzieć, organizacyjną, gdzie inwestuję 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, na przykład.

Krzysztof:
[18:26] Z klientami, z potencjalnymi klientami, tak zwani pre-sellsi, 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. Wię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ą że 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.

Łukasz:
[19:49] Nic, tylko się zgodzić.

Krzysztof:
[19:52] Dobrze, 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.

Łukasz:
[20:26] Ja zawsze twierdzę, że to zależy oczywiście. Każda organizacja jest inna, w każdej firmie jest inna dynamika.

Łukasz:
[20:36] Inne są możliwości tutaj, jeśli chodzi o rozmiar zespołu. Są firmy, w których 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ć. Jeszcze 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ą cztery tygodnie co najmniej odstępu. I teraz w wymaganiach pojawia się tak, że między szczepionką A a szczepionką B ma być te cztery 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ą, to jest oczywiste, że taka zależność powinna być dwustronna.

Łukasz:
[22:04] Tego typu nawet prostsze spostrzeżenia, czyli to nie musi być taka wiedza stricte, jakby gdzieś tam zdobyta, to może być taki też zdrowy rozsądek, pozwala uniknąć pewnych błędów i po prostu ktoś, kto pisał wymagania, no to by 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. No 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ż sześć w jednym i tak dalej i wtedy ten sześć w jednym w jednym kraju może być na przykład czymś innym niż w drugim. Sytuacje są różne.

Krzysztof:
[22:57] No 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ż, prawda, tutaj tak obrósł w piórka, że wydaje mi się, że tym ekspertem domenowym jest, może kwestionować.

Łukasz:
[23:16] Tak i to może powodować to, że nie słuchamy wtedy naszych użytkowników.

Krzysztof:
[23:19] Właśnie, właśnie.

Łukasz:
[23:20] To może być źle.

Krzysztof:
[23:22] Dokł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 i 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 domynowej. 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ć?

Łukasz:
[24:19] Oczywiście najcenniejszym źródłem wiedzy są nasi klienci. i 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, nie wiem, 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.

Krzysztof:
[25:10] Ja 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.

Łukasz:
[25:30] U mnie na studiach na Politechnice Poznańskiej, dodam informatyce, mieliśmy SMS finansów. I to właśnie było stricte zrobione pod to, żebyśmy byli programistami systemów związanych z tą domeną finansową, ponieważ jest to tak popularna i częsta domena, która występuje w wielu systemach. Wystawianie faktur. Kto nigdy nie wystawiał faktur? Ten masz części. To chyba nie znam takich osób. Także po prostu na studiach może być taki kierunek czy taki przedmiot.

Krzysztof:
[26:11] Tak, a jeśli nie macie czasu, żeby iść na studia podyplomowe, no to zawsze jakaś forma mikrolearningu, taka codzienna pigułka wiedzy da też 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 mocno i stabilnie stać w przypadku rozwoju kariery. Co? Może spróbujemy podsumować tradycyjnie?

Łukasz:
[27:23] 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 jakby tak, że narzędzia są zawsze dobre, też uważajcie na pułapki, na przykład tą nadmiertą pewność siebie, starajcie się też słuchać użytkowników, niech popadajcie w samozachwyt.

Krzysztof:
[28:39] Tak jest i to był odcinek podcastu z cyklu dla Lidera i Menadżera IT o wiedzy domynowej, a w 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 tematem, 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.

Łukasz:
[29:19] Jeszcze raz zachęcam do tego, żeby odsłuchać też archiwalne odcinki, bo wydaje mi się, że wybieramy takie tematy.