接上篇，给大家从行业和个人的角度分析了下我的观点和目前的一些实际情况。 接下来，用我自己实际工作经历中遇到的几个场景，给大家再具体的描述一下。

我之前的一小段经历

      我之前就职的一家公司，ceo每次开leader周会时，总会常说这么一句话，我觉得还挺有道理的，“你们总是抱怨被业务牵着鼻子走，只能做一个工具人，那你们倒是去了解，去调研啊，你们出方案，让业务去配合你们啊”。“工具人”这三个字，对我的刺激还是挺大的，也让我反思了很多。
      其实我们追求技术没有错，我也热爱技术，希望技术创造价值，希望技术改变世界。那这里的落脚点还是业务。
      期间我还牵头利用业余时间+和别的项目插空的机会，重构了一个业务板块，抽离的一个平台，利用流程可插拔的动态配置，利用低代码平台技术，实现可视化配置，释放研发的人力，当我准备了个ppt，兴冲冲的找老板汇报这里面用了多少牛逼的技术，将平台与业务系统解耦的意义和以后演进的规划，老板说了一句让我印象特别深刻的话：“哦，你这是做了一些提效的工作是吧，那你现在有统计数据吗，比如节省研发投入的情况，或者提高上线速度的情况”。
      好吧，又是一次成长的机会啊，虽然后来还是得到了一些老板的认可，好在当时的老板是懂技术的，get了一些东西，幸好不是找大老板汇报。
      此刻,“程序员切忌盲目的陷入自嗨中”，感受颇深。
      再后来随着自己职业发展，老板给了一个新的命题，研发不能只做一个成本中心，要成为价值中心，否则只能作为后援团队，机械的支持业务发展，好吗，委屈是自己的，锅是自己的，成绩是前端部门的。“商业化”，由此而来。
      研发觉得这个功能很low，没什么技术含量，业务方却认为这个功能却很有用，需要花功夫做细做深做好。现实情况是，功能做出来了，却很难用，或者经常用不了，或者数据不对。研发想做点高大上的功能，业务方却认为太虚了，没什么用。（IT与业务方那点事就不多说了，大家都心知肚明~~）
         多年经验反复告诫我，鉴定一个功能是不是好功能，唯一的标准是看它能否支撑业务、改善业务、推动业务，也即应用效果。一个产品，只要有30%的功能，让业务用户用起来很爽，感觉帮助很大，就已经是一个不错的产品了。
             说这些，我是想说，作为技术人员，我们既要仰望星空，也要脚踏实地，既要追逐腾飞的技术，也要重视落地的业务。如果一个业务人员很懂技术，那将很可能是技术人员的灾难。因为那样的话，业务人员会很强势，又或者那样就没有技术人员什么事了。当然，也不难想象，一个真正懂看数据的测试人员，就好比一个真正懂用算法的业务人员一样难得。

总结

      公司的高层或者老板，开一家公司是希望赚钱的，商人是逐利的，首先想的是活下去，那肯定首先是要有业务价值。 有些人可能会觉得整篇下来功利心太强，我们出来工作是为了什么，赚钱，养家糊口不是，你真的有一天财富自由了，愿意写什么代码就写什么代码不是（法律允许范围内的~），如果说这个太虚，那就甩给女朋友一个大红包，让她去逛街，我们可以安安静静进入自己的代码世界。
      有一本书，《开发者思维》，作者是一个写了 25 年代码的上市公司的 CEO。 核心理论观点就是开发者思维，那什么是开发者思维呢？说到底就是开发者必须参与业务的决策，而不仅仅只是执行者。开发者思维的背后是：给开发者提问题，而不是给现成的解决方案，因为开发者的创造力，以及对技术的熟悉度，他们会根据问题找到最佳的解决方案，能够高效的完成开发工作。 而现在的公司大多数都是产品经理规划产品功能，让程序员开发什么就开发什么，而大多数产品经理又不懂技术，很多功能规划并不符合技术的最佳实现路径，所以，就会导致很多开发工作都拖延，效率低下。
      如果说你想参与创造，不想只做一个工具人，不想只听令做事，想提升自己的不可替代性，那我觉得我们是需要懂业务的，那个时候，你和产品经理吵架都可以大声一点。