Analiza danych jakościowych - kodowanie i kategoryzacja
Wprowadzenie do metodologii badań społecznych
Cel ćwiczenia
To ćwiczenie ma na celu praktyczne zastosowanie wiedzy z wykładu o analizie jakościowej. Przeprowadzicie proces kodowania i kategoryzacji na podstawie fragmentu wywiadu z osobą opisującą swoje doświadczenia z pierwszą pracą zawodową.
Instrukcje
Praca: W grupach 3-4 osobowych
Czas: 30 minut
Zadanie:
- Runda 1: Kodowanie odkrywcze (20 minut)
- Przeczytajcie uważnie fragment wywiadu
- Zakodujcie tekst - nadajcie nazwy (kody) poszczególnym fragmentom
- Zapiszcie kody w tabeli wraz z krótkimi notatkami
- Runda 2: Organizacja kodów w kategorie (10 minut)
- Przejrzyjcie wszystkie kody
- Zgrupujcie podobne kody w większe kategorie
- Nadajcie kategoriom jasne, opisowe nazwy
- Wybierzcie kluczowy cytat dla każdej kategorii
Fragment wywiadu
Respondent: Piotr, 25 lat, absolwent informatyki
Temat: Doświadczenia z pierwszą pracą zawodową (junior developer w firmie software’owej)
Kontekst: Piotr pracuje w swojej pierwszej pełnoetatowej pracy od 8 miesięcy.
Badacz: Opowiedz mi, jak wyglądały twoje pierwsze dni w pracy?
Piotr: No to był… [pauza] …szok. Kompletny szok. Na studiach programowałem sobie mniejsze projekty, wszystko działało na moim komputerze, miałem czas żeby wszystko dopieścić. A tu pierwsze zadanie dostałem po dwóch dniach - “napraw ten bug w produkcji”. Ja patrzę na kod, kilkaset tysięcy linijek, framework’i, których nigdy nie widziałem, architektura jakby z kosmosu. Pomyślałem sobie “co ja tu w ogóle robię, przecież ja tego nie rozumiem”. Czułem się jak idiota.
Badacz: Jak poradziłeś sobie z tym uczuciem?
Piotr: Pierwsze tygodnie to była gehenna, nie będę kłamał. Przychodziłem rano do biura i miałem taki… nie wiem… stres w brzuchu. Bałem się pytać, bo myślałem że wszyscy pomyślą “a co to za idiota wzięli”. Siedziałem po godzinach, próbowałem sam sobie z tym poradzić. Czasami spędzałem cztery, pięć godzin nad problemem, który senior rozwiązałby w piętnaście minut.
Ale w trzecim miesiącu stało się coś ważnego. Kolega z zespołu, Maciek, senior developer, zauważył że siedzę po godzinach. Podszedł i zapytał “co jest grane”. Powiedziałem mu że nie kumam jednego API. On się uśmiechnął i mówi “czekaj, pokażę ci”. I przez godzinę mi tłumaczył jak to wszystko działa, pokazał dokumentację wewnętrzną, której ja w ogóle nie znalazłem. I na końcu powiedział coś ważnego: “Jak masz problem, to pytaj. Wszyscy przez to przechodzą. Ja też byłem juniorem i też nic nie kumałem”.
To było jak… [pauza] …wiesz… jak jakieś uwolnienie. Od tego momentu zacząłem pytać. I okazało się, że ludzie chcą pomagać. Nikt nie patrzy na ciebie jak na idiotę. Oni pamiętają jak to jest być nowym.
Badacz: Co się zmieniło od tamtej pory?
Piotr: Teraz? Teraz czuję się o wiele pewniej. Nie mówię że jestem ekspertem, nie jestem. Ale wiem co robić. Jak coś nie działa, to potrafię sobie poradzić - debuguję, czytam dokumentację, pytam jak muszę. Nie siedzę już po godzinach sam. Wiem kto za co odpowiada, do kogo iść z jakim problemem.
I co najważniejsze - zrozumiałem, że ta praca to nie tylko kod. To ludzie. To komunikacja. Jak zaczynałem, myślałem że będę cały dzień programować. A tymczasem połowa czasu to daily stand-upy, code review, dyskusje na Slacku, pair programming. Musiałem nauczyć się komunikować co robię, tłumaczyć swoje decyzje, przyjmować feedback.
Najtrudniejsze dla mnie było code review. Pierwszy raz jak senior zostawił mi dziesięć komentarzy do mojego kodu, to odebrałem to osobiście. “Mój kod jest do dupy, jestem do niczego”. Ale potem zrozumiałem, że to nie jest atak personalny. To jest po prostu część procesu. Oni chcą żebym się uczył, żeby kod był lepszy. Teraz nawet lubię code review, bo zawsze się czegoś uczę.
Badacz: Wspomniałeś o uczeniu się. Jak to wygląda w twojej firmie?
Piotr: To jest super. Firma daje nam tzw. “learning budget” - możemy wydać określoną kwotę na kursy, konferencje, książki. Ja kupiłem sobie kurs o Docker i Kubernetes. Ale najważniejsze uczenie się to nie z kursów - to z codziennej pracy. Jak patrzę na kod seniora, jak widzę jak on rozwiązuje problemy, to uczę się więcej niż z jakiegokolwiek kursu.
Jeden z seniorów, Ania, prowadzi takie nieformalne sesje we piątki - “knowledge sharing”. Ktoś przedstawia jakąś technologię, jakiś problem który rozwiązał, albo po prostu ciekawostkę. Ja niedawno pokazywałem jak debugowałem dziwnego buga w pamięci. Pół godziny prezentacja, potem dyskusja. Super sprawa.
Badacz: A jakie widzisz wyzwania teraz, po tych ośmiu miesiącach?
Piotr: Wyzwań jest sporo. Jednym z największych jest… [pauza] …to że czasami tracę perspektywę czasu. Dostanę zadanie, powiem “zrobię to w dwa dni”, a mija tydzień i nadal nie skończyłem. Trudno jest oszacować ile coś zajmie, zwłaszcza jak napotkasz jakiś nieoczekiwany problem. Tego nadal się uczę.
Drugim wyzwaniem jest presja. Nasza firma pracuje w sprintach dwutygodniowych i jest czasami stresujące, jak zbliża się koniec sprintu a ty masz niezrobione zadania. Czujesz, że zawiodłeś zespół. Choć tak naprawdę wszyscy mówią “nie ma stresu, przeniesiemy do następnego sprintu”, ale ja czuję tę odpowiedzialność.
I trzecie - work-life balance. Jak bardzo się wciągnąłem w tę pracę, to zacząłem myśleć o niej non-stop. W weekend siedzę i myślę “jak rozwiążę ten problem”, “może powinienem spróbować tej biblioteki”. Z jednej strony super, bo to znaczy że mi się podoba ta praca. Z drugiej… czasami muszę się wyłączyć, bo inaczej się wypalę.
Badacz: Jak radzisz sobie z tym balansem?
Piotr: Uczę się stawiać granice. Teraz jak kończę pracę, to zamykam laptopa i nie otwieram do następnego dnia. No, prawie nie otwieram [śmiech]. Czasami w weekend coś zerknę, ale staram się nie pracować. Zacząłem też chodzić na siłownię trzy razy w tygodniu - to mi pomaga się “odciąć” od pracy.
I co ciekawe - odkryłem że jak mam lepszy work-life balance, to jestem bardziej produktywny. Jak wracam do pracy wypoczęty, to myślę jaśniej, szybciej rozwiązuję problemy. Jak jestem przemęczony, to mogę siedzieć nad prostym bugiem pół dnia.
Badacz: Patrząc wstecz, co byś powiedział sobie z przed ośmiu miesięcy, jak zaczynałeś?
Piotr: Przede wszystkim: “Pytaj więcej”. Nie ma wstydu w pytaniu. Najgorszą rzeczą jaką możesz zrobić to udawać że wiesz, albo siedzieć cicho ze strachem. Wszyscy byli kiedyś juniorami.
Drugie: “To jest maraton, nie sprint”. Na początku myślałem że muszę wszystko wiedzieć od razu, że muszę być na poziomie seniorów. Ale oni mają dziesięć lat doświadczenia. Ja dopiero zaczynam. Trzeba być cierpliwym do siebie.
I trzecie: “Ludzie są ważniejsi niż kod”. Można być najlepszym programistą na świecie, ale jak nie potrafisz pracować w zespole, komunikować się, przyjmować feedbacku, to niewiele z tego będzie. Praca to nie tylko techniczne umiejętności. To relacje, zaufanie, współpraca.
Ogólnie? Jestem zadowolony. Była ciężka, była stresująca, ale czuję że się rozwijam. Każdy dzień uczę się czegoś nowego. I to jest fajne uczucie.
Arkusz pracy - Runda 1: Kodowanie
Zakodujcie fragment wywiadu, nadając nazwy poszczególnym fragmentom tekstu. Przykład:
| Fragment tekstu | Kod | Notatka |
|---|---|---|
| “Kompletny szok… miałem czas żeby wszystko dopieścić. A tu pierwsze zadanie…” | KONTRAST STUDIA-PRACA | Różnica między środowiskiem akademickim a zawodowym |
Wskazówki:
- Jeden fragment może mieć wiele kodów
- Kody powinny być opisowe, ale zwięzłe
- Używajcie słów respondenta gdy możliwe (in vivo coding)
- Kodujcie zarówno emocje jak i doświadczenia
- Nie interpretujcie zbyt szybko - trzymajcie się blisko tekstu
Arkusz pracy - Runda 2: Kategorie
Zgrupujcie podobne kody w większe kategorie. Przykład:
Kategoria 1: [Nazwa kategorii]
Definicja: [Krótki opis czego dotyczy ta kategoria]
Kody składowe: - [Kod 1] - [Kod 2] - [Kod 3] - …
Liczba kodów: [X]
Kluczowy cytat: “[Fragment wywiadu najlepiej ilustrujący tę kategorię]”
Kategoria 2: [Nazwa kategorii]
Definicja: [Krótki opis czego dotyczy ta kategoria]
Kody składowe: - [Kod 1] - [Kod 2] - …
Liczba kodów: [X]
Kluczowy cytat: “[Fragment wywiadu najlepiej ilustrujący tę kategorię]”
Kategoria 3: [Nazwa kategorii]
[I tak dalej…]
Wskazówki:
- Szukajcie kodów które mówią o podobnych rzeczach
- Kategorie powinny być szersze niż kody, ale nie zbyt ogólne
- Dobrze jest mieć 5-10 kategorii
- Każda kategoria powinna mieć jasną definicję
- Cytaty powinny być krótkie (2-4 zdania) i reprezentatywne