为什么技术人员要具备产品思维？

凌云时刻

编者按：在日常工作中，程序员和产品往往会吐槽彼此，吐槽源于产品思维和工程师思维的碰撞，导致大家对同一件事情的认知存在差异。本文作者基于自身作为技术人的视角，阐述具备产品思维的技术人会获得更多的职业成长，供大家参考。

什么是产品思维

作为一线的开发人员，大家是不是都有过和产品吵得不可开交的经历？甚至最后谁也无法说服谁，只能将问题上升由老板出面解决。而大多数情况下，老板还真能够以某种方法解决，并且是一个双方都能接受的方案。

这个时候可能大部分同学会认为是老板的权威、地位导致了这一结果。其实这不太准确，事实上很可能是由于老板们有比一线开发更强的产品力，能够听懂对方的诉求和抓住矛盾点并且给出解决方案。同时，表达方式也更容易让彼此接受。也就是说，解决问题的关键能力差异点，我认为是一种更产品思维的方式。

产品思维是通过科学方法论来持续获取最大化价值的思维方式，但这种说法似乎有点空洞。换一种更具体的说法，基于日常产品技术的产品迭代，产品思维有以下这几种形式：

为什么技术人员要具备产品思维？

 技术视角的局限性

1. 觉得产品提的这个需求没有意义、对业务没有任何帮助，是一种鸡肋需求；

2. 疑问产品的需求为什么每天改来改去？十分降低工作效率；

3. 觉得产品的想法天马行空、不专业。完全没有考虑系统的可行性，基本无法落地实施；

4. 觉得产品的方案一点都不周全，这么明显的逻辑漏洞都没有考虑到；

.......

在日常的工作中，作为程序员的你是不是经常会有上面的吐槽？其实，抛开一小部分产品可能确实由于经验少导致方案不成熟，更多的吐槽源于产品思维和工程师思维的碰撞，导致了大家对同一件事情的认知不一样，从各自角度出发都会觉得对方难以理解。

举个例子：之前盒马仓储产品评审过一个活鲜仓按箱出库的需求，大致意思呢就是针对活鲜类商品（例如鱼、螃蟹之类）直接以箱为单位进行出入库管理。这里如果从工程师思维出发会出现几个不可避免的问题：

• 箱入箱出这种场景在之前盒马的仓储系统中是不存在的，具不具备可实施性未知（HOW、技术至上）；
• 全链路要适配这种改造，改造点会非常大，难以实现（关注细节、解决方案）；
• 针对少货或者多货的场景，涉及上下游链路库存对账会非常麻烦，且极端场景下压根无法对齐（完美情节）。

针对这几个问题，研发侧进行了需求的打回，并协议产品业务对齐方案和风险后再次进行评审。但从产品的角度来看角度完全是另一种场景：

• 箱入箱出以前不存在，不代表现在以及将来不会有。这是线下真实需要的业务场景，盒马的仓储需要扩展这类能力（WHY、用户价值）；
• 全链路改造工期大，可以梳理工期进行正常排期迭代（迭代思维）；
• 异常场景是小概率事件，不能因为小概率事件影响整个项目的推进。真正少量异常数据由业务自己兜底（全局观、完成比完美重要）。

显然，由于产品和技术出发的角度不一样，会带来天然的冲突。如果在沟通中再代入情绪的话，会很难理解对方的诉求和问题点在哪里，也很难去理性思考是否有综合两者诉求且相对靠谱的解决方案。在这里，技术人员如果转换一下视角用产品思维去考虑这个需求，再去沟通是不是会更合适一些呢？

• 认可箱入箱出是一种新的能力，让产品确定业务价值之后去扩展此类能力，也是对现有仓储系统库存能力的一种补充。
• 告知产品要做好心理预期，全链路改造方案成本会比较高、耗时会比较长。看是否能够接受改造时间，如果不能接受需要去尝试中间方案。
• 技术侧如果投入大量成本去改造链路，需要产品和业务认可此事的技术价值和投入产出比。

采用这种方式去沟通，会明确告诉产品技术侧的问题点以及担忧的问题。如果双方都认可此需求的价值和必要性，就可以继续合作推进。也就是说，如果程序员具备产品思维，你就能站在产品角度去思考问题，就容易和产品团队在沟通协作层面培养更融洽的工作关系，长期来看更有利于提升工作效率。

 技术人员具备产品思维的优势

如果技术人员具备产品思维之后，除了便于沟通之外，还能给技术人员自身带来哪些工作上的优势呢？

抽象能力相信大家做技术的都或多或少有一些，平时写代码中也经常用到。但是根据已有信息去抽象和面向未知去抽象是两种完全不一样的能力。当技术人员具备产品视角之后，会更容易发现抽象的角度，也更容易表达出来抽象的概念。

例如，最近接到一个针对大仓加工智能秤称重的产品诉求（将加工过程中的原料重量通过系统记录下来）。如果简单的抽象可能是称重任务可以称原料、称成品。如果具备产品思维，就会问这个称重主要解决什么问题？是在实操作业哪一步的动作？这个时候可能结合MES系统你想到的是工序，会进行一个工序任务的抽象。

那工序到底应该怎么去表达呢？具备产品思维的技术人员会很自然地联想到精修、贴膜、贴标等等实操环节都可以通过工序去表达，再结合其它应用的场景去类比，一个面向未来的工序模型就可以逐步沉淀下来，也便于未来扩展。有兴趣的同学也可以去了解下仓内的精华装载单元面对过去是如何进行统一归纳沉淀的，面向未来是如何抽象扩展的，这是一个十分经典的抽象例子。

大家可以想一下，具备产品思维去形象表达事物的根本属性时，是不是大多从这三个角度出发：

• 给出清晰的定义
• 做出准确的简单类比
• 打出精妙的比方

如果在工作中具备了这样的思考方式，在你遇见困难的时候，会把思考的主动权攥在自己手中，而不是交给别人。这是一件当下比较累、但对未来很爽的事情，保持一定的好奇心和想象力去思考，会让自己收获更多的成长。电影《教父》里有一句经典的台词：“花半秒钟就看透事物本质的人，和花一辈子都看不清事物本质的人，注定是截然不同的命运”。

那么，对技术人员而言，更好的全局视角意味着什么呢？

• 首先是提高系统熟练度，不仅仅是针对当前你所负责的模块，你负责的系统上下游链路也应该具备相当的了解，这样你才会有更多的机会去承担更大的职责。
• 明确知道做这个需求、这个项目的价值，知道为什么去做，而不是一个简单的执行机器。会去从需求合理性、投入产出比等问题上去思考需求的必要性。
• 更容易知道如何去体现价值，知道这个项目的重点是什么，知道如何去沉淀数据，知道如何从系统的角度来阐述和达到目标。

• 更好的通过技术创造业务增值。技术同学如果具备产品力会更容易发现产品当中的优化点，并创造不小的业务价值。

  举个例子：之前优选网格仓针对中心仓发货容器进行二次分拨到站点，技术侧发现这里可以针对容器内货品进行分配关系的打乱（总体分配关系不变）从而减少分拨次数。仅这一个技术小点，就减少了网格仓现场12%的分拨次数。

  再举个例子：之前B2C大仓边拣边播，是拣完一个SKU进入一次巷道，如果巷道中有多个SKU需要折返多次；技术侧具备产品思考之后通过细微的改动提供了更好的产品体验，对总拣和分拨这俩个动作进行抽象归类。通过统一进行总拣、再进行分拨的方式，避免总拣分拨交叉使用的方式下拣货人员往返多次的问题，提升现场14%的拣货人效。

如何提升产品力

 思维的转变

在不同的思考阶段，我们看待问题的角度一定要有进步。能够针对具体表现层的变化，去抽象底层的概念和能力来以不变应万变。

举个例子：仓储系统复杂演进的过程更多是围绕产能 & 人效 & 成本 & 数字化的不断演进，需要持续锻炼自己的思维习惯，才能去提升思考力的边界。最近笔者在看一本关于产品法的书并做了部分笔记，这里面涉及到思维方式的内容，我认为以下几点是值得我们技术人员去注意并且不断学习和提升的：

• 本质思维：第一性原理从头算起，只采用最基本的事实作为依据，然后再层层推导，得出结论。抛开别人怎么做、过去怎么做得到不一样的视角（拒绝被同类产品的设计影响和压根不懂同类产品的设计是俩回事 ）。连环追问法是一种手段，理清过往思路和关键环节，帮助快速判断并且产生新的idea。
• 相对思维：日光与阴影，让东西明亮不一定是加强它的亮度，可以通过调低周边的环境。这是一种逆向思维。成功与失败，优势与劣势都是暂时和相对的概念。看问题很重要的俩个角度：关系和时间
• 抽象思维：白痴与上帝，高级抽象视角看问题和用户本能层级看问题会有冲突，切换视角看不同局部是比较重要的能力。具体与抽象，就像飞机腾空时一个个点被不断缩小的过程。多考虑新元素而不是新功能，元素可以搭建功能。
• 系统思维：反馈的地位。反馈系统模型是基础的抽象模型，本质上都是在设计反馈。思维误区所有极端和异常的路径是小概率现象。
• 演化思维：自下而上的设计。极简是演化的基础，好的框架重点突出并且能够收放自如。

 现实中的一小步

看到这里大家可能会问：上面说了这么多软思维、方法论相关的观点，如果从落地的角度看，在平时工作中怎么去提升呢？怎么去潜移默化改变自己的思维呢？

1. 普适的套路：多看书籍，培养自己的知识储备；多做总结，将自己所学到的知识尽量系统化地表达出来，进一步巩固自己的知识成果；多做分享，如果一个知识点你不光能够自己懂，还能够让大家都听懂你讲了什么、你的思考点是什么，这样会进一步提升你的结构化思考 & 表达能力；

2. 保持好奇心：这一点我更想表达在平时的工作中不要局限于自己的边界，不要仅仅满足于分配给你的工作，要多探寻你本职工作之外的部分扩充自己的领域能力。可以多问问自己：一个项目你负责其中某个模块之后，你是否能cover住你上下游的问题？线上出现问题时你是否能及时定位到原因并且协助解决？另外就是保持对周边领域的探寻，对比周边同学的工作内容和思考看看自己还欠缺哪部分能力，能做哪些针对性的提升。例如，具体工作场景中可能某个同学负责仓储的拣货实操部分：

• 那是否有了解过拣货单生成部分的主流程？
• 是否了解打包部分的设计？
• 是否知道装笼发运的几种主要方式和约束？
• 又是否知道仓储系统之外单据的交互节点和主要数据？

3. 多去思考产品需求的本质，至少先做到在PRD评审上多换位思考，多理解产品设计背后的原因。例如，如果有个“用户减肥”的需求你会联想到什么？普通人可能想到的就是减肥，但产品思维下的思考应该想到的是：可能是Ta想要更优越的外貌？可能他需要寻找伴侣？可能想要提升社交地位？

4. 多保持联想，锻炼想象力。平时接到产品需求之后是否能够联想到系统的现有能力？是否能够结合现有系统来达到需求的最优解？在这里举个仓储系统拣货的例子：之前盒马加工中心有过一个按商品拣货的需求，大意是当拣货员看到库位的商品之后可以自己主动选择商品去拣货。按商品拣货这个需求从产品侧来说是一个比较简单的诉求，这里一般会怎样联想呢？

• 接到这个需求的第一反应一般是直接根据商品选择拣货单返回给用户，再让用户做选择即可（同时需要更改拣货单相关索引）。
• 联想到全局，如果深层次想结合B2C仓内拣货任务作业的实时调度，就可以想到这里用任务调度实现是否更符合仓内实操全局调度的规划。
  
• 再联想到现有系统的瓶颈和优化点。现在的调度根据分区&任务能力选择队列拉取任务，本质是一种“实时排序”，只能够基于配置优先拉取。其实我们也应该扩宽任务调度的"选择能力"，例如这次的“按商品索取”，其实是一种队列内部的选择能力。在获取任务时除了L1级别选择不同队列的能力，我们在队列内部应该要具有L2级别的选择能力，来丰富我们的任务调度中心在实操侧的另一种调度方式（和排序平级的能力）。
  
• 最后结合过去和可能的未来，除了按商品拣货，之前的DPS拣货 & 标签拣货走任务队列时通过工具去拉取完临时过滤的方式，不应该是一种长期的方式。包括后续可能存在的按位置拣货（分区内部的巷道库位、根据人力位置实时获取最优拣货单）、按销售订单拣货（哪个订单要超时了紧急提高优先级）等等可能存在的场景，本质都是根据实时的实操动作去具备L2维度的选择能力，是否可以借本次需求来搭建基础实现能力；
  
• 最终给出一些抽象归纳的建议。拣货实操时的变动，需要考虑人的因素去动态选择。生成任务的时候照正常生产，实操的时候具备动态能力（插入的选择能力根据人的因素去抉择），如果不配置那就默认使用原有队列的排序能力。

当然这里只是一个联想的例子，可能最终决策还要考虑投入产出比等各方面的因素。保持想象力无论对程序员还是产品经理都是一种提升思考深度的方式。我们要做的就是培养习惯，让自己的思考伴随着自己的想象力去得到成长。（完）

你可能还想看

END

如果喜欢我们的文章请点击「在看」✨