Ćwiczenie ma za zadanie ośmielić osoby do mówienia głośno i wyraźnie. Ma też pomóc ustawić głos. Bardzo przydatne przy spotkaniach typu stand-up, gdzie "mruki" opowiadają pod nosem, co ostatnio robiły. Z mojego doświadczenia - działa!
Osoby biorące udział w ćwiczeniu stają w okręgu. Wybieramy sobie słówko do powtarzania. Proponowana jest ryba, ale może to być dowolne inne, proste w wymowie słowo.
Prowadzący ustala kierunek i jako pierwszy mówi szeptem ryba. Następnie, kolejne osoby powtarzają rybę, aż do donośnego"RYBA. Jeśli warunki pozwalają, można nawet krzyczeć, ale nie wrzeszczeć, bo wtedy wymowa jest niewyraźna. Po osiągnięciu maksymalnego (w pewnym sensie, ustalonego poziomu), zaczynamy ściszać głos, aż do szeptu. Naturalnie zabawę można powtórzyć dowolną ilość razy.
Jako szept warto przećwiczyć szept aktorski, czyli używanie szeptu, ale głośnego i wyraźnego, bez tembru głosu.
Mając jedno ustalone słowo, fajnie jest potem mobilizować kogoś kto mówi zbyt cicho wołając tylko "ryba!" i wtedy wszystko wiadomo.
Showing posts with label zespół. Show all posts
Showing posts with label zespół. Show all posts
Wednesday, September 21, 2011
Sunday, October 31, 2010
Pożegnanie z AutoGuard S.A.
Ale czas już w drogę, bo tkwienie w jednym projekcie zbyt długo jest złe zarówno dla programisty jak i dla samego projektu. Pojawiają się złe nawyki, przenoszone potem do kodu. A z drugiej strony, ciągłe robienie "tego samego" nie jest rozwijające.
Można też powiedzieć, że "blokowanie" stanowiska pracy przez jedną osobę zbyt długo też jest niedobre dla projektu, bo wolny wakat to nowa osoba, z zewnątrz, z nowymi pomysłami na stare problemy, z nowymi doświadczeniami i znajomością innych technologii.
W każdym z przypadków, zmiana projektu (pracy) jest zdrowa dla wszystkich.
Bardzo dziękuję wszystkim osobom, z którymi współpracowałem w AutoGuardzie. Bardzo Was polubiłem i mam nadzieję, że pozostaniemy w kontakcie.
Siemano. Patrz szwagier, jaka franca! Ale urwał! Synek, bo jak ci... Dobranoc, koniec imprezy!
No nie do końca ;)
Saturday, June 2, 2007
Re: Praca, rutyna i walka z zawodową codziennością
Post jest odpowiedzią na publikację Splatcha na temat rutyny w pracy.
Podjąłeś, Łukaszu, bardzo ciekawy temat, problemu z którym boryka się każdy programista robiący troche dłuższe projekty. Każdy wie, że nowości (projekt, zadanie, nowy język albo FrameWork) są ekscytujące i powodują wydzielanie jakichś naturalnych euforyków. Jednocześnie warto się zastanowić jak stworzyć wewnętrzny stymulator, gdy w pracy zajmujemy się projektem przewidzianym nawet na lata.
W mojej obecnej firmie, nasz projekt właśnie obchodzi pierwsze urodziny. Termin porodu bety mamy za 2 miesiące, ale rutyna dopadała mnie już wiele razy.
W dużych projektach nie możemy zmieniać ani technologii, ani języka. Fajnie jeśli są różne etapy. Przez pół roku tworzyliśmy serwer w PHP, a potem grubego klienta w Javie i każda zmiana była emocjonująca. Ale w końcu przychodzi moment stabilizacji, gdzie ma się już napisany Framework, a kolejne tickety w Tracu każą nam dodawać tylko nowe formularze i kontrolki. I tu sie pojawia ostra rutyna. Podobne GUI, podobna logika biznesowa. Kopiowanie kodu, aby uzyskać kolejną wyszukiwarkę i listę takich albo innych danych, itd.
Jeżeli samo kodowanie nie powoduje w nas entuzjazmu, to należy go szukać gdzie indziej.
Po pierwsze można próbować poza pracą. Znaleźć sobie sens działania poza programowaniem i tam "ładować się". Przychodzi mi tu na myśl reklama durexa, gdzie gościu podczas porannego śniadania nadal szczerzy się do wszystkich :D Wiadomo, że to przenośnia. Ale chodzi "aby to uczucie trwało dłużej", czyli żeby entuzjazm zdobyty w godzinach 16 - 8 starczał nam jeszcze na 8 - 16.
Z drugiej strony patrząc, często wymaga to posiadania jakiejś pasji, bliskich czy przyjaciół. Natomiast obserwując ludzi z "branży" IT i pokrewnych, zdarzają się tacy, którzy potrafią poświęcić się tylko pracy, a życie osobiste mają dużo skromniejsze. Tu można zrealizować mój drugi pomysł, zresztą wcale nie kolidujący z pierwszym. Należy w pracy zbudować dobry zespół. Tu wkraczamy na temat rzekę, który jest poruszany w większości dobrych książek o zarządzaniu projektami i w dodatku stanowi on większą część tych publikacji, niż same "techniki" zarządzania.
Dobry, zgrany zespół to podstawa. To grupa ludzi, którzy są w stanie przerwać rutynę. To miła rozmowa podczas przerwy obiadowej, albo pomoc przy "zakleszczeniu" umysłowym przy rozkminianiu danego zadania. W dobrym zespole ciekawa anegdotka opowiedziana z nienacka potrafi bardzo porawić humor. Czasem nawet ktoś wywinie orła przy wygłupach co świetnie rozluźnia sytuacje. Ale z drugiej strony, członek dobrego zespołu to ktoś kto każe się nam wziąć w garść, kiedy za bardzo marudzimy.
Takie miałem nieskrempowane pomysły. A jak jest umnie? Myślę, że jeśli mamy sensownych ludzi w zespole, drugi wariant da się zawsze osiągnąć, conajwyżej potrzeba trochę czasu i pomysłów na przełamanie barier. Z pierwszym nie zawsze jest łatwo. Mam żonę i cudnego synka. Ale dużo trudniej jest mi znaleźć w sobie chęć na wyjścia na jakies piwo ze znajomymi, albo pójść na imprezę urodzinową kumpla ze studiów.
W pracy mam bardzo fajny zespół, choć niestety uboższy o jednego, bardzo zdolnego programistę i świetnego kolegę, który był dla mnie często wsparciem.
Udało nam się "dotrzeć", choć początki nie były łatwe. Teraz panuje luźna atmosfera na przemian z dużym skupieniem. To bardzo pomaga, choć przyznaję, że czasem mnie wkurza kiedy za długo sobie żartują :) Bardzo dużo razem zainwestowaliśmy w komunikację i teraz łatwiej jest się dogadać, szczególnie przy tworzeniu nowego kawałka systemu. To wszystko powoduje, że ewentualną rutynę łatwiej jest znosić, a często ponownie wraca entuzjazm i radocha z programowania.
Podjąłeś, Łukaszu, bardzo ciekawy temat, problemu z którym boryka się każdy programista robiący troche dłuższe projekty. Każdy wie, że nowości (projekt, zadanie, nowy język albo FrameWork) są ekscytujące i powodują wydzielanie jakichś naturalnych euforyków. Jednocześnie warto się zastanowić jak stworzyć wewnętrzny stymulator, gdy w pracy zajmujemy się projektem przewidzianym nawet na lata.
W mojej obecnej firmie, nasz projekt właśnie obchodzi pierwsze urodziny. Termin porodu bety mamy za 2 miesiące, ale rutyna dopadała mnie już wiele razy.
W dużych projektach nie możemy zmieniać ani technologii, ani języka. Fajnie jeśli są różne etapy. Przez pół roku tworzyliśmy serwer w PHP, a potem grubego klienta w Javie i każda zmiana była emocjonująca. Ale w końcu przychodzi moment stabilizacji, gdzie ma się już napisany Framework, a kolejne tickety w Tracu każą nam dodawać tylko nowe formularze i kontrolki. I tu sie pojawia ostra rutyna. Podobne GUI, podobna logika biznesowa. Kopiowanie kodu, aby uzyskać kolejną wyszukiwarkę i listę takich albo innych danych, itd.
Jeżeli samo kodowanie nie powoduje w nas entuzjazmu, to należy go szukać gdzie indziej.
Po pierwsze można próbować poza pracą. Znaleźć sobie sens działania poza programowaniem i tam "ładować się". Przychodzi mi tu na myśl reklama durexa, gdzie gościu podczas porannego śniadania nadal szczerzy się do wszystkich :D Wiadomo, że to przenośnia. Ale chodzi "aby to uczucie trwało dłużej", czyli żeby entuzjazm zdobyty w godzinach 16 - 8 starczał nam jeszcze na 8 - 16.
Z drugiej strony patrząc, często wymaga to posiadania jakiejś pasji, bliskich czy przyjaciół. Natomiast obserwując ludzi z "branży" IT i pokrewnych, zdarzają się tacy, którzy potrafią poświęcić się tylko pracy, a życie osobiste mają dużo skromniejsze. Tu można zrealizować mój drugi pomysł, zresztą wcale nie kolidujący z pierwszym. Należy w pracy zbudować dobry zespół. Tu wkraczamy na temat rzekę, który jest poruszany w większości dobrych książek o zarządzaniu projektami i w dodatku stanowi on większą część tych publikacji, niż same "techniki" zarządzania.
Dobry, zgrany zespół to podstawa. To grupa ludzi, którzy są w stanie przerwać rutynę. To miła rozmowa podczas przerwy obiadowej, albo pomoc przy "zakleszczeniu" umysłowym przy rozkminianiu danego zadania. W dobrym zespole ciekawa anegdotka opowiedziana z nienacka potrafi bardzo porawić humor. Czasem nawet ktoś wywinie orła przy wygłupach co świetnie rozluźnia sytuacje. Ale z drugiej strony, członek dobrego zespołu to ktoś kto każe się nam wziąć w garść, kiedy za bardzo marudzimy.
Takie miałem nieskrempowane pomysły. A jak jest umnie? Myślę, że jeśli mamy sensownych ludzi w zespole, drugi wariant da się zawsze osiągnąć, conajwyżej potrzeba trochę czasu i pomysłów na przełamanie barier. Z pierwszym nie zawsze jest łatwo. Mam żonę i cudnego synka. Ale dużo trudniej jest mi znaleźć w sobie chęć na wyjścia na jakies piwo ze znajomymi, albo pójść na imprezę urodzinową kumpla ze studiów.
W pracy mam bardzo fajny zespół, choć niestety uboższy o jednego, bardzo zdolnego programistę i świetnego kolegę, który był dla mnie często wsparciem.
Udało nam się "dotrzeć", choć początki nie były łatwe. Teraz panuje luźna atmosfera na przemian z dużym skupieniem. To bardzo pomaga, choć przyznaję, że czasem mnie wkurza kiedy za długo sobie żartują :) Bardzo dużo razem zainwestowaliśmy w komunikację i teraz łatwiej jest się dogadać, szczególnie przy tworzeniu nowego kawałka systemu. To wszystko powoduje, że ewentualną rutynę łatwiej jest znosić, a często ponownie wraca entuzjazm i radocha z programowania.
Subscribe to:
Posts (Atom)
Posts
