Osoby techniczne bardzo często mają naturalną, potrzebę dzielenia się wiedzą, nowinkami i ciekawostkami technicznymi. Są różne sposoby, żeby to realizować. Bazując na własnym doświadczeniu, chciałbym przedstawić kilka sposobów, które u mnie się sprawdziły. W tym artykule będę pisał o alternatywnych metodach na dzielenie się wiedzą.
W tym artykule prezentuję raczej mniej znane oraz mniej popularne sposoby. O tych najczęściej wykorzystywanych przeze mnie dowiecie się tutaj:
Zapraszam na wpis o Dzieleniu się wiedzą techniczną w pracy
Tech talks
Na pewno jest to bardzo cenna forma dzielenia się wiedzą, zarówno dla uczestników jak i dla prowadzącego. Jeśli chcemy przygotować dobry tech talk to zazwyczaj musimy mocno wejść w dany temat i w ten sposób sami się uczymy.
Niestety z drugiej strony prezentacje wymagają dość dużego nakładu czasowego. Trzeba dobrze przygotować temat, najlepiej jak jest prezentacja multimedialna i przykład w formie live coding.
Ciężko jest trafić z treścią do całego zespołu, ponieważ najczęściej współpracujemy z osobami o różnym stopniu wiedzy i doświadczenia. Może się okazać, że dla kogoś nie będzie nic odkrywczego, a dla innych poziom będzie zbyt wysoki.
Z mojego doświadczenia wynika, że tech talki można przygotowywać raz na jakiś czas jeśli ktoś rzeczywiście ma jakiś ciekawy temat albo interesujące wnioski do zaprezentowania.
Podsyłanie linków - artykuły, newsy
Bardzo popularny sposób dzielenia się wiedzą w czasach kiedy pracowałem w swojej pierwszej firmie IT. Niestety z moich obserwacji wynika, że bardzo ciężko o dobre artykuły obecnie. Dużo tematów jest już wyczerpanych, a technologia nie rozwija się aż tak szybko, żeby wypełnić tematy na artykuły na wszystkich istniejących blogach.
Niemniej warto dzielić się ciekawymi linkami z zespołem. Nie wszyscy obserwują te same kanały informacji i może się zdarzyć, że ktoś przeoczy np. release nowej wersji biblioteki, którą używacie.
Traktuję ten sposób bardziej jako raczej spontaniczny dodatek niż coś regularnego.
Szkolenia
Mam tutaj na myśli szkolenia wewnętrzne prowadzone przez członków zespołu dla innych członków albo innych zespołów.
Czasami zdarza się, że jest zespołowa potrzeba na pogłębienie wiedzy w bardziej rozległym temacie, a jedna/dwie osoby mają taką wiedzę.
Taka sytuacja może się zdarzyć jeśli np. wprowadzamy w firmie nowy framework, albo decydujemy się na nową technologię, albo stwierdzamy, że od teraz kodzimy w czymś na czym jednak nie tak dobrze się znamy.
Przykład z jednej z moich poprzednich prac. Tech leader od frontendu rozmawiał z devami o potrzebach i ich brakach w umiejętnościach. Okazało się, że dużo osób wymienia TypeScript, a ja akurat czułem się w tym temacie dość dobrze (tak mi się przynajmniej wydawało 🙂 ) Po rozmowach z leaderem podjęliśmy decyzję, że przygotujemy szkolenie.
Niestety taka forma jest bardzo droga i rozwleka się w czasie. Minęło parę miesięcy zanim udało nam się przygotować materiały na ośmiogodzinne szkolenie. Trzeba było pogodzić, to z bieżącymi obowiązkami.
Plusem na pewno jest to, że sami bardzo dużo się nauczyliśmy i szkolenie było idealnie skrojone na potrzeby zespołu. Jednak z perspektywy czasu stwierdzam, że prawdopodobnie lepiej byłoby zatrudnić firmę zewnętrzną z dedykowanym szkoleniem.
Group programming
Wydaje mi się że to jest dość mało popularna aktywność w firmach IT. Polega na tym, żeby wziąć kawałek funkcjonalności i zaprogramować go razem z zespołem. Kluczowe jest tutaj, żeby wcześniej przygotować fragment kodu do zaimplementowania i dokładnie przedstawić go innym, żeby każdy był w tym samym kontekście.
Ważne jest, żeby programiści w zespole byli dosyć aktywni podczas takich spotkań, bo wtedy wymiana wiedzy jest intensywna i każdy może czegoś się nauczyć. Jeśli tylko jedna lub dwie osoby będą pisać albo mówić to niestety mniej programistów skorzysta.
Warto zaznaczyć, że nie jest to tyle dzielenie się wiedzą co pokazywanie swoich umiejętności i toku swojego rozumowania podczas kodzenia. Z jednej strony mniej doświadczeni mogą przekonać się jak myślą Ci z większym doświadczeniem, a z drugiej możemy wystawiać swój sposób myślenia na krytykę innych.
Można tutaj skorzystać z tych samych narzędzi co w przypadku pair programmingu, aczkolwiek wymaga to większej dyscypliny zespołu, żeby nie doprowadzić do bałaganu i zamieszania podczas spotkania
Podsumowanie
Jak widać sposobów na dzielenie się wiedzą jest mnóstwo. Ja w moich artykułach naliczyłem aż 7, a na pewno jest ich jeszcze więcej. Czego więc jeszcze potrzeba? Chęci 🙂
Musimy zdać sobie sprawę z tego, że dzieląc się wiedzą każdy zyskuje. Ja jeśli dziele się wiedzą, to utrwalam ją, albo pogłębiam, a inni w oczywisty sposób zyskują nową wiedzę.