Checklista "Dobre praktyki w feedbacku"

Konstruktywny feedback to dar. Użyj tej checklisty, aby upewnić się, że Twoja informacja zwrotna jest wartościowa, motywująca i wspierająca rozwój mentee.

Przed rozmową:
  • Zbierz konkretne przykłady: Unikaj ogólników. Odwołuj się do konkretnych sytuacji i zachowań, a nie do cech osobowości.
  • Określ cel feedbacku: Co chcesz osiągnąć? Jaka zmiana w zachowaniu mentee byłaby pożądana?
  • Sprawdź swoje intencje: Upewnij się, że Twoim celem jest pomoc i wsparcie, a nie krytyka czy udowodnienie racji.
  • Wybierz odpowiedni czas i miejsce: Zapewnij prywatność i wystarczającą ilość czasu na spokojną rozmowę.
W trakcie rozmowy:
  • Zacznij od pytania o zgodę: "Czy to dobry moment, abyśmy porozmawiali o...?" / "Czy jesteś otwarty/a na informację zwrotną na temat...?".
  • Stosuj model SBI (Situation-Behavior-Impact): Opisz Sytuację, konkretne Zachowanie i jego Wpływ na Ciebie/zespół/projekt.
  • Mów w pierwszej osobie ("Komunikat Ja"): Zamiast "Zawsze się spóźniasz", powiedz "Kiedy spóźniłeś się na spotkanie, poczułem, że mój czas nie jest szanowany".
  • Oddziel fakty od interpretacji: Przedstaw to, co zaobserwowałeś, a następnie zapytaj o perspektywę mentee ("Zauważyłem, że... Jak to wygląda z Twojej strony?").
  • Skup się na przyszłości: Po omówieniu przeszłości, skoncentrujcie się na tym, co można zrobić inaczej w przyszłości.
  • Słuchaj aktywnie: Daj mentee przestrzeń na odpowiedź. Zadawaj pytania, aby upewnić się, że dobrze go rozumiesz.
  • Zakończ pozytywnym akcentem: Podkreśl mocne strony mentee i wyraź wiarę w jego/jej zdolność do rozwoju.
Po rozmowie:
  • Zaplanujcie kolejne kroki: Wspólnie ustalcie, co mentee może zrobić w związku z otrzymanym feedbackiem.
  • Zaoferuj wsparcie: "Jak mogę Ci pomóc w realizacji tego planu?".
  • Sprawdź efekty: Wróć do tematu na kolejnym spotkaniu, aby zobaczyć, jakie postępy poczynił mentee.

Bank 50 "pytań otwarcia"

Użyj tych pytań, aby lepiej poznać mentee, zrozumieć jego motywacje i zdiagnozować potrzeby. Wybierz te, które najlepiej pasują do kontekstu rozmowy.

Pytania na rozpoczęcie i budowanie relacji
  1. Co Cię sprowadza do mentoringu?
  2. Gdybyś miał/a opisać swoją dotychczasową karierę w trzech słowach, jakie by one były?
  3. Jaka jest najcenniejsza lekcja, jakiej nauczyłeś/aś się w ostatnim roku?
  4. Co robisz, żeby się zrelaksować i naładować baterie?
  5. Z jakiego osiągnięcia (zawodowego lub prywatnego) jesteś najbardziej dumny/a?
  6. Co daje Ci najwięcej energii w pracy?
  7. A co najbardziej Cię tej energii pozbawia?
  8. Jak wygląda Twój idealny dzień w pracy?
  9. Gdybyś nie musiał/a pracować, czym byś się zajął/zajęła?
  10. Kto jest dla Ciebie największą inspiracją i dlaczego?
Pytania o cele i aspiracje
  1. Gdzie widzisz siebie za 5 lat?
  2. Jak wygląda dla Ciebie sukces?
  3. Jaki jest Twój największy cel zawodowy na ten rok?
  4. Co musiałoby się stać, abyś uznał/a ten proces mentoringowy za udany?
  5. Jaka jest jedna rzecz, którą chciałbyś/chciałabyś zmienić w swoim życiu zawodowym?
  6. Jakie nowe umiejętności chciałbyś/chciałabyś zdobyć?
  7. Jaki wpływ chciałbyś/chciałabyś wywierać na swoje otoczenie/firmę?
  8. Co stoi na przeszkodzie w realizacji Twoich celów?
  9. Czego najbardziej się obawiasz w kontekście swojej kariery?
  10. Gdybyś miał/a nieograniczone zasoby, jaki projekt byś zrealizował/a?
Pytania o mocne strony i zasoby
  1. W jakich sytuacjach czujesz się najbardziej kompetentny/a?
  2. Jakie są Twoje trzy największe talenty?
  3. Za co chwalą Cię inni?
  4. Jakie zadania wykonujesz z łatwością, podczas gdy dla innych są one trudne?
  5. Opowiedz o sytuacji, w której udało Ci się rozwiązać trudny problem.
  6. Jakie masz nawyki, które wspierają Twój rozwój?
  7. Kto w Twoim otoczeniu może Cię wspierać?
  8. Z jakich swoich dotychczasowych doświadczeń możesz czerpać?
  9. Co wiesz na pewno o sobie?
  10. Jak dbasz o swój rozwój?
Pytania o wyzwania i obszary do rozwoju
  1. Z jakim wyzwaniem mierzysz się obecnie?
  2. Jaka umiejętność, gdybyś ją opanował/a, miałaby największy wpływ na Twoją karierę?
  3. W jakich sytuacjach tracisz pewność siebie?
  4. Jaki feedback najczęściej otrzymujesz?
  5. Co odkładasz na później?
  6. Czego chciałbyś/chciałabyś się oduczyć?
  7. Gdybyś mógł/mogła cofnąć czas, jaką decyzję zawodową podjąłbyś/podjęłabyś inaczej?
  8. Jak radzisz sobie z porażką lub krytyką?
  9. Co Cię frustruje w Twojej obecnej roli?
  10. Jaka jest najtrudniejsza rozmowa, którą musisz przeprowadzić?
Pytania pogłębiające i refleksyjne
  1. Co to dla Ciebie znaczy?
  2. Jakie widzisz inne możliwości?
  3. Co by się stało, gdybyś nic nie zrobił/a w tej sprawie?
  4. Jaki mały krok możesz zrobić już jutro?
  5. Czego potrzebujesz, aby pójść do przodu?
  6. Jakie założenia przyjmujesz w tej sytuacji?
  7. Jak wyglądałaby ta sytuacja z perspektywy innej osoby?
  8. Co podpowiada Ci intuicja?
  9. Czego nauczyła Cię ta sytuacja?
  10. O co jeszcze nie zapytałem/am, a co jest ważne?

Szablon agendy pierwszego spotkania

Pierwsze spotkanie jest kluczowe dla zbudowania relacji i nadania tonu całej współpracy. Poniższa agenda pomoże Ci w jego uporządkowaniu.

1. Przełamanie lodów i wzajemne poznanie się (ok. 15 min)
  • Przedstawienie się (ścieżka kariery, zainteresowania, co Cię inspiruje).
  • Podzielenie się swoimi oczekiwaniami wobec procesu mentoringu.
2. Omówienie roli mentora i mentee (ok. 10 min)
  • Co mentor może zaoferować? Czym jest, a czym nie jest mentoring?
  • Jaka jest rola i odpowiedzialność mentee?
3. Wstępna diagnoza potrzeb i celów mentee (ok. 25 min)
  • Gdzie jesteś teraz? Jakie są Twoje największe wyzwania?
  • Gdzie chcesz być za 6-12 miesięcy? Co chcesz osiągnąć?
  • Wspólne zdefiniowanie 1-3 głównych celów na proces mentoringowy.
4. Ustalenie zasad współpracy (Kontrakt) (ok. 15 min)
  • Omówienie i akceptacja kontraktu (poufność, częstotliwość, forma spotkań).
  • Ustalenie preferowanych form komunikacji między spotkaniami.
5. Podsumowanie i plan na kolejne spotkanie (ok. 5 min)
  • Podsumowanie kluczowych ustaleń.
  • Ustalenie terminu i tematu kolejnego spotkania.

Szablon "Kontraktu mentoringowego"

Kontrakt mentoringowy to umowa między mentorem a mentee, która formalizuje ich współpracę i ustala wspólne oczekiwania. Skorzystaj z poniższego szablonu jako punktu wyjścia.

1. Cele i oczekiwane rezultaty
  • Główny cel współpracy (np. rozwój kompetencji liderskich, przygotowanie do nowej roli).
  • Kluczowe obszary do rozwoju dla mentee.
  • Mierzalne wskaźniki sukcesu (po czym poznamy, że cel został osiągnięty?).
2. Zasady współpracy
  • Poufność: Wszystkie rozmowy są poufne i pozostają między mentorem a mentee.
  • Szczerość i otwartość: Zobowiązujemy się do otwartej komunikacji i konstruktywnego feedbacku.
  • Zaangażowanie: Obie strony zobowiązują się do aktywnego udziału i przygotowania do spotkań.
  • Odpowiedzialność: Mentee jest odpowiedzialny za swój rozwój, a mentor za wspieranie tego procesu.
3. Logistyka spotkań
  • Częstotliwość: Spotkania będą odbywać się (np. raz na dwa tygodnie, raz w miesiącu).
  • Czas trwania: Każde spotkanie potrwa (np. 60-90 minut).
  • Forma: Spotkania będą (np. online, na żywo, hybrydowo).
  • Odwoływanie spotkań: Spotkanie należy odwołać z co najmniej 24-godzinnym wyprzedzeniem.
  • Czas trwania procesu: Współpraca jest zaplanowana na okres (np. 6 miesięcy).

Kubernetes vs Docker Swarm: Który Orkestrator Kontenerów Wybrać dla Twojego Projektu?

W miarę jak konteneryzacja, z Dockerem na czele, stała się standardem w tworzeniu i wdrażaniu aplikacji, pojawiła się potrzeba zarządzania nimi na dużą skalę. Uruchamianie i koordynowanie pracy wielu kontenerów rozproszonych na wielu maszynach wymaga specjalistycznych narzędzi – orkiestratorów. Dwoma najpopularniejszymi graczami na tym polu są Kubernetes (K8s) oraz Docker Swarm. Stając przed wyborem odpowiedniego rozwiązania dla swojego projektu lub organizacji, wielu architektów IT, liderów technicznych i inżynierów DevOps zadaje sobie pytanie: które z nich będzie lepszym wyborem? Ten artykuł ma na celu przeprowadzenie porównania obu platform, analizując ich kluczowe cechy, architekturę, mocne i słabe strony, aby pomóc Ci podjąć świadomą decyzję. Zrozumienie różnic między nimi jest kluczowe dla wyboru narzędzia, które najlepiej odpowie na specyficzne potrzeby Twojego środowiska i zespołu.

Czym są orkiestratory kontenerów i dlaczego są potrzebne?

Zanim przejdziemy do porównania, przypomnijmy krótko, czym jest orkiestracja kontenerów. W prostych słowach, jest to proces automatycznego zarządzania dużymi ilościami kontenerów i ich cyklem życia. Gdy Twoja aplikacja składa się z wielu mikroserwisów, z których każdy działa w osobnym kontenerze, a dodatkowo potrzebujesz wielu instancji każdego serwisu dla zapewnienia wydajności i odporności na awarie, ręczne zarządzanie tym wszystkim staje się niemożliwe.

Orkiestratory takie jak Kubernetes i Docker Swarm automatyzują zadania związane z:

  • Wdrażaniem i harmonogramowaniem (scheduling): Decydują, na których maszynach (węzłach) w klastrze uruchomić kontenery.
  • Skalowaniem: Automatycznie dostosowują liczbę działających kontenerów do obciążenia.
  • Odkrywaniem usług (service discovery) i routingiem: Umożliwiają kontenerom wzajemne odnajdywanie się i komunikację.
  • Zarządzaniem stanem: Dbają o to, aby rzeczywisty stan aplikacji odpowiadał stanowi zadeklarowanemu przez użytkownika (np. restartują uszkodzone kontenery).
  • Aktualizacjami i wycofywaniem zmian (rollbacks): Umożliwiają kontrolowane wdrażanie nowych wersji aplikacji.

Bez orkiestratora, zarządzanie skonteneryzowanymi aplikacjami na skalę produkcyjną byłoby niezwykle złożone i pracochłonne.

Jakie są kluczowe różnice w architekturze Kubernetes i Docker Swarm?

Chociaż oba narzędzia służą do orkiestracji, ich architektura i filozofia działania różnią się w kilku kluczowych aspektach.

Docker Swarm jest natywnym rozwiązaniem do orkiestracji wbudowanym bezpośrednio w silnik Dockera. Jego architektura jest stosunkowo prosta. Klaster Swarm składa się z węzłów menedżerskich (manager nodes) i węzłów roboczych (worker nodes). Menedżerowie odpowiadają za utrzymanie stanu klastra i harmonogramowanie zadań, a pracownicy wykonują te zadania (uruchamiają kontenery). Swarm wykorzystuje Raft jako algorytm konsensusu do zarządzania stanem klastra między menedżerami. Konfiguracja i zarządzanie odbywa się za pomocą standardowych poleceń Docker CLI, co jest jego dużą zaletą pod względem prostoty.

Kubernetes ma bardziej złożoną i rozbudowaną architekturę. Jak opisano w poprzednim artykule, składa się z płaszczyzny sterowania (Control Plane) z komponentami takimi jak API Server, etcd, Scheduler, Controller Manager, oraz węzłów roboczych (Worker Nodes) z Kubeletem i Kube-proxy. Ta architektura oferuje większą elastyczność i modularność, ale jednocześnie wprowadza wyższy próg wejścia i większą złożoność konfiguracyjną. Kubernetes używa własnego API i narzędzia kubectl do zarządzania klastrem, niezależnie od Docker CLI.

Jak wypada porównanie łatwości instalacji i konfiguracji?

Pod względem łatwości rozpoczęcia pracy, Docker Swarm zazwyczaj wygrywa. Ponieważ jest on zintegrowany z Docker Engine, aktywacja trybu Swarm i stworzenie podstawowego klastra jest bardzo proste i wymaga wykonania zaledwie kilku poleceń Docker CLI. Jeśli Twój zespół jest już zaznajomiony z Dockerem, przejście na Swarm jest naturalne i nie wymaga nauki wielu nowych koncepcji czy narzędzi.

Kubernetes jest powszechnie uważany za trudniejszy w instalacji i początkowej konfiguracji. Chociaż istnieją narzędzia upraszczające ten proces (np. minikube do lokalnych testów, k3s dla lekkich klastrów, czy zarządzane usługi Kubernetes w chmurach publicznych jak GKE, EKS, AKS), postawienie produkcyjnego klastra od zera wymaga większej wiedzy i wysiłku. Zrozumienie wszystkich komponentów Control Plane, konfiguracja sieci, zabezpieczeń i pamięci masowej stanowi wyższy próg wejścia.

Które rozwiązanie oferuje większą skalowalność i elastyczność?

Oba orkiestratory są zaprojektowane do skalowania aplikacji, jednak Kubernetes jest generalnie postrzegany jako bardziej skalowalne i elastyczne rozwiązanie, szczególnie w bardzo dużych i złożonych wdrożeniach. Jego modułowa architektura i bogaty zestaw obiektów API (np. Deployments, StatefulSets, DaemonSets, Jobs) dają ogromną kontrolę nad różnymi aspektami aplikacji i infrastruktury. Kubernetes oferuje zaawansowane mechanizmy autoskalowania (HPA, VPA, Cluster Autoscaler) oraz dużą elastyczność w dostosowywaniu konfiguracji do specyficznych potrzeb.

Docker Swarm również umożliwia skalowanie usług (docker service scale), ale jego możliwości są mniej rozbudowane niż w Kubernetes. Skalowanie jest prostsze do skonfigurowania, ale oferuje mniej opcji dostosowania. Dla wielu średniej wielkości aplikacji skalowalność Swarm może być wystarczająca, jednak w scenariuszach wymagających bardzo granularnej kontroli i ekstremalnej skali, Kubernetes często okazuje się bardziej odpowiedni.

Jak Kubernetes i Docker Swarm podchodzą do zarządzania siecią i pamięcią masową?

Zarządzanie siecią i trwałą pamięcią masową to kluczowe aspekty orkiestracji.

W Docker Swarm sieć opiera się głównie na wbudowanych mechanizmach sieciowych Dockera, takich jak sieci overlay, które umożliwiają komunikację między kontenerami rozproszonymi na różnych hostach. Konfiguracja jest stosunkowo prosta. Zarządzanie pamięcią masową opiera się na wolumenach Dockera, które mogą być zarządzane przez sterowniki (volume drivers).

Kubernetes oferuje znacznie bardziej rozbudowany i elastyczny model sieciowy. Definiuje on własne abstrakcje, takie jak Services (do odkrywania usług i load balancingu), Ingress (do zarządzania ruchem przychodzącym z zewnątrz), Network Policies (do definiowania reguł bezpieczeństwa sieciowego). Ta elastyczność pozwala na integrację z różnymi rozwiązaniami sieciowymi (CNI plugins) i implementację zaawansowanych scenariuszy. Podobnie, model zarządzania pamięcią masową w Kubernetes (Persistent Volumes, Persistent Volume Claims, Storage Classes) jest bardziej złożony, ale daje większą kontrolę i możliwość integracji z różnorodnymi systemami storage.

Jakie mechanizmy bezpieczeństwa oferują oba orkiestratory?

Bezpieczeństwo jest kluczowym priorytetem w obu platformach, ale realizowane jest nieco inaczej.

Docker Swarm wykorzystuje mechanizmy bezpieczeństwa wbudowane w Dockera. Komunikacja między węzłami menedżerskimi i roboczymi jest domyślnie szyfrowana (TLS). Zarządzanie sekretami (np. hasłami, kluczami API) jest również wbudowane (docker secret). Kontrola dostępu opiera się na standardowych mechanizmach systemu operacyjnego i konfiguracji Dockera.

Kubernetes posiada bardziej granularne i rozbudowane funkcje bezpieczeństwa. Oferuje zaawansowany system kontroli dostępu oparty na rolach (RBAC), który pozwala precyzyjnie definiować uprawnienia dla użytkowników i usług. Posiada dedykowane obiekty do zarządzania sekretami (Secrets) i konfiguracją (ConfigMaps). Umożliwia definiowanie polityk bezpieczeństwa na poziomie Podów (Security Contexts) oraz szczegółowych reguł zapory sieciowej między Podami (Network Policies). Ta bogata funkcjonalność pozwala na budowanie bezpieczniejszych środowisk, ale wymaga również większej wiedzy konfiguracyjnej.

Jak wygląda kwestia monitorowania, społeczności i wsparcia?

Obserwowalność i wsparcie społeczności to ważne czynniki przy wyborze technologii.

Kubernetes posiada ogromną, bardzo aktywną społeczność skupioną wokół Cloud Native Computing Foundation (CNCF). Przekłada się to na szybki rozwój platformy, bogactwo dostępnych narzędzi (w tym w obszarze monitoringu, np. Prometheus, Grafana, które są standardem de facto), obszerną dokumentację i szerokie wsparcie ze strony dostawców chmurowych oraz firm trzecich. Znalezienie specjalistów od Kubernetes jest również relatywnie łatwiejsze.

Docker Swarm, będąc częścią ekosystemu Dockera, również posiada społeczność i wsparcie, jednak jest ono znacznie mniejsze niż w przypadku Kubernetes. Rozwój Swarm w ostatnich latach był mniej dynamiczny. Ekosystem narzędzi dedykowanych dla Swarm, zwłaszcza w zakresie zaawansowanego monitoringu i logowania, jest mniej rozbudowany. Wsparcie komercyjne jest dostępne głównie w ramach oferty Docker Enterprise (obecnie Mirantis).

Kubernetes czy Docker Swarm – jakie są typowe scenariusze użycia?

Podsumowując, wybór między Kubernetes a Docker Swarm zależy od konkretnych wymagań projektu i możliwości zespołu.

Docker Swarm może być dobrym wyborem, jeśli:

  • Twój zespół ma już duże doświadczenie z Dockerem i chcesz szybko wdrożyć orkiestrację.
  • Priorytetem jest prostota instalacji, konfiguracji i zarządzania.
  • Potrzeby skalowania i elastyczności nie są ekstremalne.
  • Wymagania dotyczące zaawansowanych funkcji sieciowych i bezpieczeństwa są umiarkowane.

Kubernetes jest często preferowany, gdy:

  • Wymagana jest wysoka skalowalność, elastyczność i odporność na awarie na dużą skalę.
  • Potrzebujesz zaawansowanych funkcji sieciowych, zarządzania pamięcią masową i bezpieczeństwem.
  • Chcesz korzystać z bogatego ekosystemu narzędzi Cloud Native.
  • Masz zasoby (czas, ludzie) na naukę i zarządzanie bardziej złożoną platformą.
  • Strategicznie stawiasz na standardy de facto w orkiestracji i technologiach chmurowych.

Poniższa tabela zestawia kluczowe różnice:

KryteriumDocker SwarmKubernetes
Łatwość instalacji/konfiguracjiWysoka (zintegrowany z Docker CLI)Niższa (bardziej złożona architektura)
Krzywa uczenia sięStosunkowo niska (dla znających Dockera)Wyższa (więcej koncepcji, własne API/kubectl)
ArchitekturaProstsza (Manager/Worker)Bardziej złożona i modułowa (Control Plane/Node)
SkalowalnośćDobra, ale mniej elastycznaBardzo wysoka, duża elastyczność
Zarządzanie sieciąProstsze (Docker overlay networks)Bardziej rozbudowane i elastyczne (Services, CNI)
Zarządzanie pamięciąPodstawowe (Docker volumes, drivers)Zaawansowane (PV, PVC, Storage Classes)
BezpieczeństwoDobre (TLS, Secrets)Bardzo dobre (RBAC, Network Policies, Secrets)
Monitoring/EkosystemMniej rozbudowanyBardzo bogaty (Prometheus, Grafana, CNCF)
Społeczność/WsparcieMniejsza, mniej dynamicznaOgromna, bardzo aktywna, szerokie wsparcie

Który orkiestrator wybrać i jak EITT może pomóc w rozwoju kompetencji?

Ostateczna decyzja o wyborze między Docker Swarm a Kubernetes powinna być oparta na dokładnej analizie potrzeb Twojego projektu, skali wdrożenia, dostępnych zasobów oraz strategicznych celów technologicznych Twojej organizacji. Docker Swarm oferuje prostotę i szybkość wdrożenia dla mniej złożonych scenariuszy, podczas gdy Kubernetes dostarcza potężną, elastyczną platformę gotową na największe wyzwania, choć kosztem większej złożoności.

Warto zauważyć, że trend rynkowy wyraźnie wskazuje na dominację Kubernetes jako standardu w orkiestracji kontenerów, szczególnie w zastosowaniach korporacyjnych i chmurowych. Inwestycja w rozwój kompetencji zespołu w zakresie Kubernetes jest często strategiczną decyzją, która otwiera dostęp do szerokiego ekosystemu narzędzi i praktyk Cloud Native.

Niezależnie od tego, na który orkiestrator się zdecydujesz, lub jeśli potrzebujesz pogłębić wiedzę na temat obu platform, EITT oferuje specjalistyczne szkolenia, które pomogą Twojemu zespołowi zdobyć niezbędne umiejętności. Nasza oferta obejmuje zarówno praktyczne szkolenia z Dockera, które stanowią doskonały fundament, jak i zaawansowane warsztaty z Kubernetes, pokrywające jego architekturę, zarządzanie i najlepsze praktyki wdrożeniowe. Nasi eksperci pomogą Wam zrozumieć niuanse obu technologii i efektywnie wykorzystać je w Waszych projektach.

Skontaktuj się z nami, aby omówić potrzeby szkoleniowe Twojego zespołu i dowiedzieć się, jak możemy wesprzeć Was w opanowaniu sztuki orkiestracji kontenerów.

?
?
Zapoznałem/łam się i akceptuję politykę prywatności.*

O autorze:
Klaudia Janecka

Klaudia to doświadczona specjalistka z ponad 10-letnim stażem w obszarze zarządzania relacjami z klientami i sprzedaży, obecnie pełniąca funkcję Key Account Managera w EITT. Jej unikalne połączenie wykształcenia w dziedzinie dziennikarstwa i komunikacji społecznej z bogatym doświadczeniem w obszarze technologii pozwala jej skutecznie łączyć świat IT z biznesem, dostarczając klientom dopasowane rozwiązania rozwojowe.

W swojej pracy Klaudia kieruje się głębokim zrozumieniem potrzeb klientów i profesjonalnym podejściem do budowania relacji biznesowych. Jej doświadczenie w obszarach programowania, AI i cyberbezpieczeństwa, połączone z wiedzą o projektach dofinansowanych do szkoleń, pozwala jej skutecznie wspierać organizacje w maksymalizacji korzyści z inwestycji szkoleniowych przy jednoczesnym zachowaniu zgodności z ich celami strategicznymi.

Aktywnie angażuje się w rozwój osobisty i zawodowy, śledząc najnowsze trendy w branży technologicznej. Wierzy, że w dynamicznie zmieniającym się świecie IT kluczem do sukcesu jest nieustanne poszerzanie horyzontów oraz elastyczność w dostosowywaniu się do ewoluujących wymagań rynkowych, co znajduje odzwierciedlenie w strategiach rozwoju EITT.