做软件久了，你大概率听过这句话：“需求又变了。”说这话的人通常有点无奈，有时还带点火气。开发觉得自己刚写完，产品又改；产品觉得自己只是补充细节，怎么就叫变更；测试觉得验收标准一天一个样；业务觉得我一开始就是这个意思。最后大家都不太开心。但我后来越来越觉得，很多需求不是在开发中才变形，而是在一开始就没有真正定型。需求变形最常见的样子，不是产品突然推翻重来。更多时候，它是一天改一点。今天补一个字段，明天加一个状态，后天发现现场还有一个特殊流程。每一次看起来都不大，累到一起，原来的设计就开始变形。开发最痛苦的不是变化本身，而是不知道这个变化到底有没有边界。如果边界不清楚，团队就会一边改一边猜，最后谁都说不清现在做的还是不是最初那个需求。一、很多需求只是一个愿望有些需求一开始看起来很明确。比如：“做一个客户导入功能。”这句话听起来不像很复杂。可真正开始做，就会冒出一堆问题：导入模板谁维护？手机号重复怎么算？部分成功要不要允许？错误行怎么提示？导入后是否触发通知？大客户数据量很大时怎么办？如果这些问题一开始没有说清楚，开发就会按自己的经验补。产品也会按自己的理解补。业务验收时再按真实场景补。于是需求就变形了。不是大家故意折腾，而是最开始那句话只表达了一个愿望，没有变成可执行的需求。二、需求变更里常常藏着理解偏差我不太喜欢把所有变化都归成“产品反复”。有些确实是临时改主意，但很多时候是理解偏差。产品说“支持搜索”，开发理解成按名称搜索。业务验收时说，还要按手机号、客户编号、负责人搜索。产品说“数据导出”，开发理解成导出当前列表。业务说，我们要导出全部符合条件的数据，还要带上统计字段。产品说“审批通过后通知用户”，开发理解成站内消息。业务说，我们主要看企业微信。这些都不是技术难点，但它们会吞时间。因为每补一次理解，代码、接口、测试用例、文档和上线计划都要跟着动。三、技术负责人要提前问难听的问题需求评审会上，技术负责人不能只问“什么时候要”。还要问一些听起来有点扫兴的问题。比如：这个功能的真实使用人是谁？他一天会用几次？数据量大概多少？成功和失败怎么定义？哪些情况可以先不支持？这次上线后，谁负责验收？如果时间不够，哪些东西可以砍？这些问题有时会让会议变慢。但它们能让后面的开发少走很多弯路。一个需求如果在评审会上答不出来，不代表不能做，只是说明它还不够清楚。这个时候硬排期，后面大概率会靠返工补课。四、不要怕承认“不确定”很多团队的问题，是大家都不太愿意承认需求里有不确定。产品怕显得自己没想清楚，开发怕显得自己挑刺，负责人怕影响排期。于是会议上大家点点头，任务进了排期，问题留到开发中爆。我现在更倾向于把不确定性直接写出来。比如：当前不确定： 1. 导入失败是否允许部分成功。 2. 重复客户是否覆盖旧数据。 3. 企业微信通知是否本期必须支持。写出来以后，事情就变简单了。能确认的当场确认。不能确认的指定人和时间。影响排期的单独标记。不确定不可怕，不承认不确定才麻烦。五、变更不是不能有，但要有成本意识软件项目里需求不可能完全不变。业务在变化，用户在反馈，竞争对手也在动。完全冻结需求，很多时候并不现实。但变化要有成本意识。一个按钮文案改一下，成本很低。一个流程节点顺序调整，可能影响权限、通知、状态机和历史数据。一个字段从非必填变成必填，可能影响导入、接口、报表和老数据。技术负责人要帮助团队把这些成本说清楚。不是为了阻止变化，而是为了让变化被认真对待。六、小结需求总是在开发中变形，很多时候不是因为人不靠谱，而是因为需求一开始没有被场景、边界和验收标准托住。技术负责人要做的，不是每次都抱怨“又变了”，而是尽量让变化提前出现。把愿望变成场景，把场景变成边界，把边界变成验收标准。到了这一步，开发才真正有东西可做。本系列：上一篇：技术负责人到底负责什么下一篇：任务拆分不是把大需求切成小需求系列目录：一个技术负责人眼里的软件团队