业务判断：先弄懂工作，再解释方案

一个刚进入新岗位的人的成绩，可以是一项暂时没有上线的功能。

Healthie 对公司首位 FDE Shimon Mazor 的首月采访，记录了这样一件事。客户希望在预约前七十二小时发出提醒时，检查表单是否填完，并给未完成的客户加上标签。但系统在七十二、四十八和二十四小时提醒时，发出的事件相同，程序无法区分。他先把请求留在待办中。三周后，“自动化可应用已有标签”的能力有了供团队审查的代码修改请求，提醒触发的问题仍然没有解决。¹

这份记录没有一个干净利落的成功句号，却能帮助我们理解，承担客户问题究竟多出了什么。写一段接收事件的代码，与判断这段代码是否有足够信息完成承诺，是两种能力。前者可以单独练习；后者要求工程师把业务条件、系统行为和交付承诺放在一起检查。

如果只按完成了多少功能来描述这段经历，暂缓很容易显得像停滞。若按减少了多少未经验证的承诺来理解，它又有明确价值。当然，发现限制并不等于项目已经成功。客户的需要仍然存在，还需要有人说明临时怎样工作、后续改变依赖什么。职业成长发生在这段连续责任里，而不只发生在提交代码的一刻。

这个案例提出的职业问题是：当客户清楚地说出要一个功能时，工程师怎样发现其中仍有未经确认的条件？这与完整项目怎样调研和立项有关，但本章关注一个人的日常判断：问哪个问题，找谁确认，何时可以提出方案，何时应承认尚不知道。

领域理解，要能改变一个决定

新人容易把领域学习变成词汇学习。能解释几十个行业缩写，当然有助于交流；可如果这些词没有改变需求、数据或方案，它们还没有成为工作能力。

在预约练习里，“客户”就可能有不同含义：付款者、参加活动的人、负责报名的同事，未必是同一个人。如果系统只留一个姓名字段，看起来简洁，却可能无法确定谁有权取消。这里不需要先读完一本行业教科书，需要的是发现同一个词掩盖了不同职责，然后找真正做这项工作的人确认。

可以给自己的每次领域学习留下三项内容：原来以为什么，现在根据什么改变了理解，因此修改了哪个决定。比如，原以为取消总能释放名额；后来发现组织者允许保留席位转给同行者；因此把“收到取消文字”与“确认释放”分成两步。它仍然是教学假设，但推理过程可以被检查。

到了真实项目，确认的对象更重要。业务负责人可能熟悉目标，一线人员熟悉实际例外，系统管理员熟悉权限，几个人的回答可能分别正确。工程师需要弄清楚分歧来自不同情境，还是规则本身没有定下来。不能因为其中一人职位更高，就假定另一人的操作经验失去了价值。

学习也需要停止条件。新人不可能先成为客户行业的全面专家，再做第一项任务。可以先围绕一段已获授权的工作查清必要条件：哪些输入会影响它，哪些人使用它，哪里出错后损失较大，什么决定必须交还领域负责人。把尚未覆盖的部分明确排除，通常比泛泛宣称“已经了解这个行业”更可靠。

AI 可以帮助整理陌生材料、提出问题和解释程序，工程师仍应知道某个答案靠什么成立。一个能继续追问的习惯是：这个解释来自文档、代码运行，还是对方的工作经验？三者发生冲突时，应该做什么小检查来区分？工具缩短查找时间的同时，也可以把检查过程保存下来。能够找到支持理由，比记住一句流畅解释更容易迁移到下一个项目。

这里的“确认”也有层次。看过文档，只能说文档这样规定；听过一个人的操作经验，只能说此人在这个场景这样做；在测试环境看见一次行为，只能说这次输入和配置下结果如此。把三者摆在一起，有时才会发现规则与实现不一致。即使代码稳定地产生某种行为，也不等于业务认可这种行为。

从完整的一笔工作问起

第一次讨论需求，可以先请对方选一笔已经结束的工作，沿时间顺序还原：谁发起、谁接手、依据什么判断、在哪里等待、异常后来怎样处理。具体记录能把“经常”“自动”“完成”这些词拆开。看不到原始记录时，保留“受访者回忆”的身份，不把转述补成系统日志。

围绕这笔工作，最值得问的未必是“你希望界面有什么”。可以先问：如果这一步更快，下一步是否有能力接住？谁会因此减少工作，谁会多做检查？当前绕行办法为什么还在使用？一个看起来笨拙的表格，可能承担了正式系统没有记录的例外；直接删掉它，容易连同例外知识一起删掉。

问完后，用一段可以被纠正的话复述。例如：“我现在理解，你们想缩短候补者等消息的时间，但并不希望系统替组织者决定席位转让。若这两点成立，我们先整理待确认请求；是否发送邀请仍由指定人员决定。”这只是教学表达，不是预写给所有客户的标准答案。对方若纠正其中一项，记录被改正的假设，而不要急着维护已经想好的方案。

遇到相反的说法，也先还原对象。负责人说“取消就释放”，一线说“有时先替同行者保留”，可能是在讲普通取消与转让申请两个流程；也可能确实没有统一规则。前一种情况要分开场景，后一种情况要请有权者作决定。两种问题不能都交给模型根据语气猜测。

练习：这个需求现在应该做成什么

以下是一份合成的活动运营材料，与真实客户无关。它延续本篇的预约情境，但只训练业务判断，不要求写程序。原请求是“把取消后的补位全部自动化”。你获得了四条已核实的题面条件：

请交一页决策说明，包含当前目标、暂时允许的动作、暂不允许的动作、两个必须先得到答案的问题，以及会因此改变的方案。题面没有给出工作量、等待时长或通知效果，不能补写“节省一半时间”等结果。

先尝试自己判断，再看下面的检查方向。这里有多种可行选择，关键是前提必须成立。

当前可以研究普通取消后的草稿整理，但“全部自动化”的承诺尚不成立。席位转让的规则没定，候补意愿也不能由排名推断。应先分别请活动负责人确认转让期间的处理，请实际接手者确认可承担的确认工作。如果额外确认会把负担推给无人值守的岗位，技术上能够发送消息也不能解决这个缺口。

较弱的答案是列出一个万能表单，要求客户把所有字段填齐；它没有说明哪个答案会改变决定。较强的答案能指出：若转让申请期间必须保留席位，就不能按普通取消释放；若规则允许先释放，也需要负责人确认并告知适用情形。读者能从答案中看见方案随证据变化，而不是看见一个早已决定的自动化方案。

再加一个变化：假定负责人已明确所有转让申请由人工处理，普通取消可以自动产生草稿。你应修改刚才的决定，而不是仍把所有请求一律挡住。业务判断既要能指出限制，也要能在限制解除后推进；谨慎本身不是工作结果。

把方案说成对方能决定的选择

方案说明可以从工作变化开始：今天谁做什么，采用后谁还要做什么，哪种错误更容易被发现，出现异常由谁处理。技术负责人随后需要知道数据、接口和检查依据；业务负责人需要知道取舍；实际使用者需要知道具体操作。材料可以分层，事实必须一致。

例如，不宜把“生成邀请草稿”介绍为“自动补齐席位”。前者减少整理工作，后者意味着后续意愿确认、容量占用与有效期都已经妥善处理。名称提前越过了结果阶段，后续再补免责声明通常已经来不及纠正预期。

讨论收益时，也把成本说完整。程序少做了一次录入，但要求值班人员查看更多提示，净效果仍需观察。可以先记录现有步骤和使用者实际花费的工作，再比较变化；没有这种观察，就把收益写成待检验的假设。本章不要求新人一开始就完成经营分析，却要求他能分清已知结果与预期价值。

什么情况下应结束这轮学习

结束不等于“我已经懂这个行业”。更可用的判断是：这段工作的重要对象和例外已能解释；需要领域负责人决定的部分已交回；接下来允许建设和检查的范围已经清楚。剩下的问题仍可列出，但不必阻止范围内的小步工作。

如果陌生领域涉及你无权解释的专业判断，应请相应专业人员确认，不能用流畅的技术演示替代。若对方无法提供必要记录，可以先搭一个合成样本来验证理解，同时明确真实适用性尚未建立。这样的产物仍然有用：它把下一次沟通需要解决的分歧暴露出来。

业务判断的进步，可以从修改记录里看见：哪次提问改变了你原来的方案，哪项未经证实的承诺被缩回，哪项限制解除后又被推进。只记录自己最后给出的答案，会把最值得学习的部分藏起来。