作为一个兼具平台工程背景与业务增长诉求的 Product Engineer，我在不同阶段经历过很多团队的项目管理模式。最让人筋疲力竭的研发场景，往往来自于需求端无边界的随意性：销售在即时通信软件里催着救火，售前根据项目标书提来大批非标诉求，技术伙伴急于推进产品集成，而上游开源社区的主干合并窗口又在倒计时。
如果团队没有一套刚性的契约来承接和调度这些输入，产品经理就会沦为一个疲于应付的传话筒。需求在会议室里反复拉扯，研发资源在插队与返工中被稀释，最终导致整个交付节拍彻底失控。
这套产品规划流程（Planning Workflow）是我以往在极狐GitLab产品团队参与运转的核心机制之一。面对跨地域、跨团队、开源主干与商业化诉求高度交织的复杂场景，我们依靠一套确定性工作流，把来自各方的混沌输入转化为可预测的月度交付。今天我把这套流程重新梳理出来，做一次结构化的复盘。
一、 输入端的契约化：需求不是聊天记录，而是带有类型的状态实体
在开源与分布式团队中，协作的第一铁律是：消除私聊和口头承诺。所有没有沉淀为结构化议题的需求，在系统视角下都是不存在的。
在极狐的产品输入体系中，需求被明确区分为四个核心来源，并绑定了严密的标签协议：
- 业务与客户反馈（Sales / CS）：销售与客户成功团队提交议题时，必须使用指定的标准化模板（精简版或详细版），附带受影响订单规模与客户议题链接。客户反馈的需求通过一套明确的业务权重标签进行分级：
| 标签标识 | 语义级别 | 业务判定条件 | 调度动作与响应 |
|---|---|---|---|
~"CREQ::blocker" |
紧急阻断 | 直接导致采购订单停滞或续约无法进行 | 产品负责人当日介入，列入近期最高优先级排期 |
~"CREQ::high" |
核心增益 | 提升使用满意度，但不阻塞商务签约进展 | 纳入四象限评估，滚动排入 3 版本 Backlog 池 |
~"CREQ::low" |
体验优化 | 非核心阻塞项，属于体验锦上添花的诉求 | 视工程带宽闲置情况由研发按兴趣自主认领 |
- 战略与生态伙伴集成（Presales / Strategic Alliances）：这类需求并不直接对应具体租户，而是涉及底层技术生态对接。必须填写专用的集成提议模板，由战略部统一汇总后再与产品团队进行复杂度与客户价值二次研判。
- 社区与内部观察（Insight & Community）：团队成员或外部贡献者提出的产品建议统一打上
~"insight"标签，归入常态化需求池。 - 紧急升级机制（Escalation）：如果确实遇到紧急阻塞事件，可以打上
~"Escalation"标签直达产品经理。但机制附带了一个硬性约束：沟通会议纪要必须同步回写到 Issue 内，若复核后确认达不到紧急标准，标签会被立即剥离。
在底层逻辑上，这其实是一套 Labels as State Machine。
通过将需求拆分为 type::feature、type::bug、type::maintenance 等工业类型，并叠加归属团队标签和客户优先级标签，每一个 Issue 从创建之初就自带类型签名。产品团队承诺在一周内对所有标准化 Issue 给出公开答复，讨论全程公开透明。这就从源头上切断了“谁嗓门大就先做谁”的人情消耗。
二、 决策引擎：四维评估与价值-复杂度矩阵
当海量需求被规范化录入之后，接下来面对的是调度问题：有限的工程带宽应该投向哪里？
极狐采用四维评估模型来界定一个功能的落地前提：
- 价值（Value）：由产品经理负责，依据受影响用户基数、订单权重与客户诉求级别定性定量评估；
- 可用性（Usability）：由 UX 设计师负责，评估交互路径是否顺畅、是否契约化符合极狐设计系统；
- 可行性（Feasibility）：由研发负责人负责，评估技术架构风险、依赖服务稳定性与实现工期；
- 商业可行性（Business Viability）：由产品经理负责，权衡功能对商业化转化、客户留存和产品层级划分的影响。
在完成四维初筛后，所有议题被映射到一个二维坐标系中，这就是经典的价值-复杂度框架。
每个月的里程碑规划并不会固定死某一个需求的归宿，而是会在四象限动态分区中重新审视所有未排期条目：
- 第一象限（高价值、低复杂度）：这是典型的快赢项目（Quick Wins），实现代价小但对客户或商业有即时收益，排期时享有第一优先级。
- 第二象限（高价值、高复杂度）：这属于战略级功能（Strategic Epics）。直接整体推进往往会导致一个 Sprint 被撑爆，因此产品经理需要和研发团队共同把大需求拆解成若干个可独立验证、渐进交付的小特性，分批次滚入后续版本。
- 第三象限（低价值、低复杂度）：这类属于琐碎的小修小补或边角体验优化。它们不会挤占核心资源，而是停留在 Backlog 中，由研发工程师按个人兴趣在闲暇时自主认领消化。
- 第四象限（低价值、高复杂度）：既难做又见不到明显回报，属于典型的资源黑洞。这类需求在规划评审中会被明确拒绝并关闭议题，坚决不进入里程碑。
三、 节拍控制：三版本异步滚动与双周前置冻结
如果说矩阵解决了“做什么”，那么节拍控制解决的就是“什么时候交付”。
极狐GitLab 采用严格的月度发布节奏，与上游 GitLab Inc. 保持周期一致。区别在于，极狐的发布日期比上游官方 EE 版本延后一周。这一周留给极狐本地化包的集成构建、跨环境全量测试以及热修复应急排查。
为了抵御多团队协作中的阻塞，规划体系引入了两个关键机制：
1. 面向上游的 3 版本滚动 Backlog
由于极狐的代码变更很多需要向上游主干提交 Merge Request，而上游工程师的 Review 和合并周期不可控，如果等到当月才去规划当月的特性，极易因为评审拖延导致版本跳票。因此，产品团队始终保持着向后看 3 个版本的滚动 Backlog（例如同时规划当前 M、M+1 与 M+2）。这为跨组织的代码合并预留了充足的时间缓冲。
2. M-2 里程碑计划与范围冻结
很多敏捷团队受挫的原因，是把 Sprint 计划会议变成了即兴头脑风暴。而在极狐的实践中，冲刺启动被分解为严格的时间步阶：
- M-2 阶段（冲刺开始前两周）：召开M-2 里程碑计划会议。此时产品经理和 UX 设计师必须拿出已经完备的用户故事、使用用例（Use Cases）与交互原型。研发工程师接单后，用一周时间研究技术细节，给出工期预估与任务拆分。
- M-1 阶段（冲刺开始前一周）：执行严格的范围冻结（Scope Freeze）。一旦进入这个窗口，当期里程碑的研发范围原则上彻底锁死，不再接受任何重大需求变更。
- M 阶段（正式开发）：进入两周的开发冲刺，研发团队在无外界干扰的稳定范围内全力交付。
这种时间上的前置错位，把需求设计阶段的混乱与技术实现阶段的专注完全隔离开来。
四、 工程师视角的反思：这套工作流的代价与边界
任何流程都有其局限性，其本质是通过规则来置换不确定性。在实际运转这套规划流时，我也切身体会到了它带来的工程代价：
- 多维标签体系的维护成本：从团队标签、客户优先级到议题类型，多层标签给非技术团队带来了不小的理解门槛。如果缺乏自动化机器人辅助校验，极易出现漏打标签、错打标签的情况，最终导致未被标记的需求沉底。
- 价值评估的主观偏差：虽然四象限矩阵在理论上非常优雅，但“价值”和“复杂度”在实践中很难精确量化。销售往往倾向于把所有输单归因于缺少某个特定功能，而研发也可能因低估第三方依赖而压缩复杂度预估，这需要团队在多次迭代复盘中不断校准打分基线。
- 跨组织异步协同的时差损耗：保持与上游月度主干对齐极大降低了分支维护成本，但在遇到国内客户急需的定制特性时，上游严格的审查流会导致交付周期被迫拉长，往往需要通过局部特性开关或分支临时打补丁来折中解决。
在现代系统设计与自动化协同中，这套流程带给我的启发极为深远。无论是做敏捷产研交付，还是在当下探索多智能体系统与 DAG 状态机 的调度，其底层逻辑完全相通：你必须设定强类型的契约输入，建立具备剪枝能力的评估通道，并通过前置锁定时钟周期来抵抗系统熵增。
这也是我作为产品工程师一直坚持探索 AI 工作流编排 的核心原因：用确定性的规则底座，承载起真实世界复杂且多变的创造力。
关于作者
郭强 (GuoBug)，Product Engineer，做平台工程也做业务增长。目前主要在折腾 AI 工作流编排、DAG 状态机与确定性系统架构。
开源项目与主页：https://github.com/GuoBug · https://guobug.github.io
欢迎就工作流引擎架构、拓扑调度和低门槛开发体验交流指教。