Jak przetrwać okres próbny w IT: priorytety, komunikacja i szybkie wygrane

Scenka na start: pierwsze tygodnie między ekscytacją a paniką

Nowy developer siada pierwszy raz do firmowego laptopa. Slack miga dziesiątkami kanałów, Jira pełna zadań, a na stand-upie każdy wyrzuca z siebie skróty i nazwy serwisów, których jeszcze nawet nie widziałeś. Po piętnastu minutach wszyscy znikają na swoje call’e, a ty zostajesz z pustym ekranem i myślą: „Od czego mam zacząć?”.

W głowie wciąż siedzi obietnica z rekrutacji: „będzie czas na spokojne wdrożenie, dużo się nauczysz”. Rzeczywistość jest inna: produkcja żyje własnym życiem, terminy gonią, a ty czujesz, że każdy dzień okresu próbnego to test, czy „się nadajesz”. Do tego dochodzi niejasny lęk: „Jak nie dowiozę w te 3 miesiące, to co dalej?”.

Przetrwanie okresu próbnego w IT nie zależy szczególnie od błyskotliwego „talentu” czy znajomości wszystkich frameworków świata. Klucz leży w tym, jak ułożysz priorytety, jak rozmawiasz z ludźmi i czy umiesz szybko pokazać realne, choćby małe, efekty swojej pracy.

Czego firma tak naprawdę oczekuje po okresie próbnym

Perspektywa pracodawcy: minimalne kryteria „opłacalności”

Od środka okres próbny w IT wygląda jak walka o przetrwanie. Dla firmy to raczej test, czy inwestycja w nową osobę zaczyna się zwracać. Nie chodzi o to, abyś po trzech miesiącach był architektem systemu, tylko byś stał się przewidywalnym, użytecznym członkiem zespołu.

Najprostsze kryteria, które siedzą w głowach managerów, to zazwyczaj:

• Techniczne minimum – czy potrafisz samodzielnie ogarnąć typowe zadanie z backlogu; czy twój kod po kilku code review wymaga coraz mniej poprawek; czy nie popełniasz tych samych błędów w kółko.
• Komunikacja – czy informujesz o postępach; czy zgłaszasz blokery; czy umiesz zapytać, kiedy nie rozumiesz; czy nie znikasz bez śladu na kilka dni.
• Organizacja pracy – czy dowozisz zadania w sensownym czasie; czy potrafisz oszacować, ile zajmie ci praca; czy nie bierzesz na siebie pięciu tematów naraz i nie kończysz żadnego.
• Fit zespołowy – czy da się z tobą normalnie pracować; czy nie generujesz konfliktów; czy akceptujesz procesy, które już w zespole istnieją.

Firma inwestuje w onboarding programisty czas seniorów, pracy HR, licencje, sprzęt. Po okresie próbnym nie oczekuje perfekcji, ale chce widzieć, że krzywa twojej wartości rośnie – uczysz się, robisz coraz mniej trywialnych błędów, a komunikacja z tobą nie jest męcząca.

Nieformalne pytania w głowie managera

Mało który lider techniczny trzyma w Excelu formalne KPI na okres próbny. Raczej zadaje sobie kilka niebezpośrednich, ale bardzo praktycznych pytań:

• Czy mogę tej osobie zaufać? – jeśli powie, że coś skończy do piątku, to czy w piątek faktycznie jest gotowe lub przynajmniej jest uczciwa informacja, że nie będzie i dlaczego?
• Czy poradzi sobie z typowym zadaniem bez prowadzenia za rękę? – nie chodzi o brak pytań, ale o to, czy potrafisz po zadaniu kilku pytań ruszyć samodzielnie, bez oczekiwania szczegółowej instrukcji krok po kroku.
• Czy nie będę musiał gasić po niej/po nim pożarów? – czy nie wrzucasz na produkcję nieprzetestowanych zmian; czy umiesz przyznać się do błędu, zamiast go ukrywać; czy dokumentujesz to, co robisz.
• Czy zespół nie cierpi na współpracy? – czy code review z tobą nie jest wojną; czy przyjmujesz feedback; czy nie spamujesz na Slacku pytaniami, na które odpowiedzi są w dokumentacji.

To z tych pytań rodzi się decyzja o przedłużeniu umowy. Techniczne braki można nadrobić. Trudno natomiast nadrobić chaos w komunikacji, brak odpowiedzialności czy wieczną defensywę przy każdej uwadze.

Inne oczekiwania wobec juniora, mida i seniora

Okres próbny w IT wygląda inaczej w zależności od poziomu doświadczenia. Częstą pułapką jest przykładanie do siebie niewłaściwej miary.

Junior nie musi na okresie próbnym projektować architektury. Bardziej liczy się, czy szybko rozumie zasady panujące w projekcie, czy umie dojść do odpowiedzi, a nie czeka, aż ktoś poda je na tacy. Senior odwrotnie – jeśli po 3 miesiącach wciąż potrzebuje prowadzenia za rękę przy każdym większym zadaniu, zapala to czerwoną lampkę.

Jak odczytać oczekiwania z ogłoszenia i pierwszych rozmów

Spora część odpowiedzi na pytanie „czego ode mnie chcą?” jest dostępna jeszcze zanim podpiszesz umowę – w ogłoszeniu i na rozmowach. Warto wrócić do tych materiałów już po pierwszym tygodniu pracy.

Na co zwrócić uwagę:

• Opis obowiązków – czy dominują tam frazy typu „wspieranie”, „pomoc przy” (bardziej junior), czy „projektowanie”, „odpowiedzialność za” (mid/senior)? To sygnał, jaki poziom autonomii jest oczekiwany.
• Stack technologiczny – jeśli w ofercie jest 10 technologii, a w praktyce w projekcie używane są 3, to właśnie na nie patrz w pierwszej kolejności w okresie próbnym.
• Rozmowy rekrutacyjne – przypomnij sobie, o co pytali najczęściej: o komunikację, o testy, o pracę z biznesem? To podpowiada, gdzie mają największe oczekiwania lub największe problemy.
• Pierwszy feedback – każde „na razie skup się na…” jest bezcennym sygnałem priorytetów. Zapisz te rzeczy, bo łatwo je zgubić w natłoku bodźców.

Dzięki temu lepiej widzisz, jak zgrać własne cele na okres próbny z tym, czego faktycznie potrzebuje zespół, a nie tylko z tym, co tobie wydaje się ważne.

Okres próbny jako test przewidywalności, nie perfekcji

W tle całego okresu próbnego przewija się jedno: czy twoje działania i efekty są przewidywalne. Manager nie potrzebuje marzyciela, tylko kogoś, kto stopniowo, ale konsekwentnie dostarcza wartość.

Jeśli potrafisz:

• mówić, co robisz i ile to potrwa,
• zgłaszać problemy zanim zamienią się w dramat,
• samodzielnie szukać odpowiedzi,
• uczyć się na błędach zamiast je powtarzać,

to nawet nieidealny kod czy brak znajomości części narzędzi schodzą na dalszy plan. Technika jest ważna, ale na okresie próbnym równie ważna jest zdolność do współpracy i bycia „obliczalnym” partnerem dla reszty zespołu.

Pierwszy tydzień: fundamenty, które decydują o reszcie okresu próbnego

Niezbędne dostępy i narzędzia: bez tego stoisz w miejscu

Wiele osób traci pierwsze dni okresu próbnego na bierne czekanie: „jeszcze nie mam dostępu do repozytorium”, „nikt mi nie ustawił środowiska”. To zabójstwo dla postrzegania twojej inicjatywy. Nawet jeśli proces w firmie szwankuje, ty możesz być stroną, która delikatnie, ale konsekwentnie go pcha do przodu.

Lista rzeczy, które trzeba mieć jak najszybciej:

• dostęp do repozytoriów (Git, system kontroli wersji),
• dostęp do Jiry lub innego systemu zarządzania zadaniami,
• konto w komunikatorze (Slack, Teams, inne),
• dostęp do dokumentacji (Confluence, Wiki, Notion),
• możliwość uruchomienia projektu lokalnie (credentials, konfiguracja środowiska),
• dostępy do narzędzi CI/CD, jeśli z nich korzystacie.

Jeśli czegokolwiek brakuje, sygnalizuj to jasno liderowi lub osobie odpowiedzialnej za onboarding: nie w formie narzekania, tylko krótkich, konkretnych komunikatów: „Brakuje mi jeszcze dostępu do X, przez co nie mogę uruchomić projektu lokalnie. Czy możesz pomóc to przyspieszyć lub wskazać osobę, do której się zgłosić?”.

Poproszenie o plan na okres próbny

W wielu firmach plan okresu próbnego istnieje tylko w głowie lidera. Dobrze jest go wyciągnąć na światło dzienne i uporządkować. To ogromnie ułatwia ułożenie własnych priorytetów.

Możesz użyć prostego szablonu w rozmowie z liderem technicznym lub managerem:

• Zakres odpowiedzialności: „Na jakich obszarach projektu mam się w tych trzech miesiącach skupić najbardziej? Jakie moduły, komponenty, serwisy?”
• Oczekiwane efekty: „Po czym poznamy, że okres próbny jest udany? Jakie konkretne rzeczy powinienem umieć lub zrobić po 3 miesiącach?”
• Kryteria oceny: „Jak będziesz oceniać moją pracę? Co będzie najważniejsze: jakość kodu, tempo, komunikacja, samodzielność?”
• Formy wsparcia: „Kto jest moją osobą kontaktową, gdy mam pytania techniczne lub produktowe? Jak najlepiej do niej pisać?”

Jeśli lider nie ma gotowego planu, zaproponuj, że sam przygotujesz szkic i poprosisz o komentarz. Już tym pokazujesz inicjatywę i odpowiedzialność za swój rozwój w IT.

Ustalenie zasad komunikacji z liderem i zespołem

Komunikacja z liderem technicznym w okresie próbnym powinna być maksymalnie jasna i przewidywalna. W pierwszym tygodniu dobrze jest doprecyzować kilka spraw.

Przydatne pytania do lidera:

• „Jaką formę komunikacji preferujesz przy krótkich pytaniach (Slack, mail, komentarze w Jira)?”
• „Jak często chcesz mieć update, nad czym aktualnie pracuję – codziennie, dwa razy w tygodniu, na stand-upie?”
• „Czy możemy mieć regularne 1:1 w okresie próbnym, np. co 2 tygodnie, żeby zebrać feedback i skorygować kurs?”
• „Czy są godziny, w których wolisz, żeby ci nie przeszkadzać, i lepiej pisać do kogoś innego?”

Dobrze jest też nauczyć się „mapy Slacka”: gdzie zadajemy pytania techniczne, gdzie projektowe, gdzie wrzucać statusy. To brzmi banalnie, ale brak tej wiedzy potrafi spowodować, że będziesz się czuł wiecznie, jakbyś „przeszkadzał”.

Własna mapa terenu: ludzie, narzędzia, procesy

Okres próbny w IT jest o wiele łatwiejszy, gdy szybko zbudujesz sobie mentalną mapę tego, jak działa ekosystem wokół ciebie. Zamiast liczyć na pamięć, od pierwszego dnia prowadź prostą notatkę.

Co warto tam spisać:

• Ludzie: kto jest product ownerem, kto jest architektem, kto ogarnia infrastrukturę, kto jest „go-to person” od danego mikroserwisu, kto zna najlepiej testy automatyczne.
• Narzędzia: jakie środowiska macie (dev, stage, prod), jak deployujecie, jak monitorujecie system, z jakich dashboardów korzystacie.
• Procesy: jak wygląda cykl zadania od „To do” do „Done”, jak robicie code review, jak zgłaszać bugi, jak działają deploye na produkcję.
• Skróty myślowe: charakterystyczne nazwy serwisów, wewnętrzne akronimy, powtarzające się pojęcia domenowe.

Taka „mapa terenu” daje ci przewagę: zamiast po raz dziesiąty pytać „kto tu ogarnia X?”, masz odpowiedź pod ręką. To przyspiesza twoje działanie i odciąża zespół.

Dobry start zmniejsza liczbę nieporozumień

Dobrze przepracowany pierwszy tydzień nie sprawi, że nagle znasz cały system. Sprawi natomiast, że zamiast chaosu masz ramy: wiesz, kogo pytać, gdzie szukać informacji, jakie są twoje cele na okres próbny. Odpada spora część „szumu komunikacyjnego”, a zostaje czysta praca i nauka.

Priorytety na okres próbny: co jest ważne, a co tylko przeszkadza

Trzy główne osie priorytetów

Świadome wybieranie tego, co naprawdę dowozi wartość

Wyobraź sobie osobę, która przez trzy miesiące perfekcyjnie ustawia swój edytor, czyści backlog własnych zadań i pisze idealnie sformatowane notatki – ale ma na koncie tylko jeden większy ticket. Obok niej ktoś, kto ma przeciętną konfigurację środowiska, za to regularnie zamyka zadania, naprawia realne błędy i potrafi wytłumaczyć, nad czym pracuje. Zgadnij, kto dostaje pozytywną decyzję po okresie próbnym.

Na okresie próbnym bardziej liczy się kierunek i tempo przybliżania do wartości niż „estetyka” twojej pracy. Priorytety dobrze jest ułożyć tak, by twoja energia szła w trzy główne obszary.

• Wartość dla zespołu i produktu – każde zadanie, które realnie coś poprawia: naprawia buga, usprawnia proces, przybliża funkcję do releasu.
• Budowanie samodzielności – każda rzecz, dzięki której jutro zadasz o jedno pytanie mniej, a zrobisz o jedno zadanie więcej bez prowadzenia za rękę.
• Widoczność efektów – nie chodzi o lans, tylko o czytelne sygnały: „to zrobiłem, tak pomogło projektowi”. Manager, który tego nie widzi, nie jest w stanie cię obronić.

Jeśli masz wątpliwość, czy czymś się zająć, zapytaj siebie: „Czy to komuś konkretnemu ułatwi życie w ciągu najbliższych 2–4 tygodni?”. Jeśli odpowiedź brzmi „nie” albo „może kiedyś”, schowaj to na później.

Rzeczy, które kuszą, ale nie pomagają przejść okresu próbnego

Prawie każdy na starcie łapie się na aktywnościach, które wyglądają jak praca, ale nie przesuwają cię bliżej pozytywnej decyzji. Zwykle wynikają z chęci „dobrego wrażenia”, tylko że inwestujesz je w złym miejscu.

Najczęstsze pułapki:

• Przeinwestowanie w tooling – tydzień na customowe motywy w IDE, aliasy do terminala i testowanie pięciu menedżerów zadań. Ustaw środowisko tak, by nie przeszkadzało, a potem dotykaj go tylko wtedy, gdy faktycznie blokuje cię w pracy.
• Perfekcjonizm w drobiazgach – spędzasz godziny nad nazewnictwem zmiennych, a potem okazuje się, że cała funkcja jest do wyrzucenia, bo zmieniono wymagania. Na początku ważniejsze jest złapanie poprawnego przepływu danych niż dopieszczanie ostatniego szczegółu.
• „Nauczę się wszystkiego naraz” – kurs Kubernetes, dwie książki o DDD i maraton z tutorialami frontendu w jednym tygodniu. Skup się na tym, co jest używane w twoim projekcie teraz, a nie „kiedyś może się przyda”.
• Nadmierne pomaganie wszystkim – chcesz być „team playerem”, więc łapiesz każde poboczne zadanie, pomagasz w konfiguracji innym, ogarniasz spotkania. Fajne, ale jeśli kosztem twoich głównych ticketów – szkodzi.

Dobrą praktyką jest zadawanie liderowi krótkiego pytania przy wątpliwości: „Mam X godzin. Co w tym czasie da największą wartość dla projektu: A, B czy C?”. Od razu widać, czy nie wpadłeś w boczny tor.

Jak ustawić cele na okres próbny, które mają sens

Scenka jest prosta: na rozmowie wstępnej deklarujesz, że „po trzech miesiącach chcę znać cały system”. Po dwóch tygodniach okazuje się, że system ma kilkadziesiąt serwisów i pięć zespołów. Zamiast motywacji – frustracja. Cel był odklejony od rzeczywistości.

Lepsze są cele, które łączą się bezpośrednio z konkretnymi obszarami projektu i dają się zmierzyć bez skomplikowanych KPI. Przykłady:

• „Do końca drugiego miesiąca samodzielnie dowiozę 3–4 zadania średniej wielkości w module płatności, od analizy po deploy.”
• „Będę w stanie wytłumaczyć nowej osobie, jak działa nasz proces CI/CD dla backendu i gdzie szukać logów po nieudanym deployu.”
• „Do końca okresu próbnego regularnie dodaję testy do wszystkich swoich zmian (unit/integracyjne – zgodnie z praktyką zespołu) i nie ma zwrotek na code review za ich brak.”

Takie cele możesz potem zderzyć z liderem: „Czy te trzy rzeczy byłyby dobrym wyznacznikiem, że okres próbny idzie w dobrym kierunku?”. Otrzymujesz korektę, a jednocześnie twój przełożony widzi, że poważnie traktujesz własny rozwój i oczekiwania firmy.

Komunikacja z liderem: jak nie być „czarną skrzynką”

Największe obawy managera wobec osoby na okresie próbnym rzadko dotyczą pojedynczego błędu w kodzie. Bardziej boi się sytuacji, w której przez dwa tygodnie nic o tobie nie wie, a potem nagle wychodzi, że zadanie stoi, bo czekałeś na kogoś z pytaniami. Brak komunikacji wygląda jak brak kontroli.

Dobry kierunek: stać się osobą, o której lider może powiedzieć „wiem, nad czym pracuje, gdzie jest i czego potrzebuje, żeby ruszyć dalej”. To się dzieje przez kilka prostych nawyków.

• Krótki, konkretny status na daily – zamiast „dalej robię taska”, powiedz: „Wczoraj ogarnąłem integrację z serwisem X, zostało mi dodanie walidacji i testów. Szacuję, że dziś skończę, chyba że pojawią się problemy z Y”.
• Wczesne sygnalizowanie problemów – jeśli od dwóch godzin tkwisz na tej samej rzeczy i nie widać przełomu, daj znać: „Próbowałem A i B, nie działa. Potrzebuję 15 minut z kimś, kto zna moduł Z, żeby się odblokować.”
• Domykanie zadań komunikatem – po merge’u lub deployu napisz krótką wiadomość na odpowiednim kanale: „Ticket ABC-123 gotowy, pokryty testami X, wpływa na endpoint Y. W razie problemów – dajcie znać.”

Jeśli masz regularne 1:1, wykorzystuj je: przygotuj krótką listę tematów – co poszło dobrze, gdzie się zaciąłeś, jakie decyzje chciałbyś skonsultować. Spotkania bez agendy kończą się pogadanką, która niewiele wnosi do twojej sytuacji na okresie próbnym.

Komunikacja z zespołem: jak pytać, żeby nie „zjadać” innym czasu

Wiele osób na starcie boi się zadawać pytania, żeby nie wypaść na nieogarniętych. Potem kończy się na tym, że przez pół dnia błądzą po repo, zamiast dostać 5-minutowe naprowadzenie. Kluczem jest forma pytania i moment, w którym je zadajesz.

Kilka zasad, które budują zaufanie, zamiast je zjadać:

• Pokaż, co już sprawdziłeś – zamiast „Nie działa mi build, co robić?”, napisz: „Build pada na kroku X w Jenkinsie, sprawdziłem logi Y i Z, ale nie widzę przyczyny. Czy ktoś może rzucić okiem lub podpowiedzieć, gdzie jeszcze szukać?”.
• Grupuj pytania – jeśli temat nie jest krytyczny, zbierz kilka kwestii i dopytaj je hurtem na krótkim callu. To mniej przerywa innym pracę niż 10 pojedynczych wiadomości rozrzuconych po dniu.
• Szanuj tryb pracy zespołu – jeśli ktoś ma w statusie „deep work” albo „focus”, lepiej napisać: „Gdy będziesz miał wolną chwilę, potrzebuję 10 minut o module X. Daj znać, kiedy ci pasuje.”

Zespół dużo chętniej pomaga osobie, która pokazuje, że inwestuje własny wysiłek w zrozumienie systemu, a nie tylko przerzuca problemy dalej. Szybko stajesz się kimś, komu opłaca się pomagać, bo widać efekt.

Jak prosić o feedback, który naprawdę coś zmienia

Scenariusz często wygląda tak: na koniec okresu próbnego pojawia się feedback, że „za mało komunikacji”, „za mało inicjatywy”, „warto popracować nad samodzielnością”. Problem w tym, że słyszysz to dopiero na finiszu, kiedy pole manewru jest minimalne. Lepsza strategia to wyciąganie takich sygnałów znacznie wcześniej.

Zamiast ogólnego „co o mnie sądzisz?”, zadawaj pytania, które zmuszają do konkretu:

• „Gdybyś miał wskazać jedną rzecz, którą powinienem poprawić w ciągu najbliższych dwóch tygodni, żeby lepiej dowozić, co by to było?”
• „Na tle innych osób na moim poziomie – w czym jestem najmocniejszy, a w czym najsłabszy?”
• „Czy jest coś, co cię niepokoi w mojej pracy przed końcem okresu próbnego?”

Druga strona ma wtedy trudniej z ucieczką w ogólniki. Nawet jeśli feedback jest nieprzyjemny, masz czas, żeby go przekuć w działanie: umówić dodatkowe sparingi, zmienić sposób raportowania statusów, wziąć na siebie konkretny obszar.

Szybkie wygrane: jak zaplanować pierwsze widoczne sukcesy

Dlaczego szybkie wygrane są tak ważne w IT

Pierwsze tygodnie często decydują o „etykietce”, jaką dostajesz w głowach ludzi. Jeśli przez trzy tygodnie widzą głównie to, że walczysz ze środowiskiem i wczytujesz się w dokumentację, zaczynają cię kojarzyć z osobą, która „ciągle się wdraża”. Z kolei jedna czy dwie dobrze dowiezione rzeczy potrafią przykryć sporo początkowego chaosu.

Szybka wygrana to nie musi być ogromna funkcja. To może być porządnie naprawiony bug, usprawniony skrypt, ogarnięty test, który wcześniej losowo padał. Ważne, żeby:

• była czytelna dla innych („dzięki temu X działa lepiej / szybciej / stabilniej”),
• była dowieziona od A do Z (nie tylko kod, ale też testy, opis, komunikacja),
• dała ci kontakt z realnym procesem w firmie (code review, deploy, flow z Jira).

Twoim celem w pierwszych 2–4 tygodniach powinno być zamknięcie kilku takich małych „pętli”: od zadania do efektu na środowisku. Dzięki temu rozumiesz, jak działa maszyneria, a zespół widzi, że dołączasz do gry.

Jak znaleźć zadania na „pierwsze sukcesy”

Nowa osoba często dostaje na początku trochę przypadkowych zadań: coś do naprawienia tu, coś do dopisania tam. Możesz jednak delikatnie sterować tym, co trafia na twoją tablicę, tak żeby maksymalizować szansę na szybkie, widoczne efekty.

Podczas rozmowy z liderem lub doświadczoną osobą z zespołu zapytaj wprost:

• „Jakie są małe, ale uciążliwe problemy, które wszyscy odkładają, a które mógłbym ogarnąć w najbliższych tygodniach?”
• „Czy jest jakiś fragment systemu, który wypadałoby wreszcie uporządkować i który jest dobrym miejscem na start?”

Bardzo często usłyszysz o:

• starych, irytujących bugach, których nikt nie miał czasu ruszyć,
• brakujących testach wokół krytycznych funkcji,
• powtarzalnych, ręcznych czynnościach, które można częściowo zautomatyzować,
• małych poprawkach w logowaniu, monitoringach czy alertach.

To idealne pola do pierwszych sukcesów. Są stosunkowo małe, ale ich efekt odczuwa cały zespół. Łatwo potem powiedzieć przy podsumowaniu okresu próbnego: „Poprawiłem X, Y, Z – to są rzeczy, które wcześniej wszystkim przeszkadzały na co dzień”.

Projektowanie szybkiej wygranej krok po kroku

Załóżmy, że trafił do ciebie stary bug w module, z którym jeszcze nie pracowałeś. Możesz podejść do niego na dwa sposoby. Pierwszy: siadasz, kopiesz w kodzie, po dwóch dniach nadal tkwisz, a nikt nie wie, na jakim etapie jesteś. Drugi: rozbijasz to na małe, komunikowalne kroki.

Przykładowy plan:

1. Zrozumienie problemu – prosisz o krótki call z osobą, która zgłaszała buga lub go zna, pytasz o kontekst, sprawdzasz logi, odtwarzasz błąd lokalnie lub na środowisku testowym.
2. Hipoteza i plan – zapisujesz sobie (choćby w komentarzu w Jira), gdzie widzisz potencjalną przyczynę i co zamierzasz zmienić. Dzielisz się tym na kanale projektowym: „Podejrzewam, że to wynik X, spróbuję Y. Jeśli ktoś widzi ryzyko, dajcie znać.”
3. Implementacja i testy – wprowadzasz zmianę w najmniejszym możliwym zakresie, dodajesz test odtwarzający błąd, sprawdzasz behavior przed/po.
4. Code review i poprawki – nie walczysz z uwagami, tylko dopytujesz tam, gdzie nie rozumiesz. To ważne: sposób, w jaki reagujesz na review, jest często baczniej obserwowany niż sam kod.
5. Deploy i domknięcie – doprowadzasz sprawę do końca: upewniasz się, że zmiana trafiła na odpowiednie środowisko, a wynik jest zakomunikowany osobom, które na to czekały.

Przy takim podejściu nawet jeśli po drodze coś nie wyjdzie, całościowo wygląda to jak dobrze poprowadzone zadanie: z komunikacją, odpowiedzialnością i świadomością ryzyka. Dla lidera to ważny sygnał na okresie próbnym.

Najczęściej zadawane pytania (FAQ)

Jak przetrwać okres próbny jako programista bez poczucia, że się „nie nadaję”?

Pierwsze tygodnie często wyglądają jak chaos: nowe narzędzia, skróty, procesy, a ty masz wrażenie, że wszyscy wiedzą, co robią, tylko nie ty. To normalne – większość osób przechodzi przez etap „przyłapania na niewiedzy”, tylko mało kto o tym głośno mówi.

Żeby przejść przez okres próbny bez zajechania się psychicznie, skup się na trzech rzeczach: jasnych priorytetach (co jest najważniejsze dziś/ten tydzień), regularnej komunikacji z liderem (co robisz, z czym masz problem) oraz małych, widocznych efektach – nawet jeśli to „tylko” poprawka w dokumentacji czy proste zadanie z Jiry. Gdy codziennie przesuwasz choć jedną rzecz do „Done” i mówisz, na jakim etapie jesteś, presja maleje, a twoja przewidywalność rośnie.

Czego firma realnie oczekuje od programisty po okresie próbnym?

Większość firm nie oczekuje po 3 miesiącach „gwiazdy architektury”, tylko osoby, na której można polegać. Manager patrzy, czy jesteś przewidywalny: jeśli mówisz, że coś dowieziesz do piątku, to albo dowozisz, albo wcześniej sygnalizujesz, że się opóźni i dlaczego.

Po okresie próbnym pracodawca chce zobaczyć, że:

• samodzielnie ogarniasz typowe zadania z backlogu,
• twój kod po kilku review ma coraz mniej poprawek i nie powtarzasz tych samych błędów,
• komunikujesz postępy i blokery, nie znikasz na kilka dni,
• da się z tobą normalnie współpracować, bez ciągłych spięć i tłumaczenia po sto razy procesów.

To jest minimum „opłacalności”, które waży więcej niż znajomość kolejnego frameworka.

Czym różnią się oczekiwania wobec juniora, mida i seniora na okresie próbnym?

Junior często myśli, że musi „udowodnić, że jest seniorem w ciele juniora”, a senior czasem zachowuje się jak mid, który czeka na zadania z góry. To prosta droga do rozczarowania po obu stronach.

Najczęstszy podział wygląda tak:

• Junior – ma szybko łapać kontekst projektu, zadawać pytania i realizować proste zadania z coraz mniejszą pomocą. Liczy się tempo nauki i otwartość na feedback.
• Mid – ma dowozić zadania end-to-end, ogarniać proces (Jira, code review, deploye) i sensownie szacować czas. Dla firmy ważna jest przewidywalność i jakość.
• Senior – ma brać odpowiedzialność za fragment systemu, inicjować usprawnienia i wspierać słabszych członków zespołu. Tu ocenia się wpływ na decyzje techniczne i resztę zespołu.

Jeśli oczekujesz od siebie „poziomu wyżej”, łatwo wpaść w frustrację. Lepiej dowieźć wzorcowo swój poziom i pokazać, że stać cię na krok dalej.

Co mówić na stand-upach i w komunikacji, żeby dobrze wypaść na okresie próbnym?

Wielu nowych devów na pierwszych stand-upach mówi: „pracuję nad zadaniem X” i tyle, bo boją się zabrzmieć nieprofesjonalnie. Efekt jest taki, że po kilku dniach nikt nie wie, czy utknęli, czy po prostu wolno idzie.

Bezpieczny i profesjonalny schemat to: co zrobiłem – co robię – czego potrzebuję. Np.: „Wczoraj udało mi się postawić projekt lokalnie i przejrzeć flow logowania. Dziś implementuję walidację formularza. Blokuje mnie brak dostępu do serwisu Y – zgłosiłem to już do admina, dam znać, gdy będzie odblokowane”. Taki komunikat pokazuje, że pchasz tematy do przodu, widzisz przeszkody i reagujesz, zamiast cichutko tonąć.

Jakie „szybkie wygrane” mogę pokazać w pierwszych tygodniach pracy w IT?

Na starcie nie musisz robić epickich feature’ów. Dużo lepsze wrażenie robi kilka małych, domkniętych tematów niż jeden gigant, który wisi otwarty trzy tygodnie. Szybkie wygrane to sygnał, że umiesz dowozić.

Typowe przykłady:

• naprawa drobnego buga zgłoszonego przez support,
• dodanie brakującego testu do istniejącej funkcji,
• uzupełnienie dokumentacji o krok, którego brakowało przy uruchamianiu projektu lokalnie,
• uporządkowanie małego fragmentu kodu przy okazji innego zadania (refactor „po drodze”, nie rewolucja).

Takie rzeczy są widoczne w Jirze, w repo i w oczach zespołu. Po miesiącu masz już historię małych, konkretnych efektów.

Jak reagować, gdy czegoś nie umiem lub popełnię błąd w czasie okresu próbnego?

Największy strach na okresie próbnym to „wyjdzie, że jestem słaby”. Paradoks polega na tym, że dużo gorzej wygląda ktoś, kto udaje, że wszystko ogarnia, a potem po cichu psuje produkcję, niż osoba, która wcześnie przyznaje: „tego nie robiłem, potrzebuję wsparcia na start”.

Dobrą praktyką jest jasny komunikat: „To dla mnie nowe, spróbuję sam i dam znać, jeśli utknę”. Jeśli po kilku godzinach naprawdę stoisz w miejscu, pokaż, co już sprawdziłeś, jakie logi przejrzałeś, do jakich wniosków doszedłeś. Przy błędach zadziała podobny schemat: przyznanie się, opisanie skutków, co już zrobiłeś, żeby je ograniczyć, i czego potrzebujesz dalej. Dla managera to sygnał odpowiedzialności, a nie słabości.

Co zrobić w pierwszym tygodniu pracy w IT, żeby dobrze ustawić resztę okresu próbnego?

Pierwszy tydzień często znika na „czekaniu na dostępy” i scrollowaniu Slacka. Z perspektywy lidera wygląda to potem jak brak inicjatywy, nawet jeśli to proces w firmie kuleje.

Na starcie dopilnuj trzech rzeczy:

• Dostępy i środowisko – pilnuj, by jak najszybciej mieć repo, Jirę, komunikator, dokumentację i działający projekt lokalnie. Jeśli czegoś brakuje, pisz konkretnie: „Nie mam jeszcze dostępu do X, przez to nie mogę zrobić Y”.
• Mapa projektu – poproś o krótkie wprowadzenie do architektury, głównych serwisów i procesu developmentu. Zrób własne notatki, bo później do nich wrócisz.
• Ustalenie oczekiwań – dopytaj lidera, po czym za 3 miesiące pozna, że okres próbny uzna za udany. Zapisz to i co tydzień sprawdzaj, czy twoje zadania się z tym kleją.

Taki start sprawia, że nie drepczesz w miejscu i od początku budujesz obraz osoby, która ogarnia swoją stronę odpowiedzialności.