從0開始學產品策劃⑦：通過人物角色了解用戶期望

簡體傳統

　　通过人物角色了解用户期望

　　无独有偶，不仅仅是《生活大爆炸》中人物角色个性鲜明，宁财神的《龙门镖局》中的人物亦有类似的特征。

陆三金：有点面但是爱说道理。
盛秋月：冲动喜欢，武力解决一切的女性。
白敬祺：爱面子的刚性男。
吕青橙：武功好但是比较单纯的女性。
温良恭：有很多感情故事的男性。
邱缨络：爱财花痴的女医生。
蔡八斗：想赚钱的男厨子。

　　大部分时候剧情的推动往往是依据每个人的个性安排矛盾和冲突的。比如，一旦出了事情，蔡八斗永远是第一个说“出事了！”的人；温良恭则永远与前女友纠结不清。这些都是剧本的创作手法，但我认为，也是互联网产品非常值得学习的地方。

　　在日常互联网产品的使用过程中，产品经理与用户之间的距离不能说很近，虽然两者依靠产品进行连接，但大部分时候用户不会表达许多想法。因为对于产品经理来说，抱怨功能缺失的用户A 和吐槽界面设计的用户B 可能都是模模糊糊的两个人，似乎属于用户的范畴，但实际上两个人可能在现实生活之中非常不一致，情境也各有各的特点，但这些细节都是产品经理很难去获得的信息。

　　因此，在一开始产品经理通过用户调研方法建立了核心人物角色之后，可以按照电视剧的模式描述每个人物的特点，然后根据特点进行头脑风暴，讨论这几个核心用户在使用产品的过程中会遇到哪些问题——甚至是会吐槽什么类型的话。我时常看用户反馈，会发现一些很有意思的句型。

无理由抱怨型：垃圾，真是垃圾！！
有理由的反馈和建议：如果有个xx功能就好了。
恨铁不成钢：唉，上次反馈的那个问题，这个版本还是会出现……
语言侮辱和人身攻击：傻X的xxx和xxx公司！

　　在我刚入职做产品经理的时候，会和用户在QQ 群里讨论产品问题，甚至有些热心的用户时常会加好友和我聊产品问题。我发现用户与用户之间的确有着不同的背景和期望，有许多类型的用户。在观察了各大安卓市场、电商网站的用户反馈评论之后，更坚定了这一观点。

　　创立核心人物角色的方法在前面已经有所阐述，相信各位产品经理都希望去试一试这个方法。不过，我建议产品经理一定要多和用户进行沟通。和用户沟通不一定必须是关于产品体验的，可以适当发散一些，聊一聊生活等问题，可以通过这些信息更全面地了解用户，让整个人物角色更加饱满。正如谢尔顿和莱纳德都是技术宅，但后者更加了解日常社交的方法；邱缨络和蔡八斗都爱钱，但一个想要通过傍大款获得，一个希望自力更生艰苦奋斗获得。

　　把控用户体验是每个产品经理都头疼的问题，但这也是锻炼产品经理能力的阶段。尤其是刚入门的产品经理在今后遇到的项目都有可能会出现各种用户体验问题。别担心，方法可以慢慢摸索，关键是始终记得那句话：以用户为中心。这句话也是产品经理在项目前期和探索需求阶段需要特别关注的，别为了做功能而做功能。

　　目标至上——细节和ROI 的故事

　　敏捷迭代和人月神话

　　说完了用户体验，让我们回到项目的真实情况。等产品经理写完文档，以为一切都正常进行的时候，发现自己突然陷入一种忙乱的状态——相关的人一波又一波地过来找你，各种措手不及的事情让你原本心情很好的早晨变成了一团糟的开端。别太担心这种情况，每个项目启动后都很容易遇到这样的情况。这不仅仅是含混性的问题，更因为大部分时候项目规划都是在理想情况下进行的，而现实是这些理想情况都有可能背道而驰，出现一些意外。

　　我有时候会和其他产品经理讨论这种现象：究竟是什么原因使得每个项目在过程中会出现这样的情形？我的一个朋友说，首先你的预期就不应该是整个项目都按照理想状态进行，这显然是不现实的。对于一个项目来说，没开始做之前永远不知道会遇到什么问题。所以在项目进行中，应该带着问题不断前进，推动问题解决和项目进度，这才是产品经理需要关注的事情。另一个产品经理则提到，很多时候产品经理无法控制所有的细节，而这些细节会随着项目而产生。

　　那么，如何将这样的意外控制在有限的范围呢？互联网公司现在流行讲敏捷迭代，实际上有多少公司真正做到了敏捷？假设百米跑是项目经理常说的敏捷迭代，那么跨栏跑则是真实状态下的项目：既要敏捷，又要解决难题。这才是大部分项目的真相，也是产品经理不得不面对的真相。

　　如果把写作本书看成是一个个人项目，我深刻地理解了敏捷迭代是多么重要。因为还需要进行日常的工作，所以我每天都是利用下班之后的时间进行写作，尤其是周末时间。按照理想状态，我应该每天写2000 字左右。但事实上，我大部分的写作时间都来自周末。不如来看看我的“项目计划”：

工作日每天输出2000字，每个月争取输出40000字以上，周末用来修改文字和查找案例。
每个月输出一章内容让朋友提一提意见。看起来似乎挺可行的，每天2000 字对于我来说不算太难——毕竟我日常也有写博客的习惯；文字质量我对自己有信心，因为平时写的文章都有一些业内的朋友关注，他们觉得挺不错的。那么，我就把这种理想状态的计划看成是我后续写作的原则。但事实呢？
工作日基本每天的输出都达不到2000字，甚至大部分时候都没有输出；而周末因为在星巴克待两个下午，可以勉强完成10000字；几乎没有修改时间。
每个月输出的章节基本都欠缺一些关键内容，时常会出现“待补充”的字样，不忍心让朋友们阅读。这就是写作项目中的大风险——我很有可能无法保证在约定时间内写出对应的字数和有观点有价值的内容。按照计划，我现在应该每天轻轻松松地坐在电脑前，敲出2000 字，然后起身投入到生活中。但自从写作之后，我发现自己大量的时间花费在了写作之外：
加班。最直接的因素，常常会影响到下班后的状态。
社交活动。人天生就是社交动物。
呆坐在电脑前。我时常打开文本编辑器，然后一脸茫然地看着发光的显示屏，从亮到暗到关闭，然后一敲回车键，屏幕从关闭到亮。我在电脑前想：为什么缪斯女神总喜欢在我坐下的时候就离我而去呢？
排解没有灵感的痛苦，进行“劳逸结合”的活动。大部分呆坐着的时间非常痛苦。因此，我常常选择起来运动一下，或者是看看微博、刷刷豆瓣……然后就陷入了现代人常有的拖延症状态，将时间花费在刷各种资讯上。
日常的运动健身。为了保持高强度的大脑活动，我从写作开始就保持长跑，希望向村上春树的《当我跑步时，我谈些什么》一书致敬，并希望像他一样在跑步中感悟到一些思路，通过释放压力更好地获取灵感。还有一些日常的零零碎碎的事情，于是我的写作计划基本破产。按照阿瑟•布洛赫在《墨菲定律》一书中的阐述，我显然被墨菲定律缠身：事情如果有变坏的可能，不管这种可能性有多小，它总会发生（Anything that can go wrong will gowrong）。于是在一个月之后，我推倒了这个计划，重新写了一份我能接受的计划：
周末写作10000字，工作日写1000字。完成一章之后再进行编辑工作。
保证内容都可以连贯阅读，然后就给朋友们看最新章节。

　　或许有人会说这是朝三暮四的故事——不，我想称之为项目管理。我曾经戏谑地和我的朋友说，我这个才叫敏捷开发：先做再调整计划，小步快跑，随时根据自己的现状进行调整，但不影响整个项目周期，甚至还能取得更好的效果。

　　事实上，敏捷迭代并非只是简单的一套方法论，更像是一种理念，贯穿整个项目的始终。

　　Scrum 是一种迭代式增量软件开发过程，通常用于敏捷软件开发。腾讯目前在使用的项目迭代应该就是基于这种迭代方法的。最具标志性的产品就是内部使用的TAPD 系统。通过这个系统，项目相关人员可以很方便地看到各自想要的信息：需求单、开发进度、bug 单等。对于项目经理来说，通过TAPD 可以有效地统计整个项目迭代周期中出现的情况，并及时发现问题。

　　除此之外，腾讯内部流行在开发中后期举行定期的例会，比如每天上班之后的晨会，会上需要每个人阐述三个问题：

昨天做了什么？
今天打算做什么？
完成昨天的任务时遇到了什么样的困难，需要什么样的支持？

　　通过简单的信息同步之后，负责人就可以尽快联系对应的人员，沟通对应的难题。一般来说，这些问题大部分都是信息不同步造成的，产品经理通过参加这样的简短会议，可以快速找到问题要害，及时召集对应的人员给予支持。敏捷还体现在整个项目迭代中，会有许多参与角色，比如产品经理、开发工程师、测试工程师等。每个人有每个人的迭代阶段，比如：

需求收集阶段。
需求设计阶段/需求输出阶段。
开发技术预研及框架构建。
功能开发阶段。
功能测试阶段。
系统测试阶段。

　　上述粗略的阶段划分主要是想说明，每个阶段其实都不是堆栈式的，而是当有了部分输出之后，下一个阶段就会马上同步进行，通过多次迭代实现整个版本需求。

　　通过持续集成等环境，版本质量在不断提高。与此同时，测试人员在进行测试，开发人员在进行开发，产品经理则可以通过持续集成的版本，进行体验优化。当整个项目接近尾声时，则可以通过灰度测试的方式论证用户对于新产品功能的认可度。

　　这就是腾讯比较有特色的敏捷迭代方式，对于一些小团队也非常受用。在我写作的过程中，虽然只有我一个角色，但依然需要给自己不断规划迭代周期，并按照任务数进行排期实现。虽然说敏捷迭代相比传统的瀑布式开发会更加没有节奏感，但实际上，敏捷也需要良好的规划时间和任务，不然一环连一环可能引起更多的问题。

　　对于产品经理来说，了解基本的敏捷迭代方法非常有必要。大部分时候，产品经理的执行力其实就在于如何规划功能并引导相关成员把功能实现。敏捷迭代方法是一种成本低、速度快的方式，也是提高执行力的方法之一。通过细分任务，每天定时汇报，产品经理及时体验，可以在短时间内把功能做得比较完善。

　　在敏捷方法中，对于产品经理最关键的启示就是：目标导向。在日常需求讨论的过程中，时常会遇到这样一种情况：

　　这个功能符合用户场景，而且做得很炫。

　　产品经理时常会遇上这样一种情况：用户提出了一个反馈，产品经理需要考虑如何去满足；或者是有一个功能可以做得很炫，但对用户不一定有太大的价值。

　　按照常规，这些需求理所应当地被剔除，或者是延缓实现。但有一种情况就很尴尬：有价值但成本较高的功能。在《用户故事与敏捷方法》一书中展示了一个排列优先级的方法——莫斯科（MoSCoW）规则：

必须有（Must have）
应该有（Should have）
可以有（Could have）
这次不会有（Won’t have this time）

　　大部分尴尬的情况都源自于“可以有”的需求。这种需求优先级不高也不低，对于用户来说，是具有使用价值的，但在项目中并非是一个最紧急的需求，时常会被前两个需求挤掉。毕竟项目的周期和成本是关键因素，任何时候资源都需要用在“刀刃上”。因此会出现这样一种情况：每一个项目迭代周期都会有许多的高优先级需求（Must have 和Should have），于是每一期的Feature List 上都会有一些“可以有”的需求排不上队，一期又一期都没有进入迭代计划。

　　而随着项目迭代几次之后，越来越多的新功能转移了用户的注意，之前提到的“可以有”的功能只剩下零星的几个用户在反馈了。项目依然在前进，而新功能依然层出不穷，需求变更依然不停地被加塞到项目中。慢慢地，那些“可以有”的功能被边缘化了。直到有一天，产品经理发现用户重新关注起了这个功能。

　　这个时候应该怎么办？做还是不做，这不是一个简简单单的需求问题，而是涉及整个项目的问题。我第一次遇到这种情况时，急急忙忙地找交互人员讨论交互方案，找开发人员确认开发难度及工作量，找测试人员沟通测试工作量，然后还需要和项目经理沟通协调。当得知工作量比较大的时候，这个需求似乎又需要延期了。这类“搭车”需求并非是偶然出现，大部分时候是项目的常客。但作为产品经理，是否应该重新思考一下：这个需求之所以没有实现，是真的因为成本，还是因为其他原因？产品的目标是什么，我们为什么要做这些功能？无独有偶，在每个产品团队内部可能都会有这样的讨论：xxx 功能是否可以加上？往往最后大家的争论都变成了这样的对话：

这对用户来说是有场景有需求需要被满足的！
但是这对产品来说价值有那么大吗？
是否是所有的需求都需要被满足，还是产品经理应该只关注有价值的需求？有的时候，产品经理时常忘记两件事情：
用户的需求是源源不断的，而且有优先级。
每个版本、每个功能都有对应的目标。

　　在项目进展过程中，时常出现产品经理在讨论细节问题的情况，但很多细节的讨论纯属没有目的的扯皮——例如按钮放左边还是放右边比较符合规范和用户习惯。这个事情可以直接做一个内部调研或者运用灰度测试的机会测试用户的选择，而没有必要争论各自的观点，变成了两个人为了维护自己的立场进行的争辩——况且他们拥有的是同一个目标。目标很重要。

　　除了日常时常出现的争论，项目时常出现“可以有”的需求往往还有另一个原因：优先级问题。优先级意味着有一个目标，而所有的需求都应该向这个目标看齐，然后一个一个进行排队。优先级是如何安排的呢？按照A～Z 的顺序排列吗？或者是根据产品经理喜好进行排列吗？这个问题并没有准确的答案，如果需要有一个答案，那就是：权衡用户的需求和产品的价值。

　　事实上我们会发现，用户每天都大声嚷嚷的需求在经历了一个迭代之后，用户并没有欣喜：提供这个“缺失”的功能是应该的。如果这个功能还有bug，那么第二天迎接你的又将是一大波反馈。反而，产品推出了一个用户未曾想到的功能，即使问题多多，用户依然会喜欢并忍受一些缺陷。这真的是一个很有趣的现象。

　　既然如此，产品经理应该如何抉择呢？把主要精力投入到新功能开发，还是修复bug？相信每个人都有自己的答案，但我的答案是选择做新功能。产品需要前进，需要有前进的动力。

　　正是因为用户预期与产品功能有着微妙的关系，所以“可以有”的需求大部分时候都隐隐于市，被新功能遮盖了。项目的目标一开始就确立，主打新功能的开发，减少成本在修修补补的工作上，除非是特别紧急的工作。在上一章曾谈到把控用户期望，这也是一种方式，即通过新功能的方式推动产品前进。让用户感到“意外之喜”。不过往往这样进行得越久，用户的期望会越高，而老版本的问题依然存在，最后还是会爆发。所以这并非是一个可行之策。

　　正是考虑到种种现状，我们才说产品的目标尤为重要——我们有了产品原则，有了优先级，就应该朝着目标前进。用户的需求不外乎三种：