4 业务分析师

4 业务分析师

在每个软件项目中，都有人在显式或隐式地扮演业务分析师（BA）的角色。业务分析师是能够在组织中促进变化的人，他们通过定义需求和向干系人推荐有价值的解决方案来促进这些变化。分析师获取和分析他人的观点，将收集到的信息转换为需求规范说明，并于其他干系人沟通和交流这些信息。分析师帮助干系人发现他们所描述的需求与实际需要之间的差别。他承担着教导、提问、倾听、组织和学习的任务。

4.1业务分析师的角色

业务分析师的首要职责是获取、分析、记录和验证项目干系人的需要。作为首席“口译”，业务分析师要将客户群体的需求传递到软件开发团队。当然，我们还有其他很多沟通方式可用，因此项目中的信息交流不只是分析师一个人的责任。业务分析师在收集和传播产品信息时扮演主要角色，而项目经理的主要职责是沟通项目信息。

分析师是一种项目角色，而不一定是个头衔。业务分析师还有一些别名，例如需求分析师、系统分析师、需求工程师、需求经理、应用分析师、业务系统分析师、IT业务分析师或者简单称为分析师。他可能同时是项目经理、产品经理、产品负责人、主题专家和开发人员，有时甚至是用户。
在那些开发用户产品的组织中，分析师的角色通常落到产品经理或者市场人员头上。一般都是有产品经理来执行业务分析师的角色，他们通常更侧重于理解市场和预测外界用户的需求。如果项目中既有产品经理又有业务分析师，通常都是产品经理主抓外部市场和用户请求，再由业务分析师将其转换为功能需求。
敏捷项目同样需要业务分析技巧。在这样的项目中，传统意义上业务分析师的一些任务可能由产品负责人来完成。有些敏捷团队就发现，设置一名分析师的好处多多。分析师能代表客户并理解其需要，同时还能完成业务分析师的其他本职任务。
才华横溢的业务分析师可以使项目起死回生。有一家公司就发现，相比于阅读菜鸟分析师所写的说明书，他们在阅读由经验丰富的业务分析师写的需求规范说明书时，速度要快出一倍，因为后者的差错更少。尤其是项目估算方面广为流行的CocomoII模型，分析师的经验和能力对项目的工作和成本的影响非常明显。在类似的项目中，相比于初出茅庐的分析师，经验丰富的分析师可以将项目的整个工作减少三分之一。

4.2业务分析师的职责

分析师首先理解项目的业务目标，然后定义出用户、功能和质量需求，让团队进行估算和计划项目，最后设计、开发和验证产品。
业务分析师同时还是领导者和沟通者，负责将模糊的客户理念转换为清晰的规范说明，指导软件开发团队的工作。下面为执行的典型活动：

定义业务需求
作为业务分析师，首要任务是帮助业务或者出资方、产品经理或者市场经理定义项目的业务需求。可以提供一份愿景和范围的文档模板，然后与愿景负责人协同工作，帮助他们清晰地表达愿景。规划需求方法
分析师要制定获取、分析、记录、验证和管理需求方面的计划，这一过程贯彻于项目的始终。要与项目经理紧密配合，保证这些计划与项目整体计划保持一致，并帮助完成项目的最终目标。确定项目干系人和用户类别
针对每个用户类别，与业务发起人共同选出合适的代表，争取得到他们的参与，确定其责任。要解释清楚你希望从客户参与者那里得到什么，还要与每个人都达成适当的共识。获取需求
积极主动的分析师能够熟练使用各类信息收集技巧，帮助用户阐述自己需要哪些系统功能，满足其业务目标。分析需求
我们需要找两种需求：一种是从客户要求引申出来的逻辑结果；另一种是客户虽然没有明确表态但似乎有意向的含蓄需求。我们可以使用需求模型来识别模型，找出需求之间的差距，揭示相互有矛盾的需求，确定制定出来的所有需求都在范围之内。与干系人协同工作，共同确定对用户需求和功能需求的说明需求具体到什么程度。记录需求
分析师在记录需求时需要做到结构清晰，有条理，能够清楚描述将用于解决客户痛点的解决方案。使用标准模板能够加速需求开发进程，它可以提醒业务分析师要与用户代表讨论哪些主题。沟通需求
作为业务分析师，必须与所有各方高效而充分地进行需求沟通。业务分析师要确定何时非文本方式提交需求，包括各类可视化分析模型、图表、数理方程和原型。沟通不是将需求记录在纸上然后将其束之高阁那么简单。沟通还涉及与团队持续不断地合作，确保他们能够理解你想要表达的信息。主导需求验证
业务分析师除了必须保证需求说明具备人们特别想要的特性，还要保证基于需求的解决方案能够满足干系人的需求。分析师是进行需求检查的核心人物。还要检查需求引发的设计和测试，确保人们对需求的解读是正确的。如果在敏捷项目中用接收测试来代替具体需求，还需要对这些测试进行检查。帮助推动需求优先级排序
分析师作为中间人，要负责对各类干系人和开发人员进行合作和协商，保证他们做出的需求优先级决策是合理的，与达成业务目标是一致的。管理需求
业务分析师全程参与整个软件开发生命周期，因此会帮助创建、检查和执行项目的需求管理计划。在针对已知产品发布或开发迭代建立一个需求基线之后，业务分析师把重点转向跟踪这些需求的状态，验证产品是否满足需求，并对需求基线的变更进行管理。根据不同成员的信息输入，分析师要收集可跟踪的信息，这些信息将单独的需求和其他系统元素联系在一起。 4.3基本的分析技巧

分析师的技能偏向于人，而非技术。分析师需要熟知各类需求获取技巧，提交信息的方式多种多样，不止局限于自然语言文本形式。

倾听技巧
主动倾听要求能够做到几点：注意力集中、神情专注、注意眼神的交流以及重复关键问题以确保自己完全理解对方的意思。需要抓住人们说话的要点，还要理解人们的言外之意，探知他们没有明说的隐忧。了解合作伙伴喜欢的沟通方式，避免在理解客户心声时带有个人情绪。还要注意一些未说明的假设，它们是理解他人谈话或自身想法的基础。访谈和提问技巧
大多数需求输入都来源于讨论，因此，业务分析师要有能力与不同个体和人群讨论他们的需求。如果共事的对象是高管或非常固执或激进的个人，那就不太好办了。你提出的问题必须恰当，才能引出基本的需求信息。才思敏捷
业务分析师要不断提醒自己注意现有信息，并将新信息与之对比之后进行加工处理。他们要发现哪些地方是矛盾的、不确定的、模糊的和想当然的，以便在合适的机会对它们进行讨论。可以发挥自己的聪明才智预先写一套完美的访谈问题：但需要随时准备提出之前无法预见的问题。需要设计出好问题，认真仔细聆听反馈意见，迅速想出下一个需要表述或者提出的机智话题。有时，其实不是在提问题，而是结合上下文给出一个适当的例子，帮助干系人继续清楚地表达他们的意图。分析技巧
高效率的业务分析师要有高、低两级抽象思维能力，并且能自由切换。有时，必须将概要信息进行细化。在另一些情形，则需要从一个用户描述的具体需求中总结出一套可以满足多个干系人的需求。业务分析师需要理解来自不同源头的复杂信息，并能解决与之相关的难题。他们需要严格评估信息，以求协调矛盾，从基本的真实需要中独立出用户“想要的”，并区分提议方案与需求之间的差异。系统思考的技巧
虽然业务分析师必须做到事无巨细，但也要有大局观。业务分析师要参照他所了解的企业整体、业务环境和应用来核查需求，找出矛盾之处及其影响。他需要理解人、过程、技术与系统之间的关系。如果客户针对其功能领域提出一个需求，业务分析师就需要判断这个需求是否会暗地里影响到系统的其他部分。学习技巧
分析师需要能够快速吸收新的需求方法或者应用领域内的新知识。他们要能将知识高效转化为实践。分析师应当是一个高效率且具有批判性思维的读者，因为他们得处理大量材料并迅速掌握精髓。不必是具体领域内的专家，所以不要怕提出问题，要求进一步澄清。所谓“知之为知之，不知为不知，是知也。”引导技巧
分析师需要引导需求讨论和获取研讨会。引导是带领团队迈向成功的关键步骤。在大家共同定义需求、对需要进行优先级排序和解决矛盾时，引导是至关重要的。客观的引导师具有很高超的提问、观察和引导技巧，能够帮助团队建立互信，还能改善业务人员和IT员工之间偶尔的紧张关系。领导力技巧
高超的分析师能够影响干系人群体，使其步调一致，为实现共同目标而奋斗。领导力要求分析师拥有各类技巧，已协调项目的干系人之间的关系、解决冲突并做出决策。各类干系人可能并不知道其他人的动机、需求和约束，因此分析师要创造出一个和谐的环境，促进干系人之间的互信。观察技巧
善于观察的分析师能够注意到其他人不经意间提出的举足轻重的意见。通过观察用户的工作过程或者使用当前的应用程序，敏锐的观察者可以捕获到客户自己都没有察觉到的细枝末节。沟通技巧
需求开发最主要的交付物是一系列的书面需求，这些需求可以在客户、市场、经理和技术人员之间高效传递信息。分析师需要有扎实的语言功底，能用书面或者口头形式清晰地表达复杂的概念。必须能够针对不同对象写不同的需求，比如客户需要验证需求，而开发人员需要有清晰、准确的需求才能做实现工作。组织技巧
在获取和分析需求时，业务分析师必须要处理大量毫无头绪的信息。分析师要应对不断变化的信息，并将这些信息碎片构建成一个整体，这就要求他们具有非凡的组织技巧、耐心和不屈不挠的精神，从混沌和混乱中理清头绪。搭建一个信息架构，在项目进展过程中丰富它，使其能为项目提供信息支持。建模技巧
建模涉及多方面的内容，例如结构化分析模型（数据流图、实体关系图和类似图表）所表达的流程图，统一建模语言（UML）的符号，这是每个分析师不可或缺的技能。有些模型适用于和用户沟通，有些适用于与开发人员沟通，还有一些适用于纯分析，帮助业务分析师改进需求。人际技巧
分析师必须有能力让彼此有竞争关系的利益相关人以及团队身份协同工作。分析师在各种职能部门的个体和不同级别的组织交流的时候，要能收放自如，态度随和，表达清晰。创造性
业务分析师不能像记录员那样机械地记录客户的谈话内容。最优秀的分析师能够挖掘出潜在的需求引发客户的思考。他们对产品有自己的奇思妙想，能够发掘新市场和业务机遇，并能找出让客户心悦诚服的办法。真正的分析师高手能以创造性方式满足客户需要，而这些需要甚至客户自己都没意识到。但是，分析师要尽力避免给解决方案“镀金”，未经客户允许，不能随便在规范说明中添加新需求。 4.4基本的分析知识

除了拥有出众的才能和人格魅力，业务分析师还要知识渊博，只不过实践才能出真知。他们需要理解现代需求工程的实践，知道如何在不同软件开发生命周期背景下应用这些实践。他们还需要教育和说服其他人，如果有人对现有需求实践还不熟悉的话。高效率的分析师都有一个丰富的技术工具箱，知道哪些工具何时可以派上用场。
业务分析师需要将需求开发和管理活动纳入整个项目周期之中。如果分析师能够理解项目管理、开发生命周期、风险管理和质量工程，就能防止需求方面的问题对项目造成破坏。业务分析师最好能有架构和 *** 作环境方面的一些知识，以便能参与优先级和非功能需求这样的技术讨论。
业务、行业和组织方面的知识是高效率业务分析师最宝贵的财富。业务能力强的分析师能够极大减少他们与客户之间沟通不畅的情形。如果分析师能理解组织和业务领域，即使有些判断没有明确表述出来，有些需求也不太明显，他也经常能够探知得到。再改进业务流程和提出有价值的功能方面，他们能提供其他干系人不曾想到的建议。在商业环境中，理解行业领域特别有帮助，能够让业务分析师进行市场和竞争产品分析。

4.5业务分析师的培养

优秀的业务分析师是在不同的教育和工作背景中成长起来的，因此他们在知识和技巧方面可能会有所差别。每一个分析师都应根据自身的情况弥补自己的不足。下面为不同背景的人变身分析师：

前用户
他们理解业务和工作环境，所以能够轻松赢得以前同事的信任。他们讲的是用户语言，并且了解现有系统和业务流程。缺点是可能并不是特别清楚软件工程或如何与技术人员进行沟通。如果不熟悉建模技术，他们在表达信息时就可能比较外行，完全用文字描述。需要多学习一些软件开发方面的技术知识，以便能够以最适合的形式向不同类别的受众表达信息。前开发人员或测试人员
由开发人员转型而来的分析师需要在业务领域方面多下功夫。开发人员的思维和语言很容易受到技术的禁锢，他们很可能会专注软件开发而不是客户的需要。他们需要紧跟现代最优秀的需求工程实践。开发人员如果接受本章前所提及的各类软技巧方面的培训和指导，肯定会受益匪浅。
我们一般很少要求测试人员来承担分析师的角色。但是测试人员通常由分析性思维，这会使其成为优秀的业务分析师。测试人员习惯于考虑特殊情况和如何“搞破坏”，这是发现需求问题的非常实用的技巧之一。就像开发人员一样，测试人员也需要学习优秀的需求工程实践，使自己的业务知识更渊博。前（或兼职）项目经理
这是一种高效的角色转变。项目经理已经适应了与合适的团队协作，能理解组织和业务知识，具有很强的沟通技巧。他们善于倾听、协商和引导。他们也有很强的组织和写作技巧。
但是，前项目经理还得多了解需求工程实践。创建计划、分配资源和协调分析师与其他团队成员的活动，这是一回事，自己做业务分析师又是另一回事了。前项目经理必须学会理解业务需求并在现有项目计划内排列它们的优先级，而不是将精力放在时间表、资源和预算约束上面。他们需要培养分析、建模和访谈技巧，这些对项经理不是那么重要的技能，对业务分析师来说却是成功的关键。主题专家
相比于典型用户，主题专家能够根据他们的经验来判断需求是否合理，如何扩展现有的系统，提议的架构应当如何设计，在其他领域对用户有哪些影响。有些产品的开发，组织会聘请专家级的产品用户，这些用户拥有丰富的专业经验，他们进入公司要么做分析师，要么做用户代表。
但这样做也有风险，他可能在制定系统需求时侧重个人喜好而忽略各类用户类的实际需要。他在考虑需求时可能会比较盲目，缺乏创新性的新思维。菜鸟
优点是他对需求流程的工作原理几乎没有什么先入为主的概念。但是缺乏相关的经验和知识，还有很多需要学习的地方，了解如何履行业务分析师的职责以及应用错综复杂的实践。还需要充分了解软件开发流程，理解开发人员、测试人员和团队其他成员所面临的挑战。
4.6敏捷项目中分析师的角色

有些敏捷方法将这样的团队成员称为“产品负责人”。承担这个角色的人除了执行业务分析师的一些常规活动之外，还要提供产品愿景、协调约束、对余下工作的产品订单进行优先级排序以及对产品做出最终决策。
在一些项目中，同时设置有业务分析师和产品负责人两个角色。另外，其他一些团队成员，例如开发人员也要履行分析师的部分职责。但是，不管项目采取何种开发方法，业务分析师的工作仍然需要有人来做。如果团队中有成员能够集业务分析师的技能于一身，这个团队肯定会受益匪浅。
如果一个组织正在向敏捷开发方法转型，业务分析师往往都不知道如何才能高效地融入项目。按照敏捷开发精神，分析师必须走出传统观念中“业务分析师”的角色，只要对交付成功的产品有好处，做什么都可以。
下面是业务分析师如何在敏捷项目中应用其技巧的一些建议：

定义一个轻量级、灵活的需求流程，将其作为项目的基础。确保需求文档数量适中，不能太少，也不能太多。帮助确保记录Backlog的最佳方式。善于引导和领导力技巧，确保干系人彼此之间常讨论和需求相关的需要、问题和关心等。帮助验证客户的需要已准确展现在产品Backlog之中，并引导Backlog优先级排序活动。客户对需求和优先级的想法发生变化时，要配合客户并协助记录下这些变更。与团队其他成员协作，判断变更对迭代范围和发布计划的影响。 4.7打造一个协作型的团队

在软件项目中，分析师、开发人员、用户、经理和市场人员之间的关系有时比较紧张。各方都做不到完全的互信或理解他人的需要和难处。但在现实中，软件产品的生产者和消费者的目标是一致的。对于公司信息系统的开发，所有各方都供职于同一家公司，因此公司经营底线的改进对他们有利。对于商业产品来说，客户满意度会为生产者带来回报，给开发人员带来满足感。
对于促进用户代表和其他项目干系人所面临的挑战并在各种场合下始终显示出对合作者的敬意。分析师引领所有项目参与者达成需求方面的共识，从而在以下几个方面实现双赢。

客户对产品感到满意。开发组织对业务成果感到满意。所有团队成员对自己在这项富有挑战但又回报丰厚的项目中的优秀表现而自豪。