Praca w IT, Wywiady

Najpierw odpowiedzialność, później niezależność. O tym, jak mieć realny wpływ na decyzje

niezależność w it

– Aktywnie interesujemy się tym, z jakimi problemami boryka się sam klient, jak i użytkownicy produktu. Pozwala nam to wychodzić od konkretnego problemu i proponować odpowiednie rozwiązania – powiedział w rozmowie z nami Jakub Dobosz, Product Owner w Pragmatic Coders. Jakuba i Dominika Króliczka (Software Developera) zapytaliśmy o to, czym dla nich jest niezależność i odpowiedzialność w projekcie.

#top_oferta: Senior Ceph Engineer

25000 - 30000 pln

Aplikuj

Spis treści

Zacznijmy od definicji niezależności. Czym dla Was jest niezależność w IT?

Dominik: Oprócz oczywistych spraw typu niezależność developera jako możliwość pracy zdalnej, w elastycznych godzinach, pracy w młodym dynamicznym zespole itp, niezależność to według mnie decyzyjność i realny wpływ na produkt.

Jakub: Istotną kwestią jest swoboda proponowania rozwiązań, które mają szansę być zrealizowane. Innymi słowy – klienci, z którymi współpracujemy, traktują nas jak równorzędnych partnerów i słuchają naszych sugestii dotyczących rozwoju produktu. Dodatkowo, w pełni zostawiają nam decyzje w jaki sposób zrealizować daną funkcjonalność, ponieważ widzą, że jesteśmy ekspertami w tym, co robimy.

Jakie warunki, zasady w firmie, organizacji, sprzyjają rozwijaniu niezależności?

Jakub: Myślę, że najważniejszą rzeczą jest jedna z wartości firmy – “We Take Ownership”. Dotyczy ona zarówno kwestii firmowych, jak i sposobów współpracy z klientem. Dzięki temu jesteśmy w stanie dostosować się do drugiej organizacji i mieć na to konkretny wpływ. Co więcej, wykorzystując swoje pomysły w codziennej pracy czujemy się ich właścicielami i bierzemy za nie odpowiedzialność.

Dominik: Płaska struktura firmy na pewno pomaga. Nie mam nad sobą menadżera, który podejmuje decyzje za mnie i muszę zdobyć jego przychylność. Jeżeli zauważam jakiś problem lub mam propozycję na usprawnienie, mogę skonsultować go z każdym, włączając w to zarząd.

Jakie korzyści firmie, a jakie korzyści np. programiście przynosi niezależność, poczucie wolności w proponowaniu rozwiązań?

Dominik: Z perspektywy programisty na pewno zmniejsza ryzyko wypalenia zawodowego. Oczywiście jeżeli ktoś chce brać aktywny udział, a nie szuka ciepłej posady programisty, na której realizuje tylko powierzone zadania. Niezależność daje mi poczucie, że mam wpływ na środowisko, w którym pracuje (i nie chodzi o środowisko programistyczne).

Jakub: Jesteśmy osobami, które cały czas chcą się rozwijać. Dzięki niezależności i możliwości proponowania rozwiązań, sami decydujemy o tym, czego chcemy się uczyć. Pozwala to na utrzymanie motywacji do działania i ciągłe bycie na bieżąco. Oczywiście zdarzają się sytuacje, że dany pomysł czy ścieżka rozwoju nie jest na chwilę obecną najlepsza. Wtedy otwarcie rozmawiamy o tym, jak dalej pokierować danym tematem.

W Pragmatic Coders budujecie produkty z klientami – oni także nie mają problemu z niezależnością? Zostawiają Wam “wolną rękę”, jeśli chodzi o sposób realizacji projektu? Co, jeśli mają swoje wytyczne?

Dominik: Zdarza się że klient przychodzi z propozycją rozwiązania, wtedy zwykle (jeżeli ma ono sens) nie negujemy propozycji w imię niezależności. Dążymy jednak do tego, aby klient nam zaufał, po prostu wykonując dobrze swoją pracę w początkowych etapach.

Jakub: Już podczas pierwszych rozmów dążymy do wniesienia wartości biznesowej. Pozwala nam to od samego początku pokazywać, że dbamy o interesy naszego klienta i dzięki temu szybciej zyskujemy zaufanie.

Dominik: Zdarzają się klienci z zacięciem do mikro managementu lub z “własnym zaufanym człowiekiem”, którego ciężko przekonać, że możemy dać znacznie więcej niż kod wysokiej jakości, spełniający założenia biznesowe. W takim przypadku nieoceniona jest rola Product Ownera, który małymi krokami pokazuje klientowi zysk z pozostawienia zespołowi wolnej ręki w określonych obszarach – na przykład sposobie realizacji danej funkcjonalności.

jakub pragmatic coders

Jakub Dobosz, Product Owner w Pragmatic Coders

W jaki sposób zgłaszać swoje pomysły? Jak robić to tak, by wszyscy zrozumieli, o co mi chodzi, ale też nie pomyśleli, że stoję murem za pomysłem, że jestem otwarty na krytykę?

Jakub: Wydaje mi się to oczywiste – poprzez rozmowę. Myślę, że to kwestia zaufania i tego, że wiemy, że każde z nas dąży do stworzenia najlepszego rozwiązania. Ta kwestia dotyczy zarówno pomysłów technicznych, które omawiamy w zespole scrumowym, jak i tych biznesowych omawianych z klientem.

Dominik: Niedawno mieliśmy case, w którym zintegrowaliśmy się z zewnętrznym providerem ankiet, aby jak najszybciej wyjść na produkcję, co było celem klienta. Jak się okazało, wybrane rozwiązanie powodowało wiele problemów, wliczając w to zarządzanie ankietami, dość wysokie koszty. Oszacowaliśmy implementacje tej funkcjonalności po naszej stronie, omówiliśmy ją z klientem i wdrożyliśmy na produkcję. Z perspektywy czasu widzimy, że obie decyzje były słuszne, bo zrealizowały bieżące cele i dostarczyły realną wartość biznesową dla klienta, który mógł szybko zacząć zarabiać na aplikacji.

Jakub: Aktywnie interesujemy się tym, z jakimi problemami boryka się sam klient, jak i użytkownicy produktu. Pozwala nam to wychodzić od konkretnego problemu i proponować odpowiednie rozwiązania. Przykładem może tu być ułatwienie użytkownikom zakładania konta w aplikacji. Mieliśmy zdefiniowany domyślny proces, ale z analizy zachowań użytkowników okazało się, że mają potrzebę wykonywać go z innego miejsca – z powiadomienia mail/sms o otrzymaniu wyników testów. Dołożyliśmy tę możliwość i dzięki temu zmniejszyliśmy liczbę zapytań o umożliwienie dostępu do własnego konta.

Na podstawie jakich zasad podejmujecie decyzję, którym podejściem będziecie kierować się realizując dany projekt?

Jakub: To zależy od tego na jakim etapie jest klient – czy dopiero na etapie formułowania pomysłu, czy już ma rozpisane user stories i zrobione designy. Zawsze dostosowujemy nasze działanie, tak aby zrozumieć wartość biznesową danego produktu/projektu, co w rezultacie pomaga nam wybrać optymalną ścieżkę jej dostarczenia.

Mówiliśmy o niezależności, więc teraz porozmawiajmy o odpowiedzialności. Czym dla Was jest odpowiedzialność za projekt?

Jakub: Osobiście mam problem z rozdzieleniem tych dwóch kwestii. Co więcej, najpierw jest odpowiedzialność, a później pojawia niezależność. Dzięki ciągłemu braniu odpowiedzialności za nasze działania, budujemy zaufanie, co w rezultacie zwiększa możliwości bycia niezależnym. A czym jest sama odpowiedzialność? Świadomością konsekwencji działań, które podejmujemy oraz bezpośrednią komunikacją w przypadku jakichś nieprzewidzianych sytuacji.

Dominik: Support jest niezłym przykładem odpowiedzialności. Prócz tego, mamy wolność w doborze technologii, jednak w takim przypadku wybór czegoś, z czym nie mamy doświadczenia, byłby nieodpowiedzialny. Zwykle we własnym zakresie badamy technologie, przy okazji swoich pobocznych projektów i dopiero po zgłębieniu proponujemy wdrożenie, jeżeli pomoże ono rozwiązać jakiś problem.

Jak sprawdzić, czy w firmie, do której aplikuję, panują tego typu zasady?

Dominik: Zorientować się, jak wygląda struktura firmy. Czy jest bardziej płaska, czy jest może hierarchiczna. Można zapytać, jak formułowane są user stories / wymagania dla zespołu. Czy developerzy biorą udział w rozmowach z klientami poza sprint review? Czy zespół wie, jaki jest model biznesowy produktu? Najlepszym sposobem, jeżeli jest taka możliwość, jest rozmowa z osobą, która tam pracuje.

Otwartość na uwagi to jedna z cech, której poszukujecie wśród kandydatów? Co, jeśli tej cechy nie zauważacie?

Jakub: Zdecydowanie chcemy pracować z osobami, które są tzw. graczami zespołowymi i rozumieją efekt synergii. Jednym z elementów bycia taką osobą jest otwartość na uwagi. Zazwyczaj podczas rozmów kwalifikacyjnych pośrednio lub bezpośrednio o to pytamy. Co jeżeli jej nie zauważymy? No cóż, zakładam że są inne firmy IT, dla których może to nie być istotne.

Dominik: Kultura feedbacku w PC jest wysoka. Myślę, że to cecha osób, które przykładają dużą wagę do rozwoju. Oczywiście potrzeba tutaj trochę umiejętności miękkich, aby feedback w odpowiedni sposób dawać oraz go przyjmować. A jeśli nie, to osoby takie albo nie przechodzą rozmowy, albo zwykle same odchodzą po jakimś czasie.

dominik pragmatic coders

Dominik Króliczek, Software Developer w Pragmatic Coders

Co jeszcze, Waszym zdaniem, kształtuje charakter programisty, inżyniera?

Dominik: Myślę, że pewna liczba godzin spędzonych na rozwiązywaniu problemów znacząco wpływa na charakter. Na pewno byłbym innym człowiekiem, gdyby nie te wszystkie zarwane noce, poświęcone na naukę. Chęć rozwoju i ciekawość to cechy, które nabyłem. W Pragmatic Coders nauczyłem się także, że nie każdy problem jest problemem, niektóre można pominąć zamiast rozwiązywać i te wskazówki stosuje w codziennym życiu. I oczywiście przyjmowanie i dawanie feedbacku.

Jakub: Z mojej perspektywy jest to otwartość na rozmowę o każdym aspekcie implementowanego rozwiązania – zarówno kwestie techniczne, jak i biznesowe. Dzięki temu programiści poznają cały obraz tego, dlaczego dana funkcjonalność jest istotna i jaką da wartość biznesową klientowi. Na bazie tego stają się coraz lepszymi partnerami do rozmowy, którzy potrafią dobrze argumentować swoje pomysły.

Co w dłuższej perspektywie daje organizacji otwartość na pomysły pracowników, oddanie im odpowiedzialności za projekt, zespół, po części za firmę?

Jakub: Tak samo jak dla samego pracownika, również dla organizacji jest to ciągły rozwój. Osoby wdrażające pomysły w swoich projektach są w stanie stosunkowo małym kosztem zweryfikować ich użyteczność. Jeżeli okażą się trafione, wtedy tą wiedzą dzielimy się na naszych Monday Talkach. Akurat wspólnie z Dominikiem ostatnio to robiliśmy, omawiając nasz przypadek zmiany dostawcy odpowiedzialnego za wysyłkę SMSów – dostarczyliśmy do pozostałych zespołów sporo wiedzy zarówno technicznej jak i biznesowej. Takie działanie daje naturalną możliwość budowania coraz większych kompetencji i bazy wiedzy.

Dominik: W PC mamy grupy, które skupiają osoby pełniące w zespołach różne role. Na przykład mamy Gildię Scrum, w której omawiamy aktualne problemy związane z procesami scrumowymi w poszczególnych zespołach. Dzielimy się wiedzą i pomysłami na rozwiązanie tych problemów. Istnieje też analogiczna Gildia Product Ownerów. Kolejna grupa jest złożona z programistów, którzy pracują nad procesem otwierania nowych projektów. Każdy może dołączyć do poszczególnych grup i mieć wpływ na to, jak pracujemy w PC.

Co oprócz niezależności i odpowiedzialności cechuję dobrą organizację? Z drugiej strony, czego powinniśmy się wystrzegać szukając pracy?

Jakub: Dla mnie najlepszą odpowiedzią na to pytanie są ludzie. To czy mamy niezależność, odpowiedzialność lub inne cechy w organizacji, zależy wprost od tego, kto tę organizację tworzy. Dlatego też, jak już wcześniej wspominał Dominik, warto złapać kontakt z kimś, kto już w danej organizacji pracuje, aby zapytać o to, co jest dla nas istotne. Nie ma jednej recepty, że dana organizacja jest idealna. Każdy z nas zwraca uwagę na inne kwestie i to właśnie one powinny decydować, czy chcemy zacząć współpracę, czy nie.

Dominik: Dla mnie ważny jest realny wpływ na to co robię i możliwość rozwijania produktów, szczególnie w początkowych fazach, bo po prostu to lubię i chcę rozwijać się w tym kierunku. Z mojej perspektywy gorąco polecam organizację Pragmatic Coders, pracujemy nad ciekawymi projektami, mamy wpływ na to, dokąd zmierzamy i transparentność na wysokim poziomie.


Dominik Króliczek. Software Developer w Pragmatic Coders. Wchodził do branży jako Javowiec, pracował również w node.js, tworzył apki oparte o blockchain (głównie Ethereum). Jego najmocniejszym stackiem jest node.js, typescript, serverless. Preferuje pracę z projektami w początkowej fazie. Pomagał bratu rozwinąć startup – parkingshare.org, który działa produkcyjnie, ma klientów i rośnie. W wolnych chwilach rapuje (można posłuchać pod ksywką “Krulig”). Zaprasza na instagram.

Jakub Dobosz. Product Owner w Pragmatic Coders. Skupiony na wartości biznesowej i szukaniu dróg dostarczenia jej w optymalny sposób. Ceni synergię zespołu, przejrzystość działania i otwartą komunikację. W branży IT od ponad 10 lat w różnych rolach (programista, PM, lider). Poza tym partner produktywności na intencjonalnie.pl. Zbiera energię poprzez poranne pływanie, jazdę na rowerze, medytację oraz podróże.

Redaktor naczelny w Just Geek IT

Od pięciu lat rozwija jeden z największych polskich portali contentowych dot. branży IT. Jest autorem formatu devdebat, w którym zderza opinie kilku ekspertów na temat wybranego zagadnienia. Od 10 lat pracuje zdalnie.

Podobne artykuły

[wpdevart_facebook_comment curent_url="https://justjoin.it/blog/najpierw-odpowiedzialnosc-pozniej-niezaleznosc-o-tym-jak-miec-realny-wplyw-na-decyzje/" order_type="social" width="100%" count_of_comments="8" ]