1. 项目背景与痛点
目前我们公司签的两个大型定制化软件项目，服务于 A、B、C、D 四个工厂。高层规划以 A 厂为基础版，待 A 厂上线后，逐步为 B 厂、C 厂、D 厂开展定制化改造。
前期 A 厂基础版开发阶段进展顺利，无需考量其他三厂的差异化需求。但随着项目进入中后期，B、C、D 三厂陆续上线，定制化需求与本地化适配，项目团队陷入手忙脚乱的状态。
初期，版本相关信息全靠开发组长记忆，其他同事辅助验证；但随着时间推移，各厂版本差异持续扩大，管理陷入混乱 —— 没人能清晰说明各厂分支与主线的具体区别，发布的安装包混乱无序，源文件查找困难，现场出现的 BUG 也因版本信息不明确而无法复现。
所以项目经理发现问题后，决定用“版本矩阵”对项目的版本进行管理。
2. 核心管理工具：版本矩阵《版本差异清单》
“版本矩阵” 即《版本差异清单》（又称《版本管理表》），是一张二维表格，核心作用是清晰可视化各厂版本差异，为全团队工作提供统一基准，用Excel 管理即可。
2.1 《版本差异清单》结构
- 横向：A、B、C、D 各厂名 + 需求ID、代码分支、编译包位置、备注等，根据项目需要定制列内容
- 纵向：核心模块、菜单、功能分类、具体功能点
- 单元格：用 “√” 标记功能存在，用 “×” 标记功能缺失
2.2 Excel 模板
| 模块名称 | 功能名称 | A 厂（主干） | B 厂 | C 厂 | D 厂 | 需求 ID | 代码分支 | 编译包位置 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| 生产报表 | 综合物料查询 | × | √（新增） | × | × | TWQE-2199 | B-branch-08 | /package/B-V2.1 | |
| 设备管理 | 设备申请 | √ | √ | × | √（修改） | TWQE-142 | D-branch-09 | /package/D-V2.1 | C厂设备用第三方系统 |
2.3 管理规范
- 版本迭代时，复制当前工作表生成新表（可用时间命名），避免覆盖历史数据；
- 文档由产品负责更新，触发更新的两个核心节点：① 需求正式下发后（提前标注计划变更）；② 功能上线完成后（确认实际变更）；
- 全团队工作均需以该表为基础展开，技术开发核对代码分支、测试验证功能范围、厂方确认需求落地均需参照此表。
3. 版本管理启动流程
版本管理启动优先采用 “先执行再完善规则” 的模式（适配小型团队、敏捷开发、新项目），具体步骤如下：
- 产品牵头摸清现状：组织各厂负责人、技术团队，梳理各厂当前版本与 A 厂主干的核心差异，输出《版本差异清单》；
- 结合项目实际制定规范：基于清单初稿和实际操作，补充《版本管理规范（初稿）》文档（涵盖范围、人员、职责等核心内容）；
- 迭代完善：初期《版本管理规范》无需追求完美，可先搭建核心框架，随着项目推进逐步细化补充，确保贴合实际执行需求。
也可以采用 “先定规则再执行” 的模式，但要有经理的项目经理和完善的文档支持
4. 核心管理规范《版本管理规范》
4.1 管理范围
- 管控对象：A、B、C、D 四厂的定制化软件版本及对应代码分支、编译包；
- 管控模块：生产报表、设备管理、物料溯源等核心业务模块；
- 生效时间：2024年3月 ~ 2029年3月（本项目合同约定时间，含质保期）
- 除外事项：暂无
4.2 人员职责
- 产品经理：主导版本差异梳理、需求分流决策、合并功能识别、规范编写与更新；
- 项目经理：统筹进度、协调跨厂 / 跨角色资源、把控版本迭代节奏；
- 技术组长：搭建分支架构、执行版本合并、解决技术层面的版本冲突；
- 测试：跟进版本一致性校验（验证各厂版本同步情况）、反馈版本质量问题；
- 厂负责人：提出定制需求、配合功能验证与版本确认。
4.3 分支与版本号规则
- 主干定义：A 厂版本为核心主干，仅承载所有厂通用的功能 / 优化，禁止单独为 A 厂新增定制功能；
- 分支定义：B、C、D 厂各设独立分支，仅承载本厂定制功能；D 厂专属功能在本厂分支下单独标注；
- 版本号规则：主干版本（V + 大版本。小版本，如 V2.1、V2.2）；厂级分支版本（主干版本 + 厂名 + 定制版本，如 V2.1+B 厂定制 1.0）。
4.4 合并流程
- 合并条件：核心通用功能（≥2 个厂存在）必须合并，次要通用功能（≥3 个厂存在），对客户有帮助或提高效率，对系统有品质、功能提升等原则筛选；
- 合并流程：由产品识别待合并功能，标记后提交项目团队讨论通过或由 项目经理、技术经理确认；
- 合并时机：确认合并的功能排入工作计划（少量合并内容可攒集后集中开展）。
5. 可以不合并吗，为什么要合并？
必须开展版本合并工作，原因如下：
- 减少版本差异：若长期不合并，最终会形成多个完全独立的定制版本，开发与维护成本将成倍增加（如修复一个共性 BUG 需在四个版本中重复操作）；
- 实现功能复用：将分支中优秀的通用功能合并到主干，可直接复用到其他工厂，避免重复开发，提升整体效率；
- 降低管理复杂度：以主干为统一基准，可减少功能冗余与逻辑冲突，降低版本混乱带来的意外风险，实现项目管理的 “熵减”；
- 注意，合并要规避镀金风险，若担心合并带来的问题，可在合并后屏蔽新功能。
6. 市面主流版本管理策略
- 主干开发：小分支快进快出，适配敏捷高频迭代（比如美团外卖的优惠券功能迭代）
- 严格分支流：分支按开发阶段分工，适配大型复杂软件（比如Photoshop每年更新一版）
- 简化分支流：临时分支 + 评审，适配 Web 工具随时更新（多用于SaaS平台，比如飞书的在线表格优化）
- 环境分支流：主干 + 环境 + 定制，适配多厂 / 多租户项目（本次项目核心采用此模式，以 A 厂主干为基础，逐步铺开到 B、C、D 厂，支持厂级定制）；
- 发布分支：固定版本只维护，适配旧版本 / 定制化项目（比如WPS中车企业版）
7. 产品核心职责
综合以上内容，产品在这版本管理这件事情上起到重要和牵头的作用，主要职责如下：
- 识别项目版本风险（非必要，其他干系人也可识别）；
- 编写与更新《版本差异清单》（核心必要职责，确保清单信息准确、及时）；
- 需求分流决策：评审各厂定制需求，明确需求归属（如主干通用 / D 厂专属等）；
- 识别分支待合并功能：定期梳理各厂分支功能，标记符合合并条件的通用功能；
- 组织版本同步评审会：不定期牵头召开合并评审会，协调 项目经理、技术组长、厂负责人确认合并功能、优先级（不一定是正式会议）；
- 编写与更新《版本管理规范》（非必要，可以是项目经理、技术经理来编写）；
- 规范宣贯与培训：向技术、测试、厂负责人讲解版本管理规则与《版本差异清单》使用方法，确保全团队理解执行。
7. 最后
我后面没参于这个项目，这个方案没能用上，当时的解决方案是项目经理和技术组长用文档的方式，罗列出主体差异和备注，算是简略版《版本差异清单》，再给版本号和存放位置命名规则起来，草台班子继续下去。
能不能解决问题需要天时、地利、人和，有没有能力解决是自己的事，借这个机会，希望各位产品同事们，多留心、多观察、多沉淀，希望大家在AI到来的时代，能找到适合自己的新天地。