To jest 205. odcinek podcastu Porozmawiajmy o IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy w IT o nazwie Solid.Jobs, który zresztą mam przyjemność współtworzyć, dyskutujemy o narzędziach programisty. Zapraszamy do słuchania i komentowania. 

A teraz życzymy Ci już miłego słuchania. 

Odpalamy! 

 

Cześć, Łukasz! 

 

Cześć, Krzysztof! 

 

Spotykamy się z Łukaszem już po raz kolejny, żeby porozmawiać o narzędziach programistów. Było już o Code Review, było już o pair programmingu, dzisiaj kolejne ciekawe narzędzie, które może być wykorzystane na wiele sposobów, czyli Spike, przez niektórych nazywany Proof of Concept. I co ciekawe, jest to narzędzie, w którym nam, programistom, wolno popełniać błędy, więc będzie, myślę, dzisiaj ciekawa rozmowa.

Myślę, że nie wszyscy mogą wiedzieć, czym to narzędzie jest, dlatego, Łukasz, chciałbym Cię poprosić, żebyś przybliżył trochę, czym jest Spike, skąd w ogóle się ten pomysł wywodzi.

 

Spike, tak jak omawiany w poprzednim odcinku pair programming, jest praktyką, która się wywodzi z XP programming i polega ona na tym, że robimy jakąś funkcję w bardzo prosty sposób, po to, żeby się czegoś nauczyć, dowiedzieć się czegoś nowego, np. zapoznać się z nową technologią, z nową biblioteką, czy też z nowym sprzętem. I tę funkcję robimy w jak najprostszy sposób, pomijamy poza funkcjonalne wymagania, jak np. logowanie, autoryzację. To wszystko pomijamy, stabujemy, mockujemy,  staramy się po prostu poznać ten core funkcjonalności.

Jakie, Krzysztof, jeszcze według Ciebie mogą być inne zastosowania użycia Spike’a?

Spike, tak jak omawiany w poprzednim odcinku pair programming, jest praktyką, która się wywodzi z XP programming i polega ona na tym, że robimy jakąś funkcję w bardzo prosty sposób, po to, żeby się czegoś nauczyć, dowiedzieć się czegoś nowego, np. zapoznać się z nową technologią, z nową biblioteką, czy też z nowym sprzętem. I tę funkcję robimy w jak najprostszy sposób, pomijamy poza funkcjonalne wymagania, jak np. logowanie, autoryzację. To wszystko pomijamy, stabujemy, mockujemy,  staramy się po prostu poznać ten core funkcjonalności.

 

Tak, myślę, że mogę spokojnie wspomnieć o moim koniku, czyli poszerzaniu wiedzy. To może brzmieć trochę tak ogólnie, natomiast w branży IT po prostu musimy się rozwijać, to jest truizm, ale faktycznie tak jest. Możemy to robić oczywiście poza pracą, w domu, w jakichś projektach itd., ale nic nie stoi na przeszkodzie, żeby poszerzać też wiedzę po prostu pracując, wnosząc coś do projektu i taki Spike, taki Proof of Concept może być tutaj doskonałym rozwiązaniem.

Obopólne korzyści widzę tutaj do osiągnięcia i po stronie pracodawcy, nazwijmy to ogólnie, i po stronie programisty. Programista jest w stanie zaznajomić się, tak jak tutaj wspomniałeś, z nową technologią, językiem, biblioteką, frameworkiem, nawet sprzętem, bo to niekoniecznie musi być tylko software’owa rzecz. I tę wiedzę jest później w stanie wykorzystać po to, żeby lepiej wykonywać swoją pracę, żeby ten produkt, nad którym pracuje, był lepszej jakości, nowocześniejszy itd. Więc finalnie jest to inwestycja ze strony pracodawcy, pewnie jeszcze dzisiaj trochę o tym temacie powiemy, natomiast dla programisty jest to możliwość po prostu poszerzania wiedzy.

To jest takie dosyć szerokie poszerzanie wiedzy, to niekoniecznie musi być bardzo punktowe, czyli jakaś wąska biblioteka w danym zastosowaniu. To może być też nauka architektury, to może być też spróbowanie nowego podejścia. Bardzo szeroko możemy do tego podejść, więc zdecydowanie wspomniałbym o poszerzaniu wiedzy jako o takim wykorzystaniu Spike’a.

Ale co może jeszcze na marginesie zaznaczę, nie tylko po to, żeby tę wiedzę zdobywać, tylko jakby cel przyświeca taki, żeby tę nowo zdobytą wiedzę wykorzystać w projekcie, w którym się pracuje, już tak od razu można powiedzieć.

 

Innym fajnym zastosowaniem jest estymowanie. W szczególności dużych pracochłonnych zadań, takich gdzie jest dużo niewiadomych, to w taki bardzo uporządkowany sposób, zorganizowany, bo to jest jakieś zadanie, które możemy wrzucić w planowaniu sprintu i wtedy na kolejny sprint już wiemy coś więcej, możemy już to konkretne zadanie wtedy ładnie wyestymować, a tutaj sobie timeboxujemy po prostu to zadanie estymacji na 2–4 godziny i wtedy to duże zadanie będzie nam łatwiej ocenić, bo inaczej to byłoby wróżenie z fusów.

 

Dokładnie, to może zastanówmy się, porozmawiajmy chwilę o tym, jak taki Spike może przebiegać procesowo, w sensie, na co zwrócić uwagę podczas pracy nad Spikiem, jak to czasowo ogarnąć, jakie są Twoje doświadczenia?

 

Przede wszystkim powinniśmy być przygotowani na to, że nie wszystko chcemy zrobić idealnie i pomińmy w takim przypadku te dodatkowe rzeczy, czy też refaktoryzację w trakcie pracy. Tak jak wspomniałem przed chwilą, ztimeboxujmy to zadanie, czyli dajmy tutaj z góry ustalony nieprzekraczalny czas. Wiadomo, to zawsze wszystko jest płynne, jeśli to potrwa godzinę dłużej, to nic się nie stanie, ale starajmy się bardziej trzymać tego z góry ustalonego czasu i po prostu z takim zamysłem, że jak się nie udało, to trudno, ale wiemy coś więcej i wykorzystajmy wtedy tę wiedzę już przy tym właściwej pracy nad funkcją.

 

Tutaj tak jak wspomniałeś jest to praktyka wywodząca się z Extreme Programming, co może sugerować, że kod powinien być jedynym możliwym efektem Spike’a, ale oczywiście tak nie zawsze musi być. Możemy sobie to narzędzie spokojnie zastosować, żeby osiągnąć też inne efekty, bo tak jak wspomniałeś, bardzo fajnym sposobem podejścia, zwłaszcza do dużych funkcjonalności jest to, żeby np. w pierwszym sprincie wykonać takiego Spike’a, żeby sprawdzić, z czym w ogóle musimy się mierzyć albo jakie możliwe rozwiązania możemy zastosować, a w kolejnych sprintach dopiero na bazie tej zdobytej wiedzy ten produkt realizować.

W związku z tym efektem Spike’a może być ogólnie rozumiany research, albo dokumentacja, która później posłuży osobom faktycznie implementującym dane funkcjonalności do tego, żeby wiedzieć już, na czym stoją.

Efektem Spike’a może być też jakiś już produkt, coś, co jest połączeniem kilku różnych systemów czy kilku różnych repozytorów, kilku różnych jakiś subproduktów wchodzących w skład danego rozwiązania, bo jak gdyby kod jest tylko jednym z możliwych efektów Spike’a, jeśli traktujemy też Spike’a jako takie narzędzie poszerzania wiedzy, to jakaś strona wiki, jakiś rodzaj prezentacji, jakiś rodzaj zsyntezowania tej wiedzy dla pozostałych członków zespołu, to też może być jak najbardziej efekt Spike’a.

 

Możemy sobie to narzędzie spokojnie zastosować, żeby osiągnąć też inne efekty, bo tak jak wspomniałeś, bardzo fajnym sposobem podejścia, zwłaszcza do dużych funkcjonalności jest to, żeby np. w pierwszym sprincie wykonać takiego Spike’a, żeby sprawdzić, z czym w ogóle musimy się mierzyć albo jakie możliwe rozwiązania możemy zastosować, a w kolejnych sprintach dopiero na bazie tej zdobytej wiedzy ten produkt realizować.

Tak, z tym że uważałbym z traktowaniem rozwiązania jako finalnego. Tutaj jest duże ryzyko właśnie, żeby ktoś, na przykład biznes, nie pomyślał, że udało się coś zrobić w te 4 godziny, a to nie jest to, co miało być, nie jest to funkcja, która będzie w stanie przetwarzać tysiąc requestów na sekundę, tylko zostało tutaj dużo rzeczy po prostu zmockowane i zostały użyte jakieś gotowe elementy, których nie jesteśmy w stanie dostosować do tego naszego finalnego produktu.

 

Tak, powiem Ci, że sam uczestniczyłem w takim projekcie, gdzie ten Spike był znacznie większy, ponieważ dotyczył wyboru narzędzia do analityki, i to był taki Spike trwający bodajże dwa sprinty wręcz dwutygodniowe, całkiem duży, ale faktycznie z racji na taki, a nie inny czas zainwestowany w tego Spike’a, biznes robił bardzo dużą presję, żeby efekt tego Spike’a został wykorzystany później jako podstawa do rozwijania finalnego produktu. Tylko dzięki bardzo usilnemu tłumaczeniu ze strony deweloperów udało się tego uniknąć, bo faktycznie to było takie rozwiązanie, które z pewnością prędzej czy później by nas ugryzło, wiadomo gdzie, i z pewnością by się rozsypało.

Myślę, że to też trzeba zaznaczyć, że deweloperzy, programiści powinni edukować produkt i biznes o tym, na jakich podstawach technologicznych to się opiera i że to nie może służyć nam później do zdeployowania na produkcję.

 

Tak, ja też dlatego lubię nazwę Proof of Concept, bo ona też od razu mówi, czym to jest i właśnie od razu sugeruje, że to jest tylko taki proof, nie jest to coś finalnego.

 

Właśnie, powiedziałaś o ryzyku, czy też takiej potencjalnej pułapce, która się może właśnie zrodzić w głowie biznesu, żeby wykorzystać to narzędzie stworzone tak trochę na prędce, na kolanie niekiedy, ale z drugiej strony Spike, Proof of Concept, redukuje też ryzyko; ryzyko potencjalnej niewiedzy, gdy będziemy się mierzyć z finalną implementacją.

 

Tak, pozwala nam odkryć właśnie pułapki, które mogą na nas czekać już przy tej właściwej implementacji.

 

I właśnie, tutaj ja często obserwuję takie Spike’i, albo właściwie można powiedzieć oczekiwania stające się za takimi Spike’ami, że one muszą nas gdzieś do przodu popchnąć w realizacji projektu, że efekt finalny takiego Spike’a musi być po prostu pierwszym takim krokiem w implementacji finalnej funkcjonalności. W związku z tym istnieje taka tendencja do tego, żeby mimo wszystko ten Spike zawsze skończył się sukcesem, a to też jest pewne ryzyko, prawda?

 

Tak, tak. Ja myślę, że w ogóle to jest też jakiś błąd, który możemy popełniać, czyli nie bójmy się tego, żeby ten pomysł odrzucić lub tę technologię. Po wykonaniu Spike’a może będzie konieczne wykonanie w kolejnym sprincie innego Spike’a, innej technologii. Nie przywiązujmy się do tego. Właśnie to jest po to, żeby stwierdzić, czy to jest dobra droga i to jest taki właśnie drogowskaz, który nam powie: tak, idźmy dalej lub nie, stop, wycofajmy się, zróbmy dwa kroki do tyłu, bo nie jest jeszcze za późno. Dlatego to właśnie zrobiliśmy. Spike jest po to, żeby nie wpakować się w taką sytuację, że już będzie za późno, żeby się wycofać. Czasami tak jest, że już trzeba żyć z tą technologią czy z tą biblioteką, którą wybraliśmy, bo zmiana jest trudna.

 

Dokładnie, dodałbym jeszcze, że tutaj też ma zastosowanie takie podejście shift left, tak jak powiedziałeś, im wcześniej coś wyłapiemy, co może być problematyczne, co może być jakimś długiem technologicznym, co może rodzić błędy wydajnościowe albo jakiekolwiek inne, tym lepiej, tym mniejsze koszty związane z eliminacją tego problemu. Tak samo jak testujemy funkcjonalności, a przynajmniej powinniśmy, zanim jeszcze one znajdą się na produkcji, tak samo to podejście związane ze Spike’iem też jest taką formą testowania, czy ta ścieżka, o której myślimy, jest zasadna, czy ona nas po prostu prowadzi w dobrym kierunku, więc nie powinniśmy się bać tutaj schodzenia z tej ścieżki, jeśli to nie jest ta właściwa.

 

Tak. I myślę, że też kolejna ważna rzecz to jest to, żebyśmy na koniec mieli zaplanowaną dyskusję, review tego wszystkiego i też z jakąś osobą może decyzyjną, product ownerem, albo CTO, technicznym jakimś product ownerem, żebyśmy to omówili i zdecydowali, co robić z tym dalej. Tak jak mówię, nie przywiązujmy się, jeśli to jest fajne, starajmy się tego bronić, jeśli widzimy tutaj ryzyka, przedstawmy te ryzyka, jakie tutaj odkryliśmy. Po to to jest, żebyśmy mogli podjąć decyzję, co robić dalej.

Tak. I myślę, że też kolejna ważna rzecz to jest to, żebyśmy na koniec mieli zaplanowaną dyskusję, review tego wszystkiego i też z jakąś osobą może decyzyjną, product ownerem, albo CTO, technicznym jakimś product ownerem, żebyśmy to omówili i zdecydowali, co robić z tym dalej.

 

Właśnie, myślę, że warto też pozostawić jakiś ślad tego naszego dochodzenia, czy tego naszego testowania jakiejś technologii, bo ja spotkałem się raz z tym, że taki Spike był robiony dwa razy, tylko dlatego, że jeden zespół po prostu nie poinformował drugiego, że mierzy się z jakąś biblioteką w tym przypadku, to jest wtedy jawna strata czasu. Jeśli faktycznie ten Spike się udał albo nie udał, w tym sensie, że po prostu chcemy kontynuować z tym co stało przed nami w tym Spike’u, to po prostu gdzieś zostawmy jakiś ślad, albo jeśli zarzuciliśmy tę drogę, to dlaczego, jakie są powody – to może spowodować, że inny zespół nie będzie w przyszłości podejmował znowu tej samej próby.

 

Jasne, a Ty, Krzysztof, jako osoba tak bardziej związana z biznesem, powiedz mi, jak tutaj biznes podchodzi do kwestii Spike’ów?

 

Spotkałem się z różnym podejściem. W przynajmniej kilku projektach było tak, że Spike był faktycznie traktowany jako takie pełnoprawne zadanie. To ten model, o którym powiedziałeś na początku, że w tym przypadku product owner wiedział, że może wykorzystać to narzędzie, po to, żeby później lepiej zdefiniować zadanie dla programistów i świadomie wykorzystywał. Czyli, powiedzmy, w pierwszym sprincie pojawiało się takie zadanie, na jego podstawie podchodziliśmy do właściwej implementacji w kolejnym sprincie.

Ale muszę powiedzieć, że to nie jest taka oczywista i wszędzie występująca świadomość. Jeśli tą osobą najbardziej decydującą jest faktycznie product manager czy product owner, zazwyczaj przychodzi to łatwiej tym osobom, bo chyba widzą gdzieś wartość, mam wrażenie, w tego typu podejściach. Zwłaszcza jeśli to są takie bardzo techniczne zadania, takie core’owe, o których często PM wie, z czym to się je, ale nie do końca zna te wewnętrzne rzeczy, to wtedy wręcz, żeby rozwiać swoją niewiedzę, jest bardziej skłonny do tego, żeby decydować się na Spike’i.

Ale w sytuacji, kiedy zadania dla programistów są tworzone przez osoby bardziej związane z biznesem, to tutaj jak gdyby jest różnie. Spotkałem się kilka razy, o czym mówiłem wcześniej, z tym, że wtedy jest takie rozumienie: potraktujmy to jako pierwszy krok stworzenia właściwej funkcjonalności. Czyli to co powstanie, ten zrąb tego kodu, który powstanie w wyniku Spike’a, weźmy to jako taki input i budujmy na tym. I to niestety w większości przypadków kończy się źle.

Raz miałem taką sytuację, kiedy połowa zespołu programistycznego wręcz odeszło z tej firmy, bo po prostu biznes bardzo mocno nalegał, żeby wykorzystać coś co powstało w wyniku Spike’a, co absolutnie nie pasowało do zasad szeroko przyjętych i stosowanych w firmie.

 

Tak, myślę, że powinna być taka zasada, że zawsze to wyrzucamy i robimy od nowa. Oczywiście wzorujemy się, możemy pewne funkcje sobie tam wziąć z tego kodu, ale starajmy się jednak miejmy takie założenie, że będziemy pisać od nowa.

 

Tak, jest jeszcze takie rozróżnienie, o czym właśnie wspomniałem, na takie Spike’i bardzo programistyczne, takie core’owe, które gdzieś tam mają za zadanie np. rozpoznanie biblioteki czy jakiegoś podejścia architektonicznego vs takie Spike’i, które mają za zadanie rozpoznanie produktu jakiegoś np. eksploracji API, jakiegoś vendora itd. Albo wręcz sprawdzenie czy jakieś narzędzie, z którym potencjalnie możemy się zintegrować, ma sens.

Myślę, że łatwiej jest biznesowi zrozumieć właśnie ten drugi typ, że to jest jakaś praca koncepcyjna, która niekoniecznie musi się skończyć kodem i łatwiej jest zarzucić dalsze prace, jeśli faktycznie efekt takiego Spike’a to jest kawałek dokumentacji, który mówi, że tutaj mamy ryzyka takie i takie, to nas będzie kosztować trochę za dużo, bo taki jest model finansowy itd. Wtedy łatwiej jest to zarzucić, ale z mojego doświadczenia wynika, że jeśli to są takie Spike’i, które się kończą jakimś fragmentem kodu, to jakoś trudno przychodzi, żeby to wyrzucić do kosza.

Wspomniałeś na początku, że powinniśmy stworzyć takie funkcjonujące w minimalnej wersji rozwiązania, że nie musimy się przejmować tymi niefunkcjonalnymi zagadnieniami. Wspomniałeś o logowaniu, dajmy na to. W związku z tym pojawia się takie pytanie, czy Spike to jest taka piaskownica, gdzie wszystko jest dozwolone, gdzie nie musimy przestrzegać przyjętych standardów, zasad, gdzie jest samowolka i każdy robi to co chce? Jakie jest twoje podejście?

 

Myślę, że nie do końca. Na pewno korzystajmy z tych dobrych praktyk, dobrych narzędzi, które znamy. Np. taki spike może być wykonany w formie pair programmingu przez dwie osoby, co też ma swoje zalety, bo ta wiedza od razu jest u dwóch osób. Myślę też, że nie da się ukryć, że część tego kodu będziemy chcieli wykorzystać gdzieś dalej, więc też starajmy się robić takie elementy, które będą reużywalne. 

Od pisania testów też nikogo tutaj nie będę odciągał, bo nie wyobrażam sobie chyba, żeby pisać zupełnie bez testów. Natomiast mimo wszystko starajmy się zachować jak największe velocity, tę szybkość developmentu i np. korzystajmy gdzieś z gotowych elementów, gotowych rozwiązań. Mockujmy, część rzeczy może być np. nieklikalna. Zależy oczywiście, co tutaj będziemy sprawdzać w tym Spike’u, ale jeśli to bardziej chodzi nam o jakieś techniczne sprawy, to wygląd tego rozwiązania jest drugorzędny. Miejmy po prostu ten cel zawsze przed sobą i starajmy się do niego dążyć.

 

W tym modelu, o którym ja mówiłem, że w pierwszym sprincie robimy sobie Spike’a, później w którymś kolejnym podejmujemy rękawice, tworząc właściwą funkcjonalność albo nie. Najczęściej jest tak, że osoba, która podejmuje się robienia tego Spike’a, później jest osobą implementującą samodzielnie albo z innymi właściwą funkcjonalność.

Jestem ciekawy co o tym myślisz, bo ja mam mieszane uczucia. Z jednej strony rozumiem, że może to mieć sens, ponieważ ten zainwestowany czas, czy ta wiedza zdobyta przez tę osobę, już jest skumulowana, można ją po prostu wykorzystać. Z drugiej strony, jeśli to jest ta sama osoba, to wtedy potencjalnie występuje ryzyko, że ta osoba nie zauważy rzeczy, które pominęła w pierwszym podejściu związanym z Proof of Concept.

 

Okej, jest takie ryzyko, ale ja jednak będę bronił chyba tego podejścia, że to jest ta sama osoba lub te same osoby, które tutaj pracują nad tym rozwiązaniem. Wydaje mi się, że takim typowym antypaternem w firmie może być coś takiego, że te Spike’y robi np. CTO, a potem implementują już ci zwykli szarzy programiści jak my. Wydaje mi się, że to jest antypatern i tak to nie powinno wyglądać, bo właśnie wtedy ten CTO jest też mniej dostępny, nie jest takim zapewne członkiem zespołu, który na bieżąco tutaj ze wszystkimi wchodzi w interakcje, tylko jest bardziej osobą, która musi dzielić swój czas między np. różne zespoły. Tak że myślę, że na pewno to powinna być osoba z zespołu, i jestem dość mocno przekonany, że jest dobrze, by było, gdyby jednak to była ta sama osoba, która nad tym pracowała.

Oczywiście nie jest to jakaś żelazna zasada i pewnie nic się nie stanie, jeśli tak nie będzie, ale no wystrzegajmy się też takiego właśnie antypaternu, że te Spike’y są robione gdzieś tam w innym dziale, Research and Development, a my tutaj dostajemy z góry po prostu: stwierdziliśmy, że biblioteka A, a nie B, no i uwierzcie nam na słowo. To jest mało w duchu agile.

Wydaje mi się, że takim typowym antypaternem w firmie może być coś takiego, że te Spike’y robi np. CTO, a potem implementują już ci zwykli szarzy programiści jak my. 

 

Tak, tak, to trochę pachnie waterfallem. Jasne, wiesz, Tomek, zanim Ci przekażę mikrofon i pozwolę podsumować nasze spotkanie, bo już całkiem sporo myśli zebraliśmy, to może jeszcze zachęcam słuchaczy do tego, żeby namawiali, albo żeby gdzieś tam spróbowali sprzedać tego typu praktykę właśnie PM-om, którzy nie stosują tego typu rozwiązań, bo to może służyć, tak jak tutaj powiedzieliśmy, zarówno im, jak i nam. Być może PM nie wierzy, że takie podejście istnieje, warto o tym wspomnieć. Ci doświadczeni PM-i, z którymi ja miałem do czynienia, no zazwyczaj widzą w tym sporą wartość i doceniają, więc myślę, że sprawdzi się to praktycznie w każdym zespole.

Łukasz, może spróbujesz jakoś podsumować naszą rozmowę?

 

Jasne. Proof of Concept, nazwany też Spike’iem, jest narzędziem, które pomaga nam w uporządkowany, taki procesowy sposób poszerzyć wiedzę, ponieważ możemy np. taki ticket dodać do sprintu, ztimeboxować go. Pomaga estymować duże zadania, nieznane jakieś obszary, pomaga nam poznać nowe technologie, czy też np. zapoznać się z nowym sprzętem. I oczywiście piszmy takie Spike’y z myślą o ich wyrzuceniu, nie bójmy się tego, żeby wyrzucić to, co zrobiliśmy, i zrobić coś od nowa, też nie bójmy się tego, żeby zrezygnować z danego podejścia, bo to jest właśnie idea Spike’a, żebyśmy mogli podjąć decyzję i może zrobić shift i wybrać coś innego. Tego się nie bójmy, nie bójmy się tego, że coś stracimy, o to w tym chodzi.

 

Code Review, pair programming, teraz Spike, już całkiem sporo narzędzi w naszym toolboxie. O czym będzie, Łukasz, w następnym odcinku?

 

Myślę, że w następnym odcinku opowiemy o tym, co my, programiści, umiemy robić najlepiej, czyli o estymacji. Oczywiście żartujemy tutaj, ale tak, pomówimy o estymacji, pokażemy, jakie narzędzia można wykorzystać do estymowania i też pokażemy, że może nie zawsze trzeba estymować.

 

Ciekawie. Czyli będzie o szklanej kuli i tarocie, tymczasem myślę, że na dzisiaj będziemy się już powoli żegnać. Wielkie dzięki, Łukasz. I oczywiście zapraszamy do słuchania tych wcześniejszych odcinków, z wyprzedzeniem już tych, które się pojawią w najbliższym czasie. Zapraszamy do komentowania, podsyłania swoich propozycji, a osoby, które są zainteresowane zmianą pracy, być może rozglądają się za czymś nowym, zapraszamy na Solid.Jobs, gdzie zawsze możecie znaleźć ciekawe oferty z widełkami wynagrodzeń.

 

Zapraszamy także team leadów i osób, które szukają pracowników do dodania ogłoszenia na Solid.Jobs.

 

Dzięki wielkie, Łukasz! Do usłyszenia następnym razem.

 

Dzięki, cześć.