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

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

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

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

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

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

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

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

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