对业务深入程度的问题

[awanganddong]

这是我老大说的一句话。

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

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

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

[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]

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