产品需求沟通出问题怎么办？

阿拓带你飞：产品制作的流程中，发现需求并定义需求是首要环节，假如产品需求沟通出现问题了怎么办？你需要解决三个问题，避免含糊性，定义需求和功能，明确功能和属性。

一:如何避免含混性出现

含混性，指的是不清晰的程度。在项目开发过程中，含混性**一直贯穿整个过程。从需求出现到把需求变成产品，含混性始终影响着整个项目。因为含混性的存在，产品经理必须注重沟通和理解，尽可能准确地探索需求和传达需求，而工程师们则需要尽可能理解需求，在产品诞生之后，产品经理还需要关注用户需求是否发生了变化。简单地说，含混性越大，项目风险也**越大。著名思想家温伯格提到一个计算含混性的公式：含混性 = 实现需求的最大花费/实现需求的最小花费。

这个公式在项目评估的时候非常有效，尤其是技术评审阶段。不同的工程师**有不同的工作量评估。如果含混性越大，则这个工作量评估的差距就越大，说明产品经理传达需求的过程越有问题。反之，则说明大家基本保持了理解一致。那么，我们为什么要避免含混性的出现？因为含混性意味着产品有可能被用户遗弃而造成失败，意味着在开发过程中**出现大量成本，尤其是沟通成本和开发成本。从信息论角度来看，这些含混性就好像是大量的噪声，**影响人接收到正常的信息。把“信噪比”的概念引用到产品设计中，其实是一个比较有趣的方式。

所谓的讯息就是为了沟通而产生的，而使用者界面就是承载着资讯的载体。使用者透过界面和各式各样的系统进行五花八门的资讯交换。资讯可能由使用者产生，例如某个人在 Twitter 上发了一则讯息，通过界面上传到网络系统，然后通过网络传递到所有人的荧幕前，然后再由其他阅读到这则讯息的使用者接收。因此在资讯的生命周期中，包括了产生、传递、接收这三个重要的阶段，而每个阶段都有可能造成资讯的损耗。而传递中的资讯又可以分为“真正有用的资讯”和“造成干扰的杂讯”。举例来说，一张讨论各国人口数量的图表，如果采用了过多且花哨的装饰或特效，这些装饰和特效就**成为资讯的“杂讯”。如果要将讯息完整地传递给使用者，设计师可以选择强化原有的讯息，或是降低多余的杂讯，来提高“信噪比”（Signal-to-Noise Ratio）以增加讯息成功被判读的几率，也让使用者能更轻松地阅读资讯。——摘自陈威帆的《台湾设计师谈资讯与视觉设计的绝妙平衡》。

想要有效地避免含混性的出现，应该尽可能地通过一些方法保证信息的完整性，避免出现过程中的损耗。比如我在技术需求评审阶段总是**让技术人员重新复述一遍需求的细节和目标，确保我们理解一致。这种做法很有效果，尤其是在降低含混性上是非常有效的。正如许多人很喜欢看书，一年可以看好多书，但总觉得自己没有长进。实际上，当你要他复述这些书的内容时，他都不知道作者的主要观点和推导的过程，只记得自己看书的时候觉得这本书很好看，而不知道为什么好看，为什么引人入胜。反之，通过复述书中的内容，其实就是对通过阅读吸收的知识进行重新理解和思考的过程，记忆**更加深刻，而且对于信息的损耗也**降低。

另一方面，在需求评审过程中，不一致的情况时有发生，这其实也是含混性的外在表现。有的开发人员说这个功能10 天就可以实现，而有的开发人员则说5天就可以实现，这里含混性的比值就是2：1，说明存在许多不一致的情况，需要重新理解并达成一致。所以，需求评审的意义其实在于控制风险，降低含混性的出现。

二：如何定义需求和功能

我们往往发现看了再多书也抑制不住跃跃欲试的心情，于是遭遇了第一次失败的经历。那么，我们真的可以开始聊聊“需求”这个伴随产品经理整个职业生涯的名词吗？我相信大部分产品经理以后的口头禅**有这样几种：

●用户想要……

●这体验太差了！

●需求不合理！

关于需求，我们前面已经聊了许多，但往往第一次做需求的时候，**发现自己手足无措。如何对需求进行管理？如何排需求的优先级？需求之中还有许多需求，如何分解？当我第一次接到需求任务时，我和各位一样突然发现自己一无所知。阅读是需求，那么什么样的人是我们的用户，需要什么样的阅读内容，需要怎么样的阅读方式？我当时的脑子里充满了各种问号。阅读产品可以复杂如Google Reader，也可以简单如Instapaper；内容可以像Flipboard支持订阅，也可以像Zite一样支持推荐。我究竟要把这个功能做成什么样呢？是面面俱到，还是尽量满足基础需求即可？是囊括各种最新潮的交互方式，还是只包含人们最常用的交互方式？我思索了一天，直到路过星巴克才发现我现在在面临什么样的问题：切入点是目前最关键的问题。找到切入点之后，我才知道这个功能应该做成什么样，与其他产品的差异在哪里。正如星巴克有如此多种类的咖啡，因为调制方法不同而产生了许多品类，而这些品类都有各自的拥趸，这就是切入点和竞争力。即便如此，我们喝完了拿铁和卡布奇诺，依然不知道为什么这两种看起来配方类似、只是比例不同的咖啡**成为咖啡调制历史上重要的两款产品——最有趣的是，我喜欢拿铁，而我的朋友喜欢卡布奇诺、摩卡等品种。那么，同样的阅读功能是否也有这样一个“比例”可以让产品经理找到真正的切入点？

约翰?冯?诺依曼曾说：“如果根本不知道自己在讨论什么，那么对其强求精确则毫无意义。”对于产品经理来说，如果不知道自己要做什么样的需求，那么强求一个方案也是毫无意义的。经过和其他产品经理讨论，以及对用户进行一些了解之后，我发现自己好像陷入了一个坑：阅读这个需求可大可小，如何控制这个功能的广度和深度才是这个需求的关键。如何控制自己的欲望，如何避免为了做功能而加上一些花哨的功能，是产品经理时常**纠结的问题。

无论如何，让我们回到“切入点”的问题。通过与用户进行沟通，我知道了他们希望有一个可以快速获得对应资讯内容的功能。
●场景：日常无聊的时间可以看对应的资讯消遣休息一下。
●需求：了解发生了什么事情，有什么好玩的，可以适当有些深度。
●竞品：Zaker和Flipboard。

我特意把竞品列出来，是因为竞品的出现让我看到了找出“切入点”的一丝希望。在用户调研过程中，大部分用户**通过自己的使用经验去描述需求——对某个产品进行举例就是他们常用的方法。对于用户来说，他们感性地用经验去解释自己的需求，是非常合理的；对产品经理来说，用户通过某个产品去描述，是把需求具象化的有效手段。尽管这个具象化有可能出现偏差，但是对产品经理来说至少找到了一扇门，也许默默说声“芝麻开门”就能获得灵感

于是，结合用户的需求和对竞品的分析，我获得了一手资料，而需求也开始明晰化，产品原则在心里慢慢浮现。原则一：快速地阅读，丰富内容和类别。原则二：减少自定义的操作，仅仅支持订阅来源。原则三：文字越少越好，内容趣味性越强越好。

但这只是基本的产品原则，与实际开发过程中参考的需求文档还是少了很多细节的，尤其是面临一个问题：产品原则仅仅是缩小了需求的范围，更像是一个边界，而具体的产品方案还没有基本的雏形，我们还不知道用户的需求具体是什么，该如何满足。就好像用户告诉大众汽车公司，需要一个更小更便捷的经济用车，于是大众推出了经典的“甲壳虫”系列。那么，是否可以把阅读的需求也做一个类比？假设把阅读的需求比喻成开车，用户需要什么样的车子呢？按照产品原则，我们可以继续深入。原则一：允许个性化定制。原则二：操作便捷。原则三：驾驶充满乐趣。

针对这三点，大家心里应该都有几个基本款：MiniCooper、Smart、Beatles。这几辆车的共同点是针对年轻人，但每辆车有特点。于是大家心里都明白用户想要的大概是什么样的东西了。现在把比喻去掉，是否有一些对应的阅读产品可供对比和分析呢？在接下来的头脑风暴**议上，大家各抒己见，针对对应的产品原则提供参考的产品。最后发现Flipboard、Zite、Feedly、Digg 和微博（最有意思的是，微博出现在了这次的分析中）出现在参考列表中。看来通过比喻找到具象化的产品，的确可以详细地理解需求。于是在对比了几个产品之后，我们也逐渐清晰了想要的阅读功能切入点是什么：快速阅读和丰富的个性化内容。

三：功能与属性

既然已经找到了切入点，就好比找到了一根精灵绳索，可以把佛罗多拉到山顶，远眺前方正是旅途的终点——摩多。但我们依然没有拿出用户真正想要的东西。或许我们可以根据该切入点制作一些纸上原型进行用户调研，但正如之前的章节所说的，用户对于这些原型很有可能言行不一，起不到真正的效果，但我们可以通过用户对原型的描述来发现一些有趣的需求描述。

●我平时看资讯一般都喜欢有图**的。

●我平时玩微博，但是感觉其中的内容不是很好玩。

●功能能否强大一些。

●最好可以把这个资讯分享到微博等地方。

●我平时用很多软件，但是没有一个可以换肤，能不能出一个类似的功能，更保护眼睛。

●图**最好是高清的，打开可以连续看。

最后发现我被用户的一个小问题难住了：这个功能挺好的，但是我可以用这个来做什么呢？最后我解释道：你可以认为这是一本杂志，但是图很多，文字很少，而且杂志的内容都是你自己想要看的。这个时候，我才反应过来——这个产品本质上应该是做什么的，而产品经理应该打造一个什么样的产品：个性化的图**杂志。产品经理在进行需求分析的时候，常常**忽视一个小问题：如何向用户解释这个功能或者产品——用户可以拿来做什么？大部分时候，产品经理都**说：“我们这个产品有很多很多功能啊，可以换肤，可以提醒……”但实际上，用户只需要一句话解释就足够了：通过这个产品我可以做什么。正如上面用户在调研过程中提出的一些问题，其实都暗示了一个潜在的逻辑：我觉得它是一个什么样的功能，所以我可以做什么，想要什么。按照《探索需求》一书中的说明，温伯格认为对这些用户的描述都可以进行归类，而归类之后就可以更好地了解真实的需求是什么样的。

●明显的功能。

●隐藏的功能。

●装饰性的功能。

通过温伯格的方法对上面用户的反馈结果进行分类，则可以看到该方法的魅力。

产品A 方案：看资讯消息（明显）;想要分享到微博（装饰性）;图**最好是高清的（隐藏）;

产品B 方案：看资讯消息（明显）;想要分享到微博（隐藏）;图**最好是高清的（装饰性）;

产品C 方案：看资讯消息（隐藏）;想要分享到微博（装饰性）;图**最好是高清的（明显）;

产品D 方案：看资讯消息（隐藏）;想要分享到微博（明显）;图**最好是高清的（装饰性）;

产品E 方案：看资讯消息（装饰性）;想要分享到微博（隐藏）;图**最好是高清的（明显）;

产品F 方案：看资讯消息（装饰性）;想要分享到微博（明显）;图**最好是高清的（隐藏）;

通过这个方法似乎很简单地就看到了对应的产品特征和方向。A方案：注重看图文内容，尤其是文字资讯。B方案：注重分享资讯。C方案：注重看图及部分资讯。D方案：注重分享资讯。E方案：注重看图并分享。F方案：注重分享图**。

经过和其他产品经理讨论，最后这个阅读功能被定义为C 方案，所以在内容上，我偏重选择以图**为主体的资讯，满足用户看图的需求。于是这个功能就变成了阅读图**资讯的功能。

原文来自：爱财经网