作为提需求的业务方，如果对产品理解更深，则会和产品经理配合的更好，借力产品实现目标。
这是一篇产品经理自我审视、自我施压向着更高要求出发的文章。
如果是优秀且有责任的产品经理，他们会主动贴近业务，了解业务价值、目标和策略，在此基础挖掘需求，帮助业务提效增长。但实际情况下，并不是所有的产品经理都有这样的意识，或者有意识但能力不够。
作为提需求的业务方，如果对产品理解更深，则会和产品经理配合的更好，借力产品实现目标。一方面在业务过程中遇到困难时会思考是否可以产品化解决。一方面是面对“不靠谱”产品经理提供的不客观的评估方案时，可以有一个衡量的尺度。本篇就业务视角去看，如何才能更好的理解产品。
一、什么样的问题适合用产品来解决？
互联网产品或系统，核心价值就是利用计算机的计算能力以及互联网的连接能力来解决业务过程的低效问题。细盘下来，遇到如下3类情况是，可以考虑产品化来解决：
1. 重复劳动
重复劳动背后一定是固定的不变的流程，且被反复执行，这是最适合产品化来解决的。
最简单的例子就是工业生产线，生产可口可乐都是同样的步骤不停重复，机器代替人工可以提升准确性的同时可以大幅度提升效率。
又比如另外的例子是：每天早晨要看业务指标完成情况，每天都要导出相同的源数据、通过excel做透视图、生成曲线图。这种也可以数据看板产品来解决这一重复工作。
2. 空间障碍
互联网可以解决那些不依赖空间，但又因空间限制导致低效的事情。
比如视频通话功能在春节拜年没法一一拜访好友时，可以解决三五好友通过视频群聊聚一起寒暄唠嗑。
又比如合同签约，原来需要书面签好寄给对方，受制于快递文件的物理空间限制，收发合同效率低。电子合同在线签约产品的出现，就可以让合同传递瞬间完成，省时省力。
3. 精确度
用人做的事情具有创造性，但精确性并不能完全保障，而且因人而异。财务系统的出现就可以在精准精确上完全替代人用计算器加减乘除的工作。
4. 高频刚需
互联网及计算机另一个核心价值就是通过规模效应降低边际成本。当一个系统、一个功能有很多人用，且很高频的用时，产品系统就会有较高的投入产出价值。
滴滴打车、美团外卖之所以快爆发、高估值的背后就是打进了高频和刚需。但如果是1个月只有你1个人要做1-2次供应商的成长分析，就没多大必要做数据看板产品。这种不高频受众小的需求在资源部是特别充裕时还是通过导出数据，单次单独分析来的划算。
当业务上遇到瓶颈困难时，或发现有重复工作的倾向时，可以看看是否符合上述4点条件，如果有1条满足的话，就可以考虑产品化。拉上产品经理一起，阐述清楚目的和价值。绝大部分情况下，产品经理都会针对设计合理的产品方案并且推动上线。
二、如何判断需求实现的可行性？
前面提到绝大部分的产品经理都会帮助业务解决问题，但不可避免遇到能力不强的产品经理，他们有时候给出的评估可能并不客观的。
这种情况下，作为业务自己为了拿结果，可以自己对评估的结果进行合理性判断，但需要加强对产品系统的理解。
下面会花较大篇幅重点介绍产品系统，希望让完全没接触过产品的人看完后也能对产品运行有个概要的理解。
计算机的系统运作是明确、理性有逻辑的，。也就是说在产品中，都是可以用逻辑关系解释清楚的，不存在说不清楚关系的功能，就连随机函数在计算机的运行内核里也是明确的.逻辑关系主要有如下几种：
- 流程步骤型：先如何 → 再如何 → 然后如何，一步一步的。跟玩密室逃脱的道理一样，你必须开一个门，才能进入另外一个门，再进入另一个门，最后打开通关。
- 场景型：当场景=A时发生什么；=B时如何；=其他时如何。比如VIP会员9折，高级会员9.5折，其余原价。
- 是否型：一个条件满足了是怎样，不满足是怎样。比如淘气值是否1000以上，是的话买88VIP要88元/年；不满足则是888元/年；
产品的系统绝大情况就是以上3种逻辑的排列组合。举个例子，比如创建商品时，鞋服类的需要额外上传尺码对应表，并且鞋、上装、下装要传不同的尺码表：
如上简要流程（实际要复杂的多，作为业务理解到这个环节基本够用）就包含涵盖了流程步骤、是否条件、不同情况的处理等。需要强调的是，逻辑梳理过程中，需要遵循结构化思维的MECE原理（相互独立、完全穷尽），比如在给“人”做分类时，可以通过“男、女”区分，也可以通过“年龄段”区分，但不要用“老奶奶、年轻人（这样是不穷尽的，还应该有老爷爷、年轻男人、年轻女人）”这样来分。这样可以保证划分的维度是清晰的，并且能够穷举所有的场景。
在上述的案例里，尺码表虽然穷举了一些CASE，但是不穷尽，还可以增加CASE4：帽类、皮带类等（这里大家可以思考，在做尺码表时如何划分才会保证没有遗漏？）
作为业务，需要自己判断可行性的时候，可以尝试着把自己的需求按照上述3种系统逻辑尝试绘制流程图，再看看每个环节是否通顺。如此经历多个项目后，再和产品经理沟通方案，会发现对系统逻辑的理解会越来越透，也越来越有感觉，新的需求要提时也大体知道能否实现了。
PS：刚才案例的CASE4，可以按照成人、儿童进行一级划分，然后第二级可以按照上半身、下半身划分。这样可以涵盖所有的鞋衣帽手套袜子皮带这些穿搭品。
三、什么样的需求实现成本高？
高实现成本一般会有几种场景：
1. 目前不具备实现需求的前提条件，得先实现那个前提条件
比如：需要用户能在电商APP里看到每个品牌活动信息时，业务和产品经理有如下对话：
产品：这个需求暂时没法实现，品牌得拆出来单独管理才行
业务：啥意思，不是有品牌吗？我建商品的时候，页面上有让我写品牌的
产品：那个品牌是你输入的，不能拿它做管理的
业务：为啥？
产品：…..
这样就很难聊了，我们还是详细解释下（这里需要耐心看个5分钟），下图：
这是创建商品时，填写品牌的页面，左边和右边是2个方案。左边采用输入打字的方式录入品牌，比如“阿迪达斯”这个品牌，我们可以写“阿迪达斯”，也能写“Adidas”，都是代表阿迪达斯，看似没啥问题。但如果需要对每个品牌维护背后的供应商时，系统只能把“Adidas”、“阿迪达斯”和 “供应商A”和都建立关系，如下图：
显然，这样的方式是不科学的，有明显的漏洞——
当有其他运营新建“阿迪达斯”的商品时，他极有可能写了一个“阿迪”，导致的结果是这个“阿迪”无法自动和“供应商A”形成关联，后续希望看“阿迪达斯”这个品牌的数据时也是痛苦万分。
但是，如果这个时候有一个现成的【品牌库】，情况就完全不一样了——
商品创建时，如最上面右图的方案，可以直接选择“阿迪达斯”这个品牌，这样未来统计阿迪达斯真正的销量，就非常简单清晰。因为只有一个“阿迪达斯”，系统天然的控制了不会出现“阿迪”和“Adidas”。而且当系统只有一个唯一的“阿迪达斯”时，我们可以很方便的在后面直接维护供应商A，甚至是实现需求里要求的营销活动。在系统里，2中方式的信息存储结构如下图：
商品信息存储时，原来商品里的品牌信息是以文本“阿迪”存储的，而后者是以一个数字存储的，这个数字可以和品牌库里的“阿迪达斯”完成一一对应。在产品系统里，一个内容是否支持额外拓展，就看目前的实现方式是否是以唯一的ID进行存储的。这个映射到生活中可以用姓名及身份证号来理解，姓名是可以重名的，而身份证号是唯一的。如果一个叫“李三”的人犯事了，不会按“李三”这个名字来确定身份，而是用身份证号来唯一确定。
刚刚有点跑偏，实际上在实现成本里，很多需求是需要有前提条件的。在APP里要看到每个品牌的活动信息，能实现的前提需要有一个【品牌库】，并且在【品牌库】里的品牌后维护了活动信息，如果没有的话，产品经理就会告诉你实现成本比较高。
同样再举一个特斯拉老板Elon Musk要在火星上居住的例子。这个需求也是实现成本高，但不是不能实现。成本高的原因是没法一步到位，需要第一步把人送上天，第二步火星上氧气不足无法燃油驱动，得有电驱交通，第三步是有人类方便获取的再生能源。所以他做了SpaceX火箭、电驱车特斯拉、太阳能源公司SolarCity。
2. 因为投产比考虑的实现成本
有些需求其实不复杂，但是需求价值小、频率又不高，这种情况下产品经理可能会认为实现成本高。
举个例子，某刚起步电商平台，业务谈了一个客户，这个客户自己也有商城，他希望双方双方接口互通，实现货源共享销售。这个需求如果要实现的话，其实把已有的订单信息、商品信息、物流信息、资金账户等重新包装成对外的开放的接口，虽然会涉及到较多的系统模块，但是工作量并不是特别大。但如果这样的对接需求只是个例，且这个客户并不稳定，产出贡献也不大时，产品经理会认为投产比的风险是大的，内心倾向于拒绝这个需求。
另外，一个需求也不会因为实现成本大就一定不做，投入产出比合理就可以考虑。比如一个电商平台基本的买卖关系都已经实现了，接下来要发力营销活动时，虽然一个营销系统的搭建虽然成本高，但是也会考虑去投入持续建设的。
3. 涉及大宗数据计算，导致性能不佳
我们经常会听到产品或技术说“这样不行啊，性能扛不住”，背后其实是可理解的。
我们可能以为计算机是可以快速计算的，但实际上，虽然计算机可以比人的计算更高效，但它的计算力也是有瓶颈的。
我们玩游戏画面会卡，处理多行Excel时电脑有时候带不动，就是可能触及到了计算瓶颈或网络带宽瓶颈。
在互联网上也是一样，服务器其实就一台一台更牛逼的电脑，他们也是有计算上限、网络上限的，如果我们的需求涉及到大宗计算，极有可能因为系统性能而暂时无法实现。
4. 可维护性不强
先举案例：
电商系统里的卖家运费模板，针对ABC三家供应商，他们如果选择圆通快递，当收货地址为浙江省时，运费的计费方式只支持按重量计费，不支持按件数设置，但是其他区域可以两种计费并存。这样的场景就属于定制的个性化场景，是非通用的（大多产品经理会希望一套逻辑解决所有场景的心结）。
在这个情况下，未来如果再合作京东快递，那产品经理要留个神曲考虑考虑京东是否要共用刚才的逻辑，容易遗漏。
所以，作为业务方提出一个个性化的需求前，可以先仔细思考清楚背后的业务价值是不是真的很大。
对以上4点基本了解后，是比较容易判断一个需求的实现成本的，和产品经理达成共识的可能性更高。
四、需要了解哪些基本概念？
先说基础的必须要知道的3个概念数据库、表和字段。
1. 数据库
所有的产品系统都会建设在数据库之上，数据库就是由一张一张的表构成的，表与表之间会通过某个共有的字段来建立关系。
2. 表
就是我们理解的表格，有表头，每一列都由一个的字段构成，每个单元格里面都是具体的数据（字段值）。
3. 字段
就是表头里每一个单元格的内容，比如下面商品表里的“商品名称”就是一个字段，“AJ1 北卡蓝”是这个字段的值。
比如，搜索“鞋”时，计算机就是拿着“鞋”这个词，对照商品表挨个查，从第1个商品查到最后一个商品，直到查完。
如果商品像淘宝那样上百亿，一次搜索就要查一百亿商品，双11时1亿用户同时搜索，就是一次性要为1亿用户查一百亿商品，计算机要执行100000000*10000000000次动作，这就是前面讲到的，大宗数据处理就可能涉及到性能问题。
还有一些词，平时沟通过程中听到的比较多：
4. 接口
接口就是API。
先看下生活中的接口，比如水管接口，就是把一端的水通入另一端。网线接口，就是把互联网的数据接入你的电脑。互联网产品接口，就是指别人给数据给我，或者我把数据给别人。
警务系统如果对外开放身份证接口，我们就可以根据身份证号查每个人姓名、住址、是否有房、家里人有哪些等等，自然这些接口是不会开放出来给大众使用的，所以我们查不到。
电商里如果要查物流信息，也是因为物流公司开放了物流查询接口，我们可以获取每一条物流的轨迹，才能知道货物配送到了哪里。
5 .demo
一般也叫原型。产品经理按照需求绘制出来的的系统页面草图，通过草图能够大致能看到页面的信息结构和流程。业务可以据此感受方案的合理性，一般会用axure、墨刀等工具来绘制。
6. 设计稿（高保真图）
设计师会根据产品经理绘制的原型美化页面、用设计的手法优化信息的优先级，出具高保真UI图，技术基于这个图是可以直接进敲代码开发实现的。
7. 交互
指人机交互，“机”指的就是浏览器、移动设备、触屏设备这些。好的交互设计有一个核心原理，就是做到，当用户处于某个页面时，可以不费力不费脑子就知道要点什么，而且不费力不费脑子就知道点了之后会发生什么。
五、还可以从哪些网站了解产品？
最后，除了这篇文章的嘚吧嘚，如果大家还想了解更多的产品相关，可以去《人人都是产品经理》这个网站，里面有一个知识体系模块，有很多针对性的案例和主题，可以系统化学习了解。连接点击这里：http://www.woshipm.com/topics。当然更欢迎大家关注本号私信交流~
作者：归归类；公众号：归归类，微信号：gglei666
微信扫一扫 
支付宝扫一扫 
