经验分享：ToB项目需求分析、注意事项

本从将需求分析的目的、需求分析前准备工作、需求分析过程3个方面分享。

正常来讲，ToB软件在入场实施前，甲乙双方已经大概沟通过一次需求（或双方已经签订了关于功能范围的协议）。

所以入场后的需求分析其实是 二次需求分析 ，或者说是详细的需求分析。二次需求分析其实是一个长期的过程，短则十天半月，长则一两个月或持续整个项目。

以下是以二次需求分析来分享的（面对面沟通）：

一、需求分析目的

需求分析的目的个人觉得基本包括如下：

• 全面准确了解客户方需求（不赘述）
• 为开发人员等提供依据或参考（开发人员依此来进行功能实现）
• 为项目成本估算或成本控制提供依据（把控项目成本）
• 其他目的（以我个人的项目经历来讲，以上3个目的是关键）

其实，还有一个潜在目的：如果需求分析后的文档按照项目规定需要双方签字的话，这样就为避免撕逼大战提供有力证据（哈哈）。

二、前期准备

个人觉得在进行二次需求分析前应从以下方面准备：

1. 熟悉建设范围

一定要认真地阅读之前签订的文件（甚至不止一遍），因为该文件约定了本次软件建设要实现的功能范围（一般都是按功能模块来划分的）。

熟悉了建设范围后，和客户进行详细沟通时就会心中有底；不了解建设范围，有一个更可怕的后果：项目失控（结果你懂的）。

建议：把自己了解到的信息按层次或逻辑整理出来，可用软件来梳理；个人喜欢用导图，把结构梳理一遍。

要像“以结婚为目的”的搞对象方式，去了解对方（客户）。

2. 了解客户基础信息建设情况

该环节需要了解客户已实施过哪些信息软件，如ERP、CRM、供应链、OA等，甚至需要了解硬件设施情况。

why？

在了解客户的基本软件建设情况后，在做需求分析时就会心中有数，如客户是否重视软件建设、以及目前信息化程度。这样做的还有一个重要的好处:如果和其他系统做接口的话，心中有个权衡（如接口的 实现难易程度， 经常做项目的都知道）。

题外话：接口问题一直是项目管理过程中的难点之一，因为关系到甲乙丙丁等各方利益，来回扯皮是常有的事（可能有点夸张）。

要像在乎你对象过去一样，去了解客户的过去，因为这是对彼此负责。

三、需求分析过程

1. 找对人

很简单，找对人的意思就是找到合适的人去沟通，即进行需求分析时要直接和干系人沟通。

再通俗一点讲，项目验收时谁签字就找谁沟通。如甲方的对接人是某生产技术科科长，那么平常调研需求时就不要和其他人闲扯淡，即使他们提一些有意义的需求，那必须等让科长点头确认才行。

其实你要懂得，有时候领导的头衔还真不是摆设。领导的想法和基层干事的想法真不一样，这一点一定要清楚。

2. 说对话

这里要说的是沟通方式，特别是给国企或央企做项目，那领导一个个都像“大爷”一样，所以在工作中和他们打交道一定要慎重。

不是说要让大家拍马屁，工作中时不时地夸夸客户或者夸夸客户公司还是很有必要的。

干我们这一行，可能有好多直男。才工作或才毕业可以以自己的性格来办事，但是工作时间久了你会发现你必须要变通一下。

我之前在做一个项目的时候，客户直接告诉我，他喜欢和我对接需求，而不喜欢和另外一个同事沟通。原因是另一个同事平常太较真，有时候说话还比较直接（虽然有时候确实需要刚直的人，但要分场合）。

另外，处理工作在适当的时候可以和客户唠一些非工作的内容，这样也可以拉近彼此之间的距离。我一次和客户唠嗑的过程中，偶然发现他对某软件公司有偏见（之前并未发觉），后来在我的解释下，客户在后来的沟通过程中感觉我们之间的距离近多了。

不卑不亢这个四个字是我和客户沟通一直坚持的原则。

3. 要真诚

态度一定要真诚。

这里要讲两方面：

第一点：需求实现不了怎么办？

可能由于当前技术原因或者其他原因（如成本等），某需求实现不了。此时要坦诚相待，就委婉告诉客户此需求很难满足。如果对方是一个很“聪明”的领导，就很明白了。切记不要去忽悠客户或者回避，这样有时会弄巧成拙。

第二点：我们要协助解决客户头疼的问题。

其实需求分析并不是按照客户要求的去实现或者屏蔽需求，我们本质上是要为客户创造价值。

其实很多时候客户都不知道他们需要做什么，所以我们要摸清情况，帮助客户去搜集需求(纳尼，帮助搜集需求？)。

对，你没看错。

确实有时需要我们去帮助客户搜集需求，梳理需求。

这是为什么呢？

客户提出的需求有时候是伪需求，我们需求帮助他们去伪存真，并帮助他们重新梳理需求。这其实也是专业需求分析人员的高深之处，即为客户提供合适的解决问题思路。

4. “雁过留声”

引用一个词“雁过留声”。

也就是说和客户沟通确认事项后，要及时确认（不管是签字确认还是邮件确认）。

特别是一些需求变更的内容，如之前已经定了做功能A，并且已经签字确认；过了几天客户又改变主意了，还想按照原来的思路。这时候就一定要让客户签字确认。发生这样的事情也不要不好意思，客户其实是能够理解的。

5. 其他

当然了，还有其他的需求分析注意事项，由于篇幅关系就不多说了（如多思考、行业探究等）。

四、总结

本文适合初次做项目的同行，毕竟个人能力有限及平常工作时间关系，暂时给大家分享这么多。

欢迎大家批评指正。

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

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