对业务深入程度的问题

[awanganddong]

这是我老大说的一句话。

emm 咋说呢，我个人感觉吧，技术是次要的，如果想无法取代，就研究业务吧。业务熟悉了，写最简陋的代码也是有用的。当然了，如果要走技术专家路线的就是另外一回事儿了。
再不然就没啥别的建议了。现在整体上互联网这个行业就是相对不景气，也没啥一定会长远的了

想问下大家所谓对业务的精深程度是什么的一个概念 比如说我按照产品需求写业务 亦或我根据用户反馈来推断出可能需要的功能

所以想问下大家对业务这个东西的理解。

[pokeyou]

领域专家

[xuanbg]

要精通业务，首先得知道客户是谁，然后要懂客户真正需要的是什么，最后是你要如何解决客户的核心诉求。

[liuidetmks]

实话，还是得懂业务，软件 /互联网这块，真正需要技术的少,
大部分都是信息的简单处理。
有难度的部分，很多都有轮子了。

[RuiQ]

刚好今天在思考这个问题，一会整理下思路发个帖子

[FieldFarmer]

业务太宽泛了，真正还是要看客户的需求，不同客户的不同需求整理成业务可能千差万别，没有任何一种或者一套技术可以完美实现这么多的业务，大公司做的好的一点就是把通用的业务用框架技术封装起来，这样 90%的简单需求可以快速开发起来，10%的复杂需求再请大佬程序员单独入驻项目开发，更进一步做完之后还可以把这些复杂的需求做成案例供其他的项目组参考，甚至进一步再精炼加到 90%的那部分需求里下次就成简单需求了

[thunderw]

举个例子：
客户问：我有个商品明明有库存怎么无法销售？
初级程序员：什么是商品？哪个是库存？什么是销售？你就告诉我哪个页面报了什么错吧！
初级理解：我看了你这个商品了，它不在你的想出库的那个仓库里。你想办法把它弄过去才行。
中级理解：我看到你做分步式调出单了，但是没有分布式调入单，所以它还在原来的仓库里。要再补一个单据。
高级理解：是你们的 ERP 和 WMS 的对接有问题。告诉 ERP 那边以后做 XXX 的时候不要录入 XXX ，当前这一单 XXX 让 WMS 那边重新推送一下 XXX 。

[testver]

他是让你在产品经理的视角看问题。

技术只是实现的工具。

好比家庭装修，你要站在设计师的角度看，而不是单纯的站在泥瓦工的角度

[cubecube]

别听他忽悠。
基层员工技术第一，别被业务框死了，不然跳槽受限制。
所谓的业务领域，是等你升上去，不用写代码的时候吹牛逼用的，实质上大部分人能比较快的掌握。

[LeegoYih]

不喜欢技术的才会说技术不重要。
程序员平均在一家互联网三年就差不多了，没技术面试都过不去。

[chendy]

技术服务业务，业务推动技术，技术再好不懂业务做出来也不容易产生价值，业务懂了不懂技术也不容易做出来
两手都要抓，两手都要硬
两手抓不住，就抓一边吧

[cpstar]

这不就是产品经理之路？技术始终为产品服务

[coderluan]

这得看业务本身有没有什么深度，有的业务别人给你说几次你就能理解，有的业务你得自己查一堆手册才能有大概理解。

[jack778]

技术专家和业务专家不一样，业务专家不能换行，技术专家通用性比较好

[potatowish]

做技术的不可能脱离实际业务，多少都要懂一些，但是重点还是放在技术上。我同意 9L 的看法，你的 leader 大概率是不喜欢钻研技术的，所以才这么说，但是考虑到跳槽、裁员的情况，你不可能永远只待一家公司。做技术的换工作必然需要技术面试，没有人面试你业务水平，更何况每家公司的业务千差万别，但是核心技术大体是一致的。

[cool4food]

前提是正在接触一个存在一定复杂度的领域，才有机会让你成为领域（业务）专家。如果所在做的系统相关的业务和一个小白说几天，他就完全懂了，这样的业务不存在业务专家。

[cool4food]

@jack778 业务专家可以在一个领域深耕来不断巩固自己的壁垒，那么他在该细分行业内跳槽的要价可以比具有“通用性”的技术人员高

[raysonlu]

技术当然是自家心法内功好好修炼，但实际输出还是得配合业务。最理想的输出，是甲方提出了自己业务需求，你听到后能转化成自己内功能推动的东西，大概应该就是所谓的业务需求转技术需求，现实中，能做成这种转换并让甲方满意的，少之又少，于是衍生出一个叫“产品经理”的中间层，可以说这一层能专业做到这事，并且可以深度挖掘（比如可能还兼容 ui ，人工交互调研之类），但现实中每多一层，沟通成本和错误率都会大大增加。

[zw1one]

叫你即学产品又学技术，开发往上走都是这样的。但是业务知识换个行业就废了，你在哪个行业干成了领导再说吧。

[jack778]

@thunderw 这个知识换一个公司可能就没法用了

[zhaorunze]

其实吧，聪明人看问题都会很简单，不管技术角度还是业务路线，我认为都是在锤炼思维，智识上去了，啥都可以

[murmur]

@cubecube 但是 IT 业卷的太厉害，没业务理解，技术你可能都卷不过应届生

[awanganddong]

技术层面现在还是比较明晰的
比如我们现有业务基本上完全是 mysql 生扛，如果想优化的话，就必须深入 es 相关中间件了。
但是公司现状是不太需要的。


而有些需要实现的功能，与现阶段架构不相符的。
另一方面，公司的业务+数据都是在我这里的。对一个功能是否合理，我心里边是大概是有一个评判的，但是没有话语权。


所以就比较困惑，如果是自己主导一个项目，哪些迭代出来的功能是有意义的，那些是无效的。
基本上已经脱离简单写代码这个范畴。

从推广= > 产品=>技术=>变现 这个闭环，
所谓的把控作用

说的比较没条理，
现在心里边很乱

[fanxasy]

自私一点，唯跳槽 /升职论吧。假使把学习重心放在业务部分，在跳槽时，该业务类型相关求职机会多不多？这些工作岗位面试时对技术的要求又如何？

[shaojz2005]

对业务深入的意思是往项目经理或者产品经理发展，虽然业务基本上都是增删查改，但在某个业务领域，你深入了解了它的流程，就能精准地给出解决方案，这个就是你的优势。

但如果你想在技术上精进，则面临着公司的业务可能并不需要更深入的技术，那么这时你还想往这个方向发展，就得跳槽了。

[arischow]

互联网的业务？呃……

[awanganddong]

最开始负责业务是类似于巨量引擎这种 adx 广告平台，当然是比较小型的，这个就需要比较深厚的行业相关背景，侧重点是 to b 的。这种基本上路线就是比较明确的。有相关范式在里边。

现在是 to c 的，比如出了一个需求点，如果来评判这个需求点的价值？
先出需求，后埋点查看数据，这种就存在迟滞性。

如何来预估这个需求点的价值，现在更多的还是有点偏向于感性的，

其实是想作为一个技术，从产品角度查看问题。

[meeop]

这种话我觉得某种程度上是个饼

如果程序员要懂业务的话,那产品经理和你的领导是干啥的

术业有专攻,程序员要了解业务,但重点还是了解技术
除非你想转管理和产品,即便如此,只要还是在技术这条线,那还是技术要更深入一些

说技术不重要,那是公司实在没啥业务做,连一个稳定的业务线都没沉淀下来,不然出两次事就知道重要性了

[awanganddong]

平时会对竞品进行分析，然后从技术角度会发现人家有些需求设计的特别精妙。
看着还是蛮有意思的。


坐标成都。
技术这条路还是在接着走，
但是看招聘，再往上的萝卜坑已经不多了。

[456789]

程序员永远时技术第一，业务第二，不然没发跑路

[lujiaosama]

我老大也说过类似的话, 只懂技术不如懂技术+业务. 没有业务技术得不到变现代码写得再漂亮都没用, 只懂技术就是个工具人.除非你背靠的平台很大, 东西多到做不完. 不想写一辈子代码, 总归得要思考和研究业务的.

[ila]

不要被忽悠。
技术是根本，然后是理解需求。
业务排最后

[Qcui]

业务熟悉是指你知道了公司的盈利模式，熟悉了公司服务的客户和目标群体，并且还能对目标群体的需求做出改进，然后你就可以出来自己单干了

[awanganddong]

大家思想碰撞，搞不好就出来火花了

[wupher]


I believe this [article]( https://josephg.com/blog/3-tribes/) will answer your question.

> Programs, obviously, hold all of these properties. But I think there's fundamentally 3 architypes of programmers, divided by which ideals we hold in highest esteem:

- You are a poet and a mathematician. Programming is your poetry
- You are a hacker. You make hardware dance to your tune
- You are a maker. You build things for people to use

I think each group has its own conferences, and its own subreddits. Its own programming languages, heroes and its own villains.

[cnbattle]

我只能说 遇到过只会技术，业务能力差的，讲好几遍还不理解，都被骂了

如果一个人能合理的速度理解各种业务需求，我相信他在学习使用一个没接触的框架 /语言的时候，也能快速的用起来

反之的人，则会了某方面的技术，就一直在这个方面，面对大部分的新技术可能并不在乎

个人总结 前者可塑性高，我相信这类的人技术在中等以上 且容易到管理层， 后者就是一个萝卜一个坑，技术可能是大佬，到也可能很菜, 如果有能力更好的 /更合适的，或技术栈变动，则大概率被无情的替换，不带丝毫留念

[echo1937]

行业中水平越低，技术就越简单，可替代性就越高，那么技术部就越是搞不过市场部。

这不是技术没前途，而是在这样水平的公司搞技术就肯定没前途，这时候你多学点业务是好事。

大家也别强调 xx 就是工具，在资本面前，什么都是工具。

[Huelse]

技术是第一生产力，对你自己或者对工作都是有用的

[lmshl]

我讲个故事：
2012 年刚参加工作的时候，我入职了一家对日外包软件开发公司，技术栈是 .NET 。公司里有两位前辈与故事有关，老宋和李哥：老宋在这家公司干了十几年，业务熟手；李哥则是技术非常强，业务理解不算差。而当时我的 leader （老宋）曾不止一次跟我强调：“技术是有上限的，技术做到一定程度还是要转向业务，对业务理解越深，职业发展越顺”。大意如此，我不敢说一字不差的背下来，只传达核心思想。

2013 年，公司从日本回来一位同事胖子，公司给他定的薪资有 15k ，是老宋和李哥的 2.5 倍有余。得知这个消息的老宋和李哥一个星期天天往老板办公室跑，谈涨薪，无果。

一周后，技术强的李哥面试了一家银行软件开发，并收到 offer 。
而老宋，看着他拿起一本 Java SSH 网站开发的书翻几页，越看越无奈，又合上书看看我们，又翻开书再看几页，如此循环了一会儿，对我们说：“我真羡慕你们还年轻，学得进去。我这个年纪已经学不进去了”


我的观点：
极端点说，如果你的业务是银行财务相关，或者数学 /物理计算模拟软件。业务背后有经济规律 /法律甚至数学物理定律撑腰，那我觉得业务可能更重要一些。

如果你的业务是互联网 CRUD ，其中步骤来自老板 /产品经理朝令夕改的脑洞。或者你们只是在研究如何骗用户点你们平台的广告，那我并不觉得这类业务有什么值得深入的。

[murmur]

@456789 这个技术，是真的解决了生产力，还是为了保住饭碗自己在折腾自己玩

就比如 app 从 native 到 h5 到 rn 到 flutter 到小程序，但是总体市场是减量，你还得跟手机 rom 和自带功能抢饭碗

[murmur]

@lmshl

我真羡慕你们还年轻，学得进去。我这个年纪已经学不进去了

等 35 了，或者有有孩子有家了，大家都这样，只不过以前互联网蛮荒发展，靠各种折腾自己反复跳槽可以攒钱

这以后还会有么，

[Er1c0]

@murmur 老兄几岁了

[nbboy]

看以技术为主导还是业务为主导的公司，不过大多数的公司都是业务为主导的，所以楼主说的对。正所谓，一个会写 PPT 的干翻一摞子会写代码的程序员。（～手动滑稽～）

[456789]

@murmur 有老板给工资，自己看着方向可以就学呗，确实有个大趋势，又不傻该推推

[xmuli]

最近也在思考这个问题，感觉四分业务，六分技术，剩下九十分靠贵人帮忙决定

[potatowish]

做技术的懂点业务无可厚非，但你要是想深入了解，那就是分不清孰轻孰重了，只靠技术你或许卷不过其他人，但是待的不爽说走就走时你更有底气，就算被裁员了也丝毫不慌。

当然前提是你技术要做到精通，如果只是个差不多，那就是两头挨打。

[Davidwg]

太倦了，猿卷🐶

[opsonly]

高度不同，理解不来正常。
等你到了他那个时候就知道咯

[unregister]

业务熟悉，代码写的不好 有什么用呢？

[GP1]

美帝，掌握核心科技。
来，告诉我这句话是什么意思呢？

[nanjoyoshino]

一个东西不管是业务还是底层，只要你会，别人不会，那就是你的优势
如果你的业务中有这种程度的业务，那当然值得钻研了

[securityCoding]

我每次做需求都会提炼一个 FAQ 出来跟产品二次确认，然后贴到群公告。。。

[mysalt]

我觉得还是不要把业务和技术搞成对立关系，两者本身就是相辅相成的。技术服务业务，业务的发展本身也是在推动技术创新。

[imn1]

在公司一定是要学业务的，至于对“业务”的定义如何，要理解清楚

例如做服装制造，你并不需要了解具体什么布料选择、设计思路、缝制技巧这些细活，但你需要知道一件衣服，从布料到成衣整个过程的，这样你转到服装店也能生存，转到布匹店也能生存，转到家纺、布艺甚至工业织品等等都能生存。当然如果缝制技巧高超，将来也可能成为刺绣专家载入史册，如果觉得自己就是那个影响时代的人，也不妨试试

技术，那是纵向的事，在有机会学习横向的地方，就多学横向，因为接触横向的机会总是比纵向少的，但将来向上发展的话用到横向的场合却比纵向多得多

简单一句：去团队就学团队的知识，跟师傅学个人的知识。去团队却学个人的知识，那除非你的人生目标是单干（注意，当老板不是单干，也是团队），就是你老大所说的“技术专家路线”

何鸿燊说他对赌博没兴趣

[levelworm]

基本上就是去做多了就知道了，当然得留意需求之类的。然后客户还没说话你就知道他想要什么，客户一撅屁股就知道他要拉什么💩，就行了。总而言之，就是取得客户的信任，做中介的活。

[RiceNoodle]

所谓业务懂得多无法替代，前提是业务要有足够的深度和复杂度。
如果你们公司的业务，属于入职后，两个月就能把整个软件的主要业务逻辑弄明白的，那就没啥业务深度可言。
但是有的传统领域的软件，软件业务复杂到招新人进来培训就得 3 ～ 6 个月，需求、规格得业务专家才理得清写出来的那种，就属于业务无法替代了。当然缺点是一旦换行业，业务专家自身的损失巨大。

[drackzy]

让你好好认真干活的 PUA 话术，天天 CURD 业务，人就费了。

[jiangzhizhou]

业务和技术和数据都是相辅相成的。外企我就没看到过这么多细分的岗位，EM 搭配 Eng+DS+PM 就够了。To C 的话都是对产品负责的，大部分公司都用云，自己做 Infa 的也都 Cloud Native 。QA 一般外包。
从业务出发，提供解决方案，落地实施，保证 SLA ，上线分析迭代。这一套都清楚还怕跳槽问题？
人一辈子经历拉长来看，5 年 10 年都做同一个事也是蛮可怕 /厉害的。
格局大一点，路别走窄了就行

[AItsuki]

可以搜索一下 DDD 相关的书籍，看看序章大概就知道深入了解业务的必要性了，技术还真的不是最重要的。

[ericgui]

你现在这水平， 还轮不到你来谈业务，别想那么多，好好写代码

等你到了一定级别，再谈业务也来得及

[ydpro]

辩证的看待这个问题，业务与技术并不冲突，技术类似于职业发展的深度，业务类型于职业发展的宽度

[kidblg]

技术和业务互不影响，成年人两个都要。

[babalarf]

目标导向，mvp 导向。简单说来，就是从业务结果（长期的，短期的）倒推你需要做什么，并且保持技术成本在略高于最小 solution 的水平上

[358515041]

当然是技术业务两把抓啊

[feather12315]

@murmur #40 我不同意 你的观点。技术是没有尽头的，我赞成，但能不能学得进去是一种心态，学得快不快是一种知识迁移能力。

工作了十年，过去的经验就毫无价值么？

[512357301]

@thunderw 高级理解那里应该得是项目经理才能这样回答，初级的工程师很多都没办法接触到其他系统的，更不知道咋回事

[TUNGH]

@lmshl #38 讲得太好了

[aviator]

个人认为一旦选定行业之后业务知识是很重要的，这是真正和别人拉开差距的地方，但是前期行业未定，频繁跳槽的话业务基本满足工作需求就行，因为换一家公司之后行业不一又得从零开始。。。