业务与技术思考

上一篇文章有同学说想看看思考路径，于是思前想后写了这篇文章

算是结合经验总结下如何持续思考

总的来说，思考应该不设边界，但应该有一个核心的方向。私以为如果是打工人（非国企）方向应该都是：增长盈利，降本增效。（资本增长的核心逻辑）

其中增长盈利对应业务，降本增效对应技术

下面从打工人的几个阶段介绍：

• 拧螺丝
• 造工具
• 带新人
• 领团队

拧螺丝

不管是大厂还是小公司，一般来讲职业生涯的起点都是从拧螺丝开始。逐渐接触行业，然后才开始深入接触，并在一定时间的积累后进入下一阶段。

这一阶段的特点往往是有老人，或者比你资深的人带你。会给你一堆没那么重要的杂活，让你练手。如果没人带的话要么是团队的梯队不完整，不是公司刚成立，就是公司快倒闭。

在这一阶段，很多人习惯了由别人安排工作，自己只作为一个执行者，不加以思考。因此当进入下个阶段后，需要自己干事情时，没有自己的想法。

增长盈利

那么在这一阶段如何对业务有一定的思考呢？

由于这一阶段是别人安排的活，那么往往很难得到完整上下文，不管是前人挖的坑，还是需求进的水。因此这一阶段以多收集信息为主，通过做需求也好，看代码也罢，先对业务有个大概的了解，然后大概思考以下几点：

• 为啥这样做？
• 做了有啥效果？
• 之前为啥没做？

以上三个问题的答案基本上就涵盖了需求的背景、目的、收益。

如果每个需求你都了解上面的内容，那么逐渐的业务的历史与发展逻辑会逐渐清晰。

举一个例子：

刚进腾讯的时候天天做需求，没有时间思考。当时最令我头疼的事情就是给需求预估一个开发时间。预估时间这个事情，有点像军令状，你按时完成是应该的，提前完成没人会夸你，但是如果延期那就完蛋。

当时有一个需求是给腾讯云开发退费功能，产品文档上写的很简单，列表操作项里加一个退费的按钮，退回用户没使用完的余额。当时需求评审导师问我要多久，想着加个按钮调一个接口就行了吧，就算复杂一点，再留一点buffer，一个礼拜应该随便够了。

于是就说一个礼拜，然后导师反问我，一个礼拜搞得定吗？我说应该没问题，刚好leader也在，拍板说那就一个礼拜吧。现在想来当时就算有 HC 估计我也没戏。进入开发后才发现这个需求是一个天坑。

前面两个问题都很好回答，一是有用户反馈没用完的钱提不出来，二是给用户更好的体验。这个需求麻烦就麻烦在第三点上。按理说这是个很基础的功能，但是为啥之前没做呢？因为涉及了多个部门，退款链路又长，来来回回折腾了一个月才算是把需求上了线。

所以拧螺丝的时候还是得稍微想想，不然容易砸到自己的脚。

降本增效

作为新人在技术方面，其实很难给整个项目带来明显改变，但一样的这个阶段还是可以思考一些问题。主要还是从几个方面找答案：

• 要改的话好改吗？
• 别人能看懂吗？
• 会出什么问题吗？

这几个问题主要是针对代码的拓展性、健壮性、可读性，我认为在拧螺丝阶段能把这几点做好就已经很不错了。

这里就不举例了，一般来说具体场景具体分析，上面三点都能做到的话，说明螺丝拧得又快又好~

造工具

当螺丝拧得足够多以后，理论上来讲对于业务流程，以及项目结构层次就有了一定的了解。所以熟练过后应该关注的点是，如何通过造一些或者用一些工具来改善现状。

增长盈利

对业务来说，造工具的时候更多是从专业角度，以及拧螺丝的经验上给需求提建议或者解决方案。

到这一个阶段对业务的思考应该注重于：

• 流程为啥是这样？
• 有没有更好的解决办法？

一般来说需求提出到上线是：运营=>产品=>研发

这里从两个方面来讲，首先流程为啥是这样？

现有的业务流程合不合理？现在的流程可能是因为之前的一些原因或者历史局限性导致的，所以需要注意观察现状。说得简单一点就是挑刺。但挑刺这个事情简单吗？

麻烦的点在于人的适应性是很强的，你刚接触业务时可能这里觉得不合理，那里设计有问题。但是当你了解前因后果，十分熟悉的时候还能轻松挑刺吗？

所以这个时候可以从源头入手，也就是运营，或者用户。因为产品给到研发的需求是在现有信息的基础上，提炼过后的需求。如果没有提炼，那说明这个产品有问题，只是一个传话筒，那人人都是产品经理了。

因此可以从问题的源头重新思考，现有的功能是不是很好地满足或解决了，用户或者运营当时提出的问题。

另一个方面就是，如果流程上是合理的，且没啥更好的方案的话，就想想从研发的角度出发会有更好的方案吗？

一个例子：

这里以一个B端常见的场景举例，产品提了个需求，说需要给搜索框支持下批量搜索。这个需求有问题么？一般场景没啥问题，但如果运营的使用场景需要大量搜索的话，可以考虑上传一个 excel 进行搜索，是不是会比直接支持批量搜索要合理一丢丢。

降本增效

对于技术方面的思考，其实会比业务要容易一些。因为对于研发来说，代码才是根本，业务是锦上添花。

尤其是大厂，基本上都会要求搞一些技术建设，如果你想有个好绩效的话。

所以应该怎么搞技术建设呢？可能很多时候大家会想到，技术建设就是重复造轮子。这里先不讨论造轮子方便晋升的场景，从为业务和项目的角度出发，这些轮子是为了解决现有的问题。那么第一步自然就是需要发现项目中存在的问题。

这里有一点像业务的部分在于，你对项目足够了解以后，也比较难发现项目中不合理的点。所以一般来说可以这样思考：

• 有没有重复性的工作？
• 有没有不方便的地方？
• 优秀的项目是怎样的？

对于重复性的工作，可以开发一些小工具或者打包的时候处理，比如新建一个页面，可以用一些 CLI 来自动生成。项目里重复出现的逻辑封装成组件。代码迁移用AST分析批量替换处理等。

对于项目中不方便的地方，通常出现在调试测试环节。对前端来说常见的有：H5调试、前后端联调、单测调试、CI/CD等。

对于优秀项目的参考的话，可以多逛逛开源项目的源码，虽然质量良莠不齐，但总的来说会比闭门造车要好。

---

后面两个阶段尚未踏足，只是现阶段的理解

---

带新人

一般来讲当你能对前两个阶段身体力行的时候，就可以开始带人了，其实主要还是看leader对你的看法，他觉得你行，你就行。

这个阶段是从自己知道到让别人知道的转变，你的价值从一个熟练工人，变成了能培训 N 个熟练工人。

增长盈利

对业务来说这个时候意见应该上升一个层面，不要局限在当前这个需求能不能做，合不合理，对不对。而是考虑业务整体的情况，比如加一个功能，现有的功能能不能满足，不能满足能不能把现有的功能和要加的功能以更好的方式结合在一起。

从某一个点合不合理，变成业务整体是不是合理的。

降本增效

这个时候由于价值体现在为团队增加更多生产力，所以需要考虑现有的成长方式能不能帮助新同学快速成长。

对帮助新人成长的方式方法按之前类似的路径不断优化、迭代。

领团队

到了这个阶段基本上就是打工人的终点了，区别无非在于团队的规模以及质量上。主要作用从一个人干变成带着一群人一起干。

最主要的是考虑问题的角度，需要从个人利益向团队利益转变。因为你的作用就是带团队，团队好你就好。但这里比较重要的点在于，追求全局最优而不是局部最优。

增长盈利

这个时候，对业务来讲，你是掌握业务方向的人，要不要做？做到什么程度？投入多少人去做？都是需要考虑的问题。

到底是追求业务的长远发展，还是追求自己的步步高升，都是问题。目前我还是认为做对的事情比较重要，就像巴菲特的一个观点，人们总是没法忍受慢慢变富。

降本增效

对于技术来说也是一样的，重要的也是找到对的方向。一般来说业务团队和技术中心（按我待过的团队来说）侧重点有所不同。

业务团队做技术投入主要还是为了给业务服务，追求稳定性啥的。技术中心的话更侧重于团队影响力，不管是业界内还是公司内，所以会朝着技术深度的方向走。

结语

按照王守仁心学的观点来看，真正困难的是知行合一，知道到做到中间有太多的阻碍。想来这也是我们读了很多书，却依然过不好这一生的原因吧。