W R&D liczą się chęci do pracy w zmiennym środowisku, gdzie każdego dnia robisz coś innego. Devdebata
W R&D liczą się chęci do pracy w zmiennym środowisku, gdzie może się okazać, że jednego dnia klepiesz CSS-y, a następnego pracujesz nad dostosowaniem algorytmu grafowego pod zapotrzebowania projektu. Ale to się opłaca — tak twierdzą Tomasz Świstak i Jakub Kubacki z Synergy Codes, na co dzień pracujący w zespole R&D w Synergy Codes.
Spis treści
W jakim zespole pracujecie? Na czym polega jego nietypowość?
Tomasz: Nasz zespół, znany wewnętrznie jako R&D, co chyba najważniejsze, jest przypisany do wielu klientów i wielu projektów. Nasza praca polega najczęściej na opiekowaniu potrzeb nowych klientów, którzy jeszcze nie zdecydowali się na stałą współpracę.
Zwykle naszymi produktami są prototypy, wstępne wersje produktów lub małe projekty. Z racji specjalizacji firmy, są to przede wszystkim projekty webowe. Chociaż warto też dodać, że nasz zespół opiekuje się też dłuższymi projektami, gdzie klienci potrzebują na tyle mało zasobów, że nie opłaca odpalać się dedykowanego zespołu.
Ktoś, kto będzie czytał ten opis, mógłby skojarzyć sobie naszą pracę z tytułem filmu „Wszystko wszędzie naraz”, ale wbrew pozorom, nasza praca jest dość składna i bardzo ważna z punktu widzenia firmy, szczególnie dla działu sprzedaży, z którym bezpośrednio współpracujemy.
Jakub: Synergy Codes jest software house’em. Pracujemy tu głównie nad dedykowanym oprogramowaniem dla naszych klientów. Zazwyczaj jeden zespół pracuje nad jednym projektem, dla jednego klienta, nawet przez kilka lat. W R&D wygląda to trochę inaczej.
Czasami ktoś przychodzi, mając jedynie pomysł na produkt oraz szukając finansowania. Wtedy wiele pracy leży po stronie zespołu design, który pomaga klientowi opracować koncept produktu. Najważniejsze funkcjonalności są potem przez nas implementowane, tworząc POC/MVP. Mając w ręku klikalny, działający produkt, naszym klientom zdecydowanie prościej pozyskać inwestorów i rozpocząć długofalowy projekt.
Ale nie wszystkie MVP, które robimy, walczą o finansowanie. Zdarza się, że przychodzą do nas klienci, żeby wypróbować jakieś rozwiązanie. Ponieważ jako firma skupiamy się na wizualizacji danych, w szczególności diagramów, to z tym zagadnieniem najczęściej zwracają się do nas klienci. Jakiś czas temu mieliśmy klienta, któremu mieliśmy udowodnić, że napiszemy diagram prezentujący kilkaset czujników. Udało się to całkiem niedawno, firma podpisała z nim kilkuletni kontrakt na dalszy rozwój tego projektu.
W związku z naszym ukierunkowaniem na diagramy, zdarzają się nam też projekty konsultingowe, w których musimy pomóc klientowi doprowadzić jego diagram do działania.
Bywa też tak, że klientem jest firma 🙂 Kiedy pojawiają się potrzeby rozpoznania nowych technologii czy rozwoju projektów wewnętrznych, nasz zespół jest naturalnym miejscem, w którym można się tym zająć.
Obaj macie doświadczenie w pracy w zespołach klienckich. Czym to się różni od pracy w zespołach R&D?
Jakub: Różnic jest kilka, ale największy wpływ mają chyba zakres i czas trwania projektu. W długoterminowych projektach przez dłuższy czas pracujesz w jednej technologii nad jednym zagadnieniem biznesowym. Zasadniczo, jeżeli w marcu pisałeś w Angularze system dla fabryki lodowych rożków, to w kwietniu też to będziesz robić. W R&D możliwe, że kolejny miesiąc przyniesie nie tylko nowego klienta, nowy biznes i branżowe słownictwo, ale także nową technologię.
Ogólny zakres projektu i sposób dostarczania wpływają także na sposób wytwarzania oprogramowania. W długoterminowych projektach rządzi Scrum, a zakres sprintu jest przeważnie sztywny. W naszym przypadku dostosowujemy proces do wymagań biznesowych. Czasami można powiedzieć, że pracujemy w Scrumie, czasami w Scrumbanie, a czasami w Waterfallu – wszystko jest możliwe.
Zapomniałem chyba o najważniejszym. W zespołach klienckich przeważnie cały zespół pracuje nad jednym projektem. W R&D łamiemy ten schemat i pracujemy w kilkuosobowych grupach. Jest zatem tak, że jako zespół pracujemy nad kilkoma projektami jednocześnie.
Tomasz: Myślę, że główną różnicą z mojej perspektywy jest przede wszystkim różnorodność. Pracując dla jednego klienta, znasz dobrze produkt, znasz tajniki kodu i wiesz, czego druga strona oczekuje. Tutaj tego nie ma, ale w zamian za to mamy kontakt z nowymi technologiami, poznajemy różne branże i ich zapotrzebowania.
Ogólnie mówiąc, nie da się tutaj nudzić, bo nawet jak akurat przypadnie Ci, że nie pracujesz dla żadnego klienta, to i tak jest sporo innych rzeczy do roboty. Tylko dodam, że trzeba mieć do tego wszystkiego bardzo otwartą głowę. W naszym zespole nie utrzyma się nikt, kto jest np. fanbojem Reacta i nawet nie chce myśleć o ruszeniu czegoś innego. U nas jako Reactowiec możesz trafić do projektu z Vue czy Angularem.
Wiadomo, są preferencje i się ich trzymamy, ale czasem wiedza, którą ktoś posiada spoza konkretnego frameworka może być z punktu widzenia projektu ważniejsza.
Skoro technologie się zmieniają/mieszają, w jaki sposób dążycie do ujednolicenia wiedzy w zespole?
Tomasz: Wymiana wiedzy odbywa się na trzy sposoby: przez spotkania, komunikację pisaną oraz wspólny kod. W kwestii spotkań mamy daily, gdzie na bieżąco wymieniamy się informacjami, co dzieje się w projektach, a także comiesięczne spotkanie techniczne, gdzie omawiamy sobie projekty, a także co ciekawego technicznie mieliśmy okazję tam zrobić. Pisemnie to oczywiście stała komunikacja na Slacku, a także różne dokumenty na Confluence.
Natomiast wspólny kod to coś, co my wewnętrznie nazywamy „biblioteką komponentów”, chociaż nie jest to coś jak Material czy Ant. Jest to bardziej taka forma, gdzie mamy wiele mini-appek, które przedstawiają różne ciekawe, zaawansowane funkcje, które mieliśmy okazję tworzyć. Warto tutaj dodać, że o ile Angular czy React się mieszają, to jednak takim core naszego zespołu, który nas scala, jest biblioteka GoJS, której Synergy Codes jest oficjalnym konsultantem i to w naszym zespole skupia się główna wiedza na jej temat.
Jakub: W idealnym świecie każdy członek zespołu wiedziałby wszystko o wszystkich funkcjonalnościach, które zostały wytworzone przez wszystkich członków. Jest to jednak przypadek idealny, niemożliwy do spełnienia. Mimo wszystko wiedza o tym, co udało się nam wytworzyć, jakie problemy udało nam się rozwiązać, jest bardzo ważna. Korzystając ze zbiorowej wiedzy, jesteśmy w stanie sprawniej rozwiązywać problemy i szybciej dowozić funkcjonalności.
To tyle, jeżeli chodzi o teorię 🙂 W praktyce chcielibyśmy, aby każdy członek zespołu wiedział mniej więcej, jakie projekty były przez nas realizowane i o co w nich chodziło. Istotne są tutaj wspólne daily i regularne spotkania techniczne. Te drugie stanowią przestrzeń do prezentacji poszczególnych projektów oraz omawiania niektórych, ciekawszych implementacji.
To podejście ma jednak taką wadę, że wymaga udziału w spotkaniach – każdemu się zdarza zapomnieć kliknąć przycisk do nagrywania, a odtwarzanie nagrań spotkań nie zawsze jest efektywnym sposobem pozyskiwania wiedzy. Dlatego, oprócz spotkań technicznych, pracujemy nad standaryzacją dokumentacji projektów. Tworzymy też bibliotekę gotowych rozwiązań, dzięki czemu jesteśmy w stanie szybciej dostarczać wartość dla klientów.
Ale najważniejsza chyba jest atmosfera w zespole. Określenie „młody i dynamiczny zespół” urósł już do rangi mema, ale coś w nim jest. Oczywiście, zespół nie musi być ani „młody” ani „dynamiczny”, ale powinien stanowić wsparcie dla swoich członków. Atmosfera czegoś w rodzaju bezpieczeństwa psychologicznego ułatwia ludziom otwieranie się, proszenie o pomoc i zderzanie pomysłów.
Jak już jesteśmy przy atmosferze, czy w związku z częstymi zmianami dochodzi czasem do konfliktów w zespole?
Tomasz: Niestety, zawsze się tak może zdarzyć. Zawsze staramy się rozpoznawać projekty i klientów na tyle, żeby nawet jak ktoś np. nie zna dobrze Angulara, mógł się odnaleźć w projekcie, bo mógłby pracować tylko nad GoJS. Jednak klienci są różni, zapotrzebowania są różne i nagle może się okazać, że ktoś nie do końca dobrze się czuje tam, gdzie jest.
Przez lata pracy naszego zespołu nabyliśmy już różne doświadczenia, w tym te negatywne, ale zawsze w takich przypadkach staramy się wyciągnąć z tego wnioski, aby już ich nie powtórzyć. Taką lekcją było dla nas to, aby nie delegować tylko jednej osoby na projekt, ale zawsze starać się znaleźć przestrzeń dla co najmniej dwóch, nawet jeśli nie mieliby pracować dla klienta na pełen etat.
Tutaj też mogę dodać taką bardziej na luzie historię: jako zespół startowaliśmy kiedyś projekt wewnętrzny i było nas tam po równo Reactowców i Angularowców. Co więc zrobiliśmy, żeby uniknąć konfliktu? Wystartowaliśmy projekt we Vue, żeby każdy mógł po równo narzekać.
Skoro jest taka zmienność, mogą zdarzyć się sytuacje bez projektu?
Tomasz: Oczywiście, zdarzają się czasy przestoju, kiedy nie ma pracy dla klienta z zewnątrz. Wtedy jednak mamy wewnętrznego klienta, czyli Synergy Codes. Jak mówiłem wcześniej, u nas nie da się nudzić. Praca dla klientów jest najważniejsza, ale gdy tej nie ma, mamy sporo zadań, jak chociażby utrzymywanie projektów wewnętrznych, czy też większy udział w gildiach, które mają na celu przede wszystkim rozwój kompetencji firmy. Nie jest to czas stracony, bo dzięki temu Synergy Codes, które skupiało się przede wszystkim na GoJS, weszło w inne, rozwojowe obszary, w których pozyskuje klientów. I to nie tylko z wizualizacji danych, co więcej, nie tylko z frontend developmentu.
Jakub: Jasne. Zdarza się, że cały zespół jest zawalony pracą. Ale czasami ludzie mają wolne przebiegi. Nazywamy to „ławeczką” i wykorzystujemy ten czas głównie do celów wewnętrznych. Przeznaczamy ten czas głównie na rozpoznanie nowych technologii i rozwiązań, ale także na porządkowanie tego, co już wypracowaliśmy.
Skoro nazywacie się zespołem R&D, to gdzie macie to “R”? Czy „ławeczka” to research?
Tomasz: Research u nas odbywa się na kilka dróg. Oczywiście, „ławeczka” to jeden z nich – jak wspomniałem wcześniej, mamy rozwojowe gildie, ale też zadania wewnętrzne polegające na rozpoznaniu technologii. Jednak research też jest na potrzeby projektów klienckich.
Żeby dobrze wytłumaczyć: projekty frontendowe u nas to nie jest takie typowe „zróbcie formularz”, „zróbcie tabelkę”, „zróbcie funnel”. U nas frontend to przede wszystkim wizualizacja danych. A przy jej okazji wchodzi ciekawa algorytmika. Na przykład, wchodzi do nas projekt gdzie mamy zwizualizować dane z grafowej bazy danych i klient mówi, że może chcieć na raz wyświetlić i automatycznie wypozycjonować nawet 50 tysięcy encji. Wówczas, jeśli jeszcze czegoś takiego nie robiliśmy, to ktoś musi zrobić research, jakie algorytmy dadzą tutaj radę zrobić to szybko, a także jak zmusić przeglądarkę do szybkiego obliczenia tego.
Czy ludzi pracujących w grupach nad różnymi projektami można nazwać zespołem?
Jakub: Tak. Chociaż, czasami różnie bywa z naszym „poczuciem zespołowości”. Mimo tego, że na co dzień pracujemy nad różnymi projektami, we wszystkich realizujemy praktycznie ten sam cel, jakim jest wsparcie biznesu naszych klientów.
Nie zapominajmy też, że projekty są dość krótkie. W związku z tym grupy projektowe się mieszają i przeważnie każdy ma możliwość pracy z kimś innym.
Oprócz tego jesteśmy też dość dobrze zintegrowani. Przynajmniej raz w miesiącu staramy się spotkać w biurze pomimo tego, że nasz najdalszy kolega mieszka w Szczecinie. Prowadzimy wspólne daily i mniej więcej wiemy, co dzieje się w każdym z projektów.
Rozpoczynacie nowe projekty – co nowego się pojawia?
Tomasz: Patrząc z punktu widzenia organizacji i zespołu, to pojawia się możliwość używania nowych albo po prostu innych podejść, bibliotek czy frameworków. Jako R&D wprowadziliśmy do firmy programowanie funkcyjne, backendy NodeJS-owe, z początku Express, a później NestJS; na frontendzie tutaj pierwszy raz mieliśmy Vue, Next.js, a także zaczęliśmy rozpoznawać nowości takie jak Solid.
Też, jak wspomniałem, specjalizujemy się w wizualizacjach z użyciem GoJS, ale stale jesteśmy otwarci na alternatywy, np. ostatnio część naszego zespołu ostro działa z React Flow. Też w ramach R&D wypracowaliśmy, jak robić współpracę w czasie rzeczywistym na diagramie w stylu Miro.
W kontekście nowości przeszliśmy już przez kilka różnych podejść i obecnie, dzięki nowo dostępnym rozwiązaniom, udało nam się zamknąć całą wiedzę w ramach bardzo małego kodu na frontendzie i stosunkowo prostego backendu. Do tego myślę, że też w kontekście nowości możemy obserwować na swój sposób, co nowego jest na rynku technologicznym i z czym do nas przychodzą startupy. Na przykład, jak był boom blockchainowy rok temu, mieliśmy do czynienia z projektem ze świata krypto.
Jakub: Patrząc historycznie, oprócz zmian wersji bibliotek i frameworków, najbardziej widoczną rzeczą jest powrót do technologii SSR. Jest to podejście, które kiedyś dominowało na rynku i zostało wyparte przez SPA. Dzisiaj ponownie zyskuje na popularności.
Pojawiają się także nowe biblioteki i frameworki tworzone w tym kierunku, przykładowo Next.js.
Czy praca w zespole R&D jest dla każdego?
Tomasz: Absolutnie nie. Jak ludzie lubią w ofertach pracy śmiać się z „młodych, dynamicznych zespołów”, tak u nas ta dynamika faktycznie jest i to duża. Musimy nieustannie się uczyć nowych rzeczy, być otwarci na różnorodność świata JS-owego (i nie tylko!), a także umieć nie przywiązywać się do projektów. Prędzej odnajdzie się tutaj pasjonat lub ktoś, kto ma konkretny cel rozwojowy, niż ktoś, kto przychodzi do pracy odbębnić 8 godzin i tyle. Nie chcę mówić, że pracujemy dłużej, bo tak nie jest – dbamy o work-life balance, ale chodzi mi bardziej o podejście do pracy. Raczej nie odnajdzie się tu ktoś, kto chciałby codziennie robić to samo, nie czując żadnej satysfakcji z wykonywanej pracy.
Zaś w kwestii doświadczenia, nasz zespół to pełen przekrój seniority: pracują u nas juniorzy, midzi i seniorzy. Liczą się chęci do pracy w zmiennym środowisku, gdzie może się okazać, że jednego dnia klepiesz CSS-y, a następnego pracujesz nad dostosowaniem algorytmu grafowego pod zapotrzebowania projektu. Ale to się opłaca. Ludzie z naszego zespołu, nawet jeśli zaczynali dajmy na to jako frontend developerzy, zaczęli się specjalizować w innych kierunkach: backend development, machine learning, devops, architektura, a to tylko kilka przykładów.
Jakub: Sposób, w jaki pracujemy, jest specyficzny. Jeżeli ktoś lubi stabilne projekty, taka praca może go szybko zmęczyć. Osobiście mam dosyć chaotyczny styl pracy i chyba lepiej odnajduję się w zespole R&D.
Tomasz Świstak. Senior JavaScript Developer i Software Architect w Synergy Codes w zespole R&D. Podstawą jego pracy są React i NestJS, ale nie ogranicza się do nich, jako jedynych dobrych podejść. Interesuje się też architekturą oprogramowania, algorytmiką, machine learningiem — generalnie wszystkim, co wykracza poza typowe kompetencje JS developera, a co nie raz wymaga dużo researchu. Implementacja skomplikowanych funkcji, szukanie nietypowych podejść i stosowanie w praktyce algorytmów opisanych w pracach naukowych — to jego ulubione zajęcia w pracy. Lubi także dzielić się wiedzą, prowadząc od kilku lat bloga świstak.codes, gdzie łączy książkową wiedzę ze swoim doświadczeniem.
Jakub Kubacki. Swoją przygodę z programowaniem rozpoczął na studiach, od wstępu do biologii obliczeniowej w Matlabie. Ciąg różnych wydarzeń i zbiegów okoliczności doprowadził do tego, że web development stał się jego pasją, którą rozwija i pielęgnuje każdego dnia.
Podobne artykuły
Budowanie R&D od podstaw do jednego z największych ośrodków technicznych w grupie ASSA ABLOY. Wywiad z Jackiem Janiszewskim
Każdy jest odpowiedzialny za jeden problem analityczny. Jak wygląda praca w bioinformatycznym zespole R&D?
Jak technologie i projekty BlueSoft kreują przyszłość? O najnowszych trendach w IT i codziennej pracy w dziale R&D
