„Developer jest od kodu, nie od rozmów z klientami” – czyli o szkodliwym micie słów kilka

W branży IT często można spotkać się z przekonaniem, że praca programisty to zajęcie, które wymaga głównie wiedzy technicznej i minimalnej interakcji z ludźmi. Wizja developera pracującego w samotności, zanurzonego w linijkach kodu może wynikać z przestarzałego wyobrażenia o pracy w IT. 

Dziś software developerzy rzadko pracują w pełnej izolacji. Tworzenie oprogramowania to skomplikowany proces, który wymaga efektywnej komunikacji. Samo napisanie kodu to tylko część pracy. 

Od początku istnienia Pragmatic Coders, wielokrotnie zdarzało się nam, że nie byliśmy w stanie zatrudnić developera mimo jego świetnego warsztatu technicznego. Przyczyną było niedopasowanie kulturowe do organizacji, a mówiąc prościej:  brak otwartości i predyspozycji do działania w sposób zgodny z naszymi wartościami firmowymi.

Dlaczego współpraca i komunikacja w pracy software developera jest kluczowa?

W wielu firmach funkcjonuje model pracy, w którym informacje są przekazywane przez jednego menedżera (np. Project Managera), który pełni rolę pośrednika między zespołem projektowym, a klientem. To PM zbiera wymagania, rozmawia o priorytetach, i jest głównym źródłem informacji dla zespołu programistycznego. 

Na pierwszy rzut oka może się wydawać, że taki sposób komunikacji jest efektywny, ponieważ odciąża programistów od konieczności bezpośredniego kontaktu z klientami i uczestniczenia w kolejnych spotkaniach (bo przecież w tym czasie można byłoby się zająć kodem! :)). 

W rzeczywistości jednak, taki sposób pracy najczęściej prowadzi do wielu patologii, które bezpośrednio mogą zaważyć na sukcesie projektu. I niestety – kiedy już się wydarzą, lawinowo prowadzą do kolejnych problemów. 

Utrata kontekstu

Kiedy PM jest jedynym pośrednikiem między klientem a zespołem, istnieje wysokie ryzyko zniekształcenia informacji. Każda komunikacja przechodzi przez filtr osobistych interpretacji i priorytetów PM-a, co może prowadzić do niepełnego lub błędnego przekazania istotnych informacji. Zespół programistyczny, pracując na niekompletnych danych, może rozwijać funkcjonalności, które nie spełniają rzeczywistych potrzeb klienta, co prowadzi do frustracji po obu stronach. Nie dotyczy to jedynie klienta, ale też użytkownika końcowego.

Wszak brak zrozumienia rzeczywistego kontekstu użytkowania produktu ogranicza zdolność do tworzenia rozwiązań, które są intuicyjne i użyteczne. Skoro zespół unika komunikacji bezpośredniej, może on nie być świadomy codziennych wyzwań, z jakimi mierzą się użytkownicy, co prowadzi do tworzenia funkcji, które mogą być technicznie poprawne, ale nieadekwatne do potrzeb końcowych użytkowników.

Spadek motywacji i zaangażowania

Ograniczona komunikacja negatywnie wpływa na morale zespołu. Programiści, odcięci od bezpośredniego dialogu z klientem, tracą poczucie wpływu na rozwój produktu.  Brak poczucia odpowiedzialności za projekt prowadzi do spadku motywacji, co z kolei może skutkować niższą jakością dostarczanego rozwiązania. Zamiast aktywnie poszukiwać najlepszych rozwiązań zespół skupia się na „odfajkowywaniu” zadań z backlogu. 

Brak zaufania

Kiedy komunikacja z klientem jest zmonopolizowana przez PM-a, w dłuższej perspektywie może pojawić się problem z zaufaniem. Stawki pracy developerów są wysokie, a dzienny koszt utrzymania całego zespołu to znaczna inwestycja. Jeśli klient nie zna zespołu, nie wie, kto za co jest konkretnie odpowiedzialny, a do tego wszystkiego, zaczynają pojawiać się jakieś błędy i opóźnienia w projekcie  – może zacząć wątpić, czy usługa jest warta swojej ceny.

A to tylko niektóre problemy, które mogą być następstwem braku dobrej i transparentnej komunikacji z klientem.

Co z tym zrobić?

Nie ma innej rady niż to, by zachęcać zespoły do aktywnego kontaktu z klientem i budowania relacji. Pokazujmy pracownikom korzyści płynącę z takiego modelu pracy i eliminujmy wszelkie przeszkody, które mogą się w nim pojawić (np. ograniczmy zbędne spotkania i zostawmy te, które przynoszą największą wartość dla projektu, nauczmy zespoły komunikacji z klientem i je w tym wspierajmy).

Jak robimy to w Pragmatic Coders?

Wytwarzanie oprogramowania to dla nas więcej niż kodowanie.  Nasze zespoły ściśle współpracują z klientami i ich biznesem, stosując ustrukturyzowaną komunikację, wspieraną przez metodyki takie jak Scrum. Nasi developerzy mają dużą swobodę w zakresie wyboru technologii, współtworzenia funkcjonalności produktu i proponowania rozwiązań. Taki model pracy zwiększa zaangażowanie zespołów i ich poczucie odpowiedzialności (ownership).

Ponadto, regularne przeglądy postępów i otwarta wymiana informacji pomagają w budowaniu zaufania i efektywnej współpracy.

Pracownicy są zachęcani do głębokiego zrozumienia rzeczywistych problemów klientów, co stanowi fundament ich pracy. Koncentrujemy się na dostarczaniu rzeczywistej wartości, opierając się na bieżącej informacji zwrotnej i elastyczności w reagowaniu na zmiany, aby minimalizować ryzyko niepowodzenia.

Czy zawsze nam się to udaje i nie mamy po drodze żadnych potknięć? Oczywiście, że nie.

Natomiast, w Pragmatic Coders nie ukrywamy błędów ani porażek – traktujemy je jako cenne źródło nauki. Każdy zespół w naszej firmie ma możliwość dzielenia się doświadczeniami, zarówno sukcesami, jak i niepowodzeniami. Gdy popełniamy błąd lub podejmujemy niewłaściwą decyzję, staramy się dogłębnie przeanalizować sytuację, aby zrozumieć, co poszło nie tak i jakie nauki możemy wyciągnąć z danej sytuacji. Wspólne dzielenie się doświadczeniami pozwala nam unikać powielania tych samych błędów oraz wzmacnia naszą kulturę transparentności i odpowiedzialności.

Każdy błąd jest krokiem w kierunku lepszego zrozumienia naszych metod i praktyk, co w efekcie prowadzi do osiągania coraz lepszych rezultatów.