Czego się nauczyłem, tłumacząc frontend devom deployment na AWS

Zrobiłem warsztat z backend deploymentu dla mojego frontendowego zespołu. Local → VPS → AWS. EC2, Docker, Nginx, SSL. Czyli rzeczy, które mnie naprawdę ciekawią i którymi chciałem się podzielić.

Przed spotkaniem wysłałem krótką ankietę: „Oceń swoją znajomość AWS w skali 1–10”.

Większość osób odpowiedziała 2–3. Jedna osoba dała sobie 6.

Myślałem, że mam plan. Nie miałem.

Ankieta skłamała — albo zadałem złe pytanie

W praktyce wyglądało to tak:

Grupa 2–3 czuła się zagubiona. Nie dlatego, że materiał był zły, tylko dlatego, że pominąłem podstawy. Czym właściwie jest VPS? Dlaczego nie użyć po prostu Vercela? Założyłem, że „frontend dev” oznacza „mniej więcej wie, jak działają serwery”. Nie zawsze oznacza.

Osoba, która zaznaczyła 6, chciała więcej. Więcej o sieciach, więcej o rolach IAM, więcej o Terraformie. Siedziała więc na slajdach, które dla niej były zbyt podstawowe.

Ten sam warsztat. Dwa zupełnie różne doświadczenia. I obie frustracje były uzasadnione.

Lekcja nie była techniczna. Była o kalibracji.

O co powinienem był zapytać

„Oceń swoją znajomość AWS w skali 1–10” mówi bardzo niewiele.

Lepsze pytania:

• Czy kiedykolwiek logowałeś się na serwer przez SSH?
• Czy kiedykolwiek konfigurowałeś Nginx ręcznie?
• Czy wiesz, czym jest Security Group?

Odpowiedzi zero-jedynkowe. Konkretne umiejętności. Bez miejsca na zawyżoną samoocenę albo fałszywą skromność.

Miałem szansę zebrać dane, które pozwoliłyby mi zrobić naprawdę dobry warsztat — po prostu o nie nie zapytałem.

Problem z materiałem

Warsztat obejmował trzy środowiska: Local → VPS → AWS Cloud. Dla mnie ta progresja miała sens, bo sam przez nią przeszedłem. Ale dla kogoś, kto nigdy nie dotykał serwera, przejście od „mój laptop” do „komputer gdzieś we Frankfurcie” wcale nie jest oczywiste.

Z kolei dla osoby z realnym doświadczeniem w AWS tempo było zbyt wolne. Chciała rozmawiać o auto-scalingu i granicach IAM, a nie o tym, dlaczego trzeba otworzyć port 80 w Security Group.

Nie da się w czasie rzeczywistym podzielić jednego warsztatu na dwa różne poziomy. Ale da się uniknąć takiego niedopasowania, zanim warsztat w ogóle się zacznie.

Co zrobiłbym inaczej

Podzieliłbym grupę przed startem. Nawet krótka ankieta z trzema konkretnymi pytaniami o umiejętności pozwoliłaby mi rozdzielić uczestników — albo przynajmniej uczciwie ustawić oczekiwania dla każdego poziomu.

Projektowałbym pod najniższy poziom, nie pod medianę. Zagubiony początkujący traci całe spotkanie. Osoba bardziej zaawansowana może przejść do dodatkowych slajdów albo zadań. W drugą stronę to nie działa.

Powiedziałbym założenia na głos. „Ten warsztat zakłada, że nigdy wcześniej nie konfigurowałeś serwera” to pełne zdanie. Zajmuje pięć sekund, a oszczędza trzydzieści minut ludziom, którzy zastanawiają się, czy przypadkiem nie trafili do złej sali.

Co to ma wspólnego z prowadzeniem zespołu

W pracy robię to samo. Zakładam wspólny kontekst, którego czasem po prostu nie ma. Pomijam fundamenty, bo dla mnie wydają się oczywiste. Optymalizuję przekaz pod osobę na sali, która przypomina mnie sprzed trzech lat.

Dobre warsztaty i dobre techniczne przywództwo mają ten sam tryb awarii: mylenie własnej swobody w temacie z poziomem bazowym odbiorców.

Naprawa też jest ta sama — zadawaj lepsze pytania, zanim zaczniesz mówić.

Najbardziej przydatną rzeczą, jaką zrobiłem podczas tego warsztatu, nie było demo EC2. Był nią moment, w którym zatrzymałem się i zapytałem: „Czy wszyscy wiedzą, czym jest SSH?”. Połowa sali wyglądała, jakby właśnie odetchnęła z ulgą.