“人治”+”自治”：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 APP
a.语言：Swift
b.要求：不允许超过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 就是这个地方！另外，我们正在构建一个更棒的地方，你一定会爱上它！想提前打听点儿内幕消息吗？赶紧联系我们！