项目立项项目名称全流程：研发团队制度设计与一文讲清

2023 年 Q2，我刚接手一家 280 人企业服务公司的研发效能工作，第一周就被拉进一场”事故复盘”：财务发现同一个”数据中台”项目，在 OA 里立了三次项，预算累计申请了 620 万，实际做的是同一件事。更麻烦的是，追溯时没人能说清哪个立项书是最终版，三份文档分别叫《数据中台二期》《数据平台 V2.0》《数据中台优化项目》。这不是财务问题，也不是技术问题，而是项目立项制度里最容易被忽略的一环：项目名称没有做主键设计。

后来我花了两年时间，把这家公司从”立项靠 Word、命名靠灵感”改造成”立项字段全部结构化、命名规则带正则校验”的状态，累计治理了 1400 多条立项记录。这篇文章就是那次改造的完整复盘，包含命名法设计、六阶段流程、RACI 授权矩阵、工具落地方式和真实踩坑数据。

一、先给结论：立项是研发治理的数据入口，不是审批仪式

大部分团队把立项理解为”盖个章、走个流程、让领导知道有这么回事”。这个理解在 20 人团队里勉强能用，一旦超过 80 人、同时并行的项目超过 15 个，它就会立刻崩掉。

我的核心判断是：立项制度的本质，是在项目开始花钱和花人之前，把五个关键字段一次性冻结下来，让后面所有的排期、成本归集、绩效核算、审计追溯都有唯一锚点。它不是流程管理，是数据治理的前置动作。

1. 立项真正要冻结的是五个字段

不管你的公司用什么流程、什么工具，立项环节必须产出并冻结的字段只有五个。其余字段可以后续补充，这五个一旦定错，后面全是返工。

• 唯一标识：项目名称 / 项目编码，全公司范围内不可重复
• 责任主体：项目负责人、业务发起人、技术负责人，三个角色不能是同一个人兼任两个以上
• 目标与验收标准：一句话能说清交付什么，以及”什么状态算完成”
• 资源边界：人力人月上限、预算上限、时间窗
• 数据分级：项目涉及的数据密级，决定后续能不能用公有云工具、能不能外包

这五个字段中，前两个是”主键”，后三个是”约束”。我发现很多团队立项书洋洋洒洒八页，唯独这两个主键是模糊的，项目名叫”XX 系统优化”，负责人在文档里写”研发一组”。这种立项书在系统里根本无法被检索、被统计、被追责。

2. 项目名称是主键，不是标题

这是我最想强调的一点。项目名称同时承担两个功能：给人看的可读标识，和给系统用的唯一主键。绝大多数团队只考虑了前者。

我在做诊断时经常问一个问题：”请你在项目管理工具里，找出 2023 年 Q3 所有和计费相关的立项记录。”如果团队能在 30 秒内列出来，说明他们的命名体系是主键式的；如果要靠翻聊天记录或者问老员工，说明他们的项目名称只是标题。

标题可以重名，主键不能。项目名称一旦进入系统，就应该像身份证号一样，可读、可解析、全局唯一、长期稳定。它不应该因为项目方向微调而改名，也不应该因为负责人换人而改名。

3. 制度落地的顺序不能反

我见过太多团队把顺序做反了：先买工具，再想字段，最后才补制度。结果工具里建了一堆自定义字段，没人填；制度写了 12 页，没人看。

正确的顺序是四步：先定义字段（要收什么数据）→ 再设计流程（谁在什么节点填）→ 再分配权限（谁能改、谁能批）→ 最后固化到工具（用校验和必填项兜底）。顺序反了，你会得到两套并行体系：OA 里一套形式化流程，研发工具里一套真实数据，两边对不上。

二、背景与真实场景：立项混乱是怎么长出来的

没有哪个团队是主动决定”我们要混乱立项”的。混乱是一点点长出来的，通常在三个时间点加速：团队从 30 人涨到 80 人、业务线从 1 条变成 3 条、第一次接受外部审计或融资尽调。

1. 一个真实的重复立项事故

回到开头那个 620 万的案例。事后我们做了完整复盘，发现根本原因不是财务疏忽，而是三个月内组织架构调整了两次：

1. 3 月，数据团队从技术中心独立成部门，项目归属关系变了
2. 4 月，新的数据负责人上任，重新发起了”数据中台二期”立项
3. 5 月，原团队遗留的立项书仍然挂在 OA 里，状态是”进行中”

三份立项书，三个负责人，两个部门，没有一个字段能把它们关联起来。项目名称里都有”数据中台”四个字，但版本标识分别是”二期””V2.0″和”优化项目”。如果当初有强制的项目编码和受控版本词表，第二份立项书提交时系统就会提示”该编码已存在”。

2. 命名混乱的三类隐性成本

我把两年里收集到的返工记录做了归类，命名混乱带来的成本主要集中在三类，而且分布极不均匀。检索定位耗时占了将近一半，重复建档占三成，剩下两成来自审计和汇报返工。

3. 立项失控的五个信号

不用做复杂诊断，看五个信号就够了。命中三个以上，说明立项制度已经失效。

其中我最在意的是第一个。”只进不出”意味着立项被当成了资源占位工具，只要立了项，就能保住人头。这种激励机制下，制度设计再精巧也没用，因为大家有动力多立项、没动力结项。

三、项目名称命名法：一套能扛五年的编码规则

命名法的设计目标不是”好听”，而是”可解析、可排序、可校验、可扩展”。我给过十几家团队做命名规范，最后收敛成一套四段式结构，用了五年没出过大问题。

1. 四段式命名法

结构是：业务域 – 工作类型 – 主对象 – 期次（- 序号）。前四段必填，第五段只在冲突时使用。

举个例子：PAY-REF-BILLING-2024Q3 表示支付域、重构类工作、计费引擎、2024 年第三季度。看到这个编码，任何人不查系统就能知道它属于哪条业务线、是新建还是改造、大概什么时候做的。

2. 三种命名范式的对比

我给团队试过三种范式，最后选的是混合式，而不是纯中文或纯英文。原因看下面这组评分就清楚了。

3. 受控词表怎么维护

命名法能不能活下来，关键看受控词表有没有人管。我的做法是设一个”词表管理员”角色，通常由 PMO 或研发效能同学兼任，规则只有三条。

• 新增业务域需要部门负责人申请，一次审批，之后长期有效
• 已有词条不允许删除，只能标记为”停用”，历史项目继续可检索
• 每季度做一次词表体检，把从未使用的词条标记出来，超过四个季度未使用则自动进入待停用状态

这三条看似简单，但第二条最容易被违反。很多团队为了”保持词表干净”直接删词条，结果历史项目一夜之间失去分类归属，检索全部失效。治理数据的铁律是：新增可控，删除不可逆，所以永远不要真删。

4. 校验规则与代码示例

规则要能被机器执行才有意义。下面是我实际部署过的一段校验逻辑，跑在立项表单提交前的钩子里。

import re
四段式项目编码校验规则

CODE_PATTERN = re.compile(

r"^[A-Z]{2,4}-(NEW|ITER|REF|FIX|CMP)-[A-Z0-9]{2,12}-\d{4}Q[1-4](-R\d{2})?$"

)

受控业务域词表（从配置中心拉取，不要硬编码）

APPROVED_DOMAINS = {"PAY", "CRM", "DATA", "INFRA", "GROWTH", "RISK"}

def validate_project_code(code: str, existing_codes: set) -> dict:

if not CODE_PATTERN.match(code):

return {"ok": False, "reason": "格式不符合四段式规范，示例：PAY-REF-BILLING-2024Q3"}

domain = code.split("-")[0]

if domain not in APPROVED_DOMAINS:

return {"ok": False, "reason": f"业务域 {domain} 不在受控词表中，请先提交词表新增申请"}

if code in existing_codes:

return {"ok": False, "reason": "编码已被占用，请在末尾追加 -R01 形式的序号"}

return {"ok": True, "reason": ""}

这段代码的价值不在于它多复杂，而在于它把”命名规范”从文档里的建议变成了提交时的硬门禁。我在两个团队验证过：只写文档不写校验，三个月后命名合规率会掉到 50% 以下；加了校验，合规率能稳定在 95% 以上。

四、项目立项全流程：六个阶段与门禁设计

完整的立项流程不是”提交-审批”两步，而是六个阶段。每个阶段都有明确的输入、输出和门禁条件，缺一个门禁，流程就会漏水。

1. 阶段零：机会识别与预立项

这个阶段很多团队直接跳过了，但它其实是成本最低的纠偏点。预立项只需要一张卡片：谁提出的、解决什么问题、大概多大工作量、是不是已有项目能覆盖。

我要求预立项必须回答一个问题：”这件事能不能用现有项目的一个迭代解决？“如果能，直接进迭代，不立项。这一个问题在过去两年帮我砍掉了大约 30% 的无效立项申请。

2. 阶段一：立项申请材料

立项申请的核心不是文档长度，而是五个必填字段的完整度。我见过最好的实践是把立项书压缩成一页结构化表单加一段自由描述，剩下全部字段化。

• 结构化部分：编码、名称、负责人、发起人、预算区间、人力人月、起止时间、数据分级
• 自由描述部分：一句话目标、验收标准、不做的事（负面清单）

我特别推荐加上”不做的事”这一栏。它会强迫发起人想清楚项目边界，也是后续拒绝范围蔓延最有力的依据。

3. 阶段二：评审与决策

评审的层级应该由项目规模决定，而不是由提出人的职级决定。原则很简单：审批层级跟着风险走，不跟着权力走。具体分级见下一章的授权矩阵。

评审会的时间盒我一般设 30 分钟，前 10 分钟发起人陈述，中间 10 分钟质询，最后 10 分钟决策。决策结果只有三种：通过、有条件通过（列出必须先补齐的条件）、打回。不允许”再议”，”再议”意味着决策者没做决策。

4. 阶段三：立项冻结与开工

通过之后，五个核心字段进入冻结状态。所谓冻结，不是说永远不能改，而是任何修改都必须走变更流程并留下记录。系统层面表现为：这些字段对普通成员变为只读。

5. 阶段四：变更管理

变更分三档，对应不同审批路径。这是我踩过坑之后才细化出来的，早期一刀切导致小变更走大流程，团队怨声载道。

6. 阶段五：结项与归档

结项是立项流程中最被忽视的一环，也是项目池”只进不出”的根源。我推动过一个硬性规则：项目超过计划结束时间 30 天未结项，自动进入”超期预警”，超过 90 天未结项，系统自动锁定新增人力申请。

这条规则上线后，我们公司的平均结项延迟从 47 天降到了 12 天。真正起作用的不是预警本身，而是”锁人力”这个动作，它把结项从一件”没人管的小事”变成了”影响团队干活的大事”。

五、研发团队立项制度设计：角色、权限与分级授权

制度设计最容易犯的错是把所有项目套同一套流程。实际上，10 人月的项目和 200 人月的项目，管理成本差两个数量级，用同一套审批逻辑必然导致一头过松一头过紧。

1. 六个必要角色

角色定义清楚，后面的权限分配才有依据。这六个角色在小团队里可以兼任，但职责不能合并。

• 业务发起人：提出需求，对业务结果负责，通常是业务线负责人
• 项目负责人：对交付负责，唯一责任主体，不设第二负责人
• 技术负责人：对技术方案和架构合规负责
• PMO / 研发效能：维护字段规范、词表、流程，不参与业务决策
• 财务 BP：核算预算口径，验证成本归集
• 安全合规：判定数据分级，决定工具和外包边界

2. RACI 责任矩阵

把角色和阶段交叉起来，就得到一张可以直接落地的 RACI 表。R 是执行、A 是最终负责、C 是被咨询、I 是被通知。

3. 分级授权矩阵

这张表是我用得最多的一张，直接决定”什么项目该找谁批”。它的核心逻辑是：管理成本必须和风险敞口成正比。

关键在于 D 档的存在。如果没有免评审的轻量通道，团队会用两种方式绕过制度：要么把大项目拆成无数个小项目，要么干脆不立项直接干。给小事留一条合法通道，是让大制度活下来的前提。

4. 各级项目的实际评审耗时

分级之后，各级项目的平均评审周期差异非常明显。下面这组数据来自我跟踪的四个季度样本，可以帮你判断自己的分级颗粒度是否合理。

六、常见误区：九个团队里七个会踩的坑

这一章我列的是真实踩过的坑，每条后面都跟着”当时怎么想”和”后来怎么改”。

1. 误区一：把立项当成盖章流程

当时怎么想：立项就是让领导知会一声，重点是别耽误开工。
后来怎么改：把立项重新定义为”字段冻结动作”，审批只是副产品。判断标准从”领导签了没”改成”五个字段齐了没”。

这个认知转变带来的直接效果是：立项的产出从一份文档，变成了一条可以进入系统、可以被检索、可以被统计的结构化记录。

2. 误区二：项目名称交给发起人自由填写

当时怎么想：起名字是业务的事，规范太死会限制表达。
后来怎么改：名称分两部分，可读中文名自由填，编码段强制规范。两者绑定，系统自动生成编码。

我们发现，允许自由填写的结果是：217 个立项里，名称含”二期/2.0/优化/升级”这类模糊词的占 41%，其中 23 个名称在系统里无法与其他项目区分。

3. 误区三：制度一次定终身

当时怎么想：制度要稳定，频繁改会让人无所适从。
后来怎么改：核心字段稳定，词表和分级阈值每半年评审一次。

我建议把制度分成”宪法层”和”细则层”。宪法层是唯一标识、责任主体、验收标准这三条，两年内不该动；细则层是词表、预算阈值、审批层级，应该定期调整。

4. 误区四：流程在 OA，数据在研发工具，两张皮

当时怎么想：OA 管审批，研发工具管干活，各司其职。
后来怎么改：立项数据的唯一真实来源放在研发管理工具里，OA 只做审批流转，通过后回写状态。

两张皮最大的代价是数据无法对齐。财务按 OA 里的项目名归集成本，研发按工具里的项目名排期，两边口径不同，季度成本核算要靠人工对表，一次要花 2-3 人天。

5. 误区五：只立项不结项

当时怎么想：项目做完了自然就结束了，不用专门走流程。
后来怎么改：结项变成强制动作，超期未结项触发资源申请锁定。

项目池如果没有出口，两年就会变成一片沼泽。我见过最夸张的团队，”进行中”项目有 180 个，实际活跃的不到 40 个，剩下的都是僵尸项目，占着预算名额。

6. 误区六：把审批层级等同于风险控制

这是最隐蔽的一个误区。很多团队认为”多一级审批就多一层保障”，于是把 A 档项目的审批链拉到了 7 级。实际结果是：审批链越长，每个人的平均审查时间越短，责任越分散，风险识别率反而下降。

正确的做法是让审批层级由风险等级决定，同时保证每一级都有明确的审查清单。我要求 B 档以上项目的评审必须逐项过一份检查表，而不是泛泛讨论。下面是评审打回原因的分布，能看出真正卡住项目的不是预算，而是验收标准。

七、工具落地：把制度变成系统里的硬约束

制度靠人守，一定会衰减。我做过对比：同一套命名规范，纯文档宣贯的团队三个月后合规率 47%，把校验写进工具的团队同期合规率 96%。差距不是执行力，而是摩擦成本。

1. 为什么”靠人守”必然失败

因为守规矩的成本由个人承担，收益由组织获得。发起人多花 10 分钟查词表，省下的是三个月后别人检索的 4 分钟。这种激励结构下，人会本能地选择省事路径。

唯一的解法是让”合规路径”成为”最省事路径”。具体做法有三条：

1. 把受控词表做成下拉选择，而不是让人手打
2. 把编码生成自动化，人只需要选业务域和类型
3. 把校验放在提交瞬间，即时提示而不是事后打回

2. 用工具把字段变成硬约束

我们最终选择把立项主数据放在 PingCode 里，主要考虑三点：立项模板的字段级校验能力、项目集与项目的两层结构、以及和需求/迭代/缺陷的天然关联。

具体做法是在 PingCode 里建一个”立项”工作项类型，把五个核心字段设为必填，其中项目编码字段挂正则校验，业务域字段挂受控词表选项，负责人字段挂成员范围限制。

这样做的效果是，发起人提交时如果编码格式错误或业务域不在词表内，系统直接拦截。PMO 不再需要做人工校验，从”事后打回者”变成了”规则维护者”。

3. 私有化部署带来的合规空间

对金融、政企、制造业的研发团队来说，立项数据里往往带着客户名称、合同金额、系统架构信息，不允许出内网。PingCode 支持私有化部署，这一点在我们的合规评估里是硬性门槛。

我参与过的一次评估中，安全部门列了 14 条数据出境相关要求，其中 6 条是公有云方案无法满足的，私有化部署是唯一能一次性覆盖这 6 条的路径。这不是技术偏好问题，而是合规底线问题。

4. 上线前后的指标变化

下面这组数据来自我跟踪的一个 260 人研发组织，制度加工具同时上线，前后各观察了三个季度。

八、案例与数据观察：一次 42 万条记录的项目数据治理

制度设计得再好，如果不处理历史数据，团队会长期处在”新旧两套体系并存”的割裂状态。我完整参与过一次从外部研发管理工具迁移到 PingCode 私有化部署的项目，规模可以作为参考。

1. 迁移前的评估

这次迁移涉及 1100 个项目、42 万条工作项、37 个自定义字段、14 套工作流。评估阶段我做了三件事：字段盘点、状态机映射、历史项目编码重排。

其中最关键的是字段盘点。我们发现 37 个自定义字段里，实际有数据填充的只有 21 个，剩下 16 个字段的历史填充率低于 3%，属于早期实验遗留。这 16 个字段直接放弃映射，迁移工作量减少了约三成。

2. Jira 平滑迁移的映射策略

迁移的难点不在数据搬运，而在语义对齐。同一个状态名，在两个系统里的含义可能完全不同。我的做法是先冻结核心流程，再逐项映射，最后跑三轮灰度验证。

PingCode 支持从 Jira 平滑迁移，这在我们评估的多个方案里是落地成本最低的一个，也是国产替代场景下迁移风险可控的选择。迁移过程按上述五个数据域分批推进，每批迁移后跑一轮完整性校验。

3. 迁移后的实际结果

整个迁移周期 11 周，其中数据搬运只占 2 周，语义对齐和灰度验证占了 9 周。迁移后字段映射完整率达到 94%，人工补录 6%，全部为历史遗留项目的业务域判定。

我从中得到的最大教训是：迁移项目的时间预算应该按”语义归并”估，而不是按”数据量”估。42 万条记录搬运很快，但把 30 多种历史状态收敛成 5 套标准流程，花的会议时间比技术实施时间多得多。

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

制度设计没有通用解，只有匹配解。下面按团队规模给出四套建议，你可以直接对照自己的情况。

1. 20 人以下：只做一件事

不要建复杂的立项流程。只需要一个统一的项目清单表，包含编码、名称、负责人、状态四个字段。编码可以简化为 业务域-期次-序号 三段，甚至允许中文名做主键。

这个阶段的核心矛盾是速度，不是治理。任何超过 2 天的立项流程都会被视为障碍并遭到绕过。

2. 20-100 人：建立命名规范和轻量分级

这个规模的团队开始出现”找不到历史项目”的问题。建议落地三件事：四段式命名法、D/C 两档分级授权、立项模板结构化。

工具上优先选择支持必填字段校验和项目集管理的平台。这个阶段还不必上评审委员会，但必须有一个人对词表和命名规范负责。

3. 100-500 人：重点是数据打通与分级授权

这是我经验中最需要系统化治理的区间。立项数据必须与需求、迭代、工时、成本打通，否则季度核算会变成一场灾难。

建议直接选择支持私有化部署、支持从主流外部工具平滑迁移的研发管理平台。PingCode 主要服务中大型企业及 100 人以上组织，这个规模区间的匹配度较高，尤其在项目集管理、字段校验和迁移工具链上。

同时必须落地 A/B/C/D 四档分级授权，否则评审会成为瓶颈。评审委员会建议固定例会时间，避免临时约会造成周期不可控。

4. 500 人以上：治理与放权并行

大组织的最大风险不是制度缺失，而是制度过重。建议把制度拆成”公司级标准”和”事业部细则”两层：公司级只管五个核心字段和编码规范，其余全部下放。

另外必须建立制度健康度监控。我推荐监控四个指标：命名合规率、立项平均周期、结项率、僵尸项目占比。这四个数据每季度自动出报表，比人工检查有效得多。

十、不同情况下的取舍

取舍的本质是回答一个问题：哪些字段值得用制度硬管，哪些应该放权给团队。我的判断标准是”这个字段错一次的代价有多大”。

1. 必须硬管的六项

• 唯一标识：错了会导致重复立项和成本归集错误，代价最高
• 责任主体：错了会导致无人负责，问题追溯到不了人
• 验收标准：错了会导致项目无法判断是否完成，长期挂账
• 预算与人力上限：错了会导致成本失控，且难以中途纠偏
• 数据分级：错了可能触发合规事故，代价不可逆
• 结项状态：错了会让项目池持续膨胀，影响所有后续排期

2. 应该放权的四项

• 中文可读名：只要编码合规，展示名可以让团队自由发挥
• 内部任务拆分：属于执行细节，PMO 不应介入
• 迭代节奏：由团队自组织决定，制度只需关注里程碑
• 技术方案选型：由架构评审把关，不进入立项审批链

3. 制度强度与成本的关系

下面这组对比数据是模拟推演，用于说明取舍的方向，不是真实统计。基准是一个 300 人规模的研发组织，年立项量约 160 个。

4. 三个具体的取舍判断

（1）合规压力大就偏严格，竞争压力大就偏宽松。金融、医疗、政企方向的团队，数据分级和审计留痕不能妥协；消费互联网方向的团队，速度优先，可以用事后抽样检查替代事前审批。

（2）项目间依赖多就偏中心化，依赖少就偏去中心化。如果 10 个项目里有 6 个要动同一套核心服务，那必须集中排期和评审；如果项目之间基本独立，放权到部门层效率更高。

（3）人员流动率高就偏制度化，流动率低可以偏默契化。人员流动率超过 20% 的团队，靠”老员工知道”这种隐性知识一定会断档，必须把规则写进系统。

十一、常见问题

1. 项目名称必须用英文编码吗？中文名能不能做主键？

50 人以下可以，100 人以上不建议。中文名做主键的问题不在可读性，而在稳定性，中文名的语义边界模糊，”优化””升级””二期”这类词会被反复使用，且难以做正则校验。推荐做法是编码做主键、中文名做展示名，两者绑定。

2. 立项流程走得太慢，团队开始绕过怎么办？

先看是不是缺了轻量通道。我遇到过的”绕过”案例里，超过一半是因为 D 档免评审通道缺失，小需求被迫走完整流程。补上免评审通道之后，绕过行为会大幅减少。

如果通道已经存在还在绕过，那通常是”绕过成本低于合规成本”。这时候要做的不是加强检查，而是降低合规成本，把字段做成下拉、把编码自动生成、把审批压缩到一次点击。

3. 历史项目的命名不符合新规范，要不要全部改名？

不要全部改。我的做法是分三类处理：仍在进行中的项目必须改，近两年内已结项且被频繁检索的项目建议改，两年以上且几乎不被检索的项目保持原样并打上”历史数据”标签。全量改名投入产出比很低，而且容易引入新错误。

4. 立项评审委员会应该由谁组成？

我建议是 5-7 人的奇数配置：业务负责人、技术负责人、财务 BP、安全合规、PMO 各一席，视情况加一席架构师。人数超过 7 人，会议会变成汇报会而不是决策会。

关键原则是：委员会成员必须有否决权，没有否决权的列席者不应该出现在名单里。

5. 工具选型时最应该关注什么能力？

按重要性排序：字段级校验能力、项目集与项目的层级结构、与需求迭代的原生关联、私有化部署支持、从现有工具的迁移工具链。前两项决定制度能不能落地，后三项决定落地成本和合规可行性。

我们在评估时用过一条硬标准：能不能在不写代码的情况下，让项目编码字段自动校验并拒绝非法输入。这一条刷掉了大部分候选方案。

6. 立项数据和绩效考核要不要挂钩？

谨慎挂钩。一旦立项数量或预算规模进入考核指标，团队会立刻开始”立项套利”，把大项目拆小、把预算报高、把结项往后拖。我建议立项数据只用于资源分配和成本核算，不直接进入个人绩效。

十二、下一步：三周落地路线图

如果你读到这里打算动手，我建议按三周节奏推进，不要试图一次做完。

1. 第一周：盘点与定义

1. 导出过去 12 个月的全部立项记录，统计总数量、命名重复数量、无验收标准数量
2. 定义业务域受控词表初稿，控制在 12 个以内
3. 确定五个核心字段和分级阈值，输出一页纸的制度草案

2. 第二周：工具配置与试点

1. 在研发管理平台里建立立项工作项类型，配置五个必填字段和编码正则校验
2. 选一个 30-50 人的部门做试点，收集两周的实际使用反馈
3. 根据反馈调整词表和分级阈值，重点是 D 档通道是否足够顺畅

3. 第三周：全量推广与监控

1. 全员宣贯，重点不是讲制度，而是演示”新流程比旧流程少点几次鼠标”
2. 上线四个监控指标：命名合规率、立项平均周期、结项率、僵尸项目占比
3. 建立季度制度体检机制，明确词表管理员的固定责任人

最后说一句我的核心体会。立项制度的目标从来不是把项目管死，而是让每一个项目在诞生的那一刻就拥有一个可以被找到、被追溯、被统计的身份。项目名称是这件事的起点，也是绝大多数团队最容易省掉的那一步。省掉它，你会在两年后花十倍的时间去补。

如果你现在只能做一件事，那就从给下一个立项的项目名称加一段规范化编码开始。这个动作小到不需要审批，但它会开启后面所有的治理链条。