>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

说服力：从场景化出发的用户价值

“按钮应该放在右边，这符合规范！”

“但是用户习惯在这边寻找按钮，放那边不够自然。”

“这个可以做啊，但是用户会觉得很好用。”

“有没有更好的方案，为什么一开始就要做那么复杂的操作呢？”

这样的讨论总是在产品经理评审需求的时候出现。大家目标都很一致：为了用户和产品的发展。但每个人的视角或有不同，这时，产品经理就应该具备上帝视角。什么是“上帝视角”？就是指产品经理不仅可以看到主流用户的需求，还可以看到其他伙伴各自的出发点，可以和他们进行良好沟通，推动产品实现。前文曾谈到为什么需要产品经理这个职位，我认为，产品经理在整个项目中不仅需要对需求负责，更要成为伙伴之间的“润滑剂”——可以和产品经理PK 需求，也能和开发人员探讨技术方案的实现，还可以和设计师聊一聊最新的设计风格，最关键的是产品经理需要了解用户。

但事实上，谁都觉得自己更了解用户，觉得自己本身作为一个用户没有被满足需求。这种情况时常出现在每次的评审中，这就要求产品经理可以做适当的沟通。前文出现的激烈争论并非是坏事，对于需求来说，可以越辩越明，但对于决策来说，却不符合呆伯特会议规则，无法说服其他伙伴同意产品经理的方案。还有一种可能的情况，即产品经理强势地要求开发工程师或者设计师按照自己的理解去进行，通过“项目时间”和“老板需求”来强迫他们“心甘情愿”地实现需求。这种“狐假虎威”的做法有时候有效，但对于产品开发来说，并不是一件好事。

在产品开发过程中，如果相关人员都没有被产品经理说服并同意产品经理的方案，就容易产生情绪——而情绪化的结果则是潜伏在产品开发过程中的各种风险都会不断出现。例如，开发工程师没有准确地理解需求，马马虎虎地完成功能，忽略了相关逻辑和细节实现，或者将这位产品经理的需求优先级放低，不断拖延……这种情况很常见。我私底下和一些工程师关系不错，有时候就会问他们，为什么有的需求完成度很低，有的时候需求bug 会特别多？他们会回答：“不想做或者有其他优先级的事情。如果充分理解了需求，我们也是很乐意去做的。但是平时产品经理都不和工程师一起玩，没有太多的革命友谊，所以大家都是公事公办，公事公办的后果就是先做其他事情。”

产品经理们，去施展你们的影响力吧！准确地阐述用户需求和价值，让伙伴们认可你的方案，这对于方案的实现有着重大的意义。用户需求时常被挑战的重要原因之一就是缺乏场景，大部分时候把自己当作用户并不能很好地反映客观情况，需求往往是伴随着场景而变化的。正如《探索需求》中所言：“除此之外，人们并不经常购买他们所需要的东西，却常常追求他们并不特别需要的东西，即使这种期望是短暂的。”

场景化需求才会产生“期望”，而不考虑场景提出的需求，虽然客观存在，却不一定是最想要和最需要被满足的。因此，产品经理在面临日常的方案挑战时，一定要关注将需求和场景结合起来，如果可以考虑用户的使用习惯和行为数据，则会更加具备说服力。

第一次做功能——从失败到成功

第一次做功能，对于许多产品经理来说，意义非凡。但对于一个入门者来说，第一次做功能往往需要人进行辅导。在腾讯内部，导师一般会安排刚入门的产品经理承担一些简单的需求，并会进行对应的指导。即便如此，看过本书前几章的产品经理可能依然会有点茫然：“虽然我都知道该怎么做了，但是如何开始第一步呢？”

许多人在产品分析时表现得头头是道，但一面临实践操作往往就发现，理论再靠谱，也难以应用到现实中来。记得我第一次跟进的需求是做一个阅读文章的功能。当时我画了思维导图，又用PPT 做了几个线框图做说明，还写了Word 版本的需求文档。但事实上，这几个东西都没有起到太大作用——因为每个产品经理做需求的第一步，不是动手去做，而是思考。

第一次做功能：产品设计阶段

三思而后行，这是我的个人经验。如果一个产品经理在接到任务之后，不假思索地就开始要各种资源，拉设计师和工程师讨论需求，肯定会受到各种挑战和不信任。任何一个需求都应该被拿来好好思考，清楚了整个流程，考虑了各种情况都会有哪些效果，产品经理的心里才会有底，才能有效地传达需求给其他人，才可以更快地推进需求实现。

当时，我接手了阅读文章的功能，于是马上找到设计师传达需求，就遇到了类似的问题。

产品经理：我这边有一个阅读文章的需求，你能帮忙看一下吗？

设计师：要阅读什么文章，是一个怎么样的功能？

产品经理：就类似Google Reader。

设计师：Google Reader 有哪几个页面，大概流程你清楚吗？这个功能的目标是什么？

产品经理：目标就是为了看文章，和Google Reader 一致就可以了。有很多的订阅文章，然后把文章排个版，加入微博分享、收藏这些功能。

设计师：是需要和Google Reader 一致吗？但是我依然不清楚阅读文章是要干什么，是为了收藏？

产品经理：……

很显然，产品经理对于需求的理解很模糊，没有具体的目标。虽然从入门开始就一直被灌输用户第一的理念，但是一接到需求就什么都忘记了。对于一个需求任务，如果产品经理未能很好地进行分析和界定，一开始就找对应的人员进行沟通，或者简单地把方案类比为其他产品，是一种很不专业的做法。

在进行了详尽地分析之后，我重新调整了需求功能点，通过思维导图展示了基本的需求说明（参见图3.4）：

图3.4 阅读产品的需求列表展示

粗略看起来，好像这个功能点覆盖得很全面，但让人很难理解，这个功能究竟是什么样的？看起来好像有一个目录页和一个全屏页，但页面内的效果该如何展示呢？目录页中的几个子选项——工具条、文章内容、预加载、翻页操作和区域操作——究竟是什么关系呢？

当时的我还没有意识到一个问题：思维导图并不适合说明需求，而更适合整理需求点——而整理需求点，是产品经理自己的作业，拿出来给工程师和设计师看，谁都会很困惑吧。于是，费尽了功夫的我获得了两个教训：

选择工具很重要。
罗列功能并不是需求文档。

经历了现实的打击之后，我重新调整了需求文档，将改用Word 模版的需求文档交付给对应的设计师。

第一次做功能：开发阶段

没过多久，交互设计师就输出了基本的交互稿，和我的想法是基本一致的，于是我开心地找工程师评审需求了。然后又遇到了第二个问题：那些轻描淡写的“自动刷新逻辑”、“页面排版逻辑”究竟是什么玩意？

工程师对此表示很遗憾，他们找遍了需求文档也不知道要怎么做，于是我给他们又进行了一次方案宣讲，并把对应的内容都写入了需求文档中。对于工程师来说，他们的目标就是准确地实现需求文档的要求。因此越清晰的要求，对于他们来说越省力。所以入门的产品经理需要关注这个案例：尽量用详尽的文字去描述每一个细节。

自动刷新逻辑

触发条件：当用户进入该页面，触发自动拉取最新数据的操作。

刷新展示：如果刷新成功，则页面展示最新内容（渐显效果）；如果刷新失败，则弹出“刷新失败，请稍后再试”的提示。

图片展示：未拉到图片时，需要展示一个占位图，在一分钟内进行多次图片拉取；如果图片拉取失败，则出现一个裂图；超过一分钟，允许用户手动点击占位图进行拉取图片的操作响应。

每篇文章的摘要显示及排版：××××××××

如果由于网络原因数据拉取失败，需要提示网络错误。

如果由于网络比较慢，则在一分钟内多次尝试拉数据；超过一分钟则等待用

户手动触发刷新操作。
……

以上只是展示了正常的逻辑，还有许多异常情况没有考虑，因此产品经理在描述需求时，切记把每一个细节都考虑到，尤其是异常情况。对于工程师来说，没有歧义且包含多种场景的需求描述，才是好的需求文档。“自动刷新”虽然是简简单单的四个字，却包含了有可能四百字都描述不完的细节。

第一次做功能：产品体验及改bug 阶段

只有真正参与过项目，产品经理才会了解人与人之间的沟通是多么重要。如果仅仅依靠需求文档，产品经理可能会发现开发工程师实现的功能和当初构想的功能会有许多差异。先不要担心，这些差异的存在是必然的，毕竟开发工程师不会读心术，而文字描述本身就容易出现歧义，这些差异都可以在体验阶段修改。

但这个事情从侧面反映了一个问题：需求文档还是不够细致。

灾难到这里就结束了吗？产品经理体验了产品之后交给测试工程师测试，这才是产品经理发现自己无知的时候呢！测试工程师会根据测试用例提出许多异常情况，而产品经理会发现，怎么这些场景我都没有考虑到！怎么会有如此多的bug！

先别着急，这些问题几乎在以后的产品开发过程中都会遇到。但这些“突如其来”的灾难的确容易让刚入门的产品经理手忙脚乱。有条理地去解决这些问题吧！产品经理之路还远着呢！

虽然第一次做产品需求就像个灾难，但后来回首这样的经历，可以发现一个有趣的事实：尽早失败，尽快改正，是产品经理成长的必经之路。而在我往后的产品经历中，往往都会想起这样一句话：把功能想透彻。对于产品经理来说，需要想清楚以下几个问题。

●Who：用户是谁，他们有哪些特征？
●What：这个功能具体是怎么样的，确认需要做哪几个功能？
●When：什么时候会使用？
●Where：使用场景是什么，功能页面之间是什么样的关系？
●How：用户如何正常使用对应的功能？

什么叫作“想透彻”？不如请各位产品经理先想一想如何用一句话准确地表达手头的需求，如果不需思考就能脱口而出，那说明你已经在思考，反之则需要扪心自问，自己是否已经了解该需求。如果想要检测自己是否想透彻了，还可以通过以下的几个问题进行自测：

●用户的需求是什么？
●这个需求可以分解成多少个小点？
●这些小点有哪些可以满足，哪些不需要满足？
●每个需求点可以通过什么样的功能去满足？
●这几个功能之间的关系是什么？
●整个方案有几个页面，和整个产品的关系是什么？
●功能的入口放在哪儿？
●用户发现了这个功能之后，他们会怎样使用？
●如果用户中断了操作，会出现什么提示？
●是否针对功能操作设置了保护机制？

这些只是最简单的一些问题，接下来我会结合自己做产品的经验及一些朋友的经历举出一些常见的问题，希望可以给刚入门的产品经理提供更多启示。

常见的问题案例

问题一：没有分解需求。

每个人对于需求的理解都有所不同。产品经理在描述需求的时候，需要尽可能详细和无歧义。例如：

●我想在坐电梯的时候可以获得资讯。
●我想在坐电梯的时候可以获得关于股票的消息。
●我想在坐电梯的时候可以了解到公司股票的实时走势图和实时价格。

各位觉得哪个描述更容易被理解，而且没有太多含糊的信息呢？不仅仅是描述容易出现问题，大部分时候需求描述有问题就是因为需求没有得到有效地分解。产品经理还需要注意对需求进行分解，像严谨的解构主义者，不放过任何一个概念。越是分解细致，越容易降低含糊信息出现的几率。

问题二：缺乏对用户的了解。

虽然在前面一直提到以用户为中心的产品理念，但因为某些原因，大部分时候产品经理不得不尽快明确需求，而等不及对用户进行了解。这种闭门造车的需求很容易产生一个可怕的后果：用户不买账。历经千辛万苦做完一个功能，产品经理没有功劳也有苦劳，但用户不买账。这就是缺乏对用户了解的后果，即使产品经理耗费大量资源和时间，但是做出了用户不喜欢的产品，那么一切都是在做无用功——即使产品经理自己觉得在做创新，用户不买账是因为他们视野不够，但不被用户接受就失去了产品的使用价值，不符合市场的供求机制。

问题三：急于推动方案，而非获得支持。

因为刚入门的产品经理往往缺乏自信和魄力，所以很难得到工程师和设计师的信任。但由于产品经理希望尽快推动功能进行开发，所以会不断地催促设计师和工程师动手做需求。

做需求本身是一个合作的过程，如果忽略沟通，不管需求的背景和目标，而仅仅是传达任务，那么对于设计师和工程师来说，这是一种缺乏合作精神的行为。虽然产品经理是无授权的领导，但在日常需求合作的过程中，产品经理更重要的角色是“润滑剂”，即沟通各方人员，确认他们都了解需求的背景和目标，保持信息一致。

得道者多助，失道者寡助。获得了设计师和工程师们的支持，对于产品经理来说是好事，因为这意味着你们在同一条船上，可以一起朝目标前进。而失去支持的产品经理，时常会遭遇到不合作，或者不认真的合作，这种情况下,需求在实现过程中常常会出现恶性循环，导致需求总是返工，每个人都不好受。

问题四：容易被忽悠。

不懂技术的产品经理时常会被忽悠。这种情况并非开发工程师不合作，而是他们在暗示对产品经理缺乏信任。

●你自己根本不清楚需求要怎么做。
●你根本不了解我的工作很多，总是打扰我。
●和你沟通很费力，忽悠你赶快走！

刚入门的产品经理缺乏经验，总是容易被各种术语忽悠——想要改变这种情况，那就要让工程师们信任你。我常用的方法可以分享给各位试一试。

●复杂的功能如果已经在其他应用上实现了，工程师们二话不说，拼了自尊也会去实现的。

●如果他们冒出大量术语，你可以试一试请教他们这些“牛逼哄哄”的术语都是什么意思，他们愿意介绍这些“牛逼哄哄”的术语。

●不管如何，确认他们对需求理解到位，必要的时候可以让他们重复表述一遍。

其实以上几个问题都非常容易出现，但大部分时候都可以归结为一个概念：含混性。什么是含混性？产品经理对用户的需求理解出现偏差，工程师对产品需求理解出现偏差，设计师对产品需求理解出现偏差，这些都是含混性的表现。

GameRes游资网 2015-08-23 08:41:55