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

技术框架可能更新换代，而业务领域知识是长期的，更多依靠积累的。如果可以的话建议你尽量在某个行业深耕下去，你将比不断换行业的工程师更具优势。只有对业务有了深入的理解才能设计出更加灵活健壮的程序。我刚开始接触电商业务开发的时候，不明白为什么会有个主目录和销售目录的概念。后来深入电商业务，并结合现实生活中商城中的卖场和仓库不同的类目管理才明白其中的道理。

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

如果你的公司业务发展起来了，实现了你的技术抱负，那么恭喜你能有这样的机遇，因为很多程序员没有这样的机会（绝大部分的项目生命周期都很短）。这个时间还不是终点，在达到业务规模的某个临界点时要思考一下你们技术壁垒是否足够高，可以反过来驱动业务前行，让对手没有望见你项背的机会。这个时候你甚至要摒弃已有的认知，通过更加全面、深入的业务复盘，采用面向未来的业务架构设计来构建地基，方能建立万丈高楼。

这里我分享一下自己对业务的分类理解，参见下方图片。主要是toC和toB，简单来看二者差别是决策流程不同，企业的购买决策不是由一个人决定的，而是由流程来决定的。

下一篇【产品篇】将讨论业务是如何服务于用户的。