W symulacji rekrutacji IT uczestnik nie musi szukać osoby z najwyższym wynikiem programowania. Może decydować, jakie kompetencje są potrzebne do konkretnego projektu, ile informacji zebrać i czy zespół ma możliwości wdrożenia nowej osoby. To właśnie powiązanie zatrudnienia z warunkami firmy nadaje ćwiczeniu sens.
Zacznij od pytania, które ma ujawnić ćwiczenie
Dobrym celem jest prześledzenie kompromisu między szybkim zatrudnieniem a dokładniejszą oceną albo między gotowością do pracy a nakładem na wdrożenie. Jeden scenariusz nie musi jednocześnie modelować całej gospodarki, wynagrodzeń i zarządzania produktem.
Ustal horyzont gry oraz to, co uczestnik widzi. Podaj zasady budżetu i dostępne działania przed decyzją. Jeżeli ważna informacja jest ukryta, musi istnieć przemyślany sposób jej pozyskania albo jawnie określona niepewność.
Autorski przykład: projekt za sześć tygodni
Poniższy scenariusz jest fikcyjny. Zespół potrzebuje uruchomić funkcję aplikacji w sześć tygodni. Ma ograniczony budżet i mentora, który może przeznaczyć tylko część czasu na wdrożenie. Pojawiają się trzy profile:
| Profil | Znana mocna strona | Warunek do sprawdzenia |
|---|---|---|
| A | Doświadczenie w podobnym zadaniu | Termin dostępności i wymagany budżet |
| B | Szybka dostępność i podstawowe umiejętności | Zakres wsparcia mentora |
| C | Doświadczenie w innej technologii | Czas poznania używanego środowiska |
Te profile opisują warunki modelu, nie reguły oceny rzeczywistych ludzi. Warto unikać cech niezwiązanych z zadaniem i jednej zbiorczej liczby „wartość kandydata”. Uczestnik powinien móc zobaczyć, co dokładnie wpłynęło na wynik.
Informacja kosztuje turę lub zasób
Dodatkowa rozmowa, zadanie lub sprawdzenie dostępności może odsłonić nowe dane. W scenariuszu przypisz takiej czynności koszt czasu albo budżetu. Uczestnik porównuje wtedy wartość informacji z opóźnieniem decyzji.
Przykładowo można ujawnić, że A zacznie dopiero w trzecim tygodniu, a B wymaga większej liczby godzin mentora, niż początkowo założono. Nie traktuj ujawnienia jak losowej kary: powinno wynikać z przygotowanego profilu i sposobu badania.
Jeżeli można bez końca zbierać informacje bez kosztu, wybór szybko staje się oczywisty. Z drugiej strony kara za każde pytanie może promować pośpiech. Balans powinien pozwalać porównać kilka rozsądnych strategii.
Skutki pokaż po zatrudnieniu
W kolejnych turach modeluj dostępny czas pracy, wdrożenie i obciążenie mentora. Wynik pierwszego tygodnia nie powinien automatycznie przesądzać całej symulacji. Początkowo trudniejszy wariant może przynieść inną korzyść w dłuższym horyzoncie, jeśli tak zdefiniowano model.
Raport powinien rozdzielać przyczyny: opóźniony start, brak określonej umiejętności, ograniczone wsparcie lub zmianę wymagań projektu. Sama liczba punktów nie wyjaśni uczestnikowi, co zmieniłby następnym razem.
Niepewność może pozostać częścią ćwiczenia, ale zapisz, które zdarzenia są losowe. Przy porównaniu strategii warto użyć tych samych warunków zewnętrznych, aby różnicy nie tworzył wyłącznie inny rzut losowania.
Omówienie jest częścią symulacji
Po zakończeniu poproś uczestników o wskazanie założenia, na którym oparli wybór, informacji wartej swojego kosztu i konsekwencji, której nie przewidzieli. Porównaj również wynik w alternatywnym horyzoncie lub przy większej dostępności mentora.
Sprawdź, czy wygrana wynikała z decyzji, czy ze znanego wcześniej skrótu w mechanice. Jeżeli jedna strategia zawsze dominuje, zmień scenariusz w zakresie potrzebnym do jego celu. Użyteczne ćwiczenie pozwala nazwać zależności, a jego wynik trzeba interpretować w granicach przyjętego modelu.
