Dlaczego nic nie jest oczywiste: sztuka komunikacji w tworzeniu oprogramowania

Wszyscy musimy komunikować się ze sobą na co dzień. Prywatnie, w szkole, w pracy. Wszędzie i przez cały czas. Niektórzy mają lepsze umiejętności komunikacyjne niż inni, ale pod koniec dnia wszyscy popełniamy błędy od czasu do czasu.

Podczas gdy niektóre nieporozumienia mają niewielki wpływ na nasze życie (to nie koniec świata, jeśli zamówisz piwo bezalkoholowe ;)) niektóre mogą mieć większe konsekwencje (wskazanie niewłaściwego zęba do usunięcia). Nieporozumienia w komunikacji w tworzeniu oprogramowania to raczej te drugie i mogą mieć konsekwencje finansowe.

Jednym z najczęstszych problemów, z którymi wszyscy mamy do czynienia, jest założenie, że inna osoba może czytać w naszych myślach. Wszyscy czasami jesteśmy tego winni. Czy słyszałeś kiedyś takie zdanie: „To było oczywiste!”? Założę się, że masz.

Nie wierzę w obiektywną oczywistość. Uważamy, że niektóre rzeczy są oczywiste dla każdego, ale to, co jest jasne dla jednej osoby, może nie być tak oczywiste dla innych. Aby osiągnąć efektywną komunikację w tworzeniu oprogramowania przestańmy wierzyć w czytanie w myślach i po prostu powiedz, co mamy na myśli.

Dlaczego łatwiej to powiedzieć niż zrobić? Przeanalizujmy najpierw proces komunikacji.

Elementy komunikacji

Ponad 50 lat temu Roman Jakobson zaprezentował model komunikacji, który może być bardzo przydatny do analizy problemów ze zrozumieniem się nawzajem. Spójrz na diagram:

Oczywiste jest, że komunikacja to coś więcej niż tylko wiadomość między nadawcą a odbiorcą. Kontekst, kanał i kod wpływają na przekaz i mogą zmienić odbiór słów. Nawet jeśli dwa czynniki są na miejscu, a jednego brakuje, wystąpią problemy.

Ponieważ mówimy konkretnie o komunikacji w tworzeniu oprogramowania, powinniśmy przeanalizować, co by się stało podczas sesji dopracowywania projektu, gdybyśmy pominęli którykolwiek z wymienionych czynników. Innymi słowy, przyjrzyjmy się bliżej znaczeniu komunikacji w zarządzaniu projektami.

Zawsze podawaj kontekst

Kontekst zapewnia wyjaśnienie szerszego obrazu wokół każdego problemu. Można nie widzieć sensu mówienia backend developerowi o grupie docelowej produktu. Może się wydawać, że zespół programistów musi tylko wiedzieć, co jest wymagane po jego stronie, a nie powody biznesowe, które za tym stoją. Nic nie może być dalej od prawdy.

Komunikacja w tworzeniu oprogramowania to nie tylko wymagania funkcjonalne. Im więcej kontekstu możesz przekazać zespołowi, tym lepiej. Właściwe wprowadzenie do koncepcji produktu może być czasochłonne i może wyglądać jak strata czasu i pieniędzy, ale na dłuższą metę pomaga uniknąć słabej implementacji technicznej.

Jeśli zespół wie, jakie są długoterminowe plany dotyczące produktu, może dostarczyć bardziej odpowiednie rozwiązania techniczne. Nawet jeśli nie chcesz wdrażać kodów promocyjnych w pierwszej wersji swojej aplikacji mobilnej z dostawą jedzenia, dobrze jest poinformować programistów, że pojawi się w kolejnej wersji.

Aby mieć pewność, że podałeś pełny kontekst, zadaj sobie pytanie, czy udostępniłeś wszystkie posiadane informacje. Jeśli złapiesz się na myśleniu „to nie jest ważne dla programistów, nie muszą o tym wiedzieć, przynajmniej zapytaj zespół, czy ta informacja może im pomóc. Możesz być zaskoczony, jakie czynniki inni mogą uznać za kluczowe.

Korzystaj z kanału mądrze

Kanał jest powszechnie zapomnianym czynnikiem komunikacji w zarządzaniu projektami. W dzisiejszych czasach, gdy zespoły developerskie bardzo często pracują z różnych krajów, gdy backend znajduje się w Indiach (obecnie aż 85% firm amerykańskich zleca większość swojej działalności do Indii), frontend development w Polsce, a Product Owner jest w USA , wszyscy używamy wielu różnych narzędzi do komunikacji.

Wybór odpowiedniego kanału i efektywne korzystanie z niego może mieć wpływ. Połączenia konferencyjne, e-maile i czaty są świetne i pozwalają nam być w stałym kontakcie. Ale tworzą też nowe sposoby na niezrozumienie przekazu.

Nie możemy udawać, że czatowanie online to to samo, co prowadzenie rozmów w tym samym pokoju z zespołem. To, co możemy zrobić, to pamiętać o ograniczeniach komunikacji na odległość i spróbować je przezwyciężyć.

Wskazówki dotyczące skutecznej komunikacji zdalnej

1. Włącz kamerę podczas rozmowy przez połączenia konferencyjne. W zależności od sytuacji komunikacja niewerbalna może stanowić ponad 50% przekazu. O wiele łatwiej jest złapać, jeśli jesteś sarkastyczny, gdy na przykład inni cię widzą. Możesz także zobaczyć reakcje swoich rozmówców w czasie rzeczywistym. Jesteś w stanie zauważyć, czy inni mylą się z twoimi słowami, czy nie.
   
2. Używaj oddzielnych pokoi na czacie, aby kategoryzować rozmowy. Gdy projekt jest złożony, komunikacja w tworzeniu oprogramowania również staje się złożona i stale pojawiają się nowe tematy do dyskusji. Oddzielne pokoje pozwalają na uporządkowanie wiadomości i dotarcie do odpowiednich odbiorców bez wysiłku.
   
3. Oznacz odbiorców wiadomości podczas pisania na czacie. Nie jest łatwo śledzić każdą rozmowę. W Twoim najlepszym interesie jest upewnienie się, że osoba, do której piszesz, została powiadomiona.
   
4. W rozmowie pisemnej używaj emotikonów, jeśli to możliwe. Nie używaj zbyt wielu, ale poinformuj publiczność, że żartujesz z piątkowego popołudnia

Przegląd kodu komunikacji

Na samym początku pracy musisz ustalić wspólny kod, aby w ten sam sposób rozumieć główne terminy. Nawet te „oczywiste”. Na przykład mamy wymóg: „Jako użytkownik mogę złożyć zamówienie tylko rano, aby wybrany produkt mógł zostać wysłany jeszcze tego samego dnia”. Wygląda jasno, prawda?

Cóż… Więc co dokładnie oznacza poranek w tej funkcji? Kiedy zaczyna się poranek? O wschodzie słońca czy o dokładnej godzinie np. 7.00? Jeśli o 7.00 rano, jaką strefę czasową masz na myśli?

Komunikacja w zarządzaniu projektami, zwłaszcza w IT, musi być przejrzysta. Nie ma miejsca na zgadywanie. W naszym przypadku może to spowodować sytuację, w której produktów nie będzie można zamówić przed godziną 10.00 (kiedy główny programista wstaje, więc to dla niego oznacza poranek), a właściciel aplikacji traci pieniądze z powodu braku zamówień od rannych ptaszków.

Najlepsze praktyki wspólnego kodu komunikacyjnego

1. Utwórz słowniczek z powszechnie używanymi terminami. Pomaga to na początku projektu i jest niezwykle przydatne dla nowych dołączających, aby zrozumieć język, którym posługuje się zespół programistów.
   
2. Dobrze jest również zapytać odbiorcę, jak rozumie wymaganie lub frazę. I nie mówię o bezużytecznym: „Czy wszystko jasne?”. Być specyficznym. Zapytaj o szczegóły. Upewnij się, że jesteś zrozumiany. Przeprowadź przegląd kodu komunikacji.
   
   Przyjrzyjmy się jeszcze raz naszemu przykładowi: aby dojść do wspólnego rozumienia terminu „ranek”, poproś osobę, która go użyła, o przeformułowanie go.
   
3. Ogólna zasada jest taka , że ​​lepiej powtarzać komunikację w tworzeniu oprogramowania, niż zostawiać miejsce na zgadywanie gier.

Kwestia ekspertyzy

Oprócz wszystkich wymienionych powyżej metod komunikacji w zarządzaniu projektami, jest jeszcze jedna ważna rzecz, o której warto pamiętać przy omawianiu wymagań oprogramowania. Bez względu na to, czy jest to startup, czy produkt korporacyjny, w większości przypadków, zanim klient trafi do software house'u, spędza sporo czasu na myśleniu o swoim produkcie. Im więcej czasu na to spędzają, tym bardziej stają się doświadczeni w tym temacie.

Kiedy jesteś ekspertem, łatwo zapomnieć, że nie wszyscy wokół Ciebie mają taką samą wiedzę domenową jak Ty. Oznacza to, że kwestie, które są dla Ciebie oczywiste, nie są tak jasne dla zespołu programistów, z którym rozmawiasz.

Jak uniknąć problemu z ekspertyzą

1. Cofnij się o krok do początku swojej podróży z produktem i wyjaśnij zespołowi programistycznemu wszystkie podjęte decyzje. Kiedy zrozumieją, jak to wszystko się zaczęło, znajdą lepsze rozwiązania techniczne, a nawet wypełnią luki w Twoim sposobie myślenia.
   
2. Pozwól zespołowi zadać tyle pytań, ile potrzebuje. Nie ma przesady w przysłowiu, że nie ma głupich pytań.

Jak skutecznie komunikować się w zespole inżynierów oprogramowania

Tak wyraźnie, jak to możliwe! Nie ma miejsca na nieporozumienia, ponieważ konsekwencje mogą być bolesne. Pamiętaj, że nie ma obiektywnej oczywistości i lepiej powtórzyć się kilka razy, niż przeoczyć ważną informację.

Zmień swój pomysł w wyjątkowy produkt cyfrowy

Popracujmy razem

Pamiętaj o wszystkich trzech czynnikach komunikacji i sprawdź, czy Twoja wiadomość została zrozumiana zgodnie z Twoimi zamierzeniami. Z czasem komunikacja w tworzeniu oprogramowania będzie dla Ciebie łatwiejsza, a właściwe wyjaśnienie wymagań nie będzie już problemem.

Jeśli szukasz software house’u, który jest ekspertem zarówno w tworzeniu aplikacji, jak i komunikacji – nie szukaj dalej!

Po prostu porozmawiaj z naszymi specjalistami Miquido i wciel swoje pomysły w życie!