Porozmawiajmy o IT
Porozmawiajmy o IT
Wiedza domenowa i zarządzanie produktem. Gość: Łukasz Drynkowski - POIT 292
Witam w dwieście dziewięćdziesiątym drugim odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy w serii podcastów dla lidera i menedżera IT jest wiedza domenowa i zarządzanie produktem.
Dziś moim gościem jest Łukasz Drynkowski, z którym mam przyjemność współtworzyć portal z ofertami pracy dla branży IT o nazwie SOLID.Jobs.
Główne myśli o wiedzy domenowej w IT z tego odcinka to:
- jaka jest różnica między wiedzą techniczną, domenową i produktową
- jak wiedza domenowa menedżera wpływa na jakość produktu i zespół
- czy posiadanie wiedzy domenowej jest niezbędne
- czy menedżer musi być ekspertem domenowym
- jak zarządzać wiedzą domenową w zespole
- jak zdobywać wiedzę domenową
- kiedy wiedza domenowa może przeszkadzać w pracy menedżera IT
Subskrypcja podcastu:
- zasubskrybuj w Apple Podcasts, Google Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
- poproszę Cię też o polubienie fanpage na Facebooku
Linki:
- Profil SOLID.Jobs na LinkedIn – https://www.linkedin.com/showcase/solid.jobs/
- SOLID.Jobs – https://solid.jobs/
Wsparcie:
- Wesprzyj podcast na platformie Patronite - https://patronite.pl/porozmawiajmyoit/
Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl
https://porozmawiajmyoit.pl/292
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.
Łukasz: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. 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.
Łukasz: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. 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?
Krzysztof: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ń 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?
Łukasz: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: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ą, 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?
Łukasz: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, 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.
Krzysztof: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. 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.
Krzysztof: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 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.
Łukasz:Tak. 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.
Krzysztof: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: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:Tak 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.
Krzysztof: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, 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.
Łukasz:Chciał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ą.
Łukasz:Na 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ć.
Łukasz:I 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ć.
Krzysztof:Jasne.
Łukasz:Ponieważ 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.
Krzysztof:Tak, 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.
Krzysztof: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ą 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:Nic, tylko się zgodzić.
Krzysztof: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:Ja 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ć.
Łukasz: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ą 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.
Łukasz:I 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.
Krzysztof: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ż tutaj tak obrócł w piórka, że wydaje mu się, że tym ekspertem domenowym jest może kwestionować.
Łukasz:Tak, i to może powodować to, że nie słuchamy wtedy naszych użytkowników.
Krzysztof:Właśnie, właśnie.
Łukasz:To może być źle.
Krzysztof: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, 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?
Łukasz: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?
Krzysztof: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:Natomiast 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.
Krzysztof:Takż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.
Łukasz:Co 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.
Krzysztof:Tak 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.
Łukasz:Jeszcze 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ć.
Krzysztof:Zapraszamy serdecznie. A to był Kasz. Dzięki za dzisiejsze spotkanie.
Łukasz:Dzięki, krzysztof, pewnie zobaczymy.
