Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Jak być programistą, który ma wpływ na firmę?

W idealnym świecie programista ma większy lub mniejszy wpływ na produkt i firmę, dzięki swojej specjalistycznej wiedzy. Sprawdź, czy w praktyce jest to możliwe, na przykładzie firmy Northmill Bank.

Firmy korzystające z rozwiązań IT decydują się na outsourcing oprogramowania lub zatrudniają programistów. Bez względu na model współpracy, możemy mieć do czynienia z programowaniem lub rzemieślnictwem, przy czym jedno podejście nie jest lepsze od drugiego - są inne. Zdarza się często, że nie rozumiemy potrzeb biznesowych czy nawet problemów, które powinna rozwiązać zaproponowana zmiana. Klient zleca nową funkcjonalność, a programista wykonuje ją wedle specyfikacji, czasem bez zająknięcia, nawet jeśli wydaje się nie mieć to większego sensu. 

Wspomniana wyżej praktyka jest dość popularna, ale spróbujmy sobie zadać pytanie: „Czy można inaczej”? Mam na imię Daniel i pracuję jako Full-stack developer w Northmill Bank, banku ułatwiającym życie finansowe klientów.  Odpowiadając na powyższe pytanie - oczywiście, że można inaczej. Bycie świadomym programistą to tak naprawdę nie tylko umiejętności pisania kodu, posiadanie wiedzy o “wszystkich” frameworkach świata, czy znajomość wielu języków programowania - choć na pewno zwiększa to wartość na rynku. Jednak to nie wszystko. Niejednokrotnie bardzo ważne jest, żebyś rozumiał/a biznes swojej firmy oraz kontekst produktu, nad którym pracujesz. Wszystko po to, aby być w stanie proponować rozwiązania oraz, w razie potrzeby, kwestionować elementy lub zadania, które według Twojej wiedzy domenowej nie mają sensu, wartości lub są zbyt kosztowne.

Dokładnie takie rzeczy robię jako programista w Northmill Banku. Mam przede wszystkim głos, nieraz decydujący, czy coś będziemy robić, czy nie, w jakiej kolejności, a także proponuję rozwiązania, które wystarczająco zaspokoją potrzeby biznesu, a nie będą zbyt kosztowne. Czuję i mam świadomość, że mój głos ma znaczenie. Jestem pewien, że gdyby nie to, nie stworzylibyśmy takich produktów jak kredyty konsolidacyjne, karty kredytowe, konta oszczędnościowe czy też ubezpieczenia, a przynajmniej nie tak szybko, utrzymując przy tym zasady “czystego kodu”

Całość zbudowaliśmy i nadal budujemy w chmurze AWS. Dlaczego? Na pewnym etapie to my, programiści, zdecydowaliśmy, że warto się zainteresować tym rozwiązaniem. To nasza inicjatywa i decyzja podjęta po konsultacjach z innymi pracownikami sprawiła, że nasze produkty są tworzone w podejściu serverless. 

Wcześniej też nie pracowaliśmy na fizycznych serwerach. Nasze aplikacje były hostowane w chmurze u innego dostawcy. Z punktu widzenia biznesu zmiana jednej chmury na drugą nie zawsze ma sens - kosztowne są zarówno migracje, jak i jednoczesne korzystanie z dwóch dostawców (a przynajmniej przez pewien czas). Decyzja została podjęta przez nas po konsultacji z innymi działami w firmie. Skoro uważaliśmy, że przyniesie to wartość w postaci łatwiejszej pracy w przyszłości, to zainwestowaliśmy w zmianę, bo kto jak nie programista wie lepiej, co dla niego jest dobre

Wracając do samych produktów, jakie oferujemy jako bank - przykładem tego, że decyzja może być podejmowana przez każdego pracownika na każdym stanowisku, jest Reduce - produkt oferujący konsolidację swoich dotychczasowych kredytów z niskim oprocentowaniem i z prostym procesem aplikowania. Może trudno w to uwierzyć, ale byliśmy w stanie stworzyć pierwszą działającą produkcyjnie wersję produktu w mniej niż 2 miesiące! Ilu ludzi nad tym pracowało? Wyda się to niemożliwe, niemniej nad projektem pracował zespół 15-osobowy, składający się z full-stack developerów, Android i iOS developerów, UX designerów i product managerów.

Jestem przekonany, że nie byłoby to możliwe, gdyby nie fakt, że w całym gronie przegadywaliśmy praktycznie każdą kwestię, czy to odnośnie funkcjonalności, czy stricte implementacyjną. Całe rozwiązanie pod kątem koncepcyjnym mieliśmy dopracowane w około 2 tygodnie i już wtedy było ono pozbawione “bolączek wieku dziecięcego”. Każdy miał możliwość wyrażenia swojej opinii i oszacowania czy coś jest możliwe do zrobienia, a jeśli jest, to jakim nakładem pracy i czasu. 

Decyzje i wpływ na domenę biznesową jako programista w Northmill Banku mam dosłownie na każdym kroku i praktycznie każdego dnia. Projektem ostatnich miesięcy, który dopiero niedawno ujrzał światło dzienne był projekt odświeżenia kart kredytowych. Same karty kredytowe to długie rozmowy i rozważania odnośnie tego co i jak zbudować. Tutaj znów wielu programistów, w tym ja, mieliśmy wpływ na toczące się rozmowy i ich konkluzje. Mogliśmy popierać kwestie, z którymi się zgadzamy, ucinać niepotrzebne dyskusje, czy redukować wymagania jakie zakłada dział produktu do koniecznego minimum, lub ich właściwą klasyfikację i podział na fazę MVP i post-MVP. Mieliśmy także duże pole manewru na proponowanie naszych własnych pomysłów. Przyznaję, że jest to bardzo satysfakcjonujące, kiedy Twoje sugestie nie pozostają bez odzewu i niejednokrotnie ich efekty można ujrzeć bardzo szybko w postaci pewnych decyzji. 

Karta kredytowa to też przykład bardzo nietypowego projektu, w którym trzeba zahaczyć o wiele aspektów biznesowych, takich jak procesy naliczania odsetek, wystawiania faktur i gdy nadejdzie taka potrzeba, zastanowienie się nad wymaganiami prawnymi takimi jak: “Co, jeśli ktoś nie otrzyma faktury?”, lub też “Czy istnieje minimalny czas, jaki musi zostać spełniony po otrzymaniu faktury na jej spłatę?”.

Czasami są to bardzo trywialne pytania, a czasami bardzo istotne i to z nich wynikają wymagania, jakie nakłada na daną funkcjonalność dział produktu. Warto zrozumieć takie rzeczy. Nie tylko pozwoli nam to na lepsze zrozumienie tego, co robimy, ale także sprawia, że nasze pytania pozwolą na uchronienie się od przyszłych błędów - wszyscy jesteśmy ludźmi i popełniamy błędy, a nie ma nic lepszego od zapytania kogoś “Czy ten fragment ma sens?” albo zwykłe “Dlaczego tak?”. 

Poniżej krótka metoda działająca produkcyjnie, która używana jest przez API kontroler do pobierania danych o karcie kredytowej, wywoływana tysiące razy dziennie. Nad jej zarysem i funkcjonowaniu miałem pełną kontrolę, mając w głowie to, że znam potrzebę biznesową, ale także kwestie i ograniczenia natury technicznej. 

Fragment kodu do pobierania danych o karcie kredytowej 

Jako programiści w Northmillu mamy wpływ na kształt tego, jak będzie wyglądała nasza firma. Znacznie lepiej, jak i również z większym zapałem podchodzi się do zadań, które samemu się analizowało, brało udział w rozmowach przyczyniających się do definiowania produktu. Mając wpływ pracuje się efektywniej, a pisanie kodu jest wtedy zdecydowanie bardziej satysfakcjonujące. 


MakeAnImpact - miej wpływ!

Artykuł powstał w ramach akcji #MakeAnImpact promującej projekty IT, które mają wpływ na otaczający nas świat. Skierowana jest do do społeczności IT.

Zobacz kogo teraz szukają