4 niezawodne metody, żeby utrudnić sobie pracę w zespole

W większości przypadków nie jesteśmy samotnymi wyspami na oceanie i projekty, nad którymi pracujemy, wymagają pracy zespołowej. Dobra komunikacja (a także ta zła) z innymi ludźmi ma ogromny wpływ zarówno na finalną postać projektu, jak też na atmosferę panującą w zespole.

Poznajcie 4 proste sposoby na to, aby praca w zespole stała się… trudniejsza.

1. Dokładne omówienie założeń projektu? Po co to komu...

Lepiej od razu zacznij kodzić! Przecież wielogodzinne dyskusje i niekończące się planowanie to strata czasu. Cennego czasu. Czasu, który lepiej poświęcić na “naklepanie” kilkuset linii kodu i szybkie stworzenie prototypu aplikacji 💪.

Czy takie podejście aby na pewno jest dobre? Nawet jeśli uda Ci się szybko napisać coś działającego, w 95% przypadków usłyszysz od klienta: “Przecież nie o to mi chodziło.” i zostaniesz zmuszony do poprawiania swojego genialnego kodu 😐

Najważniejsza na początku pracy nad nowym projektem jest… rozmowa. I to niejedna. Rozmawiaj, dyskutuj i pytaj. Z klientem oraz innymi członkami zespołu. A jednocześnie spisuj dokumentację. Opisz w niej szczegółowe wymagania klienta i zaproponowane rozwiązania. No i oczywiście udostępnij ją klientowi (jeśli nie w całości, to przynajmniej w istotnej, z jego punktu widzenia, części). Dzięki temu upewnisz się, że zarówno on, jak i Twój zespół rozumie potrzeby drugiej strony i zgadza się na zaproponowane warunki.

W ten sposób unikniesz wielu konfliktów i nieporozumień, a nanoszenie przyszłych poprawek (gwarantuję Ci, że się pojawią 😝) okaże się zdecydowanie łatwiejsze.

2. Nie słuchaj innych

Twoje pomysły zawsze są najlepsze 😎! W końcu nikt nie rozumie Cię tak jak Ty sam, a najlepiej czyta Ci się własny kod. Po co więc go zmieniać?

Właśnie po to, żeby zrozumieli go też inni! Ile razy zdarzyło Ci się wpatrywać w cudzy kod, mając wrażenie, że ktoś napisał go w nieznanym języku? A przecież to ten sam projekt, w którym jeszcze wczoraj zachwycałeś się pięknem Pythona, Javy czy [tu wstaw ulubioną technologię].

Co się stało? 🧐

Tak jak osobowość wyróżnia Cię spośród innych członków zespołu, tak samo niepowtarzalny jest Twój styl programowania. Podczas gdy Ciebie fascynuje najnowsze Porsche, Twoja dziewczyna woli legendarną Corvettę z lat 60? A może na odwrót? 🤭 Tak czy siak, jadąc na wspólną wycieczkę nie wsiądziecie do dwóch aut. Zdecydujecie się na jedną opcję.

Grupowa praca nad projektem to właśnie taka wspólna wycieczka. Każdy z członków zespołu ma różne przyzwyczajenia. Ustalcie więc wstępne założenia i schematy w ramach danego projektu

Zacznijcie od rzeczy podstawowych, takich jak nazewnictwo zmiennych (camelCase vs snake_case) czy struktura katalogów, a stopniowo dojdziecie do elementów bardziej skomplikowanych, takich jak logika kodu. Im spójniejsza dziś, tym stabilniejszy projekt w przyszłości. A wspólna podróż zdecydowanie przyjemniejsza. 🤩

 

Ale pójdźmy jeszcze krok dalej. 

Czy Twoje rozwiązanie danego problemu zawsze jest najlepsze? Raczej nie. I uwaga! Pomysł bardziej doświadczonego kolegi też nie musi taki być. 

No więc jak znaleźć to optymalne wyjście ? Przecież oboje chcecie stworzyć coś perfekcyjnego. Takie jabłuszko na Waszym programistycznym torcie, którego nie powstydziłby się sam Steve Jobs. Ale jak je odpowiednio ugryźć? 

Odpowiedź jest bardzo prosta: rozmawiajcie. Tak, powtarzam się, ale rozmowa to klucz do sukcesu. Dobra rozmowa oczywiście. Dyskutujcie i wymieniajcie się propozycjami i pomysłami. Zróbcie burzę mózgów. Nie odrzucajcie niczego, co przyjdzie Wam do głowy, wręcz przeciwnie –  zapisujcie każdą myśl. Potem złapcie świeży oddech i dopiero wtedy zastanówcie się nad wszystkimi opcjami i wybierzcie tę najlepszą. 


Jasne, że nie zawsze okaże się ona najlepszą na świecie, ale na pewno będzie dużo lepsza od kilku innych, na które wpadliście w pierwszej chwili.

3. Nie aktualizuj repozytorium

– “Kiedy ostatnio podegrałaś swoje zmiany?”
– “No tak jakoś z tydzień temu.”
😱.

Zdarzyła Ci się kiedyś podobna rozmowa? Bo mi niestety tak! I to nieraz. Szczególnie na początku przygody z programowaniem. I oczywiścia byłam tą złą (jeśli nie wierzycie, zapytajcie Julitę 😅).

No dobra, przejdźmy do meritum. Projekt projektowi nierówny i częstotliwość podgrywania zmian może być naprawdę różna, ale jedno jest pewne. Im częściej podgrywamy swoje zmiany, tym mniejszy problem sprawiamy pozostałym członkom zespołu. I odwrotnie – im częściej ściągamy najnowsze zmiany do swojego lokalnego repozytorium, tym mniejsze problemy sprawiamy sami sobie. Co mam na myśli? Nic innego, jak konflikty w kodzie, które pojawiają się prawie non stop, jeśli kilka osób modyfikuje te same pliki.

Mało kto lubi je rozwiązywać, jednak nie mamy innego wyboru. Taki już urok tej pracy. Ale skoro już musimy się mierzyć z smokiem, niech chociaż nie zionie ogniem 🔥!  Czemu nie ułatwić sobie zadania i upraszczać potencjalne konflikty? Wystarczy jak najczęściej aktulizować repozytorium i eliminować sytuacje, kiedy w kolejce do “naprawy” ustawi się kilkadziesiąt plików…

4. Zostań Smerfem Marudą

Nie pasują Ci narzędzia, których używa Twój zespół? Nie odpowiada Ci przyjęta metodyka pracy? Koledzy z zespołu rzucają żarcikami, których nie rozumiesz? A klient znowu żąda zmiany koloru tych głupich przycisków?

Pewnie, możesz zostać małym niebieskiem stworkiem i mruczeć pod nosem, przeklinając cały świat. Droga wolna! 🤞

Ale proponuję Ci inne podejście. Zastanów się, na co nie masz wpływu. Pogody nie zmienisz, klienta tak łatwo też nie (no chyba, że cierpisz na nadmiar gotówki 😂), więc nie trać nerwów na rzeczy, które są od Ciebie niezależne. 

A potem przejdź do pozostałych. I zamiast narzekać na innych, spójrz najpierw na siebie. Co nie podoba Ci się w tych narzędziach? Są za mało intuicyjne? Brakuje w nich jakichś funkcjonalności? Spisz listę wad, uruchom przeglądarkę i … poszukaj lepszych! A potem zaproponuj alternatywy swojemu zespołowi. Przedstaw swój punkt widzenia, pokaż inne dostępne opcje i rozpocznij dyskusję. Tak samo zrób z “niewłaściwą” metodyką pracy i wszystkimi innymi rzeczami, które Ci nie pasują i które jesteś w stanie zmienić. 

Efekty naprawdę Cię zadziwią. Gwarantuję.

Podsumowanie

Wszystkie te sytuacje znam z własnego doświadczenia. Na początku przygody z programowaniem zwykle zaczynałam pracę nad projektem od postawienia repo i tworzenia pierwszych modeli. Nieraz myślałam też, że moje rozwiązanie jest tak genialne jak odkrycie Ameryki. Zapominałam tylko, że moim celem była jedynie podróż do Indii 😟

Niestety człowiek uczy się na błędach. I to głównie na swoich. A nawet wtedy popełnia je po raz kolejny i kolejny.

Nie zmienia to jednak faktu, że czasem warto spojrzeć na potknięcia innych i wyciągnąć wnioski zawczasu. Mam nadzieję, że skorzystacie z moich doświadczeń i zbudujecie na nich coś dobrego.

Pamiętajcie. Dobra komunikacja w zespole to klucz do sukcesu!

A na koniec mały tematyczny suchar. Dlaczego Szewczyk Dratewka nadaje się na programistę? Bo umie rozwiązywać konflikty 😂.

P.S. Podzielcie się w komentarzach własnymi doświadczeniami pracy w zespole. Zarówno tymi złymi, jak i dobrymi 😀.

4.7 3 votes
Article Rating
guest
4 komentarzy
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Joanna
Joanna
8 miesięcy temu

Super artykuł! Również uważam, że komunikacja w zespole jest bardzo ważna. Nieraz na swojej drodze spotkałam programistów, którzy najchętniej zamknęliby się w piwnicy i kodzili bez kontaktu ze światem, a rozmowa to dla nich strata czasu 🙄

Natalia
Natalia
8 miesięcy temu

Ten tekst jest świetny. Śmiechłam przy tym sucharze. Dobra robota!