先别急着写SRS，先做业务价值对齐

去年秋天，我在一家做企业级SaaS的公司参加他们的Sprint Review。会上，研发团队演示了花了三个迭代才做完的报表模块，功能完备、交互流畅。但我注意到坐在角落的业务负责人从头到尾一言不发。会后我问他怎么看，他打开手机给我看了一条客户投诉：“你们的报表看起来什么都有，但我想知道的核心指标一个都找不到。”

这个场景我见过太多次了，只是主角在换：有时是花两个月做的审批流程，业务说他们其实只需要一个简单的状态标记；有时是精心设计的权限体系，客户反馈说“我们团队就五个人，你们让我配置几十个角色”；有时是一个被写得事无巨细的SRS文档，交付后却被称为“昂贵的废纸”。这些问题的共同根源，不是需求写得不够详细，而是双方在坐下来写需求之前，从来没有人问过一个根本问题：我们到底要创造什么价值，以及怎么判断价值真的发生了。

SRS（软件需求规格说明书）是一个很好用的工具，但它本身无法解决“对齐”的问题。它更像一张支票，你填写的数字再工整，如果账户里本来就没有钱，支票就是废纸。而账户里的“钱”，就是业务价值共识。这篇文章，我想把我过去几年在一线接触到的痛苦、教训和补救方法，系统地讲出来。

一、先把结论放在这里

我后面会展开讲很多细节，但先把核心主张亮出来：

第一，SRS不是需求对齐的起点，而是对齐之后的“结项文件”。如果你在写SRS的时候还在争论“用户到底需要什么”，说明你们还没到该写SRS的阶段。

第二，“对齐业务”的本质不是对齐功能清单，而是对齐价值定义。具体来说，是四个方面：什么是成功、在多大时间范围内、用什么数字衡量、谁有权宣布它成功。

第三，不做业务价值对齐的SRS，写得越详细，沉没成本越高。因为你做的不是在盖房子，而是在把不确定性浇筑得更坚固。

第四，价值对齐不是开会。它是一套可以被验证、被记录、被追溯的协作流程。我在PingCode服务中大型研发团队的过程中观察到一个清晰的规律：那些能够在一个迭代周期内交付有效功能的团队，和那些反复返工的团队，差别往往不在开发能力，而在进入开发之前他们是否完成了“价值定义”这一步。

二、那个让我彻底改变工作方式的真实案例

2022年，我协助一家约有400人规模的金融科技公司做研发流程优化。他们有一个情况：产品团队和研发团队之间总是互相抱怨。产品抱怨研发“理解力差”，研发抱怨产品“需求变来变去”。他们已经引入了标准的Scrum流程，有站会、有Review、有Retro，但情况并没有好转。

我花了三天时间，旁听了他们三个业务线的需求评审会。发现有一个非常典型的需求：运营部门提了一个“客户标签体系”的需求，SRS写了三十多页，详细描述了标签的分类逻辑、创建规则、更新频率、权限控制等等。单看文档，逻辑严丝合缝。

但当我私下问运营负责人：“这个标签体系上线后，你打算用来解决什么业务问题？”他愣了五秒钟，说：“嗯……提升精准营销的转化率吧。”我问：“现在转化率是多少？你觉得提到多少算成功？”他摇头说没有具体数字。我又问研发负责人：“你知道这个功能上线后，从哪个指标上能看出来它是不是真的有用？”他坦白说：“需求评审时没人提这个，我们只确认了技术方案可行。”

这件事给了我很大的冲击。一个花了大量精力写就的SRS，在“为什么做”这个维度上是彻底空白的。SRS解决了“怎么做”和“要做什么”，但它天然不负责验证“做了有没有用”。而恰恰是这个未被验证的部分，决定了交付物是资产还是库存。

后来我们做了一个调整：任何进入SRS阶段的需求，必须前置一份价值对齐文档。这个文档很小，但卡住了所有后续流程。三个月后，他们的需求返工率下降了超过一半。不是SRS写得更好了，而是不值得写SRS的需求被提前识别出来了。

三、我们为什么总是跳过价值对齐这一步

既然价值对齐这么重要，为什么那么多团队，包括很多经验丰富的大厂团队，还是会跳过它？我不认为这是因为懒或者不专业。根据我的观察，有几个深层原因在起作用。

1. “写文档就是干活”的幻觉

在很多组织中，SRS本身就是“交付物”。一个人写了二十页SRS，看起来就在做很重要的工作。相比之下，花两天去和业务方反复确认“成功标准是什么”，反而容易被当作“还没开始干活”。体力的可见性远高于思考的不可见性，这是组织行为学上的经典陷阱。

我见过最夸张的一个例子是，某团队的SRS里面详细描述了用户界面上的每一个按钮的颜色和位置，但通篇没有出现过一个可量化的业务指标。评审会上大家讨论了很久“这个弹窗应该在什么时候出现”，却没有一个人问过：“用户完成这个操作的实际比例是多少？”

2. 业务价值在很多场景下确实不容易定义

平心而论，我不认为所有需求都能轻松量化出业务价值。有些需求是基础设施、技术债偿还、合规要求、安全加固，它们不像一条营销活动那样能直接关联收入增长。但这恰恰是很多团队选择放弃定义价值的借口。

实际上，即使是非功能性需求，也可以定义出它的价值形式。我们只是需要换一种表述方式。后面的章节我会专门讲这个。

3. 价值对齐比写SRS更需要“不舒服的对话”

写SRS是坐在电脑前就可以完成的事情。但做价值对齐，你需要去找业务方刨根问底。你需要说：“我理解你提的需求，但我还需要你告诉我，这个做完了，你打算怎么衡量我们做对了。”这种对话有时候会让业务方不舒服，因为它暴露了需求背后可能并不清晰的思考。

很多产品经理和研发经理下意识回避这种对话，不是因为不认可它的价值，而是因为它需要一种不同于写文档的勇气和沟通技巧。而组织通常也不考核你“让业务方不舒服了几次”，只考核你“文档有没有按时交付”。

四、价值对齐到底要对齐什么，四个必须明确的维度

说完了“为什么不做”，接下来我要讲清楚“做的话到底做什么”。

我在实践中总结了一个框架，一个需求进入SRS之前，必须在四个维度上和业务方达成明确共识。缺一个，我建议不要开始写SRS。

1. 成功定义，不是功能做完了，而是某个问题被解决了

这是最核心的一条。我要求团队把“成功”从“系统上线了XX功能”改为“XX业务问题被解决到以下程度”。这两个表述不是文字游戏，它们的区别会直接改变整个研发链条上的决策。

举一个例子：某电商企业的运营团队提了一个“售后工单自动分类”的需求。如果定义成功为“工单自动分类功能上线，准确率达到90%”，那么研发的注意力会放在算法模型上。但如果定义成功为“客服手动分单的工作时间从日均3小时降低到1小时以内”，研发的注意力就可能会扩展：也许不需要90%的准确率就能达成这个目标？也许不是靠更复杂的算法，而是靠改善工单录入流程就能解决？把成功定义在业务指标上，能明显扩大解题空间。

2. 时间窗口，价值必须在多长时间内被验证

我经常听到产品经理说“这个功能长期来看是有价值的”。问题在于，“长期”有多长？三个月还是两年？如果一个基础设施项目的价值需要18个月才能显现，而你的公司账上现金只够支撑9个月，那么这个项目在当前阶段的优先级就应该被压低。

时间窗口的定义不需要精确到天，但需要一个区间。我通常建议团队和业务方约定一个“价值验证期”：对于增长类功能，4到6周；对于提效类功能，8到12周；对于平台基础设施类功能，可能需要一个季度到半年。这个约定的作用，是防止那种“我们永远不知道它有没有价值，所以我们不能说它没价值”的持续性低效投入。

3. 量化指标，统一衡量尺度

这是最容易被“完成”但也最容易“做假”的环节。很多团队会在需求文档里放几个指标，比如“客户满意度”、“运营效率”、“转化率”。但这不够。量化指标必须满足两个条件：可归因和可收集。

可归因意味着你能够合理判断指标的变化和你的功能交付之间存在因果关系，而不仅仅是时间上的相关。可收集意味着你上线之前就已经有了数据采集的方案，而不是上线之后才想起来要埋点。

我在PingCode服务过的团队中，做得比较好的一类做法是：在迭代规划会议上，不只是把用户故事拆成任务，而是在此之前，先明确每一个用户故事对应的“价值验证指标”和“数据采集方式”。这些内容不会被写进SRS的技术规格里，但它会贴在任务墙的顶部，整个迭代过程可见。这使得开发人员在写代码的时候，知道自己写的这段逻辑会被哪个指标检验。

4. 决策权归属，谁有权宣布“价值已实现”

这是一个经常被忽略的维度。很多需求上线后陷入无限期的“观察中”，因为没人能最终拍板说“这个功能算成功了”或者“这个方向我们认栽，不继续投了”。

我建议的做法是：一个需求进入开发之前，必须指定一个“价值验收人”。这个人通常是提需求的业务方负责人，或者业务方和产品负责人共同组成。他或他们必须在迭代Review的时候，基于之前约定好的指标和时间窗口，给出明确的判断：达标、未达标但继续优化、或终止。

没有这个环节，价值对齐就只是写在了纸上，没有落实到责任上。

五、手把手做一个价值对齐，一个完整示例

理论讲完了，我拿一个具体的需求来完整走一遍这个过程。这个示例来自我经历过的真实项目，只是把业务信息做了抽象化处理。

原始业务需求：销售团队提出要做一个“客户健康度评分”功能，希望通过系统自动给客户打分，帮助销售识别出有流失风险的客户。

如果直接进入SRS阶段，文档可能会从数据源接入写到评分模型设计，再写到前端展示界面。但我们在评审时卡住了，先做了价值对齐。

第一步：追问成功定义。

产品经理问销售总监：“系统做出健康度评分之后，你希望发生什么不一样的事情？”销售总监最初回答：“销售能看到低分客户，然后去跟进。”产品经理继续追问：“现在销售也在跟进客户，区别是什么？”经过几轮对话，真正的业务目标浮出水面：销售团队近期发现，客户在合同到期前三个月的续约率在下降，希望提前识别风险客户，在客户表达退订意愿之前介入。

于是成功定义从“系统输出客户健康度评分”修正为：“在客户合同到期前三个月，将续约风险客户的识别率从当前的40%（销售主观判断）提升到70%以上。”

第二步：约定时间窗口。

续约是周期性发生的业务，每个季度都有一批客户合同到期。双方约定，功能上线后运行一个完整季度，以该季度的续约率数据和风险识别准确率作为验收数据。

第三步：确定量化指标。

最后确定的指标不是“健康度评分准确率”（这个太技术视角），而是三个业务指标：

• 高风险客户的提前识别率（目标：70%以上）
• 高风险客户的续约率变化（目标：环比提升15%）
• 销售对风险预警的响应率（目标：80%以上的预警在48小时内被处理）

同时确认了数据采集方式：CRM系统中已有合同到期时间和续约状态字段，销售跟进记录也已有日志，不需要额外从零搭建数据基础设施。

第四步：确定决策权归属。

销售总监被指定为价值验收人。季度结束后，由他根据上述三个指标的实际数据给出Go/No-Go判断。

结果：因为有这四个前置约定，后续SRS的范围被大幅度压缩，团队发现不需要一开始就做复杂的机器学习模型，先把CRM里已有的数据（最近登入频率、工单提交频率、合同到期时间）做加权组合，配合销售手动标注，就已经能覆盖70%以上的风险识别需求。实际开发周期从预估的六个迭代缩小到三个迭代，首版上线后客户续约风险识别率从40%提到了68%。

六、特殊情况怎么处理，当价值量化真的很难

我承认不是所有需求都像上面的例子那样容易量化。接下来谈谈几种常见的情况和我的处理方式。

1. 基础设施类需求

比如数据库拆分、服务化改造、中间件升级这类需求。你很难直接说“这个技术改造提升了多少营收”。我处理这类需求的原则是：不看收入看损失，不看增长看风险。

和业务方的对话可以是这样的：“如果现在不做这个数据库拆分，未来六个月内最坏的场景是什么？宕机时间可能达到多少？影响到多大比例的客户？每次宕机的业务损失大致在什么量级？”即使得不到精确数字，这个过程也让“技术投入”不再被视为单纯的“成本”，而是被量化为“风险对冲”。

2. 合规和安全类需求

这类需求的价值更容易被挑战，因为它在很多时候看起来纯粹是“花钱消灾”。我的建议是：把“不合规的代价”作为价值的反面进行对齐。

比如某金融客户需要做数据脱敏，看起来是纯粹的成本。但通过和法律合规团队的对话，明确了如果不做脱敏，监管罚款的区间、业务暂停的概率、以及品牌声誉受损后客户流失的估算范围。把这个“风险定价”前置确认，整个组织就能理解这笔投入实际上在买什么。

3. 探索创新型需求

这是最难量化的一类。一个全新的功能，没有历史数据可以参照，也无法准确预测用户的接受度。这种情况下，我不建议做出虚假的精确量化。应该诚实地说“这是探索”，然后用“学习价值”代替“业务价值”来设定成功标准。

具体做法：明确“我们做这个探索，希望在四周内学到什么”。学习目标是可以被验证的：“用户是否有付费意愿”、“用户在这个场景下的核心操作路径是什么”、“转化漏斗中最大的断点在哪里”。即使这个功能最后被证明跑不通，只要它产出了这些学习，投入就不是毫无价值。

七、工具和流程怎么配合，一个轻量级落地方法

回到操作的层面。价值对齐这个理念听起来有道理，但如果落实成一个需要填十页的表格，它就会变成另一个被大家消极对待的流程。我设计了一个非常轻量的方法，在很多团队验证过。

1. “机会一页纸”卡片

在需求进入产品待办列表之前，产品经理和业务方一起完成一张极简卡片。这张卡片只有五个字段，我建议手写而不是用模板软件，手写的仪式感会引导双方更认真地确认内容：

• 业务问题：用一句话描述（不是用功能描述，而是用业务现状描述）
• 如果解决了：谁会受益，受益到什么程度（尽量量化）
• 如果没解决：三个月后最坏的后果是什么
• 验收指标：最多三个，每个指标必须有数据来源
• 价值验收人：写具体人名，不写部门

这张卡片不是SRS的替代品，而是SRS的“入场券”。卡片没有完成对齐评审，需求不允许进入迭代规划。

2. 价值对齐评审会

很多团队在做需求评审的时候，90%的时间花在技术方案和交互细节上，价值层面的讨论要么没有，要么蜻蜓点水。我的建议是：把价值评审从需求评审中分离出来，作为一个独立的前置环节。

这个会不讨论技术方案，只讨论三个问题：我们确认在解决正确的问题吗？我们对成功的定义一致吗？我们有没有把握在约定的时间窗口内验证它？

我在PingCode接触的一些中大型企业研发团队中，看到有PMO部门已经把这种价值评审作为立项的强制卡点，这比单纯依赖团队自觉要有效得多。

3. 在迭代中持续可见

价值对齐一旦确认，不能在迭代启动后就被遗忘。我推荐的做法是：把“机会一页纸”贴在物理看板或电子看板的顶部，每个迭代的站会上，最后一个问题不只是“有什么阻塞”，还要问一句：“我们的交付仍然指向约定的价值指标吗？”

这个环节很有用，因为它能及时发现一种常见的情况：开发过程中发现技术难度比预期大，团队开始悄悄缩减功能范围，但缩减之后的功能是否还够得着原来的价值目标，没有人重新评估。把价值指标放在每日可见的位置，大大减少了这种“无意识价值偏离”。

八、一个重要提醒：价值对齐也是团队能力的晴雨表

我在做咨询的过程中发现，价值对齐这件事，与其说是一种流程规范，不如说它是团队产品成熟度的一面镜子。

一个能够自然做好价值对齐的团队，通常具备以下特征：产品经理和业务方之间有足够的信任基础，业务方愿意花时间参与前置讨论；研发团队有业务理解意愿，不把“我只负责实现”当作护身符；组织文化允许在需求评审中说“我还没想清楚”，而不是用一页又一页的文档来掩盖不确定性。

相反，如果发现推动价值对齐非常困难，阻力往往不在流程层面。可能是业务方和产品团队之间已经有信任裂痕，业务方认为“说了也没用”。可能是研发团队长期处于被压榨状态，已经形成了“你让我做什么我就做什么，别让我思考”的保护机制。也可能更根本上，组织的绩效体系鼓励“交付速度”而惩罚“前置思考”。

这种情况下，强行推行价值对齐流程不会有效，需要先处理更深层的团队和组织问题。我建议从一个小范围试点开始，选一个配合度高、业务清晰的需求，认认真真做一次完整的价值对齐，然后用实际效果（缩短的周期、减少的返工、提升的满意度）来说服更多人。

九、放下SRS模板，先去问对问题

文章写到这里，我想再回到标题：先别急着写SRS，先做业务价值对齐。这不是反对SRS，SRS在一个成熟的软件工程流程中有它不可替代的位置。我反对的是在没有价值共识的情况下，用一份详细的技术文档来伪装成协作已经完成。

如果你是一个产品经理，我的建议是：下次收到业务需求时，先不要打开SRS模板。先去找业务方，问五个问题：

1. 我们当前遇到的最痛的业务问题是什么？
2. 如果没有技术系统介入，我们打算怎么解决？
3. 如果这个问题被完美解决，什么迹象会让你觉得“钱花值了”？
4. 我们打算在多长时间内看到这个迹象？
5. 你愿意作为最终确认它是否成功的人吗？

这五个问题问完，你会发现有的需求变得清晰了，有的需求会自动降低优先级，有的需求甚至不需要做了。一个好的问题，比十页文档更接近需求的真相。

如果你是一个研发负责人，在面对一份厚厚的SRS时可以尝试问一句：“在开始编码之前，我们有没有和业务方确认过，这个功能做完之后，从哪个数字上能看出来它有用？”这个问题可能会让你一时不受欢迎，但它保护的不只是你的研发资源，更是整个团队避免在错误的方向上高效奔跑。

回到我在开头讲的Sprint Review的故事。那次会议后，我帮他们团队做了一个调整：不是改进SRS模板，而是新增了一个SRS之前的环节。他们没有给它起很花哨的名字，就叫“价值前置对话”。三个月后我问那个业务负责人情况怎么样，他说了一句话我记到现在：“以前你们问我需求细节，现在你们问我我这块业务到底怎么做。我感觉被当人了。”

SRS写的是功能，但价值对齐写的是尊重。后者才是好产品的起点。