需求实战：PM如何快速培养思维的严谨性？

2017-12-28 12:52:00

需求分析是产品经理的核心技能，网上有很多从需求收集到需求落地的理论，但是如何从实例出发剖析要点，如何保证自己的产品设计思路全面严谨，几乎没有可以参考的文章。在这里我总结下自己填坑后总结的经验，借此抛砖引玉~

为什么要加入这一步呢？一是为了展示需求分析的全流程的每一个步骤，另一个是产品要关注需求收集的用户角色和场景，这会跟需求分析直接产生联系。
竞品分析
假如你是从0开始的产品，可以最大减少试错成本的方法就是去看各类竞品，不过这种方法有一个很核心的要点就是产品经理要保持自己的判断力。
所以同样是产品经理去学习竞品，初级的可能是有什么抄什么，高级的知道什么功能最适合自己再抄过来，再优化下交互形式。还有个比较傻但是比较有效的办法是，就是统计所有竞品涉及的功能点，筛选出通用的。

用户反馈
用户反馈来自很多方面，比如测试、运营等，但是有时候他们是站在自己的角度去思考问题，所以产品经理很难做出判断，这时候可以运用一些需求利器，比如卡诺模型。
业务需求
B端业务方就是老大，很多时候客户可能是基于某个地方想做这个功能。客户觉得某个字段里的字段值排序不符合阅读习惯，就会提出自定义排序字段值的功能，这时我们都会把客户提出问题看的报表要过来，至于为什么，留个悬念。接下来，我们就这个需求进行示例来进行需求分析。

需求背景

角色：决策层
场景：某次客户表明在看报表时更关心“是否咨询”的“是”多于“否”。
功能：可以对当前图表某个字段设置字段值排序功能，将字段值“是”排在字段值“否”前面。

需求拓展

通过需求分析我们大概可以构思出满足用户需求的交互界面，但是这样就够了吗？因为用户这次基于功能点的某一方面提出需求，你满足了，下次基于功能点的另一方面提出需求，你就懵逼了，上次设计界面的交互形式根本无法容纳这次的需求，这时候你又要完全改变交互界面和交互形式。
所以虽然都只是做一个功能，有一做一的产品和由一想到二三的产品是完全不一样的境界，思考全面的产品会知道未来产品发展形态，从而在产品设计中留下拓展性，避免下次加功能点需要改造界面甚至系统。
那很多产品就担心了，要是我经验不足真的想不到呢？那就可以去看竞品了。业内很多都是传产品经理就是抄竞品的，但是这并不是一件丢脸的事，有东西可以借鉴，你可以避开前人踩的坑（竞品公司砸了那么多钱，请了那么多大牛，迭代那么多次帮你踩的坑。）但是抄要建立在这个产品有足够的判断力的基础上，不要为了抄袭而抄袭，在下面一点就会感受到。
基于自定义排序的功能，笔者如饥似渴地去看了一堆竞品。

BDP个人版-数据表级别排序

BDP个人版-图表级别排序

大数据魔镜-SQL执行错误

数据观-图表级别排序
不出所料，还是BDP的功能比较全面，其他的有这个功能的竞品寥寥无几，有这个功能的竞品其中一个还有问题……不过大部分的产品经理到了抄完竞品这一步就结束了，所以这也是产品经理经常被人指责就是抄竞品的原因，要让自己的思维更进一步的方法是：
归纳竞品规则，思考竞品这么做的原因
从竞品中了解到自定义排序分为数据表级别排序和图表级别排序。

数据表级别排序：排序规则对用到这份数据表的图表都生效。
图表级别排序：排序规则只对当前设置规则的图表生效。

为什么会有这两种呢？因为一份数据表可能用于做多张适应不同主题的图表。所以用户可能对数据表进行统一排序来规
范所有图表的字段值排序规则，也可能是某张图表的特殊需求而暂时性改变该图表的字段值排序规则。
根据业务场景，优化竞品的交互体验
很多人都觉得参考完竞品就完事了，没有去想竞品的交互体验是不是可以优化，比如本来是三步操作简化成一步就好了，页面是否可以更友好等等。像是对于参考的bdp交互形式，我觉得已经很完美了，不过之前专门总结过表单设计，所以我稍微改动了下按钮的位置。
根据自己的思考，能对竞品有所补充
最后一步也是比较难的，当你在设计一个小产品，参考的是BAT的产品时，你会觉得自己没什么可以补充的……就像我做数据分析类产品，每次看别人家的产品，我都觉得竞品的场景覆盖已经很全面了。
但是你要相信，没有什么是绝对完美的，等你有一天你发现一个他们没考虑到的点，你的成就感也是double的。基于这个点笔者在“需求挖掘”中进行深入阐述。

需求挖掘

每个产品中，都有一个特殊要考虑的要素，像是BI中字段类型和表的结构等要素对产品设计会产生影响。

在BI里面字段类型分为文本字段、数值字段、时间字段，对于相同的功能，字段类型不同也会展现不同的界面。比如同样是筛选器功能。
不同字段类型的字段筛选是截然不同的，文本类型的筛选包含文字的模糊匹配，数值类型则是包含具体数值筛选，时间类型需要调用时间相关的设置。

文本类型

数值类型

时间类型
文本类型中还要分出普通结构和层级结构，为什么文本类型中特意划分出这两大类？因为普通结构中的各字段没有关联的，层级结构中的字段与它的上一层级和下一层级都会有关联，比如省份字段上一层级是国家字段，下一层级是地区字段。

普通结构

层级结构

行政区字段-自定义排序
像这个需求还有个要考虑的点，因为字段类型的缘故，自定义排序是分为全局排序和局部排序，普通结构是要全局排序，层级结构则需要局部排序，比如带层级结构的行政区字段。
杭州只有与温州、湖州这些同省字段值互换排序位置才有意义，如果仅仅是设计的那样（全局排序），将杭州移到福州上面，他们分别归属于不同省时，这样的排序是毫无意义的。因此这类字段必须建立在上一层级的基础上进行自定义排序的，即只能局部排的。
行政字段只是层级结构中的一种，可能你说带行政区字段的数据并不是很常见，并不是的，可以看看下列数据，就可以联想很多相似场景了。二级分类是要在一级分类的前提下进行自定义排序，比如营养成分只需要与一级分类是营养保健下的二级分类的各成员（保健器械和营养健康）进行排序。

层级结构

需求规划

由此我们可以看到这个需求其实是分为：

数据表级别，只能全局排序。
图表级别，其中分为全局排序和局部排序。

页面布局
Q1：为什么数据表级别不用分为全局排序和局部排序？
因为绿色框中摆放多个字段才可以建立字段的层级结构，可以进行局部排序。而黄色区域的字段都是独立的，无法与其他字段建立层级结构，所以只有全局排序。
Q2：为什么不是如下排序？

全局排序，其中分为数据表级别排序和图表级别排序。
局部排序，只能图表级别排序。

因为是当初我们页面布局的属性决定的，图表设计里左边的字段列表都是代表在数据集中永久加一个字段，对所有引用该数据表的图表都会产生相同设置。中间的代表只在对当前图表的设置，另一个图表可以用其他的设置。所以建立在原有系统结构上，我们按第一种分类进行划分功能属性。
Q3：同时存在数据表级别排序和图表级别排序怎么处理？
图表级别的排序优先级大于数据表级别排序，因为图表级别相当于个性化定制排序，数据表级别相同于通用排序。
因为是B端产品，所以我们比较好分析功能优先级。在开发时间有限的情况下，先满足客户提出需求的这张报表即可，在后期迭代时再完善其他功能，并要给后续功能留有拓展性。还记得为什么要分析用户角色和场景、以及展示图表吗？

因为用户角色是决策层，仅对自己查看的图表有需求，而不是对数据表进行规范管理的执行层。所以确定先上“图表级别排序”。
该张图表没涉及层级结构，所以先上“图表级别-全局排序”，再上“图表级别-局部排序”。
最后业务量较大，需要自定义排序的图表需求增多时，再上“数据表级别排序”。
所以迭代顺序是：1.图表级别-全局排序；2.图表级别-全局排序；3.数据表级别排序
需求设计
根据确定的功能进行交互，要给将来迭代的功能留下入口。

图表设计
一期：图表级别-全局排序。在绿色区域点击“自定义排序”弹出设置框。

一期：图表级别-全局排序
二期：图表级别-全局排序。一期的功能入口不变，只需要在弹出框上加上可切换的标签。

二期：图表级别-全局排序

二期：图表级别-局部排序
三期：数据表级别排序。二期的功能入口不变，只需要在黄色区域增加功能入口，弹出该设置框。

三期：数据表级别排序
在这里展示三期完成后的自定义排序交互稿。
需求说明
以三期完成后的完整交互稿，书写规范。

图表级别-全局排序

图表级别-局部排序

数据表级别排序
需求验收
产品将产品方案交付后，需要跟进需求的落地，是否产出物符合自己的设计。
操作：将“营养成分”移到“保健器械”前面。

排序前

排序后：数据表级别排序

排序后：图表级别-全局排序

排序后：图表级别-局部排序
question：为什么图表级别-全局排序在排序后很多已合并单元格会被拆开，你是不是有一丝错乱？
总结
应用场景丰富性
数据的不同应用场景决定了很多功能，比如自定义排序其实涉及这么多种应用场景。设身处地地去思考各个应用场景，这样你的思维能力才会有所进步。
功能拓展性
很多时候你做一个功能，要想到这个功能最完善的时候是什么形态的。这样，即时你现在上一个简单的版本，下次迭代也不会对系统有太大的改造。
思考全面性
在产品设计中，有意识地锻炼自身的逻辑缜密性。我经常忘记新增或修改的功能对其他模块产生的影响，也不断地根据产品自查清单一遍遍地提醒自己，虽然我现在还是有时候会忘记，但是至少我比昨天的自己更好了。
建议
多多跟开发沟通学习
有技术背景的人逻辑能力比较强，所以对于开发的建议，产品人员应该大力鼓励（如果是不负责的开发，完全可以说什么做什么，而不会去提还缺什么）。一个产品永远不可能把所有的细节考虑到，只有这个团队所有人从自己的岗位角度思考问题，才会尽量避免错误，而产品人员不能太过强势去扼杀这种良性循环的可能性。
倒推竞品产品文档
很多人会去问怎么学习，看什么资料快速了解产品，我的建议是去看优秀竞品的帮助文档，不断去玩他们的产品，然后倒推他们的产品文档，这样你会发现你进步的特别快。在这里推荐一篇文章倒推“饿了么”App产品需求文档
完善知识体系
定期的总结，可以帮助你建立自己的知识体系，不断地补充自己的技能短板，在这里推荐产品知识体系框架
参考资料
B端产品需求分析的实践与思考
需求分析：它从哪里来，到哪里去?
实战总结：如何将需求转化为PRD？
PS：这里是以bdp做示范来加功能，所以根据bdp的产品特点（比如页面布局的属性）和交互形式而进行交互设计。不同产品要加上这个功能肯定入口和交互形式也不同，本文仅供参考，有些地方我还没细讲，还是有很多门道的，或许你在深入思考后会发现另一片深渊···

作者：安琪Angela，公众号：idatadesign。互联网数据行业PM&UX，参与过数据中心，商业智能和数据分析平台等产品设计。关注大数据、人工智能和互联网金融。欢迎大家一起交流~