推薦 K24, 我的觀劇亮點

先講結論：蠻推薦我的朋友們有機會可以去欣賞一下台南人劇團的 K24，今年目前還有兩場在台南的機會，敬請把握。

我沒能力寫劇評，所以只是想把我自己覺得十分有趣的地方列一下給朋友們參考：

• 超大重點是看 Sandy / Jay 這個角色。一開始已經覺得男扮女裝還可以這麼有味道蠻不簡單，但更重要的是忽男忽女的時候的，動作與口白的節奏抓得真好，實在很精采。在演到第四集結束後，就讓我覺得不去買個節目單好好認識一下演員不行，而結束謝幕時這個角色也獲得最熱烈的喝采。
  
• 對細節的重視真的很不簡單，劇中劇的歌舞部分都看得出投入十足的努力，而每集的片頭片尾也很棒 :P 中場休息時我推了一句：真的很像日劇一集一集看下去的感覺（反而不那麼像美劇，可能我日劇看得比較多有偏差 :P）。是說頒獎典禮的看板上好像有錯字，不知道是不是故意的，還是我看錯。
  
• 旋轉舞台應用十分巧妙，我想起之前自我檢討手語社舞台劇時有提到「因為太被電影電視般的運鏡影響，設計了過多換幕，造成工作人員的麻煩」。如果那時有看過 K24 的話我應該可以更有點子吧？舞台轉一圈不只是場景的切換，也有時是分割畫面，有時是同一個空間的不同角度等等；中間隔檔的門也用不同材質應付不同需求，讓我開了眼界。
  
• 長達六小時（連中場休息共八小時）的連續舞台劇，並不多見。神奇的是，除了中間大段我只勉強聽懂一點的日文對白，讓人而覺得沒聽懂有點可惜 + 無聊之外，我沒覺得有什麼冷場，也非常精神飽滿地看完了六集。第五集結束時我還想：耶？又一集了喔？原來一個小時又過了！
  

一直很喜歡相聲裡「一桌二椅，變化無窮」的表達方式，這次 K24 裡也有個用沙發來表現的橋段很棒，如果要換成用電視劇的話怕是沒有這麼精采的想像與編排，而就會很「簡單」地用真實場景來表達了。除此之外，我喜歡看現場演出，也是因為那些表現、那些互動、甚至那些凸槌的狀況都僅此一次。劇中有段問到「有看到的舉手」時，我很快地舉了手（觀眾席中也有三三兩兩的手舉起），並且真實感受到自己跟演員處在同一個時空之中。總之，這是一次十分精采的體驗，推薦我的朋友們去觀賞。

關於社群式管理的心得隨筆

本來今天打算來 MozTW Lab 整理一下週末討論的活動定位，不過今天在公車上看的書 -- 「約耳續談軟體」，裡面頭幾篇跟管理相關的文章，實在與我對社群的看法太也相近，決定先把一些東西打起來分享給大家。第四章的第一句話就是作為社群協調者要面對的、最重要的問題：「如果你想領導一個團隊、一家公司、一支軍隊，甚至是一個國家，首要問題就是讓大家都朝著同一個方向前進。這話說得很客氣，意思就是『讓別人做你想要的事』。」

正如大家所知，Open Source 程式貢獻者本質上都是做爽的。記得以前 XDite 也曾經提過類似的話：這群被視為「愛分享」的人不見得真的那麼愛分享，許多情形下分享出去的東西都只是自己已經獲得利益後的殘渣。我們撰寫程式許多時候是為了讓自己用更好的軟體，至於別人怎麼用那些成果，反正我們也不太介意 -- 我們的問題已經解決了。當然，某些人更會因為基於「我也踏在別人的肩膀上，應該回饋」的心情，把這些想法更提升到道德的層次，但這畢竟不是多數人。

所以，我覺得志工就是不能要求（註）的 -- 要用什麼當作這份「要求」的誘因？用約耳說的「指揮與控制管理法」，以嚴厲的恐懼讓大家能以最快的速度反應一致嗎？還是「經濟學 101 管理法」，用獎勵代替懲罰，鼓勵這群人往一致的目標前進？書裡提到，「軍隊裡會使用指揮與控制的方法，是因為沒有別的辦法能讓 18 歲青年衝過地雷區，並不是認為在各種狀況下，這都是最好的管理方法」；又說經濟學101管理法的大問題「就是內在動機會被外在動機取代」。我想這兩種方法也就是所謂的棒子與胡蘿蔔，一則脅之以威，另一則誘之以利。

我相信 Open Source 專案裡是這樣的：你有意見就送補綴（patch），讓比較有信譽、受信任的人審閱程式碼。審過以後，補綴就會被收進主幹裡，成為之後新軟體的一部分，皆大歡喜。而萬一審不過，或許代表程式寫得不夠好（例如不符合 coding style，這會讓別人日後維護非常麻煩），也還有另一種可能是解法不被認同。一旦兩人在程式解法上出現爭議，這時雙方一般會開始辯論可行作法，接著若仍無法取得審閱者的同意，則要不就不補，要不就把這套程式直接搬回家打上自己的補綴、出自己的版本。這套作法裡，審閱者跟補綴者並沒有層級上的差別，審閱者只是把自己工作做好，而補綴者也可以選擇自己用行動（把程式搬回家自己出一版）來證明所持方案的可行性。

那麼審閱者若真的希望補綴者能繼續投入貢獻（我相信每個居於協調人的角色都會把這件事情視為使命），該怎麼「讓別人做你想要的事」？我想「利誘」還是正確的作法，不過這邊要用以誘之的「利」我想並不真指錢財禮品等的東西，更重要的是自我動機，這也就是約耳提的認同管理法。審閱者站在「程式上游」（mainstream）的角度，能做的就是說服補綴者也認同自己的方法即使不是最佳、也是比較能被接受的作法。這麼一來，補綴者才可能願意以審閱者的論調貢獻重寫後的程式。由於補綴者是志工，並沒有人可以用扣薪水的方式「逼迫」他何時要把問題解決，也沒人可以用加薪水的方式「獎勵」他把問題解決，那麼只能讓他自己也接受「這種方式是這個時間點上最可行的解決方案」才行。

我們當然可以「要求」補綴者照自己的作法走，但在過程中必然含有非常多的溝通與討論，而到最後當某一方被說服，也就不會是「要求」了，因為被說服的那方已然認同了對方的思考。做事也是一樣的。希望某件事情改變作法，就動手參與；覺得「審閱者」或「補綴者」做得不對，就以開放態度盡力溝通，以求讓對方能夠繼續（在這個問題、或其他方面）貢獻心力。

那我怎麼知道你是更好的？請證明。此時你是審閱者，如果我送的補綴你不想接，請證明你的想法即使不是最佳、也是比較能被接受的作法。否則，我可以不做。

註：「要求」的定義或有不同，我這邊採取是以最壞的「我是對的，請照我的方法做」這種態度行事的作為。當然你可以說這個詞非常中性，我同意，只是我也相信每個人的感受會有差異、也不真的都能這麼邏輯分明地就事論事。