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

2014-11-08 12:08:00

一:如何避免含混性出现

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

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

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

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

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

二：如何定义需求和功能

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

●用户想要……

●这体验太差了！

●需求不合理！

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

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

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

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

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

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

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

三：功能与属性

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

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

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

●功能能否强大一些。

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

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

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

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

●明显的功能。

●隐藏的功能。

●装饰性的功能。

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

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

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

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

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

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

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

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

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