上周着重讲了讲，如何去了解客户真实的问题和核心诉求，其本质上说的是业务需求（Business Requirement），业务需求通常提纲挈领的将项目的愿景和范围作了很好的描述和规范，从一个2B端的项目而言，展示了这个组织做这个项目的目标是什么。

了解完真实的问题之后，下一步该怎么做呢？上周碰到一个客户的问题，我们一位产品顾问为他规划的内容，他在执行过程中认为是和他对这个产品的理解有偏差，再短暂的暂停之后，将为该客户重新安排需求的分析和变更。之后我和团队的同学一直在想什么地方出了问题，就这周末去海边放风的空档，认真回顾了一下。

发现不光是从事外包的人员，非常大数量的产品经理在对用户的需求进行了解的过程中，都会犯这样的错误，往往是将功能清单混淆当做用户需求来用。

不止在一篇文章中写过，大多数的委托方都是通过他看到可能的解决方案来提需求的，而需求的本质其实就是用户的预期和现实之间的差距和问题的展现，功能则是这些问题可能的解决途径。

如果说产品就是解决问题的途径，那么简单讲这里面就两道坎
a、问题（需求）找错了
b、解决问题的方法（功能）设计有问题

太多的产品经理压根就是跳过实际问题直接找解决方法，反过来推断找到的解决方法所对应的问题是真问题，这就是用户需求（User Requirement）和功能需求（Functional Requirement）的区别。当你听到委托方抱怨说，你们写的这东西太复杂都把我绕进去了的时候，有没有考虑过，你的客户真的理解你列的东西么？你列的东西和他要解决的问题又是否契合呢？如果我们的目的是真实的将客户的问题去解决，那么什么样的描述能够更符合委托方的认知和习惯呢？

所以问题来了，上来不写功能清单，我们又该怎么做呢？

a、一定要分清用户是谁
既然是了解用户需求，先对用户有一个详细的了解和分类，他们是谁，各自有什么样的特点，处在整体业务或流程的哪个阶段？

b、通过用户故事来描述用户需求
很多做过Scrum的同学都会了解用户故事，它本身是一种轻量有效的用户需求描述方式，一般而言我们的描述格式为

“作为xx（角色），希望通过xxx样的方式（活动），以便达成xxxx（目的）”

将解决方法放回到用户实际的场景中去看，并且将真实的预期和现实之间的问题暴露出来。

c、最后的功能清单的确定不止来源于用户需求
到最终的一个项目实施，功能清单的来源则不仅仅是用户需求和问题的搜集解决，还要受系统设计、质量要求、业务规则的实际影响，而这些常常被称作是项目中的软性需求，当我们无法意识到它们的时候，给项目埋下的雷将在交付过程中无限倍的放大，甚至是重新开始。