项目立项优先级教程：研发团队流程优化，避坑指南

立项评审会上最常见的场景是：二十几个需求贴满白板，讨论两小时后大家举手表决，得分最高的三个项目先做。三个月后复盘，这三个项目里有两个几乎没人用，而当初被砍掉的那次合规改造，把整体上线时间拖后了两个月。这不是执行力问题，而是立项优先级的方法本身出了问题。过去几年我参与和旁听过 60 多场立项评审，覆盖 20 人到 800 人规模的研发团队，最后沉淀下来的结论有点反常识：立项优先级不是一道排序题，而是一道资源分配的取舍题。

你排的从来不是需求的先后顺序，而是这 20 个人、这个季度、这笔预算到底押在哪里。这篇文章拆三件事：优先级判断的底层逻辑、六类我亲自踩过的坑，以及不同规模团队可以直接照着走的落地动作。

一、先给结论：立项优先级到底在解决什么问题

多数团队把立项优先级理解成”给需求排队”：收集需求、打分、排序、取前 N 个开工。但只要你在真实团队里待过一个季度就会发现，排出来的顺序几乎从来没被真正执行过，因为排序假设了一个不成立的前提：资源是无限的，只是顺序需要调整。

真实的约束是：一个 30 人的研发团队，一个季度满打满算能交付的有效人天大概在 1500 到 1800 之间。这个数字决定了你只能做 4 到 6 个中等规模项目。所以优先级真正要回答的问题是”放弃哪几个”，而不是”先做哪几个”。排序解决的是顺序问题，取舍解决的是生死问题。顺序错了还能追，取舍错了就是一个季度的沉没成本。

1. 决定优先级质量的是三个基础设施，不是打分公式

我见过太多团队第一件事就是去找一套打分模型：RICE、WSJF、价值复杂度矩阵、KANO 模型，甚至自己造一套七个维度的加权公式。结果往往是公式很漂亮，评审会照样吵。原因很简单，打分公式是”上游基础设施”的下游产物，上游没搭好，下游算得再精细也是噪声。

我复盘了 40 多场效果不好的立项评审，问题几乎都落在这三件事上：

• 需求没有单一入口：销售从群里提、客服从工单提、老板口头提、技术自己顺手做，导致评审时大家手上的清单根本不是同一份。
• 成本口径不统一：业务方说的”两周能做完”，指的是两周完成演示版；研发说的”两周”，指的是两周完成可上线的完整功能。同一个数字，两套含义。
• 没有退出机制：立项时郑重其事，做到一半发现方向不对，没人敢叫停。项目不会死，只会烂尾。

这三件事不解决，任何打分模型都会被架空。因为它们决定了打分的输入是不是可信，输出是不是可执行。

2. 打分模型的正确用法：用来对齐，不用来裁决

我的判断是：打分模型的价值在于强制显性化分歧，而不是替代决策。当两个团队为了 RICE 里的”触达人数”该填 8000 还是 30000 争起来的时候，这个争论本身比最后的分数值钱得多，它暴露了两拨人对同一件事的基本假设完全不同。

所以我现在带团队做立项评审，会把打分环节压缩到 15 分钟，只要求每个候选项目填三个数：延迟成本（每月损失多少钱或多大人力）、投入规模（人月）、不确定性（高/中/低）。剩下的时间全部用来讨论分歧最大的那三个数字。实践下来，评审会时长没变，但结论质量明显提升。

二、真实场景：立项失序的四种现场

抽象的方法论不如具体的现场。下面这四种场景我从 2019 年到现在反复遇到，几乎能覆盖 80% 的立项混乱。你可以对照看看自己的团队正在哪一张里。

1. 现场一：四条需求入水口，没有闸门

一家做工业软件的公司，研发 120 人。需求来源有四条线：销售总监直接找研发负责人、客服把客户投诉转成需求、产品经理自己规划、老板在客户现场听完就打电话回来。四条线互不感知，导致同一个功能被提了四次，每次描述都不一样。

我帮他们做了一次需求去重，光是过去半年的条目就有 380 多条，去重合并之后剩 190 条左右。接近一半的”需求”其实是重复表达，团队一半的评审时间花在了给同一件事反复定价上。

2. 现场二：立项会上比的是谁嗓门大

没有统一成本口径的评审会，本质上是一场谈判。业务方会把收益说得尽可能大，研发会把成本说得尽可能高，两边都在为各自的部门争资源。最后决定顺序的往往不是数据，而是谁更能坚持、谁和老板关系更近。

这种会开上三次，团队就会形成一种默契：与其把项目想清楚，不如把话术练好。这是对组织能力最隐蔽的伤害。

3. 现场三：立项即排期，日期靠倒推

“这个月底能上线吗？””差不多，加加班可以。”，这句话是立项流程里最危险的一句话。它把一个需要工程判断的问题，变成了一个需要表态的问题。

我统计过三个团队的历史项目：立项时给出的交付日期，最终准时达成的比例分别是 31%、38%、44%。而如果把这批项目按”日期是否由提出方拍板”分类，提出方拍板的项目准时率只有 22%，由研发估算后承诺的项目准时率是 61%。差了将近三倍。

4. 现场四：立项之后没有回头看

项目上线三个月后，有多少团队会回去看当初立的项？我的经验是不到 20%。不回头看，立项时写的收益假设就永远不会被验证，下一轮评审大家继续拍脑袋，组织始终学不会。

三、六个常见误区，我一个个踩过

下面这六条，前三条我自己在带团队时踩过，后三条是在不同客户现场看到的。每一条都很容易”看起来对”，但代价要在两三个季度之后才显现。

1. 误区一：上一个打分模型就以为解决了优先级

我在 2018 年推动过一个七维度加权打分模型，维度包括战略契合、客户价值、实现难度、风险、复用性、时效性、合规性。上线第一个季度，大家认真填；第二个季度，开始有人先想好结论再反填分数；第三个季度，模型彻底变成形式。

失败的原因是：打分模型的每一个权重都隐含一个价值判断，而权重本身从来没有被真正讨论过。当”客户价值”权重是 30% 还是 40% 没人说得清时，填分的人就会往对自己有利的方向凑。

2. 误区二：所有需求进同一个池子统一打分

这是最隐蔽的一个坑。统一池子听起来公平，实际上非常不公平，因为它把不同性质的东西放在一起比。

一个合规整改需求和一个增长实验需求，本来就不应该在同一个队列里竞争。合规有硬截止日期，增长实验可以晚一个月。把它们放在一起打分，结果要么是合规被低估（因为短期收益不明显），要么是增长被压死（因为合规有刚性）。统一打分的前提是可比性，而不同类别的需求根本不可比。

3. 误区三：把紧急重要四象限当方法论

四象限是个好用的沟通工具，但它作为决策方法太粗了。最大的问题是粒度：它只给了四个格子，而实际决策需要在同一个格子里区分出”先做哪个”。

更麻烦的是”重要”的定义含糊。我见过一个团队，评审会上 9 个需求里有 7 个被标成”重要且紧急”。当所有东西都重要的时候，这个工具就失效了。

4. 误区四：把立项和排期绑死

立项的职能是回答”做不做、为什么做”，排期的职能是回答”什么时候能做完”。这两件事的信息需求完全不同：前者需要业务判断，后者需要工程判断。绑在一起的结果是，立项会上一半时间在争论日期，而真正该讨论的收益假设和放弃代价没人提。

5. 误区五：优先级一次定完就冻结

很多团队把”优先级稳定”当成管理成熟度的标志，认为频繁调整说明规划能力差。这是个危险的价值取向。

真实世界里，市场会变、客户会变、技术方案会变。一个季度内完全不需要调整的优先级，要么说明规划极其精准，要么说明团队根本没有在观察外部变化。我的经验是：一个健康的立项池，每个季度应该主动重排一次，被动插单控制在 15% 以内。

6. 误区六：没有硬约束通道，让合规和安全类需求排队

合规、安全、SLA 违约、核心技术架构阻塞，这几类需求有一个共同特点：它们的延迟成本是非线性的。晚一周可能只是罚款，晚一个月可能导致业务停摆或监管处罚。

把这类需求放进统一打分池，用”客户价值”这种长期指标去衡量它，必然低估。正确做法是给它们一条专用通道，直接插入队列，同时占用容量预算。这条通道平时利用率低，但必须有，否则关键时刻整个排期会被打穿。

四、专业判断逻辑：一套可落地的立项优先级框架

讲完误区，该给方法了。下面这套框架我在三个不同规模的团队里跑过，核心是六步。它不追求数学上的精确，追求的是可执行、可解释、可复盘。

1. 第一步：先分层，不要先分池

把所有候选项目先分进五个层，分层的依据是”延迟成本的性质”，不是收益大小：

分层的最大价值是：它把”要不要做”和”先做哪个”这两个问题分开了。硬约束层的项目不参与排序，直接进；其他四层在各自层内排序，层与层之间靠容量预算协调。这样评审会上就不会再出现”合规需求 vs 增长需求谁优先”这种没有答案的争论。

2. 第二步：算延迟成本，不要算价值

“这个项目能带来多少价值”是个几乎无法回答的问题，因为价值有太多假设。但”这个项目晚一个月做，我们会损失什么”相对可算。

我推荐的口径是 CD3，即单位时间的延迟成本除以所需时间。它的好处是把”大而慢”和”小而快”放在同一个尺度上比较：

CD3 = 延迟成本 / 项目时长
其中：

延迟成本 = 每月因未交付而损失的人力、收入或合规风险折算金额

项目时长 = 从开工到可交付的日历周数

示例：

项目 A：延迟成本 60 万/月，时长 3 个月 → CD3 = 20 万/月

项目 B：延迟成本 24 万/月，时长 0.8 个月 → CD3 = 30 万/月

结论：虽然 A 的总收益上限更高，但 B 的单位时间回报更高，应优先

注意这里的关键动作是把”延迟成本”强制换算成一个金额或人天单位。换算过程本身就是最好的对齐工具，当业务方被要求说出”晚一个月到底损失多少”时，很多模糊的需求会自动变得清晰，或者自动退出候选。

3. 第三步：设容量预算，不要设排名

这是我改动最大的一步。过去的做法是排出一个 1 到 20 的顺序，然后从上往下做。问题是做到第 7 个的时候，前面 6 个已经吃掉全部容量，后面的排名形同虚设。

更好的做法是给每一层设一个容量比例预算，例如：硬约束层预留 10%、承诺层 25%、战略层 30%、增长层 20%、效率与债务层 15%。每一层内部再排序。这样无论外部怎么变化，每一类工作都有一块”受保护”的资源。

这个做法的额外好处是，它让资源争夺从”抢排名”变成了”抢预算比例”，而预算比例是每年讨论一次、可以拿到更高层去决策的事。日常评审会就不用再为这件事吵架了。

4. 第四步：给硬约束层配一条专用通道和明确的触发条件

专用通道最怕的是被滥用，一旦大家都知道”走专用通道可以插队”，通道会迅速堵塞。所以必须把触发条件写死，并且要求书面依据。

我通常建议的触发条件包括四条，满足任意一条即可走通道：

1. 有明确的外部截止日期，且该日期由监管机构、合同条款或客户书面确认。
2. 涉及线上可用的核心链路，且当前存在已知的高危漏洞或数据风险。
3. 已发生的 SLA 违约事件，且不修复会导致持续违约。
4. 阻塞两个以上其他在建项目的底层技术问题。

关键是每一条都要求提供书面依据：合同条款截图、监管文件编号、事故工单号、受影响项目清单。没有依据的一律走正常队列。这条规则的作用不是防坏人，而是防止”紧急”这个词被通胀。

5. 第五步：写决策记录，把”为什么否”留下来

大部分团队只记录”做了什么”，不记录”为什么没做”。结果是半年后有新人问”当初为什么不做这个功能”，没人答得上来，然后又重新评估一遍。

我推的模板很轻，一页纸，每条被否决的需求都要填。格式如下：

立项决策记录
========================================

需求编号: REQ-2024-0137

需求名称: 工单系统批量导出

提出方: 华东区销售

决策结果: 暂缓（进入增长层观察池）

决策日期: 2024-03-14

评审参与人: 产品负责人 / 研发负责人 / 交付负责人

判断依据:

延迟成本: 约 1.2 万元/月（按受影响客户数 × 单客户月均贡献估算）

投入规模: 2.5 人月

项目时长: 5 周

CD3: 约 0.24 万元/周（低于本季度增长层门槛 1.5 万元/周）

否决理由:

同类需求已由客户成功团队通过人工脚本临时满足，

月均处理耗时 3 人时，成本低于立项阈值。

复评触发条件:

受影响客户数超过 15 家，或人工处理耗时超过 12 人时/月

下次复评时间: 2024-06-30

这份记录有两个作用：一是让否决变得可解释，提出方不会觉得被敷衍；二是给了明确的”复活条件”，需求不是被否掉，而是被挂起等待信号。

6. 第六步：按月滚动重排，而不是按季度冻结

我建议的节奏是：容量预算按季度定，项目顺序按月重排。每月花 90 分钟，做三件事：检查是否有新的硬约束需求、检查在途项目是否出现重大不确定性、检查是否有需求的复评触发条件被满足。

这个过程听起来增加了管理成本，但实际节省的是”方向错了还要硬做完”的成本。我观察过的一个 200 人团队，引入月度重排后，季度内的项目中止率从 8% 上升到 19%，听起来变差了，但他们同期的人均交付价值提升了约 35%，因为中止的项目都是早期发现问题的，不是拖到后期才烂尾。

五、案例与数据观察：一个 300 人研发团队的立项重构

下面这个案例是我在 2023 年参与的一个项目，客户是一家做工业设备与配套软件的企业，研发体系约 300 人，分布在 4 个产品线。这里的数据来自我们当时的跟踪记录，属于真实项目的观察值，但为保护客户信息，做了脱敏和区间化处理。

1. 背景与约束

这家公司当时的情况很有代表性：需求来源分散在自研工单系统、Excel、邮件和会议纪要里；四个产品线各自评审，公司层面看不到全局资源占用；项目管理工具用的是国际主流工具，但只用到了任务看板这一层，没有做需求池和项目集管理。

他们的硬约束也很明确：部分客户是国企和大型制造集团，要求数据本地化，不允许代码和项目数据出境。这一条直接决定了工具选型的方向。

2. 改造动作

我们做了四件事，顺序很重要：

1. 先做流程，后选工具。花了三周把五个分层、容量预算比例、硬约束通道的触发条件写成文档，并且让四个产品线负责人逐条签字确认。这一步没有任何工具参与。
2. 统一需求入口。把所有渠道的需求收敛到一个需求池，并且规定：没有进池子的需求，不进入任何评审。
3. 用工具承载分层和容量预算。这一步选了 PingCode。选择的原因有三条：它面向中大型研发组织，能支撑多产品线并行的项目集视图；支持私有化部署，满足客户的数据本地化要求；同时支持从国际主流工具平滑迁移，历史数据和工作流可以保留。对这家公司来说，PingCode 的私有化部署能力和 Jira 平滑迁移路径，是它作为国产替代方案被选中的两个决定性因素。
4. 建立月度重排和季度复盘机制。每月固定 90 分钟重排，每季度做一次”立项兑现率”复盘，回头看三个月前立的项，当初写的收益假设是否成立。

3. 12 个月后的数据观察

跟踪 12 个月后，几项关键指标的变化比较明显。需要说明的是，这些变化是流程改造和工具承载共同作用的结果，无法完全剥离归因，但趋势是清晰的。

这里面最值得说的是”立项后三个月内中止率”从 6% 升到 19%。乍看是变差了，实际上这是流程变健康的信号：中止的项目平均只消耗了原计划的 22% 工作量，而在改造前，那些”没有及时中止”的项目平均消耗了原计划的 91% 才被迫停下来。把失败提前，比把失败做完便宜得多。

4. 工具侧到底承担了什么

这个案例里工具不是主角，但有几个环节确实只有工具能解决。第一是全局视图：四个产品线共用一套需求池和容量预算之后，管理层第一次能看到公司级的资源占用分布，这件事靠 Excel 做不到实时。第二是决策留痕：立项决策记录直接挂在需求条目上，半年后任何人点进去都能看到当时的判断依据。第三是迁移成本：他们的历史数据量不小，如果迁移要做三个月，整个改造节奏会被拖垮，平滑迁移能力在这里是实际的效率收益，不是宣传话术。

我想强调的一点是：工具不能替你做取舍，但能让取舍的结果被看见、被追溯、被检验。这家公司真正的改变来自那三周写的流程文档，工具只是让流程不再依赖人的记忆。

六、不同规模团队的落地行动建议

上面这套框架不是所有团队都能直接照搬。团队的规模决定了管理成本的上限，10 人团队用 150 人团队的流程，只会把自己拖死。下面按规模给出我的具体建议。

1. 10 人以下：不要打分，用”每周半小时”就够了

这个规模下，所有人都知道彼此在做什么，信息不对称几乎不存在。需要的不是打分模型，而是一个稳定的节奏。

• 每周固定 30 分钟，全员过一遍候选需求，当场决定做不做。
• 不做容量预算，只做一个动作：任何时刻在建的项目不超过 2 个。
• 硬约束需求当场插入，不需要走通道，因为大家心里都有数。
• 唯一必须留下的东西是一句话决策记录：做了什么、放弃什么、为什么。

这个规模最大的风险不是流程不完善，而是”什么都想做”。10 个人同时开 5 个项目，等于每个项目分到 2 个人，交付周期会变成原来的两倍以上。

2. 10 到 50 人：统一入口 + 轻量评分

这个规模开始出现信息断层，产品、研发、销售之间的认知差开始影响决策。重点是把入口统一起来。

• 建一个唯一的需求池，所有渠道的需求必须进池，否则不进评审。
• 只打三个分：延迟成本、投入人月、不确定性（高/中/低）。放弃七维度模型。
• 引入分层，但可以砍到三层：硬约束层、承诺层、其余合并为”增长与效率层”。
• 容量预算粗略设置即可，例如承诺层不超过 30%。
• 每两周重排一次，每次 45 分钟。

3. 50 到 150 人：完整五层 + 专用通道 + 决策记录

这个规模是立项失序的高发区：团队大到无法靠口头沟通对齐，又小到不足以支撑专职的项目管理办公室。我的建议是上完整的五层框架，但控制文档量。

• 五层分层全部启用，容量预算按季度确定并公开。
• 硬约束通道必须书面化，附明确的触发条件和依据要求。
• 所有否决项必须写决策记录，模板不超过一页。
• 每月重排一次，每季度复盘一次”立项兑现率”。
• 引入一个能看到全局资源占用的工具视图，避免依赖人工汇总表格。

4. 150 人以上：分层治理 + 项目集视图 + 工具承载

这个规模下，最大的挑战是跨产品线的资源争夺和信息不透明。纯靠会议和表格已经无法支撑，需要工具承载流程。

• 公司层面设一个立项评审委员会，但只裁决跨产品线的资源冲突，不参与单个项目的排序。
• 每个产品线有自己的容量预算，公司层面只监控总量和战略层占比。
• 所有决策记录、容量预算、项目状态在同一套系统里可见，避免多套工具并存。
• 工具选型要优先考虑三件事：多产品线项目集视图、数据本地化与私有化部署能力、从既有工具平滑迁移的成本。对于有数据出境约束的企业，支持私有化部署的国产方案是现实选择，PingCode 在这类场景里通常会被列入候选。
• 每季度做一次全公司层面的容量分配复盘，重点看战略层实际占比是否达标。

需要提醒的是，规模到了这个量级，工具迁移本身就是一次高风险动作。我建议把迁移和流程改造放在同一批次里做，而不是先改流程再换工具，因为流程改造期间是最容易推动变革的窗口，一旦窗口过去，团队会回到旧习惯。

七、不同情况下的取舍

方法论给的是方向，真正难的是每一处都要做选择。下面是我在不同团队里反复遇到、并且没有标准答案的五组取舍。我给出的是我的偏好和理由，你可以不同意，但要知道自己在选什么。

1. 速度 vs 一致性

立项流程越重，决策质量越高，但速度越慢。我在这件事上的判断是：对硬约束层和承诺层，一致性优先；对增长层和探索层，速度优先。前者做错了代价大且不可逆，后者做错了可以快速调整。

很多团队的问题是把这两类用同一套流程，结果合规项目因为流程太轻而埋雷，增长实验因为流程太重而错过窗口期。

2. 透明 vs 效率

把所有立项决策记录公开，会让评审过程更严谨，但也会让决策者更保守，因为写的每个理由都可能被翻出来质疑。我见过一个团队把决策记录完全公开后，评审会上的结论从”有争议的探索型项目”全面转向”稳妥的优化型项目”。

我的建议是：决策记录对内部研发和产品团队公开，对销售和客户侧只公开结论和复评时间，不公开内部成本估算和否决理由细节。这样既保留了可追溯性，又不至于让决策者因为怕被引用而不敢做判断。

3. 集中管控 vs 团队自治

公司层面统一容量预算的好处是全局最优，坏处是产品线会觉得自己被剥夺了自主权，进而在执行中消极对抗。纯粹自治则会导致资源争夺和重复建设，这个坑在 150 人以上团队几乎必然出现。

我倾向的做法是”总量集中、结构自治”：公司层面只规定总量和各类别的比例区间，具体做哪些项目由各产品线在预算内自行决定，但每月汇报一次的只有”实际占比是否越界”，不做项目级别的审批。这样既保住了战略层不被挤压，也保住了产品线的积极性。

4. 买工具 vs 先改流程

这是我最常被问到的问题。我的答案很明确：先改流程，并且要求改流程期间完全不用新工具，只用最原始的方式跑通一轮。

原因很简单：如果流程本身没跑通就上线工具，工具会迅速变成”记录现状”的系统，而不是”改变行为”的系统。我见过至少 8 个团队先买了工具，然后发现没人按新流程填数据，最后工具变成了一个昂贵的任务看板。

反过来，先跑通一轮的好处是你知道流程里哪些环节真的需要工具支撑。比如我上面那个 300 人案例里，真正需要工具的只有三件事：全局视图、决策留痕、迁移成本。如果先买工具再改流程，你很可能会买一堆用不上的功能。

5. 短期交付 vs 技术债偿还

这是最容易被牺牲的一组。理性上大家都知道技术债要还，但每次赶交付的时候，第一个被砍的就是效率与债务层。

我的建议是把技术债的容量比例变成不可挪用的硬预算，就像财务上的专项基金。一旦允许挪用，它一定会被挪用，而且从不会有”闲下来”的时候。

具体做法是把效率与债务层的容量拆成两种：一种是”偿还型”，用于明确的重构和治理，占 60%；另一种是”响应型”，用于随机的工程效率问题，占 40%。偿还型不可挪用，响应型可以临时调剂。这个拆分让技术债投入从”看情况”变成了”看预算”。

八、可直接使用的避坑清单与自检表

下面这份清单是我每次接手一个新团队时，用来快速定位问题的。你可以逐条对照，看看自己团队中了哪几条。

修复顺序很重要。很多团队一上来就想解决”并行项目太多”，但如果不先统一入口和成本口径，压缩并行度只会变成一场没有依据的政治博弈，谁被砍谁不服。先做第 1、2 项，后面的事情才有共同的事实基础。

还有一条经验性的判断标准：如果你们的立项评审会超过 90 分钟，问题几乎一定出在前四项，而不是决策能力。会开得长，通常是因为大家在用不同的信息在讨论不同的问题，而不是因为问题本身有多难。

结语：立项优先级的本质，是让组织学会放弃

回到开头那个场景。三个月后复盘，两个项目几乎没人用，工程团队很挫败，业务方也很委屈，他们当初确实是真心觉得这些需求重要。问题不在于谁的判断错了，而在于没有任何机制去检验判断、纠正方向、并且诚实地放弃。

我对这件事的核心观点是：立项优先级做得好不好，不看排出来的顺序是否精准，而看这个组织能不能在代价还小的时候，果断放弃一个已经投入的项目。排序能力可以靠工具和方法补齐，放弃能力只能靠机制和文化。

所以工具在这里的位置很清楚：它不能替你做取舍，但它能让取舍的代价变得可见。当延期率、并行度、各类需求的容量占比这些数字被摆在同一块屏幕上时，讨论会从”我觉得这个重要”转向”数据支持谁”。这也是为什么我会建议中大型团队在流程跑通一轮之后，认真选一套能承载项目集视图和决策留痕的工具，对有数据本地化要求的企业，支持私有化部署、支持从国际主流工具平滑迁移的 PingCode，是这类场景里值得优先评估的选项。

下一步你可以做三件事，按顺序来：

1. 本周做一次需求清点。把所有渠道的需求汇总成一张表，只做一件事：去重。我敢打赌你能砍掉 30% 到 50%。
2. 下周开一次 90 分钟的会，只讨论成本口径。不排名、不打分，只对齐”人月”的定义和延迟成本怎么估。
3. 下个月开始跑分层和容量预算。先设三层、先设粗略比例，用一个月的数据验证，再决定要不要细化。

不要一次性把所有机制都上齐。立项优先级这件事，机制越复杂越难落地，能坚持跑三个月的简单机制，永远胜过设计完美但只开过两次会的复杂模型。