写点什么

如何写好 B 端产品的技术方案?

作者:汤师爷
  • 2022 年 4 月 27 日
  • 本文字数:6509 字

    阅读完需:约 21 分钟

如何写好B端产品的技术方案?

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

B 端产品有以下特点:

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

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

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

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

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

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

一、概述【强制】

1.1 术语解释

为什么要这块内容?

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

1.2 项目背景与价值

为什么要这块内容?

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

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

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

1.3 本期项目目标

介绍本期项目需要达成的目标

1.4 方案评审纪要

为什么要这块内容?

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



二、业务分析【强制】

2.1 业务用例分析

为什么要这块内容?

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

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

举例说明



小项目如何设计?

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

2.2 业务流程分析

为什么要这块内容?

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

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

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

举例说明



小项目如何设计?

在原有业务流程图的基础上,需要用不同颜色标识出需要修改的部分。



2.3 概念模型分析

为什么要这块内容?

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

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

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

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

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

举例说明



三、方案选型分析【可选】

为什么要这块内容?

有些项目比较简单,简单到不需要花太多时间做方案决策。

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

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

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

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

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

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

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

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

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

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

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

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

举例说明

方案 1:。。。(描述)

方案 2:。。。(描述)

方案 3:。。。(描述)



四、业务平台化设计【可选】

为什么要这块内容?

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

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

4.1 业务能力建模

为什么要这块内容?

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

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

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

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

具体来说,业务能力视图有以下 2 大应用场景:

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

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

举例说明



4.2 系统工作流与扩展点设计

为什么要这块内容?

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

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

有了扩展点机制,我们就可以基于现有基础能力,快速实现定制需求。

举例说明



五、概要设计【强制】

5.1 限界上下文划分

为什么要这块内容?

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

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

限界上下文的价值主要有:

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

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

举例说明



5.2 应用架构设计

为什么要这块内容?

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

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

举例说明

容器级应用架构:



组件级应用架构:



5.3 领域模型设计

为什么要这块内容?

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

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

举例说明



小项目如何设计?

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

5.4 容器级交互时序

为什么要这块内容?

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

举例说明



小项目如何设计?

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

六、详细设计【强制】

6.1 组件/代码级交互时序

为什么要这块内容?

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

举例说明



小项目如何设计?

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

6.2 领域模型详细设计

6.2.1 领域实体 &值对象定义

XX 领域实体




XX 值对象



6.2.2 领域服务定义

XXDomainService



6.2.3 应用服务定义

XXAppService



6.2.4 领域事件定义

XX 领域事件



6.2.5 领域实体状态机定义

举例说明

要货申请单的状态机:



6.3 物理模型详细设计

为什么要这块内容?

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

举例说明

XX 表结构



6.4 前端接口详细设计

接口名称:XX

入参设计:


 

返回值设计:



错误码解释:



七、非功能性需求设计【强制】

为什么需要这块内容?

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

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

7.1 性能分析

1.数据库性能

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

若有高并发、热点数据集中访问等场景,需要有详细的缓存设计方案。

2.JVM 调优

JVM 参数是否配置合理,是否有参考线上标准配置。

3.外部系统性能

当前业务流量,下游系统能否支撑,是否需要做限流处理。

4.服务器性能

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

7.2 稳定性分析

1.降级、熔断、限流

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

2.灰度发布

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

3.监控报警

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

4.数据一致性对账设计

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

7.3 资损分析

1.评估资损点,例如服务接口中包含资损相关字段(资金、积分、虚拟币等)。

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

7.4 兼容性分析

1.历史数据迁移

该项目对历史数据是否有影响,若有,需要制定详细的数据迁移计划。

2.历史版本兼容

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

7.5 安全分析

1.评估常用技术攻击手段的防控,比如脚本(JS)注入、SQL 注入、CSRF 攻击、越权问题、id 遍历、防重放攻击。

2.数据是否需要脱敏,比如手机号等隐私、敏感数据。

八、附录【强制】

8.1 参考文档

附上需求文档、过往技术方案设计文档、依赖的技术组件、技术服务的说明文档等,给出文档链接或附件。

 

参考资料

1.《ThoughtWorks 现代企业架构框架白皮书》

2. https://c4model.com/

3.《实现领域驱动设计》作者:Vaughn Vernon

4.《领域驱动设计》作者:Eric Evans

5.《决胜 B 端:产品经理升级之路》作者:杨堃

 

发布于: 刚刚阅读数: 3
用户头像

汤师爷

关注

人人都会抽象,但只有智者知道在哪里停下~ 2018.04.26 加入

公众号:汤师爷说。 南京大学硕士,在华为实习,毕业后加入阿里。 自己开过公司,也做过创业公司CTO。 10年以上互联网老兵,现任某上市公司架构师。 关注新零售SaaS、企业架构、领域架构、中台架构、技术领导力等。

评论

发布
暂无评论
如何写好B端产品的技术方案?_SaaS_汤师爷_InfoQ写作社区