如果要做好一款产品，需求分析是非常有必要且不容易的事情。而且进行需求分析也是为了明确我们的系统目标。具体而言进行需求分析的目的可以从两方角度来谈论：
- 从客户的角度而言，进行需求分析可以帮助我们跟好的理解客户所需，以便于后续能够更好的满足客户的期望。当然这也是减少开发出来的产品与客户需求偏差的重要步骤。
- 从开发人员的角度来讲，理清需求是帮我们系统地对功能和非功能性的业务能够有更多的掌握，尽量做到在项目开始时就掌握相对更多的需求信息，尽量确保需求的完整性，从而降低后期需求变动的成本。
那么，要怎样才能做好需求分析呢？
(一) 明确的需求分析理念
需求分析从来都不是一次就能做好的，他需要我们不断的讨论，并自已有的基础上进行细化、推演，并就存在的问题不断进行沟通才能最终达到想要的目标。因此，我们必须要明确需求分析的理念：
- 不要期望一次就做好需求。实际上，对于很多小公司的项目，需求多数时候都出自产品经理，不存在任何的与客户和技术沟通的中间过程，往往，在这个过程中产品对系统既有的业务和逻辑缺乏思考。直到需求评审的那一刻，才暴露出大量的问题。最终，需求评审会变成了需求讨论沟通会。
- 需求沟通前，要做足功课，确保沟通的过程和范围可控及沟通的内容有效。
- 要有需求层级的概念，先理清需求的总目标，再逐步深入细节。只有明确了需求分析与沟通，才能保证需求的可控性，否则就容易出现该分析的需求没分析到位，可有可无的需求却不断延伸。细细想一下，是不是有过需求评审中，突然发现某些需求缺失了，而领域部分需求又把流程过于复杂化？
(二) 分步进行，不断沟通，逐层分析
需求的复杂性以及不确定性，决定了我们无法一步到位做好需求分析。因此我们需要分步进行，层层细化。这样才能让需求越来越明确。
现在有这样一个简单的需求描述：开发一款满足企业员工使用的ERP+CRM相融合的系统，并能保证员工的即时通信与资源共享，此外，除了功能性要求外还要求保证系统的数据传输的安全性、即时性以及系统稳定性，同时需要考虑公司业务人员外出使用的方便性。
对这个需求，从用户的角度讲，便捷使用、网络通畅、满足业务需求(如即时通信功能、ERP功能、CRM功能等)就是根本。但是如果从开发的角度来讲，我们需要从更专业的角度来分析，比如使用的方便性问题，由于存在外出的员工，我们就必须考虑多种使用场景，比如是否支持PC端、移动端等等；信息的及时性则要求我们需要考虑通信的方式；数据通信的安全性问题则让我们不得不思考是否要对数据进行加密；还有一点系统的稳定性则要求我们在设计系统是是否要考虑系统才分，甚至是分布式或者微服务等等。
到这里，我们就能够逐步勾勒出一个初步的产品画像了。但是，这仅仅是需求分析的第一步。因为我们勾勒出的产品画像还很抽象，甚至抽象到我们都不知道具体能干些什么。那么，我们就必须根据勾勒出的画像，建立一个初步需求结构，然后对需求的每一部分进行逐步细化、层层分解。这样需求也会变得越来越完善。比如我们前面提到的需求，我们即时通信功能：从业务上来讲，这样的需求并不完善，因为我们不知道这里的即时通信指的是IM文字之类的，还是语音与视频电话之类的沟通。甚至对于这个过程中是否需要对通信记录做服务器备份存档以便后续业务信息整理归档等等我们都不确定。因此，我们就需要在前面的模糊画像上，进一步细化每个部分。如此层层展开，最终保证需求的清晰性。当然，在这个过程中，需要不断的与用户进行沟通交流。不断完善才能做到。为了避免无效的沟通，在每一个阶段的沟通，我们都需要提前设定沟通目标，并思考沟通的范围。
(三) 重视各部分间的联系，避免需求冲突
之所以把这个话题放在第二点，是因为这个问题应该贯穿于整个需求分析与沟通过程中：每次需求沟通之后，进行需求分析的过程中，我们都需要验证个部分间是否存在冲突。在这个过程中，严格来将，要保证需求间不存在冲突，是需要对任何层级都进行验证的。不过，为了节省时间上的成本，通常，我们可以在每次需求沟通之前，对要沟通的内容进行一定的边界界定，这个界定范围其中一个要考虑的因素就是该部分要遵循的规则不应该造成系统间个部分的冲突。否则我们就需要在此之前，考虑可能带来的冲突，以及要从哪些方面来进行平衡。然后带着这些问题在需求讨论的时候才更有针对性，也才能把我好需求的尺度。
(四) 把握重点防止需求泛化
做好需求不容易，特别是控制需求的边界，更不容易。稍不注意就容易出现需求泛化，这样的需求泛化，不仅仅表现在需求本身，也表现在需求的功能确定性导致相关人员理解出现偏差上。在小团队项目中，常有一种现象，产品在出需求的时候，会对某些功能点一笔带过，没有更多的细节，看似是为了简化需求，一旦牵扯到多人协作的时候，就出现了千人千面的现象，最终导致需求边界扩大化。相反，某些用户常用的功能，却可能因为产品为了最求功能的强大，而最终加了很多无用功能，导致需求臃肿。对此，我们要做到：想清楚功能的重点是什么，满足重点需求。如果说，存在某些个别的特例，应该延后排期，以次级功能或隐藏功能的形式出现。毕竟一旦某个功能面向用户产生数据之后，哪怕只有极少数用户甚至只有一个用户，都会导致后续砍掉困难重重。
(五) 鉴别伪需求，避免资源浪费
关于伪需求，往往是见仁见智的。我们自己必须要建立一个衡量需求的尺度。就是这把尺帮我们做决定。就我个人的观点大致包含如下几方面：
- 明确项目的阶段任务；
- 不应最求大而全；
- 功能不是一次性的；
- 资源的支持力度；
- 配合市场目标，强调重点；
- 满足是间的要求。
之所以要求做到这几点，主要在于我们做产品的目的是为了推向市场，服务目标用户。而服务的提供应该伴随业务的发展而发展，只有这样，我们才能保证有足够的资源，服务我们的目标群体，一旦某些需求的目标群体和资源投入不成正比或偏差过大，我们就应该进行取舍，延后排期、甚至在一定时期内进行舍弃。
(六) 验证需求的完整性，避免业务断层
实际上，就上面谈到的几点问题，基本上都存在交叉性，即便是验证需求完整性的问题也是如此。但是这里还是要对这个问题进行强调：在做需求的时候，沟通收集整理出来的需求，在分析整理出来之后，一定要进行需求验证，特别是重点需求，一定要对需求业务流程的完整性进行验证，甚至在必要的时候画出完整的业务流程图，辅助业务逻辑验证。
总结
最后，需求在项目开发中是特别重要的。特别是项目的前期，一定要先把业务需求的核心搞清楚。如果这一点没有搞清楚，后续的一切都是白搭。即便产品做出来了，最终结果也是得不偿失。就我个人的经历而言，遇到的一些项目，不论是市场定位、目标群体都很不错，但就是在产品推进这块往往因为想要快速推出并且最求功能的大而全，从而导致在边缘功能上浪费了大量资源，而到了最后产品差不多的时候，资源却不足以在继续支撑项目，其实这就是项目的最大不幸。
网友评论