"人治"+"自治"：DAO 治理的漸進化之道單一目標的最小可行 DAO 已經得到了驗證，它是可以成功的，例如 MolochDAO。但我們知道，人類的協作往往都是超過最小可行單元的，甚至需要大型協作。如果我們希望將 DAO 應用到更多的場景，那麼 "DAO 治理" 便是一個尤為重要的話題，因為糟糕的 DAO 治理會將我們推進"烏合之眾"的泥潭。遺憾的是，迄今為止還沒有關於 DAO 治理的指導方法來幫助我們。去年3月初，我參與了一個 DAO（作為協調人），參與者包括Web3開發者、Web2開發者，以及大量從未接觸過web3的非技術人員（包括：設計師、產品經理、行政人員、會計、創業者、媒體工作者、音樂人、畫家、電影人、學生等等）。在近一年的時間裡，我收穫了一些 DAO 治理的經驗，也積累了很多教訓。一直想寫一些總結性的文章，可惜始終沒有時間。這幾天，在"1 Million developers"社羣，Kames 和我聊起了關於 DAO 治理的話題，我向他表達了一部分我的思考。這件事鼓勵了我，促使我完成了這篇關於 DAO 治理的總結文章。感謝 Kames！我也希望繼續完成其他關於 DAO 的思考文章，最好能成為一個系列。希望能夠為那些打算或者已經在實踐 DAO 人一些參考或者啟發。但它們僅僅是的我個人觀點，不一定對。如果把你推進泥潭那個人是我，我是不會去救你的！關於 DAO 治理，我們面臨很多疑問，或者說困惑，例如：什麼樣的治理形式才是去中心化的？我們如何實現"自治"？DAO 的優勢應該是透過自動執行的程式碼來減少人與人的溝通成本，但是為什麼看上去我們並沒有減少溝通成本，反而更高了呢？我想用 DAO 完成一個產品的開發，我如何進行專案管理？我是一名創業者，我很興奮於 DAO 的優勢，但我真的要把我的公司變成一個 DAO 嗎？這些困惑其實都聚焦在一個問題上：我們怎樣做才符合 DAO（去中心化和自治）。很顯然我們面臨的是一個組織治理基本準則的問題。這就好比是二進位制程式碼中的0和1，非黑即白。也正是因為非黑即白，很多 DAO 陷入了泥潭，很多試圖嘗試 DAO 的人望而卻步。我個人認為，DAO 的治理需要漸進。這是解決這些問題的起點。漸進我們還沒有準備好進入徹底的 DAO。這是由於相關的治理機制、工具和技術還並不完善，但更重要的是人們的意識和習慣。我們不能保證每一位參與者都已經為 DAO 做好了準備。這就像 web3 產品一樣，我們需要找到一個讓 web2 使用者更容易上手 web3 的方法，讓更多的使用者更快地進入 web3 世界，只有當 web3 形成了規模效應，才能真正啟用 web3 生態的發展。關於這一觀點，Eric Chung 在他的文章 Incremental Decentralization 中有介紹。DAO 治理同樣如此，只有讓 DAO 在社會範圍形成規模效應，才能真正啟用全球化 DAO 網路的發展，包括相應的治理機制、工具和技術的完善，以及人們普遍意識和習慣的養成。所以在我們還沒有準備好之前，儘量不要給自己套上"非黑即白"的枷鎖。我們沒有去往羅馬的直達航班，我們必須"漸進"。然而問題是，我們如何漸進？我認為有一種實現方法：人治 + "自治另外，我們真的能夠實現完全的"自治"嗎？這也是一個值得研究的話題。人治 + 自治人治是"熱連線"，是不可量化，高頻的溝通，很明顯的例子就是 Telegram group。自治是"冷連線"，是可量化，低頻的溝通，一種實現方式是 Bounty。人治專門用來解決 DAO 治理中不可量化的事務。例如 DAO 的未來規劃，處理突發事件，討論重大議題等等。這些事務通常無法提前設計出可自動執行的程式。這就像我們無法專門為突發事件提前設計一個標準化的處理方案一樣，因為每一次突發事件的組成因素都不一樣。很顯然，人治並不符合純粹的 DAO 精神。但也只有它才能解決 DAO 治理中最棘手的問題。自治專門用來處理 DAO 治理中可量化的事務。例如開發任務、設計工作、財務處理會計工作等等。這些事務通常可以提前設計出可自動執行的程式。很好的實現方式就是 Bounty。Bounty 最大的優勢在於標準化。我們甚至只需要設計一個完善的 Bounty 機制就可以應對不同型別的工作。Bounty 最重要的是"量化"，只要做到足夠的量化，DAO 的很多工和工作就不需要依賴於溝通，甚至不需要溝通。通常來說，如果你的 DAO 是一個非最小可行 DAO，例如產品開發團隊，或者是一家去中心化公司，那麼自治絕對會佔 DAO 治理的大部分工作量。Bounty 通常需要包含任務各個環節的內容以及它們的各項指標，例如：任務描述、任務需求列表以及相應規範、完成時間、驗收標準、賞金金額等等。我們大膽地舉一個例子：DAOSquare Bounty #007任務描述：開發一款針對冠狀病毒的電子蚊香程式任務需求列表：1. Mac APP語言：Swift要求：不允許超過10行程式碼2. iPhone APPa.語言：Swiftb.要求：不允許超過9行程式碼完成時間：3個小時驗收標準：親自實驗，成功即合格賞金金額：100 $MAGIC你或許已經發現，我們完全可以用這個 Bounty 模板來進行其他任務，讓我們來看看：DAOSquare Bounty #008任務描述：打掃房間任務需求列表：1. 客廳工具：拖把要求：用水量不允許超過一桶2. 廚房工具：抹布要求：用水量不允許超過半桶完成時間：1個小時驗收標準：用顯微鏡看不到細菌即合格賞金金額：10 $MAGIC我相信沒有人會真的釋出上面的 Bounty！但嚴肅地說，Bounty 的各項內容越具體、越明確，執行就會越順暢，溝通成本也就會越小。當然，Bounty 一定會出現突發狀況。例如賞金獵人突然不幹了。這時候就需要啟動人治來處理這一棘手的問題。所以，我們需要在 DAO 治理中靈活地組合人治和自治。我的建議是將它們元件化。
元件化
我們最好將人治和自治作為兩個元件，就像樂高積木一樣。根據我們的需求靈活組合成不同的治理方案。例如，我們可以將一項軟體開發專案拆分為不同的任務，每一個任務相當於一個積木，這裡面有人治積木也有自治積木。而且很有可能一個積木本身也是由幾個不同的積木組成。這就好比你建了一個樂高城市，一座大樓作為城市的一個組成部分（一個積木），但它本身也是由很多不同的積木組成。
所以說，你能不能很好地進行 DAO 治理，就看你是不是一個優秀的樂高玩家！
以上說的元件化都是針對 DAO 內部的治理，下面我們擴大一下範圍，看看在多個 DAO 組成的協作網路中，如何發揮元件化的優勢。
首先我要表達一下我的觀點：儘量不要啟動大型、複雜的 DAO，這樣的 DAO 失敗率極高。生命力最頑強，也最容易成功的 DAO 一定是最小可行 DAO。同樣，生命力最頑強，也最容易成功的 DAO 協作網路也一定是由最小可行 DAO 所構建。義烏小商品業的成功足以說明一切。
基於這一模式，網路中的每一個 DAO 就是一個元件，或者說是一個樂高積木。
Vitalik 曾經說：
“The killerness of the ecosystem is not the nodes, it’s the links. Every single application that gets built is not just an application in its own right, it’s also a component that every future thing in the Ethereum ecosystem can benefit from.”
DAO 協作網路也是如此，它的致命弱點也是連線。每一個 DAO 應該成為整個 DAO 網路的元件，讓網路中的其他 DAO 或者 DAO 組合能夠從中受益。
問題是，如何連線網路中的 DAO 來搭建具有無窮想象空間的 DAO 樂高世界呢？我們同樣需要利用 "人治" 和 "自治" 這兩個治理積木。
"人治" + "自治" 的模式不僅可以作為 DAO 內部治理的工具，而且同樣適用於外部，DAO 與 DAO 之間，甚至整個 DAO 協作網路的治理。
例如 Bounty，我們同樣可以透過 Bounty 在 DAO 與 DAO 之間進行交易，這就有點類似承包商。如果這個 DAO 協作網路建立在無數個最小可行 DAO 的基礎之上，那麼每一個 DAO 都是其他 DAO 的承包商，同時又是僱主。如果它們的交易基於 token，那麼將更大化彼此之間甚至整個 DAO 網路的共同利益，讓這場遊戲變成一場正和博弈的遊戲。這是相比傳統商業協作模式的絕對優勢和競爭力。
不過一切都在飛速發展，尤其是 DAO，以上的理論也需要隨之不斷調整。
我遇到的一些提問
我的 DAO 就是大型的、複雜的 DAO，我該怎麼辦？
這種情況相當普遍，同時也是那些希望將公司改成 DAO 的人所面臨的問題。我的建議是：
· 首先，砍掉非核心單元。例如，財稅完全可以外包出去。
· 然後將那些你無法丟掉的單元拆分為 DAO，以最小可行 DAO 來執行，並透過一個協調單元來保持各個 DAO 的同步。
但說實話，我並不建議你這麼幹，尤其當你還是一位 DAO 的新手的時候。
我應該如何發起 Bounty？有工具或者模板嗎？
我曾經制作過一些 Bounty 模板，雖然它需要專人來管理 Bounty，還不夠"自治"，但總的來說執行正常。如果有一個很棒的工具那最好不過了。這會不會是一個商機呢？
有沒有可以學習交流這方面知識的地方？
毫無疑問，DAOSquare 就是這個地方！另外，我們正在構建一個更棒的地方，你一定會愛上它！想提前打聽點兒內幕訊息嗎？趕緊聯絡我們！
