需求的归类与拆分要约定俗成还得实事求是

　　获取需求的时候，基本上都是很零散的，散到总觉得每个都是独立的一条。大家讨论起来也很难按照统一的逻辑思考，因此产品经理更需要具备对需求的汇总的技能，这项技能是需要反复磨练熟能生巧，尤其是每次遇到都的倍加细心，其中的不确定性肯定都会影响到前后端开发和UI的工作量。因为标准不一，基本上多数人都遵循较为传统的方法，一方面是确保多个岗位的认知统一，另一方面是节省后续优化时的工作量。
　　上一期说到需求要区分功能需求、交互需求、数据埋点，本期主要说的只是功能需求。以前端产品举例，选取最普遍的方案，仅讨论功能需求，暂不涉及到交互和后台接口。
　　从应用类产品着手，基本上分为：用户体系、推荐和内容展示、支付体系、设置，这几个大框逐一说明一下。
　　一、用户体系
　　用户体系并不只是用户昵称、用户名、密码这么简单的几项，它涉及到关于账号的方方面面。用户体系包括账号基本信息、社交体系、等级体系、任务体系。
　　账号基本信息：包括用户ID、昵称、密码、第三方账号、手机、邮箱，除了互联网信息外还包括性别、性向、年龄、地址等等，这些资料是否需要都根据产品的基础需求有关。如果是电商类软件，那用户的通讯方式就很重要，新闻资讯客户端，那用户的第三方账号和自然属性就更重要，更利于推荐体系中用户画像的建立。
　　社交体系是必然绑定在用户体系下的，其中包括：关注、好友、消息、收藏、评论评星、转发分享等等，在社交软件中，这个体系将单独拿出来做为一级项目，但在普通应用类产品中，社交体系的高度往往远低于推荐和内容，所以是否搭建社交体系也是产品中重要的决定。这个体系搭建起来相当复杂，因为涉及到用户与用户，用户与内容之间的信息交换，而且在时效和审核上都有严格的要求，所以建与不建，建成什么样都要产品经理谨慎核定。
　　用户等级体系是为了拉拢新增用户，培养活跃用户，维护深度用户，激活沉默用户的必要功能，用户的等级会像游戏中一样，级别越高拥有的能力越大，比如打折、免费、优惠甚至其他想不到的福利，在业内用户等级体系做得不错的有很多，比如天猫、微博、迅雷、网易新闻等等。这里要说明用户体系不论数值还是内容还是展现形式都是可以直接拿来借鉴的，但用户是否有感知，就要看等级体系与基础功能是否紧密，运营是否高效利用起来了。
　　与等级体系紧密相连的就是任务体系，是大家耳熟能详的做任务拿积分，拿到积分去升级的传统流程，任务体系的建设离不开运营对软件所有功能的解读，也跟大家的KPI紧密相连，要提升用户开机次数、在线时长、浏览量、分享、评论等等都会在任务体系里进行设定，但是否一定要有任务体系才能提高用户活跃度这点就没有必然联系，腾讯的任务体系一直都是大家模仿的对象，但真的有多少用户注意过每天的任务，估计是少数中的少数。
　　二、推荐体系与内容展示
　　这两个真不能分开谈，因为每一个推荐都必将引导到内容，没有独立显示的推荐，作为内容，都是有机会被推荐的，不可能存在肯定不被推荐的内容。推荐体系含有推荐位、搜索、广告三种基本模式，内容展示则是文本、图文、视频和融合模块。
　　推荐位：推荐位多种多样，除了我们经常看到的推荐页面内的BANNER推荐和每日推荐以外，还有限免、火爆等推荐专区。包括浏览时的相关推荐，延伸阅读，好友正在看，喜欢这个的人也喜欢等等模块，全都属于推荐位。在推荐位上有些是算法给予推荐，有些是运营人员手工配置，基本上能随随便便看到的都是推荐位。
　　搜索的推荐属性是很强烈的，只是用户以为是自己搜索出来的而已，其实基本上所有的搜索结果都是平台设定好的参数，哪个显示在前哪个显示再后也都是搜索的规则定义的，在搜索之前的热词提示，搜索之后的排序，搜索不到后的相关结果其实都是推荐位的设置方式。形成热门话题或热门商品，让冷僻的新生事物见天日，除了用显著的推荐位以外，基本上都是靠搜索来偷偷完成的
　　广告这个其实不用多说，只是形式上有些是让用户知道自己看的是广告，有些是靠软文、评测、互喷等方式形成话题让用户误以为不是广告。至于采取哪种方式更有效是运营的工作，产品经理需要设定准确广告的位置和表现形态即可。
　　文本、图文和视频的现实方法基本上不用过多阐述，大家用的手段也都大同小异，在这里产品经理需要定义的功能是默认文本及文本展开的模式，图文显示时的附属功能，视频播放的规则等等，至于字体字号、图片效果、视频手势都是交互需求，而非功能需求。
　　融合模块是指隶属于其他体系的功能是否需要出现在内容展示相关页面中，比如评论、分享、关注、收藏等等，如果要添加选择加哪些，加到什么程度。显示的方式（如审核前仅对自己显示）、缓存读取方式（前端缓存后台同步，无缓存即时同步，读取缓存，读取接口数据）都需要备注中简要说明一下。
　　三、支付体系
　　这是一个看似简单，却无比纠结的体系设定，从用户看来只是输入密码甚至连密码都不用输入，付了钱或者压根不用付钱，就完成了一次交易，但在产品经理方面就要考虑到中间很多层次。
　　用户在什么地方进行付款，有多少付款动作的触点，有那些位置提示付款或金额。
　　用户选择什么方式进行支付，余额、支付宝、银联、话费、积分有多少种支付方式就有多少选择，排列顺序怎样，如何提示用户。
　　每个不同的支付渠道都需要有符合规范的流程，但整体来看差别不能太大，尽可能统一。
　　支付成功，支付不成功，支付成功后没到账，各种支付后的情况如何提示，如何跳转。
　　支付到一半用户跳出怎么办？用户误操作怎么办？
　　支付账号的安全如何保证，提高用户支付效率的同时还要考虑到心理上的接受度。
　　如何应对一切关于支付的投诉，可能发生的极端情况都要有相对的应急方案。
　　四、设置
　　这里的设置不仅仅是软件本身的设置，还包括用户资料公开设置、社交级别的设置、浏览页面的UI设置、使用习惯的设置
　　软件本身的设置在完善的软件中都很近似，也很全面，比如检测版本，关于，推荐给好友等等。
　　社交级别设置中好友级别，指定显示，分组，各类信息开放性都是设置中需要考虑到的，社交级别最麻烦的事情就是把偷偷发东西显示给了不该看的人。
　　浏览页面中的UI设置，这点看来像是交互需求，但哪些能自定义，哪些是选项，哪些必须默认，都是产品经理决定的，至于选择什么颜色、字体、比例则是交互上的需求。
　　使用习惯这个范围过于笼统，但基本上会都是左右手，翻页习惯，进度快慢，护眼模式等等。这些都是设置中的小玩意儿，做好了是小亮点，做不好不如压根没有。
　　需求的组合拆分根据产品的不同相当灵活，产品经理若能将表格写得富有条理和逻辑性，会大大提高团队的工作效率和协调性，并且这个表格做得好对测试人员出测试用例也有极佳的协助作用。