做业务分析，必须认清的十一条事实

前言

最近，在偶然的机会下成功转岗。由一名测试人员转为业务分析师。初入职时，我本以为这是一份简单却具有挑战性的工作，站在测试的维度进行分析，可以优化系统提出更好的见解。直到，第一次参与项目会议，在大Boss的带领下分析了项目，提出自己的见解后经过点评才发现自己的想法和对业务的分析时如此的肤浅。在得到批评的同时也获得大boss的指导，他推荐了《掌握需求过程》这本书，让我们仔细的阅读和结合项目进行探究，并整理为笔记。 后续，将结合LD的指导，书中的内容和项目的学习情况进行分享。

---

掌握需求你必须明白的十一个事实

1.需求其实并非在谈需求

在谈需求之前，我们先了解需求的概念是什么？需求是“消费者对于具体某种商品的使用程度（包括是否会购买、购买数量、使用频率、使用时长等等）”。这是比较官方的，简单的来说，需求便是消费者愿意为我们产品买单使用并产生粘性。所以，作为业务分析师的我们需要清楚的认识到：我们工作不仅仅是谈需求，而是如何设计产品并让消费者愿意买单，并对产品的使用产生依赖。围绕这两点，我们首先要做到如何愿意让消费者愿意为我们产品买单，因为买单是瞬时性的，短期的，这也是产品存活的第一步，而产生依赖和粘性是一个长期培养的过程。

2.构建软件的初衷是为拥有它的人提供价值

使用者之所以愿意买单，一定是从这个产品中能够获得他所需要的价值。这便要求我们死磕“愿意”，这里可以理解为是“有做某事的动机”，而产生动机的基础是“需要”。比如，炎热的夏天，一名工人刚刚结束烈日下的工作，走到了小卖部，这个时候，他的动机是什么？需要一瓶饮料帮助解渴，如果小卖部没有饮料，他可能会找取代品，比如冰棍或其他可以辅助解渴的，或者去别的小卖部买水。这里，水的价值便是我们提供饮料的最初动机。因为抓住了没带水的人口渴时的痛点，进行设计提供便携的解渴物质。至于，饮料的品类和口味，便是设计他之后价值的提升和让客户产生依赖或者粘性。

3.正确的软件 = 要求 + 痛点 + 价值的实现

什么是正确的软件，站在设计的角度上是没有判断的标准，因为“存在即合理”。但作为一款产品，使者的满意度和粘性便是产品评判的标准。当我们决定设计一款正确的产品时，就需要从要求、痛点和价值去考虑。要求是最直接的，他的来源可能是客户提出的要求，或者他们业务中的要求，行业要求等，甚至一些潜在的要求，这个就需求我们自己去发掘，比如使用者的年龄比较大，这个时候就要结合使用者的实际情况考虑页面，字体大小等因素。痛点，也就是使用者的吐槽点，比如工作上经常遇到的麻烦或困难，这个时候我们不仅需要学会倾听，还是善于发现，思考。围绕“痛点”下功夫，设计出来的产品最容易得到客户的认可。价值是从整体出发，客户会考虑使用这个产品能给我带来什么价值，帮助我解决什么问题，带来什么效益等，这个价值也是一种等价的衡量，这个产品带来的价值是否与我为他买单的价值相匹配。所以，一个正确的产品，客户为其买单是要在要求达成度，痛点解决度和价值实现度上达到或者超过客户的预期值。

4.构建软件和解决业务问题是不等价的，存在巨大差别

当我们构建软件基于想客户交付某种功能时，这个时候我们就处于一种被动的状态，客户会通过长期的使用来判断是否解决他们的问题，如果没有解决就会提出新的需求和问题，让软件陷入一种重复迭代的过程，也会让参与软件的人陷入一种疲惫。所以，构建软件的时候，我们不能单纯的抱着解决用户的工作来设计功能，而是带着一种“我要改变或颠覆用户固有的工作方式，并通过这种方式提高工作效率，解决痛点，这样用户就以我们为导向”。这种改变和颠覆是困难，是需要我们通过大量的时间，资料来分析，深刻的明确使用者的心理，习惯和业务等，然后进行设计和分析。

5.需求不一定要写下来，但构建者必须知道他们

《需求规格说明书》等文档都是需求的一种记录形式。很多时候我们都通过文档的形式记性记录，但是很多时候面对不同的对象，一份厚厚的规格说明书并不能成为各个部门或单位的通行证，因为并非每个人都是专业的，更多的时候，大家都更偏向于自己的理解方式和思维，而不是通过认真的阅读文字然后理解，这会消耗大家的时间，某种意义上是别人不能接受的。所以，针对不同的受众，我们要采用不同的方式进行帮打，帮助他们更容易理解。这就需要业务分析去不断的学习，能够灵活的借助不同的工具，譬如：面对上游客户，最直观最简洁的操作是他们最能接受的表达方式，这个时候，我们可以通过Axure工具构建处产品的原型，通过PPT等图形文字结合的方式进行表达和信息传递；面对下游的开发者，纯文字是他们最不能接受的方式，这个时候，我们可以通过他们比较理解的方式去传达信息，如数据库之间的关系通过E-R图，数据库模型进行表达，数据具体信息通过Excel进行记录，业务的逻辑通过流程图、时序图和业务架构图等图标结合辅助性文字进行传达，不仅提高了传达的效率，同时提高传达的准确度。

6.客户是上帝但客户说的不一定是圣旨

在与客户进行对接过程中，业务分析师需要认真聆听客户的需求，但有些时候客户也不知道什么是对的，有时候也不知道需要什么。当我们记录了客户的需求后，需要对需求进行再分析，基于业务熟悉的基础上，进行分析，取其精华去其糟粕。作为业务分析人员，我们需要定位自己的产品最终目的，不是单纯的附和客户，而理性的为客户解决问题，因为最终客户检验我们的产品不是他说到的是否全部实现，而是这个产品覆盖了他的需求之余给他带来的价值。我们需要记住“有时候，你的客户就像匹诺曹，不会告诉你全部事实”。

7.需求不是偶然得到的，要通过某种有序的过程得到

需求的获取是一个阶段性，有序的过程的，不是一次和客户谈话便能得到一个完成的需求。在获取需求之前，我们需要对我们软件的定位用户，他们的工作职能，业务等做足够的功课，从而在与用户交流过程中及时捕捉有效信息；有些时候，还需要我们融入他们的工作当中，融入市场进行调研，掌握足够的资料。在需求的实现过程中，也会面临着新需求的提出。所以，参与需求的过程，我们需要明确每个阶段的任务和输出，那些任务对项目是最重要的。

8.迭代是以理解业务需求为基础

迭代开发是一种比较高效率的研发模式，之前测试的时候，经常会有“版本迭代”和“功能迭代”。无论什么迭代都是，以需求为导向。版本的升级可能是因为需求的变动或者需求的新增，这两点最终落实就是功能的新增或修改。

9.业务分析师最重要的工具：头脑、眼睛和耳朵

软件服务的对象是人，所以最直接的获取需求的方式是从看，听，研究中获取需求。其他的工具只是在获取需求之后进行信息传递和表达的方式。

10.需求必须是可度量、可测试的

可测试，可度量的需求：什么是可测试性需求

11.需求业务分析的最终目的是改变用户思考问题的方式

当需求来自于不同利益相关者时，需求的分析需求抽象话，对于一个产品的最初需求分析，我们考虑产品的受众不能只是提出需求的人，而是涉及相关工作的一类人，这样我们的使用者范围广了，使用的前景也就广了。对于特殊的群众，我们可以基于这个需求进行定制化，如此以来，投入的成本和输出也就增加了。因此，在需求开始时建立一些抽象概念，并对专业名称，术语整理好相关词汇表。在展示业务过程模型是，可以与利益相关者一起发现工作的本质，从而得到清晰和可测量的需求。

---

总结

做产品要解决的问题绝不仅仅是“可以满足用户需求”，而是“让用户对你的产品有需求”这便要求我们对我们的客户的心理、习惯和业务等综合性的了解，带着客户的动机去了解需求，抓住痛点并解决痛点去设计软件，从而达到价值最大化。