前两天和朋友吃饭，她听说我是做业务需求分析的，第一反应是：“哦，就是那种天天写文档、画流程图、跟开发吵架的人吧？”我听完笑了半天，因为这句话虽然不太准确，但确实说中了不少业务需求分析师的日常，写文档、画流程、对齐开发，这些都是基本功，可如果只把自己当成“需求记录员”，那这份工作很快就做成了夹心饼干：业务嫌你不懂，开发嫌你烦,项目上线后用户还不买账。
我越来越觉得，业务需求分析师真正值钱的地方，不是把用户说的每一句话都写进需求文档，而是听懂那些话背后的“人话”——他到底想解决什么问题，他为什么着急,他嘴上说的方案是不是他真正需要的方案。
举个特别生活化的例子，我朋友阿琳开了一家烘焙店，去年想做个会员小程序，她一开始跟我说得特别明确：“我要积分商城、会员等级、优惠券，最好还能签到领积分。”如果我只是个需求记录员，听完就可以开始列功能清单了，但我多问了几句：你现在最头疼的是什么？她说每天晚上七点以后，柜台里还剩一堆面包和蛋糕，扔了心疼，不扔第二天口感又不好，她以为会员系统能帮她拉复购，可我跟着她看了两天店才发现，她真正的问题不是“客户不来”，而是“来的时间太集中，下午库存卖不掉”，后来我们把需求重点从“积分商城”改成了“附近小区定向折扣提醒+临期库存推荐”，会员积分只保留一个轻量版本，上线一个月，她晚上浪费的库存少了不少,复购也有一点提升。
这件事对我触动很大，用户说“我要积分”，很多时候只是因为他见过别人这么做，或者他觉得“会员系统就该有积分”，但业务需求分析师要做的，是往后退一步，问一句：“你要积分，是为了解决什么问题？”这句话听起来简单，做起来特别难，因为你要忍住“赶紧写需求”的冲动,还要有耐心跟业务方一起把模糊的痛感拆成具体场景。
再比如家庭装修，我爸妈装修房子时，反复强调“柜子要多打一点”，如果按表面需求执行，那就是满墙柜子，但我妈真正烦的是什么？是换季找被子要翻半天，是厨房小家电没地方放，是进门鞋子堆一地，最后我们没盲目加柜子，而是把收纳按“动线”和“使用频率”重新分了区：玄关做常用鞋位，厨房留小家电抽拉层，卧室把换季被褥放到高处，柜子数量没多太多，但她说“顺手多了”，这其实和做业务需求分析一模一样：表面需求是“多打柜子”，真实需求是“少一点乱、快一点找到东西”，业务需求分析师如果只接表面需求，最后交付的往往是一堆功能,而不是一个真正好用的方案。
我个人一直认为，业务需求分析师不是“传话筒”，更不是“文档生产机”，这个岗位最核心的能力有三层：第一层是听懂业务语言，知道对方在什么场景下遇到了什么阻碍；第二层是翻译成产品和开发能理解的语言，包括流程、规则、边界和验收标准；第三层是敢于做取舍，帮业务区分“想要”和“需要”，帮项目识别“现在必须做”和“以后再说”，没有第三层，需求文档写得再漂亮,也很容易变成一本谁都不愿意看的流水账。
还有一个很现实的体会：业务需求分析师一定要有“质疑”的勇气，但质疑的方式要柔软，比如业务方说“这个功能明天就得上”，你别急着怼回去，可以先问：“如果明天不上，最坏的影响是什么？是客户投诉，还是内部效率低？有没有一个更小的版本先顶住？”很多时候，对方不是不讲理，而是被时间追着跑，没空想优先级，业务需求分析师的价值,就是帮他把焦虑拆成可执行的选项。
这份工作也有委屈的时候，业务觉得你问太多，开发觉得你没写清楚，项目经理觉得你进度慢，可越是这样，越要记住：你不是在讨好所有人，你是在帮大家少走弯路，一个需求在文档阶段多问五个“为什么”，可能比上线后返工五轮更划算，业务需求分析师要有点“翻译官”的耐心，也要有点“守门员”的坚持：伪需求要敢拦，模糊需求要敢追问,关键规则要敢写死。
如果你问我业务需求分析师到底在做什么，我会说：他在人和系统之间搭桥，在“我想要”和“真正需要”之间做翻译，在业务目标和落地成本之间找平衡，写文档只是结果，听懂人话才是起点，下次再有人把业务需求分析师理解成“写文档的”，我可能会笑着补一句：对，但我们写的不是文档，是一群人没说出来、又真正想解决的问题。