业务分析师
业务分析师负责弄清一套软件究竟必须做到什么，并把它表述得足够精确，从而可以被构建、也可以被验证。这门学科位于懂业务的人与懂系统的人之间，它的价值以「没有发生的缺陷」来衡量——被避免的返工，以及在代价还很低时就被抓住的误解。本指南说明这个角色、哪些情形会真正产生对它的需求，以及如何把分析与写文档区分开。
业务分析师在软件项目里做什么？
业务分析师调查一个业务问题，并定义一套系统必须做到什么才能解决它。在软件项目上，这意味着从干系人和用户那里获取需要、梳理现有流程以及它在哪里失效、识别当前行为与期望行为之间的差距，并把结果表述为工程师可以据以构建、测试人员可以据以验证的需求、业务规则、数据定义与验收标准。这份责任是让团队构建正确的东西——区别于让团队按时构建出来。
这份工作后果最重的部分，是干系人所要求的东西与他们真正需要的东西之间的距离。干系人描述的是解决方案，因为解决方案比问题更容易讲清楚：一个「加个导出按钮」的请求，通常是一个「把两个系统对上账」的请求，而把按钮做出来并没有解决对账。一位照单全收的业务分析师，产出的是一份准确却不切题的规格说明。
这份工作的另一半是精确。需求的失败源于含糊多过源于遗漏——「快速」「相关」「合适」「用户」这类词，对每个读到它们的人含义都不同，而每一种解读会在开发、测试和上线之后被分别发现。在含糊变成代码之前把它暴露出来，是这门学科主要的经济贡献。
大量实质内容存在于规则、数据与边界情况里，而不是在界面上。什么样的账户符合条件、在什么条件下哪些字段是必填、一次退款如何与一次部分发货相互作用、日期区间的边界上会发生什么、当两个系统给出不同答案时以哪一个为准。组织通常把这些知识分散在若干人身上，没有谁掌握全部，而且往往从来没有人写下过：当流程不走寻常路径时会发生什么。
这个角色也带着与它关联最紧的失效模式。业务分析师可以产出大量没有人读的文档，满足了流程，却没有提供任何清晰度。真正算数的产出是一份共享的、当前有效的、可被检验的共识：正在构建的是什么。如果一份文档没有被用来做决定，它的篇幅是成本，而不是工作量的证明。
团队何时需要这项能力
每个项目都会发生分析，无论有没有人被指派去做。问题在于它是被有意识地完成，还是在开发过程中被发现。以下是有意识地去做通常划算的几种情形。
这个领域有没人写下来的规则
信贷、保险、物流、薪资、医疗、税务、受监管的定价——在这些领域里，正确的行为取决于只存在于资深员工头脑中、以及一个老系统行为里的条件。工程师无法推断出这些，而让他们去推断，正是规则被近似实现的方式。
工单反复被打回
工作按规格构建、被验收，然后又被重新打开，因为它做的不是某个人所期待的事。这几乎总是需求缺陷而不是工程缺陷，而它之所以重复发生，是因为原因位于正在被排查的位置的上游。
这套软件要替换一个既有流程
一次迁移、一次系统替换或一次人工作业的自动化，都需要有人先确立当前流程实际上做了什么——包括那些非正式的步骤和人们不假思索就处理掉的例外——然后再决定新系统应该做什么。复制一个没有人检视过的流程，正是变通做法变成永久特性的方式。
干系人之间存在分歧，而没有人把它摆出来
几个部门各自对某件事应该如何运作有一套自洽的看法，而这些看法互不兼容。分歧通常在验收测试期间才被发现，那时解决它的代价最高。把它提前显性化是分析工作，不是外交工作。
工程师把时间花在澄清上
开发人员反复停下手上的工作去确认某条需求是什么意思、去找那个知道的人、然后等待。团队看起来很忙，交付却很慢，原因是界定工作被以尽可能低效的方式分摊给了所有人。
一次集成必须调和同一事物的两种模型
两个系统都存着客户、或者订单、或者账户，而它们指的东西存在微妙差别。把字段映射起来并不难；确立以哪个系统为准、身份如何匹配、冲突时会发生什么，才是分析，而跳过它会产生在上线很久之后才浮现的数据问题。
核心能力
需求获取
把人们需要的东西引导出来，而不是记录他们说出来的东西。这意味着在访谈中不做诱导、在工作坊里让安静的专家开口、观察工作实际是怎么被执行的，并注意到某个人因为太熟悉而略过的那些步骤。
问题的界定
把请求与其背后的需要分开，并以结果而不是机制来陈述问题。一条写成解决方案的需求，会堵死工程团队本可能提出的更好方案，而这正是规格说明中最常见的缺陷。
流程分析
记录工作今天如何流转、在哪里停滞、在哪里返工，以及人们在哪里搭建了非正式的变通做法。例外比主路径更重要，因为如果没有人把例外说出来，新系统正是会在这些地方处理得很差。
需求定义
把需要表述成两个人读完会得出同一个结论。可检验、无歧义、不夹带隐含的解决方案，并且能追溯回支撑它的业务结果——同时把那些确实可选的部分标注出来。
验收标准
事先定义什么可以证明这条需求已经被满足，包括边界条件和那些并不顺利的路径。在实现之后才写的标准，描述的是已经建成的东西而不是所需要的东西，那是另一件用处小得多的产出物。
业务规则与数据定义
捕捉支配行为的条件逻辑、资格规则、计算与有效性约束，连同它们所作用的数据的含义、来源、归属与生命周期。决策表通常会暴露出散文所掩盖的缺口。
差距分析
把当前状态与期望状态对照，精确指出必须改变什么——在系统里，往往也在围绕它的流程与职责里。软件很少能独自交付一个业务结果，而一份止步于系统边界的分析，往往会错过结果为什么没有到来。
可追溯性
维护从业务目标到需求、到实现、到测试的链路，使一次变更的影响可以被评估，也使没有依据支撑的工作变得可见。正因如此，缩减范围才成为一个经过考虑的决定，而不是一次猜测。
在不同受众之间转译
用能支撑设计决定的方式向工程师解释一条业务约束，用「这对他们意味着什么」的方式向干系人解释一条技术约束。两个方向都是必需的；只擅长一个方向的分析师，产出的规格说明总有一方会悄悄忽略。
这门学科是如何运作的
业务分析由方法而不是技术栈定义，因此以下列出的是在通常的业界实践中刻画这门学科的技术、记法与交付物——它描述的是这个职业，而不是关于任何个人工具箱的说明。工具本身在很大程度上可以互换：一种建模记法可以在不同的绘图产品之间迁移，一套需求实践也能挺过跟踪系统的更换，因此判断一位候选人，看他如何获取与表述需求，远好过看他上一次用的是哪个软件。
需求获取技术
- 结构化干系人访谈
- 引导式需求工作坊
- 观察与跟岗
- 文档与系统分析
- 问卷与调查
- 用于激发反馈的原型
流程与系统建模
- BPMN 流程模型
- 泳道图与价值流图
- 上下文图与范围图
- 用例图与活动图
- 状态转换图
规格产出物
- 用户故事
- given/when/then 形式的验收标准
- 用例描述
- 业务规则目录
- 非功能性需求
- 持续维护的领域术语表
数据与规则分析
- 概念数据模型与逻辑数据模型
- 实体关系图
- 数据字典
- 决策表与决策树
- 增删改查权限矩阵
- 数据画像与质量评估
分析与优先级方法
- 差距分析
- 根因分析
- 影响地图与故事地图
- 干系人梳理
- MoSCoW 及其他优先级框架
- 需求追溯矩阵
常见的工具类别
- 绘图与建模软件
- 待办事项与需求仓库
- 协作式维基与知识库
- 线框图与原型工具
- 用于数据调查的查询与报表工具
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
Talent.ID handles
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
招聘时应关注什么
业务分析师候选人通常表达清晰，这让面试容易进行、却难以判读。可靠的做法是给他们一个来自贵司领域的真实问题，然后看他们如何着手，因为分析能力体现在一个人提出的问题里，几乎从不体现在他对自己方法的描述里。
提问的质量
用两三句话描述一个贵司真实存在的需要，然后让他们来追问。这一项练习比面试其余部分加起来更有信息量。要看的是探究结果与例外的问题，而不是收集功能点的问题。
- 先问为什么，再问是什么
- 很早就去追例外情况
- 注意到你没有说的部分并就此提问
- 用不同的措辞复述回来，以检验自己的理解
区分想要与需要
问他们某次干系人提出了一个具体要求、而分析师断定其背后的需要并不相同的经历。你要找的是他调查请求而不是转录请求的证据——以及他如何应对一位对自己方案很有感情的干系人。
- 能给出一个具体例子，以及通向结论的推理
- 在不否定干系人专业性的前提下把方向拉回来
- 明白人们之所以描述解决方案，是因为问题更难表述
书面表达的精确度
请他们提供一份自己写的需求或一组验收标准（必要时可脱敏），或者安排一次简短的书面练习。分析是以书面形式交付的，而口头流利并不能预测它。要找的缺陷是含糊、无法被证伪的措辞。
- 写出的标准是可以被判定为不通过的
- 避免不同读者会有不同解读的词
- 把假设显式写出来，而不是留在言外
- 在陈述需求时不夹带解决方案
文档的分寸
问他们如何决定写多少。这个角色有一个众所周知的失效模式：产出详尽却无人查阅的文档，而最强的候选人对此保持警觉。合适的量随风险、监管、团队人员延续性以及决定的可撤销程度而变化。
- 按「弄错的代价」来调整深度
- 能描述某件自己刻意没有写下来的东西
- 把文档当作达成共识的手段，而不是交付物本身
处理相互冲突的干系人
问他们在业务的两个部分想要互不兼容的东西时是怎么推进的。有用的回答包含把冲突显性化、并把它交给能拍板的人，而不是悄悄偏向职级更高的一方，或者写出一个行不通的折中方案。
- 尽早把分歧摆出来，而不是自己吸收掉
- 能识别出真正握有决定权的人
- 能描述一个与自己建议相反的决定
面对数据与规则的从容
最困难的分析大多是条件逻辑与数据含义。问他们在文档已经过时、原作者也已离开的情况下，如何确立支配某个流程的真实规则。愿意直接查看数据是一个很强的正面信号。
- 会去查询或检查数据，而不是依赖别人的描述
- 当条件开始增多时会拿出决策表
- 当两个系统持有同一实体时会追问以哪个为准
在工程团队内部工作
与开发人员保持距离的分析师，往往产出完整却没有帮助的规格说明。问他们在一个迭代中如何与工程师协作，以及当工程师提出需求没有预料到的方案时会怎么做。
- 在工作进行中随时可被找来澄清
- 把工程师的提问当作需求不清晰的信号
- 愿意因为一项技术洞见而修改需求
值得一问的面试问题
用于支持采购方自己的面试流程。对候选人的评估属于招聘方，由招聘方对照自身的业务领域与期望进行权衡，并自行作出决定。
这是我们业务里的一个问题，用两句话描述。你需要问我什么？
What a strong answer shows
这是能拿到的最可靠的信号。强候选人会追问结果、受影响的人、当前流程与例外。弱一些的会收集一份功能清单，并在问题还没被确立之前就开始提方案。
讲一条你写错了的需求。它是怎么暴露出来的？之后你的做法有什么改变？
What a strong answer shows
他们是否承担过自己规格说明的后果。要看一个具体的缺陷、对造成它的那处含糊的诚实交代，以及方法上的改变，而不是一句「以后会更仔细」。
一位干系人要一份带有特定列的报表。你会如何回应？
What a strong answer shows
他们是否调查请求。较强的回答会问这份报表支撑的是什么决定、这个人读完之后会做什么，因为其背后的需要往往由报表以外的东西满足得更好。
当正确行为取决于若干条件相互作用时，你如何写验收标准？
What a strong answer shows
处理条件逻辑的严谨程度。要看决策表或等价的结构、对组合的有意覆盖，以及对边界的显式处理——而不是一段只描述了预期情形、其余留给解读的文字。
你在记录一个既有流程，而两位资深员工对它的描述并不一致。你会怎么做？
What a strong answer shows
调查的本能。好的回答会把这处不一致当作信息——常常两人各自在不同情形下都是对的——并去找证据：观察工作、检查数据、看系统实际上做了什么。
多少文档才是合适的量？你如何决定？
What a strong answer shows
对这门学科核心失效模式的认识。较强的回答会按风险、监管暴露、团队人员流动与可撤销程度来调整深度，并且说得出某件自己选择不写下来的东西。
一位工程师告诉你，这条需求无法按现在写的方式实现。你如何处理？
What a strong answer shows
他们是协作还是防守。最好的回答会把它当作重新审视底层需要的机会，因为一条在技术上别扭的需求，往往是一条被写成解决方案的需求。
你产出过的哪一份分析没有产生任何作用？你认为原因是什么？
What a strong answer shows
诚实与分寸感。每一位有经验的分析师都写过没人使用的东西。能解释原因的候选人——受众不对、时机不对、形式不对、决定早已做出——已经学会了这份工作中不属于技术的那一部分。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- 某公司正在替换一个用了很久的内部系统。真正重要的行为编码在软件本身以及操作它的人的习惯里，文档反映的是更早的版本，原作者也已经离开。开发已经启动，并不断被没有人能确定回答的问题打断。
- Approach
- 追加的分析能力在客户既有的工作方式之内工作——他们的待办事项、他们的就绪定义、他们的干系人关系、他们的发布节奏。产品的所有权、什么值得先做，以及这次替换最终是为了什么，仍然属于客户；追加的能力负责确立当前的规则与数据含义、记录例外，并把它们转化为团队可以据以构建和验证的需求与验收标准。
- What this adds to the team
- 客户获得了分析能力，同时保留关于业务意图的每一个决定。系统应该做什么、哪些取舍可以接受，仍然属于对业务结果负责的那些人。
Related disciplines
Frequently asked questions
- 业务分析师与项目经理有什么区别？
- 他们回答不同的问题。业务分析师关心的是应该建什么以及为什么：底层问题、需求、规则、数据与验收标准。项目经理关心的是让一份已商定的工作被交付出来：顺序、依赖、风险、时间与汇报。两个角色面对同样的干系人，很容易被混为一谈，但责任不同——一个对界定的正确性负责，另一个对抵达负责。当一个人同时承担两者时，通常被压缩的是分析那一半，因为交付的压力更响。
- 业务分析师与产品负责人或产品经理有什么区别？
- 预期中的区别在于决定权。产品负责人或产品经理决定什么值得做、以什么顺序做，并对结果的价值负责。业务分析师确立并表述被选中的那件事必须做到什么，并对这份界定的正确与完整负责。实际上这条边界在业界并未取得一致：有些组织期望产品负责人自己做分析，有些组织的分析师实际上在决定优先级，而各家公司对头衔的使用并不一致。在为其中任何一个岗位招聘之前，值得先明确在贵司的结构里由谁掌握优先级决定权，因为那正是两个角色真正不同的地方。
- 敏捷团队还需要业务分析师吗？
- 认为不需要的看法来自一个公允的观察——敏捷实践用对话取代了大规模的前期规格说明，很多文档确实不再有用。没有消失的，是理解一个复杂领域、化解相互矛盾的干系人观点，并把行为表述到可被测试的程度这项工作。在简单的领域里，一位产品负责人和一个投入的团队可以把它吸收掉。在有监管约束、规则错综复杂，或者系统行为无人完全掌握的领域里，这是一项分量不小的工作，而让它无人负责，通常意味着它会在迭代中途由好几个人各做一部分。
- 业务分析师与数据分析师是一回事吗？
- 不是，尽管这两个称谓被用得很松，也确实有一些岗位横跨两者。数据分析师解读数据以回答「发生了什么」，工作主要在查询、统计与报表上。业务分析师定义一套系统应该做什么，并把数据当作关于流程真实行为的证据，而不是工作的产物。许多有能力的业务分析师会写查询，这是相当大的优势——但一位经历完全集中在报表上的候选人，未必做过需求工作。
- 业务分析师应该产出多少文档？
- 足以让构建和测试这项工作的人达成同一理解，不再多。合适的程度随「弄错的代价」而变化：一项受监管的计算、一次不可逆的数据迁移，或者一个供另一家组织依赖的接口，所值得的精确度不同于一次内部界面的调整。为满足流程而不是为支撑决定而存在的文档，是这门学科最常见的浪费——而它的篇幅常被误当作分析足够充分的证据。
- 业务分析师需要技术能力吗？
- 他们不需要写生产代码，但技术素养会显著提升其产出的质量。读懂一份数据库结构、写一条查询来验证某个假设、理解一个 API 能表达和不能表达什么，以及跟得上一场架构讨论，都让分析师得以核实而不是转述。领域知识至少同样重要：懂这块业务的分析师能识别出一个错误的答案，而这是通用分析技术给不了的能力。
- 业务分析师如何与现有的工程团队协作？
- 在技术团队扩展的安排下，分析师在客户既有的流程之内工作——他们的待办事项、他们的梳理会议、他们的文档标准、他们的干系人关系——并由客户指挥工作。产品所有权、业务优先级与路线图自始至终属于客户；追加的分析能力支持这些决定，绝不取代它们。Talent.ID 的部分仅限于雇佣：它持有雇佣关系、负责薪资发放与员工福利、处理人才管理，并与所雇员工保持持续的关系。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.