-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathKomunikacja-i-jezyk-w-zespole.html
1 lines (1 loc) · 11.2 KB
/
Komunikacja-i-jezyk-w-zespole.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>Komunikacja i język w zespole · Rafal Makara</title> <meta property="og:title" content=" Komunikacja i język w zespole "> <meta property="twitter:title" content=" Komunikacja i język w zespole "> <meta property="og:description" content=" Hi! I am Rafal and I am a generalist. I was an software engineer, project manager, product owner, scrum master, chief digital officer. I know about people, collaboration, project management, software development and business operations. "> <meta name="twitter:card" content="summary" /> <meta name="twitter:site" content="@rafalmakara" /> <meta property="og:image" content="https://rmakara.github.io/assets/20171012_header.jpg" /> <meta name="twitter:image" content="https://rmakara.github.io/assets/20171012_header.jpg" /> <meta name="description" content="Programowanie pracą zespołową"> <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//Komunikacja-i-jezyk-w-zespole"> <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="/Developer-vs-Project-Manager-001-Wiedza-o-projekcie">Previous article - Developer vs Project Manager 001: Wiedza o projekcie</a> </div> <div class="divider"></div> <h1 class="title">Komunikacja i język w zespole</h1> <div class="center"> <time class="code">2017-10-12</time> </div> <div class="divider"></div> <h1 id="programowanie-pracą-zespołową">Programowanie pracą zespołową</h1> <p>Pracując nad dowolnym projektem komercyjnym bardzo rzadko zdarza się pracować samodzielnie. Zazwyczaj projekty są na tyle złożone, że konieczne jest budowanie zespołów, których członkowie uzupełniają się umiejętnościami i wiedzą. W takiej rzeczywistości, poza wysokimi kompetencjami technicznymi, kluczem do sukcesu jest efektywna komunikacja zarówno z kolegami i koleżankami z zespołu, jak i klientem. Świat IT nie tworzy ograniczeń geograficznych zarówno pod względem poszukiwania klientów, ponieważ codziennością jest współpraca polskich firm programistycznych z klientami z całego świata. Podobnie podczas budowania własnych zespołów, szefowie nie wymagają od ludzi przebywania w jednym biurze. Istnieją takie firmy jak <a href="http://zapier.com">Zapier</a>, <a href="https://nozbe.com">Nozbe</a> czy <a href="https://softwaremill.com/">SoftwareMill</a>, które współpracują w pełni zdalnie i nie tworzy to żadnego problemu.</p> <p>Ze względu na takie standardy naszej branży, specjaliści zmuszeni są do poznania najważniejszego w programowaniu języka - angielskiego. W takiej sytuacji, ciekawą kwestią staje się budowanie zespołów z uwzględnieniem języków jakimi posługują się ich członkowie. W zależności od konfiguracji można zaobserwować różne zalety oraz wady.</p> <p>W trzech historiach będę się posługiwał zwrotem “język polski” w rozumieniu języka natywnego, a “język angielski” jako dowolnego języka obcego.</p> <h1 id="zespół-polskojęzyczny">Zespół polskojęzyczny</h1> <p>Wszyscy porozumiewamy się językiem natywnym, posiadamy komfort pozwalający na skupienie się głównie na rozwiązywanych problemach. Każdy członek mojego zespołu jest w stanie swobodnie posługiwać się wszelkimi oficjalnymi sentencjami, jak i mową potoczną, która jest bardzo charakterystyczna dla domeny, dla której tworzymy oprogramowanie. Przy takich możliwościach, techniczne i domenowe elementy projektu wymagające omówienia są łatwiejsze do przedstawienia. Obniżamy koszt komunikacji i zyskujemy na jej efektywności. Jesteśmy dość ujednoliceni pod względem kulturowym. Koledzy i koleżanki czują się pewnie podczas wygłaszania swoich wypowiedzi i nikt nie odczuwa strachu przed niezrozumieniem innych. Z czasem jest to element, który zaczynam uznawać się za oczywisty i przez brak kontaktu z ludźmi z innych kultur zaczyna wydawać się nudny i niezaspokajający ciekawości, oraz potrzeb napotykania wyzwań.</p> <h1 id="zespół-anglojęzyczny">Zespół anglojęzyczny</h1> <p>Jako jedyna osoba mówiąca w języku polskim trafiam do zespołu anglojęzycznego. Zyskuję poczucie pojawiającego się przede mną wyzwania i pracy na skalę globalną. Nie miałem wcześniejszego doświadczenia w komunikacji, więc w takich warunkach moja pewność siebie odrobinę spada. Czuję się osamotniony przez brak możliwości porozmawiania z kimś w zespole w języku polskim. Podczas rozmów pojawia się slang, idiomy, skróty myślowe oraz precyzyjne nazwy domenowe, których nie rozumiem. Tworzy to dodatkowy strach, ponieważ moim jedynym problemem nie jest jedynie omówienie architektury systemu, a dodatkowo - muszę omówić ją w języku angielskim. Z czasem jednak dostrzegam otwartość współpracujących ze mną ludzi i zaczyna mi się podobać, ponieważ moje umiejętności językowe błyskawicznie szybko progresują. Dostrzegam, że dzięki możliwości pracy w takim środowisku zdobywam umiejętności, które przydadzą mi się w codziennym życiu.</p> <h1 id="zespół-mieszany">Zespół mieszany</h1> <p>Nie znam charakterystycznych cech dla narodowościowych osób z którymi pracuje, przez co czasami narażam sie na gafę. Tworzą się grupki, które nie mówią, ani po polsku, ani po angielsku, a używają swojego natywnego języka, którego nikt poza nimi nie rozumie. Wzrastają koszty komunikacji i prowadzenia spotkań w języku angielskim. Na Slacku, Szwedzi rozmawiają po szwedzku, Francuzi po francusku, ja Polak … nie piszę. Najgorzej… Podczas zespołowej retrospekcji omawiamy zainstniały problem i decydujemy się na komunikację jedynie w języku angielskim ze względu na współną decyzję o chęci okazania szacunku każdemu z członków. Wszyscy na to przystają i w końcu zaczynamy działać jak zespół.</p> <p>Dochodzi do mnie, że w takich sytuacjach bardzo ważną rolę odgrywają proporcje - ile osób posługuje się którym językiem. Należy pamiętać, aby nikt nie pozostał sam. Trzeba zachować uprzejmość, a także okazać otwartość i ciekawość w komunikacji z każdym członków zespołu. Nie wytykać błędów. Razem się do siebie dostosować i zacząć zmierzać w tym samym kierunku po którego obraniu przyjemność ze współpracy jest niesamowicie wysoka.</p> <h1 id="its-fun-isnt-it">It’s’ fun! Isn’t it?!</h1> <p>W branży wytwarzania oprogramowania mamy to szczęście, że często jest ono naszą pasją. Poza samym zarabianiem na życie możemy sobie pozwolić na odnajdowanie szczęścia w tym co robimy.</p> <blockquote> <p>Some 80% of your life is spent working. You want to have fun at home; why shouldn’t you have fun at work?</p> <p>– Sir Richard Branson</p> </blockquote> <p>Poznawanie innych ludzi daje nam możliwość podnoszenia własnych kwalifikacji, umiejętności oraz wiedzy. Poczucie braku granic dzięki współpracy za pośrednictwem internetu daje nam nieznane dotąd możliwości uczenia się oraz zaspokajania własnej ciekawości. Być może podczas rozważań o kolejnych krokach kariery zawodowej warto rozważyć rzucenie się na głęboką wodę i potraktowanie naszej pracy jako możliwość poznawania świata?</p> <blockquote> <p>Life is a helluva lot more fun if you say yes rather than no.</p> <p>– Sir Richard Branson</p> </blockquote> <h1 id="próba-sensownego-podsumowania">Próba sensownego podsumowania</h1> <p>Musimy pamiętać, że komuniakcja stanowi jeden z większych kosztów w każdym projekcie informatycznym. Nie tylko dotyczy to języka jakim się posługujemy w kontekście “polskiego”, “angielskiego”, “francuskiego”, a także słownictwa jakie wykorzystujemy. Częstym problemem okazuje się dialog programistów z klientem, gdzie to klient jest zmuszany do używania terminów technicznych, podczas gdy to my jako osoby mające za zadanie pomóc naszemu klientowi powinniśmy się dostosować i używać bardziej rozumianych przez biznes określeń. Niby każdy mówi w tym samym języku, ale nikt się nie rozumie.</p> <p>To stanowi jednak bardzo szeroki problem, który omówię w przyszłości. Jako przedsmak, warto zapoznać się z pojęciem <a href="https://martinfowler.com/bliki/UbiquitousLanguage.html">UbiquitousLanguage</a>, który został zaproponowany w książce Domain Driven Design, Tackling Complexity in the Heart of Software autorstwa Erica Evansa. Książka, którą jest napisana w niezbyt przyjazny sposób i naprawdę trzeba chcieć ją przeczytać… ale warto, koniecznie w języku angielskim.</p> <p>Warto również pamiętać, że jedna osoba nie posługująca się naszym językiem natywnym - tworzy z nas zespół wielojęzyczny.</p> <hr /> <h4 id="źródła-i-pojęcia">Źródła i pojęcia</h4> <ul> <li>[1] <a href="https://martinfowler.com/bliki/UbiquitousLanguage.html">UbiquitousLanguage</a></li> <li>[2] <a href="https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215">Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans</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="/Developer-vs-Project-Manager-002-Zarobki">Next article: Developer vs Project Manager 002: Zarobki</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>