本周一，我发了一篇文章《客户带来的解决方案，真的能够解决问题吗？》，文章中着重讲解如何去了解客户真实的问题和核心诉求，今天，我们就讲讲在这之后的事。
全文共1006字，消化约5分钟。
让我们先来回顾一下，客户想要的，其本质上来说是业务需求（Business Requirement），业务需求通常提纲挈领的将项目的愿景和范围作了很好的描述和规范，从一个2B端的项目而言，展示了这个组织做这个项目的目标是什么。
了解完真实的问题之后，下一步该怎么做呢？想起上周碰到一个客户的问题，我们一位产品顾问为他规划的解决方案，产品顾问在执行过程中认为对这个产品的理解有偏差。在短暂的间隙之后，为该客户重新安排需求的分析和变更。
之后我和团队的伙伴一直在想什么地方出了问题，就着周末去海边放风的空档，认真地回顾了一下。
我发现，不光是从事外包的工作人员，就连大部分产品经理在对用户的需求进行了解的过程中，也会犯这样的错误，这个错误就是，我们往往是将功能清单混淆当做用户需求来用。
不止在一篇文章中写过，大多数的委托方都是通过他看到可能的解决方案来提需求的，而需求的本质其实就是用户的预期和现实之间的差距和问题的展现，功能则是这些问题可能的解决途径。
如果说产品就是解决问题的途径，那么这里面就有两道坎：
a. 问题（需求）找错了
b. 解决问题的方法（功能）设计有问题
大多数产品经理压根就是跳过实际问题直接找解决方法，反过来推断找到的解决方法所对应的问题是真问题，这就是用户需求（User Requirement）和功能需求（Functional Requirement）的区别。
当你听到委托方抱怨说，你们写的这东西太复杂都把我绕进去了的时候，你有没有考虑过，你的客户真的理解你写的东西么？你写的东西和他要解决的问题又是否契合呢？如果我们想要真心解决客户的问题，那么什么样的描述能够更符合委托方的认知和习惯呢？
所以问题来了，在写功能清单之前，我们能够做些什么呢？在这里，我提供三个思路。
1. 分清用户是谁
既然是了解用户需求，先对用户有一个详细的了解和分类，他们是谁，各自有什么样的特点，处在整体业务或流程的哪个阶段？
2. 用故事描述需求
很多做过Scrum的同学都会了解用户故事，它本身是一种轻量有效的用户需求描述方式，一般而言我们的描述格式为
“作为xx（角色），希望通过xxx样的方式（活动），以便达成xxxx（目的）。”
将解决方法放回到用户实际的场景中去看，并且将真实的预期和现实之间的问题暴露出来。
3. 最后的功能清单
到最终的一个项目实施，功能清单的来源则不仅仅是用户需求和问题的搜集解决，还要受系统设计、质量要求、业务规则的实际影响，而这些常常被称作是项目中的软性需求，当我们无法意识到它们的时候，给项目埋下的雷将在交付过程中无限倍的放大，甚至是重新开始。
如有问题，欢迎在官方微信公众号留言，微信公众号搜索“外包大师”点击关注即可。
网友评论