《企业的性质》中提到，企业不断壮大，直到企业内部交易的成本大于企业外部成本，此时企业将停止增长。同样的，当业务大到一定规模，为支撑业务复杂度的不断攀升，将开始出现一些巨无霸系统，相应的带来应用系统复杂度与建设成本的提升。此时，定义清楚各个业务模块、区分业务模块和技术平台，对系统进行必要的拆分势在必行。
另一方面，应用系统的新建往往是对口某一业务部门的需求，所以在IT管理方面也会维护应用系统对应的业务部门和业务定位。然而，业务形态向着复杂化的方向发展，往往伴随着多业务部门的协同（有时是冲突），此时应用系统的业务属主将变为多元化。
回到我们的主题，很多时候技术业务难以区分，业务之间也难以划分，我们为什么要分那么清楚呢？
“如果问题都错了，那么答案也必定是错的” 。清晰定义就是为了尽量问对问题。
一、业务和技术的问题域不同
业务的问题域在于业务目标的达成电业局sg186工程营销业务应用系统讲座，关注业务形态的展现，比如APP、微信公众号、小程序等等，但并不关注技术实现细节。
技术的问题域在于高质量、低成本的研发落地，关注是否使用可靠的技术栈，技术团队是否hold住，技术栈是否可以复用也尤为关键。
因此以APP建设为例电业局sg186工程营销业务应用系统讲座，APP原生及内容管理，可以抽象下沉为技术框架，建多个APP都可复用该技术框架，这些归口为技术问题范畴。具体在APP中投放什么内容、如何布局则是为支撑业务所需考虑的，归口为业务问题范畴。
二、业务部门和研发部门之间的关联在于事、而非系统
业务部门提出的需求并不是一个系统的需求，而是一个事的需求。至于研发部门是用一个系统还是多个系统来实现的，业务部门并不关心。
因此作为研发，不应纠结所负责的系统是哪个业务部门属主，而更应关注业务事情本身。一个业务需求，有可能是多业务部门协同发起的，相应的，也有可能是多业务系统协同达成的。
过于强调一个业务系统对口一个业务部门，而不关注事情本身，就有可能各方只考虑自己系统既有的能力、而排斥其他的事情，导致业务需求不能被充分考虑、完全覆盖；也有可能所有，需求堆积在一个系统中，超出一个系统所应承载的边界，导致系统难以拓展和维护，影响应用系统的稳定性。这些都是业务边界不清、问题重点偏移所导致的问题。
真正的问题和目标，不在于研发任务的完成，在于业务效果的达成。研发部门的价值，就是理解业务、融合技术，承接业务需求和技术产品之间的桥梁，用技术的砖瓦构建起业务的大厦。
本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请添加站长微信举报，一经查实，本站将立刻删除。
如若转载，请注明出处：http://www.ibjoo.com/7874.html
