【经典回顾】浅谈B端产品工作中的业务设计和应用设计

2023年写了不少比较优秀的原创文章，但是由于微信公众号的推荐机制问题，可能后面关注公众号的朋友就错过了这些文章。所以后续我会不定期地翻阅之前的经典、优秀的文章，然后重新推送一遍。看过的朋友可以再看一次，加深印象和理解；没看过的朋友也不用每次去翻阅历史的文章，直接看我重发的内容即可。

背景

2022年下半年的时候我大力推荐过一本书，叫作《大话软件工程：需求分析和软件工程》，这本书的体系化知识讲得很好，将产品日常的工作分成了两大块，一个是需求工程，一个是设计工程。

需求工程中主要的工作内容是：需求调研和需求分析。

设计工程中主要的工作内容是：业务设计、应用设计和技术设计。产品主要关注的就是业务设计和应用设计。

初看此书的时候，我有一个很明显的疑问，那就是：

什么是业务设计？什么是应用设计？这两者有什么区别？为啥业务设计有概要设计和详细设计，而应用设计就没有？

看完此书一段时间之后，我对这一块的知识有一个模糊的记忆，但是感觉还是没有吃透。在上周的时候，和一个创业公司的老板交流他们的项目的时候，我突然发现：哎呀，业务设计和应用设计的区别我好像知道了。

创业老板外包研发系统的故事

这个老板是做跨境物流业务的，客户是在海外，然后在国内的电商平台下单，把货物寄送到自己的仓库，然后国内仓库进行预加工（质检，贴标，装箱等）后，再通过头程物流送到国外的海外仓或者亚马逊仓库。由于业务比较复杂，涉及的环节和链路比较长，然后本人又是比较open的心态，想要拥抱数字化改革，搭建一整套业务系统。

不过由于自己的公司规模还不是很大，自己养研发团队比较烧钱，于是就选择用IT外包的方式来搭建这样一整套的系统。在我和他的深入交流过程中，他感慨，这样一套系统研发太难了，自己从0开始学产品，然后做了很多业务梳理的工作，最后交付给外包团队的时候，还是踩了很多坑。

• 外包团队没有跨境的经验，很多基础是行业术语在前期花了很大力气去解释，但是后续工作过程中还是会犯错踩坑；
• 外包团队的产品经理本身经验不是很丰富，能力也不是很突出，再加上没有行业经验，很多需求场景考虑不周全，需要老板自己亲力亲为去关注一些细节的事情，累得半死，进度还很慢；
• 外包团队交付的质量不及预期，内部验收的时候发现很多业务逻辑、业务场景、业务细节、系统体验等方面等都不达标，还需要返工修改一两次才算勉强能用；
• 整套业务体系包含多个系统，自己虽然懂业务，但是不懂产品架构设计，不知道怎么划分领域，怎么划分系统，怎么做数据流转的设计，怕自己的架构搭建的不好，到时候又要推翻重来；
• ……

在交流的过程中，我突然就get了业务设计和应用设计的区别，而这个老板踩的一个坑之一就是模糊了业务设计和应用设计的一些边界，导致自己有些时候过于深入到应用设计层，从而被一些小细节、决策点给困住了。

下面，我来给大家简单拆解一下，分享我对这一块的理解和认知，如果有什么不当之处，欢迎大家拍砖点评。

什么是业务设计

先看看书上对于业务设计的基本定义是怎么样的：

业务设计部分含概要设计和详细设计两个阶段。业务设计的重点是对业务优化、业务功能以及业务价值的设计。成果包括设计规范、业务架构、业务功能等。

业务设计，是将“需求”放在“业务”这个背景中去思考、设计的。明确功能是为业务提供信息化支持服务的。也就是说，功能需求的真伪、包含的内容、处理的形式等都是通过对客户业务处理过程的充分理解后才能确定的。

这两段话我觉得已经很简洁地将业务设计的核心给指出来了，很多时候我们聊到“产品设计”的时候，一般都会用“需求设计”或者“产品设计”等词语来概括，所以就很容易将设计的过程理解为只有一个。当作者提出有业务设计和应用设计的时候，我们会有一点点懵逼，不太能直观地理解这个区别。

回到上面的创业老板的案例中。老板和他的同事们，对整套线下的业务链条非常熟悉的，一共有几条业务线，每条业务线有多少个环节，然后业务线上的节点分别是什么角色做什么事情，具体的事情要怎么做，结果是怎么样等，都非常的清楚。

但是，如果要做一整套信息化系统，要将线下的一些流程搬到线上去，这件事难度就突然陡增了。线下的业务具有高度的灵活性，员工可以采用不同的应对方式去处理，但是线上化处理必然就是标准化的东西，这样才能发挥系统的最大优势。

那，线下的业务，有哪些是可以标准化的，有哪些是可以搬到线上去的，有哪些是需要整合调整的？

这就是面临的最大难题！

所以，梳理线下的业务需求，完成对业务层的设计就非常的重要了。而这一块，往往让懂业务且又稍微懂一些系统架构设计的人去做是最好的，但是这样的复合型人才比较稀有，所以往往会造成“懂业务的人不懂产品，懂产品的人不懂业务”这样的窘境。

而上面提到的这老板，他就遇到这样的窘境。自己花了很多时间精力去梳理业务，去完成业务设计，但是交付给外包团队的产品经理的时候，由于这一层不是产品经理设计的，所以就会导致在应用设计的时候频繁踩坑，不能很好衔接起来。

业务设计和应用设计如果是一个人来做，从头跟到尾，是最好的。在常规的IT研发团队中，如果不是特别大的项目，一般来说一个产品经理从头跟到尾的情形很多，但是在这种IT外包的场景下，由于对方对业务并不是很熟悉的情况下，就会出现“两头衔接”的情形，信息就会有一些不对等。

业务设计的前提是抛开系统设计的一些细枝末节的东西，专注在业务层的梳理，了解实际业务是怎么发生的，有多少链路，多少节点，多少相关方，多少工作事项，然后将这些内容划分成不同的业务领域，各个领域有对应的业务流程，业务模块，业务动作和数据等。

什么是应用设计

了解了业务设计之后，我们再来看看，什么是应用设计，先看看书本上的定义:

应用设计，是将业务设计成果结合技术实现的要求，给出系统开发完成后的应用样式和应用模式。在业务设计阶段，是站在客户的业务视角来看待设计对象的，此时尚未考虑如何实现系统。进入了应用设计阶段后，就把业务设计的要素看成是系统“构件（或是零件）”，此时的关注点已不在业务方面，而是放在构建“人-机-人”的信息化工作环境方面，重点是实现企业管理的信息化、智能化的设计。

简单来说，可以把应用设计理解为具体的系统设计和功能设计。有多少个系统，每个系统有多少模块，有多少功能，有多少数据，系统、模块、功能之间是怎么联动的等这些都是在应用设计阶段去完成的。

这一部分就是大多数B端产品经理日常在做的内容，梳理业务流程，设计产品结构图，画原型，写文档，然后评审需求，交付给研发去做技术设计等……

应用设计是业务设计和技术设计之间的桥梁，应用设计的目的就是要从用户应用的视角出发，在软件开发完成前就可以预知完成后的价值和效果（效果不仅是界面的颜色、布局）。

业务设计和应用设计怎么使用

上面对业务设计和应用设计都做了一个大概的介绍，相信大家已经get到了它们的区别和各自的价值、效用等，那么在日常的实际工作中，这一块应该要怎么去使用呢？

一定是要先业务设计然后再应用设计吗？我之前搞的那一套是不规范的吗？除了2B领域，2C的产品适用吗？

结合我自己日常工作中的一些方法论，我认为：

1. 先业务设计，再应用设计，这个事情2C领域用的很少，可以说几乎不太适用；
2. 业务设计和应用设计的本质都是为了输出一套解决方案，而拆分成两个部分来做，是因为当业务场景比较复杂的时候，这样划分更利于方案的输出，所以如果业务比较简单，可以直接应用设计就好了；
3. 对于2B领域来说，也不是说非要单独将业务设计拆出来，一些简单业务其实可以在应用设计的时候，加上一些业务逻辑的梳理，可以算是简单版本的业务设计了；

业务设计的前提是业务复杂，繁琐，需要有专门的人进行整理和梳理，然后站在一个非技术的角度去思考怎么解决，优化这个业务。如果这个东西很简单，就类似于日常的登录，注册，提交表单数据等场景，完全用不上业务设计，也不用招相对应的人去做这件事。

拿上面老板的他们仓库收货的场景来说，站在业务设计的角度，可以从这么几个点去输出对应的业务设计方案：

1. 需要先梳理一下仓库收货的全流程是怎么样的，货物怎么送过来？是否要提前预报？如果没有预报怎么处理？
2. 货物收到之后，要怎么处理，一般会有几个流程，有哪些关键节点，每个节点大概的输出物和完成的标准是怎么样的？
3. 当前的收货流程有哪些是标准化的，哪些是非标准化的？当前的流程中有哪些东西可以优化，可以改进，可以提升效率？
4. 假设上了信息系统之后，哪些地方是需要用系统的，哪些是不需要的？用系统的部分能带来哪些提升，有哪些变化是需要员工学习和适应的；不用系统的部分能不能“复杂的事情简单化，简单的事情标准化，标准的事情流程化”？
5. 最后，将业务梳理后的结果整理输出一份比较丰富的文档，拿着这样一份文档可以跟大家讲解清楚我的业务当前是怎么跑起来的，引入信息系统之后是怎么跑起来的，信息系统要支撑哪些方面的业务和场景等；
6. 拿到了业务设计后的文档，就可以和应用设计的产品经理打交道了，不过这个过程也是一个困难且痛苦的过程；因为应用设计的产品经理毕竟是没有接触过具体的实际业务，只有这么一份文档还是会有很多困惑，但是如果有机会让其参与具体的业务或者多给一些时间调研和梳理话，对于有一定能力的产品经理来说还是能达到快速上手的效果的，这也是业务设计的核心价值之一：推动下一步的应用设计；

总结

其实在写这篇文章之前，我感觉灵感很多，启发很多，动力也很足，但是等写到了一半之后我发现有一些概念和案例好像用文字还是挺难讲解清楚的。

在我和那位老板的沟通过程中，我深刻地感受到了业务设计这一块的断层对应用设计的影响是巨大的，懂业务的人并不一定懂“业务设计”，懂产品、懂应用设计的人不一定懂业务、也不一定懂“业务设计”，所以就导致最终的交付结果非常的不尽如人意。

我发现挺多产品相关的课程和文章都很侧重在讲应用设计方面的知识，这一块细枝末节的东西非常多，导致课程或者文章内容很长，但是最终可能交付的东西就是一个很垂直的点。大家学习的多了，接触的多了就会习以为常，认为好像产品就应该多花时间钻研一下“应用设计”这一块的内容，从而忽视了业务设计方面的锻炼。

以上就是我对业务设计和应用设计的一些小感触，小思考，希望对大家有所启发。

最后，还是建议大家去啃一下这本书，里面有挺多章节的内容让我非常受启发的，尤其是一些2B或者2G的产品，经常要涉及到一些复杂业务流程的方案输出，那么就可以多啃啃。