-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathJournaling-narzedzie-rozwoju-i-budowania-zaufania.html
1 lines (1 loc) · 19.3 KB
/
Journaling-narzedzie-rozwoju-i-budowania-zaufania.html
1
<!DOCTYPE html> <html lang="pl"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1" /> <title>Journaling, narzędzie rozwoju i budowania zaufania · Rafal Makara</title> <meta property="og:title" content=" Journaling, narzędzie rozwoju i budowania zaufania "> <meta property="twitter:title" content=" Journaling, narzędzie rozwoju i budowania zaufania "> <meta property="og:description" content=" Czego możemy nauczyć się od firm pracujących w pełni zdalnie? Komunikacji i jej transporentności, a także metod wspólnego uczenia się. Przyjrzyjmy się technice nazywanej journalingiem. "> <meta name="twitter:card" content="summary" /> <meta name="twitter:site" content="@rafalmakara" /> <meta property="og:image" content="https://rmakara.github.io/assets/20180512_header.jpg" /> <meta name="twitter:image" content="https://rmakara.github.io/assets/20180512_header.jpg" /> <meta name="description" content="Powtarzalne problemy"> <link rel="icon" href="https://rmakara.github.io//assets/favicon.ico"> <link rel="apple-touch-icon" href="https://rmakara.github.io//assets/apple-touch-icon.png"> <link rel="stylesheet" href="https://rmakara.github.io//assets/core.css"> <link rel="canonical" href="https://rmakara.github.io//Journaling-narzedzie-rozwoju-i-budowania-zaufania"> <link rel="alternate" type="application/atom+xml" title="Rafal Makara" href="https://rmakara.github.io/feed.xml" /> </head> <body> <aside class="logo"> <a href="https://rmakara.github.io//"> <img src="https://avatars0.githubusercontent.com/u/1880231?v=4" class="logo-avatar"> </a> <span class="logo-prompt code">Back to Home</span> </aside> <aside> <p class="goodbye"> This blog is no longer maintained <br/><br/> Subscribe to new articles at <a href="https://www.sorryengineering.com/">https://www.sorryengineering.com/</a> </p> </aside> <p class="menu"> <br /><br /> <a href="/">EN Articles</a> | <a href="/pl">PL Articles</a> <br /> <a href="/about">About me</a> | <a href="/help">How can I help?</a> | <a href="https://www.linkedin.com/in/rafalmakara/">My LinkedIn Profile</a> </p> <div id="content"> <article> <div class="divider"></div> <div class="center"> <a class="prev" href="/Event-Storming-Warsztaty-Agile-Wroclaw">Previous article - Event Storming: Warsztaty Agile Wrocław</a> </div> <div class="divider"></div> <h1 class="title">Journaling, narzędzie rozwoju i budowania zaufania</h1> <div class="center"> <time class="code">2018-05-12</time> </div> <div class="divider"></div> <h1 id="powtarzalne-problemy">Powtarzalne problemy</h1> <p>Każda z firm, które spotykałem na ścieżce mojej kariery nauczyła mnie niesamowicie dużo. Z drugiej jednak strony, mierzyły się one z różnymi problemami. Jedne z nich były unikatowe, a drugie powtarzalne i występujące w każdej z nich. Należącymi do tej drugiej grupy były między innymi dzielenie się wiedzą oraz budowanie zaufania w stosunku do pracy zdalnej.</p> <p>Moja perspektywa odnosi się do organizacji, które pracują w większości w biurze, ale dopuszczają pracę osób w pełni zdalnych.</p> <h1 id="dzielenie-się-wiedzą">Dzielenie się wiedzą</h1> <p>Gdy pracowałem jak programista zawsze współpracowałem z innymi programistami. Dawało mi to możliwość otrzymywania natychmiastowego feedbacku odnośnie jakości mojej pracy przez rozmowy z kolegami i koleżankami o tej samej specjalizacji. Narzędzia takie jak code review, continious integration pozwalały uczyć się każdego dnia. Współna edukacja najczęściej zamykała się jednak wewnątrz zespołu, a wymiana wiedzy w skali firmy była zdecydowanie mniej efektywna. Z przekonaniem jestem w stanie stwierdzić, że osoby siedzące po dwóch stronach tego samego budynku, często odkrywały koło na nowo.</p> <p>Gdy zacząłem pracować jako project manager sytuacja się odmieniła. Dlaczego? Zazwyczaj w projekcie jest tylko jeden project manager, który współpracuje ze specjalistami, ale nie z drugim managerem wewnątrz tego samego projektu (opisuję tu sytuację PM + Specjaliści, a nie (PM +) PO + SM + Specjaliści). Tworzy to sytuację w której jako managerowie jesteśmy w stanie się uczyć od specjalistów. Czy jednak czegoś tutaj nie brakuje? Skoro programiści tworzący jeden projekt są w stanie popełniać te same błędy i implementować te same rozwiązania to z kim powinien dzielić swoją wiedzę manager? Konieczne są techniki pozwalające na wymianę wiedzy z managerami prowadzącymi inne projekty. Niestety, bardzo często takich technik brakuje i managerowie nie mają codziennej okazji do uczenia się od innych osób wykonujących te same obowiązki, przez co ich krzywa uczenia jest wolniejsza, niż mogłaby być.</p> <h1 id="zaufanie-do-pracowników-zdalnych">Zaufanie do pracowników zdalnych</h1> <p>W firmach, które nie pracują w modelu #NoOffice, a skupiają się głównie na pracy z jednego budynku, umożliwiając dodatkowo pracę zdalną dla osób spoza biura - czasami tworzy się podział na “normalnych” i “zdalnych”. Jest to jeden z antywzorców, który nie jest najprostszy do wyeliminowania, ale konieczny do przemyślenia, ponieważ zarówno pracownicy lokalni, jak i zdalni są bardzo wartościowi.</p> <p>Osobę pracującą w biurze ocenia się po wspólnych rozmowach, aktywności na spotkaniach, podnoszeniu ręki, gadaniu o niczym przy kawie. Taka osoba jest zauważalna. Specjalista, który nie pracuje z biura w przypadku niewytworzonej kultury organizacyjnej w której “zdalnych, nie nazywa się zdalnymi” w większości przypadków oceniany jest jedynie po efektach swojej pracy. Co robi osoba, której nie widać?</p> <h1 id="remote-team-guide">Remote Team Guide</h1> <p>Dwa miesiące temu wyjechałem do rodzinnego Olsztyna, aby przez tydzień pracować zdalnie. Przeczytałem poradnik współpracy zdalnej stworzony przez firmę pracującą w modelu #NoOffice, czyli <a href="https://x-team.com">X-Team</a> - <a href="https://x-team.com/remote-team-guide/">The Definitive Guide To Remote Teams</a>. Genialny zbiór wiedzy mówiący o tym dlaczego warto włączać kamerkę podczas telekonferencji oraz dlaczego czasami warto spotkać się na żywo. W pełni polecam.</p> <p>W powyższym poradniku znalazła się jedna technika, która podczas obecności w Olsztynie wzbudziła moje zainteresowanie i dzień później postanowiłem spróbować, ponieważ była możliwa do natychmiastowego wdrożenia. Był to journaling (kronikowanie).</p> <h1 id="journaling">Journaling</h1> <p>W przypadku firmy X-Team została przytoczona forma journalingu polegająca na stworzeniu własnego kanału na Slacku (np. <em>rmakara-journal</em>) i otwartemu komunikowaniu samemu sobie oraz wszystkim osobom chętnym to przeczytać: co się zrobiło dziś, co planuje się zrobić jutro, czego się dzisiaj nauczyło. Taka struktura może przypominać najbardziej oklepaną formę znaną z daily, ale w praktyce okazała się czymś innym, co omówię w kolejnych paragrafach.</p> <p>Swoją próbę zrealizowałem na firmowym Confluence. Stworzyłem blog na którym umieszczałem każdego dnia post składający się z:</p> <ul> <li>Nagłówka.</li> <li>Obrazka.</li> <li>Bloku <em>Today</em>.</li> <li>Bloku <em>Tomorrow</em>.</li> <li>Bloku <em>Today I learnt</em>.</li> <li>Bloku <em>Summary</em>.</li> </ul> <h1 id="nagłówek">Nagłówek</h1> <p>Zdecydowałem się na wykorzystanie 3 danych. Daty pokazującej ciągłość wpisów, imienia i nazwiska. Dane osobowe zostały dodane na wypadek, gdyby komuś idea się spodobała i chciałby zacząć pisać swój dziennik w obrębie tej samej przestrzeni Confluence. To się nie zdarzyło, ale środowisko jest pod to przygotowane. :)</p> <h1 id="obrazek">Obrazek</h1> <p>W ramach budowania kultury tak jak zostało to opisane w poradniku X-Team - obrazki, emotikony i nieformalne rzeczy mają olbrzymie znaczenia dla budowania kultury firmy. W każdym poście pojawił się obrazek nawiązujący do tematyki danego dnia. Wybranie go zajmowało mi około 15 sekund. Szukałem na Googlach pierwszego skojarzenia, które pojawiło mi się w związku z danym dniem. Czasami były to zdjęcia z najlepszego miasta na świecie (Olsztyna), a czasami człowiek robiący inhalację pod ręcznikiem. Głównym zadaniem tego było zachęcenie ludzi, rozbawienie, wprowadzenie mniej formalnej atmosfery.</p> <h1 id="today">Today</h1> <p>Często efekty pracy managera są trudne do zmierzenia. W zakres obowiązków wchodzi tzw. prowadzenie projektów, wspieranie klienta i zespołu we wzajemnej komunikacji, przeprowadzanie rozmów feedbackowych ze specjalistami i wspieranie ich rozwoju, komunikacja wewnątrzfirmowa, planowanie przydziałów specjalistów do projektów, konsultacje z prawnikami w zakresie przygotowywania umów czy windykacji, i wiele innych rzeczy. Takich aktywności często nie można dotknąć lub przytulić. O ile programista po zakończonym dniu pracy jest w stanie pokazać klocek, który danego dnia stworzył to managerowie od czasu do czasu wychodzą z pustymi rękami. Taki brak fizycznego obiektu, który można zobaczyć jest demotywujący dla nas samych. Zdarza się zakończyć dzień z poczuciem braku świadomości, że zrobiło się cokolwiek, ponieważ większością aktywności było - rozmawianie. Nie oznacza to jednak, że praca managerów nie jest wartościowa czy efektywna. Wręcz przeciwnie!</p> <p>Podsumowanie minionego dnia i spisanie wykonanych rzeczy buduje motywację i pokazuje, że przeprowadzone działania, mimo braku pozostawienia fizycznego śladu wniosły dużą wartość do pracy firmy, ludzi, naszej, zespołu. Dla mnie miało to bardzo pozytywny wpływ, ponieważ nie miałem więcej dni po zakończeniu których wychodziłem ze swiadomością <em>“nic dzisiaj nie zrobiłem”</em>.</p> <p>Z punktu widzenia kolegów i koleżanek czytających wpisy journalingowe blok ten pozwala na dostrzeżenie czym się zajmowałem, co czasami generuje pytania <em>“Jak to zrobiłeś? Pokażesz mi?”</em>. Osiągamy dzięki temu wymianę wiedzy o niewielkim zasięgu, ale motywujemy siebie i innych przez możliwość wspólnego edukowania się.</p> <h1 id="tomorrow">Tomorrow</h1> <p>Wydaje mi się, że to najmniej istotny blok z całej struktury kronikowania. Wymusza jednak konieczność przemyślenia dnia kolejnego oraz wstępnego jego zaplanowania, a to zgodnie z wszechobecną wiedzą o planowaniu i produktywności wpływa pozytywnie na wydajność naszej pracy. Rozpoczynając następny dzień, mamy wstępny plan na to czym chcemy się zająć.</p> <p>Jeżeli ktoś czyta nasze wpisy na bieżąco to na podstawie tego jest w stanie zagadać <em>“Hej, widziałem że będziesz pracować nad rzeczą X, czy mogę dołączyć i zobaczyć jak to robisz?”</em> lub <em>“Robiłem X już kilka razy, mogę Ci w tym pomóc!”</em>. Jest to kolejny element, który wspiera dzielenie się wiedzą, wspólny rozwój oraz prowadzi do lepszych rezultatów naszych działań, które następie dostarczamy klientom.</p> <h1 id="today-i-learnt">Today I learnt</h1> <p>Jest to część, która wpływa zarówno na naszą własną motywację, a także na motywację innych. Często w pracy popadamy w pułapkę krytycznego myślenia o miejscu w którym pracujemy i wmawiamy sobie, że nie umożliwia nam ono rozwijania się. To jednak bardzo rzadko jest prawdą, ponieważ w prawie każdej sytuacji jesteśmy w stanie sami stworzyć środowisko w którym możemy się uczyć. Dotyczy to szczególnie branży IT, gdy struktura organizacyjna zazwyczaj zmierza w kierunku turkusowych lub zielonych organizacji, które zostały opisane w książce <a href="http://www.reinventingorganizations.com/">Reinventing Organizations</a> (ciągle czekającej na przeczytanie). Również organizacje pomarańczowe przejawiają otwartość na inicjatywy bottom-up. Jeżeli wpadłeś/aś w takie błędne koło myślenia o swoim pracodawcy jako kimś kto Ciebie nie rozwija to zazwyczaj złotą radą jest - zmień siebie. Jeżeli jednak upewniłeś/aś się, że jesteś najlepszą osobą w firmie i nie masz się od kogo uczyć - zmień firmę.</p> <p>Zawarcie bloku TIL (Today I Learnt) w dzienniku pozwoliło mi na skupienie się na utrwalaniu wiedzy. Przed rozpoczęciem kronikowania stale uczyłem się nowych elementów, ale nie miałem w pełni świadomego spojrzenia na to, że one istnieją - dlatego również trochę marudziłem. Dzięki ich spisywaniu mogę utrwalać zdobywane umiejętności i wiedzę, doceniać je, i cieszyć się tym, że się rozwijam.</p> <h1 id="summary">Summary</h1> <p>Miejsce dające możliwość wylania swojej radości lub żalu. Przestrzeń, gdzie w postaci jednego zdania możemy podsumować emocje towarzyczące nam po przeżyciu danego dnia.</p> <h1 id="moje-doświadczenie">Moje doświadczenie</h1> <p>Rozpocząłem przygodę z journalingiem w marcu bieżącego roku i do dnia dzisiejszego stworzyłem 36 wpisów. Pomijając jeden z urlopów na którym chciałem się w pełni zresetować daje to blisko 100-procentowe pokrycie dni roboczych. Moje odczucia po tym czasie są zdecydowanie takie, że zamierzam kontynuować ten nawyk, ponieważ wpływa pozytywnie zarówno na mnie jak i na pojedyncze inne osoby, a wymiana wiedzy z innymi, oraz inspirowanie pojedynczych osób jest tym co sprawia mi w pracy największą satysfakcję. W obrębie journalingu możemy tworzyć dodatkowe wyzwania do których jesteśmy jeszcze bardziej motywowani dzięki złożeniu publicznej deklaracji ich wykonania. Tym sposobem w ciągu najbliższego tygodnia planuję rozpocząć tworzenie jednego odręcznego rysunku dziennie, który zastąpi obrazki pochodzące z Internetu. Jest to nie lada wyzwanie, ponieważ nie jestem mistrzem, ani w pisaniu odręcznym, ani rysowaniu. Zobaczymy jakie będą efekty. :)</p> <h1 id="co-robi-manager-co-robię-ja">Co robi manager? Co robię ja?</h1> <p>Chorobą organizacyjną na którą journaling okazał się być lekarstwem był absolutny brak wiedzy specjalistów o tym czym zajmuje się manager. Wielokrotnie od znajomych developerów pracujących w innych firmach słyszałem, że ich project manager robi absolutne nic. Taka sytuacja mnie nie dziwi, ponieważ sam mam problem ze zdobyciem wiedzy o tym co robią inni managerowanie. Nic więc dziwnego, że programiści, testerzy, analitycy, designerzy, graficy często mają takie postrzeganie swoich managerów w projektach, w których Ci nie schodzą do niskopoziomowej pracy nad projektem/produktem wspólnie z zespołem, a zajmują się organizacją niezwiązaną bezpośrednio z wytwarzaniem.</p> <p>Problem braku świadomości nie dotyczy tylko linii specjalista-manager, ale również manager-manager i specjalista-specjalista. W szczególności relacji pozaprojektowych. Journaling pozwala jawnie wylistować rzeczy, które się wykonało i przy odrobinie zaangażowania inni mogą zostać tym zaciekawieni i dopytać jak rozwiązało się problem X lub wykonało rzecz Y. Bez świadomości tego CO ktoś robi, nie można dowiedzieć się JAK, ani DLACZEGO to robi.</p> <blockquote> <p>Journaling wzbudza zaufanie, przez otwarte pokazywanie co robimy. Propaguje naszą wiedzę i doświadczenia. Motywuje nas i innych.</p> </blockquote> <h1 id="co-nas-powstrzymuje">Co nas powstrzymuje?</h1> <p>Często spotykałem się z dwoma problemami rozpoczynania tego typu inicjatyw. Pierwszym z nich była obawa przed jawnym pokazaniem swoich aktywności innym osobom - <em>“Co jeżeli ktoś powie, że nic nie robię i firma płaci mi za nic?”</em>. Zazwyczaj nie będzie to prawdą. Hejterzy pozostaną cicho, a osoby wspierające nas docenią proaktywność. Jeżeli jednak rzeczywiście nic nie robisz to journaling będzie świetnym motorem napędowym, aby to zmienić. Myslę jednak, że robisz więcej, niż Ci się wydaje. :)</p> <p><a href="https://hbr.org/2006/12/the-curse-of-knowledge">The Curse of Knowledge</a>, czyli Klątwa Wiedzy. Drugim potężnym problemem blokującym nas przed rozpoczęciem jest przekonanie mówiące o tym, że to co wiemy jest banalne. Trudno się z tym nie zgodzić. Zawsze możemy powiedzieć, że rzeczy w których jesteśmy kompetentni są (dla nas) oczywiste. Na podstawie własnych przekonań oceniamy przydatność naszej wiedzy i umiejętności w życiu innych, a zazwyczaj jesteśmy w tym zbyt krytyczni. Dziesięć lat temu trenowałem żonglerkę i teraz bez problemu mogę obudzić się o 3:00 w nocy i żonglować pięcioma piłkami, jest to dla mnie banalne. Czy jednak dla każdego? Gwarantuje, że czynności, które dla nas wydają się być najprostsze na świecie - będą bardzo wartościowe dla innych. My z kolei, opisując je lub ucząc inne osoby wzmocnimy naszą wiedzę jeszcze bardziej. Dodatkowo, zyskamy zdecydowanie więcej wartości, która wróci do nas po otwarciu się na innych.</p> <h1 id="podsumowanie">Podsumowanie</h1> <p>W ramach podsumowania planowałem umiescić jeden wpis journalingowy pokazujący jak to wygląda w praktyce. Zdecydowałem się tego nie robić, aby osoby czytające ten atykuł mogły zrobić to według własnej wizji, która z pewnością będzie dobra.</p> <p>Journaling to jedna z tych rzeczy o której można słuchać i czytać, i nic z tego nie wyciągnąć. Ze względu na bardzo niski próg wejścia zachęcam do spróbowania. Uważajcie jednak, czy nie dzielicie się zbyt poufnymi informacjami, które są zabezpieczone przez podpisane przez Was umowy.</p> <p>Za alternatywne zakończenie niech posłużą dwa cytaty odpowiadające na przedstawione problemy dzielenia się wiedzą i budowania zaufania.</p> <blockquote> <p>Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has “cursed” us. And it becomes difficult for us to share our knowledge with others, because we can’t readily re-create our listener’s state of mind.</p> <p>– Someone</p> </blockquote> <blockquote> <p>Trust is not something that’s given because you win an election; it’s something you have to earn.</p> <p>– Tom Perez</p> </blockquote> <hr /> <h4 id="źródła-i-pojęcia">Źródła i pojęcia</h4> <ul> <li>[1] <a href="https://x-team.com">X-Team</a></li> <li>[2] <a href="https://x-team.com/remote-team-guide/">The Definitive Guide To Remote Teams</a></li> <li>[3] <a href="http://www.reinventingorganizations.com/">Reinventing Organizations</a></li> <li>[4] <a href="https://hbr.org/2006/12/the-curse-of-knowledge">The Curse of Knowledge</a></li> </ul> </article> <div class="divider"></div> <div class="page-navigation code"> <a class="home" href="https://rmakara.github.io//" title="Back to Home">Back to Home</a> <br/><br/> <a class="next" href="/Project-Manager-wiec-kto-Wstep">Next article: Project Manager, więc kto? Wstęp</a> </div> </div> <br/> <aside> <p class="goodbye"> This blog is no longer maintained <br/><br/> Subscribe to new articles at <a href="https://www.sorryengineering.com/">https://www.sorryengineering.com/</a> </p> </aside> <div class="footer"> <span class="block">© 2023 Rafal Makara</span> <span class="block"><small></> Powered by <a href="https://jekyllrb.com/">Jekyll</a> and <a href="https://github.com/heiswayi/the-plain">The Plain theme</a>.</small></span> </div> </body> <script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-92815270-1', 'auto'); ga('send', 'pageview'); </script> </html>