为什么需求总是在开发中变形

做软件久了，你大概率听过这句话：“需求又变了。”

说这话的人通常有点无奈，有时还带点火气。开发觉得自己刚写完，产品又改；产品觉得自己只是补充细节，怎么就叫变更；测试觉得验收标准一天一个样；业务觉得我一开始就是这个意思。

最后大家都不太开心。

但我后来越来越觉得，很多需求不是在开发中才变形，而是在一开始就没有真正定型。

需求变形最常见的样子，不是产品突然推翻重来。

更多时候，它是一天改一点。今天补一个字段，明天加一个状态，后天发现现场还有一个特殊流程。每一次看起来都不大，累到一起，原来的设计就开始变形。

开发最痛苦的不是变化本身，而是不知道这个变化到底有没有边界。

如果边界不清楚，团队就会一边改一边猜，最后谁都说不清现在做的还是不是最初那个需求。

一、很多需求只是一个愿望

有些需求一开始看起来很明确。

比如：“做一个客户导入功能。”

这句话听起来不像很复杂。可真正开始做，就会冒出一堆问题：

导入模板谁维护？
手机号重复怎么算？
部分成功要不要允许？
错误行怎么提示？
导入后是否触发通知？
大客户数据量很大时怎么办？

如果这些问题一开始没有说清楚，开发就会按自己的经验补。产品也会按自己的理解补。业务验收时再按真实场景补。

于是需求就变形了。

不是大家故意折腾，而是最开始那句话只表达了一个愿望，没有变成可执行的需求。

二、需求变更里常常藏着理解偏差

我不太喜欢把所有变化都归成“产品反复”。

有些确实是临时改主意，但很多时候是理解偏差。

产品说“支持搜索”，开发理解成按名称搜索。业务验收时说，还要按手机号、客户编号、负责人搜索。

产品说“数据导出”，开发理解成导出当前列表。业务说，我们要导出全部符合条件的数据，还要带上统计字段。

产品说“审批通过后通知用户”，开发理解成站内消息。业务说，我们主要看企业微信。

这些都不是技术难点，但它们会吞时间。

因为每补一次理解，代码、接口、测试用例、文档和上线计划都要跟着动。

三、技术负责人要提前问难听的问题

需求评审会上，技术负责人不能只问“什么时候要”。

还要问一些听起来有点扫兴的问题。

比如：

这个功能的真实使用人是谁？
他一天会用几次？
数据量大概多少？
成功和失败怎么定义？
哪些情况可以先不支持？
这次上线后，谁负责验收？
如果时间不够，哪些东西可以砍？

这些问题有时会让会议变慢。

但它们能让后面的开发少走很多弯路。

一个需求如果在评审会上答不出来，不代表不能做，只是说明它还不够清楚。这个时候硬排期，后面大概率会靠返工补课。

四、不要怕承认“不确定”

很多团队的问题，是大家都不太愿意承认需求里有不确定。

产品怕显得自己没想清楚，开发怕显得自己挑刺，负责人怕影响排期。于是会议上大家点点头，任务进了排期，问题留到开发中爆。

我现在更倾向于把不确定性直接写出来。

比如：

当前不确定：
1. 导入失败是否允许部分成功。
2. 重复客户是否覆盖旧数据。
3. 企业微信通知是否本期必须支持。

写出来以后，事情就变简单了。

能确认的当场确认。不能确认的指定人和时间。影响排期的单独标记。

不确定不可怕，不承认不确定才麻烦。

五、变更不是不能有，但要有成本意识

软件项目里需求不可能完全不变。

业务在变化，用户在反馈，竞争对手也在动。完全冻结需求，很多时候并不现实。

但变化要有成本意识。

一个按钮文案改一下，成本很低。一个流程节点顺序调整，可能影响权限、通知、状态机和历史数据。一个字段从非必填变成必填，可能影响导入、接口、报表和老数据。

技术负责人要帮助团队把这些成本说清楚。

不是为了阻止变化，而是为了让变化被认真对待。

六、小结

需求总是在开发中变形，很多时候不是因为人不靠谱，而是因为需求一开始没有被场景、边界和验收标准托住。

技术负责人要做的，不是每次都抱怨“又变了”，而是尽量让变化提前出现。

把愿望变成场景，把场景变成边界，把边界变成验收标准。到了这一步，开发才真正有东西可做。

本系列：