计划进度怎么做？项目负责人制度设计：进度管理从0到1

2024 年冬天，我帮一家做工业 SaaS 的公司做交付复盘。他们有 14 个研发、3 条产品线、同时在跑 5 个项目，计划表做得非常漂亮，甘特图、里程碑、责任人一栏全都填满了，颜色分三级，看起来像是可以直接拿去投标的样板。但连续四个季度，他们的按期交付率没有一次超过 60%。更让我意外的是，我问创始人"现在这 5 个项目，分别是谁负责"的时候，他停顿了大概四秒，然后说："每个项目都有个牵头人吧，主要是 XX 在统筹。

"这四秒的停顿，比任何一张甘特图都更能说明问题。这篇文章不讲怎么画排期表，而是讲一件更前置的事：在 0 到 1 阶段，怎么设计一套真正有人对进度负责的制度，以及这套制度该怎么一步步长出来。

一、先给结论：进度管理的起点不是排期表，而是责任接口

我把过去几年经手的项目做了分类复盘，最终得到的结论有点反直觉：计划精细度对交付结果的解释力，远低于责任明确度。换句话说，一张粗糙但责任清晰的计划，往往比一张精美但责任模糊的计划更能按时交付。

原因不难理解。计划是静态的，现实是动态的。计划一旦写下来，它面对的第一个冲击就是变化，需求变了、人走了、优先级被老板调了。能扛住这些冲击的不是计划本身，而是计划背后那个"必须把事情做成"的人。

1. 一个反常识的观察：计划做得越细，延期往往越隐蔽

很多人以为计划细就等于管理强。实际情况常常相反。当计划被拆到以"天"为单位、每个任务都有明确的起止时间，团队会产生一种"已经管到位了"的安全感，于是没人再主动去核对真实进展。

更麻烦的是，细计划会把延期"碎化"。一个大延期被拆成 20 个小任务后，每个小任务只晚半天，看起来都不严重，等到所有小延期叠加起来暴露在大里程碑上时，已经来不及补救了。我在复盘中见过最典型的一次：某个项目 37 个任务里有 26 个各自延期不超过 1 天，最终整条链路晚了 19 天。

2. 三问测试：2 秒内答不出来，制度就没建立

判断一个团队有没有真正的负责人制度，不需要看文档，只需要问三个问题，而且要求对方在两秒之内回答。超过两秒，制度就是纸面上的。

• 这个项目如果只能有一个人对结果负责，是谁？，考察责任唯一性。
• 他能不能自己决定砍掉一个需求、抽调一个人？，考察决策授权。
• 项目延期了，他个人会承受什么？，考察后果承担。

三问里任何一问卡壳，进度管理的所有工具、模板、流程都会失效。因为工具只能记录进度，不能产生进度。

3. 从 0 到 1 阶段，负责人制度要满足的三个条件

成熟组织可以靠流程和矩阵管理运转，但 0 到 1 阶段不行。团队小、目标不稳、资源不足，流程还没来得及固化就要改。这个阶段的负责人制度，我建议只追求三个条件，多一个都是负担。

二、真实场景：0 到 1 阶段的进度为什么特别容易失控

0 到 1 阶段和成熟期最大的区别，不是团队能力，而是不确定性本身。目标可能中途转向，关键人可能同时兼三个角色，资源永远比需要的少一半。在这种环境里谈进度管理，如果直接照搬成熟期的制度，等于给一辆还在跑的车上换轮胎。

1. 三个典型症状：计划靠催、进度靠问、延期靠猜

我总结过 0 到 1 团队最常见的三种病态表现，它们几乎总是一起出现。

计划靠催。负责人不主动更新，需要管理者每隔几天去问一次。问一次动一次，不问就停。这本质上是负责人没把计划当成自己的东西，而是当成了交给上级的作业。

进度靠问。团队里没有一个公共的地方能看到所有项目的真实状态，所有信息都散落在各人的聊天记录和记忆里。想了解进度，只能挨个找人问，问完还得自己拼图。

延期靠猜。没有人知道某个任务到底会不会晚，只能凭经验判断。等到真的晚了，已经过去了一周，补救窗口基本关闭。

2. 根因三条：目标在变、角色在兼、责任在飘

这三个症状背后是三个结构性原因，它们很难靠"加强沟通"解决。

第一，目标在变。0 到 1 阶段的产品方向本身就在探索，今天做的功能明天可能被砍。如果计划被当成承诺而不是预测，负责人就会倾向于"拖到最后再承认变化"。

第二，角色在兼。一个人可能是产品、又是项目经理、还写一部分代码。当他同时是需求提出方和进度负责人时，自我监督基本失效，他很自然地会给自己"通融"。

第三，责任在飘。这是最致命的。当一件事被三个人同时"关注"时，没有人真正负责。会议纪要里写着"XX 牵头、YY 配合、ZZ 支持"，实际上就是没人负责。

3. 一个 14 人团队的具象场景

回到开头那家公司。他们的 5 个项目里，有 3 个是同一个"牵头人"在统筹。这个人本身还要写核心模块的代码，每周能花在进度管理上的时间不到 6 小时。

于是出现了这样的循环：周一开例会，各人报一下做了什么；周三有人发现某个接口对不上，在群里 @ 一下；周五负责人想起来要更新计划表，发现已经和实际差了两周，就干脆先不更新了。到月底，计划表还停留在第三周，真实进度停留在第五周，而管理层看到的是第三周，三周的信息差，就是延期的全部空间。

这个场景里没有坏人，每个人的工作量都很饱满。问题出在制度上：没有人被明确赋予了"对最终交付负责"这个角色，也没有人拥有与之匹配的时间和权力。

4. 数据观察：延期被发现的时点分布

我统计过自己经手的 63 个延期事件，记录它们第一次被"明确识别"的时间点。结果很不乐观。

三、拆解六个常见误区

在讨论怎么做之前，先说清楚哪些做法看起来合理、实际上在制造问题。这六条我都亲眼见过，其中三条我自己也踩过。

1. 误区一：把负责人当成"背锅人"

很多团队引入负责人制度的真实动机是：出了事得有人担着。这种动机一旦被感知到，负责人就会进入防御姿态，少承诺、多留余量、把风险写在邮件里抄送所有人。

结果是计划变得极其保守，看起来都在按时完成，但项目整体没有推进速度。更糟的是，有能力的人会主动避开这个角色。负责人制度的健康标志不是"有人怕担责"，而是"有人愿意接"。

2. 误区二：制度比项目还重

我见过一个 9 人团队，为了管好两个项目，设计了包含立项审批、周报模板、月度复盘、季度考核在内的完整制度，光模板就有 11 份。三个月后，这套制度的使用率不到 30%。

0 到 1 阶段的项目本身寿命可能只有两三个月，如果制度的学习成本比项目周期还长，它就不会被使用。制度的第一原则是"能跑起来"，第二原则才是"跑得规范"。

3. 误区三：只考核不授权

这是最普遍也最伤人的一条。负责人被要求对交付时间负责，但既不能决定需求优先级，也不能调动额外人力，甚至不能决定技术方案。这种情况下，"负责"变成了"承担后果"，而不是"推动结果"。

判断标准很简单：如果负责人连"这件事我先不做"都说不出口，那他就不是负责人，只是一个进度汇报人。

4. 误区四：计划一次定死，不允许滚动调整

把计划当成合同，是 0 到 1 阶段的大忌。因为目标本身在变，任何一次定死的计划都会在两周内过期。而当计划过期后又不允许修改，团队就只剩下两个选择：假装没变，或者私下改。

两种选择都会让计划失去可信度。真正该管住的不是"计划不能变"，而是"变更必须留下痕迹、必须有人批准、必须重新评估影响"。

5. 误区五：用工具替代制度

买一套项目管理工具，把任务导进去，然后期待进度自动变好，这个幻想我见过太多次。工具能解决的是"信息在哪里"的问题，解决不了"谁对信息负责"的问题。

一个没有负责人制度的团队上了工具，最常见的结局是：任务卡片全在，但更新时间全部停留在两周前，看板变成了一个更大的、更贵的记事本。

6. 误区六：把"项目负责人"和"项目经理"混为一谈

这两个角色在很多公司被当成同一个岗位，但它们在 0 到 1 阶段承担的责任完全不同。项目经理关注的是流程、协调、文档、风险登记；而 0 到 1 阶段真正需要的那个人，关注的是"这周必须拿下哪一个关键结果"。

如果只设项目经理而没有业务责任人，项目就会变得流程完整但结果模糊。项目经理是让项目"跑得顺"，项目负责人是让项目"跑得到"。小团队里这两个角色可以由同一人担任，但心里必须清楚此刻自己在扮演哪一个。

四、专业判断逻辑：负责人制度的四个设计变量

既然制度不能照搬，那就要有一套判断逻辑，用来说明"在我的团队里应该设计成什么样"。我把这套逻辑归纳为四个变量，它们决定了制度的形态。

1. 变量一：权责利是否对等

这是所有管理设计的底层约束。一个人被赋予的责任，必须与他拥有的权力和能获得的利益大致匹配。三者失衡，制度就会自动退化。

具体的失衡形态有三种：责大于权，负责人会变得保守、推诿、只做最安全的选择；权大于责，负责人会滥用资源、频繁变更、不受约束；利不匹配，负责人会在项目和个人发展之间选择后者，表现为"人在心不在"。

这三者里，0 到 1 阶段最常见的是第一种，因为给权力需要老板放手，而给责任只需要口头一句话。

2. 变量二：责任半径要匹配项目复杂度

"责任半径"是我自己用的一个说法，指的是一个负责人能有效覆盖的决策范围。项目越复杂、依赖越多，责任半径就需要越大，否则就会出现"负责人管不了别人的人，只能等"的局面。

判断方法：列出这个项目需要做决策的事项，看有多少是负责人能自己拍板的。如果低于 60%，说明责任半径不够，项目必然依赖外部协调。

3. 变量三：责任接口要分层，不要一个人扛所有

很多团队的做法是"一个项目一个负责人，所有事都找他"，这在项目小的时候可行，一旦跨团队就会崩。我建议把责任接口分成三层。

三层里最关键的是结果层必须唯一。可以有多个执行责任人，但只能有一个结果责任人。

4. 变量四：0 到 1 阶段要选"最小可行制度"

所谓最小可行制度，是指只保留能让责任链条闭合的最少要素。我的建议是四条：一张负责人清单、一份能被随时看到的进度视图、一条变更入口、一次简短的月度复盘。

除此之外的所有东西，考核细则、流程文档、评审模板，都应该等到项目跑通之后再补。原因很简单：0 到 1 阶段最大的成本不是管理成本，而是决策延迟成本。制度每增加一层审批，决策就多延迟一天。

五、从 0 到 1 搭建负责人制度的五个动作

理论说完，进入操作。这五个动作我建议按顺序做，因为后面的动作依赖前面动作的输出。每做完一个动作，制度就应该能独立运转一小段，而不是全部做完才见效。

1. 动作一：定角色，先解决"谁"，再解决"怎么"

第一件事是把所有在跑的项目列出来，每一个后面只写一个名字。如果写不出来，或者写了两个，这个项目就先不要启动，先把人定下来。

选定负责人时有三个判断点：他是否了解业务目标（而不是只了解技术任务）；他是否有能力对不愿意听的话说"不"；他是否有时间。第三个最容易被忽略，一个每周只剩 5 小时的人，是当不了负责人的。

反例："这个项目由 A 牵头，B 和 C 共同参与决策。"这不是负责人制度，这是委员会制度。

2. 动作二：定计划，从目标倒推，当面认领

计划不要从"我们要做哪些任务"开始，而要从"三个月后必须实现什么"开始倒推。倒推出来的里程碑数量应该很少，我一般建议 0 到 1 阶段一个项目不超过 5 个里程碑。

关键的仪式感在于：里程碑的日期必须由负责人自己说出来，而不是由上级指派。自己说出的日期，才会有心理契约。指派下去的时间，只会被当成"老板的一厢情愿"。

3. 动作三：定规则，统一进度口径和更新频率

没有统一口径，进度就是一个形容词。什么叫"完成 80%"？是代码写完了，还是联调通过了，还是上线了？不同人的答案能差出两周。

我的建议是只定义四种状态，并要求所有任务都必须落在其中之一：未开始、进行中、受阻、已完成。同时规定一个最小更新频率，建议每周固定一天，所有负责人更新自己所辖范围的状态，不更新视为未开始。

下面是我在项目里实际使用过的进度上报口径模板，可以直接改字段使用。

# 项目进度周报口径模板（0-1 阶段建议版）
project: "订单中台重构"

owner: "张XX" # 有且仅有一个结果责任人，不接受并列

week: "2026-W14"

milestones:

name: "开放平台接口联调完成"

planned_date: "2026-04-10"

forecast_date: "2026-04-15" # 由负责人自己填，不填视为"未知"，不能留空

status: "at_risk" # 四选一：on_track / at_risk / blocked / done

blocker: "第三方支付沙箱环境未开通"

decision_needed: "是否先用模拟回调联调，真实沙箱延后验证"

decision_owner: "张XX" # 必须写明这条决策由谁拍板

change_log: # 有变更必须留痕，没有变更就写空数组

date: "2026-04-08"

type: "scope" # scope / resource / priority / schedule

content: "营销券核销功能移出本期范围"

approved_by: "张XX"

4. 动作四：定授权，把"能决定什么"写清楚

授权最忌讳的是模糊表述，比如"重大事项需要汇报"。什么是重大？没人说得清，最后所有事都往上汇报。

我建议用清单的方式写清楚，比如：单个需求增减 3 人天以内，负责人可自行决定；调整里程碑 3 天以内，负责人可自行决定；抽调其他项目人力，需与对应负责人协商；范围变更超过 10%，需要升级决策。数字可以按团队情况调整，但必须存在一个数字。

5. 动作五：定复盘，归因要分"判断失误"和"资源不足"

复盘最容易变成批斗会，是因为归因太粗。延期了就是"执行力不行"，这种结论对下次没有任何帮助。

我建议复盘只回答两个问题：第一，这个延期在发生前，负责人有没有可能提前知道？如果有可能而没上报，是能力问题还是意愿问题？第二，如果提前知道了，他有没有权力去处理？如果没有，说明授权不够，要补的是制度而不是批评。

六、让制度真正跑起来的三个细节

五个动作做完，制度只是"立起来"了，还谈不上"跑起来"。真正决定成败的是三个容易被忽略的执行细节，它们分别对应信息的可见性、风险的暴露速度和变更的入口。

1. 细节一：进度必须可观测，且要能被"顺手看到"

可观测不等于"有地方记录"，而等于"不需要额外动作就能看到"。如果一个人要打开三个系统、登录两次、点四层菜单才能知道项目状态，那这个状态在事实上就是不可见的。

我建议的做法是"看板 + 周报 + 里程碑验收"三选二，不要三个全上。小团队用一块共享看板加一次周会就够了；跨团队用周报加里程碑验收更稳。关键是选定之后不要频繁更换载体，团队需要形成肌肉记忆。

2. 细节二：偏差必须早暴露，所以要有"上报不追责"的窗口期

这是我最想强调的一条，也是大多数团队做得最差的一条。如果一个人上报风险之后，第一反应是被质问"你怎么搞的"，那下次他就不会再上报了。

我的建议是设置一个明确的窗口期：在计划到期前 3 天以上主动上报的延期，一律不追责，只讨论怎么处理；在到期后才暴露的，才进入归因流程。这个规则必须由最高管理者公开承诺，否则没人相信。

这条规则的效果非常直接，它把"承认问题"的成本降到接近于零，从而把整条预警链路激活了。

3. 细节三：变更必须有统一入口，禁止私下改期

0 到 1 阶段变更频繁是常态，管理的重点不是减少变更，而是让变更可见。私下改期的危害在于：它让计划失去参考价值，等到有人发现时，整个排期已经和现实脱节了。

一个可用的最小变更入口只需要三个字段：改什么、为什么改、谁批准的。这三个字段的记录成本不超过两分钟，但能保住整张计划表的可信度。

七、工具什么时候该上场：制度沉淀到系统的触发信号

我一直主张先有制度再有工具，而不是反过来。但这不等于工具不重要。当团队规模跨过某个门槛，制度本身会变得难以靠人力维持，这时候工具是必需品而不是奢侈品。

1. 四个触发信号：出现任何一个，就该考虑工具了

• 项目数量超过同时在线 5 个，且存在跨项目共用人力的情况。
• 团队人数超过 50 人，靠每周一次口头同步已经同步不过来。
• 出现外部审计、客户验收或合规要求，需要留下可追溯的进度证据。
• 关键岗位开始流动，进度信息开始随着人走而不是留在组织里。

如果四个信号都没出现，我建议继续用共享表格加周会，因为工具的引入成本（配置、培训、习惯迁移）在小团队里往往高于收益。

2. 选型看什么：三个容易被忽略的判断点

市面上的项目管理工具功能列表高度相似，看功能对比表没什么意义。我建议换三个角度来判断。

第一，它能不能表达"唯一负责人"这个概念。有些工具的字段设计默认支持多负责人，这在 0 到 1 阶段反而是负担，因为它会让责任继续模糊。

第二，它能不能承载变更留痕。变更记录如果只能写在评论里，就等于没有结构化的变更数据，季度复盘时会非常痛苦。

第三，它的数据能不能被导出和私有化。项目进度数据往往包含产品路线和客户信息，对中大型企业来说，数据放在哪里是一个必须先回答的问题。

3. 以 PingCode 为例：它适合什么样的团队

在需要把制度沉淀到系统的阶段，PingCode 是我会优先考虑的一类产品。它主要服务中大型企业及 100 人以上的组织，这个定位本身就说明了它的适用边界，它是一个把成熟研发管理体系固化下来的平台，而不是给 5 人团队用的轻量看板。

它的两个特性对本文讨论的主题特别有意义。一是支持私有化部署，这意味着进度数据、需求文档、变更记录都可以留在企业自己的环境里，对于做 to B 业务、或者对数据出境有要求的团队来说，这是选型时的一票否决项。二是支持 Jira 平滑迁移，这让很多已经用惯了海外工具、但又需要国产化替换的研发团队可以低成本平移，历史数据和字段映射不用重建。

在国产替代这个维度上，PingCode 的完成度是比较高的选择。但我要提醒一点：工具的能力上限不能弥补制度的下限。如果团队还没有确定唯一负责人、还没有统一进度口径，先上平台只会把混乱放大，你只是把"没人知道进度"变成了"系统里有一堆没人看的状态"。

4. 什么时候不需要工具

反过来说，有三种情况我建议先不上系统。一是项目周期短于两个月且只有一两个项目；二是团队没有专职的协调角色，没人能承担配置和维护的成本；三是管理层的决策习惯还没有改变，仍然依赖"找人问"而不是"看数据"。

第三种情况最隐蔽。如果老板依然习惯在群里问"那个东西做完了吗"，工具就会被绕过，最后变成一份需要额外维护的负担。

八、一个 40 人研发团队的 6 个月观察

为了让上面的判断更具体，我完整记录过一个 40 人研发团队从"没有负责人制度"到"基础制度跑起来"的 6 个月过程。这段观察也修正了我自己的一些原有看法。

1. 背景与初始状态

这家公司做企业级协同产品，40 人研发，分成 5 个小组，同时进行 7 个项目。初始状态下，所有项目由 CTO 一人统筹，每周花在进度管理上的时间约 10 小时。计划表由各组组长维护，格式各不相同，有人用表格，有人用文本，有人只写在纸上。

我介入时做了一次基线测量：随机抽查 20 个进行中的任务，问负责人"这个任务下周能不能完成"，得到的答案里，有 7 个最终判断错误，准确率 65%。

2. 我们做了什么，以及顺序为什么重要

我们没有一次性上完整制度，而是分三步走。第一个月只做一件事：给 7 个项目各指定一个唯一负责人，并把名字写进周会纪要的第一行。这个动作本身的成本几乎为零，但它立刻改变了会议的内容，以前大家在汇报做了什么，现在开始有人主动说"我这边有个风险"。

第二个月做了口径统一。原来的状态有十几种说法，收敛成四种，并确定了每周四下午为统一更新时间。这一步的阻力比我想的大，有三个组长明确表示"太麻烦了"，其中两个在两个月后改变了态度，因为发现更新一次能省掉三次被追问。

第三个月才引入工具，把已经稳定的字段搬进系统。这个顺序非常关键：先让人习惯"我要更新"，再让工具承接"在哪里更新"。如果反过来，前两个月一定会在配置和培训上消耗掉所有耐心。

3. 六个月后的数据变化

六个月后我又做了一次同样的抽查。20 个任务里有 3 个判断错误，准确率提升到 85%。其他几项指标的变化如下。

其中最有价值的不是按期交付率的提升，而是主动上报风险比例从 12% 涨到 68%。这个数字说明了"上报不追责"这条规则确实生效了，团队开始把风险当成需要处理的信息，而不是需要隐藏的错误。

4. 一个反例：同期的另一支团队为什么失败了

几乎同时，我还观察了另一家规模相近的团队，他们做了几乎相同的动作，但六个月后几乎回到原点。差别只有一个：他们把负责人制度当成了考核工具。

具体表现是，第一个月就出台了延期扣分规则，并且把扣分与季度绩效直接挂钩。结果是负责人开始集体保守，把两周的任务报成四周，把不确定的事情从计划里删掉。计划看起来越来越准时，但项目整体交付时间反而延长了。

这个反例让我更确信一件事：负责人制度的第一目标是让风险被说出来，第二目标才是让结果被达成。顺序反过来，制度就会变成一个防御系统，而不是一个推进系统。

九、不同情况下的行动建议

前面讲的是通用逻辑，但每个团队的起点不同。下面按团队规模和项目复杂度给出四套不同的行动建议，可以直接对照自己的情况取用。

1. 3 到 10 人：只需要两件事

这个阶段最大的优势是沟通链路极短，任何制度都可能成为负担。你只需要做两件事：一是每个项目写一个唯一负责人的名字，哪怕他同时还写代码；二是每周固定一次 15 分钟的进度同步，只说三件事，上周承诺的事完成没有、本周最大的风险是什么、需要谁帮忙。

不需要工具，不需要文档，不需要考核。如果需要记录，一张共享表格足够。这个阶段的常见错误是为了"规范"而引入复杂流程，结果拖慢了唯一真正重要的东西：推进速度。

2. 10 到 50 人：补上口径和变更入口

这个阶段开始出现跨组协作，口头同步不再够用。核心任务是两件：统一进度状态口径（建议四态），以及建立变更记录的最小入口（改什么、为什么、谁批准）。

同时建议开始培养"项目协调人"这个角色，哪怕只是兼职。他的职责不是做决策，而是保证信息准确、会议有效、风险不漏。这个角色是未来 Project Management Office 的雏形。

3. 50 到 200 人：引入系统，并把授权写进制度

这个阶段信息量已经超过人力承载上限，必须引入系统。选型时优先考虑能否表达唯一负责人、能否承载变更留痕、能否支持私有化部署。前面提到的 PingCode 就是在这个区间开始具备明确价值的平台，它的定位本就是服务中大型企业及 100 人以上的组织。

比工具更关键的是把授权落成文字。这个阶段最常见的瓶颈是"负责人不敢做决定"，因为组织里没有明确的授权边界。建议至少把需求增减、排期调整、资源借用这三件事的阈值写清楚。

4. 200 人以上或多项目强并行：制度要能脱离个人

这个阶段的核心命题是"制度要能脱离个人运转"。判断标准是：如果某一天所有项目负责人同时请假一周，公司是否还能知道每个项目的真实状态。如果不能，说明制度还挂在人身上。

重点要做的是数据沉淀和定期审计，让进度、变更、风险成为组织的资产，而不是个人的记忆。私有化部署和数据导出能力在这个阶段从"加分项"变成"准入项"。

十、不同情况下的取舍

任何制度都是取舍的结果，没有一种设计能同时满足所有目标。这一节我把四组最常见的取舍摊开，帮助你在具体情境下做出选择。

1. 取舍一：推进速度 vs 管理规范

这两者在 0 到 1 阶段是明确冲突的。规范带来可追溯性，但每一次审批都会增加决策延迟。我的建议是：在核心目标尚未验证之前，优先保速度；在核心目标已验证、进入规模复制阶段后，优先保规范。

判断节点可以设得很具体，当同一个流程你已经重复执行超过 5 次，就该把它固化成规范；少于 5 次，就继续靠人。

2. 取舍二：责任集中 vs 决策分散

责任必须集中，但决策不能全集中。我见过两种极端：一种是什么都由负责人拍板，结果他变成瓶颈；另一种是什么都要开会，结果没人对结果负责。合理的做法是"结果集中、过程分散"，负责人对最终交付负责，但技术方案、测试范围、UI 细节这些决策下放给职能角色。

3. 取舍三：自建工具 vs 采购平台

自建的优势是贴合度高、数据完全自主，劣势是维护成本随时间线性上升，而且很难招到愿意长期维护内部系统的人。采购平台的优势是功能成熟、迭代快，劣势是流程需要迁就产品设计。

我的经验判断是：当内部工具的维护人力超过 0.5 个全职当量，就应该认真考虑采购。这个门槛在多数公司大约出现在 60 到 100 人之间。

4. 取舍四：制度保护负责人 vs 制度约束负责人

这是最根本的一组取舍。同一套制度，可以被解读为"我承诺了就要做到"，也可以被解读为"做不到就要扣分"。前者让负责人愿意承诺，后者让负责人尽量少承诺。

我的立场很明确：0 到 1 阶段，制度的第一功能是保护愿意负责的人，而不是约束不愿意负责的人。因为前者稀缺，后者靠制度也约束不好。

结尾：进度管理的起点，是先把那一个名字写下来

把整篇文章压缩成一句话：计划进度做不下去，绝大多数时候不是不会排期，而是没有人真正对结果负责。在 0 到 1 阶段，团队最该做的不是买工具、不是建流程，而是先把每一个项目后面的那一个名字写清楚。

如果你现在就想动手，我建议按这个顺序走。今天下班前，把在跑的所有项目列一遍，每个后面只写一个名字，写不出来的项目标记出来，这周内补齐。下周的例会上，让每个负责人自己说出下一个里程碑的日期，而不是你替他定。再下周，把"到期前 3 天主动上报不追责"这条规则公开宣布一次，并且真的执行一次。

这三步做完，你的团队就已经拥有了进度管理最重要的一块地基。工具、模板、平台这些事，等这块地基稳了再谈，效果会好得多，成本也会低得多。