Dalsze odkrywanie trybu pracy w firmie produktowej #it


Przez ostatni rok pracowałem z zespołem, gdzie dwie główne devki były, w mojej ocenie, dość nielotne.

Po każdym refinemencie jak już wiedziałem jakie są wymagania zabierałem się za design. Moje pliki z figmy zawsze zawierają mockupy poukładane tak że odzwierciedlają ścieżkę użytkownika i stany komponentów (jakieś errory, empty, active, hover itp.) tak żeby frontend dev miał wszystko na tacy. Czasem nawet robiłem klikalny prototyp i nagrywałem to żeby dev mógł łatwo obejrzeć jak wygląda happy path. Dodatkowo każda ścieżka posiada tytuł z linkiem do taska w jirze w którzym są kryteria akceptacji (np. dodawanie do koszyka JP-2137) tak że jak się czegoś nie rozumie z mockupów to można łatwo znaleźć dodatkowe informacje. Na każdym design handoverze tłumaczę dlaczego tak coś zostało zaprojektowane, w oparciu o co, i robię często dwie wersje: minimum z której nie da się już nic wywalić żeby nie zepsuć ficzerka, oraz pożądaną.


I jak przychodziło do implementacji, to i tak te devki potrafiły miesiąc po klepnięciu wszystkiego zadawać pytania "a czemu tak? a mi się podoba inaczej" albo "a jak to działa?", "a po co ten przycisk?". Mając dokładne mockupy, kryteria akceptacji i spotkanie z handoverem.


Przełknąłem to, nauczyłem się z tym żyć.


Ale przyszedłem do drugiego zespołu i jest to samo. Porozmawiałem w zespole o tym, bo pomyślałem że może to ja coś za dużo zakręciłem i się w tym gubią. Pogadałem ze znajomymi devami z innych firm żeby dali mi feedback czy takie coś pozwalałoby im mieć wiedzę co zrobić i jak i wychodziło że bez problemu.


I wtedy eureka, dotarło do mnie.


Otóż wczoraj przekazałem kolejne mockupy i dosłownie minutę później pisze do mnie PO projektu:

-Siema Maciek, bo Tomek jest zblokowany z taskiem, nie może rozkminić o co chodzi w tych mockupach

-Tak jak mówiłem na spotkaniu chodzi o blablabla, co jest dodatkowo opisane w tasku blablabla

i zatrzymałem się bo raz że wkurzyłem się że znów muszę to powtarzać, a dwa dlaczego ten dev sam do mnie nie napisze


I sobie pomyślałem, że jakby ten dev od razu wziął się do pracy, to wyszłoby że albo

a) zrobiłby to szybko i miał czas na dodatkową wrzutkę

b) jakby chciał to porobić na chillu to wyszłoby że robi to dłużej niż przewidywano i musiałby się tłumaczyć czemu


tak źle i tak niedobrze.


więc co robią devi?


W d⁎⁎ie mają te taski, mockupy, handovery itp. Oni już z góry wiedzą, że jak przyjdzie do implementacji to napiszą na priv (no bo wiadomo że nie na kanale zespołu) do PO czy innego BA że brakuje im danych do rozpoczęcia pracy, wrzucają taska na "blocked" i mają labę, bo wtedy druga osoba musi te informacje zdobyć. Zanim ten PO czy BA ogarnie o co chodzi i napisze do mnie, zanim ja mu odpiszę, zanim on upewni się że faktycznie wszystko jest i zanim odpisze devowi mija jakieś pół dnia, a może nawet i kilka dni jak BA uzna że może lepiej zrobić spotkanko. W tym czasie można mówić "no ja jestem zblokowany z tym taskiem" i mieć wywalone.


I podstawą tu jest pisanie na priv, nie bezpośrednio do ludzi którzy mogą ci pomóc, tylko znaleźć sobie takich który wielbią się w byciu potrzebnymi.


Serio, przejście z software house do firmy produktowej to nadal jest dla mnie odkrywanie nowych poziomów opierdalactwa i spychologii.


#pracbaza #pracait #korposwiat #design

Komentarze (7)

koszotorobur

@Maciek - jak wszystko udokumentowane to jak ktoś do Ciebie pisze to wysyłasz linki do dokumentacji i mówisz, że odpowiesz chętnie, ale tylko na KONKRETNE pytania.

Trzeba też się nauczyć nie odpisywać największym męczydupom i nie akceptować spotkań, które tracą Twój czas.

Z drugiej strony też polecamy trochę zluzować bo żyłka pierdząca Ci pęknie i tylko problemów ze zdrowiem się nabawisz.

lipa13

@Maciek Miałem ostatnio podobną rozkminę na temat współpracy z Hindusami. Wszystko podane na tacy a oni i tak dopytują, organizują bezsensowne spotkania, rozpisują się na czatach. Potem i tak połowa rzeczy jest źle zrobiona i mijają kolejne dni a nawet tygodnie na poprawki, testy, spotkania. I tak w sprincie nasz zespół z Polski dostarcza dwa-trzy razy więcej niż koledzy z Indii.


I tu pojawia się pytanie czy dostajemy jakieś premie za bardziej wydajną pracę? A skąd - jedyna premia to task na pomoc hindusom bo znowu nie dowieźli. Czyli w nagrodę za więcej pracy dostajemy więcej pracy a oni pomoc od innych zespołów i więcej wolnego czasu. I kto tutaj jest frajerem? xD

d.vil

@lipa13 sama prawda, robić trzeba tyle, ile wymagane jest minimum, reszta to frajerstwo. Sporo młodych ambitnych ludzi wchodzi do świata IT i chcą zaczynać od rewolucji. Praca 12h + doszkalanie? No pewnie! Przecież kochają poznawać nowe technologie i pokażą tym starym dziadom, jacy są zajebiści. Chwila moment mija 10 lat, wypalenie zawodowe, brak życia towarzyskiego, rodziny, depresja. No tak, warto było, przynajmniej prezes ma więcej czasu na kolejne wakacje i nowe Porsche.

Maciek

@d.vil @lipa13 tylko że ja się sam nie przemęczam w pracy, czasem nawet się boję że ktoś pomyśli że się opieprzam. Robię tyle ile się wymaga w jakimś racjonalnym czasie, a i tak wychodzi na to że jakbym zaczynał pracę od środy to nic by się nie stało, bo większość devów nie pracuje praktycznie wcale (ale kalendarze zajebane spotkaniami XD)@lipa13

d.vil

@Maciek no i legancko, masz czas na opierdalanie się na hejto i socjalizowanie w pracy, przestań marudzić i korzystaj z życia

rith

@Maciek miałem podobne odczucie jak zmieniłem stronę. W SH potrafiliśmy zrobić coś w 2 tygodnie a ta sama rzecz tutaj zajmuje 2-3 miesiące. I tak wszystko powoli się kręci. Kasa wypada, nikt nie ciśnie to tak powoli robimy.

d.vil

@Maciek choopie, luzuj majty, nie ma się czym przejmować oraz za bardzo starać, jeżeli to nie praca nad urządzeniami medycznymi czy innymi technologiami kosmicznymi. Ile takie projekty żyją? Jak często ewoluują w inną stronę i Twoja praca po 4 -5 latach jest już nieobecna? Jest projekt, trzeba zrobić, na końcu ma działać. Ty masz mieć z pracy $ na uciechy a w 4 literach uśmiech bombelka prezesa z dodatkowej premii, którą usilnie chcesz dla niego wypracować.

Zaloguj się aby komentować