近业务=困死在一条船上？

大家好，我是Z哥。

先来描述一个常见的场景。

程序员与业务需求方常常是一对冤家，经常因为一个业务功能实现争辩得耳红面赤。研发觉得这个功能很low，没什么技术含量，业务方却认为这个功能却很有用，需要花功夫做细做深做好。而最终的结果往往是，功能做出来了，但是很难用，或者做出来的功能要么经常出bug，要么数据异常。相对地，研发想引入些高大上的新技术，业务方却认为太虚了，没什么用。双方活在两个不同的世界。

因此，我相信每位程序员都有过这样一个困惑：“如果我在一家公司蒙头钻进业务里去，扎得很深，是不是就相当于把自己困死在这条船上了？”因为业务了解得再多，跳槽换一家公司后就毫无价值了，需要重新与业务方扯皮。为了避免浪费自己投入的精力，所以我更需要追求技术上的造诣。

这个问题其实很现实，也是很多程序员变成一个技术控的主要原因之一。毕竟，从这个逻辑来看，只有钻研技术，自己的未来才更有前途。

但是现实却是，这些技术控也逃不出迷茫和浮躁的困扰。为什么呢？原因我在后面会说。

对于今天要讨论的问题，我的观点很明确，近业务≠困死在一条船上，大家可以放心大胆的深入到业务里去。并且，业务的背后也有我们可以“带走”的通用价值。

下面且听我来给你分析分析为什么，也欢迎你在留言区分享你的观点。

/01 业务对程序员来说意味着什么/

首先最重要的一点，在日常工作中，业务是你吃饭的家伙。如果你技术再牛逼，但是无法满足业务上的需求，那你估计用不了多久就得卷铺盖走人。

因为在更大的层面，业务也是一家公司在市场中吃饭的家伙。引用薛兆丰教授在他课程中的例子，公司的老板好比一艘捕鱼船的船长，雇佣帮手的目的是帮他捕捞更多的鱼，如果他自己1个人能捕100条，那么他自然希望多增加2个人通过分工协作可以额外多捕之少200条以上。

那么你作为雇员，如果不知道大家是怎么捕鱼的，怎么去提升捕鱼的效率呢？如果你不知道如何提高捕鱼（业务）效率，整天把你的捕鱼工具（技术）打磨得再牛逼又有什么意义呢？而且没实际发挥过价值，也不知道是不是真的很牛逼。

/02 普遍看待业务的误区是什么/

在很多程序员眼中，熟悉业务是产品经理或者需求分析师做的事。自己只要根据他们提供的页面原型做开发工作就好了。

按照这个思路，程序员的工作就变成了装修施工队，根据图纸施工就好。如果是这样的话，能做到的最好标准也只是“完全符合设计图”，这样的话，算是与“提高业务效率”这件事完全划清关系了，没自己什么事，因为完全没有参与到这个设计的过程。

然而，如果有跟进过房子装修的人都知道，对于施工队来说，完全符合设计图这个要求本身就是很难达到的，总会有这里、那里的瑕疵。

因此，将自己置之于业务之外并不是一个好的选择，你很可能在别人眼里永远在“及格线”前面挣扎。

/03 应该如何看待业务/

Z哥我觉得，应该将业务视作你在当前岗位工作的意义，是你需要去战胜的目标，技术不应该是目标，而是你的武器，用来战胜目标的武器。

我们大部分程序员都不是搞科研的，如果沉迷于技术上的招招式式，而不去考虑需要战胜的业务目标是什么，那么你的招法再牛逼，也是花拳绣腿而已，并没有什么实际价值。

相反，有了一个清晰目标之后，反而会促使你思考是否有其它“武器”和“招式”可以来解决这个问题，不让自己拘泥于一个固定的框架之中。甚至能创造出自己原创的“武器”和“招式”。

因此，我更提倡将业务看作是一个“测试环境”，将你的所学投入到这个环境中去验证效果。让你成为一位能真正解决问题的技术大牛。

/04 可以怎么做/

如果你想提高自己的业务能力，可以试试以下这几件事。

01 查阅公司资料

这第一点是很多做技术的同学不愿意做的事情，但如果你刚进一家公司，查阅公司资料是快速了解业务的最好渠道之一。

从顺序上，首先应该先了解它的经营产品；其次，可以通过宣传资料、宣传 PPT、公司宣传视频等方式进行了解公司产品情况。当然，你也可以通过互联网搜索公司相关资料。

02 从业务角度思考问题

“从业务角度思考问题”这句话看上去很假大空，其实是因为这样的场景无处不在，最好能形成一种条件反射，自然地从业务角度考虑问题。

我觉得真正实践从业务角度出发的好办法是，自己去使用产品。使用后才能让你更清楚产品的特性、产品的亮点和产品的竞争力，以及你们公司产品与其他公司产品有什么区别。

另外，如果公司的业务是 To B 的，那么可以找机会多与老客户沟通沟通，如果是 To C 的，那么可以多与产品经理和运营沟通，这样也能让你更快地了解业务。因此我建议广大程序员同学还是应该懂一些行业里的行话和专有名词的，否则这里交流起来会有不小的问题。

03 观察分析数据

如今，各行各业对数据的重视度在不断加强。数据发挥的作用已经不仅仅是一个数字那么简单了。

引用网上看到的一个例子：

当你在某个夏天的中午12点，走进位于公司楼下的24小时便利店，使用微信支付，花了3.5元，买了一瓶无糖330ml摩登罐的可乐，收银员MM返回给了你一张POS单据，这时所发生的这一切都已经记录在了便利店的数据库里。更糟糕的是，店里的摄像头也已经把你在店里的一举一动录了下来了，转化成为一帧帧图像数据。
这就是业务数据化。
店长通过数据分析发现，最近3.5元330ml摩登罐可乐的销量比上月增长了20%，而消费者中75%是20-35岁的男性，相比之下，300ml塑料瓶装的可乐销量却下滑了40%。店长权衡比较了一下，决定下架300ml塑料瓶装可乐，增加330ml摩登罐可乐的商品。
这就是数据业务化。
https://www.jianshu.com/p/cda3537f00b7

从这个例子中可以看到，如何在业务中体现数据，以及如何在数据中分析业务。还可以从数据中观察到业务正在发生着什么样的变化。因此，数据也是我们学习业务的一个好地方。

另外，在培养起对数据的敏感度之后，遇到很多社会现象就更容易进行发散思考。比如，小镇青年火了，那么他们有哪些特征？这些特征中又有哪些可以被量化？是否可以用来改善算法模型？

04 请教业务懂得多的人

前面第2点中有提到去请教他人来了解业务，那么该怎么去寻找这个人呢。

我的经验是，除非是特别小的团队，否则一个团队中业务懂得最多的人往往是比较乐于帮助、分享的人。否则 TA 不可能有机会接触到那么多业务，毕竟一个人工作所面对的业务领域往往是局限在一定范围内的。

所以，你可以去请那些乐于助人的小伙伴吃个饭，喝个下午茶，去向 TA 请教业务相关的问题。我想只要 TA 手头没有什么特别紧急的事情，应该是很乐意帮助的。虽然这样了解到的业务，不一定能覆盖到100%的细节，但是弄懂个80%还是问题不大的。

好了，总结一下。

这篇呢，Z哥与你分享了我对“程序员该不该深入到业务里去”这件事的看法。

我的观点是很明确的，「应该」。

因为业务是公司生存的根基，也是每一位员工吃饭的家伙。想要获得更高的待遇，远离了吃饭的家伙怎么行。

远离了业务的程序员，就是“装修施工队”，永远在及格线上挣扎，无法100%满足业务，更不要说提升业务了。

Z哥建议你将业务视作你在当前岗位工作的意义，是你需要去战胜的目标，技术不应该是目标，而是你的武器，用来战胜目标的武器。这样的思路才能更合理地看待业务的价值。