业务现状调研
区分“痛点”和“痒点”
找到业务“痛点”，明确要解决的问题，抽象出背后的关键问题，把关键问题放到台面上狠狠地干穿干透它解决它。
搜集业务数据
有业务数据方便为后续方案选择权衡提供判断依据和数据支撑，也为方案增加了说服力。
明确PRD需求范围 scope
方案调研
素材来源：论文、技术网站 ...
搜索资料找准中心词
搜索是一种能力，其中的关键就是找准 keyword，紧贴自己方案的主旨找准 keyword 中心词，避免无知觉中把中心词弄错了、整个思路方向都错了，结果陷入到信息茧房，被错误中心词之下的概念所错误引导，一叶障目，导致无法获取到优质资料；
带着目的出发去找资料，漫无目的效率低且容易疲惫；
不同的keyword也能侧面体现出对方案涉及问题和技术理解的视野、层次格局；
设计目的（必需）
本次方案设计的目的、核心要解决的问题、解决问题能带来的价值
设计目标（必需）
核心：目标定义“性感”而精准、考虑ROI（效能，收益，成本）
具体量化的指标，用来衡量此方案解决问题的具体效果，例如：成功率提升至99.9%，接口RT小于100ms，交付投入3人日，原厂研发投入0人日等等；例如：轻量化交付，先可以估算预计所需使用的资源的数量级，哪怕是一个粗略的估算；
注意，并非所有事情都具备“可量化性”——不是所有事情都是可以被量化、被比较容易和有说服力的量化的
设计原则和约定（必需）
整个方案推导逻辑的底层依据和合作方达成一致的前提，原则不被突破；
具体包括：产品策略约定、业务规则约定；
约定的意义：根据约定减少方案的复杂度
核心用例
功能性用例
非功能性用例
用例走查
方案设计前，搜集整理核心用例，再从用例出发归纳场景和关键问题；
方案设计完，再用例走查一遍，check方案是否能cover所有核心用例场景；
关键问题（必需）
当前方案所涉及业务的业务特性下，不同于其他业务的独有的挑战和难题，例如：公告系统全员公告推送，IM系统消息如何100%到达，在线文档系统内容0丢失等等，直播推流双推流备份；
洞悉关键细节很难，往往那些最基本的但也是最重要的最容易被人忽略的东西，例如漏洞热修复，往往注意点都放在了怎么各种骚套路热修复上但是实际执行的时候难点是怎么知道“正确的修复版本是哪个”；TZ交付的应用的scope到底是哪些，这个模块下到底有哪些应用，回到最基本的模块-应用-制品的关系；
数据指标（必需）
方案可以定义的数据指标，后续汇报用
其他通用考虑问题
产品功能规格限制
线上容量预估 + 对产品功能规格有明确的说明（B端产品写入正式的产品使用手册）
考虑端到端全链路
涉及独立APP、小程序、H5的C端设计方案，一定要考虑端到端的全链路方案，尤其是独立客户端。
超长链路设计优化
性能问题
安全性
基本的安全性措施，例如预防XSS DDoS等等。复杂场景涉及安全资质的，找专门的安全同学或者三方安全机构来评估，例如：文件安全检测沙箱领域，一般的公司无技术能力无资质，需要引入三方安全能力厂商
弹性 可伸缩性
例如容器化改造、上云、基于云原生理念来设计
幂等性
幂等可重入是后续重试设计、最终一致性设计等基础
可重试
默认不重试，识别可重试的场景，例如：并非所有异常都可以通过重试来解决；
有限次重试 + 退避策略（无限重试导致的线上故障比比皆是）+ 重试范围可控；
灰度方案
人工介入流程设计
角色关注点分离
标准化交付
可观察性
方案上线后需要配置哪些运维的监控告警（系统监控 + 业务监控 + 错误码定义）、问题排查文档；
可兼容性
方案是否能兼容老数据且用户侧无感
上线方案
例如无法做到兼容的情况下，线上数据订正的变更方案--变更步骤、验证方法、回滚方案、应急预案；
详细设计
详细设计主要是用来指导执行层的同学具体如何干活落地，简单来说上述的目的目标价值等是给Leader汇报用，详细设计是实际干活开发用；
API 设计
最小粒度返回，精简返回字段，根据要求按需返回必要的数据，尤其避免同作用的字段返回多个或者返回大量无用字段，造成对接联调的理解成本、后续的维护成本，同时过大的返回报文也会影响接口性能。
核心模型、数据结构
- 谨慎使用json/xml存值，谨慎使用“扩展字段”， 这种东西，就好比“map一时爽，重构火葬场”，最开始可能非常好用，但是到后期可维护性，管控，校验等都会变得极其复杂，很容易出错——因为很容易滥用，如果真的不得不用，一定要要做好对大json/xml等这类"extension"型自字段的管控；
- 定义核心字段的名称、value的格式、value的内容、如何使用、限制条件
核心时序逻辑流程
BadCase
1、使用大JSON作为系统交互媒介，且缺少可视化的排查手段导致排查成本大，效率低下
实际工作中，有一个项目及其SB的设计，是用来一个大JSON（格式化后1w+行）作为系统的输入和交互，导致排查问题的时候直接奔溃，及其恶心、及其SB的设计
WBS（必需）
明确Owner、任务拆解、任务指派、工时评估等，保证后续迭代开发落地实施的事项无遗漏、人力保障，保证按期交付上线。
总结
以上列举的因素除标记为**“必需”**外都是考虑的“可选项”，实际开发中不同产品和系统的业务特点不同不可能“面面俱到”，有无法达成的点也不用焦虑，方案设计本身就是一个取舍的过程，关键是结合业务弄清哪些点无法做到、为什么、做不到带来的影响、预防和兜底的手段，让一切可控。
