先说个具体的
2021年9月我接手一个后台权限系统的改版，需求文档从 v1 做到 v11。最夸张的一周，周三评审完，周五下午四点运营那边发消息说“权限那块再想想”，周一早上又变成“还是按原来的来吧”。我统计过，11 版里有 6 版的改动都集中在同一个页面——角色权限配置页。返工工时加起来 47 个小时，这是从 Jira 里拉的，不是我嘴上拍的。
那时候我干过两件蠢事。一是当场答应，回工位在群里跟同事骂两句；二是硬顶回去，说“这个改不了”。前者让我在同一个坑里摔了六次，后者让运营那边觉得我不好合作，后面提需求直接绕过我找我们总监。两个都不行。
我后来想明白的一件事
需求反复变的根本原因，不是提需求的人想不清楚，是变的成本不落在做决定的人身上。你加班到十点改完，他第二天早上看到新版本，中间隔着的是你的工时，不是他的。
所以这件事的解法不是“说服他别改”，而是把这个成本挪到他眼皮底下。这跟技术能力关系不大，跟流程设计关系很大。我以前总觉得沟通是情商问题，后来发现大部分是信息不对称——他不知道动这一下要牵连多少东西，我也没告诉过他。
我当时做的第一件事，是拉了一张表，每行一次变更，列了六项：变更内容、提出人、影响的接口数、预计返工工时、原上线时间、变更后上线时间。
具体怎么做的，四步
第一步，这张表我先自己填了两周，没给任何人看。目的不是留证据，是搞清楚哪些变更是真变更、哪些只是我自己没理解到位。填完发现有一半的返工其实可以避免，里面有三四次是我把口头的一句话直接当成了最终需求。
第二步，给选项，不给结论。运营说“权限要能按部门继承”，我不再回“好”或者“这个做不了”，我回三个选项：A 先只做一级继承，3 个工作日；B 完整继承关系，8 个工作日，上线顺延到 10 月 29 号；C 这版先不做，下个迭代单独排。让他挑。
第三步，让他确认。不是真签字，是把选项写进会议纪要，邮件发一遍，请他回一句“按 B”。这一步我犹豫过，觉得太正式，像在甩锅。但事实是他要的是东西能做出来，我要的是知道做到哪算数，两边目标其实一致，只是以前没人把话说清楚。
第四步，设变更窗口。每周二、周四下午两点到四点集中处理变更，其他时间不改。这条最难执行，因为人是随时会想到点子的。我一开始也破过规矩，后来发现只要破一次，后面就全破了。
结果，还有几个没用的
大概两周后，变更频率从平均每周 4.2 次降到 1.3 次。上线时间从原定的 10 月 15 号推到 11 月 8 号，晚了 24 天，但这次是所有人一起点头的，没人再抱怨。
这套东西不是万能的。我遇到过一个真没法量化的需求，老板说“我要一个像抖音那样刷的”。这个怎么算工时？最后我 48 小时之内用 Figma 做了个能点的原型，让他上手划了五分钟，他自己说“不是这个感觉，我要的是推荐准”。原型比开会管用，因为有些东西用语言确实描述不出来。
另外也不建议照抄。我们当时有 Jira 和工时统计，数据能拉。五六个人的小团队没这些工具，用微信聊天记录手记也能算，关键是让“变更”这件事变得可见。做这张表我最大的收获不是流程变好了，是我终于知道自己的时间到底花在哪儿了。