一、什么是业务？

业务是指一个企业或组织所从事的主要活动，包括生产、销售、服务等方面的工作。简单来说，业务就是公司或组织为了实现其目标而进行的各项活动和操作。在软件开发中，理解业务意味着要了解客户的需求和问题，并加以解决。只有深入了解业务，开发人员才能设计出更符合客户需求的软件系统。--- 来自 ChatGPT

二、为什么业务难以理解？

为什么理解业务这么难呢？个人理解有以下几点原因：

1.通过上面对业务的定义来看，业务是一个非常笼统的概念，导致理解起来不是那么容易。

2.俗话说：“隔行如隔山”。对于一些 C端业务还好，因为自己可能就是用户，能够更好代入业务，知道用户需要什么。而对于一些 B 端业务，往往个人很难深入接触该业务，只能通过产品的需求来了解业务。

3.真实情况是，很多业务线，天天思考业务的业务同学都洞察不出业务真正的痛点，靠开发或其他角色去补位，绝大部分情况下就是个伪命题，“深入业务”很容易变成一句 PUA。

4.很多业务知识是需要日积月累的，大部分是以“年”为单位的。

三、我们需要理解业务吗？

理解业务看起来是一个非常困难的过程，所以我们还需要理解业务吗？回答肯定是不容置疑的。如果我们对业务没有足够的理解，肯定也就没办法支持好业务。

四、理解业务的优点

1.能够帮助我们更清晰地理解需求，减少理解差异，减少返工。

2.能够帮助我们去思考需求的合理性，以技术视角给出一些建议，帮助产品优化需求，这也是支撑好业务的基础。

3.能够帮助我们去发现更真实的需求，用专业的决策去支撑业务。

4.能够帮助我们评估需求的优先级，合理利用资源。

5.能够帮助我们找到技术的发力点，使用合适的技术去高质量支撑业务。

6.更够让自己更有参与感，而不只是一个工具人。

理解业务的优点还有很多，这也是我们为什么需要理解业务的原因。

五、如何理解业务？

说了这么多，那么到底怎么去理解业务呢？上面说到业务是一个非常笼统的概念，所以要理解它肯定也不是一蹴而就的。理解肯定是从浅到深的，主要分为以下几个层级：

(一) 理解实现

简单来说就是拿到需求文档之后，我知道该怎么去实现这个需求，比如用什么技术栈？用什么工具或组件？主要有以下几个要点：

1.能够根据需求文档梳理清楚需求，产品功能逻辑

2.知道具体该如何实现这个需求，是否有现成的工具或组件能够支持。如果没有，应该如何去调研？（这对于确定开发排期很重要）

3.梳理清楚需求后，可以再梳理下实现该需求都需要哪些接口

a.根据需求文档，梳理实现需求需要的接口；

b.确定接口的入参和出参（数据格式和字段说明）；

c.接口的调用流程也要写清楚；

d.和后端逐条核对接口，有问题的及时讨论确定。定下最终的接口文档，前后端都需要严格遵守。然后就可以开始开发了（前端可以先根据接口文档 mock 数据）；

以上这些都是实现需求最基本的要求，能做到这些基本就可以顺利的完成需求。但是为什么会有这个需求？这个需求要解决的问题是什么？有没有更好的解决方式？这些就不在这一层的考虑范围之内了，所以常常处于这一层的同学会觉得自己是一个工具人。

(二) 理解需求

在互联网产品开发中，需求是指用户对产品的期望和要求，包括功能需求、性能需求、用户体验需求等。通俗的定义是人们对产品的期望和要求。比如我饿了想吃饭，我想吃米饭，但是你给我一碗面条，那就是没有满足我的需求。

如何理解需求，需要想清楚这几个问题：

1.这个需求的用户是谁？2.这些用户提出这个需求的场景是什么？

3.这个需求能够帮用户解决什么问题？

了解了这些之后我们可以将自己代入用户视角，想想自己面对这个问题时，我的需求是什么？我希望这个系统是什么样的，能帮我解决什么问题？然后根据自己在技术方面的经验和思考，给出一些意见和建议，将自己的理解融合到系统开发中。这样就算是跨入了支持好业务的门槛：有参与，有思考，有理解

(三) 理解业务

理解了需求能够让我们更好地支持需求，但是能不能更好地支持业务却不一定。因为业务是一个比较笼统的概念，不像需求那么具体。即使做好了每一个需求，也不一定能做好这个业务。要想抓住业务的关键点，就需要更加深入地探索真实的业务。我们需要探究以下几个问题：

1.这个业务的客户是谁？用户是谁？（客户不一定等于用户，使用产品和服务的是用户，购买产品和服务的是客户）

2.这个业务能够解决客户的什么问题？能够解决用户的什么问题？

3.这个业务能给公司解决什么问题？能给公司带来什么价值？

如果能深入了解到这些问题的答案，那么就可以从一个更高的视角来看待业务，知道业务的重心在哪里，从而也就能知道该从哪个方向去促进业务的发展，在技术和设计方案上也能更加前置和全面地进行思考。

(四) 理解行业

1.了解这个行业的现状，友商都有哪些，他们是怎么做的？

2.了解公司在这个行业的布局、优劣势、目前所处的位置和战略规划等等。

六、其他思考

(一) 上下游质检

一个产品往往是多个角色分工协作的产物，一般包括：业务方，产品，研发，设计，测试等等。一个产品做出来，业务觉得不好用，研发说产品需求和设计就是这样，产品说业务提的需求不明确，业务说反正就是不好用。到头来也不知道是谁的问题。

整个流程其实是环环相扣的，上游链路没想清楚，下游跟着一起肯定也就走歪了，习大大说过“人生就像扣扣子，第一颗扣子扣错了，下面的都会错”。

所以对于上游链路的质检就变得很重要。在传统流水线作业中，下游必须保证上游提供的产物是符合要求的，否则就没办法继续加工，如果每个环节的零件都是不符合要求的，那么最终生产出来的产品肯定也是不合格的。

作为产品需要对业务方的需求进行质检（去除不合理的需求，补充完善不清晰的需求，把抽象的业务需求具象化为产品能力）。

作为前端，我们需要对于上游（需求文档、设计稿、接口文档）进行质检，才能确保我们在业务支撑中更加高质量、高效率地前行。那如何有效地进行质检？就需要我们做到理解需求，理解业务。

(二) 帮助理解业务的方法

圆桌研发模式

圆桌研发模式是一种集体智慧和协作的研发方法，它强调团队合作、信息分享和平等参与，以实现高效的创新和问题解决。在这种模式下，团队成员可以围绕一个共同的问题或项目展开讨论和合作，每个人都有机会发表自己的观点和想法，同时也会受到他人的启发和影响。

举例来说，一个公司的研发团队在开发一款新产品时可以采用圆桌研发模式。团队成员可以每周举行一次圆桌讨论会，共同探讨产品的功能设计、技术实现、用户体验等方面的问题。每个成员可以就自己负责的部分发表看法，同时也可以提出对其他部分的建议或意见。通过这种方式，团队可以充分发挥集体智慧，快速找到最佳解决方案，推动产品的迭代和优化。

圆桌研发模式能够激发团队成员的创造力和合作精神，促进项目的成功进行。它也可以帮助团队成员之间建立更加紧密的联系，提高协作效率。因此，这种研发模式在企业创新和项目开发中得到了广泛的应用和认可。

让开发人员参与业务部门的会议

这样不仅提高了他们对业务需求的理解，还促进了技术团队与业务团队之间的沟通，从而提高了项目的交付效率和质量。

开发人员亲身参与和体验

开发人员也可以亲身参与和体验业务应用，观察用户是如何使用产品的，业务流程是怎样运转的。可能阅读再多的文件资料也不如亲身体验，亲眼所见。

来源  |  阿里云开发者公众号

作者  |  万杰