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