B端产品为企业提供协同办公的工具，帮助企业解决某类经营管理问题，核心价值在于为企业增加收入、降本提效、管控风险，企业级SaaS产品也是B端产品中的一类。

　　客户是一个群体：B端产品为某个企业组织服务，一项工作通常需要由多名角色完成，例如，门店要货流程，需要门店店员、总部运营、仓储人员、配送人员共同完成，B端产品帮助他们完成分工协作。

　　功能繁杂：由于B端产品涉及企业经营的方方面面，关联的用户角色、业务流程非常繁多，反应到产品上，菜单、界面、配置项特别多，复杂度远高于C端产品。为了实现一项功能需求，往往会影响其他许多功能，需要进行全面的梳理，考虑各种极端情况，才能保证整体功能正常。

　　定制化功能：B端产品必然会有很多定制化需求，如果一味抗拒，很容易丢掉一些优质客户，但如果大包大揽地接受，系统复杂度会指数级上升，高昂的研发维护成本将很难承受，所以如何处理好定制化需求，是一项非常艰巨的任务。

　　见效慢、难量化：由于B端产品的客户是一个群体，产品上线新功能，通常是管理层先评估，能否在企业中适用，如果合适，才会组织一线人员，进行操作培训。这样一来一回，可能要2个月后才有客户正式使用新功能。

　　其次，业务见效的影响因素非常多，很多时候并非因为B端产品设计问题。例如，采购部门核心目标是找到更多优质、低价供应商，而这主要依赖采购员的专业能力，以及商家的管理能力，很难衡量产品功能对商家业务的实际贡献。

　　正是由于B端产品这些复杂性，要写好一份B端产品的技术方案，是非常有挑战的事情，对最终项目价值达成起到决定性的作用，技术方案质量差可能直接毁灭一块业务。下面推荐一份B端产品的技术方案模板，供读者参考。

　　B端产品中的专业名称非常多，对专业名词进行汇总解释，方便项目组理解上下文，统一认知。

　　介绍项目的背景，为什么需要做这个项目，解决了用户哪些痛点，为用户创造什么价值，或者是技术价值，例如，带来多少活跃商家数？提升多少NPS？性能有多少提升？开发效率上有多少提升？

　　这部分内容极其重要，前文提到B端产品见效慢、难量化，但这并不代表只能自暴自弃，不去进行收益分析，相反，我们需要更加努力地对B端项目进行收益分析，即使最终也很难找到合适的度量方法，思考如何度量收益，这个过程本身就能帮助决策该不该做，如果一件事很难度量，同时放飞自我，不去谨慎思考，最终项目大概率失败。

　　站在技术视角，系统复杂度无节制地增加，很重要的一个原因是由大量无价值的项目累积起来的，最终演变成一座“代码屎山”，在项目初期，多追问项目的价值，项目上线后，也追着产品设计者回顾项目价值，能有效避免这种情况，让技术人员的付出更容易获得结果。

　　一个复杂项目，通常需要好几次评审才能通过，记录每次评审纪要，根据评审建议改进，是非常重要的。

　　业务用例，是指参与者为完成某个特定业务目标的一系列活动的集合，用例图用于描述系统与用户之间交互关系。用例图关心的是系统为用户提供什么价值，而不是如何实现系统功能，它驱动了后续各阶段的研发工作，如果用例分析出错，很可能导致项目目标失败。

　　业务用例希望我们跳出系统功能，以用户视角来看待系统，思考什么场景下为谁提供什么服务？这样才能以用户为中心获取需求，设计产品功能，同时这种视角也是用户最容易理解的逻辑。

　　在原有业务用例图的基础上，需要补充新用例或标识出待修改的用例，并在图中用不同颜色标记出来，如上图所示，红色表示新增用例，黄色表示变更用例。

　　业务流程，是指为达成特定业务目标，由不同的角色分工完成的一系列活动。活动之间不仅有严格的先后顺序限定，并且活动的内容、方式、责任等也都必须有明确的安排和界定，让不同活动在不同岗位角色之间进行流转与交接。

　　业务流程对于B端产品的意义不仅在于对B端客户业务的一种描述，更在于产研团队对B端业务运营的理解和剖析，这种理解是对企业资源的优化、对企业组织机构的优化以及对管理制度的一系列深入探究。只有真正理解业务流程，才能帮助B端客户达成期望的目标：降低企业的运营成本，提高对市场需求的响应速度，争取企业利润的最大化。

　　对于研发人员，业务流程模型可以帮助研发人员更好地了解企业真实的运营场景，进而更好地实现客户的需求。

　　概念模型，是指从业务视角出发，聚焦业务流程、业务活动中涉及的信息数据，抽象出关键业务对象，并描述这些对象间的关系。

　　概念模型实际上是现实世界到数字世界的第一层抽象。通过观察业务中关于数据的采集、传输、处理、存储、输出等需求，经过分析、总结之后建立起来的一个逻辑模型，它主要是用于描述业务系统中数据的各种状态。

　　概念模型不关心具体的实现方式（例如如何存储）等技术细节，而是主要关心数据在业务流中各个处理阶段的状态。

　　想要全面地了解某个业务领域，首先要了解该业务是什么，其次就要了解业务内部的核心运作原理，即从静态到动态，从目标到过程，系统地理清业务的框架和脉络。

　　业务的动态描述可以通过活动图，流程图，时序图，泳道图等模式描述，而业务的静态描述首先要分析出概念模型。

　　但一些成本大、风险高的大型复杂项目，会让人感觉到头疼、焦虑，这些项目的技术方案的决策结果，很可能摧毁一个项目，甚至一块业务。

　　为了避免做出错误决策，需要一系列的分析步骤，帮助我们做出正确的决定，保障项目目标顺利达成：

　　1.详细的现状分析：很多项目失败，原因是一开始就没分析清楚问题。在这个环节，需要明确真正的问题是什么，它与各个问题症状的因果关系是什么。常用的分析工具有五个为什么、根因分析法等。

　　2.核心成员同频：一个复杂项目，通常需要很多人参与，有人是受益方，有人是受影响方，有人是决策者，需要让核心成员尽早参与进来，并营造一个积极的讨论氛围，让每个人充分贡献自己的想法，这对做出正确的决定至关重要。

　　3.充分挖掘可行方案：挖掘出的可行方案越多，最终得出最优方案的概率就越大。

　　4.方案对比分析，选择最优方案：通过一些分析维度，对比方案的优劣，最终选择最优方案，分析维度可以通过团队头脑风暴筛选得出，或其他方法得出。这里推荐几种常用的分析维度：

　　交付效果：该方案是否对最终交付给存量或新客户的价值有影响，例如，对存量客户的操作体验、效率有损，部分新功能无法实现等。

　　工作量：该方案需要多大的工作量？这是非常重要的一个决策因素，方案再好，无法真正落地也只能是空想。

　　影响面：该方案涉及多少关联方改动？如果影响全公司所有部门，即使每个部门改动量不大，但要协调这么多人，也是一项非常艰巨的任务。

　　稳定性：项目上线后是否有数据库性能问题？服务器资源不足？并发流量问题？能否平滑发布？历史接口或数据能否兼容？

　　长期价值：该方案是不是长期方案？有时候对方案做长期投资也是很重要的一件事，短视的方案虽然工作量会减少一些，但会阻碍未来新项目迭代，欠的技术债可能要加倍还上。

　　5.向更多项目成员传达方案，进一步优化：通过上述步骤，可为最终方案提供大量的信息，例如，根本问题、风险、收益、替代方案、决策方式和决策的原因等，这会让更多人有理由支持该方案。在传达的过程中，也可能有人指出方案的缺陷，这时可以进一步完善方案，这时对方案的改动，成本非常低，如果等到进入研发阶段，昂贵的代价可能无法接受。

　　业务平台化是将多业务线可复用的能力抽取出来，并集中管理和演进的架构方案。

　　一方面，可让企业避免重复建设，浪费技术资源，另一方面基于平台化的能力，让新业务快速组装上线，支撑业务创新。

　　业务能力描述了应对当前和未来的挑战，企业目前能做什么或需要做什么。业务能力建模的关键点在于它定义了企业做什么，而不是如何做（由业务流程描述）。

　　以招聘业务为例，大部分公司都需要“招聘人才”这项业务能力，“招聘人才”告诉我们要做什么，但并没有展开说如何去做，可能是通过人力资源的招聘流程实现，例如，从招聘网站吸引候选人，再到招聘信息的管理，也可能外包给猎头公司。

　　业务能力独立于组织的结构、流程、人员、资产，准确地说，这些业务要素是支撑企业的业务能力而存在的。还是以“招聘人才”为例，“招聘人才”包括人力部门（人力资源团队）、业务流程（例如吸引、筛选、面试、雇用）和IT系统（例如招聘系统、人事系统）。准确的业务能力是非常稳定的，在过去的几十年中，招聘的流程、技术、模式发生了翻天覆地的变化，但“招聘人才”这项业务能力始终恒定存在。

　　正是因为业务能力的这些特征，业务能力视图对构建IT架构提供了至关重要的帮助，围绕业务能力构建的IT系统会具备更加稳定的结构，并易于扩展。

　　1.产品定义与演进路线图。如果需要推出的新产品或服务，可以使用业务能力地图来描述产品规划。尤其在基于敏捷、最小可行产品 (MVP)的文化中，业务能力地图可以在定义产品的同时，保持最终产品方案的正确性，不至于在伪敏捷文化中迷失自我。

　　2.基于现有能力快速搭建新应用系统。通用能力很可能被多条业务线复用，当新业务需要搭建新应用系统时，合理地对现有能力进行组合是最高效的方案，此时业务能力图可能是最重要的输入。

　　基础能力是对领域对象的原子操作，是可复用的最小能力单元，扩展点是对基础能力的可变性设计，而业务身份是业务能力在业务平台上的唯一标识。

　　在技术视角下，基础能力可对应于服务接口，将基础能力的内部实现展开，即为一个系统工作流，而扩展点是指系统工作流的某一步骤级接口，这个步骤级接口的实现即为一个扩展点实现。基于业务身份，可实现工作流内部组件的路由、链路溯源、链路监控、业务隔离等。

　　在业务分析环节，我们需要分析业务流程、业务活动，根据业务目标的相关性、耦合关系，对业务活动进行归类分组，划分出一个个的边界，这个边界就是限界上下文。

　　限界上下文内包含一组能够独立提供服务的模块或组件，这些模块或组件服务共同的业务目标。

　　1.基于业务目标的相关性，维护了一个分解后的逻辑边界，将相关的模型封装在内，对外提供抽象简化后的服务接口，降低了系统整体复杂度。

　　2.以限界上下文定义的逻辑边界为基础，建立团队间的协作边界，团队间同样以服务接口进行交互，屏蔽内部的业务复杂度与技术复杂度。

　　应用架构描述出应用系统的层次结构，包括系统、应用、模块、组件等构件的划分规范，以及它们的定义、边界、相互间的交互协议。

　　画应用架构图，推荐西蒙布朗提出的C4模型，它将应用架构分为4个抽象层次，分别为系统级、容器级、组件级、代码级。

　　领域模型是对业务知识的抽象与浓缩，它能够有效帮助业务人员、技术人员快速理解现实业务，同时也是团队统一语言的关键。

　　在DDD理论中，领域模型包含限界上下文、领域实体、聚合、值对象、领域事件、仓储、应用服务、领域服务等，以及它们间的关系。

　　在原有领域模型的基础上，需要补充新的模型或新属性，并在图中用不同颜色标记出来。如果没有模型变更，可以不需要这块内容

　　容器级交互时序图是一种流程建模，描述了应用容器之间的交互顺序，将交互行为建模为消息传递，通过描述消息是如何在应用容器间发送和接收，来动态展示它们之间的交互。相对于其他UML图，时序图更强调交互的时间顺序，可以直观的描述交互的过程。

　　在原有交互图的基础上，需要补充新的调用关系，并在图中用不同颜色标记出来，例如，用红色线条标识为本期项目新增。

　　相比于容器级交互图，组件或代码级的交互图是更细粒度的交互流程，描述了应用容器内各个组件或代码的交互顺序。

　　在原有组件间交互图的基础上，需要补充新的调用关系，并在图中用不同颜色标记出来，例如，用红色线条标识为本期项目新增。

　　物理模型是指按照一定规则和方法，将领域模型中定义的实体、属性、属性类型、关系等要素转换为数据库设计所能够识别的表关系图，即我们常说的数据库表结构设计。

　　非功能性需求是指软件产品为满足用户业务需求，除功能需求以外必须具有的特性，包括系统的性能、可靠性、可维护性、扩展性、安全性等。

　　大多时候我们更关注功能需求，而容易忽视非功能性需求，但这些需求没有做到位，也很容易让用户体验受损，产品饱受诟病。我们在做技术方案时，需要有非功能性需求的checklist，避免遗漏关键的需求点。

　　评估新增的数据库表的IO、事务数，是否有并发场景，是否有性能瓶颈，是否对现有业务或实时/离线数仓有影响。

　　当前业务流量，对服务器性能是否有挑战，建议通过压力测试，验证服务器性能状况。

　　在大流量、高并发场景下，熔断、降级、限流是保护系统的利器，评估该项目是否需要使用这些机制。

　　评估该项目是否需要灰度发布，虽然功能在测试环境测试过，但生产环境的场景异常复杂，对于复杂项目很难全面评估，通过灰度发布，让少部分用户先使用新版本，提前发现bug，或者稳定性问题，提前做好修复，可以有效降低新版本带来的影响。

　　评估该项目是否需要新增或变更监控报警，监控报警能够保障出现故障之后，第一时间知道，防止影响面扩大。

　　分布式架构极容易出现数据不一致的问题，该项目是否需要设计数据对账脚本，帮助及时发现不一致问题。

　　2.评估为了防止资损，是否需要进行幂等控制、并发控制、越权校验、风控机制设计、止损机制设计、监控报警设计等。

　　该项目对老系统、APP历史版本、开放平台接口是否有影响，是否需要开发兼容逻辑。