Jeżeli ktoś chce się angażować, wystarczy nie przeszkadzać. Tak powstają zgrane zespoły

Co odpowiada za sukces oprogramowania? Zgrany zespół, z którym można przysłowiowo „konie kraść”. Sam proces tworzenia i rozwoju takiego zespołu to już nie taka prosta sprawa, o czym opowiedzieli nam: Patryk Grabowski, Senior Android Developer oraz Sobiesław Gabara, iOS Tech Lead w itCraft.

Zaangażowanie, szeroka wiedza i cierpliwość. Wymieniliście, że te trzy elementy składają się na najlepsze oprogramowanie. Czym dla Was jest zaangażowanie?

Patryk Grabowski:

Bez wątpienia, trzy wymienione elementy: zaangażowanie, szeroka wiedza i cierpliwość są czynnikami, które mają duży wpływ na powodzenie projektu. Zaangażowanie, według mnie, ma tutaj największe znaczenie. Pytasz czym ono jest dla mnie – zaangażowanie według mnie to zestawienie kilku cech osobowości członka zespołu, których mieszanka ma pozytywny wpływa na rozwój projektu i jest paliwem dla pracy innych członków zespołu.

Cechy, które mam na myśli tutaj np.: dociekliwość, pracowitość, sumienność, odpowiedzialność, perfekcjonizm, ale też zdolność do wyjścia poza swoją strefę komfortu, umiarkowany nonkonformizm, czy nawet lekka butność. Każda z tych cech w czasie projektu może przyczynić się do rozpoczęcia dyskusji, której efektem może być zmiana podejścia np. próby zmiany nieintuicyjnej dla użytkownika funkcjonalności na taką, która będzie bardziej oczywista – nawet jak specyfikacja nie zakłada takiego scenariusza.

Sama chęć podjęcia tej dyskusji, próby zmiany czegoś, walka o swoje pomysły – wprost sugeruje, że zaangażowaliśmy się w projekt i chcemy, aby to, co tworzymy było wspomnianym ”najlepszym oprogramowaniem”. Taką atmosferę pracy mamy u nas – w itCraft. Mamy przestrzeń do zgłaszania pomysłów, to podejście, dzięki któremu możemy pozwolić sobie na wyjście poza schematy. I – co najważniejsze – są tu ludzie, którzy dbają o te czynniki, które napędzają rozwój – pracowników i firmy.

Sobiesław Gabara:

Zaangażowanie to dla mnie po prostu chęć robienia czegoś. Jeżeli interesuje nas temat, nad którym pracujemy, to chcemy go zgłębiać – i ta chęć sama w sobie pcha nas ku rozwiązaniu. Ta chęć nie ma stałej wartości, więc trudno też jest zdefiniować samemu sobie poziom własnego zaangażowania. Prosto zarówno nie docenić, jak i przecenić swoje zaangażowanie.

Zaangażowanie z zewnątrz zazwyczaj manifestuje się dobrą znajomością tematu, bo obcując z daną dziedziną i będąc zaangażowanym niejako siłą rzeczy zaczynamy funkcjonować w obrębie „bańki informacyjnej” zagadnienia. Zaangażowanie to też umiejętność niepoddawania się, gdy przyjdą trudności – a zazwyczaj przychodzą. Wiedza i chęci towarzyszące zaangażowaniu pozwalają na zaciśnięcie zębów i znalezienie rozwiązania.

Jak sprawić, że zespół poczuje, że ich pomysł/głos ma znaczenia?

Patryk:

Aby zespół poczuł, że ich zaangażowanie ma sens, trzeba pozwolić mu działać, być otwartym na propozycje, nie tworzyć szklanych sufitów. Każdy chce czuć się potrzebny, wysłuchany, każdy chce czuć sprawczość swoich działań – szczególnie jeśli mówimy o kimś zaangażowanym. Tak właśnie podchodzimy do tworzenia aplikacji, nasi programiści nie są tylko zasobem, każdy z nas ma głos i swój udział w powstawaniu oprogramowania. A postawa zamknięta, trzymanie się sztywnych reguł, blokowanie innowacyjności, czy ”dyktatura” w zespole na pewno nie będzie miało pozytywnego wpływu na zaangażowanie członków zespołu. W itCraft zespół współpracuje i jest zaangażowany na wielu płaszczyznach, a nie tylko dostarcza prace przed deadline’ami.

Sobiesław:

Jeżeli ktoś chce się angażować, wystarczy nie przeszkadzać. Moim zdaniem najważniejszym zadaniem w zespole jest umożliwianie płynnej komunikacji, rozumiane jako pilnowanie, aby każdy miał prawo głosu i żeby każda myśl znalazła swój koniec w postaci przemyślenia/dyskusji itp. Prawie każdy członek zespołu ma przemyślenia, którymi chciałby albo powinien się podzielić. Drobne elementy, które składane w całość stopniowo decydują o skuteczności zespołu – gdy wiemy, że nasze pomysły brane są pod uwagę to chcemy się nimi dzielić. Gdy wiemy, że pomysł nietrafiony nie zostanie nazwany głupim i pogardliwie podeptany, tylko rozważony merytorycznie i merytorycznie odrzucony bez żadnych osobistych przytyków – nie boimy się mówić o najdziwniejszych spostrzeżeniach, nie boimy się nie mieć racji.

Co rozumiecie przez pojęcie “szerokiej wiedzy”?

Patryk:

Dla mnie mieszanka wiedzy teoretycznej z bogatym doświadczeniem praktycznym. Tak jak wiedza teoretyczna jest dość oczywista, tak pragnąłbym opisać, co mam na myśli używając określenia ”doświadczenie praktyczne”. Doświadczenie praktyczne dla mnie to w dużej mierze, czas, w którym wykorzystujemy swoją wiedzę teoretyczną, ale też wszystkie triki, skróty, udogodnienia, z których nauczyliśmy się korzystać w celu polepszenia swojego warsztatu, czy rozwiązaniu specyficznych problemów, na które jeszcze nie ma konwencjonalnego rozwiązania. Zestawienie doświadczenia z wiedzą teoretyczną wymnożone przez czas pozyskania ich obu, uznać można za wskaźnik szerokiej wiedzy.

Zobacz też

Wywiady Zorganizuj jedno źródło wiedzy o pracy zespołu. Ułatwi to estymację stanu realizacji projektu

Sobiesław:

Szeroki temat. Szeroka wiedza to rozbudowana baza wiedzy o różnych aspektach danej dziedziny. Bazę tą tworzymy z czasem, jako jej fundament mając swoje doświadczenia oraz wiedzę teoretyczną. Stykając się z różnymi fragmentami układanki w zakresie jakiejś dyscypliny po jakimś czasie znamy ją na tyle dobrze, że nasza wiedza może być uznana za szeroką.

Wiedzę bardzo łatwo poszerzyć. Wystarczy działać zespołowo – ja wiem to, Ty wiesz tamto i nagle okazuje się, że szerokość wiedzy wzrasta i to znacznie, w niektórych aspektach pokrywając się z różnych źródeł, a w innych poszerzając całościową wiedzę. Taki trochę paradoks z wiedzą, która, nawet gdy jest szeroka, to głębia i szczegółowość każdego zagadnienia sprawiają, że nawet kilka osób posiadających szeroką wiedzę z danej dyscypliny znakomicie uzupełnia się właśnie w szczegółach. Doceniam fakt, że w itCraft poszerzanie wiedzy właśnie w taki sposób jest codziennością. Wysoka jakość pracy jest tu normą.

Na końcu tej krótkiej listy jest cierpliwość. Jak rozwiązać problem czasu, czyli czegoś, co trudno rozciągnąć? Każdy projekt powinniśmy dostarczyć możliwie najszybciej?

Patryk:

Nie, na pewno żadnego projektu nie powinniśmy dostarczać jak najszybciej, bo taki projekt najczęściej jest wtedy słabej jakości, a praca przy nim jest stresująca – co może mieć bezpośredni wpływ na naszą motywację i zaangażowanie. Faktem jest, że problem czasu jest najczęstszą bolączką wielu projektów. Co możemy z tym zrobić? Wszystko zależy od metodologii, w jakiej pracujemy i jakie mamy możliwości wpływania na zakres projektu. Nie ma co ukrywać, że najlepszym rozwiązaniem, przy okrojonym czasie jest usuwanie z zakresu, wszystkich zadań o najmniejszym priorytecie a największej czasochłonności, które nie mają drastycznego wpływu na funkcjonalność produktu, który ma być wynikiem projektu. W itCraft wiemy, że to czas jest najcenniejszą walutą – dlatego zużywamy go mądrze, wszyscy.

Sobiesław:

Brak czasu potrafi być bolączką. We właściwie przeanalizowanym projekcie ilość czasu powinna być wystarczająca do realizacji każdego z zadań. Niestety z powodu różnych czynników zazwyczaj na przestrzeni pracy z projektem jesteśmy zmuszeni do mniejszych lub większych korekt planów czasowych. Nie ma chyba jednej skutecznej recepty na problemy z czasem – ilość czynników, które mogą je wywołać jest naprawdę spora, warto po prostu zachować czujność, aby nie popełniać drobnych błędów, które w późniejszych etapach mogą urosnąć do kosztownych pomył (jak zapewne powinna zwać się wielka pomyłka). Nie warto się też stresować opóźnieniami. W sumie łatwo to powiedzieć trudniej zrobić, ale bardzo często a wręcz zawsze martwienie się nie przynosi niczego dobrego – jeżeli projekt „nie idzie” bo ciągle coś przeszkadza to taki jego chwilowy urok, trzeba przeczekać i robić swoje.

Oferty pracy z

Co stoi za sukcesem danego projektu? Ile procent dalibyście technologii, ile procent zespołowości a ile jeszcze innej, dowolnej składowej?

Patryk:

Wszystko zależy od tego, co rozumiemy poprzez ”sukces projektu”. Może to być sukces rynkowy albo sam fakt ukończenia projektu wraz z realizacją wszystkich założeń w terminie. W obu przypadkach sukces projektu, w mniejszym stopniu wynika z użytej technologii – ta może mieć wpływ na termin oddania projektu. Większą zasługę przypisałbym tutaj zespołowi, gdyż to jego zgranie, zaangażowanie i zapał do osiągnięcia celu kształtuje końcowy efekt, a więc projekt. Od zespołu zależy na ile zaimplementowane funkcje będą spójne od strony logiki biznesowej, na ile kod jest wolny od błędów, albo na ile wizualna część projektu będzie dopracowana i interaktywna, a tym samym, lepiej odebrana przez użytkownika. Tak więc – sukces projektu, myślę, że w 80% przepisałbym zespołowi, a resztę technologii.

Sobiesław:

Zakładam, że pod pojęciem sukces projektu rozumiemy udane uruchomienie aplikacji? Bo wypuszczenie aplikacji to jedno, ale to czy aplikacja zdobędzie uznanie użytkowników, czy w ogóle zdobędzie użytkowników – to już w dużej mierze zależy od innych czynników.

Z mojej perspektywy jednym z najważniejszych czynników wpływających na sukces projektu jest stałość celu. „Chodzenie po wodzie i tworzenie oprogramowania wg specyfikacji są łatwe, o ile woda i specyfikacja są zamrożone” [Edward V. Berard] – jeżeli w trakcie realizacji projektu nie borykamy się z silnie „pływającą” koncepcją realizacji – szansa na sukces rośnie dramatycznie.

Celu nie da się osiągnąć bez zespołu, więc czynnik ludzki odgrywa chyba nawet ważniejszą rolę. Istnienie w zespole synergii w działaniu zawsze podnosi szanse sukcesu, bo taki zespół jest w stanie wszystko zrobić wydajniej i szybciej. Jeżeli realizacja projektu sprawia przyjemność – na pewno się uda! Otwarta komunikacja wśród wszystkich członków zespołu to kluczowy aspekt. Na końcu zaś technologia – z jednej strony chciałoby się powiedzieć, że rzecz nieco drugorzędna, niemniej równie kluczowa , jak pozostałe elementy, bowiem decydując się na jakąś technologię wybieramy również sposób obsługi długu technologicznego, który niczym inflacja nieustannie narasta.

Jaka jest procentowa ważność tych trzech czynników? Chyba coś koło 20-50-30. Czynnik ludzki jest bardzo ważny, właściwie chyba najważniejszy.

Co wpływa na zespołowość, na to, że jako grupa ludzi zawsze dążymy do wspólnego celu?

Patryk:

Jakby spojrzeć na definicję zespołowości, to śmiało można przyznać, że praca zespołowa zawsze ma wspólny cel. Co ma wpływ na to, że mamy wspólny cel? Żartobliwie można powiedzieć, że przełożony, który przydzielił nas do projektu…

Człowiek jest istotą stadną, ale każdy ma samoświadomość, własne cele, podyktowane sytuacją, w jakiej się znajduje obecnie. Gdy owa sytuacja, jest formą problemu do rozwiązania, która przerasta możliwości jednostki, a problem ten, w tym samym czasie dotyka większą ilość członków ”stada”, to wspomniani członkowie potrafią skrzyknąć się, określić wspólny cel – rozwiązanie problemu, podzielić się zadaniami i wspólnie rozpocząć prace nad rozwiązaniem.

Sobiesław:

To chyba tkwi głęboko w nas, że działając jako zespół czujemy swego rodzaju przyjemność, z jednej strony dostajemy od zespołu klocki potrzebne do wykonania naszej pracy, a z drugiej – sami dostarczamy takie klocki komuś innemu w zespole, co w końcu przynosi rezultat w postaci skomplikowanego bytu cyfrowego, jakim jest aplikacja.

Zakładam, że nie jestem odosobniony w tym, co czuję, gdy działanie kończy się sukcesem – tę wewnętrzną euforię, świadomość, że długookresowe działania przyniosły skutek, że to po prostu działa, a obok siebie ma się grupę ludzi, którzy dokonali tego razem z Tobą. Świadomość wspólnego skutecznego działania – to dla mnie esencja zespołowości.

Patryk Grabowski. Senior Android Developer w itCraft. Swoją przygodę z programowaniem na urządzenia mobilne rozpocząłem jedenaście lat temu, z czego aż dziewięć poświęciłem w pełni Androidowi. Przez te wszystkie lata i wszystkie szczeble kariery zawodowej, nauczyłem się nie tylko jak wykorzystywać w pełni Javę, czy Kotlina, napisać nietuzinkowy widok, czy wzorowo ostylować aplikację. Nauczyłem się, że nie ma rzeczy niemożliwych — każdy problem programistyczny da się rozwiązać, a to co najważniejsze w projekcie — to zgrany i w pełni zaangażowany zespół, który nie myśli szablonowo, bo przy takim zespole, mimo tylu lat doświadczenia, nadal mogę się rozwijać.

Sobiesław Gabara. iOS Tech Lead w itCraft. Przedtem przez kilkanaście lat programista w wielu językach i na wielu platformach. Gorący orędownik dobrego klimatu w pracy jako głównego warunku powodzenia projektów. Swoją pracę traktuje jako stanowisko służebne, jest zawsze gotowy nieść pomoc potrzebującym :), czerpać wiedzę i się nią dzielić, podważać niepodważalne i przedyskutowywać nienaruszalne. Czerpie przyjemność z samorozwoju i obserwacji rozwoju innych. Prywatnie pasjonat sportów ekstremalnych i rodziny.