业务，似乎与开发人员不是太相关，开发人员天生处于技术端。但是，一个只会开发的开发人员，很容易被代替，只有真正了解业务，才能真正了解需求，做出好的产品。

前言

你一定经常听到“作为一名开发人员，一定要熟悉业务…blabla”类似的说法。但是当你本着“听人劝，吃饱饭”的想法，开始尝试去熟悉业务时，一些问题迎面而来：

业务到底什么？能不能具体点？业务、产品、研发之间到底是什么关系？应该如何去熟悉业务？怎么样才算了解业务？To B业务的特点是什么？……

那么如何去解决这些问题呢？

什么是业务？

我理解，业务是一个很实在的东西，就是办的什么事？怎么办事的？

记得我刚到公司实习，接触的第一个项目是某银行供应链金融智能风控。老大没有直接让我clone代码去写程序，而是拿出一个小本，一边给我讲供应链金融体系怎么回事，一边在本上给我画出了业务流程以及简单的产品架构。

那是我第一次知道了核心企业与小b、小r之间的业务及资金的关系，银行通过核心企的订单去管理上下游中小企业的资金流和物流，银行的盈利模式，我司应该从怎样的角度去建立风控模型等业务相关的知识。

了解这些“相关背景”，知道我要做什么，才能更好地知道下一步怎么做。

还是以智能风控系统做例子，假设一名技术人员小A负责开发其中一个功能模块：每天从行方指定sftp上获取当天的信贷数据，将其解析成指定格式的数据，进行一定的处理，并入库。

如果我们单纯开发，肯定很简单。但是在开发之前，我们要明确业务需求：

• 数据属性是什么？是业务平台的订单数据、期初数据还是授信数据？
• 每种数据是什么含义，有什么用途？是实时数据还是银行当日的跑批数据？实时数据的响应时间要求是多少？银行一般晚上几点跑批？几点进行对接？
• 数据如何存储，如何设计表结构设计为全表还是拉链表？
• 那些数据是需要更新，那些数据是需要存储，方便月终对账的行方对账的逻辑是什么？
• 如何设计表结构才方便对账以后出报表的时候，怎么才方便取数？

这些问题实际上是和开发没有什么关系的，但却是我们应该去了解的业务问题。

下面总结几点我的理解：

• 技术和产品服务于业务，业务方就是需求方；产品梳理业务结构，将业务转变为可行性需求；通过技术输出为工程产品，从而实现我们的核心价值。
• 开发和产品设计需要遵循一个规则——这个规则就是业务，我们依照这个规则，对业务不断地深挖、不断地细化；这样才能优化出符合业务需要的产品，从而去支撑业务、改善业务、推动业务。
• 业务领域的知识包括：我们对行业领域的思考、对业务模式的熟悉、对业务模块的理解等；是一个积累的过程，业务不是“坐而论道”，而是要在实际项目中实践，“真听真看真感受”。

为什么要了解业务？

在明确了什么是业务问题后，很多同学可能会认为：“我是一名开发人员，我只需要按照要求去写代码就好了啊；即使后续有什么问题，那也不是我的锅啊。

其实这种想法没什么毛病，但是这样就可以满足了么？

首先我们要明确一个观点：不管是开发人员还是数据分析人员，都要熟悉业务。

对于技术人员来说，有两种大牛：一种是技术大拿，技术团队中的定海神针，可以不食人间烟火；另一种就是如何能够利用手中的技术去解决某一方面的业务问题，从而产生了什么价值。

懂业务就是懂需求，就是懂得换位思考。我们讲共情心，我们都不知道对方想要什么，怎么能做出满意的产品。技术是我们的手段，但不是目的。业务方想要的是各种数据分析结论的落地，是能够产生价值的工程产品。

如果我们不去了解业务，那么就要警惕变为“被动执行者”，在居士的《数据团队思考：数据驱动业务，比技术更重要的是思维的转变》一文中提到：

被动执行者完美地完成业务需求，但没有主动去发现和提出问题。被动执行者在数据相关的工作中，一般来讲主要是各种完成业务的报表、业务提数需求和一些业务方想法的验证。如果你一直处于这种角色，那么，请注意，公司是永远都不缺被动执行者的，你的工作可能很快会被外包同学替代。

这个世界，缺的是技术过硬又精通业务的工程师，缺的是真正能解决实际业务问题的人，缺的是复合型的人才。

了解业务，说白了就是对自己的团队的资源非常熟悉，并且洞悉和掌握了公司的流程，知道如何利用这些资源和流程来完成业务目标。

一个产品、一个项目，能否落地、如何落地、整体的判断，都依赖于对自身业务的了解。因此，开发人员要做的不仅仅是去满足业务的需求，而是要去了解业务的背景。参与到设计阶段，使技术可行性和产品需求更契合。

一方面降低了产品经理与开发之前的沟通成本；另一方面在开发之前尽可能地将各个方面考虑清楚，有助于把开发任务拆解的简明、清晰，既提高了开发效率，又避免了后续因为业务逻辑问题而对代码进行的修改和调试。

可以说尽可能的去了解业务，是一名开发人员的职业素养。

如何去了解业务？

如何了解业务：

可以遵循“面-线-点”的方式，先从宏观上去了解行业以及公司的整体业务，然后是某个垂直领域，最后再深入到具体的业务场景。

首先要认清楚公司的业务模式、组织架构、部门角色以及KPI。在熟悉了基本信息之后，就要从自己所接触的业务框架和业务流程学起，这个时间段需要做的就多看，多问，多做。

• 多看：多看公司内部文档，包括需求文档、产品白皮书、原型图、产品帮助文档、使用手册、成功案例等等与公司业务相关的文档。
• 多问：用正确的提问方法，在恰当的时机，找相关的人去问合适的问题。关于以上四个形容词，可以自行理解。
• 多做：自己在看和问的时候有所产出。比如，看文档或系统时，去梳理整体业务流程，动手画出大致地系统流程图来，也可以是系统框架，系统功能模块等；将问的问题与自己的感悟相结合，做总结；多使用公司的产品，多跑业务流程，去分析流程后的业务细节，通过数据、代码、动作去理解。

在“做”这个过程中，我们可以进行“角色扮演”：

• 把自己当作用户，去熟悉使用过程；
• 把自己当作是测试，审核需求及流程完整度；
• 把自己当作产品，理解产品设计；
• 把自己当作开发，去深挖业务细节；
• 把自己当作架构，学习其架构设计等等。

关于To B业务

最后再简单地说一下To B的业务。

To B就是面向企业，To B产品本质是帮助企业提高生产效率的工具，企业消费，除了有可见的购买成本，还有不可见的更高昂的维护和迁移成本。

因此整个过程是是理性的、专业的、团队化决策的，每次采购，涉及的关键角色很多，至少有使用方、评估方、预算方、拍板方、签字方共同参与。不像个人的冲动消费，完全是个人决策，如在淘宝买一件衣服、安装一个APP。

To B产品还有一个非常重要的点，就是和企业客户的业务流程是高度相关的。

如果对目标客户的业务不了解，本来能匹配的需求就可能被忽略，本来能正确交付的产品就可能交付错误。对不同领域的客户，如果不明确目标需求，就会出现交付服务不匹配，客户问题没得到解决等问题。

因此To B公司，更需要去了解业务。

总结

针对以上内容做一个总结。

• 什么是业务？我的理解是：业务是产品和服务实现价值的目标，是在设计和研发阶段需要遵循的准则，是价值的量化体现。
• 为什么要了解业务？摆脱“被动执行者”，可以从更高的层面去看待问题。
• 如何了解业务？多看多问多做。

最后还要说一句，本文只提供一些对业务重要性的认识及了解业务的方法论。在实际工作中，业务与本职工作的结合和取舍，还要自行把握。

坦白说，做这些并不能为你带来立竿见影的高处，更多的是一个积累的过程，只有厚积薄发才能水到渠成。

另外我们做一件事的时候，需要时刻提醒自己，要想清楚三个问题：

1. 弄清楚，为什么做这件事？做这件事的价值是什么？
2. 去思考，如何做这件事？
3. 完成后的产出是什么？明确衡量标准。

以上三个问题虽然简单，但确是简单有效的方法论（来自阿里某资深产品经理的），需要时刻牢记。

作者：Japson。某人工智能公司AI平台研发工程师，专注于AI工程化及场景落地。公众号：木东居士（ID：Data_Engineering）

来源：https://mp.weixin.qq.com/s/L1hCgTOs2IM92AkLQNPzfw

本文由 @木东居士 授权发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议