Kim jest Product Engineer i dlaczego warto nim zostać

Trwa “cyfrowa transformacja”. Coraz częściej o przewadze firm na rynku stanowi sprawność w tworzeniu i integracji oprogramowania. Każdy departament w dzisiejszych firmach zabezpiecza w budżecie coraz więcej środków na prace programistyczne – a to oznacza eldorado dla firm świadczących usługi rozwoju oprogramowania i dla samych koderów. Ale ten raj jest solą w oku ludzi biznesu. Firmy, dla których wytwarzanie oprogramowania to studnia bez dna, poszukują sposobów, żeby ten koszt obniżyć. I takie sposoby znajdują. Czy zatem długoterminowo możemy się spodziewać rynku pracy IT jakiejś (r)ewolucji? Jakie będą konsekwencje dla naszych rodzimych programistów i jak można ich uniknąć?

Michał Sędzielewski. Współzałożyciel software house’u rspective i platformy Voucherify. Absolwent Politechniki Śląskiej. 10 lat w IT pozwoliło mu na poznanie branży z różnych stron. Obejmował role programisty, team ledera, project managera, handlowca i marketera. Współorganizator Śląskiego Zakładu Oprogramowania — comiesięcznych spotkań poświęconych tworzeniu oprogramowania i zarządzania produktem.

---

Entry level jobs zagrożone

To już się dzieje. Niewidzialna ręka rynku nieprzerwanie kombinuje, jak obniżyć koszt rozwoju i utrzymania oprogramowania. Obniżanie wydatków dokonuje się na dwóch płaszczyznach.

Prostsze technologie

Nowe technologie sprawiają, że rozwiązywanie problemów biznesowych staje się szybsze i tańsze. Ostatnia dekada to prawdziwy rozkwit rynku Software as a Service (SaaS), czyli cyfrowych produktów, hostowanych w chmurze i rozliczanych w modelu subskrypcji (pay as you go). Niski koszt instalacji oraz utrzymania usługi w porównaniu do rozwiązania tworzonego od zera zachęcił biznes do porzucania własnej infrastruktury na rzecz rozwiązań w chmurze.

Rząd oszczędności jest w tym przypadku tak duży, że nawet przykładające szczególną wagę do bezpieczeństwa danych firmy, decydują się do porzucania rozwiązań budowanych in-house i wybierają SaaS. Potwierdzeniem tego trendu jest przeniesienie “do chmury” takich gigantów jak MS Office. Innym dowodem tego trendu są wyniki firmy Salesforce (ponad 30 tys. pracowników i 8 miliardów dolarów przychodu) — jednego z pierwszych, chmurowych CRMów.

Przykład Salesforce jest bardzo trafny w tym przypadku, bo pokazuje jeszcze jeden kierunek na rynku tworzenia softu. Trend, o którym spora część developerów nie wie.

SF nie byłby miliardowym przedsiębiorstwem, gdyby dostarczał tylko dashboard automatyzujący sztywno określoną liczbę zadań w dziale sprzedaży. Twórcy SF zauważyli, że poza kilkoma stałymi elementami, każdy dział sprzedaży ma inne procesy i korzysta z innych narzędzi. Taki układ wciąż wymusza spore inwestycje szczególnie w kierunku oprogramowania szytego na miarę.

Salesforce wyszedł do swoich klientów z ofertą ścięcia tych kosztów poprzez wbudowanie w platformę własnego środowiska programistycznego. Stworzyli własny język programowania (APEX), framework do budowania UI (Lightning Experience), oraz rozbudowane REST API z webhookami do komunikacji ze światem zewnętrznym. Taki zestaw pozwala oprzeć działanie całego działu na jednej platformie. Wszystko za ułamek ceny, którą trzeba wydać na zbudowanie i utrzymanie dobrze “naoliwionego” CRMa od zera.

Na tłumy klientów żądnych takich oszczędności nie trzeba było długo czekać. Popyt i tym samym wysokie zarobki sprawiły, że liczba Salesforce developerów zaczęła rosnąć lawinowo.

O szybkości wytwarzania softu biznesowego Salesforce’a przekonaliśmy się w kilku naszych projektach. Jeśli jesteście ciekawi, jak za pomocą tej platformy tworzyć aplikację w błyskawicznym tempie (np. bez zewnętrznej bazy danych), zapraszam do lektury naszych artykułów 1 i 2).

Oferta redukcji kosztów IT okazała się żyłą złota. Idąc tym tropem Salesforce postanowił przejąć Heroku — platformę do hostowania i skalowania aplikacji w modelu PaaS. Hosting to właśnie kolejny obszar, który generuje biznesowi wysokie rachunki do zapłacenia. Obszar, o który walczy coraz więcej firm. Np. Amazon, które oferuje już nie tylko przestrzeń dyskową i moc obliczeniową (IaaS), ale ponad 100 usług, spośród których duża część pokrywa właśnie obszar “zarządzania chmurą”.

Amazon zaczyna też podbijać teren produktów, które pomagają firmom zmniejszać nakłady na tworzenie własnego kodu. Są nimi rozwiązania API-first SaaS, czyli funkcjonalne klocki (tzw. building blocks), z których możemy zbudować szyte na miarę rozwiązanie. Taki produkt często jest udostępniany za pomocą REST API oraz dashboardu do administracji. Tego typu rozwiązania to kompromis pomiędzy pisaniem całego oprogramowania in-house (duży koszt), a rozwiązaniem pudełkowym (niedopasowana funkcjonalność).

Poza usługami AWS rynek zapełnił się takimi produktami jak Stripe (płatności), Twilio (SMS i rozmowy telefoniczne), Contentful (CMS), Algolia (wyszukiwarka), auth0 (uwierzytelniania i zarządzanie użytkownikami), Shippo (dostawa paczek), Layer (chat/wiadomości), SendGrid (Email) i wiele innych. Zapotrzebowanie na tego typu produkty okazało się tak duże, że kilkoro przedstawicieli dojrzało do wejścia na giełdę.

SaaS, PaaS i IaaS pozwalają firmom na przyspieszenie budowania aplikacji biznesowych oraz obniżają tzw. Total Cost of Ownership, czyli wszystkie koszty związane ze stworzeniem i późniejszym utrzymaniem systemu.

To wszystko oznacza, że dzięki nowym technologiom firmy potrzebują mniej programistów. Ale również to, że ci programiści potrzebują mniej doświadczenia. Łatwiej jest wywołać endpoint z API Algolia niż budować przyjazny dla użytkownika system do full-text search od zera, prawda?

Łatwiejsza nauka programowania

Dzięki lepszym narzędziom programistycznym, szybciej rozwija się również rynek samej nauki programowania. Po pierwsze niższy próg wejścia oraz darmowe, interaktywne kursy pozwalają uczyć się podstaw programowania na własną rękę. W jednym z ostatnich podsumowań ankiety StackOverflow, ponad 40% respondentów przyznało się do bycia samoukiem. Coraz więcej stanowisk w branży nie wymaga wyższego wykształcenia z informatyki czy pokrewnych dziedzin.

Tę możliwość wykorzystują teraz szkoły programowania. Obiecują, że w okresie 6-9 miesięcy są w stanie przygotować kandydata do pracy w zawodzie. W wielu przypadkach taki model bardzo dobrze się sprawdza. Taka ścieżka nauki do złudzenia przypomina pierwsze kroki studenta informatyki, który już na 2. roku studiów zostaje wciągnięty na stanowisko juniorskie — nie mając jeszcze tworzenia aplikacji biznesowych w planie zajęć.

Łatwość nauki programowania oraz wysokie pensje zachęcają ścisłowców, którzy nie wybrali informatyki, do zmiany kariery. Matematycy, ekonomiści, mechanicy, a nawet absolwenci nauk przyrodniczych coraz chętniej próbują się wedrzeć do programistycznego eldorado — i robią to coraz skuteczniej.

Dzisiaj nauka programowania zaczyna się też dużo wcześniej. Dzięki takim organizacjom jak code.org kodowanie pojawia się już programach dla przedszkolaków. To między innymi wynik starań gigantów technologii jak FB, MS czy Google, którzy inwestują spore środki w rozwijanie przyszłościowych umiejętności już wśród najmłodszych. Jednak w niedawnym artykule Guardian donosi, że edukacyjne akcje wielkich graczy mogą wynikać z nie do końca szczytnych pobudek. Autor twierdzi, że długoterminowo zależy im na obniżeniu wynagrodzenia za pracę programisty poprzez zwiększenie podaży jego umiejętności.

Już dziś liczba “zasobów programistycznych” wzrasta. Konsekwencją będzie spadek wartości wynagrodzenia. Tak już się przecież stało w przypadku innych zawodów. Grafik DTP, prawnik, bankier, spec od zarządzania i marketingu — te zawody pod koniec lat 90. ubiegłego wieku uznawano za intratne fuchy. Dziś widzimy, że automatyzacja oraz zwiększenie podaży zmieniły ten stan rzeczy. Czy zawód programisty w Polsce stoi przed podobną transformacją? Przyjrzyjmy się rodzimemu rynkowi IT.

Outsourcing

Programistyczna mapa Polski jest usłana firmami outsourcingowymi. Nie trzeba długo wyjaśniać, dlaczego tak jest — jesteśmy 3-5 krotnie tańsi niż koledzy po fachu na zachodzie jednocześnie dostarczamy usługi na tym samym poziomie. Charakter projektów w takich firmach w dużej mierze nie wymaga wyspecjalizowanych profili, w większości przypadków koderzy na poziomie entry level są w stanie dostarczyć rozwiązania o dobrej jakości i bez większych opóźnień.

Trafią się rzecz jasna outsourcowane perełki, w których zespoły dostają większą autonomię — np. kiedy klientem jest startup czy jednostka naukowa. Niemniej, uogólniając, większość aplikacji pisanych przez firmy outsourcingowa sprowadza się do mniej lub bardziej złożonych “CRUDów”. Dzieje się tak dlatego, że z reguły firmy nie przenoszą projektów kluczowych dla biznesu na zewnątrz.

Jak zatem wygląda typowa ścieżka kariery przeciętnego programisty w Polsce?

1. Rozpoczęcie pracy w firmie outsourcingowej jeszcze na studiach.

2. Dołączenie do pierwszego projektu, “łapanie” podstawy fachu oraz pracy w grupie.

3. Potem kilka przejść pomiędzy zespołami, zdobywanie szerszego doświadczenia w zakresie inżynierii oprogramowania i specyficznych technologii.

4. Ewentualna przesiadka do innej firmy outsourcingowej, która:

• zapewnia lepszą płacę,
• mami projektem typu greenfield z nowiusieńkimi technologiami na pokładzie.

Na koniec powrót do punktu 3.

Wciąż są to jednak te same niskopriorytetowe projekty wymagające niewielkiego doświadczenia. Potwierdzają to przypadki z projektów, w których brałem udział. Okazywało się, że osoba z dwuletnim stażem radziła sobie w nich równie dobrze, co osoba z 5 letnią praktyką. Prawdą jest, że starsi stażem mają w swojej skrzynce z narzędziami zdecydowanie więcej frameworków i bibliotek, przez co wykonują niektóre zadania szybciej i lepiej. Natomiast często wiele z tych technologii ma krótki okres ważności i przestaje być przydatna po zmianie projektu.

Mamy więc w Polsce sporą pulę specjalistów, którzy pomimo wieloletniego stażu wciąż piastują stanowiska entry level “klepiąc” proste CRUDy czy parsery. A to właśnie tego typu zadania biznes chce zautomatyzować.

Co się stanie, kiedy zmieniająca się sytuacja geopolityczna (rosnące wynagrodzenia w Polsce, wygaszanie konfliktu na Ukrainie, wstąpienie nowych krajów do UE) oraz galopujący rozwój automatyzacji tworzenia oprogramowania naruszy mocną pozycję outsourcingowego eldorado w naszym kraju? Co zrobić, żeby nie zostać na podwórku entry level na zawsze? Odpowiedzi poszukajmy u naszych kolegów po fachu na zachodzie. Tak — u tych samych, którym sami odebraliśmy część juniorskich posad.

Inna ścieżka kariery

Ale zanim o tym jeszcze kilka słów o ścieżce kariery w świecie outsourcingu. Generalnie są dwie. Albo, tak jak wspomniałem, przeciętny programista skacze pomiędzy projektami typu CRUD, zdobywając wiedzę o coraz nowszych technologiach, albo idzie w tzw. management. Może się wydawać, że ta druga droga jest wyjściem z pułapki “entry level job”. Że to furtka, którą da się uciec przed karuzelą prostych, nudnych, często leciwych aplikacji biznesowych. Ja uważam, że nie jest.

Management w projektach outsourcingowych często sprawdza do zarządzania ludźmi. Choć to ważna funkcja, po wyoutsourcowanej stronie projektu sprowadza się niestety do roli brygadzisty na budowie. Mamy tutaj proste, administracyjne zadania typu załatwianie sprzętu, klepanie urlopów i spisanie prostego podsumowania dla kierownika projektu.

Praca poniżej swoich umiejętności i ambicji prowadzi do demotywacji, i długoterminowo do wypalenia. Znam wielu inżynierów, którzy szukając swojej ścieżki rozwoju trafili do leadershipu i którzy z perspektywy czasu negatywnie oceniają swój wybór. Teraz daliby się pokroić za możliwość powrotu do spokojnego zamykania tasków w Jirze. Niestety na to często jest za późno.

Duża część wynagrodzenia w tak pojętym managemencie bierze się ze znajomości firmy. Żeby utrzymać dobrze prosperujący biznes outsourcingowy, warto zapłacić za ludzi, którzy znają strategię, narzędzia i ludzi. Wiedza ta jednak przestaje być użyteczna, jeśli taki manager zmieni firmę.

Ale my nie o tym — mieliśmy omówić, jaką ścieżką awansu kroczy przeciętny programista na zachodzie.

Oferty pracy z

Dark Matter Programmers

Poza procentem osób, które zajmują się promowaniem technologii lub żyją z konsultingu/szkoleń, większość naszych zachodnich kolegów należy do grupy Dark Matter Programmers. Termin ukuty przez Scotta Hanselmana odnosi się do koderów, którzy wykonują swoją robotę bez “jarania” się migoczącym światem nowych technologii, twittera, konferencji i blogów programistycznych. Niewidoczni w “internetach”, ale skupieni na dostarczaniu dobrej jakości softu na czas. Cytując Scotta “They use mature products that are well-known, well-tested and well-understood. They aren’t chasing the latest beta or pushing any limits, they are just producing.” Inaczej ujmując, uprawiają Getting Shit Done™.

Jak wygląda ścieżka awansu przeciętnego DMP w krajach rozwiniętych? Trafia jako junior developer do firmy produktowej lub konsultingowej. Tam zdobywa szlify pod okiem doświadczonego zespołu. Uczy się technologii, cyklu życia oprogramowania, procesu wytwarzania softu — i tak przez kilka lat. Brzmi zupełnie tak samo jak w przypadku adeptów kodowania w firmie outsourcingowej z obszaru EMEA.

Różnica polega na tym, że ten pierwszy poznaje równocześnie jakąś dziedzinę biznesową. Niezależnie czy jest to e-commerce, transport, hardware, finanse czy gry — zdobywa wiedzą na temat działania biznesu i firmy.

Dla porównania, programista w wyoursourcowanym projekcie, nie dość, że nie ma możliwości poznania procesów biznesowych dogłębnie, to jeszcze kilka razy w ciągu kontraktu zmienia zespół oraz często branżę. Pomimo tego, że takie przejście pozwoli mu zapoznać się z nowymi technologiami i mnogością technik tworzenia softu, uniemożliwia stanie się ekspertem domenowym. A na tym właśnie buduje się swoją wartość i drogę do awansu na zachodzie. Dlaczego tak jest?

Nie tylko kodem

Ano dlatego, że pisanie kodu to zazwyczaj mała część działania zarówno biznesu, jak i samego dostarczania softu. Jak pokażę w drugiej części tego artykułu, poza kodowaniem ważna jest umiejętność:

• ustawiania priorytetów dla zadań,
• dokonywania analizy cost vs. benefit dla danego rozwiązania,
• rozwiązywania problemów przy użyciu zewnętrznych narzędzi,
• bezpiecznego dla ciągłości biznesu deployowania,
• oraz zbierania i analizy danych.

Sięgnijcie do swojej pamięci, czy zdarzyło Wam się tak, żeby błąd programisty położył cały biznes lub chociaż cały projekt? Takie rzeczy zdarzają się bardzo rzadko.

Natomiast często słyszy się o bankructwach spowodowanych nietrafionymi inwestycjami w IT oraz prześcignięciem przez konkurencję. Takie rzeczy dzieją się nawet w firmach, których produktem jest software — warto tutaj przytoczyć postmortem RethinkDB, które przegrało wyścig z MongoDB.

Dlatego programista, który jest ekspertem domenowym, zna meandry prowadzenia biznesu i wie, jak szybko dostarczyć rezultat niekoniecznie za pomocą kodowania, jest dla biznesu na wagę złota. Mówimy o takim profilu product-oriented lub nazywamy product engineerem.

Product-oriented vs technology-focused

Spójrzmy na listę prezentującą podstawowe różnice pomiędzy programistą product-oriented i takim, z którego możemy spotkać w projektach outsourcingowych — nazwijmy go technology-focused.

Product-oriented

• wie dlaczego i za ile implementujemy rozwiązanie/feature,
• stara się rozumieć cele ludzi z innych departamentów, komunikuje się z nimi często,
• rozwiązuje problemy biznesowe różnymi narzędziami.

Technology-focused

• zna najnowsze frameworki, języki i narzędzia programistyczne,
• “nie po to kończyłem polibudę, żeby teraz rozmawiać z ludźmi”,
• 100% code coverage ( ͡° ͜ʖ ͡° ),
• Machine Learning zamiast dwóch ifów.

To rzecz jasna przerysowane porównanie. Dokładniej ujętą charakterystykę programisty typu product-oriented znajdziemy w artykule napisanym przez Engineering Manager Quora.

W tym miejscu trafna też będzie pewna anegdota: w jednym z poprzednich projektów pracowaliśmy nad systemem do zarządzania plikami multimedialnymi. Na pierwszy rzut oka prosta sprawa — ot, zwykły CRUD. Problemem jednak była synchronizacja danych pomiędzy bazami online i offline — klientem była firma oferująca rejsy wycieczkowe, która posiadała bazy danych z multimediami na lądzie i na statkach swojej floty.

Dlatego rozwiązanie zlecono dwóm firmom. Firma A — grupa konsultingowa z Niemiec, która projektuje systemy dla rynku multimediów. Firma B — software house z Polski. Plan był taki, że firma A robi design i zbiera wymagania, a firma B dostarcza kod. Po roku trwania projektu i pierwszych pomyślnych rezultatach, klient chce zaprezentować rozwiązanie spółce matce oraz całej, przynoszącej miliardy euro przychodu, grupie. Prosi obie firmy o przygotowanie stosownej prezentacji.

Firma A miała zająć się częścią odpowiadającą “dlaczego” rozwiązanie ma sens i jakim kosztem można je wdrożyć na pozostałe statki, z kolei firma B miała się skupić na części technologicznej.

Firma B przygotowała kilkudziesięcioslajdową prezentację, w której streściła technologie, patterny, podejście do zapewnienia jakości, rozszerzalności architektury, zasadności zastosowania frameworku Spring, rozwiązania problemu zbudowania relacji na nierelacyjnej bazie, której użyto do synchronizacji danych (CouchDB)… — materiał na świetną prelekcję na niejednej z polskich konferencji programistycznej.

Przychodzi dzień spotkania. Firma A kończy swoją część, pada kilka pytań ze strony interesariuszy. Firma B przechodzi przez slajdy i zachęca do zadawania pytań. Pada pierwsze, i jak się potem okazuje jedyne pytanie: “What is Spring?”

Okazuje się, że CTO spółki matki już od pierwszego, fundamentalnego slajdu, bo tam właśnie znalazł się Spring, nie wiedział, o czym w ogóle mówi firma B. Jak myślicie, kto został zaproszony do dalszych rozmów?

Jeśli chodzi o wybory na ścieżce kariery, product engineerowie mają jeszcze jedną wspólną cechę — starają trzymać się jednej branży. Niezależnie czy wybierają wejście do managementu w ramach tego samego pracodawcy, czy też zatrudniają się jako programista w innej firmie, budują doświadczenie w tej samej dziedzinie. Nie boją się również wybierać projektów typu brownfield, o ile zdobędą w nim dodatkowe punkty doświadczenia.

Podsumowując, product-oriented developer to osoba, która rozumie, że:

• produkt to coś więcej niż technikalia,
• pisanie software’u to koszt, który należy minimalizować,
• optymalizowanie kodu nie zawsze prowadzi do optymalizacji biznesu,
• są inne sposoby na zautomatyzowanie procesów w biznesowych niż kodowanie,
• dowiezienie działającego oprogramowania jest często ważniejsze niż wysoka (z inżynierskiej perspektywy) jakość kodu,
• tworzenie oprogramowania to nie tylko kodowanie, ale też rzeczy wymienione na tym obrazku:

Źródło: Wojtek Seliga / youtube.com

• w udanym projekcie softwarowym częściej wymaga się znajomości procesów z prawej kolumny,

Źródło: Wojtek Seliga / youtube.com

• dokładna estymacja i priorytetyzacja zadań jest bardzo ważna dla dobra projektu,

Opanowanie tych punktów wymaga sporego zaangażowania. Dlaczego zatem warto popchnąć swoją karierę w tym kierunku?

Profity “niezasobu”

Odpowiem kolejną anegdotę. W pewnym outsourcingowym projekcie mieliśmy (rzadką) okazję zbliżyć się do osób, których stanowiska zaczynają się od liter C- lub VP. Podczas spotkania po godzinach, opowiadali nam o swoich karierach.

Jeden z nich zaczynał jako programista kodujący na pierwszym modelu niemieckiego komputera. W trakcie kilkudziesięciu lat kariery przeszedł ścieżkę od junior developera do top managementu. Od zawsze jednak jako developer trzymał się tej samej branży rozwijając, poza umiejętnościami kodowania, wiedzę na temat funkcjonowania biznesu.

Inkrementując liczbę wypitych piw, przeszliśmy płynnie z tematu kariery na zainteresowania. Zapytacie pewnie, jakie hobby ma taki inżynier w zarządzie? Już odpowiadam: kupuje superszybkie samochody. Przede wszystkim ma słabość do używanych Ferrari. Wiecie, jak się kupuje używane Ferrari? Ja też nie wiedziałem. Otóż, Ferrari personalizuje fotel według wzrostu kierowcy. Dlatego żeby kupić dopasowane Ferrari, trzeba przejechać czasem pół Europy w poszukiwaniu osoby o tych samych paramsach. Ale Ferrari to nie jedyne maszyny w jego garażu.

Jego kolega, również ex-programista, jeździ “tylko” Seatem Leonem — tak w ogóle to rzadko potrzebuje samochodu, bo lata swoim samolotem.

Badanie przeprowadzone przez Hired pokazuje, że w Silicon Valley to właśnie product managerowie, a nie jak się powszechnie sądzi, programiści zarabiają więcej. To pokazuje, że programista, który zacznie gromadzić wiedzę o budowaniu produktu, zwiększa swoje szanse na wyższe wynagrodzenie. Ale przecież pieniądze to nie wszystko.

Jeśli potrafisz za pomocą technologii wycisnąć dla biznesu większy przychód lub też ściąć koszty, automatycznie stajesz się wartościową i, co za tym idzie, docenianą osobą.

Dostajesz sporo autonomii i dzięki temu możesz pracować według swoich zasad. A to należy do rzadkości w świecie outsourcingu. Na naszym podwórku widać sporo frustracji wywołanej pomijaniem w procesach decyzyjnych, co z kolei wynika właśnie z niezrozumienia, na czym zależy biznesowi i skupianie się nad inżyniersko pojętą jakością kodu.

Co dalej?

Nowe technologie pozwalają zautomatyzować coraz większą część zadań programisty. Tworzenie biznesowych aplikacji staje się prostsze, a nowe narzędzia sprawiają, że coraz rzadziej wymagane są specjalistyczne umiejętności. Te ułatwienia powodują, że przybywa nam koderów na poziomie entry level. Koderów, których umiejętności są wystarczające, żeby spełnić wymagania biznesu.

Jeśli ten trend się utrzyma, a popyt wyhamuje, programistów czeka gorsza sytuacja na rynku pracy. Obniżka będzie dotkliwa dla pracujących w firmach outsourcingowych pracowników z Europy centralnej i wschodniej.

Jednym ze sposobów na ucieczkę przed tymi konsekwencjami, może być podążenie ścieżką product engineera. Bardzo dobra koniunktura na rynku pracy IT, to świetny moment, żeby zrobić pierwszy krok w tym kierunku. No ale jak zrobić ten pierwszy krok do zostania PE w polskich realiach? O tym w drugiej części. Do następnego!

---

Zdjęcie główne artykułu pochodzi z pexels.com.