Komunikacja w pracy zespołowej jest kluczem do osiągania lepszych rezultatów. O ile się nie robi prywatnego projektu, to najczęściej programuje się w ramach zespołu. Mniejszego lub większego ale jest to zespół. Bez dobrej komunikacji pojawiają się problemy.

 

Abstrahując już od narastającej frustracji, niskiego morale czy braku pracy zespołowej, które to mogą pojawić się niezależnie od wykonywanego zajęcia, w przypadku programistów inne mogą być konsekwencje niewłaściwej komunikacji.

 

Obserwując ludzi przez kilka lat swojej pracy z zespołami zauważyłem, że wcale to nie te najczęściej wymieniane skutki braku komunikacji były widoczne. Wielu programistów to introwertycy i nie mają potrzeby się uzewnętrzniać. Dostają zadania i je realizują w swoim tempie. Nie zwracając w tym czasie na innych.

 

Poniżej 3 typowe problemy jakie wielokrotnie obserwowałem.

 

Przeciągające się zadania

Przez kilka lat pracowałem w środowisku gdzie utrzymanie istniejącego systemu zajmowało dużą ilość czasu pracy. Poprzez utrzymanie systemu mam na myśli naprawianie błędów zgłaszanych przez klientów. Nie jest to wymarzona praca większości programistów, w związku z czym obserwowałem dużą rotację w zespołach. Duża rotacja to wiele osób do podpatrzenia. Praca na dużym, skomplikowanym systemie wymaga dobrej komunikacji. Zawsze jest ktoś, kto ma większą wiedzę i jest w stanie coś podpowiedzieć, Nakierować na źródło problemu. Wielokrotnie widziałem jak programiści nie chcieli lub też obawiali się spytać o pomoc. Starali się rozwiązać problem samodzielnie. Różnie się to kończyło. Czasami problem rozwiązali dobrze z czasami nie. Minęło kilka dni a oni dalej się męczyli przechodząc przez kolejne moduły systemu. Wszystko trwało dłużej niż powinno w związku z czym nie było czasu na strategiczne zmiany. Po prostu inni czekali w kolejce aby ich problemy rozwiązać. A problem był łatwy do rozwiązania gdyby tej komunikacji pomiędzy poszczególnymi członkami zespołu było więcej.

 

Nieoczekiwane zachowanie aplikacji

Jak się nie wie co się robi, Prowadzi archeologię w kodzie programu to łatwo o wprowadzenie zmiany albo nie tam gdzie ona ma być wprowadzona lub też popsucie systemu w celu doraźnego rozwiązania problemu. Zakomentowanie kodu, tylko dlatego, że pojawił się błąd NullReferenceException nie należy do rzadkości. W końcu jak się zakomentuje miejsce gdzie występuje błąd to aplikacja nie będzie denerwowała już użytkowników komunikatami o błędach. Na początku swojej kariery w programowaniu byłem świadkiem jak osoba za takie podejście musiała odejść z pracy. Postępowanie takie jest związane z tym, że nie ma się odpowiedniej wiedzy na temat systemu. Rozwiązać to można na dwa sposoby. Albo analizować dalej kod albo spytać się kogoś kto wie jak to powinno działać o pomoc.

 

Duplikacja rozwiązań tego samego problemu

W przypadku większych systemów, nad którymi pracuje wielu programistów, do rzadkości nie należy implementacja podobnych rozwiązań w wielu miejscach. Np. może być to pakowanie i rozpakowanie plików zip. Dając ten sam problem do rozwiązania 10 programistom, każdy to zrobi w inny sposób. Każdy to zrobi po swojemu. Wymyśli koło na nowo. Nie ma ku temu jednakże potrzeby. Jedno rozwiązania może zadowolić wiele osób. Tylko ku temu potrzebna jest komunikacja. Po pierwsze zakomunikowanie innym, że się rozwiązało taki problem a po drugie zapytanie innych czy przypadkiem nie rozwiązali już takiego problemu. Programistom łatwiej przychodzi zadanie pytania na StackOverflow niż zapytanie osoby z innego zespołu pracującego nad tym samym projektem. Nie wykluczone, że ten pierwszy programista, który miał taki problem do rozwiązania też zadał pytanie na StackOverflow. Wtedy dochodzimy do sytuacji o której pisałem tutaj.

 

A ty z jakimi problemami się spotkałem, które wynikały z braku komunikacji?