从代码现实而非观点构建路线图

Source: Dev.to

大多数产品路线图都是在会议室里用便利贴和强烈的主观看法搭建的。声音最大的人往往赢得决定，所以路线图往往反映的是政治动态，而不是工程现实。

随后现实会敲门。原本计划的“2 周功能”因为没人检查代码库的复杂度而拖了两个月。“快速集成”需要重写数据层。“简单的 UI 改动”却触及了 14 个其他页面共用的组件。

数据驱动的替代方案

如果你的路线图是基于实际代码库数据来制定的，会怎样？

从代码中获取特性清单

与其问“我们有什么特性？”并从产品、工程、销售得到不同的答案，不如通过代码分析自动提取特性。对依赖图进行 Louvain 聚类即可生成明确的特性列表，包含：

• 清晰的边界
• 复杂度度量
• 所有权数据

竞争差距评分

对于竞争对手拥有而你没有的每个特性，根据你实际的代码库对实现复杂度进行评分：

• 需要改动哪些地方？
• 受影响的文件有多少？
• 哪些团队会参与？
• 依赖关系是什么？

在规划会议上听起来很简单的特性（“只要加个 SSO”）可能会因需要在认证、用户管理、计费和管理员四个不同的特性集群中进行改动而被评为高度复杂——涉及三个不同团队的所有者。

团队能力映射

谁真正能构建什么？Git 历史可以揭示专业能力：

• Sarah 对支付系统有深入了解。
• Mike 熟悉实时特性。
• 已经八个月没有人触碰过遗留的报表模块。

把路线图任务分配给错误的团队会导致工期延长三倍。具备能力感知的规划可以避免这种情况。

基于复杂度的工作量估算

与其使用故事点（主观看法），不如依据结构复杂度来估算工作量：

• 受影响的文件数量
• 跨特性依赖关系
• 测试覆盖率缺口
• 这些区域的历史变更速度

能经得起代码检验的路线图

数据驱动的路线图包括：

• 要构建什么 – 基于竞争差距和用户需求
• 实际有多难 – 基于代码库复杂度分析
• 谁来构建 – 基于团队专业能力映射
• 它依赖什么 – 基于特性依赖图
• 可能出现什么问题 – 基于历史回归模式

这并不是用数据取代产品直觉，而是让产品直觉在承诺之前接受一次现实检验。

最初发布于 glue.tools。Glue 是预代码情报平台——粘贴工单，即可获得作战计划。