以前遇到过的直属领导都是做技术出身的，最近换成了一个非技术出身的新领导，没想到一上任就来了一番震撼发言……
简单概括一下就是要求我们开发也需要多了解熟悉业务，希望开发多接近一线客户，最好可以在工期轻松的时候亲自跑一跑业务谈一谈客户，这样才能做出好用可靠的项目。以及进一步鼓励我们，如果有意愿的话希望我们向客户经理或者实施工程师发展……
这种情况你们会怎么看？做为开发而言了解熟悉业务到底有多大用处（尤其是在本身公司也有负责业务的包括产品经理在内的其他同事的情况下）？

了解商业逻辑，增长知识面

这领导格局够，研发只关注技术，绝大多数都把自己的路给走窄了

没毛病啊，对于开发来说本来就应该多熟悉业务。当然向客户经理或者实施工程师发展，也要看个人意愿

我觉得有道理,虽然我是写代码的没有业务,代码没有什么价值,除非你写的是基础框架有业务,垃圾代码也能赚钱

有利有弊吧，好处是可以更快理解客户的需求和痛点，发现新的创新点或优化方向，直接反馈效率高，坏处是容易扯皮，工作重心分散，本来就是产品的活，有好处是有好处，但是你花的这个时间会不会给你加工期开发，不然就是一份工资干两份活

技术是为业务服务的，脱离业务，技术一文不值

"要求我们开发也需要多了解熟悉业务，希望开发多接近一线客户，最好可以在工期轻松的时候亲自跑一跑业务谈一谈客户，这样才能做出好用可靠的项目"------- 这是好领导呀。

不强制而是自愿的话，很好啊强制的话就难讲了

非常同意, 开发一定不能闭门造车, 多了解业务才能事半功倍, 我做开发最怕需求不明确, 代码翻来覆去的修改. 我经常说的一句话就是 "只要需求明确, 开发不是问题."

我个人实践的结果是，多了解业务是挺好的，但是直接面对一线客户，谈一谈客户的必要性不是特别大，而且会有很多问题

本就该如此，只关注技术就只能成为一个执行者，成不了创作者就好像你只会打字，别人说一句你打一句，这样你永远成为不了作家还是要多动脑子

多熟悉业务非常赞成，不闭塞自己本身就是最大优势。起码表现是：换工作时候不是只能找同类工种，很多技术转岗其实也是经历过其他场景后发现了自己更适合做些别的

我们反着，新领导不去了解业务，丢弃过去几年的代码，从零开始，忙活啥一年也没做出来

除非你想转产品，不然你产品和代码同时搞的话，怕你没那么多时间。

熟悉业务没毛病, 很多业务自己写的时候就想着这样符合规则那样严谨, 然后做完没法落地😹

作为有追求的开发其实自己就应该这样做，但是领导这样要求可能就是另外一回事了，注意权责问题，留神别成了背锅侠。

出发点是好的，但还是得看个人意愿。公司有一些技术厉害的同事，连在公司内部沟通起来都不太顺畅，他们的性格就适合埋头写代码，让他们去跑客户也太勉强了吧！

看你要分配多少时间和精力到这块，太多就得不偿失，否则挺好的

小公司的开发不是一直和业务直接相关？

我先说结论，这是我的一些思考的总结： 1.做应用软件开发，不仅要了解商业模式、了解业务流程而且要深入了解。 2.面相对象从了解现实生活、了解行业、了解业务流程开始。 3.代码的组织架构、服务器组织架构设计其实也可以应用到公司组织架构设计中，以及现实生活中其他方面的系统设计，其中一些道理是相通的。 4.提高编程的抽象能力可以让你对世界有一个更清晰的认识。

于公我觉得是好事于私能不能让产品去干，我不想搞

本身就是这样啊，这样可以减少被菜逼产品坑，导致反复改。之前在某 top 跨境电商发现产品太菜拉扯时间太长，deadline 产品早早确认最终开发苦不堪言。后来直接对接业务方产品会议当场可以拍版哪些能做需要多久，当前需求以及业务部门未来规划非常清晰，直接无视产品，开完会之后就可以安排技术选型和方案设计，甚至有些需求可以提前做，deadline 无任何压力甚至提前，当下有什么困难，哪些排期优先级调整直接跳过产品对接业务方，就因为这个烂产品导致之前业务对产研满意度很低，这就是直接原因，后来负责的产品直接换人了，产品老大瑟瑟发抖。付出的代价是我每周开半天会罢了，部门内的人压力都小很多，有充足时间自测，代码质量比之前高很多，原来项目组满意度在中心吊车尾，之后满意度都能排到 top3 ，后面还安排一起团建啥的，年终基数增长就不用说了，最主要没有被分配到末位淘汰名额。

愿不愿意看个人。但是我感觉这个领导很鸡贼，他没有把最核心利益的点、矛盾的点摆出来讲：如果我遵循这个模式，那么我的薪资结构产生什么变化，多了还是少了；我的工作时间产生什么变化，会有无偿加班产生吗？我相信领导把这两个点摊开来说后，上面说好的人，得有一半以上的会后悔

多了解业务是好事，但后边就见仁见智了

个人感觉这个领导挺好的。

多接触到业务有好处，但是涉及到具体业务有话语权吗？还是说了解然后转发项目经理

熟悉业务是肯定要的，但是直接跑客户有点过了。

要把你们转岗到销售？还是说开发也要有销售业绩 KPI ？

听领导的，做开发没钱途，写 PPT 和跑业务才是一技之长，扩充人脉，知识面对转行有帮助

那可能说明你们领导觉得你们产品对接得不好

其实从个人发展的角度来说扩展一下蛮好，不能局限在一个领域。

看你有没有出去单干的想法然后对公司当前的行业有没有感兴趣

了解了业务又能如何，提需求会被采纳？产品经理的价值又在哪？

"最好可以在工期轻松的时候亲自跑一跑业务谈一谈客户"如果这说的真的，这领导是有魄力有格局的人，就不怕你们偷家。业务才是发展的起点！

这个出发点是非常正确的，开发不是只关心技术，要多关注业务，懂业务才能更好的做开发现在单纯开发路就走窄了

程序的目的就是将各行各业的方式方法转换成机器可以理解的编码，提高效率，也就是说程序最终是为业务服务的

这不说挺好的吗

没毛病

和客户交流需求的事情应该交给销售或者产品专门去做，研发技术多和销售产品交流。如果每天又要维护几个客户，整理需求，开会讨论，有多少时间能写点代码？

没毛病

不怕你们把客户拉走吗

理是没错，确实需要懂业务逻辑和业务流程阿里的不少产品，缺的就是这个——没有认真了解客户需求，自认为需求都在他们技术范围内但实操是另一面纯技术人员跟客户沟通，绝大多数会遇到“无理需求”，这些一般在客户经理或者业务会使用沟通技巧过滤掉，但纯技术人员不具备这样的沟通能力，吵架为多

道理当然是对的，多了解客户，多了解实际需求，有利于你开发的时候代入使用者角度思考如果你不接触一线客户，那拿到的需求都是包装过滤过的，虽然不用动脑思考需求这块，但开发出来的东西很容易和真正需求南辕北辙，一线用户很多需求是矛盾的、无法实现的，但接触接触还是更能开拓自己的眼界想法，很多新奇的想法反而能给你很多灵感更好的解决问题

估计你是想来听大伙骂他的，谁知道清一色的认同你领导的话。不管哪行哪业了解业务都是最没错的。毕竟你不可能一辈子当个打工仔吧？

这是好事。

销售换公司都拉不走客户，公司的资源才是侧重点，创业另说

这是好事啊！研发独自去跑业务肯定不现实，让商务带你们去跑！这简直可以算是福利了

作为一个开发， 我还是很喜欢跑业务的，只是没有机会
根据我个人的经历，一旦客户认识了你，就会直接向你提需求和问题，这时候你还得反过来向产品和实施汇报，结果就是产品、实施、开发的工作你都得做。而且你根本无法集中精神码代码，因为每过一会就会有客户联系你，打断你。" 以及进一步鼓励我们，如果有意愿的话希望我们向客户经理或者实施工程师发展…… "，你可以建议 "鼓励客户经理和实施工程师学点编程 "

核心开发要是上一线直面客户，就俩结果，要么客户上来就被开发气跑了，要么开发无脑接了一堆客户的要求最后项目、开发、以及客户那边的对接人全部跑了。就算光看人事安排这一点，把开发直接敢到客户那里之后，产品经理就被架空了，同时这个领导自己连开发加业务也都不会去管，架空别人但自己又不接，这是重大的人事问题。你这领导，纯沙雕无疑。 ＃1 ＃2 ＃3 ＃4 ＃5 ＃6 ＃7 ＃9 ＃11 业务跟客户的原始需求，是两码事。

个人觉得业务也是研发的核心竞争力，最好能成为领域专家

小公司可以，大公司没必要

换个角度看问题，”别人说你只会增删改查，你还不乐意“

和销售一起去拜访客户，听人家怎么沟通怎么说就好了。去客户那，不要乱说话，不要说这个没问题。去现场长长见识挺好的。

这不挺好的的吗

我认同他的想法，很多研发都把路子走窄了，以为赚钱只有写好的代码

开发了解业务，做出来东西可以更少返工，可以更加解决用户痛点。对于公司来说，可以减少产品压力和交流成本，让开发承担分担产品压力。但归根结底，如果工资没有上涨，那都是放屁

那分工是为了什么？

技术本来没有任何价值，技术价值依托于业务实现。即使是技术企业。深入理解业务，才能设计出真正好的业务架构。所以，我一直认为，一个好的产品经理应该同时懂技术和业务。

出发点不一样 好处坏处也不一样只想做个打工仔，能避就避想创业，想在这个行业深耕并在业务上发展，多少跑不掉，可以参与，初期练好闭口禅，多干活少说话

强制的话可能领导就是人力资源专业的了，不强制那就是大格局了

看你们公司哪个岗位持久，有权力，薪资高，门槛高。如果 客户经理 实施工程师 > 开发 ； 那就领情，相当于多了一条路；如果 客户经理 实施工程师 < 开发； 那就让不适合走研发路子的人转岗，多一条路子。

听领导安排，多接触客户，最好是能和客户建立长期联系，没坏处，当然技能点也不能落下

我也希望有机会去见一见客户，见一见用户，即便是挨喷挨怼吧，不然造不出好产品。

熟悉业务没毛病，非常支持。但是岗位是要干啥？觉得开发没用？

好多人想得太好了，抱着恶意猜想（因为我看到了「如果有意愿的话希望我们向客户经理或者实施工程师发展……」这句话），未来有些开发可能会有业绩方面的 KPI 了（不管是维护老的合同不丢，在老合同上增加金额还是开拓新业务）。多了解业务肯定不是坏事，但对你来说，得撇清说清自己的范畴（就是根据你个人年度/季度/月度 KPI 来多了解业务，有可能影响到自身业绩表现的一定及时同领导汇报沟通），开发一旦扛指标工资可能都拿不全了，除非你真的想未来从开发转业务。

先搞清楚主楼的行业和业务情况才能具体分析。拿到一个题目表述含糊不清的题目就开始跟帖回复的话，怎么讨论都可能是错的。开发是需要了解一定的业务模式，知道部门如何赚钱，但这并不带表技术在任何情境下都需要深入到开拓客户的过程中去。所谓“专业的人做专业的事”。知道了业务，也能帮助开发更好的去理解产品和业务方提出的需求。你可以更好地理解需求背景和最终的目标，从而思考：如果产品提出的方案不合理，但这个目标使我们要去实现的，是否会有其他方式达到同样的效果？ ——而技术上的事情是开发门儿清的，产品如果不拿到足够多且清晰直观的 IT 知识文档是很难理解开发的苦衷的。开发和产品的沟通有时候也是“商量着来”的过程。

从个人成长来看，懂业务、懂产品、懂客户、懂人性是往高层次进发绕不过的路。从团队管理来看，分工的价值是发挥专长。各方向的合力才能平衡。而不是一个方向的往另一个方向倾斜一些。

1.技术层面如果你做的不是基础技术、组件、架构开发，而是应用业务开发，熟悉业务，甚至是商业模式都是工作中重要的一环，更好的理解业务前提下编程，后期迭代维护或许会更好.2.职业发展大多数程序员社交这块比较弱，与客户接触，会拓宽视野，甚至会积累些人脉，对你以后的发展可能有好处。最后，具体工作还需要制定细则，免的领导扯皮，只是拿开发做免费劳动力。

熟悉客户没你们想的那么理性的，有专门对接的人尽量让专业的人来搞，贪多嚼不烂的。有些东西不是说你产品好技术好业务好就能搞的风生水起的，有些东西看不见摸不着的。

开发转实施，20K 到 10K ，实施是个低端岗位。如果是实施顾问还可以，类似咨询岗位了。

这是好事啊，很多客户的需求其实他自己都不知道，你多了解一下，以后自己搞私单还是单独出来 solo 都是有帮助的，最好就是利用这个机会多拓展客户群，为以后自己单干或者分包做好基础。不要以为很多项目都很大没你发挥的空间，很多客户的需求其实直接一个微信小程序就能解决，对客户来说很复杂的功能对开发者来说就是左右逢源搭根线就行。

了解业务和直面客户没有任何关系

作为管理技术部门超过十五年的老混混告诉你：了解业务和接触好处很多！1 ，老子混了这么多年 IT 了，接触的项目那么多，见过的项目尸体都比哪些公司招聘的产品多，他们大多经验从业经验不超过 5 年，不用听他们忽悠，不用担心争不过他们！因为他们往往喜欢搞些锦上添花的无关痛痒的功能。2 ，知道自己做的东西的价值，知道客户痛点，不会再闭门造车了。3 ，累计客户资源，说不定下次客户就直接来找你了。。。。。

挺好的，出去练练，正好积累一下转行经验，牛逼一点的直接把客户带走。

为了 35 岁以后考虑，还是需要了解下业务的，就算做了研发经理，也需要熟悉业务，而不是被动接收产品输入，会把人累 si 的

每个领导不都是这么说的，很奇怪吗。

其实如果不在一家公司长待就不用，两年一跳这种；纯技术路线以后朝外企发展没问题；如果不是这两种情况，了解点业务也挺好

實施就是項目交付崗位，客戶經理銷售崗位；前者的薪酬天花板比研發體系低，後者的固定薪酬比研發低。考慮下收益再看怎麼選擇吧。

＃72 你有看楼主的描述吗。这里面绝大部分的回复，压根就是看了个标题就开始回复。甚至就是标题都没仔细看，标题已经点名了，这不是让开发去熟悉业务，是让开发兼岗或者直接转岗去当客服。不闭门造车，不是让你走向另一个极端去先当客服。程序的业务，也是个技术活，要做什么、什么能做、什么不能做、哪些先做、哪些后做，这都是要有一定能力才能做的。这是产品经理或者产品负责人的事，开发要想熟悉业务，首先要找的是他们。如果开发越过产品负责人去直面客户，熟悉到的业务大概率是「苹果掉了之后该往天上飞」这种正常情况下应该被过滤掉的业务。另一个事实是，回复里面相当一部分人，是打心眼里瞧不起开发和产品，表面上说着熟悉业务，背地里想得是「只要给客户当好孙子，敲代码的开发，和决定做成什么的产品，就都是他的孙子」

有一个疑问。技术的目的是实现业务价值，开发多了解业务确实是有用的。但是，产品、业务人员如果能更了解技术，肯定对整体效率也是有用的。却很少见到要求他们主动去学习了解技术知识的言论，最多就是说希望他们是原本有技术背景的人。这是为什么？

了解实际业务是非常好的，这对于理解业务逻辑，解决一线问题非常有帮助，毕竟面向客户的一线业务才是真正赚钱的部门，需要对他们有足够的尊重；但是需要注意的是，公司最近是否有裁员的计划，很多时候转岗体验也是裁员的一个手段。

就应该是这样子，对个人发展是很好的

我认为说的很对，作为开发肯定是需要多了解业务的，这样才能更深刻的认识到自己所开发的功能是不是用户想要的，而且基于对业务的认识也可以帮助你更好的设计软件业务架构，也很大程度的避免了做一些无用功能（具有一定发言权的情况下）

领导说的多接触客户多接触一线好像没毛病，接触客户可以，不过谈单已经到商务销售的程度，那就有点过了，轮也是轮到产品上，让研发去谈不怕把客户谈没么，最多就是协助一线，了解他们怎么谈的客户对产品要求是怎样的关心什么，谈客户真正的主力肯定还得是一线人员或者产品的。另外这种情况还要看公司风气和倾向，有些重业务的会要求研发多熟悉业务，有些重前沿技术研究的对业务熟练度要求没那么高，不过总的来说熟悉业务是更好的，如果你确定以后都做这类业务的产品的话，那么熟悉业务的竞争优势会很大，保障技术 ok 的前提下多熟悉业务是正确的。我所在的公司，toB 的项目，职级高的大佬不仅是技术强，还都是对客户和一线交付运维接触非常多，这方面经验丰富。而且我看他们评优，也都是和一线一起搞定客户的定制线的研发容易评到优，家里搞主线的评优反而很少见。。显然上面是更喜欢这种看上去在搞钱的研发吧。如果 op 公司开始有这种倾向，那建议跟上以适应公司的要求，不认可那只能苟住或者准备换公司了。

工作四年内，还是不要去的好，这个阶段有太多的技术细节需要学。但是超过四年，可以考虑去了。这个阶段大部分技术稍微花点时间就能 cover 住了，此时更需要了解用户，了解业务，让自己去深耕某个业务领域，继续专注于代码反而把路走窄了

挺好的事情。大多数还是有由业务驱动技术的。对个人来说可以提升非技术的知识广度。

只懂技术的人很多， 又懂技术又懂业务的人少。 在我看来， 开发应该多懂业务，多自己会有很大的提升和积累

很好的领导！技术只是工具，不想做工具人，去学习业务知识就对了。

因为半桶水的产品经理害死人，但半桶水的研发主管会害死整个公司。再说，程序员懂业务有很大好处，懂一点点也只有好处没有坏处。但产品经理懂一点点技术的话，除了比不懂技术不乱开口的更讨人嫌外没，并没有什么半点用处。

就是从 ROI 的角度考虑是吧。学习技术只有深了才有用，学习业务总是有用。按这样一想，以技术作为立身之本的岗位似乎有点吃亏

应该去了解业务，掌握行业 knowhow ，个人认为这个是比技术更值钱的东西

业务了解就行了 ，如果是感兴趣可以深入学习一下，大部分公司的业务，在离开这个公司之后就毫无价值了。

个人觉得这领导没毛病，非常良心，对于不是单纯想混日子的员工，绝对是正作用

这事不是光看表面，要看里子的。恰巧我做过类似的人员调配方案。我来直接给 LZ 解题吧。为什么是新来的领导强调多熟悉业务，鼓励往前端转岗？这是公司风口在变。在这大环境下，公司需要盈利，需要看现金流。那么研发之于公司，就是资源，成本。你们老板开始注意精算成本，毕竟这么一堆研发的人员在这，不能直接跑客户，不能多面手，也不能在现场解决问题，只能在家里研发产品，那么研发了之后呢？就是纯维护，需要这么多人吗？养这么多人，都是成本，干不干活都是要支付成本的。那么这么多研发，有沟通不错的，往实施，客户转，这样项目一多，实施也就不用招了。剩下的研发在差不多的时间就可以考虑砍掉了。这就是老板的想法。如果不信，你可以考虑探一下负责客户，实施的 HRBP 或者一些关键节点的人，探口风是不是实施客户之类的岗位有缺口，但一直按着不招？ 如果是，那就对了，因为他想一部分好的研发转到这里，这样省的再去外面招人。不过 LZ 获得这个关键信息应该是挺难的。最后回到 LZ 的问题。你要做的就是：1. 开始做好两手准备，留意合适机会2. 如果你觉得公司，沟通能力挺强的，对转实施和客户经理，可以考虑多跑多刷脸，多举荐自己的。毕竟研发转实施是毕竟少的。你的优势是有技术能力，可以以一种“踏实稳重，做事靠谱的技术男”作为亮点。如果你选择了这个方向，LZ 记得在薪资和职级谈一谈，最起码平薪平级，不要降。降容易升难。

这个贴暴露了本站很多人根本不适合做技术，可能不少人是没本事搞业务才来搞技术的😀知道什么样的工厂效率高吗？每个人都有自己的明确分工，专精某一工种。而不是人人啥都会一点，谁都能随时取代谁，那样的话就是小作坊，即使规模大了也是大规模作坊而已。

这个分析很有道理

我感觉你说的有可能是真相……HR 相关的信息我没法获取，不过一个间接的暗号应该至少表示公司的盈利肯定是有所下降了的——今年年中突然开始要求强制写日报，漏写有罚款。虽然下一个月领导又不再提及日报相关的事了，但多少算是个暗示

其实这也是我疑虑的地方，技术好歹可以带到任何一个公司都有用处，但是业务知识能够用上的地方可就窄太多了，我至少现在还不想把自己锁在这个行业或者这公司上