Gdy szuka się firmy, albo ogólnie myśli o swoim programistycznym rozwoju, chyba najłatwiej przychodzi nam skupienie się na wiedzy. i technologiach.Zazwyczaj właśnie pod takim kątem oceniamy różne szanse i możliwości. Czy projekt jest nowy? Jakie technologie? Jak doświadczony zespół? Jaka metodologia pracy? To nie są złe pytania, ba, uważam, że absolutnie powinny paść na każdej rozmowie, niemniej moje ostatnie doświadczenia pokazały mi, że można też zupełnie inaczej zbierać doświadczenia i rozwijać się. Co więcej, myślę tutaj nie tylko o rozwoju swoim, ale i całego zespołu, projektu czy firmy. A tym co robi różnicę, jest absolutne skupienie na kliencie i tym, by produkt spełniał jego oczekiwania. O różnych tego konsekwencjach przeczytacie w poniższym wpisie.
Klient ma zawsze rację
To akurat nieprawda, i nie należy działać według tej dewizy. Niemniej, jeśli twój klient czy użytkownik zgłasza potrzebę czy problem, należy przede wszystkim zastanowić się, co on ma na myśli i dopytać dokładnie, czemu właśnie tego potrzebuje. Czasem może być tak, że zaawansowany edytor, którego oczekuje jest po prostu edytorem, jakiego używał w poprzednim systemie do osiągnięcia bardzo prostej rzeczy. Czasem, może on również nie do końca rozumieć, jak produkt działa i oczekiwać funkcjonalności nie do końca zgodnej z jego wizją. Czasem, korzystając z jednej części aplikacji, może wskazać pomysł na rozwój zupełnie innej. Niemniej, to właśnie od klienta możemy dostać prawdziwą informację na temat jego potrzeb, co powinno przekładać się bezpośrednio na nasze plany rozwoju produktu. I takie założenie, choć niby oczywiste i banalne, naprawdę ułatwia planowanie i wyznaczanie naszych priorytetów.
Skąd u programistki takie przemyślenia? Bo w swojej pracy współuczestniczę w procesie tworzenia produktu. Mam dostęp do informacji zwrotnych od użytkownika, mogę brać udział w user testach, a gdy brakuje mi jakiegoś kontekstu w mojej implementacji, zawsze pytam designera albo product managera. Gdy przedstawiany jest nam plan na dalsze funkcje, nie są one “z kosmosu”, albo tajemniczo wypełnianego backlogu, a właśnie z tych potrzeb, problemów i oczekiwań. Gdy pojawia się bug, sprawdzamy jak bardzo jest uciążliwy dla użytkownika i z takim priorytetem go rozwiązujemy. Nie mam więc poczucia, że to kolejny ticket do zamknięcia, a raczej, że to realne bolączki, w których mogę użytkownikowi pomóc. Pomiędzy klientem a mną nie ma sztucznych barier tworzonych przez analityków, project managerów i dyrektorów. Te osoby są oczywiście w strukturach firmy, ale nie przeszkadzają, a pomagają w układaniu tej relacji i budowaniu dobrego zrozumienia.
Grasz dla zespołu, a nie dla siebie
Jeśli naszym głównym celem jest pomoc użytkownikowi poprzez nasz produkt, to dość naturalnie przychodzi coś bardzo, bardzo ważnego. Gra zespołowa. Działanie na korzyść produktu, to też działanie na korzyść zespołu. Jakie są z tego zyski?
Mogłam ostatnio przysłuchać się kilku rozmowom o relacji senior — junior i powiem szczerze byłam mocno zdziwiona tym, co usłyszałam. A mianowicie oczekiwaniu, by junior seniorowi nie przeszkadzał, czekał aż tamten będzie miał wyznaczony dla niego czas, kolejkował swoje problemy… W moim obecnym zespole, gdy ktoś ma problem niezależnie od pozycji, po prostu o nim pisze/mówi i w miarę możliwości, ale raczej szybciej niż później zyskuje odpowiedź na swoje pytanie. Mamy wewnętrzne stack overflow, czy slackowe kanały tematyczne, jednak to tylko narzędzia, postawa jest znacznie ważniejsza. I w niej, każdy z nas skupia się raczej na rozwiązaniu problemu, niż na pokazaniu kto jest mądrzejszy. A im szybciej problem zostanie rozwiązany(nie zależnie czy mój czy mojego kolegi), tym lepiej dla projektu i klienta. Podobnie z code review. Skupiamy się w nim przede wszystkim na efektywnej implementacji i podzieleniu się wiedzą, jeśli jest taka potrzeba (więcej o dobrym code review przeczytasz tutaj!).
Inną rzeczą jest elastyczność i brak przywiązania do kodu. W poprzednich firmach, zawsze był taki ktoś, kogo kodu bano się ruszać, a przepisywanie na nowo pewnych rozwiązań, było niemal zawsze “wyceniane” na nie warte fatygi. Nawet w sytuacji, gdzie jasno mówiliśmy, że tylko na tym zyskamy. Gdy jednak programiści myślą o produkcie a nie technologiach, to podejście do kodu jest również inne. Znacznie łatwiej przychodzą zmiany, nawet te drastyczne jak usuwanie, czegoś, co powstało nie tak dawno. Kod nie jest efektem naszej pracy, jest nim działający produkt i takie podejście naprawdę dużo zmienia.
Podejmowanie decyzji technologicznych i bycie guru
Skupienie na produkcie pomaga też w zdroworozsądkowym podejściu do nowych technologii, bibliotek i refaktoru kodu. Gdy na szybko się coś nabałaganiło, to trzeba to potem posprzątać. Nie ma jednak mowy o poprawianiu kodu do perfekcji (której przecież nie da się osiągnąć). Ale też w drugą stronę, jest pewien akceptowalny poziom, poniżej którego nie zejdziemy jako zespół.
Implementowanie najnowszych bibliotek nie jest celem samym w sobie, niemniej, szukanie ich, gdy pojawiają się problemy (lub gdy przewidujemy, że coś może się niedługo przydać), jest raczej normą. Kto podejmuje takie techniczne decyzje? Zespół. We współpracy z naprawdę doświadczonymi osobami, które chętnie dzielą się wiedzą. Świetnym jest to, że Ci ludzie absolutnie nie chcą być niezastąpionymi, szanują swój czas i naprawdę chętnie dzielą się swoją wiedzą. To układ win-win, bo im więcej wiedzy jest łatwo dostępne (dokumentacja, dobre praktyki, nagrania z cotygodniowego tech talku, czy specjalne dużury z zespołami współtworzącymi infrastrukturę), tym szybciej i bardziej samodzielnie można poradzić sobie z problemami. Wartość eksperów technicznych to nie tylko to, co sami są w stanie zaimplementować, ale (a może przede wszystkim), co z ich pomocą mogą zrealizować inni.
Narzędzia a nie cel sam w sobie
Metodyki projektowe, frameworki, biblioteki, to wszystko tylko narzędzia, z których korzystamy.One mają działać dla nas, a nie odwrotnie. Z doświadczenia znam bycie niewolnikiem “Scruma” rozumianego przez organizowanie spotkań, które naprawdę nie za wiele wnosiły. Dochodziło czasem od kuriozum, gdzie ludzie czekali ze swoimi problemami 1.5 tygodnia, do retrospektywy, ale wiecie, było nowocześnie i zwinnie (w projekcie, który używał iteracji, choć wcale ich nie potrzebował). Podobnie z technologiami, których nadmierne uwielbienie może wprowadzić wielkie legacy (no bo architekt zawsze stosował ten framework, więc wszyscy musimy), albo po prostu zmusić do przepisywania kodu tylko dla samego przepisywania (bo inne firmy używają tego języka, to i my musimy).
Mając wizję, że to jednak nasz produkt i jego użytkownik jest najważniejszy, można odeprzeć takie pokusy i dobierać narzędzia tak, by pomagały osiągnąć cel biznesowy, nawet jeśli nie da się nimi pochwalić przed kolegami (chociaż umówmy się, jeśli biznes się kręci to jest się czym pochwalić ;)).
Zaczęłam od rozwoju programisty i na nim skończę, bo czytając ten wpis możesz zastanawiać się, no i gdzie ten rozwój?
Gdy przyjmiesz postawę skupienia na użytkowniku i dostarczenia najlepszego produktu, to on sam przyjdzie. Nie będzie to znajomość najnowszych bibliotek, rozeznanie w definicjach elementów Sprintu czy ilość wystąpień publicznych — to wszystko można ‘wyczytać’ z książek lub ‘załatwić’ w czasie studiów. Będzie to umiejętność wykorzystania technologii do rozwiązywanie konkretnych problemów, rozumienia interesu klienta/użytkownika oraz możliwość pomocy w podjęciu przez niego najlepszej możliwej decyzji — czyli wszystko to, co zwykliśmy nazywać “doświadczeniem”. To wszystko będzie twoimi narzędziami by pomóc użytkownikom osiągnąć ich cel.
Co więcej, takie podejście pozwoli Ci też bardzo łatwo odpowiedzieć na pytanie: “którą technologię/rozwiązanie wybrać?” - wystarczy przekształcić je w pytanie: “która będzie lepsza z punktu widzenia użytkownika/klienta?”. I taka postawa pomoże biznesowi osiągnąć sukces. Wizja samotnego programisty w świecie ekranów jak z matrixa już dawno powinna zniknąć z Twojej głowy. Praca z daleka od biznesu, w izolacji, w dłuższej perspektywie naprawdę nie pomaga we wszechstronnym rozwoju, a wręcz przeciwnie, może budować totalne oderwanie od faktycznych potrzeb i rozwiązywania problemów. Dlatego: programisto, pokochaj produkt i jego użytkowników!
