Wszystkie artykuły

KajoData / Praca i rozwój

Konferencje IT dla introwertyka: przygotowanie, rozmowy i spokojny plan

Pokazuję, jak zaplanować konferencję wokół własnego pytania, kilku sensownych rozmów i jednego pomysłu do sprawdzenia. Bez obowiązku poznawania całej sali.

Kajo RudzińskiOpublikowano Aktualizacja 11 min czytania

Pusta sala konferencyjna połączona złotą ścieżką z cichym miejscem do odpoczynku.

Konferencja IT potrafi wyglądać jak bardzo głośny test z bycia towarzyskim. Wokół stoją grupki ludzi, ktoś właśnie opowiada o projekcie na ogromną skalę, a Ty zastanawiasz się, czy przy stoliku z kawą wypada po prostu napić się kawy. Wypada. Nie trzeba natychmiast zamieniać każdej przerwy w rundę prezentowania własnej wartości.

Ja lubię patrzeć na konferencję jak na miejsce, w którym można zdobyć konkretną perspektywę: usłyszeć, dlaczego ktoś wybrał dane rozwiązanie, zapytać o błąd, którego nie widać na slajdzie, albo poznać osobę pracującą nad podobnym problemem. Taki cel pomaga bardziej niż ogólne postanowienie, że tym razem „muszę zrobić networking”.

Ten poradnik kieruję do osób, które wolą spokojniejsze rozmowy i potrzebują odpoczynku od tłumu. Nie zakładam, że wszyscy ludzie w IT mają podobną osobowość. Nie próbuję też diagnozować stresu na podstawie zachowania przy mikrofonie. Proponuję praktyczny plan udziału, który możesz dostosować do siebie, rodzaju wydarzenia i dostępnego czasu.

Przykłady rozmów i plan dnia poniżej są wymyślone na potrzeby tekstu. Nie opisują konkretnej konferencji ani rozmów z jej uczestnikami. Dokumentację PyCon US przywołuję wyłącznie jako przykład rozwiązań organizacyjnych istniejących podczas edycji 2026, bez założenia, że są dostępne na każdym wydarzeniu.

Wybierz pytanie, z którym jedziesz

Przed przeglądaniem agendy zapisuję jedno pytanie związane z moją pracą albo nauką. Na przykład: jak zespoły sprawdzają jakość danych przed publikacją raportu? Albo: jak analityk uzgadnia definicję wskaźnika z kilkoma działami? Dzięki temu mogę ocenić, które wystąpienia i rozmowy mają szansę coś wnieść.

Nie musi to być pytanie eksperckie. Początkująca osoba może chcieć zrozumieć, jak wygląda pierwszy miesiąc pracy z danymi w zespole. Ktoś bardziej doświadczony może szukać sposobu na przegląd zmian w modelu. Ważne, żeby cel był własny. Lista tematów, którymi wypada się interesować, potrafi być znacznie dłuższa od realnego dnia konferencyjnego.

Dopisuję oczekiwany rezultat. Chcę wrócić z jednym przykładem procesu, dwiema rzeczami do sprawdzenia w dokumentacji albo pomysłem na małe ćwiczenie. Taki punkt odniesienia pomoże mi później ocenić wydarzenie bez porównywania liczby nowych kontaktów z najbardziej towarzyską osobą w sali.

Przeczytaj program przed wyborem wydarzenia

Sam tytuł konferencji niewiele mówi o poziomie i formacie. Czytam opisy kilku sesji, sprawdzam wymagania warsztatów i szukam informacji o nagraniach. Prezentacja architektury dużej platformy może być interesująca, ale niekoniecznie odpowie na pytanie osoby uczącej się pierwszych zapytań. Podobnie warsztat może wymagać przygotowanego środowiska, którego nie da się uruchomić w kolejce do wejścia.

Biorę pod uwagę cały koszt udziału: bilet, dojazd, nocleg i czas potrzebny na podróż oraz odpoczynek. Nie zakładam, że droższe wydarzenie automatycznie da więcej użytecznej wiedzy. Lokalny meetup, warsztat lub nagranie z późniejszą dyskusją mogą lepiej pasować do konkretnego celu. Nie ma obowiązku wybierania największej możliwej imprezy.

Jeśli jedziesz z budżetu pracodawcy, uzgodnij wcześniej rezultat: krótka notatka dla zespołu, omówienie wybranej praktyki albo sprawdzenie jednego rozwiązania. Unikaj obietnicy, że po dwóch dniach wrócisz z odpowiedzią na wszystkie problemy firmy. Konferencja daje materiał do dalszej pracy, a nie gotowe wdrożenie zapakowane razem z identyfikatorem.

Przygotuj prostą mapę dnia

Wybieram kilka sesji, które najbardziej pasują do pytania, i sprawdzam, czy nie kolidują. Zostawiam margines na zmianę planu. Jeśli rozmowa po wystąpieniu jest użyteczna, nie muszę jej urywać tylko po to, żeby odhaczyć kolejną salę. Jeśli prezentacja okazuje się zupełnie innym tematem, mogę spokojnie skorygować wybór.

Przykładowy plan to dwie sesje przed południem, jedna rozmowa przy przerwie, posiłek i spokojniejszy blok po południu. To propozycja organizacji, nie obowiązkowy cel ilościowy. Nie wpisuję rozmowy w każdą wolną minutę. Pomiędzy punktami programu trzeba jeszcze znaleźć salę, uzupełnić notatkę i czasem zwyczajnie odetchnąć.

Zapisuję miejsce rejestracji, sposób dojazdu i kontakt do organizatora. Sprawdzam zasady wydarzenia oraz dostępne formy pomocy. Mniejsza liczba drobnych niewiadomych pozwala skupić się na tym, po co przyjechałem. Nie jest szczególnie przyjemnie zaczynać pierwszą rozmowę z myślą, że za chwilę zgubię się w drugim budynku.

Poszukaj formatu dla nowych uczestników

Niektóre wydarzenia pomagają wejść w społeczność przez spotkania wprowadzające, wspólne stoliki albo sesje dla osób przyjeżdżających pierwszy raz. Warto sprawdzić, czy coś takiego jest w programie. To może dać naturalny temat do rozmowy: wszyscy próbują zorientować się, jak działa dane wydarzenie i gdzie zacząć.

Przykładem jest Newcomer Orientation na PyCon US 2026, opisane przez organizatora jako krótkie wprowadzenie dla nowych uczestników. Przywołuję konkretną minioną edycję, żeby pokazać rodzaj rozwiązania. Przed własnym wyjazdem sprawdź aktualny program wybranego wydarzenia; podobna nazwa nie gwarantuje identycznego formatu.

Jeśli takiego punktu nie ma, możesz przyjechać ze znajomą osobą i umówić się na wspólny początek. Dobrze jednak zostawić sobie możliwość osobnych wyborów sesji. Towarzystwo ma ułatwiać udział, a nie tworzyć kolejną listę zobowiązań. Można spotkać się przy obiedzie i porównać, co każdemu rzeczywiście się przydało.

Przygotuj przedstawienie się w dwóch zdaniach

Nie potrzebujesz przemowy o całej karierze. Wystarczy powiedzieć, czym się zajmujesz lub czego się uczysz oraz co sprowadza Cię na wydarzenie. Przykład: „uczę się analizy danych i robię mały projekt o terminowości zamówień. Przyjechałem posłuchać, jak zespoły sprawdzają jakość danych”. Rozmówca dostaje konkretny punkt zaczepienia.

Jeżeli dopiero zaczynasz, nie musisz przepraszać za swój poziom. Możesz uczciwie nazwać etap nauki. „Jeszcze nie pracuję jako analityk, ćwiczę SQL i próbuję zrozumieć pracę zespołową” jest wystarczającą informacją. Nie potrzebujesz dopisywać doświadczenia, którego nie masz, ani przedstawiać się jako ktoś, kto niczego wartościowego nie może powiedzieć.

Warto przećwiczyć te dwa zdania na głos przed wyjazdem. Chodzi o znajomość własnego komunikatu, nie o wyuczenie sprzedażowej prezentacji. W rozmowie możesz go skrócić albo zmienić. Jeśli druga osoba pyta o projekt, opowiedz o pytaniu i jednym problemie, który próbujesz rozwiązać. Lista wszystkich poznanych bibliotek może poczekać.

Zacznij od wspólnego kontekstu

Po prezentacji masz gotowy temat. Możesz zapytać: „który element tego podejścia najbardziej pasuje do Twojej pracy?” albo „czy u Was też trudne było ustalenie właściciela danych?”. Takie pytanie zaprasza do doświadczenia rozmówcy. Nie wymaga błyskotliwego dowcipu ani demonstracji, że znasz wszystkie skróty użyte na scenie.

Przy stoliku można zacząć jeszcze prościej: „mogę się dosiąść?” i „na jaką sesję idziesz później?”. Jeśli odpowiedź jest krótka i rozmówca wraca do swoich zajęć, nie trzeba ciągnąć rozmowy siłą. Być może odpoczywa, czeka na kogoś albo ma własną sprawę. Jedna krótka wymiana nie daje podstaw do oceny całego Twojego udziału.

Ja skupiam się na jednym kolejnym pytaniu wynikającym z odpowiedzi. Gdy ktoś wspomina o wdrożeniu testów danych, pytam, od jakiego błędu zaczęli. Nie przeskakuję od razu do własnej historii, żeby udowodnić podobne doświadczenie. Uważne słuchanie daje materiał do rozmowy i pozwala zauważyć, czy druga osoba chce ją kontynuować.

Pytaj o decyzje i ograniczenia

Techniczne pytania są bardzo przydatne, zwłaszcza jeśli dotyczą rzeczy, których nie da się wyczytać ze slajdu. Dlaczego wybrano ten sposób? Jakie alternatywy odrzucono? Co wymagało najwięcej pracy? Która część rozwiązania zależy od skali albo struktury zespołu? Takie pytania pokazują warunki, w których prezentowana praktyka ma sens.

Do tego dokładam pytania o współpracę. Kto zatwierdza definicje? Jak zespół dowiaduje się o błędzie? Co dzieje się, gdy dwa działy potrzebują sprzecznych rzeczy? W analizie danych narzędzie często działa wewnątrz procesu, który trzeba zrozumieć. Rozmowa o ludziach może pomóc wyjaśnić, dlaczego podobny kod w dwóch firmach daje różne efekty organizacyjne.

Nie próbuję uzyskać poufnych szczegółów. Jeśli rozmówca nie może opowiedzieć o danych albo kliencie, pytam o ogólną zasadę i akceptuję granicę. Podobnie sam nie pokazuję firmowego raportu przypadkowej osobie w korytarzu. Syntetyczny przykład zwykle wystarcza do rozmowy o mechanizmie, a przy okazji zmusza do jaśniejszego opisania problemu.

Notatnik z prostym schematem i zbudowany obok mały model pokazują przejście od pomysłu do próby.

Zadawaj pytania bez wygłaszania drugiej prezentacji

Przy mikrofonie formułuję jedno pytanie i krótki kontekst. „Mówiliście o kontroli świeżości danych. Jak wybieraliście moment, po którym brak aktualizacji stawał się alarmem?”. To wystarcza, żeby prelegent wiedział, do czego się odnosisz. Pięciominutowy opis własnej architektury prawdopodobnie nie pomoże pozostałym uczestnikom.

Jeśli pytanie wymaga długiego omówienia, można zapytać o możliwość rozmowy po sesji. Prelegent może nie mieć czasu, więc nie zakładam takiego zobowiązania. Czasem lepszym rezultatem jest wskazanie dokumentacji albo publicznego przykładu. Nie każda konferencyjna rozmowa musi kończyć się konsultacją całego Twojego projektu.

Jeżeli nie rozumiesz pojęcia, możesz o nie dopytać. Warto odróżnić brak podstawowego kontekstu od pytania, które rozwija temat dla całej sali, i dobrać moment. Obie potrzeby są normalne. Nie trzeba udawać zrozumienia, ale nie trzeba też publicznie rozwiązywać każdej własnej luki podczas ostatnich dwóch minut sesji.

Notuj rzeczy, do których potrafisz wrócić

Nie próbuję przepisywać całej prezentacji. Zapisuję tezę, warunek jej zastosowania i pytanie do sprawdzenia. Na przykład: „kontrola liczby rekordów przed publikacją; potrzebny punkt odniesienia i obsługa sezonowości; sprawdzić na własnym pliku”. Po tygodniu nadal wiem, co miałem na myśli i od czego zacząć.

Oddzielam twierdzenie prelegenta od własnej interpretacji. Jeśli zapisałem wynik wydajności, dopisuję kontekst testu i link do materiału, o ile jest dostępny. Nie przenoszę liczby ze sceny do własnej rekomendacji bez sprawdzenia warunków. Demonstracja na przygotowanym zbiorze nie oznacza, że identyczny efekt uzyskam w innym środowisku.

Przy ciekawym slajdzie notuję, co zadziałało: czytelna definicja, prosty diagram, przykład przed szczegółami. Przy nieczytelnym próbuję nazwać problem zamiast tylko narzekać. Dzięki temu z konferencji można wynieść również pomysł na własną prezentację. Same zdjęcia kilkudziesięciu slajdów łatwo stają się archiwum, którego nigdy nie otworzysz.

Zostaw miejsce na ciszę

Przerwa może być częścią dobrego planu. Jeśli po kilku sesjach trudno Ci śledzić rozmowę, kolejny intensywny blok nie musi być najlepszym wyborem. Możesz przejść się, zjeść spokojnie albo usiąść z notatkami. Nie musisz tłumaczyć każdej takiej decyzji ani porównywać swojej energii z kimś, kto zostaje do końca imprezy wieczornej.

Organizator PyCon US 2026 opisywał Attendee Quiet Room jako miejsce dla osób potrzebujących spokoju i przerwy. To przykład konkretnego udogodnienia. Na własnym wydarzeniu sprawdź dostępność podobnego miejsca i zasady korzystania; nie zakładaj, że każda sala oznaczona jako wolna jest przeznaczona do odpoczynku.

Warto też uwzględnić powrót. Jeśli czeka Cię długa podróż, pełny program do ostatniej minuty może być kiepskim planem. Udział ma pasować do Twoich możliwości i celu. O współpracy osób preferujących spokojniejsze otoczenie piszę szerzej w tekście o pracy analityka dla introwertyka.

Zakończ rozmowę jasno i uprzejmie

Nie musisz czekać, aż rozmowa sama całkowicie wygaśnie. Możesz powiedzieć: „dzięki za przykład, pomógł mi zrozumieć ten problem. Idę teraz na kolejną sesję”. Jeśli potrzebujesz odpoczynku, wystarczy podobnie proste zdanie. Krótkie zakończenie nie unieważnia dobrej rozmowy i nie wymaga wymyślania pilnego telefonu.

Gdy jest powód do dalszego kontaktu, zapytaj o preferowany sposób. „Wspominałeś o publicznym przykładzie. Czy mogę napisać po konferencji i poprosić o link?”. Taka prośba ma kontekst. Druga osoba może się zgodzić, wskazać materiał od razu albo odmówić. Nie traktuję wymiany kontaktów jako zgody na nieograniczoną serię pytań.

Jeśli coś obiecujesz, zanotuj to. Wysłanie linku do własnego ćwiczenia albo materiału jest małym zobowiązaniem, które można łatwo zgubić między sesjami. Lepiej obiecać jedną rzecz i ją zrobić niż deklarować współpracę przy kilku projektach, których jeszcze nawet nie rozumiesz. Konferencyjny entuzjazm nie wydłuża następnego tygodnia.

Po wydarzeniu wybierz jeden eksperyment

W ciągu kilku dni przeglądam notatki i wybieram pomysł do sprawdzenia. W naszym fikcyjnym przykładzie może to być prosta kontrola kompletności danych przed odświeżeniem raportu. Zapisuję wejście, oczekiwany wynik i przypadek, który ma wykryć problem. Dopiero potem sprawdzam, jak wykonać tę kontrolę w używanym narzędziu.

Odróżniam inspirację od dowodu. To, że metoda zadziałała w prezentowanej firmie, nie potwierdza jej przydatności w moim projekcie. Mała próba pozwala zobaczyć koszt, zależności i ograniczenia. Jeśli nie pomaga, zapisuję dlaczego. Nadal czegoś się dowiedziałem, zamiast bez końca odkładać materiał w folderze „do wdrożenia”.

Wiadomość po rozmowie powinna przypomnieć kontekst i dotyczyć uzgodnionej sprawy. Przykład: „rozmawialiśmy po sesji o testach danych; dzięki za wskazówkę o brakujących kluczach. Sprawdziłem ją na syntetycznym zbiorze. Wspominałaś o publicznym przykładzie, chętnie go przeczytam, jeśli możesz podesłać link”. To zaproszenie do kontynuacji, bez oczekiwania natychmiastowej odpowiedzi.

Oceń konferencję według własnego celu

Po powrocie porównuję rezultat z pytaniem, które zabrałem ze sobą. Czy lepiej rozumiem problem? Czy znalazłem wiarygodne źródło? Czy sprawdziłem jeden pomysł? Czy mam konkretny kontekst do dalszej rozmowy? Liczba identyfikatorów, zdjęć i kontaktów może być miłym dodatkiem, ale sama nie odpowiada na te pytania.

Jeśli wydarzenie nie pasowało do potrzeb, zapisuję, czego szukać następnym razem: mniejszych grup, bardziej praktycznych warsztatów, innego poziomu albo większej ilości czasu na rozmowy. Nie muszę z tego robić oceny własnej osobowości. Czasem po prostu wybrałem format, który słabo wspierał mój cel.

Na kolejną konferencję przygotuj jedno pytanie, dwa zdania przedstawienia się i miejsce na przerwę. Wybierz kilka sesji, a po powrocie sprawdź jeden pomysł. Taki plan daje Ci możliwość uczestniczenia na własnych warunkach, przy jednoczesnym zrobieniu czegoś konkretnego z wiedzą i rozmowami, po które przyjechałeś.

Najważniejsze w pigułce

Czy na konferencji trzeba rozmawiać ze wszystkimi?

Nie. Warto dobrać udział do własnego celu i możliwości. Jedna konkretna rozmowa, użyteczna odpowiedź lub pomysł sprawdzony później mogą być dobrym rezultatem. Liczba kontaktów sama nie mierzy wartości wydarzenia.

Jak zacząć rozmowę na konferencji IT?

Od wspólnego kontekstu: konkretnej prezentacji, pytania o zastosowanie rozwiązania albo własnego małego projektu. Krótkie pytanie i uważne słuchanie zwykle dają więcej materiału do rozmowy niż długa autoprezentacja.

Co zrobić po konferencji, żeby wiedza nie przepadła?

Uporządkuj kilka najważniejszych notatek, sprawdź źródła i wybierz jeden mały eksperyment. Jeśli uzgodniono dalszy kontakt, napisz wiadomość przypominającą rozmowę i dotrzymaj własnej obietnicy.

Przy pracy nad artykułem użyto w zautomatyzowany sposób sztucznej inteligencji. Jeśli też chcesz tak umieć, sprawdź ten projekt.

Kajo Rudziński

Newsletter KajoData

Zostańmy w kontakcie.

Piszę o analizie danych, uczeniu się i zmianie pracy. Dzielę się tym, co pomaga mi ogarniać technologię i zawodowe decyzje. Jeśli lubisz ten sposób myślenia, zapraszam do mojego newslettera.