想着改变人类

顺便征服世界

公众微信号：跟Sam一起学需求分析

今天我们来简单介绍这本书，这本书的中文名是：《CACP证书和BABOK学习指南》，目前该书本是没有中文翻译的，因为整本书都是英文版，我将会把它翻译成中文，然后方便大家通过中文进行阅读。若有纰漏请原谅，因为不是英语专业，虽不是英语专业，但对软件需求的专业术语运用自我感觉没有问题~而且附上英文原文供大家提供用户对照。

这本书的翻译我会分每一章的进行翻译，供大家阅读和学习，本书对我们做软件需求分析的，有着重要影响和帮助。

接下里我们来看看本书的作者是谁？

Hans Jonasson ，CBAP，PMP，JTC Unlimited创始人，拥有超过30年的项目管理、业务分析和专业发展培训经验。1980年，他在瑞典哥德堡的沃尔沃公司(Volvo Ltd.)担任系统分析师/程序员，开始了自己的职业生涯。1984年，他移居美国，为EDS(一家全球领先的信息技术（IT）服务公司)和通用汽车公司开发新项目。他管理着汽车行业软件开发项目的各个方面，预算从10万美元到1000万美元不等。汉斯现在居住在瑞典哥德堡。他在IBM、EDS、福特汽车、戴姆勒克莱斯勒、通用动力、花旗银行和沃尔沃等公司教授了2万多名专业人员的项目管理、需求收集、能力成熟度模型集成和过程开发入门级和高级课程。Hans是项目管理研究所和国际商业分析研究所(IIBA)瑞典分会的成员。他也是密歇根东南部IIBA的创始成员。

此时这个时候其实已经出现了很多名词：CACP、IIBA、BAbok，不要着急，在本书中都会对这些名词有着明确的解释。都和我们做产品经理、业务分析、需求分析有着密切的关系。

1、介绍

在过去的三十年里，我教过项目管理和要求在全球范围内超过25000人。在这些课程中，大多数都讨论了为什么项目，尤其是信息技术(IT)项目会失败。不可避免的是，首要原因是需求的不明确或变化。当团队遇到这些问题时，他们经常快速解决，比如使用新的需求收集工具方法或聘请顾问。然而，比这些方法更好的。不是来自新的需求收集工具，也不是来自用户访谈。它是一组可重复的过程，这些过程将项目从早期的想法阶段带到客户和开发人员之间商定的项目和产品范围的创建。这个可重复的过程集，以及帮助执行它们的工具和技术，是我想在本书中提到的。这一章通过让你熟悉这本书的格式、写作风格和目的，为本书的其余部分奠定了基础。每一章都有相似的结构和格式，贯穿全书。内容基于关于使用什么标准和包含什么技术的某些选择。这些选择是由我做出的，并在本章中通过回顾系统开发的历史和当今标准的演变来解释。这一章的主要目标之一是让你知道这本书是如何组织的，书里涵盖的内容，以及它能给你带来什么。第一章的内容正与创建好的需求文档时的时的阅读建议非常一致。

1.1  Objectives   本书的目标

解释这本书的目的

介绍怎么使用这本书

回顾这本书的目标读者

介绍业务分析的专业领域

回顾商业分析几十年内的演变

回顾目前行业标准制定权威

介绍一个项目作为一个例子贯穿全书的知识点。

1.2  Overview 概述

This book is designed to be used for multiple purposes:

这本书可以用在以下多种用途：

1、可以作为认证的业务分析专业学习指南考试(CBAP®),但未来会进行扩展。这本书的文本对准备考试有很大帮助。此外，这本书包括300个样题帮助你准备考试。它是基于版本3的指南业务分析知识®(BABOK®)。

2、 作为参考书。任何参与收集需求的人都可以使用这本书来发现最佳实践和学习有用的技术，以及工具和模板，以改进团队中的需求收集过程。

3、用于自我提升。需要更多需求收集技术指导的业务分析师，或正在准备考取关于业务分析方面的任何证书的人，都可以将本书作为学习指南。本书包含练习和案例解决方案，如何处理需求收集过程中可能遇到的不同情况。

4、作为一本课程书，研究组以及企业内部培训和咨询培训的参与者都可以用这本书作为教科书，因为它包括内置练习，最佳实践，工具和模板。 因为它还包含对活动的全面解决方案， 所以这个提醒是必要的。 提出的解决方案对于当前案例的解决方案，而不是真正对于你的项目的解决方案。 由于没有真正的进行用户访谈，因此会有假设，因此书籍解决方案与您的解决方案之间可能存在一些差异。

5、提供模板， 业务需求文档的两个不同示例已包含在本书的附录B中。 第一个是全面综合模板，由ESI International提供，第二个是更简单的模板，适用于较小的项目。 你可以书上查阅它们，自定义它们，并将它们引入您的项目中。

本书不作为工具书，也不是提倡任何特殊的方法或技术。其目的是对大量业务分析问题进行广泛的概述，并提供有关工具和技术的足够信息，使读者能够为不同类型的项目选择最佳方法。 这是通用性的书，不是专家的书。 对于组织可能投入大量时间和精力的关键领域，更应该考虑全面的培训。

为了评估行业当前的现状和收集业务分析师当前面临挑战的相关信息，我与以前参加过我的培训研讨会的一群业务分析师和项目参与者进行一项调查。虽然不是大型或全面的调查，该调查是通过探索业务分析师在不同组织的角色职责，捕捉需求的困难和专业人员在协助分析过程中使用到的工具进行调查。因为这个研究在本书中都被引用和讨论。

调查中问到的问题之一是，“收集和记录需求的主要困难是什么?”前五名是什么？

一部分客户缺乏时间

客户缺乏业务知识

缺乏业务范围的支持

缺乏熟练的业务分析师

没有可重复的过程可学习

调查了这些问题结果，站在更高的层面来看，前三个问题都与客户有关系。原因是调查的人都是开发人员，所以都在责怪客户了？还是客户在沟通方面确实遇到了困难，也许在他们公司的业务不熟悉？这可能两者都有可能，不管哪种方式，它清楚地表明了客户在需求收集中的角色和能力的重要性。

1.3  Early Days 早期

在计算机系统早期，大多数应用程序都是为了解决特定的问题。客户大部分都是开发人员去沟通的，开发人员并且需要对需求有着清晰的了解。但是最大的限制是计算机本身的能力。硬件价格昂贵，功能有限。回顾30年前计算机的性能与今天计算机的性能，总是感觉是一段奇幻的旅程。尽管现在计算机的能力在不断提高，但计算机的能力已经不再是开发软件的限制因素。当时，计算机系统被看作是一种工具，就像一台计算器或手机一样，在当时是不可能可能预见到这个工具像到现在竟然可以推动组织变革或将业务推向新的方向。当时的软件的集成和互操作性是做得很粗糙的，现在看来就等于钓鱼网站似的。那时候开发人员的生活很轻松，因为客户不太挑剔，他们用一些简单的开发方法就可以满足到他们日常工作的需要了。与早期的电视节目作比较，当时的节目很少，画面质量很差，节目质量不高。但总的来说，用户对它很满意，因为人们的期望值很低，所以和容易满足。如今，有数百个频道和高质量的节目，似乎大多数人很难找到他们喜欢的东西，预期已经发生了变化。

尽管在20世纪80年代中期出现了几种系统开发方法，但它们都倾向于将重点放在系统方面，牺牲了理解真正的业务需求为代价。当时项目一开始就直接写代码了，然后是大量的测试和错误。导致很多项目被取消，更多的项目没有得到客户的认可。开发人员很少或根本没有理解客户解决的实际业务问题究竟是什么。虽然其实可以理解的，因为系统解决方案的优先级是有限的，客户常常面对开发人员时描述他们需要什么时经常会说，“我不知道怎么描述，但我看到就知道”。

在20世纪80年代和90年代，这种情况开始逐渐改变。系统迅速变得更加复杂，业务更加具有竞争力和全球化，从苦苦的研究技术到苦苦的研究于业务究竟要做什么。1984年搬到美国后，我参与的第一个项目是通用汽车的通用应付账款系统。在此之前，我在瑞典沃尔沃有限公司(Volvo Ltd.)看到的项目大多是单用户、相对非集成的应用程序。在通用汽车，更强调的是获取客户的需求。

要想在这种环境中取得成功(我认为成功的项目是，是该系统在30年后仍在运行)，它需要一套不同于传统系统开发人员的技能。尽管技术技能仍然很重要，但系统开发现在越来越多地涉及到沟通、促进、谈判和基本的人际技能。有许多非常优秀的技术人员不喜欢这个新环境，这导致了开发人员和用户之间存在许多问题，开发人员的想法是解决方案，而用户的想法是业务需要。

（Figure 1.1 Evolution of systems.） （图1.1 系统的进化）  

为了尝试不同的方法来改善开发人员和客户之间的沟通，组织选了一些分析人员组成的客户团队，专门负责与客户进行交互，收集他们的需求，并确保他们满意。客户不再与开发人员对话，而是由客户团队负责确保开发团队理解客户的需求。不幸的是，从事这些工作的人往往没有很强的业务背景或者对开发人员的需求没有很好的理解。在缺乏方法和培训的基础上，业务分析人员正在努力解决这种双重交流——与客户进行业务沟通，与开发人员进行系统沟通。按照这种做法是要求开发人员、用户和中间人之间进行协调，从而使项目更加复杂。这让项目管理实践的需求比以前更加重要。

1.4  Project Management Institute®  项目管理协会

20世纪60年代末，项目管理协会(PMI)成立。尽管其影响在一开始是渐进的，但到上世纪90年代中期，项目管理协会(PMI)已成为建立项目管理标准领域的推动力。他们对项目管理知识体系的指导，目前已在其第四版中，在建立一种通用的语言和集中于项目规划方面起了重要作用。

在PMI和各种开发方法论的帮助下，上世纪90年代末出现了比较好的开发实践和开发过程管理，使开发团队能够更快地开发程序。然而，这仍然留下了很大的空白。比如说产品描述(无论它的详细程度如何，它都是有用的)是项目管理过程的输入。但是谁去写的产品描述呢?开发人员又如何通过产品描述开发出正确的产品?显然，以一种有组织的方式来开发出一种稳定的产品是理想的;但是，还有一个问题，如果他是一个错误的产品那怎么办？有些人认为PMI可以做更多的工作来定义这个标准，但是实际上有必要将项目经理的角色和产品开发人员的角色分开。因为他们的角色和目标是相互冲突的。此外，产品定义方面往往非常依赖于所从事工作的行业。IT项目的产品定义与构建项目的产品定义不同。因此，PMI将需求开发过程留给了其他知识领域。在最近,PMI也进入业务分析领域，PMI专业业务分析®(PMI-PBA®)认证。虽然这本书并没有与这个认证的知识保持一致，但是这本书中涉及的许多概念都与PMI观点一致。

1.5  International Institute of Business Analysis™ 国际商业分析研究所

2003年，国际商业分析研究所（IIBA）在加拿大成立，其目标是完善在系统分析，业务分析和流程改进的工作方法。IIBA已经取得了很大的成功，并且已经被大量的从业者所接受，这本BAbok是大多部分的业务分析师一开始就采用的方式。IIBA认为，项目计划和系统设计过于关注，但还不足以定义所交付的产品。他们使用的流程和方法通常都在工具中体现，或与特定供应商对接。 IIBA可能是建立专业领域框架的关键驱动因素，称为业务分析。

业务分析师的角色随着时间的推移而不断演变。最初作为开发人员工作的一部分，该角色被称为系统分析和需求分析。这项工作的职责根据组织和用于开发的工具有很大的不同。现在，它正在演变成一个增值的位置，充当开发人员和客户之间的沟通纽带。发展的语言往往晦涩难懂，充满了首字母缩略词。公司里都希望业务分析师能够有效地与业务组织和开发人员沟通，但是客户和开发人员可能位于不同的楼层，使用不同的术语，或者还有时间、语言和文化差异等复杂性时，沟通面临的问题会成倍增加。由于全球化很可能是一种趋势，这种趋势将会持续下去，因此在未来将会更多的处理这些问题。业务分析师是前景较好工作，这个岗位正朝着重要性和地位提高的方向发展。实际上，外包工作是比较困难的工作之一，因为需要接近客户。但这至少部分地解释了，不仅是公司对业务分析的兴趣增加了，而且个人实践者对业务分析的兴趣也增加了。

1.6  Role of the Business Analyst 业务分析师的角色

在本章前面提到的调查中，受访者被问及业务分析师在组织中的角色。从他们的回答中可以清楚地看出，目前还没有一个普遍接受的行业标准。回答的例子包括

创建文档

与最终用户一起定义需求，然后与开发人员一起确保这些需求可以开发为程序。

促进会议

为测试计划和测试用例提供依据

开发流程和程序文档制定。

创建项目计划，作为客户和IT之间的沟通桥梁。

用户培训

定义海外职位

从中可以看出，业务分析师有时是普通员工，有时是高级人员，本书中使用的定义反映了行业的发展方向，而不一定是现在的位置。如果分析师在一个大型组织中工作，分配到一个重要项目，他或她很可能是一名全职业务分析师。但是，大多数业务分析师通常不会这样。除了收集需求外，他们还管理项目，设计系统，建立客户关系，甚至可以在早上制作咖啡。第2章更准确地定义了当前对业务分析师角色划分的看法。但是现在，请记住，当本书中使用术语业务分析师时，它不是描述一个人，而是描述业务中的角色。它可能是一个人20％的时间，或者可能需要三个人100％（或更多）的时间来填补这个角色（图1.2）。业务分析师使用的流程所涉及的正式程度也会因所使用的工具，组织的规模和项目以及正在处理的项目类型而有很大差异。当然，如果项目是一个大型的企业级计划，分析师将花费大量时间分析业务，进行企业建模，规划组织变更等。但是，如果项目要修改现有报告，在当前系统中，可能很少花时间分析企业目标（或者客户会质疑分析师的能力）。

（图1.2）业务分析师的角色与工作。

本书是在BABOK v3之后组织的，每个知识领域有一章。然而，值得注意的是，书中的主题超出了BABOK，并引入了其他相关主题。它也不是用来代替BABOK，所以对于那些学习认证的人来说，这本书应该与BABOK一起使用。除了IIBA之外，还有其他组织影响了业务分析专业的发展，包括大型工具制造商，培训公司和其他标准制定机构，如电气和电子工程师协会，软件工程研究所（ SEI™）等。一个值得关注的是SEI。 SEI始于20世纪80年代初，最初以软件行业为目标，成功定义了运行在软件项目中所需的流程。今天的SEI不仅仅是软件，而是在研究工程实践，但他们的很多标准仍然有软件感觉。他们早期就特别强调了需求实践，并且在许多其他组织已经抓住它之前就已经这样做了。 SEI的一些定义将在第2章中进行探讨。

1.7  Where Is It All Going?  需求分析学科会如何走向？

虽然IIBA在开发业务分析框架方面做得很好，但是它的知识体系还是不断的在变化的。 IIBA在业务分析范围内所采用的领域非常庞大，比PMI在项目管理方面知识里所采用的领域要大得多。 部分原因是PMI解决通用项目的管理，可以应用于所有项目的流程。 另一方面，在探索开发方法，建模技术，质量保证和组织参与时，IIBA更加详细。 例如，业务分析师涉及项目前期，项目期间和项目后期，而不仅仅是粗略的级别。 业务分析师在这三个阶段都发挥着重要作用和责任; 另一方面，项目经理是主要负责项目的。

业务分析也比大多数其他领域更不成熟。 系统开发只进行了大约40到50年，在这种情况下，业务分析甚至更少。 与制造，建筑和其他学科相比，业务分析的学科成熟度在他们的成熟度相比更是九牛一毛。 这意味着未来许多年内，业务分析的知识体系可能会发生重大变化。 经验教训和流程改进也会随着学科的成熟度而变得成熟。 随着行业的变化，从业者需要随之而改变。 业务分析这个行业中，工具、方法和最佳实践都在发生巨大的变化。 只需看看敏捷开发等主题（将在以后进一步探讨）：20年前，很少有人听说过它，几乎没有人使用它。 如今，大多数公司的项目都会用到敏捷开发方法的某些方面。

1.8  Book Project  书中的项目

为了举例说明书中讨论的不同技术和工具，将使用一个虚构的项目，称为“处方药交互项目”。决定把它变成一个虚构的项目而不是一个真实的项目有很多原因。首先，任何真正的项目都可能涉及特定行业的独特细节。其次，没有一个实际的项目会使用本书中讨论的所有技术和工具，这意味着即使是一个真正的项目也需要一些伪造来完成本书中所讨论的所有技术和工具。第三，也是最重要的一点，项目需要简单和直观，以便主要关注业务分析部分，而不是业务本身。

“处方药交互项目”是一个大型连锁药店C.V. Green正在进行的项目。这是美国的传统习俗。但正在缓慢地向亚洲和欧洲扩张。C.V. Green的愿景是尽量减少开给客户的不同药物之间的负面相互作用，并希望尽可能早地积极识别任何潜在的药物相互作用。该公司一直在主导着标准化药物相互作用报告的工作，并与一个联盟合作创建一个共享数据库，在此可以识别潜在的药物相互作用的同时也要维护个人客户的权利。接下来的章节即可找到该项目的起点和框架。

除了书本的项目外，还有一个案例研究项目。这是为Swede-Mart创建的一个库存和订购系统，它将用于每章末尾发现的大多数案例研究活动。第10章详细描述了Swede-Mart案例研究

1.9  Summary  总结

业务分析仍然是一门相对较新的学科。虽然行业中有许多新兴的标准，但在很大程度上，每个组织仍然需要选择在其环境中工作的工具、流程和定义。这本书使用了IIBA知识体(BABOK)作为商业分析框架的主要参考。本书的目标是让一个组织，或者个人，开始走上业务分析过程的正规化的道路，同时也为那些寻求业务分析认证的个人提供学习指南。

Activity  活动

您组织中成功收集需求的最大障碍是什么?你可以作为一个团队进行头脑风暴，也可以独自进行。列出8到10个因素。根据项目成功的重要性对它们进行优先排序，然后选择前五名。对于前五名的障碍，记录你的工作的团队使用什么行动进行减少障碍，以及你作为个人可以采取的一到两件行动来减少障碍的。你也可以在你的团队会议上讨论这些问题，以此提升团队能力，并开始朝着更可重复的需求收集过程的方向发展。

无运动，不女神！

看完文章动一动吧~

▼

文 | Sam

编辑 | Sam

乐于推动需求分析师达到行业的标准，也与你分享人生深刻的无趣。

这里有关于对产品经理的小见解，也有关于生活肤浅的快乐

#谢谢你 于千万人中 朝我走来#

#将还你一个不偷懒的人生#