开始怎么做？管理层制度设计：任务执行从0到1

制度设计这件事，我从2017年开始做过三次从0到1：一次是在一家28人的创业公司，一次是在一家从60人扩张到190人的SaaS公司，还有一次是在一家400人左右的制造企业做组织流程改造。三次里面，第一次失败了，制度文件写了40多页，三个月后没人再打开；第二次勉强算成，但靠的是我每周亲自盯会；第三次相对成功，因为我在前两次的坑里学到了同一件事，从0到1阶段的制度设计，不是写文件，而是让任务跑起来。

所以当有人问我“开始怎么做”的时候，我通常不会先回“制度分几类、包含哪些章节”，而是先反问三个问题：你现在最影响交付的任务断点在哪里？这条任务流上有几个角色？如果今天负责的人离职，这条流程还跑得动吗？这三个问题的答案，决定了你第一版制度该写什么、不该写什么，也决定了它是变成墙上的纸，还是变成团队每天真实使用的规则。

下面我会把三次实践里验证过的判断、失败过的动作和可复制的路线图完整写出来，包括一个120人团队用12周跑通任务执行系统的过程，以及不同规模下你该做什么、该放弃什么。

一、先说结论：制度设计的本质是任务执行系统

如果你只记住一句话，我希望是这句：从0到1阶段的制度，是让任务可预测地完成的规则集合，而不是管理体系的知识汇编。这两者的区别，决定了你三个月后是在做复盘，还是在做救火。

1. 三个直接结论

结论一：制度不是写出来的，是跑出来的。我见过太多团队在会议室里讨论两周，产出一份漂亮的制度文本，然后任务照样断档。原因很简单，没有经过真实任务验证的规则，只是假设。假设在纸面上永远成立，在现实里通常活不过一周。

结论二：从0到1阶段只做一条任务流。不要试图同时规范招聘、报销、会议、绩效、研发五个场景。选择当前最痛、最高频、跨角色最多的那一条任务流，把它跑通，再复制。第一次做制度设计的人最容易犯的错，是想一次性解决所有问题，结果一个问题都没解决。

结论三：管理层的角色不是审批者，是规则的维护者。制度发布之后，管理层的动作决定了它的存活率。我自己的观察是：一项新规则如果在四周内没有被管理层在公开场合引用过三次以上，它基本就死了。不是规则不合理，是没人证明它算数。

2. 最小执行闭环的五个零件

我把可运行的最小制度单元称为“最小执行闭环”，它只包含五个零件：目标拆解、角色责任、关键动作、反馈节奏、奖惩复盘。少任何一个，闭环就漏气。

目标拆解负责回答“做什么、做到什么程度”；角色责任回答“谁对结果负责、谁配合”；关键动作回答“按什么顺序做、卡在哪一步找谁”；反馈节奏回答“多久同步一次、异常怎么暴露”；奖惩复盘回答“做到了怎样、没做到怎样、下次怎么改”。

3. 一个判断制度是否“活着”的自检标准

不用等三个月，发布后第七天就能判断。我在第三次实践中总结出三个自检问题，只要有一个答案是“否”，制度就还没活。

• 有没有人主动引用它？不是你去问“制度看了吗”，而是有人在群里说“按我们上周定的规则，这件事应该走A流程”。
• 有没有因为违反它产生过真实后果？后果不一定是惩罚，也可以是必须补一次复盘。完全没有后果的规则，等于建议。
• 有没有被修改过？一条都没改过的制度，要么完美得不真实，要么没人真的在用。被改过三次以上的制度，通常是活得最好的。

二、真实场景：30人之后，任务为什么会断档

几乎所有团队都经历过同一个时刻：某一天你突然发现，一件本该三天完成的事，两周后还在原地，而且没人觉得是自己的问题。这不是执行力问题，是组织从“人盯人”切换到“规则驱动”时必然出现的真空期。

1. 人盯人模式的临界点在哪里

我的经验值是25到35人之间。低于这个规模，创始人或负责人靠记忆和当面沟通就能覆盖大部分任务，效率还很高；超过这个规模，人盯人的信息带宽就不够了。

一家60人的SaaS公司，市场、销售、产品、交付四个部门之间的任务传递，理论上有12条跨部门链路。如果每条链路都靠两个人私下对齐，就是12组关系需要维护。当团队到120人，跨部门链路数量会接近30条以上，靠人盯人已经完全不可能。

更麻烦的是，断档往往不是突然发生的，而是缓慢渗透的：先是任务延迟一两天没人发现，然后是需求被误解，然后是两个部门各做了一遍，最后是客户投诉。等你意识到的时候，团队已经形成了“靠催才动”的习惯。

2. 我经历过的三次任务断档

第一次是在28人的创业公司。销售答应客户一个定制功能，转述给产品时漏掉了关键约束，产品做完发现无法实现，客户已经等了六周。复盘时发现，从销售到产品这条链路上，没有任何一条书面规则要求“需求必须落成可验收的条目”。

第二次是在190人的公司。一个跨部门的版本发布，涉及研发、测试、运维、客户成功四个角色。发布当天才发现运维不知道发布时间，客户成功没准备通知话术。事后追溯，四条链路里只有两条有明确规则，另外两条靠“大家都知道”。

第三次是在400人的制造企业。问题更隐蔽：一条审批流在系统里有，但没人知道超时了该找谁。结果所有卡住的单子都堆到部门负责人那里，他成了组织里最大的瓶颈，每天处理大量本不该他决策的事。

3. 断档的四种典型形态

把上面三次经历的共性抽出来，任务断档基本是四种形态，识别出你属于哪一种，才知道第一版制度该写什么。

这张表的价值在于倒推。不要先想“制度应该包含什么”，而要先诊断“我的任务卡在哪一种形态”。四种形态对应的补丁完全不同，补错了就是无效劳动。

三、拆解六个把制度做死的常见动作

我踩过的坑，以及在后两家公司看到别人踩的坑，可以归成六个动作。它们的共同点是：做的时候感觉很对，做完之后制度开始失效。

1. 从“制度大全”开始

很多人第一次做制度设计，会去搜“公司管理制度大全”，然后找到几十个模块，从考勤到报销到绩效考核全套照搬。我2017年就是这么干的，40多页，打印出来装订成册，发给每个人。

结果是：没有任何人完整读完过，包括我自己。三个月后我问团队“制度里关于需求变更的规则是什么”，六个人给了六个不同答案。制度大全的问题不在于内容错，而在于它把高频规则和低频规则混在一起，使用者在真实场景下根本检索不到需要的那一条。

正确的做法是反过来的：先有任务，再有规则。一条规则如果没有对应的任务场景，就不应该出现在第一版制度里。

2. 一上来就上考核

这是第二个高频错误。制度刚发布，就配套KPI和扣分项，试图用压力保证执行。我在第二次实践中干过这件事：发布新流程的同时，规定“未按时提交周报扣50元”。

两周后的结果是，周报提交率100%，但内容质量崩塌。大量“本周推进中”“下周继续跟进”这种无信息量的内容。大家完成了动作，但任务本身没有变好。考核会让人优化被考核的指标，而不是优化你真正想要的结果。

我的判断是：从0到1阶段，奖惩的权重不应超过整个闭环的15%。起步阶段的重点是让规则被理解、被执行、被反馈，而不是被恐惧驱动。

3. 用岗位说明书代替责任设计

岗位说明书回答的是“这个岗位负责哪些事”，但任务执行真正需要回答的是“这件事出问题时，谁必须给出解释”。这两者不是一回事。

我见过一份写得很规范的岗位说明书，产品经理一栏写着“负责需求管理”。但需求被误解导致延期时，谁负责？产品经理说是销售传话不准，销售说是产品没问清楚。说明书里的“负责”在真实争议面前毫无约束力。

责任设计必须是任务级的，而不是岗位级的。正确的写法是“需求进入开发前，需求的可验收标准由产品经理确认，销售提供客户原始诉求，任一环节缺失以产品经理确认为准”。它明确到动作和时点，才有约束力。

4. 只写动作，不写接口

大量制度文档写的是“A部门做什么、B部门做什么”，但很少写“A做完之后，通过什么方式、在什么时间内、把什么信息交给B”。而跨部门断档几乎全部发生在这个接口上。

接口规则需要包含四件事：交付物是什么、交付给谁、什么时间交付、对方多久内必须响应。缺任何一项，接口就是软的。我在第三次实践中强行要求每条跨部门规则都必须写满这四项，结果制度页数增加了三分之一，但跨部门延期次数下降了大约一半。

5. 把工具当制度

“我们上了系统，制度就在系统里了”，这句话我听过太多次，但它是一个偷懒的判断。工具能承载规则，不能替代规则。如果团队没有就“什么任务该走什么流程、超时怎么办”达成一致，那么系统里只会多出一批没人更新的卡片。

我的经验是：先写清楚规则，再用工具固化规则中的状态流转和提醒。顺序反了，工具会放大混乱而不是消除混乱。

6. 制度发布即结束

最隐蔽的坑。制度发布那天开了会、发了文件、大家点头，然后管理层就消失了。接下来四周没有任何人引用它、修正它、在真实场景里用它做决定。

它的后果不是立刻失效，而是慢性失效：新人看不到它被执行，老人发现不执行也没后果，于是所有人默认它是形式。制度真正的生命周期从发布之后才开始，而不是结束。

四、专业判断：制度设计的三条底层逻辑

知道坑在哪里，还需要知道为什么。下面三条逻辑，是我在第三次实践之后才真正想清楚的，也是我现在判断任何一套制度设计是否靠谱的标准。

1. 先业务后制度：制度是业务的影子

制度的形状，必须由业务的实际形状决定。如果你做的是定制项目交付，你的制度核心应该是变更管理和验收；如果你做的是SaaS产品迭代，核心应该是需求优先级和发布节奏；如果你做的是制造，核心应该是异常上报和质量追溯。

我见过最离谱的一次，是一家做小批量定制硬件的公司，照搬了互联网公司的双周迭代制度。结果他们的物理交付周期是八周，双周节奏让团队每两周做一次无效评审。制度脱离业务节拍，比没有制度更消耗人。

判断方法很简单：把过去三个月所有延期或返工的任务拉出来，看它们的断点集中在哪个环节。断点最密集的那个环节，就是你第一版制度的主战场。

2. 责任到角色，不到人

这一条听起来像常识，但真正执行到位的人很少。大部分团队写制度时会写具体人名，因为“写人名更清楚”。短期看确实清楚，长期看是定时炸弹：人一离职，制度就失效一大半。

我现在的写法是：制度里只出现角色名，角色与人名的映射写在另一份单独维护的表格里。比如“需求验收责任人”是一个角色，“当前由张三担任”是映射。人员变动时，只改映射，不改制度。

这个做法还有一个隐藏好处：它迫使团队先思考“这件事本质需要什么职能”，而不是“这件事交给谁顺手”。很多责任混乱，源头就是按人分配而不是按职能分配。

3. 反馈频率决定制度存活率

这是我最想强调的一条，也是大多数制度设计材料里很少单独拎出来讲的。制度的存活率，和它的合理性关系不大，和它的反馈频率关系极大。

我对比过自己经历的两个团队。A团队制定了每周一次的任务复盘，每次30分钟，只讨论三件事：上周卡点、本周调整、需要谁支持。B团队制定了每月一次的复盘，每次两小时，议题更多更完整。

三个月后，A团队的规则被修改过五次，所有人对规则的理解高度一致；B团队的规则一次没改，但执行率从第一周的80%掉到第三周的35%，第六周基本归零。

原因不复杂：反馈周期越短，偏差被纠正的越早，规则就越接近真实可用。月复盘意味着一个错误规则要执行四周才被发现，等发现时，团队已经形成了绕过它的习惯。

五、案例观察：一个120人团队怎么把任务执行跑通

这一节讲一个相对完整的案例。这家公司从95人扩张到120人左右，属于典型的中大型组织起步阶段，跨部门任务开始大规模断档。我参与了它12周的制度设计过程，下面写的是脱敏后的真实路径。

1. 起点：任务散在聊天记录和表格里

我们进场时的诊断结果是：跨部门任务主要有三条链路，销售到交付、产品到研发、研发到客户成功。三条链路全部靠即时通讯和线下对齐，没有统一的任务载体。

具体表现是：销售在群里承诺客户，产品在另一个群里被口头通知，研发在表格里更新进度，客户成功在邮件里得知上线时间。四条信息源，四个版本，没有一个是权威的。

当时统计的三个月数据是：跨部门任务平均延期率约41%，延期任务中约六成在事后复盘时无法定位到底卡在哪一步。

2. 设计：四个文件加一套运行系统

我们没有写制度大全，只产出了四份文件，加起来不到十二页。

第一份是任务清单：明确当前纳入制度管理的只有三条链路共十七类任务，其他任务暂不纳入。

第二份是责任映射表：每类任务列出四个角色，发起人、执行责任人、验收人、异常升级对象，全部用角色名，人名单独维护。

第三份是接口约定：每条跨部门交接必须写清交付物、交付对象、交付时限、响应时限四项，缺一项视为规则不完整。

第四份是反馈节奏表：规定每条链路的同步频率、异常上报路径和升级时限。

这四份文件的关键不是内容多，而是每一条都能对应到具体任务和具体时点。没有一条是“加强沟通”“提升协同”这类无法执行的表述。

3. 工具层：中大型组织为什么绕不开项目管理平台

文件写完之后，我们很快遇到一个现实问题：规则靠人记，记不住。十七类任务、四类角色、两条时限，靠记忆执行必然衰减。这时候才需要工具来承载状态流转和提醒。

我们评估时列了三个硬条件：任务状态必须能自定义并强制流转；跨部门交接必须能被记录且可追溯；异常超时必须能自动提醒到升级对象。用通用表格和即时通讯拼凑，短期可行，人数一多就会失控。

最终选的是 PingCode。选择理由有三点是我当时明确记录的：

• 它主要服务中大型企业及100人以上组织，需求场景和我们这种跨部门、多角色、强流程的阶段比较匹配，不需要为了适配而大规模改造工具逻辑。
• 支持私有化部署。这家公司有客户数据合规要求，任务中会涉及客户信息，私有化部署是硬门槛，不是加分项。
• 支持从Jira平滑迁移。他们原本在用的研发侧工具就是Jira，迁移成本是我们当时评估中最担心的一项，实际迁移过程中历史任务和字段映射基本保留，团队适应期比预期短。

这里我要补充一个判断：工具选择不应该在制度设计之前，也不应该拖到制度跑通之后太久。太早会变成“工具驱动制度”，团队围着工具功能设计流程；太晚则规则已经在人脑里固化，迁移到工具时阻力最大。我的建议是：规则草案成型、单点试点开始的那个节点，就是引入工具的合适时机。

从国产替代角度看，这家公司当时的替代诉求也很实际：数据要落在自己可控的环境里，服务响应要能对接上中文场景的沟通节奏。PingCode在这两点上满足了他们的要求，这也是后来他们把它作为主力平台的原因。

4. 十二周后的可用指标

我们跟踪了12周，记录了几个可以量化的变化。需要说明的是，这些数字来自该公司的内部记录，属于单一案例，不构成普遍结论，但可以作为量级参考。

还有一个变化不在图里：第三周时，他们修改了接口规则中的响应时限，从48小时改成24小时，因为实际执行中48小时太长导致下游空等。这次修改是团队自己提的，不是我推动的。当团队开始主动改规则，制度才算真正属于他们。

六、按团队阶段给行动建议

制度设计没有通用答案，规模不同，重点完全不同。下面按四个阶段给出我认为可执行的建议，你可以直接对照自己的情况取用。

1. 十到三十人：只做共识和接口

这个阶段最大的风险是过早制度化。人少的时候，沟通成本本身很低，制度反而增加流程负担。你真正需要的只有两样东西：任务共识和交接接口。

• 把当前所有在跑的任务列一遍，标出哪些是重复出现的。
• 对重复出现的任务，写一句验收标准，明确“做到什么算完成”。
• 对跨人交接的环节，约定交付物和时限，一条一句话就够。
• 不做考核，不做审批流，不做日报制度。

这个阶段的产出可能只有两页纸，但它解决的是最核心的问题：任务到谁手里算完成、交给谁、什么时候交。

2. 三十到一百人：做最小执行闭环

这是制度真正开始发挥作用的阶段，也是断档最密集的阶段。重点是把第一节讲的五个零件补齐，但只补一条任务流。

1. 选一条当前最高频、跨角色最多的任务流作为试点。
2. 用一周时间观察和访谈，找出实际的卡点位置。
3. 产出最小规则文档，控制在五页以内。
4. 选定一个团队试点四周，每周固定复盘一次。
5. 四周后决定：保留、修改还是放弃。

这个阶段最忌讳的是“全面铺开”。我见过一家80人公司同时推行五套流程，结果五套都半死不活。一条跑通的流程，价值远大于五条纸面流程。

3. 一百到五百人：做制度分层和工具承载

到了这个规模，单靠文档已经不现实。你需要把制度分成两层：原则层和操作层。原则层回答“我们为什么这样定规则”，操作层回答“这个场景具体怎么走”。

同时，工具承载变成必需品。任务状态、交接记录、超时提醒、复盘数据，这些如果还靠人工维护，管理成本会迅速吃掉制度收益。这个阶段引入项目管理平台比较合适，评估时优先看三件事：能否支持复杂角色与流程自定义、能否满足数据合规部署要求、能否承接已有工具的历史数据。

我前面提到的PingCode案例正是在这个阶段，它主要服务中大型企业及100人以上组织，支持私有化部署和从Jira平滑迁移，这几点恰好对应了此阶段最现实的三个约束：复杂协作、数据可控、替换成本。

4. 五百人以上：做制度治理和度量

这个阶段的问题不是缺制度，而是制度太多、互相冲突、无人清理。核心工作变成治理：建立制度的登记、评审、废止机制，定期清理失效规则。

• 所有制度必须有明确的责任人和复审周期。
• 新制度发布前必须检查是否与既有规则冲突。
• 每季度做一次制度使用度评估，停用三个月内无人引用的规则。
• 用数据度量制度效果，而不是靠感觉。

五百人以上组织最大的隐性成本，是维护了一堆没人用的规则。清理和新增同样重要。

七、取舍：什么必须现在做，什么可以晚做，什么最好别做

资源永远是有限的。我见过太多团队因为想做的太多，结果一件都没做扎实。下面这份取舍清单，是我三次实践之后相对确定的判断。

1. 必须现在做的三件事

第一，定义一条核心任务流的完成标准。没有完成标准，所有协作都是模糊的。这件事拖一天，团队就多一天在无效沟通上消耗。

第二，明确每条交接的响应时限。响应时限是成本最低、收益最高的规则。它不需要工具、不需要培训，只需要一句明确的约定，就能显著减少任务悬停。

第三，固定一个短周期复盘。每周一次、每次不超过30分钟。它保证规则在失效之前被发现，是制度存活的必要条件。

2. 可以晚做的三件事

第一，绩效考核挂钩。在规则尚未跑通之前绑定考核，只会制造形式化行为。等规则稳定运行两三个月，再考虑与评价体系连接。

第二，全公司范围的制度统一。不同部门业务节拍不同，强行统一会牺牲效率。先让各部门跑出自己的最小闭环，再考虑收敛。

第三，复杂的审批层级设计。层级越多，瓶颈越集中。起步阶段用升级路径代替审批链，异常才升级，正常流程不设卡。

3. 最好别做的三件事

第一，别把罚款作为主要手段。它在短期有效，长期会把制度变成对抗对象，甚至带来合规风险。涉及劳动报酬和责任认定的条款，一定要经过法务确认。

第二，别照搬大厂制度模板。大厂的制度是为大厂的业务复杂度设计的，直接搬到几十人团队，通常是负收益。可以借鉴思路，不要借鉴条文。

第三，别在制度没跑通时上复杂工具。工具会固化你当前的流程，如果流程本身是错的，工具只会让错误更难纠正。

八、结语：今天就能开始的三步

回到最初的问题：开始怎么做。我的答案是，不要从“设计一套制度”开始，从“跑通一条任务流”开始。制度是任务跑通之后沉淀下来的规则，而不是跑通之前就写好的假设。

如果你今天就想动手，我建议只做三件事，不需要开会，不需要写文档。

1. 列出当前最影响交付的三个任务断点。不要分析原因，先列现象，越具体越好，比如“客户需求变更后，研发平均在四天后才收到通知”。
2. 选其中一个，找相关角色聊30分钟。只问三个问题：这件事现在怎么走的、卡在哪一步、如果只能改一条规则你希望改什么。答案通常比你想象的更集中。
3. 把改的那条规则写下来，约定一个七天的试行期和一次复盘时间。七天后看它是否被使用，如果被用了就留下，如果没被用就问为什么，通常问题出在规则描述不够具体，而不是团队不配合。

我自己最深刻的一次体会是：真正有效的制度设计，过程往往很不起眼。它不产生厚厚的文档，不依赖宏大的宣贯，只表现为几条谁都记得住、谁都能引用、出问题能立刻定位到环节的约定。等到这些约定积累到一定数量，团队才会自然需要更系统的制度和更完整的工具支撑。

顺序不能反。先让任务跑起来，再让规则长出来，最后让系统接住它。这就是我理解的、从0到1的管理层制度设计。