小公司的制度边界：什么时候该定规矩，什么时候该放手

小公司的制度困境

几年前，我创立的往日时光网络科技只有四个人。那时我们没有任何制度：代码直接往master推，报销靠微信截图，请假说一声就行。事情推进得很快，但偶尔会出乱子——有一次某个功能上线后才发现数据库字段没对齐，回滚花了半天。

后来团队扩大到十几个人，我开始觉得“乱”了。于是照搬了之前工作过的公司那套制度：每周一晨会、周报、代码评审、请假审批流、报销流程……结果呢？执行了两个月，大家怨声载道，产出反而下降了。写周报的时间比写代码还多，晨会成了形式，审批流程让一个紧急bug耗了两天才修复。

这是小公司典型的“制度困境”：要么没有制度，像一盘散沙；要么制度太多，把自己捆死。

核心判断：制度是交易成本的折中

我后来想明白一件事：制度本质上是一种“交易成本”。你花时间制定规则、监督执行，是为了减少另一种成本——由于随机性、错误或冲突带来的损失。如果制定制度的成本大于它节省的成本，那这个制度就是负资产。

大公司为什么需要那么多制度？因为规模大了，人多了，错误代价也大。一个错误的发布可能影响千万用户，所以需要严格的变更管理。但小公司呢？错误的代价通常很小，反而灵活性的价值很大。

所以问题不是“要不要制度”，而是“在什么边界内需要制度”。

决策框架：三个问题

我现在判断一个事情是否需要制度化，会问三个问题：

• 1. 这件事重复发生的频率有多高？
• 如果是每周都会发生的事，比如代码合并冲突、客户反馈收集，那值得有个简单的标准流程。如果是半年才遇到一次的特殊情况，比如服务器宕机，那就写个检查清单就够了，不用搞成制度。
• 2. 做错的代价有多大？
• 如果错一次可能损失几万块钱或一个核心客户，那需要制度保护。如果只是耽误半天时间，那允许犯错，事后复盘就行。
• 3. 执行者是否有足够的判断力？
• 如果团队里都是资深工程师，那代码规范可以是一份文档而不是强制检查。如果招了新人，或者需要多人协作，那自动化检查（如lint、CI）比制度更有效。

举个例子：报销流程。我们公司平时报销不多，一个月也就三五笔，单笔金额很少超过一千。之前我坚持要填单、审批、财务复核，结果大家嫌麻烦，往往攒到年底才报。后来我改成：500元以下直接微信说一声，截图留底就行；500元以上需要简单说明。运行一年，没出过问题，反而大家更愿意及时报销了。

制度的边界条件

根据我的经验，不同规模有不同的边界：

• 1-5人（初创期）：几乎不需要制度，靠口头约定和信任。唯一需要的是“钱怎么分”，这个要提前说清楚。
• 6-15人（成长期）：开始需要一些“轻制度”，比如代码分支策略、客户问题响应SOP、会议节奏。但每一条都要问“能不能更轻？”
• 16-30人（扩张期）：需要基础的财务、人事、项目管理制度，但依然要避免复杂审批。可以引入工具自动化，比如用低代码平台做请假申请，而不是用钉钉的复杂审批流。

一个反直觉的发现：制度越详细，越容易被绕过。因为人总会找漏洞，而详细的制度往往意味着没人能完全记住。不如定几条原则，加上“如果拿不准，问老板”的兜底。

如何逐步建立制度

不要一次性写一本《员工手册》。我推荐的做法：

1. 记录摩擦点：当某个问题反复出现，或者某个决策卡住了，就记下来。
2. 最小化解决方案：针对这个摩擦点，写一页纸的规则，或者用工具自动化。不要考虑未来可能发生的其他情况。
3. 试运行一个月：如果这一个月内没有因为缺少规则而出问题，或者规则本身带来了新问题，就调整或废弃。
4. 定期回顾：每季度回顾一次制度清单，删除那些已经没用的，简化那些仍在运行的。

比如代码合并冲突频繁，我最初想写一个“git工作流规范”文档，后来发现直接用一个简单的脚本强制rebase并自动检查，比任何制度都管用。

制度不是目标，是手段

最后一点：小公司最容易犯的错，就是把“制度建设”当成管理能力的象征。KPI、OKR、周报、日报、考核……这些工具本身没有错，但如果你引入它们只是因为“别人都这么做”，那大概率会变成负担。

真正的管理，是让团队能在低成本下做出正确决策。制度只是工具之一，甚至不是最重要的工具。信任、沟通、共同的价值观，往往比白纸黑字的规则更能解决问题。

PaxLee