EB

700 osób
zaangażowanych
w projekt firmy?
Da się!

SCRUM
Jak go zepsuć
i znienawidzić

AGILE
Narzędzie do
budowania
marki

Ogród
Agile
Ty też masz w sobie
pierwiastek Agile
Od dziecka chorowałam na weryfikowanie prawd moralnych po swojemu.
Poddawałam głębokiej analizie zasady o życiu przekazywane przez rodziców
i nauczycieli. W liceum uwielbiałam chodzić na wagary. Tę formę spędzania
czasu traktowałam jako zajęcia praktyczne z dziedziny badawczo-rozwojowej :).

Już wtedy nosiłam w sobie mikro pierwiastek Agile, o którym wówczas nie
miałam pojęcia. Dziś, stojąc tu przed Tobą, trzymając bulldoga francuskiego,
niczym kochanka księcia Ludwika Sforzy, z obrazu Leonarda DaVinci Dama
z gronostajem, oddaję w Twoje ręce 47 stron materiału, który potwierdza,
że: a) żyjemy w czasach Agile, b) każdy z nas ma w sobie pierwiastek Agile,
c) nie ma jednej metody, która sprawdzi się zawsze i wszędzie. Nadzieją jest
zwinność i otwartość na zmiany.

Poznaj sztukę agile w praktyce w 3. numerze Think IT Magazyn HR.

To jest strasznie świetny numer!

Zobaczysz, że Agile jest wszędzie. Niezależnie od perspektywy: developer

IT, specjalista HR, manager employer brandingu, rekruter, ogrodnik czy Pan
Mariusz planujący remont mieszkania. Ty też masz w sobie pierwiastek Agile.

Barbara Pasek napisała książkę Zrób z życia dzieło sztuki. Mam propozycję
dla Ciebie. Zrób z życia dzieło sztuki, maluj życie Agile, Scrum. Testuj zwinność
i otwartość, a przede wszystkim czytaj Think IT Magazyn HR :)

Iwona Tur
CEO Bulldogjob
iwona.tur@bulldogjob.pl

2
 SPIS TREŚCI

TEMAT NUMERU

21 Agile w praktyce
narzędzia i wskazówki

HR WYZWANIE

4 Jak zaangażować ponad 700 osób

do osiągnięcia wspólnego celu?

9 Uwaga! Szukam Programisty.

Czyli jak zrekrutować talent w IT

EB CASE STUDY

13 Jak zaprosić 70 Python Developerów

na kawę?

17 Zwinny Employer Branding,

czyli jak Agile wspiera budowanie
marki pracodawcy

LIFESTYLE

44 Bulldogjob poleca książki

DO WODY

45 Dowody na istnienie Ludzi Bulldogjob

Zobaczcie co tutaj się wyprawia

ZAWÓD PROGRAMISTA

42 Kim jest,
co umie,
ile mu płacą
gdzie go szukać
JavaScript Developer

3
 HR WYZWANIE

Natalia Białek

Jak zaangażować ponad

700 osób do osiągnięcia
wspólnego celu?

Wyznaczanie celów to jedna z umiejętności, które wielu osobom,

sprawiają trudności. Wykonując codzienne zadania, najczęściej
robimy je rutynowo. Ile razy w ciągu dnia stawiasz sobie pytanie,
czy mój cel jest mierzalny, ambitny i czy mnie motywuje?

Pracuję w firmie Polskie ePłatności (PeP), która w 2020 r. została przejęta

przez zagranicznego właściciela. Cała organizacja, ponad 700 osób, stała
u progu zmiany. Jak wiemy, każda zmiana rodzi poczucie niestabilności,
braku bezpieczeństwa i nasuwa się pytanie: Co będzie dalej?
Dodatkowo to był czas pandemii Covid-19, co jeszcze bardziej utrudniało
utrzymanie poczucia bezpieczeństwa wśród pracowników. Musieliśmy
działać szybko i zwinnie. Naszym celem było wyznaczenie idealnego kie-
runku, który będzie: mierzalny, ambitny i który zaangażuje wszystkich, bez
wyjątków w jego realizację. Efekt? Poznasz w treści :)

K200 CHALLENGE, wyprawa na szczyt - wyznaczenie celu

Stworzyliśmy projekt o nazwie K200. Nazwa zbiegła się w czasie z wydarze-
niem zdobycia przez zespół Nepalczyków szczytu K2. To drugi co do wysokości

4
 HR WYZWANIE

wierzchołek Ziemi. Do stycznia 2021 roku pozostawał ostatnim niezdobytym

zimą 8-tysięcznikiem.

My w firmie, zainspirowani determinacją alpinistów, wiarą w sukces

i wytrwałym dążeniem do jego osiągnięcia, bez względu na okoliczności
postanowiliśmy wyznaczyć sobie równie ambitny cel. Okazało się, że spora
część naszych pracowników jest zapalonymi alpinistami, dlatego droga na
szczyt była odrobinę łatwiejsza.

Pytanie brzmiało: co chcemy osiągnąć?

Odpowiedź była jak zawsze w PeP konkretna: zdobyć 200 tysięcy terminali do
końca 2021 roku. Dodatkowo cyfra 2 na początku sugerowała, że osiągnięcie
celu sprawi, że będziemy nume-
rem 2. na polskim rynku płatności
bezgotówkowych. Z kolei litera K
ma dwojakie znaczenie, ponieważ
z jednej strony nawiązuje do
motywu gór i wejścia na szczyt,
wiąże się naszymi pasjami, a po
drugie K oznacza tysiące, czyli
200 tysięcy terminali do zdoby-
cia. Projekt stał się motywato-
rem dla wszystkich pracowników
PeP na 2021 r., a bezpośrednie
nawiązanie do sportu i wysiłku
wzbudzało u wszystkich z jed-
nej strony chęć rywalizacji, a z
drugiej walki o wspólny sukces.
Tym bardziej, że na wszystkich,
bez wyjątków czekała obiecana
nagroda.

WSPÓLNY CEL DLA WSZYSTKICH - realizacja celu

Mimo że zdobywanie terminali wydaje się być jedynie celem sprzeda-
żowym, zadbaliśmy o to, aby zaangażować wszystkich bez względu na
lokalizację (mieliśmy zatrudnionych ponad 680 pracowników w całej
Polsce). W dobie kończącej się pandemii nie było to łatwe. Praca zdalna
i ograniczenia utrudniały wspólne spotkania, lecz naszym celem było
mimo wszystko pobudzenie pracowników do działania i wyjścia z domowej
strefy komfortu.

5
 HR WYZWANIE

Udało się, zmotywowaliśmy wszystkich pracowników back office do walki

o każdy kolejny terminal, a każdy pracownik PeP, idąc „na zakupy”, mógł
poprzez rozmowę zachęcić właściciela sklepu do tego, aby zdecydował się na
zakup terminala w PeP. Następnie poprzez dedykowaną stronę internetową
pracownicy zgłaszali potencjalnych klientów i po skutecznym zainstalow-
aniu terminala otrzymywali dodatkowe wynagrodzenie. W każdej sytuacji
identyfikowaliśmy się z firmą.

BAZY, czyli nasza integracja - utrzymanie zaangażowania i motywacja

Aby utrzymać motyw górski, podzieliliśmy pracowników na 7 obozów w całej
Polsce. Każdy obóz dostał swoje pierwsze zadanie – zadeklaruj, ile terminali
jesteś w stanie dostarczyć, czyli pokaż swój cel i nakręć filmik, w jaki sposób
chcesz to osiągnąć. Finałem akcji był hybrydowy event, przed którym wszys-
cy pracownicy otrzymali koszulki i czapki z logo 200K, a innowacyjny stream-
ing z głównego studia do wszystkich lokalizacji w całej Polsce spowodował,
że każdy mógł czuć, iż stanowi istotny element całego projektu. To też
umożliwiło wszystkim głosowanie na wybrany filmik. Wzbudziło to ducha ry-
walizacji pomiędzy regionami, ponieważ każda baza chciała zdobyć główną
nagrodę na wyjście integracyjne.

Panowała znakomita atmosfera,

a wszyscy po motywacyjnej mowie
słynnego himalaisty i Dyrektora
Sprzedaży poczuli, że cel jest
możliwy do realizacji.

Cała firma stała przed wyzwaniem, które nas integrowało bez względu na to,
w jakim dziale pracujemy i jakie zadania na co dzień realizujemy.

PEP TV, czyli determinacja do osiągania celów

Kolejne miesiące to podtrzymywanie ducha ciągłej wspinaczki i dążenia do
celu poprzez: dedykowane konkursy mobilizujące siły sprzedaży do większej

6
 HR WYZWANIE

efektywności, stworzenie dedykowanej drużyny sportowej, która była tzw.

zwiadowcą w górach i ostatecznie event PeP TV. Po kilku miesiącach pra-
cownicy potrzebowali kolejnej dawki adrenaliny, wydarzenia, które powie:
jesteście już niedaleko, to ostatnia prosta. Dajcie z siebie wszystko, bo szczyt
jest na wyciągnięcie ręki.

Zorganizowaliśmy wydarzenie PEP TV o charakterze telewizji śniadaniowej

z zaproszonymi gośćmi, m.in. Robertem Korzeniowskim, trenerem reprezen-
tacji Polski. To przyciągnęło przed ekrany wszystkich pracowników. Po raz
kolejny podtrzymaliśmy chęć walki o cel. Pokazaliśmy, że nie można się
poddawać i tak jak u sportowców, wiara w sukces, determinacja i niezłomność
pozwalają stanąć na szczycie. Całość w konwencji tv wraz z gotowaniem na
żywo, łączeniem z bazami, głosowaniem i prawdziwym studio telewizyjnym,
dała poczucie, że jeżeli tylko się chce, to wszystko jest możliwe i Dyrektor
Sprzedaży może stać się Marcinem Prokopem, a koleżanka z HR Dorotą
Wellman. Wiara prowadzi do sukcesu.

JEST MOC, czyli siła zaangażowania pracowników

Ostatecznie nie udało nam się pozyskać do końca 2021 r. 200 tysięcy
terminali, ale zyskaliśmy zdecydowanie więcej. Realizacja projektu spra-
wiła, że w całej firmie zawrzało, wszyscy zaczęli myśleć, jak osiągnąć
upragniony cel, co zrobić, aby pomóc innym zespołom efektywniej
pracować. Poczuliśmy zaangażowanie i moc każdego pracownika. Każdy
z nas wiedział, jak ważnym jest dla PeP. Codzienna praca doprowadziła nas
do wspólnego sukcesu, a wzajemna motywacja zbudowała niesamowitą
atmosferę, która obecnie pozwala nie tylko zdobywać szczyty, ale także
przenosić góry.

7
 HR WYZWANIE

Koniec końców 17 stycznia 2022 r. K200 PeP zostało zdobyte! My jako już
zespół doświadczonych, wysokogórskich wspinaczy polskich ePłatności
wyruszyliśmy do Zakopanego, gdzie w gronie wszystkich pracowników,
z naszym wewnętrznym team spirit, świętowaliśmy nasz wspólny suk-
ces, nasze K200. Co dalej? Mamy nowy cel… o którym pewnie niebawem
opowiemy.

Projekt pokazał, że nie jest najważniejszym osiągnięcie celu liczbowe-

go, ale zbudowanie zaangażowanego zespołu, dla którego kolejne
wyzwania są motorem napędowym i wszystko staje się możliwe.

Natalia Białek
HR Manager
Polskie ePłatności

8
 HR WYZWANIE

Martyna Mroczka

Uwaga, szukam Programisty!

Czyli jak zrekrutować
talent w IT

Programiści, niezależnie od stosowanej technologii, są jednymi

z najbardziej rozchwytywanych pracowników. Dla tej grupy zawo-
dowej to duży plus. Ale… co i w jaki sposób może zrobić Rekruter,
by taki talent przyciągnąć do organizacji? W tym środowisku krąży
suchar: Spotyka się dwóch programistów: – Słyszałem, że straciłeś
pracę. Jak to jest być bezrobotnym? – To było najgorsze pół godziny
mojego życia! Fajnie fajnie, tylko nie dla rekrutera i firmy, która szuka
specjalisty IT.

Jak więc wyróżnić firmę na tle konkurencji? Na co warto postawić, kiedy

brakuje specjalistów? Na to pytanie odpowiem przykładem prowadze-
nia rekrutacji specjalistów IT do firmy Polskie ePłatności, w której pracuję.
W PeP badamy opinie pracowników. Ostatni wynik ankiety to: indeks sa-
tysfakcji pracowników na poziomie 82,4%, frekwencja 93,1%.

Przeczytaj, jak osiągamy tak dobre wyniki i jak pozyskujemy talenty do firmy.

9
 HR WYZWANIE

Rekrutacja to ludzie. Jak dotrzeć do człowieka, który codziennie

dostaje kilkanaście podobnych ofert?
Rekrutacja w branży IT weryfikuje Rekrutera - jego elastyczność, zadaniowość,
innowacyjne podejście i kreatywność. To cechy pożądane, które warto
rozwijać. Czy znajomość technologii to must have u rekrutera? Nie. Dla-
czego? Dlatego, że od znajomości technologii ważniejsza będzie znajomość
swojej firmy, specyfiki branży, charakterystyki pracy na stanowisku, oczeki-
wań grupy docelowej i ogólna znajomość zagadnień technicznych - na tyle,
by przygotować właściwie ofertę, czy dokonać wstępnej analizy aplikacji.

Na co zwracają uwagę kandydaci?

By osiągnąć sukces w rekrutacji IT, trzeba skupić się na szczegółach. Kandy-
daci niechętnie składają aplikacje na oferty bez szczegółów - nie tylko w IT.
Dlatego już przy ustalaniu wymagań z hiring managerem należy dopytać o
wszystkie detale: projekt, metodologię pracy, technologie, ustalić wymaga-
nia must / nice to have. Warto opisać role w zespole, jego strukturę, system
pracy (zdalna/ hybrydowa/ stacjonarna), budżet szkoleniowy, dostęp do plat-
form e-learningowych, itp. Ważny aspekt to szybki proces rekrutacji - nikt
nie chce czekać tygodniami na decyzje. Oferty szybko tracą na ważności,
zwłaszcza w IT.

Ogłoszenia czy direct search?

Nie ma jednoznacznej odpowiedzi - to wszystko zależy od wielu zmiennych
(technologii - niszowa, popularna, budżetu, modelu pracy, projektu, specy-
fiki firmy, itp. ) - warto stosować różne metody i podejść kreatywnie do zada-
nia (marketing szeptany, grywalizacja, wyzwanie rekrutacyjne). W procesie
rekrutacji w PeP, za który odpowiadam, skupiamy się na: autentyczności,
transparentności oczekiwań, stawek płacowych, szybkim przepływie infor-
macji i jasno określonych wymaganiach.

10
 HR WYZWANIE

Rekrutacja się kończy, a osoby z oczekiwanym seniority brak. Co wtedy?

1. Bądź elastyczny - szukaj mocnych stron kandydata, patrz na jego potencjał,
który wykorzystasz z korzyścią dla obu stron. Pomóc w tym mogą szko-
lenia wewnętrzne, zewnętrzne, techniczne oraz miękkie, ponieważ w IT
ludzie ze sobą rozmawiają i współpracują wbrew różnym opiniom.
2. Zwróć uwagę na wykształcenie kierunkowe. Z doświadczenia wiem, że
kilkumiesięczny kurs nie dostarczy oczekiwanego poziomu wiedzy.
Ukończenie prestiżowej uczelni nie zawsze gwarantuje wysokie
umiejętności, ale kilkumiesięczny kurs nie zrobi z laika eksperta.
3. Zastanów się, czy oferowana stawka jest rynkowa. W dobie inflacji jest to
szybko zmieniająca się wartość. Trzeba być na bieżąco.
4. Sprawdź poprawność sformułowania wymagań, nazwę stanowiska, która
optymalnie powinna opisywać wiodącą technologię, jak i tytulaturę
- ja wykorzystuję: junior/ mid/ senior.

Uwaga! rekomenduję
skrócić proces rekrutacji
do minimum!
5 dni od momentu wysłania CV - tyle trwa proces rekrutacji w PeP. Składa
się z 3-4 etapów. Pierwszym z nich jest rozmowa wstępna z Rekruterem -
screening call (rozmowa zdalna 15 min, podczas której badamy najważniejsze
aspekty: dostępność, oczekiwania odnośnie do pracy, motywację, dopaso-
wanie do oferty, przedstawiamy najważniejsze informacje dotyczące organi-
zacji oraz pracy na danym stanowisku) i rekomendujemy wybranych kandy-
datów do kolejnego etapu.

Następnym krokiem jest weryfikacja techniczna przez przełożonego i osobę

z zespołu (podczas spotkania sprawdzamy też dopasowanie do zespołu
i naszej kultury organizacyjnej). Ten etap jest kluczowy. Weryfikujemy
nie tylko wiedzę, ale również podejście do pracy i wyzwań, gdyż szukamy
wytrwałych osób. Doświadczenie to nie umiejętności, dlatego stawiamy na
weryfikację wiedzy, udział w projektach i inne parametry, a nie tylko staż
pracy, ponieważ nie zawsze koresponduje to z umiejętnościami.

11
 HR WYZWANIE

Po spotkaniu omawiamy najważniejsze dla nas aspekty i podejmujemy

wspólnie decyzję. Jeśli nie jesteśmy jednomyślni, zapraszamy kandydata
do dodatkowego etapu, jakim jest test /Coding assessment/ czy kolejne
spotkanie.

Korpo – nie Korpo.

Jak przekonać Programistę,
że to firma dla niego?
Uczciwa i prosta komunikacja bez lania wody. W PeP to jasno
określone oczekiwania, transparentność, możliwości rozwoju i awansu, ale
przede wszystkim atmosfera, dobre relacje oraz życzliwość. Stawiamy na
integrację zespołowe i ogólnofirmowe poprzez wspólny udział w konferen-
cjach, wydarzeniach sportowych czy imprezach. Stawiamy na elastyczność
- w każdym obszarze od ustaleń ofertowych, po pracę zdalną 100%, brak
dress code i niekorporacyjne podejście.

Dobrym rozwiązaniem jest też Program Poleceń. Jeśli znasz swoje moc-
ne strony i pracownicy doceniają firmę, świetnym rozwiązaniem jest intrat-
ny program poleceń. W firmie, gdzie indeks satysfakcji wynosi 82,4% przy
frekwencji 93,1%, nie jest to trudne. Świetny wynik jest zasługą otwartości
naszego Zarządu na zmiany i ulepszanie procesów. Po każdym badaniu
satysfakcji, a przeszliśmy już 5 edycji, wprowadzamy ulepszenia w obszarach,
które tego wymagają. Zebrane dane nie są tylko pustymi wskaźnikami
analitycznymi, a są początkiem poprawy jakości i efektywności funkcjo-
nowania firmy w wielu obszarach. Nie boimy się wyzwań stawianych
przez Pracowników, dlatego w ramach rozwoju wprowadziliśmy Program
Innovation in PeP. Pracownicy mogą w nim zgłaszać inicjatywy rozwo-
jowe wpływające na całą organizację i usprawnianie procesów. Warto
współpracować z ekspertami zewnętrznymi.

Czy Ty masz swoje złote zasady, które sprawdzają się w Twojej firmie?
Podziel się ze mną wskazówkami!

Martyna Mroczka
Recruitment Manager
martyna.mroczka@pep.pl

12
 EB CASE STUDY

Mateusz Fiedosiuk

Jak zaprosić 70
Python Developerów
na kawę?

Takie pytanie postawił przede mną klient z branży IT. Firma

zatrudniająca ponad 800 specjalistów IT, chciała zaangażować
developerów do udziału w evencie organizowanym w jednej z wroc-
ławskich kawiarni.

Cele

Budowanie marki klienta. Nawiązanie relacji z developerami, którzy nie znają

dobrze firmy. Promocja firmy wśród potencjalnych przyszłych pracowników.
Zbudowanie zaufania.

Wyzwania Ograniczenia związane z miejscem i czasem

Wydarzenie organizowane przez klienta odbywało się stacjonarnie we

Wrocławiu. Tak wąska grupa odbiorców, skierowana tylko i wyłącznie do
jednego miasta zmniejsza szansę na dotarcie z komunikatem do dużej
grupy użytkowników. Event odbywał się w lipcu. To tzw. miesiąc ogórkowy :)
Martwy okres w branży IT, słaby na prowadzenie projektów EB, rekruta-

13
 EB CASE STUDY

cyjnych i wydarzeń. Dlaczego w okresie czewiec-lipiec-sierpień prowadzenie

projektów jest ryzykowne? Bo większość pracowników jest przed/po lub
w trakcie wakacyjnych wyjazdów. Ciężko w tym czasie przebić się z komuni-
katem o evencie i kawie.

Rozwiązanie Bulldogjob

Pewnie często usłyszysz od doradców: “Do każdego klienta podchodzimy indy-

widualnie”. To może brzmi świetnie, ale w praktyce oznacza przedłużający
się okres wyceny, słabe know-how w realizacji i efekt dowieziony w ułamku
planu. Celem jest dotarcie do określonej grupy docelowej w liczbie X,
zebranie Y zapisów na wydarzenie. Spełnienie tych KPI wymaga:
analizy sytuacji,
zaplanowanie przemyślanego działania,
wdrożenie go w życie,
optymalizacja,
przedstawienie efektów i raport z działań.

Moim zadaniem w dziale EB Bulldogjob

jest realizacja celów Klienta przy wykorzystaniu
mocno stargetowanego profilu IT.
Łącze puzzle - biorę potrzebę firm IT, idę z nią do zespołu
marketingowego Bulldogjob, układam to w całość.
Uruchamiam maszynę :) Dzieje się.

Taki model pracy wymaga szybkiego działania.

Rynek IT jest tak dynamiczny, że “spokojne”
planowanie działań na wiele miesięcy w przód,
często jest niemożliwe. Kandydat, do którego
docieramy tu i teraz, za rok może mieć już zupełnie
nowe kompetencje i rozwijać się w nowej firmie
bez dalszej chęci na zmianę pracy. Pamiętajmy
też, że specjaliści HR oraz EB, którzy kontaktuję
się ze mną, robią to dlatego, że nie mają czasu
lub zasobów na ciągnięcie projektu własnymi
siłami. To oznacza, że komunikacja na linii Klient -
Bulldogjob powinna być maksymalnie konk-
retna i oszczędna w czasie. Wtedy klient ma
miejsce na swoje pozostałe działania.

14
 EB CASE STUDY

Słysząc od klienta: “Chcemy wypromować wydarzenie dla branży IT”,

nie zastanawiam się, od czego zacząć, tylko zadaję klientowi 6 pytań:

1) Jak dużo wydarzeń planujecie?

2) Czy jest już gotowy kalendarz?
3) Wydarzenia firmy będą otwarte czy obowiązują wcześniejsze zapisy?
4) Kto jest Waszym targetem? (Junior/Mid/Senior? Jakie technologie?)
5) Ile ludzi chcielibyście zebrać na każdym i/lub wszystkich wydarzeniach?
6) Czy macie zamknięty budżet całej kampanii, który musimy brać pod uwagę?

Tak też było w przypadku promocji eventu dla Python Developerów, czyli
zaproszeniu siedemdziesięciu Python Developerów na kawę we Wrocławiu.
Klient odpowiedział na 6 pytań. Na podstawie odpowiedzi ja przygotowałem
ofertę. Klient spędził kilka dni nad analizą oferty i wrócił do mnie z akceptacją
warunków i zielonym światłem na uruchomienie działań.

W poniedziałek o 15:04 na mojej skrzynce mailowej zamigotało powiado-

mienie. Dostałem wiadomość od klienta -> startujemy z promocją eventu
razem. Tego samego dnia klient dostał fakturę, która jest potwierdzeniem
ustaleń. Zespół Bulldogjob ruszył z działaniami.
Do zrobienia był: media plan kampanii, grafiki zgodne z wytycznymi klienta,
rozłożenie budżetów mediowych na reklamy i terminarz postów organicz-
nych. Dwa dni od wystawienia faktury wszystkie elementy układanki były
gotowe i czekaliśmy tylko na akceptację od klienta

W poniedziałek, niecały tydzień od decyzji, kampania działała w inter-

necie, promując event wśród Python Developerów.

Efekty

Kampania Adsowa, czyli reklama, którą zobaczysz na Facebooku i w okien-

kach reklamy Google, została wyświetlona 239 094 razy. 64 831 unikalnych
użytkowników zobaczyło reklamę, a 1 283 osób kliknęło link do wydarzenia.

Dla zobrazowania wyobraź sobie wszystkich mieszkańców Stegny

(prawie 10 tys. osób) w jednym momencie na plaży… i pomnóż to razy
6,5. Dużo, prawda? :)

Oczywiście nawet celując stricte w grupą docelową, tylko część odbiorców

zdecyduje się na udział w wydarzeniu. Jednak zgrywając akcję z wewnętrzny-
mi działaniami klienta, aż 70 programistów zapisało się na wydarzenie.

15
 EB CASE STUDY

Wnioski

Jeśli chcesz zaangażować konkretną ilość doświadczonych developerów,

musisz dotrzeć do 900 razy większego grona odbiorców.

Wydarzenia stacjonarne są trudniejsze w organizacji, ale żaden najlepszy

webinar online nie zastąpi otwartej rozmowy na żywo.

Jeśli planujesz wydarzenie dla branży IT, warto odezwać się do

Bulldogjob - niezależnie czy termin jest za 3 miesiące, czy 3 tygodnie :)

Mateusz Fiedosiuk
Employer Branding & Business Manager
mateusz.fiedosiuk@bulldogjob.pl

16
 EB CASE STUDY

Marta Rydzanicz

Zwinny Employer Branding,

czyli jak Agile wspiera
budowanie marki pracodawcy

Minęło sporo czasu, odkąd rzeczywistość zarządzania projektami IT na

zawsze zmieniła swoje oblicze dzięki Agile Manifesto. Sformułowane
wówczas 4 główne wartości i 12 zasad pracy zwinnej odesłało do la-
musa tradycyjne metody tworzenia oprogramowania. Zdefiniowały
na nowo podejście do produktu, współpracę z klientem, budowanie
i organizację zespołów, reakcję na zmiany czy rozwój. Nic więc dziw-
nego, że otworzyło to również przestrzeń dla skutecznych metod
działania poza środowiskiem IT, a uniwersalność zwinnych technik
przyjęła się także w Employer Brandingu.

Agile dla EB
I oto jest – Manifesto for Agile HR Development, który ku radości wszyst-
kich HR-owców i EB-owców określa, jak budować angażującą kulturę
organizacyjną. Tak więc, jeśli mówimy o budowaniu marki pracodawcy
w duchu Agile, warto zacząć od podstaw, czyli wartości. Agile HR Manifesto
definiuje je następująco:
sieci współpracy ponad hierarchiczne struktury,
przejrzystość ponad tajność,

17
 EB CASE STUDY

zdolność do adaptacji ponad wykonywanie poleceń,

inspirowanie i angażowanie ponad zarządzanie i utrzymywanie,
motywacja wewnętrzna ponad zewnętrzne nagrody,
ambicja ponad obowiązek.

Brzmi doskonale, a momentami może nieco utopijnie, ale im szybciej

określimy miejsce swojej organizacji na tle tych zasad, tym łatwiej i pre-
cyzyjniej będziemy mogli wybrać z metodologii Agile takie techniki, które
otworzą nam drogę do zwinnej pracy nad projektami EB.

Nowa rzeczywistość, zwinne metody

Zgodnie z raportem The State of Agile HR 2020, wśród głównych powodów,
dla których działy HR rozpoczęły prace w trybie Agile, pojawia się szybsza
odpowiedź na zapotrzebowanie biznesowe.
Pandemia Covid-19 i wojna w Ukrainie rzuciły nas wszystkich w nowe realia
i bez wątpienia odcisnęła mocne piętno na sposobach realizacji oraz orga-
nizacji pracy działów EB.

Pytanie, czy bez kompetencji Agile,

silnej współpracy działów i umiejętności
szybkiego dostosowania się do zmian,
bylibyśmy w stanie zdać ten egzamin
pozytywnie?
Jak wynika ze wspomnianego raportu,
według 65% respondentów pandem-
ia przyspieszyła przyjęcie Agile HR wśród
działów zajmujących się zasobami ludzkimi.
Dzięki temu wiele firm potrafiło w szybkim
czasie wdrożyć konkretne rozwiązania ta-
kie jak zaopatrzenie pracowników w sprzęt
na potrzeby home office, zdalne rekrutacje
i onboarding, szkolenia z zakresu efektywnej
pracy zdalnej, motywowanie pracowników,
nowe benefity wspierające well-being czy
nawet wirtualne spotkania zespołu przy
użyciu technologii VR.

Podobną elastyczność działania możemy zaobserwować w przypadku

otwarcia się na pracowników z Ukrainy. Wraz z wojennymi wydarzeniami
ostatnich miesięcy, polski rynek pracy przywitał rzesze nowych, wykwali-
fikowanych osób. Zgodnie z badaniem Antal Market Research, 77% firm

18
 EB CASE STUDY

w Polsce jest gotowych zatrudnić u siebie obywateli Ukrainy. I choć często

pracodawcy podkreślają znajomość języka angielskiego jako warunek ko-
nieczny, część firm zdecydowała się na przygotowanie całej komunikacji
z przyszłym pracownikiem w języku ukraińskim.
Niektóre firmy, jak IKEA, Accenture czy Monterail, poszły nawet o krok dalej,
wdrażając działania z zakresu diveristy & inclusion, czyniąc tym samym swoją
organizację dostępną dla wszystkich, bez względu na narodowość, wyznanie,
wiek, płeć, orientację seksualną czy sytuację rodzinną.

Żadnych tajemnic
Kluczowym czynnikiem sukcesu dla Agile HR jest przejrzystość przepływu
pracy. Transparentność jest pożądana, ale niełatwa do osiągnięcia i utrzy-
mania. Budowanie przejrzystości nie sprowadza się jedynie do ułożenia
tasków na tablicy Kanban i cyklicznego śledzenia statusów. Transparentność
to przede wszystkim komunikacja oparta na autentyczności, wzajemne za-
ufanie i dzielenie się informacją zwrotną. Nie ma zwinnej organizacji bez
nawyku dzielenia się feedbackiem, czy to na poziomie samoorganizujących
się zespołów, czy całej firmy.
Co istotne, przejrzystość odnosi się do całego employee experience, dlatego
należy zadbać o spójność komunikatów zarówno wewnątrz, jak i na zewnątrz
organizacji.

Sprintem do celu
Jednym z głównych założeń metodologii Agile jest otwartość na zmiany przy
szybkim dostarczaniu efektów. Weźmy zatem na warsztat jeden z produk-
tów, który chyba każdy zespół EB miał na swojej roadmapie, czyli stronę
kariery. Autorzy książki “Bądź Agile. Zwinnie o HR i Employer Brandingu”
kompetencje potrzebne do zrealizowania tego projektu dzielą między
EB-owca, Rekrutera, UX-owca, Grafika, Marketingowaca, PR-owca i Pro-
gramistę. Ręka do góry, kto miał
szansę pracować przy stronie ka-
riery w takim właśnie składzie?
Owszem, to zestaw idealny, ale...

W przypadku mniejszych firm,

które dopiero budują swoją
strategię Employer Brandingu,
pierwsze wyzwanie pojawia się
już na etapie zebrania zespołu,
który w szybkim czasie poz-
woli zrealizować ustalony cel.

19
 EB CASE STUDY

Zaczynając od celu właśnie, warto na samym początku określić, jakie zadanie

powinna realizować strona kariery zgodnie z ogólnymi założeniami bizneso-
wymi firmy. Tutaj z pomocą przychodzi praca w Scrumie, czyli przełożenie
kolejnych tasków na sprinty, planowanie, codzienny Scrum, przegląd sprintu
i retrospektywę. Oczywiście każdy zespół powinien wybrać z tych narzędzi op-
tymalny zestaw, który będzie spójny z potrzebami i możliwościami zespołu.
Wszak nie ma jednej idealnej metody, która sprawdzi się w każdej firmie.

Podsumowanie
Zwinna metodyka działania podczas pracy przy projektach EB pozwala
zapanować nad chaosem i z całą pewnością stanowi ewolucję struktury
zarządzania pracą. Nie należy się bać tej metody, mimo że pierwsze kroki
mogą okazać się dosyć trudne. Nie każdą decyzję podjętą szybko nazwie-
my zwinną. Przyjęcie zmiany powinno odbywać się w sposób przemyślany,
świadomy i przede wszystkim zgodny z firmowym Agile Mindset.

Marta Rydzanicz
Employer Branding & Communication Manager w Linker Cloud
marta.rydzanicz@linkercloud.com

20
 TEMAT NUMERU

Anna Ordyńska

Testuj tworzenie
prywatnych działań
w Scrumie w domu

Na początku był tylko SCRUM w IT

Przez 17 lat pracowałam w firmach, w których pełniłam naprzemiennie
różne role, m.in. Project Managera, Scrum Mastera czy Product Ownera. Wyko-
rzystywano w nich różne podejścia od kaskadowych po zwinne. Scrum był
wykorzystywany tam głównie do produkcji aplikacji IT dla klientów i wydawało
mi się, że to jest jego jedyne naturalne środowisko.

Scrum
IT
 TEMAT NUMERU

SCRUM to nie tylko IT

Historia ta rozpoczęła się kilka lat temu, podczas jednego ze spotkań Scrum
Warsaw, organizowanego przez Mateusza Żeromskiego. Tam poznałam
Lucynę Konkel, która opowiadała, w jaki sposób podjęła się wyzwania
dotyczącego połączenia pracy działu HR z pracą Scrum Masterów. Temat
był dość kompleksowy. Mówiła o metodach planowania szkoleń dla Scrum
Masterów, których celem było stanie się „satelitami” działu HR, a więc spec-
jalistów, którzy pracowali wewnątrz zespołów i blisko ludzi. Była też mowa
o sposobach, w jakie burzyli “mury” między tradycyjnym działem HR
a całym wnętrzem organizacji. O tym, jak dzięki swojemu doświadczeniu
HR-owcy pomagali zespołom IT usprawnić komunikację, aby miała ona real-
ne przełożenie na atmosferę i jakość pracy ludzi, ale też o tym, że HR również
może zacząć pracować w Scrumie.

Ta myśl nieustannie krążyła po

mojej głowie. Byłam zafascynowana
i wdzięczna Lucynie, że otworzyła mi
oczy, iż Scrum to nie tylko IT.
Potem przyszła era koronawirusa, czyli praca online i konieczność zajęcia się
w 100% swoim prywatnym czasem w obrębie domu. Na domiar wszystkiego,
wcześniej miejscem, gdzie odpoczywałam i zrzucałam stresy dnia codzienne-
go, był basen. W czasie pandemii musiałam zrezygnować z pływania i długo
szukałam miejsca albo aktywności, które pozwoliłyby mi się zrelaksować.

Scrum
IT
HR
 TEMAT NUMERU

SCRUM w domu?
Po godzinach pracy zaczęłam nieśmiało zajmować się pracą w ogrodzie.
Po jakimś czasie uświadomiłam sobie, że znalazłam dla siebie zajęcie, które
sprawia mi przyjemność. Tak powstał pomysł, aby zrewitalizować spory ogród
przy domu.

Pomyślałam: a gdyby zaprojektować

ogród, wykorzystując Scruma?
Rozdałam domownikom kartki z planem działki, na których zaznaczone były
elementy stałe i każdy miał nanieść na nią swoje pomysły: gdzie umiejscowić
kompostownik, rabaty kwiatowe, które krzewy należy przesadzić na jesień,
jakie warzywa i owoce chcemy uprawiać, gdzie postawić stół ogrodowy i czy
chcemy go zadaszyć.

Stworzyliśmy wstępny Product Backlog (listę zadań dotyczącą produktu)

i zaplanowaliśmy początkowy budżet. Zrobiliśmy inwentaryzację sprzętu
ogrodowego i rozpisaliśmy, czego nam brakuje, z podziałem na te narzędzia,
które należałoby kupić od razu i te, których zakup musiał poczekać.

Przy pracach w ogrodzie warto pamiętać, że wiele milestone’ów wyznacza

sama natura i kalendarz księżycowy, który podpowiada, jak przygotować
ogród na wiosnę, kiedy planować nasadzenia, a później, jakie prace należy
wykonać przed zimą. Podzieliliśmy zakres prac na miesięczne sprinty i tak
działamy od dwóch lat. Są miesiące wiosenno-letnio-jesienne, kiedy prac
jest więcej, bo siejemy, kosimy, przesadzamy oraz miesiące mniej aktywne
podczas zimy.

Scrum
IT
HR
 TEMAT NUMERU

Co to w ogóle jest SCRUM?

W dużym skrócie Scrum to metodyka, według której pracuje się iteracyjnie
i tworzy przyrostowo. Maksymalną jednostką iteracji, czyli tak zwanym
sprintem, jest jeden miesiąc. Rozwój produktu podzielony jest na sprinty,
w których planujemy konkretny zakres działań. Przyjmuje się, że dokładne
planowanie wykonujemy dla 3 najbliższych, natomiast dla pozostałych
są to orientacyjne plany i im bliżej jesteśmy tych kolejnych, tym bardziej
Product Owner powinien pilnować, aby zadania były jak najdokładniej
opisane. Oznacza to, że wymagania powinny być na tyle wyczerpująco opra-
cowane, aby zespół wiedział, jak je wykonać.

Jak wykorzystuję SCRUMA w domu?

Na początku miesiąca spotykamy się na domowym Sprint Planningu
i rozmawiamy o tym, które z zadań z Product Backlogu chcielibyśmy
w tym okresie zrealizować, tworząc dzięki temu Sprint Backlog. Daily
(codzienne piętnastominutowe spotkanie uczestników) dzieje się natu-
ralnie, gdy wychodzimy na chwilę do ogrodu, podziwiamy dotychczasowe
osiągnięcia i rozmawiamy o tym, co warto byłoby wykonać ze Sprint Back-
logu na ten miesiąc.

Każdy ma swój zakres zadań. Jeden kosi, drugi podlewa rośliny kwitnące,
trzeci zgłasza się z pomysłem, że można coś przesadzić, a czasem ktoś
przychodzi z nową rośliną “niespodzianką” i pyta, gdzie ją posadzić. Wtedy
staramy się znaleźć w sieci, jakie są wymagania tej rośliny i wybrać dla niej
odpowiednie miejsce (to takie opracowanie wymagania, które zaraz znajdzie

24
 TEMAT NUMERU

się w Sprincie).
Pod koniec miesiąca podczas Sprint Review staramy się usiąść i sprawdzić,
które z planów udało się wdrożyć, a które musimy przesunąć na kolejny
Sprint. W przypadku ogrodu zdarza się, że niektóre z nich lądują z powrotem
w Product Backlogu i czekają na kolejny rok.

Dzięki tym doświadczeniom

zrozumiałam, że Scrum to przede
wszystkim zmiana sposobu myślenia.

Gdzie jeszcze można zastosować SCRUM?

Jeśli się dobrze zastanowić, to w zaciszu domowym mamy wiele okazji do
wdrożenia Scruma: od planowania ślubu, poprzez zakup wymarzonego
mieszkania i planowanie remontu, zakup rodzinnego auta oraz jego utrzy-
manie, aż po organizację rodzinnych wyjazdów czy roku szkolnego dzieci.
Na oddziałach szpitalnych też prowadzone są codzienne odprawy, a zabie-
gi na blokach operacyjnych planuje się w sposób iteracyjny. Często ludzie
pracują w Scrumie, ale nie są tego świadomi.

Ostatnio usłyszałam słowa, które dziś krążą po mojej głowie: gdy wiemy,
czego oczekujemy, układamy plany i konsekwentnie je realizujemy
- wtedy mamy szansę przeżyć to życie zgodnie ze sobą. Nie czeka-
my na to, co przyniesie nam los. Oczywiście nie można dać się zwariować,
z nadgorliwym używaniem Scruma na wszystkich czynności domowych.
Jak we wszystkim, ważna jest równowaga.

Na początku tej drogi ważne jest, by zrozumieć filozofię zwinnego działania.

W późniejszym czasie proponuję zagłębić się w różnice między zwinnymi
projektami a produktami.

Z jakich narzędzi korzystać, stosując SCRUMA?

Dla mnie Scrum to przede wszystkim praca z ludźmi. Nie ma znaczenia, jakie
narzędzie wybierzemy. Pamiętam, jak w pracy pierwsze planowanie sprintu
wykonywaliśmy po prostu na kartkach papieru i przyklejaliśmy je do ścian.
Dziś na rynku jest sporo aplikacji IT, które pozwalają przenieść ten świat do

25
 TEMAT NUMERU

formy cyfrowej.
Jak zdobyć doświadczenie?
Kiedy zmniejszono obostrzenia i znów mogliśmy się spotykać na Scrum
Warsaw, miałam okazję poznać osoby, które chcąc się przebranżowić, między
innymi z gastronomii na IT, przyszły posłuchać o Scrumie.

W dzisiejszych czasach tylko w świecie IT słowo Scrum jest rozpoznawalne.

Wiele osób nie posiada doświadczenia. Dysponują jednak silnymi stron-
ami (np. talenty według Gallupa), dzięki którym mogliby z dużą dla siebie
łatwością pełnić rolę np. Scrum Mastera. Jednak przeczytanie Scrum Guide’a
i zdanie egzaminów na Scrum Mastera (SM) czy Product Ownera (PO), nie
jest już progiem wejścia do nowej branży.

Zatem jak zdobyć doświadczenie i zrozumieć filozofię zwinnego działania?

Spróbujmy odwrócić ścieżkę. Najpierw potrenujmy Scruma w domu. Oso-
by pracujące zwinnie powinny mieć otwartą głowę. Chodzi o poszerzanie
horyzontów. By być SM czy PO, nie musisz pochodzić ze świata IT. Spróbuj
i potestuj tworzenie prywatnych działań w Scrumie. Podczas pisania tego
artykułu podzieliłam się tą myślą z kilkoma osobami, które też znają Scruma.
Dowiedziałam się, że część z nich też praktykuje tę metodykę w domu.

Wiele praktyk ma dzisiaj charakter interdyscyplinarny i wartość danej prak-

tyki wykazuje jej bogactwo, gdy ma ona wszechstronne zastosowanie.
Tym bardziej ucieszyła mnie tegoroczna publikacja “Bądź Agile. Zwinnie
o HR i Employer Brandingu” Olgi Żółkiewicz, Marcina Olszewskiego i Ma-
teusza Czarneckiego, w której udowadniają, że zwinne podejście sprawdza
się również i w tych obszarach.

Anna Ordyńska
Scrum | IT Project Manager

26
 TEMAT NUMERU

Michał Mazur

PATOSCRUM
Jak zepsuć projekt scrumowy
i znienawidzić Scruma

Scrum jest frameworkiem opartym o zwinne techniki organizacji pracy,

służącym szybszemu dostarczania wartości biznesowej klientowi. Powiem tak
- widziałem wiele z fotela programisty. Sam wdrażałem trzykrotnie te zasady
do małych kilkuosobowych projektów, byłem w kilku firmach, gdzie był on
wdrożony w dużej skali. Czasem to działało fajnie, a innym razem wychodziły
potworki z połączenia waterfalla ze Scrumem. Mam kilka przemyśleń o pa-
toscrumie, czyli niezrozumieniu, czym on jest i jakie ma cele.

Przeliczanie story pointów na czas

Jak zapewne wiesz, w Scrumie używa się tzw. story pointów do szacowania
złożoności zadań. Jest to liczba z ciągu Fibonacciego, np. 1,3,5,7 itd. Zespół
oszacowuje złożoność i na tej podstawie powinno się decydować, czy np.
dane zadanie powinno być podzielone na mniejsze i czy zespół powinien się
nim zajmować w aktualnym sprincie.

Niektórzy klienci traktują storypointy jako wyrocznie i przeliczają sobie np.,

że 3 storypointy to 2 dni robocze. Zespół robi 21 punktów w ciągu sprintu.
Do dowiezienia epika trzeba 120, więc w 6 sprintów epik będzie gotowy na
produkcji. Otóż nie do końca tak to działa.

27
 TEMAT NUMERU

Jeśli zespół składa się z robotów, żadne nieprzewidziane sytuacje nie są

planowane oraz dokładnie wiadomo, co i kiedy trzeba zrobić, to jeszcze ma
szansę to działać. W praktyce wygląda to zupełnie inaczej. Mówi się, że Bóg,
słysząc o jakichkolwiek planach, daje nam pstryczka w nos i cały misterny
plan w… ;)

We know from chaos theory that even if you had

a perfect model of the world, you’d need infinite
precision in order to predict future events. With
sociopolitical or economic phenomena, we don’t
have anything like that. - Nassim Nicholas Taleb,
autor m.in “Czarny Łabędź”, “Antykruchość”
A co, jeśli zmieni się skład zespołu. Np. dochodzi nowa osoba, więc trzeba ją
wprowadzić. Zajmuje to czas i uwagę doświadczonych developerów, więc
ich produktywność spada, a to wpływa na wyniki zespołu. Albo najbardziej
doświadczony developer idzie na urlop, co wpływa bardzo negatywnie na
produktywność, szczególnie w złożonych projektach, gdzie nie ma tradycji
prowadzenia dokumentacji i testów.

Słyszałem historię, o jednym kliencie, który chciał wynegocjować pakiet sto-

rypointów, np. 100 pkt- 10k złotych, zamiast płacić standardowo za godziny,
czy projekt/moduł. Rodzi to ciekawe patologie, jak np. sztuczne rozdmuchi-
wanie estymat, czy problemy z rozliczaniem teamu za faktyczną pracą. Co
w przypadku, gdy funkcjonalności zawierają błędy? Jak je rozliczać?

Czy to oznacza, że nie warto tego robić?

Jestem zwolennikiem estymowania, bo to wprowadza moment do dys-

kusji o zadaniach i czekających zespół wyzwaniach. Wszyscy są świadomi
(szczególnie Product Owner) potencjalnych zagrożeń dla celu sprintu.
Nie brałbym estymacji na 100% poważnie, ze względu na to, co może się
wydarzyć w trakcie sprintu. Na pewno nie używałbym punktów do ustalania
budżetu projektu.

No estimate

Obecnie coraz popularniejszy staje się podejście “#NoEstimates”, polegające

na tym, że w ogóle nie estymuje się zadań. Polecam ciekawy artykuł na

28
 TEMAT NUMERU

Bulldogjob o tej strategii: Ruch #NoEstimates, czyli koniec estymat.

Sam autor Scruma wypowiedział się krytycznie o estymowaniu za pomocą

storypointów.

Klient jest Product Ownerem

Według definicji Scruma Product Owner reprezentuje klienta. Powinna to

być osoba od strony wykonawcy, która ma bezpośredni kontakt z klientem.
W niektórych aplikacjach Scruma właścicielem produktu jest mianowana
osoba od strony zleceniodawcy. Największym plusem jest to, że skracamy
ścieżkę decyzyjną i przyspieszamy proces wytwórczy. Zespół developer-
ski otrzymuje osobę, która jest zazwyczaj najbardziej kompetentna. Wybór
osoby od klienta jako PO ma kilka strategicznych wad.

Załóżmy, że klient przynosi dużo pieniędzy firmie. Może się wycofać z pro-
jektu i przejść z nim do konkurencji. Powoduje to konflikt interesu i potrzebę
uprawiania polityki. Klient nie może się dowiedzieć o wszystkim, co się dzie-
je, szczególnie o trudnych sprawach, bo źle to wpływa na PR firmy tworzącej
oprogramowanie. Szczególnie kłopotliwe jest, jeśli zespół przechodzi trudne
momenty, a Product Owner jest na każdym spotkaniu, szczególnie na daily.
Według podręcznika Scruma, PO nie powinno na nim być.

Jeśli PO nie zna Scruma, to na Scrum Masterze spoczywa dodatkowa

odpowiedzialność, czyli nauczenie go zasad pracy zwinnej, co nie zawsze jest
proste i przyjemne.

29
 TEMAT NUMERU

Scrumowodospad

Scrum i waterfall wydają się być jak bracia z różnych matek i ojców. W teorii
można stosować Scruma w waterfallu, ale jest to trudniejsze niż samo prowa-
dzenie projektu czysto agile’owego, bo mieszamy różne sposoby i zasady
pracy.

Widziałem projekt, który był prowadzony w formie Scrumowodospadu.

Miał być jako Scrum, ale powstała dziwna mieszanka, bo prawdopodobnie
menadżerowie z wyższej półki od klienta dotąd głównie pracowali w wodo-
spadach.

Zespół dostawał z góry zaplanowany zestaw gotowych zadań z wybranych

epików na dany sprint. Zadania zazwyczaj nie miały kryteriów akceptacji. Nikt
w zespole nie wiedział, dlaczego to robimy, jaki jest “wyższy cel”. Programiści
po prostu klepali kodzik.

Oprogramowanie stale się zmienia. Każda zmiana może wymuszać wiele

innych zmian, a to wpływa na jakość doświadczenia z danego produktu.
Niemal niemożliwe jest przewidzenie każdego problemu z góry.

Dla nas developerów jest bardzo ważne, abyśmy mieli wpływ na backlog
i mogli brać udział w planowaniu sprintu. Daje to więcej satysfakcji, poz-
wala na wcześniejsze przygotowanie się i zmniejsza napięcie w zespole. Nie
mówiąc o tym, że daje dużo większą szansę na dowiezienie sprintu do końca.

Definition of done jest niezdefiniowane

Definition of done, czyli “definicja ukończenia” określa, co oznacza, że coś jest

ukończone. Każdy w zespole powinien rozumieć, co oznacza, kiedy zespół
developerski mówi, że skończył pracę nad funkcjonalnością, którą wziął do
sprintu. Każdy powinien też zrozumieć, co zostało wykonane i co może być
jeszcze potrzebne, aby wdrożyć dane rozwiązanie na produkcję. Określenie
definicji ukończenia należy do obowiązków zespołu.

W praktyce nie widziałem dobrej definicji w projektach, co nieraz budziło

dyskusje, czy coś faktycznie jest gotowe. Dla niektórych to zamknięcie
zadania przez developera było oznaczeniem jako “ukończone”, a dla
innych akceptacja przez QA, czy dopiero moment sprawdzenia wdrożonej
funkcjonalności na produkcji.

30
 TEMAT NUMERU

**źródło:** [Definition of Done - po co i jak stworzyć? | QAgile - Jakość w Agile]

Brak kryteriów akceptacji czy definiowanie ich podczas trwania sprintu

Kryteria akceptacji (acceptance criteria) to lista konkretnych warunków

i wymagań stanowiących podstawę do określenia historyjki jako kompletnej
z biznesowego punktu widzenia.

Klasyk w patoscrumach. Zadania nie są dobrze zdefiniowane, nie wiadomo

jak dokładnie coś ma działać, brakuje dokumentacji i przykładów. Develo-
perzy estymują takie zadania na podstawie tytułu ticketa, ew. kilku słów od
Analityka czy Product Ownera. W trakcie pracy developer musi zdefiniować
kryteria akceptacji. Okazuje się, że nie da się wykonać zadania, bo brakuje
elementów układanki oraz są zależności, których się nie przewidziało.

Powoduje to masę opóźnień w projektach i przepalanie energii developerów

na tworzenie zbędnych lub źle działających funkcjonalności.

Wyciskanie sprintu na maksa i brak przestrzeni na nieprzewidziane

Kierownictwo myśli sobie:

Nasz zespół developerski przez ostatnie sprinty robi średnio 20 pkt., więc
w tym sprincie też pewnie tyle zrobi. Przypiszmy im tyle, a może nawet
więcej. Niech się wykażą i szybciej dowiozą nowe historyjki, na których zależy
prezesowi.

31
 TEMAT NUMERU

Może się to udawać, jeśli nie wydarzy się nic nieprzewidzianego, a estymacje
biorą dokładnie pod uwagę, że trzeba np. przygotować infrastrukturę, napisać
testy, dokumentacje, testować, developować itd. Na pewno wydarzy się coś
nieprzewidzianego, np. choroba dziecka jednego z członków zespołu, zepsuje
się laptop, trzeba będzie szybko poprawić poważny i złożony błąd na produkcji.

Jeszcze raz powtórzę:

punkty to nie estymacja czasowa ;)
Dobry zespół scrumowy powinien zawsze mieć bufor bezpieczeństwa, np.
20% czasu na nieprzewidziane obsuwy.

Słyszałem o ciekawej praktyce w jednym zespole. Co każdy sprint jedna

z osób zostawała “szeryfem”. Jakie było jej zadanie? Miała obsługiwać wszyst-
kie wykryte błędy, wspierać użytkowników produktu i support. Wtedy nie
miała przyznawanych story pointów, a zespół mógł się skupić na dostarcza-
niu nowych funkcjonalności i nie był rozpraszany “wrzutkami”.

Podsumowanie

Źle używane narzędzie może się łatwo obrócić przeciwko użytkownikowi.

Podobnie jest z metodykami agile, szczególnie ze Scrumem. Wierzę, że
można dobrze prowadzić projekt, szczególnie jeśli słucha się potrzeb zespołu.
Z jakiegoś powodu “retro” jest najbardziej znienawidzonym rodzajem
spotkań. Dlaczego? Myślę, że wynika to z wyuczonej bezradności. Zespół nie
wierzy, że coś się może zmienić. Otrzymuje on teksty w stylu “nie da się”,
“tak już tutaj jest” itd. Szczególnie wtedy łatwo jest o dalszy rozwój patologii.

Michał Mazur
Senior Java Developer

32
 TEMAT NUMERU

Justyna Szatan

Agile i jego twarze

Jak mawia Anthony Robbins: “sposobem podejmowania lepszych

decyzji jest podejmowanie ich częściej!”. To idealnie obrazuje styl
zwinnego zarządzania znany jako słynny Agile. Przygotowałam dla
Ciebie pigułkę wiedzy o Agile i różnych obliczach zwinnego zarzą-
dzania procesami.

Początek rewolucji
Na początku 90. lat technologia prężnie się rozwijała, co przełożyło się
na wzmożoną pracę programistów. Stosowali kaskadowe podejście do
zarządzania projektami Waterfall, który sprawdzał się na liniach produk-
cyjnych.

Niestety w przypadku IT szczegółowa analiza przypadku, przygotowanie

planu działania, dostosowanie do wymagań klienta i wdrożenie tych prac,
zajmowało średnio 3 lata. Dla biznesu to trwało zdecydowanie za długo,
dlatego programiści poszukiwali innych rozwiązań dla IT.

Konfucjusz najwyraźniej zainspirował specjalistów IT słowami: “nieważne

jak wolno dążysz do celu, ważne, że się nie zatrzymujesz”, ponieważ w myśl
rodzącej się koncepcji zwinnego zarządzania projektami przyjęli zasadę, że
lepiej dostarczyć klientowi 80% gotowej i sprawnej aplikacji w ustalonym
czasie, niż opóźniać cały projekt, jak się coś po drodze wysypie.

33
 TEMAT NUMERU

Czym jest Agile?

W 2001 r. w lutym powstał Manifest Agile, czyli zbiór 12 zasad i 4 wartości,
które są wspólne dla zwinnego zarządzania projektami. Tak narodził się
paradygmat filozofii Agile, w myśl której działamy do dziś.

Opiera się na 4 głównych filarach:

1. działające oprogramowanie ponad
dokumentację
2. elastyczność ponad ślepe dążenie
za procesem
3. współpraca z klientem powinna wykraczać
ponad formalności
4. ludzie i komunikacja są nadrzędne
nad procesami i narzędziami

12 założeń zwinnego programowania:

satysfakcja klienta jest priorytetem,
otwartość na zmiany - zmienność działań świadczy przecież o płynności
podejmowanych decyzji,
płynne i częste dostarczanie działającego oprogramowania
- Konfucjusz ;),
praca zespołowa,
wsparcie zespołu produkcyjnego - zadbaj o ich komfort, środowisko
pracy i niezbędne materiały, by mogli się skupić na właściwej robocie,
komunikacja to podstawa - spotkania są najlepszą formą przepływu
informacji,
działające oprogramowanie jako miara postępu prac,
zrównoważony rozwój projektu to równe tempo pracy w teamie,
zwinność to równowaga w rozwijaniu produktu,
rozsądne planowanie pracy poprzez ustalanie priorytetów i kolejność
działań - np. z wykorzystaniem zasady MoSCoW,
samoorganizacja zespołów - pozwól im wybierać style pracy i najlepsze
narzędzia,
kontrola realizacji procesów - tzw. sprinty, by ocenić aktualny stan,
przeszkody i potrzebne zmiany.

34
 TEMAT NUMERU

źródło: AgileAdept
W teorii Agile umożliwia podniesienie efektywności pracy całego zespołu
oraz dostarczenie produktu o najwyższej jakości. W praktyce wymaga to
umiejętnego zarządzania projektem, stałej analizy sytuacji i subtelności, by
zespół miał poczucie prowadzenia całym procesem.

Z tego względu Agile uchodzi za Święty Graal zwinnego zarządzania pro-

jektami, ponieważ wymaga zaangażowania i współpracy wielu zespołów z
różnych dziedzin do osiągnięcia wspólnego celu - działającego produktu,
który usatysfakcjonuje klienta.

Inne zwinne metody pracy

Według Walta Disneya, aby osiągnąć sukces, potrzebujemy aż 4 składników:
myślenia, wiary, marzeń i odwagi. Brzmi znajomo? Agile jest wszędzie — ma
różne oblicza i działamy zgodnie z tymi założeniami na co dzień. Po prostu
nie zdajemy sobie z tego sprawy, dlatego podrzucam ciekawe alternatywy.

Inne oblicza zwinności:

Scrum - często mylony z Agile, a w rzeczywistości to ramy postępowania
ukierunkowane na współpracę.
Lean Software Development - metodologia biznesowa, której celem jest eli-
minacja marnotrawstwa i optymalizacji procesów według klucza potrzeb klienta.
Kanban - czyli metoda zarządzania powyższym procesem Lean wizualizo-
wana na tablicach typu: to do, in progress, done itd.
Programowanie Ekstremalne (XP) - metoda wykorzystywana w mnie-
jszych i średnich zespołach developerskich, która skupia się na aspektach
technicznych, czyli dobrych praktykach programowania.

35
 TEMAT NUMERU

Feature-driven development (FDD) - to składowy model manifestu Agile,

ponieważ łączy tradycyjne aspekty planowania działań z wyprzedzeniem ze
zwinnymi praktykami iteracji i przyrostowego dostarczanie produktów.
Dynamic systems development method (DSDM) - idea tworzenia produk-
tu z gotowych komponentów, która ewoluowała do AgilePF - Agile Project
Framework.
Crystal - skupia się na interakcjach ludzi w zespole ponad sztywną
metodologią pracy. Podzielono ją na 7 kategorii (kolorów) zależnie od skali
projektu i wielkości teamu, który go realizuje.

Te przykłady to wierzchołek góry lodowej. W biznesie (szczególnie wśród

kadry kierowniczej i wyższego zarządu) najczęściej spotykany jest PRINCE2®
- międzynarodowy standard zarządzania projektami. Jest dobrym punktem
wyjścia do zrozumienia metodologii Agile.

Dodam, że w naszym Badaniu Społeczności IT 2022 wśród ankietowa-

nych PM, PO i Scrum Masterów najpopularniejszą odpowiedzią była meto-
dyka Scrum - natomiast każda firma wybiera najlepsze dla siebie rozwią-
zanie.

36
 TEMAT NUMERU

Jesteś wzrokowcem? Ja tak, dlatego polecam przyjrzeć się rozwojowi filozofii

Agile w najróżniejszych odsłonach w grafie przygotowanym przez Delloite.

źródło: Delloitte
Wizualna pigułka zwinnego zarządzania projektami tutaj:
(https://bulldogjob.pl/files/6e673cdba66e95fb6e61/graf-metod-agile-delloite)

Powodzenia we wdrażaniu go do swojego codziennego życia.

Justyna Szatan
Content Specialist
justyna.szatan@bulldogjob.pl

37
 TEMAT NUMERU

Adam Kukołowicz

To nie był prawdziwy Scrum!

Czyli, dlaczego programista
nie lubi Scruma

Scrum to najbardziej popularny framework do zarządzania projek-

tami IT. Żeby sprawdzić tę tezę, podsumowałem dane z ofert pracy na por-
talu bulldogjob.pl, gdzie można wpisać informacje o metodyce prowadze-
nia projektu. Okazało się, że spośród firm, które skorzystały z tej możliwości,
niemal 85% używa Scruma. I nic dziwnego, metodyka ta jest zwięźle
opisana na ledwie kilkunastu stronach, dodatkowo bardzo mocno stawia na
tworzenie wartości, a o to przecież chodzi w tworzeniu oprogramowania.

Trzeba tu dodać, że przeciętnemu programiście najczęściej jest wszystko

jedno, w ramach której metodyki pracuje, o ile wie, co ma robić, będzie to
w miarę interesujące i będzie zauważać efekt swojej pracy. Wydaje się, że
Scrum nie powinien mieć zbyt wielu przeciwników.

Gdzie więc został popełniony błąd, skoro całe rzesze programistów nie lubią
lub mają ambiwalentne uczucia wobec Scruma? Oczywiście zwolennicy me-
todyki mają w takich wypadkach jedną sprawdzoną odpowiedź: “to nie był
prawdziwy Scrum”. Z jednej strony to hasło jest używane niemal za każdym

38
 TEMAT NUMERU

razem, gdy Scrum nie zadziała, z drugiej jednak jest wiele przypadków, gdzie
jest coś na rzeczy. Okazuje, że te z pozoru proste reguły sprawiają sporo prob-
lemów w implementacji. Cierpi w tej sytuacji zespół scrumowy, który składa
się głównie z developerów.

Sam Scrum z punktu widzenia

członków zespołu wymaga dużego
zaangażowania, zarówno na poziomie
spotkań, kodowania, jak i innych
codziennych obowiązków. Jeżeli więc
Scrum nie działa tak, jak to reklamują
zwolennicy metodyki, to jest to
odczuwalne dla każdego programisty.

Proces, który miał służyć tworzeniu wartości, staje się przeszkodą w produk-
tywnej pracy. Spotkania się dłużą, bo niewiele wnoszą, backlog sprintu,
zamiast wprowadzać pewność co do tego, co należy dowieźć, wprowadza
złudne poczucie kontroli. Dostarczane są nieoszlifowane moduły, które
często stają się przyczyną awarii i błędów, a w dłuższej perspektywie mogą
stać się legacy code.

Zwykle na tego typu objawy skarżą się programiści, którzy za Scrumem nie
przepadają. Warto jednak przyjrzeć się, dlaczego dochodzi do takich sytuacji.

Złe zastosowanie

Scrum został stworzony z myślą o projektach, które służą rozwiązaniu

złożonego problemu, za pomocą rozbicia go na mniejsze części, które można
inkrementacyjnie dostarczać, przy okazji ucząc się i dostosowując plan do
realnych potrzeb. Nie pasują do niego projekty utrzymaniowe czy też pro-
jekty realizowane w stabilnym środowisku, w którym sposób rozwiązania
naszego problemu najprawdopodobniej się nie zmieni podczas trwania pro-
jektu. W takich przypadkach Scrum staje się pustym procesem, zestawem
ceremoniałów, które nie przekładają się na tworzenie wartości. Tym samym

39
 TEMAT NUMERU

z punktu widzenia programistów staje się zbędnym dodatkiem, a z punk-

tu widzenia managera może wydłużyć projekt i podnieść koszty całego
przedsięwzięcia.

Skupienie na procesie, a nie produkcie

Łatwo podążać ślepo za procesem, trudniej bezustannie myśleć o tym, jak

Ł
wykorzystać proces, by dostarczyć jak najlepszy produkt. I to bardzo mocno
w
widać w przypadku Scruma, który niestety w wielu implementacjach jest
synonimem organizowania pracy za pomocą JIRY i paru spotkań w tygod-
niu. Scrum w zamyśle jest inkrementacyjny, zmienia się wraz z rozwojem
produktu, gdy rozpatrywany jest w formie procesu łatwego do powtarzania
kolejne sprinty są jak akcja filmu “Dzień Świstaka”, proces jest monotonny
i niewiele wnosi.

Źle zrozumiany Scrum, w którym proces jest ważniejszy niż cel może przełożyć
się na wiele niekorzystnych zjawisk. Na przykład zmniejszenia priorytetu dla
dużych i ważnych przedsięwzięć, bo łatwiej jest zapchać sprint drobnymi
zadaniami. Może wystąpić presja na dostarczanie kolejnych funkcji, mimo, że
produkt wymaga bardziej poprawek bugów czy refaktoryzacji. W takich wy-
padkach wszystkie scrumowe metryki mogą wyglądać idealnie, ale produkt
będzie cierpieć, a w developerach może pojawić się frustracja.

Słaby Product Owner i/lub Scrum Master

Scrum definiuje 3 role: Product Ownera, Scrum Mastera i developerów. Dwie

pierwsze są kluczowe dla poprawnie działającego Scruma. Developerzy
oczywiście są równie ważni, ale mają sporą przewagę - działają w grupie,
wiele decyzji podejmują wspólnie, tym samym błąd jednostki nie ma tak
dużego wpływu na całość. Łatwiej wyłapać nieprawidłowości, poprawić je
i zadbać o to, by nie powtórzyły się w przyszłości.

Natomiast Product Owner czy Scrum Master (zakładając, że ta rola nie jest
rotująca), to pojedyncze osoby, które mają bardzo odpowiedzialne zadania.
Weźmy Product Ownera - odpowiada za definiowanie i komunikowanie wizji
oraz celu produktu, utrzymywanie backlogu, a także komunikowanie jego
elementów w taki sposób, żeby były dla wszystkich zrozumiałe. Scrum Master
natomiast musi prowadzić wszystkich uczestników tak, by proces zachodził
prawidłowo, dając zdrowe przyrosty.

40
 TEMAT NUMERU

Jeżeli którakolwiek z tych osób będzie zawodzić, to stwarza okazję, by

w Scrumie pojawiły się patologie. Dodatkowo nawet odpowiednia osoba,
bez jakościowego i stałego feedbacku od zespołu może mieć problem z dob-
rym wypełnianiem swojej roli.

Niesamodzielny lub stłamszony zespół

Jednym z głównych założeń Scruma jest samowystarczalność i samoor-

ganizacja zespołu scrumowego. To zespół decyduje kiedy i jak robi zadania
w ramach sprintu, uczestniczy też w ich definiowaniu. Jeżeli Product Owner,
Scrum Master czy inny manager decyduje o tych kwestiach, to zabija istotę
Scruma i zasadność obecności zespołu scrumowego na spotkaniach scru-
mowych. W takich warunkach efektywniej byłoby po prostu dostarczyć listę
tasków do zrobienia.

Scrum, pomimo złudnej prostoty, jest metodyką trudną w zastosowaniu,

wymaga dużo świadomości i autorefleksji od Product Ownera oraz Scrum
Mastera, umiejętnego pokierowania zespołem scrumowym. Sukces jest
możliwy, co potwierdza wiele moich rozmów z programistami z różnych
organizacji, którzy Scruma naprawdę lubią. Wśród plusów, które widzą, jest
skupienie na konkretnym celu i branie za niego odpowiedzialności.. Niewiele
osób zdaje sobie sprawę, że dojście do takiego poziomu, to efekt włożenia
sporej pracy.

Adam Kukołowicz
CTO Bulldogjob
adam.kukolowicz@bulldogjob.pl
 ZAWÓD PROGRAMISTA

JavaScript
Developer
potraktuj ten zestaw jako narzędzie do stworzenia
persony JavaScript Developera
stwórz na jego podstawie swoje wyobrażenie
specjalisty IT
ówisz
naszym celem jest pomóc Ci zrozumieć, do kogo mówisz

Kim jest?
płeć: mężczyzna
wiek: najczęściej 25 - 29 lat
pracuje: React, Angular, Vue.js, Node.js

Co umie?
zajmuje się frontendem aplikacji webowych, projektowaniem
interfejsów użytkownika i opracowywaniem API umożliwiających
komunikację z backendem aplikacji

Ile zarabia?
na UoP zarabia średnio 7028 PLN netto na fakturze
Na B2B zarabia średnio 15 994 PLN netto na fakturze
Na UoZ/UoD zarabia 6063 PLN netto na fakturze

Gdzie go znajdę?
w sieci
na blogach branżowych
na LinkedIn
na grupach FB

ŻRÓDŁO
Badanie Społeczności IT 2022 Bulldogjob, bulldogjob.pl/it-report/2022

42
 ZAWÓD PROGRAMISTA

7 PYTAŃ
REKRUTACYJNYCH
DLA JavaScript
Developera

1. Co to jest DOM?

2. Czym jest pętla zdarzeń w JavaScript?

3. Czym jest IIFE?

4. Jak możesz udostępniać kod między plikami?

5. Jakich konstrukcji językowych używasz do iteracji

po elementach tablicy i właściwościach obiektów?

6. Jakie rezultaty będzie miał ten kod?

7. Jak opróżnić tablicę?

Odpowiedzi na pytania znajdziesz na #readme bulldogjob

https://bulldogjob.pl/readme/javascript-developer-pytania-rekrutacyjne-odpowiedzi

43
 LIFESTYLE

Pełnia Twoich Możliwości / Brand Stulberg, Steve Magnuess

Zawsze lubiłam chwytać kilka srok za ogon, przez co brałam na siebie zbyt
dużo zadań. Kalendarz pękał w szwach, a ja planowałam dodatkowo tren-
ing, naukę, studia weekendowe - bo przecież jakoś dam radę. Dostałam
recenzowaną książkę na szkoleniu z efektywności. Jej treść szybko sprowadziła
mnie na ziemię i pokazała wartość odpoczynku w realizacji swoich celów. Czyta
się ją lekko i przyjemnie. Jest podzielona na tematyczne podrozdziały, a kluc-
zowe myśli są zaznaczone w ramkach. Dowiesz się z niej, jak oszlifować swój
potencjał, by ten proces był łatwy i przyjemny. Każda dawka wiedzy kończy się
prostym zestawem ćwiczeń, a autorzy opierają swoje tezy na badaniach nau-
kowców z różnych dziedzin. To świetna lektura dla osób, które rozpoczynają
swoją przygodę ze zmianą codziennej organizacji pracy. Dla tych, którzy mają
pojęcie w tym temacie, będzie dobrym uporządkowaniem wiedzy. Jest świetnie
przemyślana pod kątem rozdziałów i oprawy graficznej. Jej główne przesłanie
można zamknąć w tych słowach: obciążenie + odpoczynek = rozwój. To rów-
nanie sprawdza się zawsze.
Adrianna Teszner, Marketing Specialist, Bulldogjob

Realizm kapitalistyczny / Mark Fisher

„Realizm kapitalistyczny” to pozycja zdolna wstrząsać umysłami i wywracać
światopoglądy. Stanowi zredagowaną kompilację wpisów blogowych
nieżyjącego już Marka Fishera, który w ciągu ostatnich dekad jako jeden z naj-
bardziej przewrotnych myślicieli atakujących neoliberalny porządek nie unikał
mierzenia ostrza swojego intelektu w same podstawy kapitalizmu. Fisher stawia
diagnozę, że dziś nie mamy już do czynienia z kapitalizmem czy nawet neolibe-
ralizmem, lecz z realizmem kapitalistycznym – ideologią wyrosłą na zrębach
skompromitowanego systemu gospodarczego, która stanowi dla ludzkiej cywi-
lizacji egzystencjalne zagrożenie w stopniu nie mniejszym niż dwudziestowiec-
zne ideologie totalitarne. Katastrofa klimatyczna, bezrefleksyjna maksymali-
zacja zysków przez najbogatszych przy jednoczesnym pogarszaniu się jakości
życia całej reszty, skrajna komercjalizacja w zasadzie każdego obszaru życia,
kult indywidualności i egoizmu, wyzysk, a nawet rozwój przemysłu farmaceu-
tycznego w kierunku masowej popularyzacji leków przeciwdepresyjnych -
wszystkie te mechanizmy Fisher skrupulatnie i z niebywałą erudycją opisuje
w swojej pracy.

Maciek Olanicki, Technical Content Writer, Bulldogjob

Potęga pozytywnego przywództwa. Dobry szef, lepszy pracownik / Jon Gordon

Nikogo nie powinno dziwić, że zespoły zmotywowane z fajnym vibe’em
osiągają znacznie lepsze wyniki. Dostajesz awans? Masz przewodzić zespołem,
ponieważ “masz do tego predyspozycje”. Czy Twoja wiedza jest wystarczająca?
Widziałam wiele dowodów na to, że dobre chęci nie zawsze wystarczą. Dlatego
proponuje Ci tę książkę, która zawiera liczne case study, historie i cenne wska-
zówki. Niech posłużą Ci za drogowskaz, jak z przełożonego zostać prawdziwym
liderem. Kwintesencją tej pozycji niech będzie cytat: “przewodzić należy z wia-
rą, nie z lękiem”. Jon Gordon umocnił mnie w przekonaniu, że dobry zespół
nie istnieje bez dobrego przywódcy. Natomiast być liderem potrzebujesz
wiedzy, doświadczenia, predyspozycji, chęci i ludzkiego podejścia. Dlatego
uważam, że jest to lektura obowiązkowa dla wszystkich (przyszłych lub obec-
nych) managerów, liderów, dyrektorów i wszystkich tych, których praca wiążę się
z zarządzanie ludźmi.

Paulina Kordeusz, Customer Care Team Leader, Bulldogjob

44
 DO WODY

45
Think IT Magazyn HR
nr 3 / wrzesień 2022

Redakcja
tel. +48 530 828 515
e-mail: marketing@bulldogjob.pl
www.bulldogjob.pl

Redaktor naczelna
Iwona Tur
iwona.tur@bulldogjob.pl

Zespół redakcyjny
Gabriela Rybińska
gabriela.r@bulldogjob.pl
Justyna Szatan
justyna.szatan@bulldogjob.pl

Autorzy
Natalia Białek, Martyna Mroczka,
Marta Rydzanicz, Anna Ordyńska,
Michał Mazur, Maciej Olanicki,
Mateusz Fiedosiuk, Adam Kukołowicz,
Adrianna Teszner, Paulina Kordeusz
i Justyna Szatan

Dyrektor artystyczny
Grzegorz Głogowski
grzegorz@profil-art.pl

Korekta
Paulina Wyszyńska-Górecka
paulina.wyszynska@bulldogjob.pl

ISSN 2720-7544