研究业务是啥意思？

闪雷可达鸭

作为程序员入行不久，干的事勉强跟算法沾点边，做数据处理。
常听两种论调，研究技术没用，研究业务才有用。
劳力者治人 劳心者治于人啥的。
后者我大概明白，这也是管理岗比技术岗更好的原因。
技术大牛是少数，技术也要服务于业务。
那前者又是什么意思？

LaZier

..................说白了就是琢磨渠道，想明白找谁揽生意啦....

闪雷可达鸭

LaZier 发表于 2024-7-3 15:55
..................说白了就是琢磨渠道，想明白找谁揽生意啦....

……
也就是说不是刚入行的小卡拉米考虑到事吧？

枯风瘦雪

程序员的研究业务没这么复杂吧，就是要知道业务是怎么运转的，需求是怎么产生的，别当一个纯粹的需求实现机器

细川蓝

比如说，你做的软件是一个工厂生产管理系统，那么你是接收产品经理或者业务顾问给你的功能说明书才能明白你具体要做什么功能。
研究业务就是从客户讲述到功能说明书的过程。
开发人员如果能够理解业务，研究业务，那么很多功能在实现上会采取不一样的策略和写法。
再比如说，你这个软件是根据生产线生产100个物料，产生出100个物料的检验内容，理论上在订单生成的时候你同步生成100个检验项目就行了，
但是如果你了解实际业务的话，你会想是不是需要一次性生成，能不能根据订单的开工生成，生成后是不是需要更改，如果是不同步生成，且生成后需要更改，那么我实现功能的时候要怎么写。

Hydro

说"业务比较重要"确实需要有个"技术基础"的前提，一般都是干了一段时间的会这么说，无论他们有没有意识到这个前提
在连开船都不会开或者动不动就在基础问题上踩雷触礁的情况下，谈如何定义船的目的地的问题，就是纯扯淡
可能是干太久忘了，初入行的尤其是学生初入行的缺的更可能是技术，而不是业务理解

Misono_Mayu

怎么说呢，最近在做内部 tob 的项目，做的很累，复杂的业务逻辑，一个方法写个 3000 行都小意思

Misono_Mayu

Hydro 发表于 2024-7-3 16:10
说"业务比较重要"确实需要有个"技术基础"的前提，一般都是干了一段时间的会这么说，无论他们有没有意识到这 ...

要个 der 技术，会写 java 代码，能写 vue，会 cv，够了

Hydro

不是有一头重X的牛如何通过限重Y的桥的问题，那个就是个典型的目标理解（和寻找相应的方法）的问题
这头牛必须是整个运过去吗？切成小块运输再根据标记重组整个牛满足"整个"的定义吗？河深多少，是不是牛根本就不用走桥？这个牛是不是会飞？
客户为什么想要运牛过去？运费很高的话能不能有距离村子很近的边缘牧场，用户在边缘牧场买牛，不要从远处还走桥运牛？etc. etc.

GN-010

我的理解是，客户未必知道自己真的需要什么，所以需要产品经理来翻译一遍。但其实产品经理也不一定知道自己想要什么，所以面对产品经理提出的需求，如果你能大概明白他想做什么，你就能发现其中可能不合理的地方，然后提出修改建议，可以提前解决很多后患。

不过话又说回来了，我前东家的领导也鼓励程序员要多了解业务，但是他还鼓励程序员亲自和客户面对面谈业务，这我就觉得有点没必要了。

nexus1

看数据科学段子,一数据科学家吭哧吭哧一顿分析,发现了显而易见的规律,兴冲冲找老板汇报----就是业务员的薪资提成公式

LaZier

闪雷可达鸭 发表于 2024-7-3 15:56
……
也就是说不是刚入行的小卡拉米考虑到事吧？

...........属于几乎所有技术岗位后期的职业进阶需求。当你熟练掌握了各种你理应掌握的技术后，下一步你需要掌握的，就是你公司的客户群体是谁，他们对你公司产品的需求点是什么，其中哪些点是你技术范围内可以解决的。搞懂之后，在对接客户或是协助销售开发客户时，你才能更好地对接客户，从而累积你自己进一步提升的本钱...........
..........严格来讲，应该属于是小卡拉米有空可以想想，早想通早享受，晚想通有折扣（？）的事情。

aithinkso

具体地说，有些需求聊一聊很可能就能改得好写，甚至不用写
（其实是项目/产品经理不行 ）

流缨

举个会计相关的例子
开发来了个新人，连借贷方向是啥都不知道，无法理解账务会计分录是如何生成的
需求分析跟他对接了大概三天后直接要求换人，开发大佬好说歹说让人找了本会计入门书足足看了一个星期才勉强跟上趟
接下来大家每天在群里就会看到各种稀奇古怪的刁钻问题不过还真别说，这种外行往往能发现一些老手看不到的灯下黑，不少开发好的代码都被重新打回去排除隐患了

绚烂航迹云

引用第9楼GN-010于2024-07-03 16:20发表的  :
我的理解是，客户未必知道自己真的需要什么，所以需要产品经理来翻译一遍。但其实产品经理也不一定知道自己......

确实，程序员很多时候思考的角度，并不是业务上的，有的人会非常螺丝钉视角，你就说要改什么吧，而客户往往只会给出笼统的想法，鸡同鸭讲，

----发送自 Sony XQ-AT72,Android 12

绚烂航迹云

引用第12楼aithinkso于2024-07-03 16:25发表的  :
具体地说，有些需求聊一聊很可能就能改得好写，甚至不用写（其实是项目/产品经理不行 ）

聊一聊，不用写，就能动代码，那确实是项目/产品不行

----发送自 Sony XQ-AT72,Android 12

yeo

客户提的需求：载重100吨的续航20000km的飞艇
客户的实际需求：运输50吨钉子

流缨

又想了想，其实举例子不是很好的办法，还是说说条理
程序开发本身就是业务的附着物，在没有信息化改造的时候仍然可以通过旧的流程跑通，如果你没有业务的能力，是不可能从底层、动机、概念上理解这套流程如何运行的，技术适应了业务才使得效率更高，而不是因为你技术高才使得业务效率高
另外钻研技术没屌用这个可能是真的，大部分产品都不会去主动采用最先进的技术，要走成熟稳健路线。
如果你不是在专门的研究开发岗，还是老老实实打螺丝吧，真的不需要

犹格索托斯

指正：劳心者治人，劳力者治于人

長友彩海

不需要关注业务的程序员，那不就是日本