程序员探险记8-业务篇-载体-CSDN博客

本文链接：https://blog.csdn.net/kingtao_1985/article/details/100072691

通俗的讲业务就是用户的痛点。没有用户，就谈不上业务。业务为公司直接带来收入，而技术则是解决问题的工具。技术如果脱离了业务，那么技术应用就无法很好的落地，技术的研究也将失去场景和方向。业务是支撑着公司向前发展的载体。

技术框架可能更新换代，而业务领域知识是一直延续的，更多依靠长期积累的。如果可以的话建议你尽量在某个行业深耕下去，你将比不断换行业的程序员更具优势。只有对业务有了深入的理解才能设计出更加灵活健壮的程序。我刚开始接触电商业务开发的时候，一直不明白为什么会有个主目录和销售目录的概念。后来深入电商业务，并结合现实生活中商城中的卖场和仓库不同的类品摆放位置才明白其中的道理。技术与业务就像锤子和钉子。目前来讲，手握锤子再找钉子难落地；而有钉子，甚至找个石头也可以解决问题。

在研发过程中，我们不可避免要与各个业务方打交道。所以仅仅认识到业务的重要性还不够，你还要多站在业务方的角度想想他们最关注的是什么。帮助他们取得成功，才能成就你自己。合作共赢已经是这个时代的趋势。这里不得不再提一下【面试篇】和【职业篇】都引用了的《高效能人士的七个习惯》，其中第四个习惯——双赢思维。特别是关于工程师和产品经理的恩怨情仇想必大家都知道。相信这里面肯定有很多客观原因，甚至可能是组织架构的问题。但主观的因素同样重要，想要跨越这样的思维鸿沟，需要改变思维，通过沟通取得互相理解。毕竟大家的目标是一致的。

如果你的公司业务发展起来了，实现了你的技术抱负，那么恭喜你能有这样的机遇，因为很多程序员没有这样的机会（绝大部分的项目生命周期都很短）。这个时间还不是终点，在达到业务规模的某个临界点时要思考一下你们技术壁垒是否足够高，可以反过来驱动业务前行，让对手没有观你项背的机会。这个时候你甚至要摒弃已有的认知，通过更加全面、深入的业务复盘，采用面向未来的系统架构设计来构建地基，建立万丈高楼。就像Amazon的贝佐斯2002年的API命令和两个披萨原则，在微服务概念都还没有流行起来之前就看清了未来的趋势。

这里我分享一下自己对业务的分类理解，参见下方图片。ToC和ToB，表面看二者差别主要是决策流程不同，企业的购买决策不是由一个人决定的。实际上ToC产品解决的是一个确定的问题域，需求比较具象和聚焦。但在ToB领域里完全不同，在企业信息化中，要满足企业中各层级的不同角色职能的最终使用者，在不同的业务场景下的需求。即使是一个行业，也分为大中小型企业；即使是同一个公司，也分为早中晚不同时期的管理模式。可以说，永远不可能凭借想象来穷举所有遇到的需求，需求是无穷无尽的。所以B端成熟的SAAS产品未来往PASS方向发展，做到更弹性灵活也许是云服务时代的一个趋势。