产品经理的思考-我们是技术的主人吗？_做技术的主人

思考的起源

最近在准备公司内部的研发大会的汇报时，发现我们组的成员都跟我一样，是技术出身，在努力或者被迫努力的往技术产品经理的维度转变，晚上准备PPT到凌晨三点多，在最后收尾的时候，脑海里突然有几个疑问：在技术维，我们是技术的主人还是技术的奴隶？在产品维我们是主人还是奴隶？什么是技术?什么又是产品？

做技术的主人

默默的思考到东方泛白，好像突然顿悟了，在PPT的最后一页写上了:做技术的主人，做产品的奴隶。发布会上，底下做的产品们很开心，说技术人员是不是要做产品的奴隶了。其实这句话不是写给产品的，是写给做技术的人。
作为一名普通程序员，时常会觉得自己十分渺小，甚至会感到迷茫。我们内心崇拜技术，却也对日新月异的技术抱有深深的恐惧。有时候我会思考难道在技术领域内不断紧跟新潮，不断提升技能就是我的价值所在？

我觉得技术人员（程序员）的迷茫不仅仅是面对技术繁杂的无力感，更重要的是因为长期埋没于细分的工作任务中，无法看清从业务到软件架构的价值链条，无法清楚定位自己在分工体系的位置，处理不好自身与技术、业务的关系所致。看不到自己技术实现的商业价值，找不到存在感，只能不断的丰富所谓的技术栈来给自己安全感。

让自己喜欢业务

技术人员不喜欢业务，对业务人员充满敌意，这一点我曾经也经历过，宁愿花大量时间去学习框架工具、技术组件等相关事情，也不想听业务人员给我讲哪怕五分钟的业务价值，即使耐着性子听了，也是带着敌意和批判去理解业务。直到有一天，在跟业务主管聊天的时候，他说:"你们天天加班加点写了那么多代码，然后呢？有改变什么吗？不能变现，不能满足客户的需求，及时在酷炫，还不是写出了一堆垃圾。"仔细想想自己做技术的那几年，很多时候业务在我们脑海中留存下来的是一个个迭代，一个个碎片的功能点，一段段代码逻辑，对业务场景的了解、对业务流程的梳理、对用户痛点的体会、对业务发展的思考几乎是空白。但是这些恰恰是跟价值紧密相关的部分。作为技术人员我们习惯性的用战术的勤快掩盖战略的懒惰！我们死死的把自己陷在流水线式的迭代计划和功能排期上，用实现一个个功能和修复一个个bug，来给自己带来成就感，阉割了自己能够发现业务价值的能力，而过多关注新技术对职场竞争力的价值。
所以我们越来越焦虑，感觉技术越来越复杂，从而产生技术学习焦虑症的根本原因。

价值链条

其实我们更应该花时间去思考业务、技术、系统的价值链条是什么？

那么什么是业务呢？

就是指某种有目的的工作或工作项目，业务的目的就是解决人类社会与吃喝住行息息相关的领域问题，包括物质的需求和精神的需求，使开展业务活动的主体和受众都能得到利益。通俗的讲业务就是用户的痛点，是业务提供方（比如公司）的盈利点。而技术则是解决问题的工具和手段。

技术脱离了业务，那么技术就是无根之水，无法很好的落地，技术的研究也将失去场景和方向。而业务脱离了技术，那么业务就会回归到原始状态，变得极其昂贵和低效。

所以我们想想自己没日没夜写了那么多的代码从而构建起来的软件系统，它的真正的价值是什么呢？

说白了就是为了解决业务问题，所以当你所从事的工作内容并不能为解决业务问题带来多大帮助的时候，你应该要及时做出调整。那么软件系统又是如何体现它自身的价值呢？在我看来主要提供的就是业务功能和服务能力

互联网公司正是借助大规模的软件系统承载着繁多的业务功能，使其拥有巨大的服务能力并借助互联网技术突破了空间限制，高效低廉解决了业务问题，创造了丰厚的利润，这是人肉所不可比拟的。

正确的学习方式应该是将学习与具体业务场景结合起来，技术人员通过提升软件系统服务能力创造价值将，从对这些价值产生帮助的程度去思考优先级。学习本身没有错，错的往往就是那颗初心。

忠告

不要让自己敌对业务，从服务业务的角度思考技术的选型和必要性。因为当一个技术人员听到业务人员提出新的需求和变动的时候，第一反应是我的技术实现难度？我的代码改动大小？从而跟业务人员站在了对立面。抛开技术，应该思考这个新的需求或者改动，给业务带来了哪些价值，从价值出发去思考用什么技术解决，是不是有必要那么复杂的实现。让技术服务与业务，而不是让技术困住业务的发展。