Programisto, pokochaj produkt!

By 20 June 2018 Inspiracje

Gdy szu­ka się firmy, albo ogól­nie myśli o swoim pro­gramisty­cznym roz­wo­ju, chy­ba najłatwiej przy­chodzi nam skupi­e­nie się na wiedzy. i technologiach.Zazwyczaj właśnie pod takim kątem oce­ni­amy różne szanse i możli­woś­ci. Czy pro­jekt jest nowy? Jakie tech­nolo­gie? Jak doświad­c­zony zespół? Jaka metodolo­gia pra­cy? To nie są złe pyta­nia, ba, uważam, że abso­lut­nie powin­ny paść na każdej roz­mowie, niem­niej moje ostat­nie doświad­czenia pokaza­ły mi, że moż­na też zupełnie inaczej zbier­ać doświad­czenia i rozwi­jać się. Co więcej, myślę tutaj nie tylko o roz­wo­ju swoim, ale i całego zespołu, pro­jek­tu czy firmy. A tym co robi różnicę, jest abso­lutne skupi­e­nie na klien­cie i tym, by pro­dukt speł­ni­ał jego oczeki­wa­nia. O różnych tego kon­sek­wenc­jach przeczyta­cie w poniższym wpisie. 

Klient ma zawsze rację

To aku­rat niepraw­da, i nie należy dzi­ałać według tej dewizy. Niem­niej, jeśli twój klient czy użytkown­ik zgłasza potrze­bę czy prob­lem, należy przede wszys­tkim zas­tanow­ić się, co on ma na myśli i dopy­tać dokład­nie, czemu właśnie tego potrze­bu­je. Cza­sem może być tak, że zaawan­sowany edy­tor, którego oczeku­je jest po pros­tu edy­torem, jakiego uży­wał w poprzed­nim sys­temie do osiąg­nię­cia bard­zo prostej rzeczy. Cza­sem, może on również nie do koń­ca rozu­mieć, jak pro­dukt dzi­ała i oczeki­wać funkcjon­al­noś­ci nie do koń­ca zgod­nej z jego wiz­ją. Cza­sem, korzys­ta­jąc z jed­nej częś­ci aplikacji, może wskazać pomysł na rozwój zupełnie innej.  Niem­niej, to właśnie od klien­ta może­my dostać prawdzi­wą infor­ma­cję na tem­at jego potrzeb, co powin­no przekładać się bezpośred­nio na nasze plany roz­wo­ju pro­duk­tu. I takie założe­nie, choć niby oczy­wiste i banalne, naprawdę ułatwia planowanie i wyz­naczanie naszych priorytetów.

Skąd u pro­gramist­ki takie prze­myśle­nia? Bo w swo­jej pra­cy współuczest­niczę w pro­ce­sie tworzenia pro­duk­tu. Mam dostęp do infor­ma­cji zwrot­nych od użytkown­i­ka, mogę brać udzi­ał w user tes­tach, a gdy braku­je mi jakiegoś kon­tek­stu w mojej imple­men­tacji, zawsze pytam design­era albo prod­uct man­agera. Gdy przed­staw­iany jest nam plan na dal­sze funkc­je, nie są one “z kos­mo­su”, albo tajem­nic­zo wypeł­ni­anego back­logu, a właśnie z tych potrzeb, prob­lemów i oczeki­wań. Gdy pojaw­ia się bug, sprawdza­my jak bard­zo jest uciążli­wy dla użytkown­i­ka i z takim pri­o­ry­tetem go rozwiązu­je­my. Nie mam więc poczu­cia, że to kole­jny tick­et do zamknię­cia, a raczej, że to realne bolącz­ki, w których mogę użytkown­ikowi pomóc. Pomiędzy klien­tem a mną nie ma sztucznych bari­er twor­zonych przez anal­i­tyków, project man­agerów i dyrek­torów. Te oso­by są oczy­wiś­cie w struk­tu­rach firmy, ale nie przeszkadza­ją, a  poma­ga­ją w układa­niu tej relacji i budowa­niu dobrego zrozumienia.

Grasz dla zespołu, a nie dla siebie

Jeśli naszym głównym celem jest pomoc użytkown­ikowi poprzez nasz pro­dukt, to dość nat­u­ral­nie przy­chodzi coś bard­zo, bard­zo ważnego. Gra zespołowa. Dzi­ałanie na korzyść pro­duk­tu, to też dzi­ałanie na korzyść zespołu. Jakie są z tego zyski?

Mogłam ostat­nio przysłuchać się kilku roz­mowom o relacji senior — junior i powiem szcz­erze byłam moc­no zdzi­wiona tym, co usłysza­łam. A mianowicie oczeki­wa­niu, by junior seniorowi nie przeszkadzał, czekał aż tamten będzie miał wyz­nac­zony dla niego czas, kole­jkował swo­je prob­le­my… W moim obec­nym zes­pole, gdy ktoś ma prob­lem nieza­leżnie od pozy­cji, po pros­tu o nim pisze/mówi i w miarę możli­woś­ci, ale raczej szy­b­ciej niż później zysku­je odpowiedź na swo­je pytanie. Mamy wewnętrzne stack over­flow, czy slack­owe kanały tem­aty­czne, jed­nak to tylko narzędzia, postawa jest znacznie ważniejsza. I w niej, każdy z nas sku­pia się raczej na rozwiąza­niu prob­le­mu, niż na pokaza­niu kto jest mądrze­jszy. A im szy­b­ciej prob­lem zostanie rozwiązany(nie zależnie czy mój czy mojego kole­gi), tym lep­iej dla pro­jek­tu i klien­ta. Podob­nie z code review. Sku­pi­amy się w nim przede wszys­tkim na efek­ty­wnej imple­men­tacji i podzie­le­niu się wiedzą, jeśli jest taka potrze­ba (więcej o dobrym code review przeczy­tasz tutaj!).

Inną rzeczą jest elasty­czność i brak przy­wiąza­nia do kodu. W poprzed­nich fir­ma­ch, zawsze był taki ktoś, kogo kodu bano się ruszać, a przepisy­wanie na nowo pewnych rozwiązań, było niemal zawsze “wyce­ni­ane” na nie warte faty­gi. Nawet w sytu­acji, gdzie jas­no mówiliśmy, że tylko na tym zyskamy. Gdy jed­nak pro­gramiś­ci myślą o pro­duk­cie a nie tech­nolo­giach, to pode­jś­cie do kodu jest również inne. Znacznie łatwiej przy­chodzą zmi­any, nawet te drasty­czne jak usuwanie, czegoś, co pow­stało nie tak dawno. Kod nie jest efek­tem naszej pra­cy, jest nim dzi­ała­ją­cy pro­dukt i takie pode­jś­cie naprawdę dużo zmienia.

Podejmowanie decyzji technologicznych i bycie guru

Skupi­e­nie na pro­duk­cie poma­ga też w zdroworozsąd­kowym pode­jś­ciu do nowych tech­nologii, bib­liotek i refak­toru kodu. Gdy na szy­bko się coś nabała­ganiło, to trze­ba to potem posprzą­tać. Nie ma jed­nak mowy o popraw­ia­n­iu kodu do per­fekcji (której prze­cież nie da się osiągnąć). Ale też w drugą stronę, jest pewien akcep­towal­ny poziom, poniżej którego nie zejdziemy jako zespół. 

Imple­men­towanie najnowszych bib­liotek nie jest celem samym w sobie, niem­niej, szukanie ich, gdy pojaw­ia­ją się prob­le­my (lub gdy przewidu­je­my, że coś może się niedłu­go przy­dać), jest raczej nor­mą. Kto pode­j­mu­je takie tech­niczne decyz­je? Zespół. We współpra­cy z naprawdę doświad­c­zony­mi osoba­mi, które chęt­nie dzielą się wiedzą. Świet­nym jest to, że Ci ludzie abso­lut­nie nie chcą być nieza­stą­pi­ony­mi, szanu­ją swój czas i naprawdę chęt­nie dzielą się swo­ją wiedzą. To układ win-win, bo im więcej wiedzy jest łat­wo dostęp­ne (doku­men­tac­ja, dobre prak­ty­ki, nagra­nia z coty­god­niowego tech talku, czy spec­jalne dużury z zespoła­mi współt­worzą­cy­mi infra­struk­turę), tym szy­b­ciej i bardziej samodziel­nie moż­na poradz­ić sobie z prob­le­ma­mi. Wartość eksperów tech­nicznych to nie tylko to, co sami są w stanie zaim­ple­men­tować, ale (a może przede wszys­tkim), co z ich pomocą mogą zre­al­i­zować inni.

 

Narzędzia a nie cel sam w sobie

Metody­ki pro­jek­towe, frame­wor­ki, bib­liote­ki, to wszys­tko tylko narzędzia, z których korzystamy.One mają dzi­ałać dla nas, a nie odwrot­nie. Z doświad­czenia znam bycie niewol­nikiem “Scru­ma” rozu­mi­anego przez orga­ni­zowanie spotkań, które naprawdę nie za wiele wnosiły. Dochodz­iło cza­sem od kuri­ozum, gdzie ludzie czekali ze swoi­mi prob­le­ma­mi 1.5 tygod­nia, do ret­ro­spek­ty­wy, ale wiecie, było nowocześnie i zwin­nie (w pro­jek­cie, który uży­wał iter­acji, choć wcale ich nie potrze­bował). Podob­nie z tech­nolo­gia­mi, których nad­mierne uwiel­bi­e­nie może wprowadz­ić wielkie lega­cy (no bo architekt zawsze stosował ten frame­work, więc wszyscy musimy), albo po pros­tu zmusić do przepisy­wa­nia kodu tylko dla samego przepisy­wa­nia (bo inne firmy uży­wa­ją tego języ­ka, to i my musimy). 

Mając wiz­ję, że to jed­nak nasz pro­dukt i jego użytkown­ik jest najważniejszy, moż­na ode­przeć takie pokusy i dobier­ać narzędzia tak, by poma­gały osiągnąć cel biz­ne­sowy, nawet jeśli nie da się nimi pochwal­ić przed kolega­mi (cho­ci­aż umówmy się, jeśli biznes się krę­ci to jest się czym pochwalić ;)).

Zaczęłam od roz­wo­ju pro­gramisty i na nim skończę, bo czy­ta­jąc ten wpis możesz zas­tanaw­iać się, no i gdzie ten rozwój?

Gdy przyjmiesz postawę skupi­enia na użytkown­iku i dostar­czenia najlep­szego pro­duk­tu, to on sam przyjdzie. Nie będzie to zna­jo­mość najnowszych bib­liotek, rozez­nanie w definic­jach ele­men­tów Sprintu czy ilość wys­tąpień pub­licznych — to wszys­tko moż­na ‘wyczy­tać’ z książek lub ‘załatwić’ w cza­sie studiów. Będzie to umiejęt­ność wyko­rzys­ta­nia tech­nologii do rozwiązy­wanie konkret­nych prob­lemów, rozu­mienia intere­su klienta/użytkownika oraz możli­wość pomo­cy w pod­ję­ciu przez niego najlep­szej możli­wej decyzji — czyli wszys­tko to, co zwyk­liśmy nazy­wać “doświad­cze­niem”. To wszys­tko będzie twoi­mi narzędzi­a­mi by pomóc użytkown­ikom osiągnąć ich cel. 

Co więcej, takie pode­jś­cie poz­woli Ci też bard­zo łat­wo odpowiedzieć na pytanie: “którą technologię/rozwiązanie wybrać?” - wystar­czy przek­sz­tał­cić je w pytanie: “która będzie lep­sza z punk­tu widzenia użytkownika/klienta?”. I taka postawa pomoże biz­ne­sowi osiągnąć sukces. Wiz­ja samot­nego pro­gramisty w świecie ekranów jak z matrixa już dawno powin­na zniknąć z Two­jej głowy. Pra­ca z dale­ka od biz­ne­su, w izo­lacji, w dłuższej per­spek­ty­wie naprawdę nie poma­ga we wszech­stron­nym roz­wo­ju, a wręcz prze­ci­wnie, może budować totalne oder­wanie od fak­ty­cznych potrzeb i rozwiązy­wa­nia prob­lemów. Dlat­ego: pro­gramis­to, pokochaj pro­dukt i jego użytkowników!