开发人员想要精进业务，有什么方法论吗

[banjueaz]

作为一个多年的老开发，之前都是业务方说什么我干什么， 现在想要在公司更进一步的发展，需要对业务有更进一步的了解了

目的是想要比较深入详细的了解业务，能够在一些会议上面针对业务给出自己的建议和意见，至少在上级的眼中需要是比较懂业务的

请教一下各位有没有什么方法论或者工具，能够系统的梳理一遍业务，方便理解

顺便说一下，目前是外企银行业务，欢迎这方面经验的一起交流

[v1]

你业务精进总得有个方向，消金、个金、对公、外汇、个贷企贷……一大堆

[Need4more]

开会的时候多说几句，拽拽术语，做做样子，让领导觉得你有业务思维就行了。
你再懂也没业务人员懂，人的精力是有限的，至于说什么，看你的领导在说些什么，关心什么

[xuanbg]

@Need4more 这说法我个人完全不能同意。谁说的技术人员不能比业务人员更懂你业务，没这个道理。业务人员里面也一样大多是混子，也就个把精英在撑着这一摊子罢了。一般人只要智商在线，对业务上心点，三五个月精通一个领域的业务真不是什么难事。

[xuanbg]

技术人员精通业务不是为了去做业务，而是为了具备针对业务的痛点提出解决方案的能力。单纯的技术从来不值钱，只有把技术转化成能落地解决问题的解决方案才值钱。

[jimbray]

问了下 AI ，有很多个角度的方法论可以套用，比如：

费曼学习法：用通俗语言解释业务规则，帮助自己和他人快速掌握复杂逻辑。
STAR 法则（情境-任务-行动-结果）：用来描述业务问题或技术方案，让业务方听得懂。

就不贴那么多了，最近刚好做了一个小网站，收集学习方法论，有兴趣的话可以看看：
[学习方法论]( https://thinking.jimbray.xyz/)

[94]

平时做开发的时候和对接的业务方多问两句，没事的时候把手头上的业务逻辑串一串，其实很快就能了解到很多具体业务情况了。
结合自己当前在进行的项目去理解业务就好了。如果脱离工作，很难会有一些深入的理解。

[dog82]

以服务好甲方的脑残需求为最终目的，和光同尘，在屎山上摸爬滚打

[dododada]

这个要看业务内容，如果业务内容和技术耦合比较紧，这种上手很快；如果业务和技术离得比较远，几个月也能上手，不过业务里面的坑没人带的话，不管是业务的、技术的、人的，要挨个踩过去才知道；

比如前两年吹起来的数据治理，技术就那些，但是业务方向不一样，数据特点的差别就很大，不同的客户关注的内容完全不同，这种如果不懂业务、吹不到客户的心坎上，就很难落地

[lswlray]

轮岗，去做业务。

[midsolo]

大家可能忽略了一个点，就是你待在这个项目，就只能拥有这个项目的代码跟文档权限，而你日常做的事项只是业务中的某一块东西......

想把某个业务搞通，首先就要解决这个问题。

[banjueaz]

@xuanbg 很赞同，现在就是想更加深入了解业务，能够针对痛点提出解决方案。

[banjueaz]

@jimbray 感谢。我回头钻研一下

[94]

@midsolo #10 ，如果只做开发大头兵，事前不问事后不管，只顾着自己的一亩三分地。平时也不主动要求参会，任务安排下来就做，开发完了跑通用例了就交付。
不知道也不管开发出来的功能是给哪个业务哪些个用户用的，那么就算有全部的代码权限和完整的需求文档也是不会去看的。

大部分经理是乐意你去了解当前项目的实际业务的，这是对项目推进有帮助的。但是绝大多数的开发是不会想要去了解这些东西的。在他们心里觉得自己写出来的代码才是最重要的，业务是什么看都不想看。
最好 PM 能把需求文档写的清清楚楚，自己只需要按照开发说明书上的 1234 做下去完成任务，能跑通用测试用例就行了。还有一部分是连看着开发说明书都不知道自己开发的业务逻辑是怎么样的，稍微改一下逻辑就没办法通过回归测试了。

[midsolo]

@94 #13 很赞同你的说法。

我在某个做无人机的公司，公司是按照 "研发部门-业务线-项目组" 这种结构来进行划分的，项目组做的业务只是业务线的某个流程而已，公司对账号权限控制的极为严格，在哪个项目就只能看到与项目相关的代码跟文档，对接上下游都是严格按照上下游对接文档执行的，有事直接邮件沟通，根本就接触不到其它项目组的人。

请问这种情况，我该如何去了解整个业务（公司同事分布在深圳、香港、欧美......）。

[94]

@midsolo #14 ，我们也是一样的。是接触不到其他 BU 和项目组的。我的意思不是跨项目组和了解整个业务线，是需要精通当前项目组对应的业务。一条完整业务线有太多方向和具体细节了，就和 #1 楼提到的一样。
比如说我现在项目开发是质量管理品质管控相关的业务和考评，虽然不像一线专业人员一样精通，但是开发过程中可以清晰理解分析不同的质量管理的体系、方法和工具，知道要怎么和应该怎么审核，这样就算以后不想做开发了或者 IT 研发部门解散了也可以内部调岗到集团品质中心。

到你说的现在项目组做的是业务线的某一个业务流程。那你就要对这个业务流程有相当程度的理解。在了解的时候就会有一些不知道的专业名词和专业知识，这个时候你就可以去询问当前项目组对应业务线的对接人（如果对方乐意解答的话）通过口头交流或者 IM 沟通都行，或者自己检索相关的信息去串这个项目中的各种细节。然后如果你自己的部分搞定了，就可以去入侵到同项目组的其他开发同学负责的开发业务上面去，慢慢把当前项目组的业务流程和逻辑都掌控起来，那你就成为项目 PM 的候选人了。我那个项目组中间有一段时间 PM 缺失了，顶岗 PM 的半年多的时间里面正好遇到了裁员，但是因为对于业务和项目的理解程度，考虑到交接成本的情况下就被+3 领导保了下来。