本从将从需求分析内容、需求分析过程2个方面来分享2B项目的需求分析相关内容。

一、需求分析的内容

需求分析基本包括以下几个关键词：调研（获取）、分析、整理（编写）、管理，当然了这4个关键词肯定和需求有关的，比如调研是指需求调研。另外，根据不同公司岗位工作的安排，可能有的需求分析岗还有软件产品设计等相关性工作，但不在本篇文章讨论范围内。

• 调研（获取）：和客户直接或间接沟通，对客户方的业务需求做深入了解。
• 分析：该过程中发生在调研过程中调研后，对需求的收集不仅仅是“获取”，更重要的是通过分析去挖掘需求。
• 整理：是对所有需求进行梳理，归类及详细描述，便于其他人能通过你的整理产出物快速准确了解需求。
• 管理：需求是动态的，需求变更是做项目性需求的常态，要学会适应。对于处于变化中的需求要学会需求管理。

了解了需求分析的内容，可以试着思考需求分析的目的是什么？答案一般包含于以下几方面：搜需求、挖需求、纠需求、砍需求等，个人认为需求分析要用一个词来归纳的话，那就是价值最大化：让软件或产品能够为客户提供最大价值。可能有人不太赞成我说的这句话，由于做项目会考虑到各方利益。但不管怎样，应该保持这样的初心。

二、需求分析过程

下面将围绕需求分析的内容对需求分析过程进行阐述。

2.1 调研

调研的方法有很多种，比如访谈法、会议法、体验法、观察法等，但具体到某个项目就各有千秋了。访谈法和会议法是比较常用的方法，毕竟比较直接有效。在调研过程中，有以下注意事项和大家分享：

（1）找对人

做项目性需求时，一般都有专门的业务对接人或者叫关键用户。做需求调研时，一定要让关键用户在场参与。既然客户方指定某个人为对接人，肯定有是原因的。说明他是能够代表客户方利益，并且对客户方的需求也是有独到见解的。其他参与人的想法或思路，我们不是完全否定，而是要条条记录、层层分析，最后要和关键用户讨论是否要纳入建设范围。

现实中有一些比较缺乏经验的小伙伴在做需求分析时，可能太为客户着想，觉得应该接受客户方所有人的需求。结果把自己折腾得求生不能求死不得，更可怕的是关键用户不认可这些需求，一切都凉凉了。

（2）多沟通、多确认

平常大家可能有这样类似的经历，说话的人觉得自己说的很清楚了，听者也觉得自己明白说话者的意思了，其实双方还是没理解到一块。比如一句话客户说“我们部门工作内容有点多，平常很忙”，客户可能的意思是说他们部门是公司的关键核心部门，而听者可能理解为需要给他们部门减减压。

现实中可能还有些业务专家可能觉得自己在同行业很久了，用户说的他都懂。在和客户沟通时，侃侃而谈，有点“喧宾夺主”的赶脚，这是很危险的。同样的一个问题，在不同客户那可能诉求是不一样的，所以要有耐心，让客户多说话，不要盲目自信。

关于需求确认，个人觉得比较有效的方式是把你理解的意思重复一遍讲给客户听；或者把你理解的意思用具体的业务场景描述出来，比如把你和客户都当成实际需求中的用户，然后把需求描述一遍，让客户确认是否理解正确。

在调研时，不要一直局限于项目范围，因为这样会限制你的思路，也不能全面的去了解客户需求。所以可以暂时不考虑项目的范围，让客户尽情地表达他们的想法，把需求甄别放在下一步。

2.2 分析与挖掘

需求分析不是简单的需求搬运工，而是要处理正确的需求。

更准确的说，客户或用户提出的一般都不是需求，而是问题。他们希望我们需要对问题进行提炼，转化为软件需求（解决方案），然后转交给开发人员。从问题到解决方案就是一个思路、分析的过程。

比如客户提出“我们所有的工作都要用软件管理起来”一句话，这是一个10星级的很抽象的问题，作为需求分析人员需求对问题做深入的了解并转化，才能成为软件需求。

另外，有时候客户的想法也是脑门一拍的事儿，所以我们要通过分析去识别出错误的需求或伪需求，这里不再举例，回头有机会会补上。

需求分析的过程也是把控范围的一个过程，比如本次是给客户做一个OA管理系统，客户突然提到说他们的办公用品台账管理太乱了，这个问题很明显就不属于OA的建设范围。

技术是一步一步发展的，客户提出的所有需求并不是技术上都能实现，所有不能实现的需求也要靠分析去识别出来。

以上是对需求分析的概述（转化需求、甄别伪需求、控制需求等）。

需求收集、分析是本能，能够引导客户，挖掘需求才是高手。

满足用户提出来的需求不是目的，建立客户在行业领域的标准化管理体系才是目的。这也就决定了用户提出的需求不一定都要实现，没有提出的需求也不一定不实现。让用户提需求只是实现这个目标的手段之一。

2.3 需求管理之文档管理

从一开始的初步调研到最后的上线，需求管理是贯穿整个需求分析的过程中的。

日常对需求的管理，对文档的依赖性还是挺多的，所以一定要重视文档。有人觉得写文档太浪费时间了，可是从长远来看写文档确实是为了提供效率。如有新人进入团队，他想了解团队之前的工作，如果有文档的话他可以直接从文档中就能了解大概；如果没有文档，那他只能点点滴滴都去问其他人了，中间的苦衷就不言而喻了。

需求管理涉及到不少过程及方法，本篇文章暂时只分享用文档在需求管理中的应用。

（1）版本管理

由于各种原因，如调研不完善、规划不全面、业务有变化等，需求池也是不断变化的，那么如何对这些变化进行管理呢？

下面就说到文档版本的管理，因为需求的记录还是要用文档的。当需求变化或更新时，需要及时更新文档，重要的事情说三遍：及时更新文档、及时更新文档、及时更新文档。

对于规范的需求文档一般都会有文档的“更新记录”这样的类似的章节，每次对版本做详细说明，如本次修改了什么内容、修改人等：

提示：需求文档要保留历史版本，而不是只留最新版本。比如从版本v1.1向v1.11过渡时，应保留V1.1的文件，复制一份V1.1的文件并在它上面修改后作为V1.11。

（2）完成度及优先级管理

在软件开发过程中可以用以下格式的文档对需求进行管理：

由于篇幅有限，暂时对需求的分享先到这里了，以后有机会再对以上某个细分领域继续分享……

毕竟个人能力有限，欢迎大家批评指正。

本文由 @喝茶唠嗑 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplah，基于CC0协议。