Dorzucam kolejnych parę groszy ze swej strony w sprawie tworzenia gier 😊🎮! Poruszymy teraz kwestię tworzenia zespołowego, czyli coś, co jest rzeczą niemożliwą do przeskoczenia, gdy zakres projektowy przewyższa zdolności fizyczne jednostki 🙂. Pokażę Ci 4 zasady tworzenia gry w zespole jakich zalecam się trzymać w codziennej pracy, tak aby nie zostać posądzonym o jakiś sabotaż (a nawet o nim nie wiesz) 😄! Zapraszam!
POZNAJ 4 ZASADY TWORZENIA GRY W ZESPOLE!
Zaczynamy. Zasady są głównie skierowane w stronę pracy u kogoś komercyjnie 💲, jednak możesz oczywiście wdrożyć je również, gdy tworzysz grę razem ze znajomymi albo podczas "game jamu" 👍.
Zasada 1: Uzgadniaj, zanim coś zrobisz
Tworząc grę samemu, jesteś jej panem i władcą 👑😁. Kiedy tworzysz ją z innymi, to masz liczyć się ze zdaniem reszty ⚠️! W praktyce oznacza to następującą rzecz: kiedy przyjdzie Ci do głowy jakiś pomysł, to od razu przedstaw go całej reszcie!
Od razu na dzień dobry pociąga to za sobą dużo korzyści 👇:
- Pokazujesz, że liczysz się ze zdaniem innych ✅,
- Możesz się dowiedzieć, że ten pomysł już dawno został wdrożony ✅,
- Ktoś z zespołu może zasugerować swoje propozycje jako drobne lub większe poprawki ✅,
- Nie narażasz się na samowolkę, która będzie postrzegana negatywnie ✅.
To się tyczy nie tylko pomysłów na implementację czy usunięcie błędu 🐛. Również w takich sprawach, jak to, którym zadaniem się teraz zająć, należy wszystko uzgadniać z przełożonymi i resztą załogi ‼️.
Zatajenie swoich zamiarów i próba dodania ich do gry "cichaczem", sprawi że ściągniesz na siebie same kłopoty i staniesz się piątym kołem u wozu 😱!!! Nikt nie będzie tolerował kogoś, kto wprowadza do projektu zmiany, nawet o tym nie informując 👎.
Zasada 2: Kolejność to świętość
Dobrze prowadzony projekt przez doświadczoną osobę, to przede wszystkim organizacja, notowanie i monitorowanie pozostałych zadań do wykonania.
Wypisywanie zadań na bieżąco, to rzecz święta ✅. Wyznaczanie tych właściwych odpowiednim pracownikom, również "Święty Graal" ✅. Pilnowanie się priorytetów przez pracowników, to jest trzecia "świętość" ✅!!!
Jeżeli np. jako programista, dostajesz 2 zadania i szefostwo mówi Ci, że najpierw zadanie A, a potem zadanie B, to rób wszystko, żeby się nie skusić i nie przejść do zadania B bez skończenia pracy nad zadaniem A! Jeżeli lider nie jest konowałem, to z pewnością ma swoje powody, żeby w taki sposób nałożyć priorytet wszystkim zadaniom, a nie inny 🔥!
Co innego, gdy zakończyłeś(-aś) wykonywanie zadania A i czekasz na potwierdzenie od "góry" – to to jest inna postać rzeczy 😁. Wtedy jak najbardziej wskazane jest przejście do kolejnego zadania w liście! W ten sposób pokażesz, że dobrze zarządzasz czasem ⌚ i jesteś w stanie wykonać więcej podczas pracy na etacie 💪.
Zasada 3: Multitasking does not exist!
Wielozadaniowość (ang. multitasking) określa teoretyczną zdolność pracownika do wykonywania wielu rzeczy w tym samym czasie. Napisałem "teoretyczną", nie bez przyczyny 😮.
Pracowanie nad wieloma sprawami jednocześnie, to mit ⛔! Wymaż to słowo ze swojej świadomości najprędzej, jak potrafisz!!! Zamiast tego, postaw na koncentrację na JEDNYM zadaniu, które masz wysunięte jako pierwsze na liście i nie opuszczaj go za cholerę, dopóki nie ukończysz go w 100% 💯!
Zasada 4: Pytaj tylko w ostateczności
Jest takie porzekadło: "kto pyta, nie błądzi". To jak najbardziej prawdziwe ✔️. Natomiast, gdy mowa o pracy zespołowej nad projektem, musisz zmienić myślenie i nieco "przerobić" to przysłowie na następujące:
"Kto pyta, gdy NAPRAWDĘ czegoś nie wie bądź nie może się dowiedzieć, nie błądzi. W pozostałych przypadkach popełnia wielki błąd!"
Traktuj zadawanie pytań jak ograniczony surowiec, który masz prawo wykorzystać tylko na czarną godzinę ⚫. Chcę przez to podkreślić, żebyś unikał(a) zawracania głowy innym członkom zespołu w sytuacji, gdy MOŻESZ sam(a) poznać odpowiedź na dane pytanie (albo chociaż spróbować) np. przeglądając internet, przeglądając pliki projektu lub uruchamiając test gry.
Nigdy nie pytaj "na pałę"! Miej zawsze przed oczami scenariusz osób, które zamiast zajmować się swoimi zadaniami, muszą "obsłużyć" Twoje pytanie, tak żebyś tylko mógł/mogła podziękować i "cześć" ✋. Zadawaj pytania, lecz tylko wtedy, gdy ktoś posiada nigdzie nieudokumentowaną wiedzę na temat czegoś specyficznego. Jeżeli na przykład inny programista w zespole napisał system do poruszania się NPC po mapie, a Twoja implementacja dotyczy gonienia gracza przez przechodniów, to pytanie o to, jak przebiega ustalanie punktu docelowego (po uprzednim przejrzeniu całego kodu źródłowego i niemożności jednoznacznego wywnioskowania samodzielnie), będzie jak najbardziej uzasadnione 👍.
Postaraj się jak najszybciej wcielić te 4 zasady komunikacji w zespole w praktyce, gdyż kompetencje miękkie to druga strona medalu niezbędnych umiejętności w pracy komercyjnej i to nie tylko w branży gier 🔔! Dzięki za przeczytanie 👍!