作者 | 行溪
来源 | 阿里技术公众号
一 产品思维是什么？
作为一线的开发人员，大家是不是都经历过和产品吵得不可开焦的经历，甚至最后谁也无法说服谁，只能将问题上升。最后由老板出面解决，而大多数情况下老板还真能够以某种方法去解决，并且是一个双方都能接受的方案。这个时候可能大部分同学会认为是老板的权威，地位导致了这一结果。其实这很不准确（可能有一部分原因但绝对不是主要原因）其实更多的是各个老板们有比一线开发更强的产品力，能够听懂对方的诉求和抓住矛盾点并且给出解决方案。同时其中的表达方式更容易让彼此接受，才导致了最终你看到的老板出马，问题解决，好像自己的观点继续保持了，同时对方也留有余地。那这里这项重要的能力来源于什么呢？其实我认为更是一种产品思维的方式。
从这里可以看到产品思维是通过科学方法论来持续获取最大化价值的思维方式、但这样说或许有点空洞、在基于日常产品技术的产品迭代、更想说产品思维以下这几种形式。
二 为什么技术人员要具备产品思维？
1 技术视角的局限性
- 觉得产品提的这个需求没有意义、对业务没有任何帮助、是一种鸡肋需求；
- 疑问产品的需求为什么每天改来改去？十分降低工作效率；
- 觉得产品的想法天马行空、不专业。完全没有考虑系统的可行性、基本无法落地实施；
- 觉得产品的方案一点都不周全、这么明显的逻辑漏洞都没有考虑到；
- .......
在日常的工作当中、作为程序员的你是不是经常听过如上的吐槽、其实抛开有一小部分产品可能确实由于经验导致方案不成熟、但更多的有没有想过是由于产品思维和工程师思维的碰撞、导致了大家对同一件事情的认知不一样、从各自的角度出发的时候会觉得难以理解。首先我们来看一组产品思维和技术思维的对比。
举个例子:之前盒马仓储产品评审过一个活鲜仓按箱出库的需求、大致意识呢就是针对活鲜类商品（例如鱼、螃蟹之类）直接以箱为单位进行出入库管理。但这里如果从工程师思维出发会出现几个不可避免的问题:
1、箱入箱出这种场景在之前盒马的仓储系统中是不存在的、具不具备可实施性未知（HOW、技术至上）；
2、全链路要适配这种改造、改造点会非常大、难以实现（关注细节、解决方案）；
3、针对少货或者多货的场景、涉及上下游链路库存对账会非常麻烦、且极端场景下压根无法对齐（完美情节）；
针对这几个问题、研发侧进行了需求的打回、并协议产品业务对齐方案和风险后再次进行评审。但从产品的角度来看角度完全是另一种场景：
1、箱入箱出以前不存在、不代表现在以及将来不会有。这是线下真实需要的业务场景、盒马的仓储需要扩展这类能力（WHY、用户价值）；
2、全链路改造工期大、可以梳理工期进行正常排期迭代（迭代思维）；
3、异常场景是小概率事件、不能因为小概率事件影响整个项目的超前推进。真正少量异常数据由业务自己兜底。（全局观、完成比完美重要）；
在这里由于产品和技术出发的角度不一样、则会带来天然的冲突、在情绪带入之后会很难理解对方的诉求和问题点在哪里、以及是否有综合2者之后相对靠谱的解决方案。在这里技术人员如果转换一下视角用产品思维去应对这个需求、这样去沟通是不是会更合适一些呢？
1、认可箱入箱出是一种新的能力、让产品确定业务价值之后去扩展此类能力。也是对现有仓储系统库存能力的一种补充。
2、告知产品具备心理预期、全链路改造方案成本会比较高、耗时会比较长。看是否能够接受、如果不能接受去尝试中间方案。
3、技术侧如果投入大量成本去改造链路、则需要产品和业务认可此事的技术价值和投入产出比。
当采用这种方式去沟通之后会明确告诉产品技术侧的问题点以及担忧的问题、这样当双方都认可此需求的价值和必要性之后再一起同步携手往前走。回到这个例子、其实就是程序员如果具备产品思维，你就能站在产品角度去思考问题、就容易和产品团队沟通协作培养更加融洽的工作关系、更有利于提升工作效率。
2 技术人员提升产品力后的优势
我们再来看如果技术具备产品思维之后除了更加便于沟通还能给技术人员带来哪些工作上的优势呢？
抽象能力相信大家做技术的都或多或少有一些、平时写代码中也经常用到。但是根据已有的内容去抽象、和面向未来去抽象是2种完全不一样的能力。当技术人员具备产品视角之后，会更容易发现抽象的角度、也更容易表达出来抽象的概念。例如最近接到一个针对大仓加工智能秤称重的产品诉求（将加工过程中的原料重量通过系统记录下来）如果简单的抽象可能是称重任务可以称原料、称成品。如果和产品交流过后具备产品思维就会问这个称重主要解决什么问题？是在实操作业哪一步的动作？这个时候可能结合MES系统你想到的是工序、会进行一个工序任务的抽象。但是这里再考虑表达、是否要更加让大家明白工序是什么意识？这里就会自然的类比精修、贴膜、贴标等等实操环节是否都可以通过工序去表达、再结合他应用的场景这样一个面向未来的工序模型就可以逐步沉淀下来、也便于未来扩展（有兴趣的同学也可以去了解下仓内的精华装载单元是如何面对过去进行统一归纳沉淀、面向未来是如何抽象扩展的、这是一个十分经典的抽象例子）。
修炼思考力，提升角度，更容易看问题本质。大家想一下具备产品思维去形象表达事物的根本属性的时候是不是大多从这三个角度出发：
1、给出清晰的定义；
2、做出准确的简单类比；
3、打出精妙的比方；
你在工作中一直具备如此的习惯、在你遇见困难的时候、会把思考攥在自己手中、而不是交给别人。这是一件当下比较累、但对未来很爽的事情、保持一定的好奇心和想象力去思考、会让自己收获更多的成长。电影《教父》里有一句经典的台词：“花半秒钟就看透事物本质的人，和花一辈子都看不清事物本质的人，注定是截然不同的命运”。
更好的全局视角、这里针对技术人员更好的全局视角意味着什么呢？
1、首先当然是提高系统熟练度、不仅仅是针对当前你所负责的模块、更是你所负责系统的上下游链路也具备相当的了解。这样会给你更多的机会去承担更大的职责。
2、明确的知道做这个需求、这个项目的价值、知道为什么去做、而不是简单的执行机器。会去从需求合理性、投入产出比等问题上去思考需求的必要性。
3、更容易知道如何去体现价值、知道这个项目的重点是什么？知道如何去沉淀数据、从系统的角度来阐述和达到目标。
4、更好的通过技术创造业务增值、技术同学如果具备产品力会更容易发现产品当中的优化点、并创造不小的业务价值。举个例子：之前优选网格仓针对中心仓发货容器进行二次分拨到站点、技术侧发现这里可以针对容器内货品进行分配关系的打乱（总体分配关系不变）从而减少分拨次数。仅这一个技术小点、就减少了网格仓现场12%的分拨次数。再举个例子：之前B2C大仓边拣边播、是拣完一个SKU进入一次巷道，如果巷道中有多个SKU需要折返多次；技术侧具备产品思考之后通过细微的改动给了更好的产品体验、对总拣和分拨这俩个动作进行抽象归类。统一进行总拣，再进行分拨的方式，避免总拣分拨交叉使用的方式下拣货人员往返多次的问题，提升现场14%的拣货人效。
三 如何提升产品力
1 思维的转变
在不同的思考阶段、我们看待问题的角度一定要有进步。能够针对具体表现层的变化、去抽象底层的概念和能力来以不变应万变（举个例子、仓储系统复杂演进的过程更多的就是围绕产能 & 人效 & 成本 & 数字化的不断演进）要不断锻炼自己的思维习惯、这样才能去提升思考力的边界。最近笔者在看一本关于产品法的书并做了部分笔记、这里面关于思维方式我认为以下几点是值得我们技术人员去注意并且不断学习和提升的
- 本质思维：第一性原理从头算起，只采用最基本的事实作为依据，然后再层层推导，得出结论。抛开别人怎么做，过去怎么做得到不一样的视角（拒绝被同类产品的设计影响和压根不懂同类产品的设计是俩回事 ）连环追问法是一种手段，理清过往思路和关键环节，帮助快速判断并且产生新的idea。
- 相对思维：日光与阴影，让东西明亮不一定是加强它的亮度，可以通过调低周边的环境。这是一种逆向思维。成功与失败，优势与劣势都是暂时，相对的概念。看问题很重要的俩个角度：关系和时间
- 抽象思维：白痴与上帝，高级抽象视角看问题和用户本能层级看问题会有冲突。如果看不同局部可以切换是比较重要的能力。具体与抽象像飞机腾空时一个个点被不断缩小的过程。多考虑新元素（能力）而不是新功能，元素可以搭建功能。
- 系统思维：反馈的地位。反馈系统模型是基础的抽象模型，本质上都是在设计反馈。思维误区所有极端和异常的路径是小概率现象。
- 演化思维：自下而上的设计。极简是演化的基础，好的框架重点突出并且能够收放自如。
2 现实中的一小步
看到这里大家可能会问、上面说了这么多软思维、方法论相关的观点。如果从落地的角度看、在平时的工作中怎么去提升呢？怎么去潜移默化的改变自己的思维呢？
- 普适的套路：多看书籍、培养自己的知识储备；多做总结、将自己所学到的尽量系统化的表达出来、这也是进一步巩固自己的知识成果；多做分享、如果一个知识点你不光能够自己懂、还能够让大家都听懂你讲了什么你的思考是什么这样会进一步提升你的结构化思考 & 表达能力；
保持好奇心：这一点我更想表达在平时的工作中不要局限于自己的边界、不要仅仅满足于分配给你的工作、要多探寻分配你工作之外的部分扩大自己的领域能力。基础的要求:列如一个项目你负责其中的某一个模块之后、你是否能cover住你上下游的问题、线上出现问题时你是否能及时定位到原因并且协助解决；另外就是保持对周边领域的探寻，对比下周边同学的工作内容和思考看看自己还欠缺哪部分能力、能做哪些针对性的提高。例如工作时可能某个同学负责仓储的拣货实操部分：
- 那是否有了解过拣货单生成部分的主流程？
- 是否了解打包部分的设计？
- 是否知道装笼发运的几种主要方式和约束？
- 又是否知道仓储系统之外单据的交互节点和主要数据？
再放大一些到除开工作之外、是否平时会关心他人的生活经验？是否对于大到国际新闻小到周边内网八卦一概充耳不闻？这样会让自己处于信息的闭塞状态、久而久之会导致思维的僵化。所以一定要保持自己的好奇心、保证自己知识储备的宽度、让自己的思维处于活跃的状态。
- 多去思考产品需求的本质、至少先做到在PRD评审上多换位思考、多理解产品设计背后的原因。举个例子如果有个用户减肥的需求你会联想到什么？普通人可能想到的就是减肥、但产品思维下的思考应该想到的是、可能是他想要更优美的外貌？可能他需要寻找伴侣？可能想要提升社交地位？
- 多保持联想、锻炼想象力、平时接到产品的需求之后是否能够联想到系统的现有能力、是否能够结合现有系统来达到需求的最优解？在这里举个仓储系统拣货的例子:之前盒马加工中心有过一个按商品拣货的需求、大意是当拣货员看到库位的商品之后可以自己主动选择商品去拣货、按商品拣货这个需求从产品侧来说是一个比较简单的诉求。这里一般会怎样联想呢？
a. 第一反应接到这个需求一般是直接根据商品选择拣货单返回给用户、再让用户做选择即可（同时需要更改拣货单相关索引）；
b. 联想到全局、如果深层次想一下结合B2C仓内拣货任务作业的实时调度、就可以想到这里用任务调度实现是否更符合仓内实操全局调度的规划？
c. 再联想到现有系统的瓶颈和优化点、现在的调度根据分区&任务能力选择队列拉取任务、本质是一种“实时排序”、只能够基于配置优先拉取。其实我们也应该扩宽任务调度的"选择能力"、例如这次的按商品索取、其实是一种队列内部的选择能力。在获取任务时除了L1级别的选择不同队列的能力、我们在队列内部应该要具有L2级别的选择能力、来丰富我们的任务调度中心在实操侧的另一种调度方式（和排序平级的能力）；
d. 最后结合过去和可能的未来、除了按商品拣货、之前的DPS拣货 & 标签拣货走任务队列时通过工具去拉取完临时过滤的方式不应该是一种长期的方式。包括后续可能存在的按位置拣货（分区内部的巷道库位、根据人力位置实时获取最优拣货单）、按销售订单拣货（哪个订单要超时了紧急提高优先级）等等可能存在的场景、本质都是根据实时的实操动作去具备L2维度的选择能力、是否可以借本次需求来搭建基础实现能力；
e. 最终给出一些抽象归纳的建议、拣货实操时的变动、具备人的因素、去动态选择。生成任务的时候照正常生产、实操的时候具备动态能力（插入的选择能力根据人的因素去抉择）如果不配置那就默认使用原有队列的排序能力。
当然这里只是一个联想的例子、可能最终决策还要考虑投入产出比等各方面的因素。保持想象力无论是对程序员还是产品经理都是一个提升思考深度比较不错的方式。我们要做的就是培养习惯、让自己的思考伴随着自己的想象力去得到成长。
从传统数据库到云数据库演进
随着云计算的发展，数据库的部署形式也发生了很大的变化。传统的数据都是部署在客户机房里面，与客户的机器绑定。而在云环境下，希望数据库能够在多种形态下部署，比如公有云、专有/私有云、混合云以及软硬件一体化独立部署，以及纯软件输出。阿里云数据库不仅在云上提供服务，还会支撑整个阿里巴巴集团内部经济体的所有活动。2019年双11，在零点刚过的第一秒，阿里的数据库系统峰值增长了大概135倍，瞬间爆发，这就需要数据库具有较高的可扩展性、弹性以及高可用。
点击这里，查看课程～
