Komunikacja i praca zespołowa#

Dobra robota techniczna to za mało — liczy się też, jak pracujemy razem.

Praca w Git#

• Każda zmiana idzie przez Pull Request — main jest chroniony.
• Małe, częste PR-y > jeden wielki. Łatwiej je zrecenzować.
• Opis PR mówi co i dlaczego, nie tylko „fix".

git checkout -b feat/krotki-opis
# ...zmiany + commit (Conventional Commits: feat:, fix:, docs:)
git push -u origin feat/krotki-opis
gh pr create --fill

Code review#

• Recenzja to nauka dla obu stron — nie krytyka osoby.
• Komentuj kod, nie człowieka („ta funkcja może...", nie „źle zrobiłeś").
• Jako autor: odpowiadaj na komentarze, nie ignoruj.

Standard ProfessNet: kultura „no blame". Błąd w kodzie złapany w review to sukces procesu, nie porażka autora.

Kanały komunikacji#

• Teams — bieżąca komunikacja, kanały zespołowe.
• GitHub — wszystko związane z kodem (issues, PR, dyskusje techniczne).
• Spotkania — krótkie i konkretne; jeśli można mailem/czatem, to lepiej.

Zadawaj pytania#

• Najpierw spróbuj sam (dokumentacja, ta platforma, wyszukiwarka).
• Utknąłeś > 30 min? Pytaj. Czas zespołu jest cenny, ale Twój też.
• Pytanie + co już sprawdziłeś = najlepszy sposób na szybką pomoc.

Asynchronicznie i z szacunkiem#

Pracujemy w różnych godzinach i lokalizacjach. Pisz tak, by dało się odpowiedzieć później. Szanuj czas innych — i swój.

---

Gratulacje — ukończyłeś onboarding! Sprawdź wiedzę w quizie poniżej, a potem ruszaj na ścieżkę ZEUS — od zera do operatora. Powodzenia! 🚀