Cześć, tu Michał Diner – jestem Senior Android Engineerem w Svitla Systems.

Na co dzień dłubię w Compose, ogarniam architekturę i próbuję robić rzeczy, które nie tylko działają, ale też mają sens. Coraz częściej łapię się na tym, że samo „dowożenie ticketów” to za mało – i właśnie o tym jest ten tekst. Chcę pokazać, jak jako programiści możemy brać większą odpowiedzialność za produkt, bez wchodzenia w buty PM-a.

Programiści od lat postrzegani są głównie jako wykonawcy — ktoś inny projektuje, a oni to po prostu wdrażają. Ale to się zmienia. W szybkim, nastawionym na efekty środowisku IT, deweloperzy przestają być tylko „koderami” — coraz częściej wpływają też na strategię produktu, pomagają zespołom zrozumieć co budujemy i po co.

W Svitla Systems, mimo że oficjalnie nie pełnimy funkcji właścicieli produktu, często przyjmujemy podobny sposób myślenia. Warto zaznaczyć: nie chodzi o zacieranie granic między rolami. Programista to nie product manager, ale może się rozwinąć — zawodowo i osobiście — adaptując część tego podejścia. Jak? Poprzez lepsze zrozumienie celów biznesowych, potrzeb użytkownika i długofalowego wpływu swoich decyzji technicznych.

Wierzymy, że kiedy programiści mają bardziej produktowe podejście, rezultatem tego jest lepsza komunikacja, tworzenie skuteczniejszych funkcji i produktów, które mają szansę odnieść sukces na rynku.

Jak zmienia się rola dewelopera i jak wejść w tryb „rozwiązywania problemów”

Zwinne metodyki, a szczególnie Scrum, promują zespoły cross-funkcyjne, w których programiści są zaangażowani od samego początku — razem z PM-ami, UX-ami i designerami. Nie chodzi tylko o wydajność, ale o to, by produkt był realny technicznie, opłacalny i przyjazny użytkownikowi.

Przykład Atlassiana: programiści biorą udział w burzach mózgów już na etapie pomysłu, wykorzystując swoje umiejętności techniczne do budowania skalowalnych i wykonalnych rozwiązań.

W Spotify zespoły pracują w tzw. „squadach” – programiści, designerzy i product lead wspólnie odpowiadają za doświadczenie użytkownika. Ten model praktycznie stał się standardem przy wprowadzaniu nowych produktów.

W takim środowisku programista nie kończy pracy na zrobieniu ticketu. Zadaje pytania: Jaki problem rozwiązuję? Jak zareaguje użytkownik? Czy to będzie działać za pół roku? – i to właśnie wtedy zaczyna się prawdziwa odpowiedzialność.

1. Spójrz szerzej

Wzięcie odpowiedzialności oznacza zrozumienie, jak konkretne zadanie wpisuje się w większą wizję biznesową i produktową. Kiedy programista wie, dlaczego dana funkcja jest ważna, podejmuje lepsze decyzje techniczne, kwestionuje błędne założenia i proponuje alternatywy korzystne dla użytkownika.

Załóżmy, że zespół ma przyspieszyć działanie dashboardu, a programista nie ma wglądu w wzorce użytkowania, może to oznaczać optymalizację zapytań o dane bez kontekstu. Jeśli dashboard jest używany głównie w godzinach pracy przez użytkowników korzystających z urządzeń mobilnych o słabym połączeniu Wi-Fi, wdrożenie renderowania po stronie serwera lub minimalizacja rozmiarów pakietów może mieć większy wpływ na wydajność.

Dlatego kluczowe jest, aby dane dotyczące użytkowania, wnioski z analizy produktu i opinie klientów wyznaczały priorytety rozwoju.

Ta szersza wizja jest potrzebna nie tylko do efektywniejszego kodowania, ale także do zapobiegania marnotrawieniu wysiłku i czasu. Zespoły marnują tygodnie na dopracowywanie funkcji, które nikogo nie interesują, i zaniedbują stopniowe zmiany, które mogą radykalnie poprawić satysfakcję. 

2. Przyjmij proaktywny sposób myślenia

Manager produktu nie czeka na tickety – działa z wyprzedzeniem i przewiduje problemy, zanim się pojawią.

Jeśli widzisz, że nowa funkcja generuje dług techniczny (np. hardkodowane wartości, zbędna logika), zgłoś to i zaproponuj lepsze rozwiązanie — nawet jeśli nikt Cię o to nie poprosił.

To samo z UX-em. Rzeczy tak drobne jak liczba kliknięć do wykonania akcji czy niespójne etykiety przycisków wpływają na satysfakcję użytkownika. Pokazując takie problemy wcześniej i proponując poprawki, pokazujesz, że zależy Ci na jakości.

Wzięcie odpowiedzialności to także zainteresowanie się o to, co dzieje się po wdrożeniu. Jak wszystko działa w produkcji? Jak użytkownicy wchodzą z nim w interakcje? Czy można coś poprawić? Tu pomocne są Sentry, New Relic, Firebase Analytics. Jeśli coś się psuje — nie czekaj, aż QA zgłosi błąd. Bądź pierwszym, który to sprawdzi.

3. Komunikuj się transparentnie

Prawdopodobnie najważniejszą cechą brania na siebie większej odpowiedzialności jest umiejętność komunikacji. Chodzi nie tylko o mówienie co się stało, ale dlaczego to ma znaczenie.

Zamiast: „Implementacja listy jest nieefektywna”, lepiej powiedzieć: „Lista produktów przycina się podczas scrollowania na tańszych telefonach. Przez to użytkownicy mogą nie dojść do przycisku 'Kup teraz'”.

W Androidzie z Jetpack Compose może to oznaczać optymalizację renderowania — by ekran nie był rysowany od nowa przy każdym scrollu.

Dobra komunikacja to też umiejętność odmawiania. Jeśli ktoś z biznesu prosi o coś nierealnego technicznie albo sprzecznego z UX-em, programista powinien zaproponować alternatywę w kontekście celu biznesowego.

Dobra komunikacja pozwala także lepiej zrozumieć odbiorców. Interesariusze nie muszą znać wszystkich niuansów tech stacku; muszą być jednak świadomi, jak dane wyzwanie techniczne wpłynie na czas wprowadzenia produktu na rynek lub zadowolenie użytkowników. Umiejętność tłumaczenia i komunikacji między różnymi obszarami (np. z biznesem, odbiorcami, itd.) to właśnie to, co odróżnia programistów biorących większą odpowiedzialność za produkt od osób tylko piszących kod.

Konkretne kroki, by brać większą odpowiedzialność

1. Zadawaj właściwe pytania

Wszystko zaczyna się od ciekawości. Pytaj:

• Jaki problem użytkownika to rozwiązuje?
• Jaki jest cel biznesowy tej funkcji?
• Jakie są założenia, które powinniśmy sprawdzić?

Jeśli product manager prosi o popup z potwierdzeniem usunięcia, zapytaj: „Czy chodzi o zapobieganie przypadkowym kliknięciom, czy potrzebujemy czegoś w stylu “cofnij”?” To zmienia rozmowę z “jak to zrobić” na “dlaczego to robimy” – i poprawia jakość produktu.

2. Rozmawiaj z interesariuszami

Bycie obecnym to również krok do brania odpowiedzialności. Programista powinien brać udział w planowaniu sprintów, testach UX, przeglądach — nie tylko stand-upach. Dzięki temu wie, z jakimi problemami mierzą się inni, i może zaproponować rozwiązania techniczne, które inaczej by umknęły.

Np. UX designer proponuje nietypowe komponenty w aplikacji mobilnej. Programista nie mówi "nie", ale przypomina, że zbytnie odejście od Material Design to większa złożoność, niespełnione oczekiwania użytkowników i potencjalne bugi. Kilka niestandardowych elementów to jedno — przebudowa całego UI to drugie.

Tu nie chodzi o wyręczanie innych w pracy. Chodzi o to, by wszyscy byli na bieżąco i dążyli do wspólnego celu.

3. Myśl w kategoriach efektów, nie funkcji

Funkcja bez efektu = zero wartości. Programista z podejściem produktowym nie patrzy na tickety, tylko na to, co one faktycznie dają.

Czy zwiększyliśmy zaangażowanie? Zmniejszyliśmy frustrację? Czy rozwiązanie jest skalowalne?

Tu wchodzą metryki: konwersje, błędy, czas ładowania, adopcja funkcji. Dodawaj logowanie i analitykę już na etapie developmentu, by śledzić realne wyniki. Dzięki temu zamykasz pętlę między kodem a rezultatem — i wiesz, co działa.

Od czego zacząć?

Warto sięgnąć po materiały i kursy z zakresu product developmentu. Nawet jeśli nie są skierowane do programistów, pomagają zrozumieć, jak myślą inni. Mentoring też ma ogromne znaczenie — pytaj starszych devów, jak oni wdrażają takie podejście w codziennej pracy.

Case study: od programisty do partnera strategicznego

Aleksandra, programistka z firmy fintechowej, świetnie pisała kod i zawsze “dowoziła” na czas. Ale zaczęła zauważać, że mimo realizacji funkcji zgodnie z planem, użytkownicy wciąż byli sfrustrowani, a lista poprawek rosła z każdym sprintem. Zamiast to zignorować, potraktowała to jako sygnał, że coś trzeba zmienić.

Zaczęła aktywnie uczestniczyć w planowaniu sprintów — nie żeby przejąć rolę PM-a, ale by lepiej projektować techniczne rozwiązania. Zadawała pytania typu „Dla kogo to jest?” czy „Po czym poznamy, że to działa?” — co pozwoliło szybciej wyłapywać edge case'y i ograniczenia.

W jednym ze sprintów zespół miał stworzyć onboarding. Pierwszy pomysł: długa instrukcja. Aleksandra zaproponowała podejście tzw. progressive disclosure, czyli wprowadzenia informacji krok po kroku, tylko wtedy, gdy są potrzebne – i nie tylko zasugerowała, ale wdrożyła A/B testy, spięła analitykę i przygotowała dwa warianty. Efekt? 40% więcej ukończonych onboardingów i mniej ticketów do supportu.

W innym przypadku zauważyła zapomniany przycisk „Eksportuj do CSV” na pulpicie produktu. Zamiast go zignorować, zażartowała o tym na retro, a potem przeprowadziła analizę, aby to zbadać. Wyniki skłoniły zespół do zastąpienia go automatycznymi raportami, i… pozbyli się problemu. Mniej frustracji, mniej kodu.

Aleksandra nie zmieniła pracy — zmieniła podejście. To dowód, że dobry inżynier to nie tylko ktoś, kto koduje, ale ktoś, kto rozumie system, zna użytkownika i działa z ciekawością i precyzją.

Podsumowanie: jak zostać prawdziwym partnerem w budowaniu produktu

Branie większej odpowiedzialności to nie robienie cudzej pracy. To robienie swojej — ale z szerszej perspektywy: z myślą o użytkownikach, strategii i trwałości rozwiązań.

Programista może — i powinien — zadawać pytania, rozmawiać z interesariuszami i myśleć o efektach długoterminowych. Takie podejście buduje silniejsze zespoły, szybsze iteracje i produkty, które naprawdę mają sens.

Kod to tylko połowa historii. Ci, którzy myślą jak product owner, stają się partnerami w tworzeniu czegoś wartościowego.

________________________________

Autor: Diner Michał — Senior Android Engineer w Svitla Systems.

Michał to doświadczony inżynier Androida, specjalizujący się w tworzeniu skalowalnych i przyjaznych użytkownikowi aplikacji mobilnych. Pasjonuje się czystą architekturą i optymalizacją wydajności, dostarczając solidne rozwiązania dla złożonych wyzwań biznesowych.

Źródła:

- "Scrum (software development)" – Wikipedia

- "How Spotify Builds Products" – Mind the Product

- Atlassian Agile Coach

- "Bridging the Gap Between Technical and Non-Technical Teams" – Omid.dev

- Google Design Sprint FAQ – Wired