开发人员如何从理解代码到理解业务？本文提供了一种逐步深入理解业务的方法，帮助开发者更好地支持业务发展。
原文标题：开发同学如何理解业务？
原文作者：阿里云开发者
冷月清谈：
首先，理解实现是指开发者能够根据需求文档进行开发，并了解技术实现方案。其次，理解需求是指开发者需要理解用户是谁，他们的使用场景是什么，以及需求能够解决什么问题。接着，理解业务是指开发者需要了解业务的客户和用户是谁，业务能解决什么问题，以及业务能给公司带来什么价值。最后，理解行业是指开发者需要了解行业的现状、竞争对手以及公司在行业中的定位和战略。
文章还强调了上下游质检的重要性，即开发人员需要对需求文档、设计稿、接口文档等进行质检，以确保高质量、高效率地进行开发。此外，文章还介绍了一些帮助理解业务的方法，例如圆桌研发模式、让开发人员参与业务部门的会议，以及开发人员亲身参与和体验业务应用等。
怜星夜思：
2、除了文章提到的方法，大家还有哪些理解业务的好方法？
3、作为开发人员，理解业务对我们个人的职业发展有什么帮助？
原文内容
阿里妹导读
本文深入探讨了理解业务的重要性及其对于软件开发流程的深远影响。
一、什么是业务？
业务是指一个企业或组织所从事的主要活动，包括生产、销售、服务等方面的工作。简单来说，业务就是公司或组织为了实现其目标而进行的各项活动和操作。在软件开发中，理解业务意味着要了解客户的需求和问题，并加以解决。只有深入了解业务，开发人员才能设计出更符合客户需求的软件系统。--- 来自 ChatGPT
二、为什么业务难以理解？
为什么理解业务这么难呢？个人理解有以下几点原因：
1.通过上面对业务的定义来看，业务是一个非常笼统的概念，导致理解起来不是那么容易。
2.俗话说：“隔行如隔山”。对于一些 C端业务还好，因为自己可能就是用户，能够更好代入业务，知道用户需要什么。而对于一些 B 端业务，往往个人很难深入接触该业务，只能通过产品的需求来了解业务。
3.真实情况是，很多业务线，天天思考业务的业务同学都洞察不出业务真正的痛点，靠开发或其他角色去补位，绝大部分情况下就是个伪命题，“深入业务”很容易变成一句 PUA。
4.很多业务知识是需要日积月累的，大部分是以“年”为单位的。
三、我们需要理解业务吗？
理解业务看起来是一个非常困难的过程，所以我们还需要理解业务吗？回答肯定是不容置疑的。如果我们对业务没有足够的理解，肯定也就没办法支持好业务。
四、理解业务的优点
1.能够帮助我们更清晰地理解需求，减少理解差异，减少返工。
2.能够帮助我们去思考需求的合理性，以技术视角给出一些建议，帮助产品优化需求，这也是支撑好业务的基础。
3.能够帮助我们去发现更真实的需求，用专业的决策去支撑业务。
4.能够帮助我们评估需求的优先级，合理利用资源。
5.能够帮助我们找到技术的发力点，使用合适的技术去高质量支撑业务。
6.更够让自己更有参与感，而不只是一个工具人。
理解业务的优点还有很多，这也是我们为什么需要理解业务的原因。
五、如何理解业务？
说了这么多，那么到底怎么去理解业务呢？上面说到业务是一个非常笼统的概念，所以要理解它肯定也不是一蹴而就的。理解肯定是从浅到深的，主要分为以下几个层级：
(一) 理解实现
简单来说就是拿到需求文档之后，我知道该怎么去实现这个需求，比如用什么技术栈？用什么工具或组件？主要有以下几个要点：
1.能够根据需求文档梳理清楚需求，产品功能逻辑
2.知道具体该如何实现这个需求，是否有现成的工具或组件能够支持。如果没有，应该如何去调研？（这对于确定开发排期很重要）
3.梳理清楚需求后，可以再梳理下实现该需求都需要哪些接口
以上这些都是实现需求最基本的要求，能做到这些基本就可以顺利的完成需求。但是为什么会有这个需求？这个需求要解决的问题是什么？有没有更好的解决方式？这些就不在这一层的考虑范围之内了，所以常常处于这一层的同学会觉得自己是一个工具人。
(二) 理解需求
在互联网产品开发中，需求是指用户对产品的期望和要求，包括功能需求、性能需求、用户体验需求等。通俗的定义是人们对产品的期望和要求。比如我饿了想吃饭，我想吃米饭，但是你给我一碗面条，那就是没有满足我的需求。
如何理解需求，需要想清楚这几个问题：
3.这个需求能够帮用户解决什么问题？
了解了这些之后我们可以将自己代入用户视角，想想自己面对这个问题时，我的需求是什么？我希望这个系统是什么样的，能帮我解决什么问题？然后根据自己在技术方面的经验和思考，给出一些意见和建议，将自己的理解融合到系统开发中。这样就算是跨入了支持好业务的门槛：有参与，有思考，有理解
(三) 理解业务
理解了需求能够让我们更好地支持需求，但是能不能更好地支持业务却不一定。因为业务是一个比较笼统的概念，不像需求那么具体。即使做好了每一个需求，也不一定能做好这个业务。要想抓住业务的关键点，就需要更加深入地探索真实的业务。我们需要探究以下几个问题：
1.这个业务的客户是谁？用户是谁？（客户不一定等于用户，使用产品和服务的是用户，购买产品和服务的是客户）
2.这个业务能够解决客户的什么问题？能够解决用户的什么问题？
3.这个业务能给公司解决什么问题？能给公司带来什么价值？
如果能深入了解到这些问题的答案，那么就可以从一个更高的视角来看待业务，知道业务的重心在哪里，从而也就能知道该从哪个方向去促进业务的发展，在技术和设计方案上也能更加前置和全面地进行思考。
(四) 理解行业
1.了解这个行业的现状，友商都有哪些，他们是怎么做的？
2.了解公司在这个行业的布局、优劣势、目前所处的位置和战略规划等等。
六、其他思考
(一) 上下游质检
一个产品往往是多个角色分工协作的产物，一般包括：业务方，产品，研发，设计，测试等等。一个产品做出来，业务觉得不好用，研发说产品需求和设计就是这样，产品说业务提的需求不明确，业务说反正就是不好用。到头来也不知道是谁的问题。
整个流程其实是环环相扣的，上游链路没想清楚，下游跟着一起肯定也就走歪了，习大大说过“人生就像扣扣子，第一颗扣子扣错了，下面的都会错”。
所以对于上游链路的质检就变得很重要。在传统流水线作业中，下游必须保证上游提供的产物是符合要求的，否则就没办法继续加工，如果每个环节的零件都是不符合要求的，那么最终生产出来的产品肯定也是不合格的。
作为产品需要对业务方的需求进行质检（去除不合理的需求，补充完善不清晰的需求，把抽象的业务需求具象化为产品能力）。
作为前端，我们需要对于上游（需求文档、设计稿、接口文档）进行质检，才能确保我们在业务支撑中更加高质量、高效率地前行。那如何有效地进行质检？就需要我们做到理解需求，理解业务。
(二) 帮助理解业务的方法
圆桌研发模式是一种集体智慧和协作的研发方法，它强调团队合作、信息分享和平等参与，以实现高效的创新和问题解决。在这种模式下，团队成员可以围绕一个共同的问题或项目展开讨论和合作，每个人都有机会发表自己的观点和想法，同时也会受到他人的启发和影响。
举例来说，一个公司的研发团队在开发一款新产品时可以采用圆桌研发模式。团队成员可以每周举行一次圆桌讨论会，共同探讨产品的功能设计、技术实现、用户体验等方面的问题。每个成员可以就自己负责的部分发表看法，同时也可以提出对其他部分的建议或意见。通过这种方式，团队可以充分发挥集体智慧，快速找到最佳解决方案，推动产品的迭代和优化。
圆桌研发模式能够激发团队成员的创造力和合作精神，促进项目的成功进行。它也可以帮助团队成员之间建立更加紧密的联系，提高协作效率。因此，这种研发模式在企业创新和项目开发中得到了广泛的应用和认可。
这样不仅提高了他们对业务需求的理解，还促进了技术团队与业务团队之间的沟通，从而提高了项目的交付效率和质量。
开发人员也可以亲身参与和体验业务应用，观察用户是如何使用产品的，业务流程是怎样运转的。可能阅读再多的文件资料也不如亲身体验，亲眼所见。
互联网应用全球加速
互联网应用加速解决方案面向各行各业的互联网应用，提供一站式加速网络访问、提高网络稳定性的服务。
点击阅读原文查看详情。