niezależność w it

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

– 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.

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

ZOBACZ TEŻ:  Droga Nowoczesnego Architekta. Wywiad z Maciejem Aniserowiczem

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.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Przyszłość jest teraz. Powstały soczewki z zoomem