如何写好一个技术方案
认知提升的途径是什么？唯一途径：学习，思考，实践，沉淀。
人与人的本质差距在于： 他拥有多少清晰的概念（观点），建立了多少正确的价值观（判断），总结了多少有效的方法论。
概念，价值观，方法论，是我们需要不断去总结和打磨的几个东西。
高质量决策
有幸参加公司安排的一些列提高职场能力的培训。
其中有两堂课是：《高质量决策》、《问题分析与解决》。
主要讲的内容可以分为分析和判断两大块。
其中分析部分又包含：辨识问题/机会、分析问题；
判断包含：制定方案、评估结果。
识别问题
问题是什么？结果不如你的预期，那就是问题
什么问题是一个高性价比需要解决的问题？解决难度低，并且高收益的问题
识别一个问题我们需要，搜集问题信息，并将问题描述出来。
描述一个问题我们使用SMART模型
- 主导性问题
- 具体可描述
- 非事实罗列
- 可行动
- 以下一步行动为重点
并辨识出我们真正需要解决的问题是什么？用简单的话概括出问题的主旨。比如高并发，现在不再是一个新鲜的词汇，甚至大学生都知道怎么去做，缓存、异步操作、并行……，这些都是具体的措施，问高并发到底是什么，大家都能回答一些，比如流量大、系统压力大、用户多……，这些都具体的特征，自己用一句话概括高并发：有限的资源应对大量的请求，概括出了高并发的根本特性，抓住了本质的东西就比较解决问题。
分析问题
我们通过搜集信息，然后在进行诠释信息。
分析工具我们有：5-WHY、逻辑树、MECE、鱼骨图。
信息包括不限于：数据、一手资料、专家，供应商等。
通过信息比较、信息之间的联系、信息的变化和趋势去分析，客观的评估，找出关联。不能偏见，盲点；闭门造车；带主观思想等。
制定方案
根据根本原因制定，并提供多个方案进行选择。
决策方式
- 决策因素（最关心的）
- 决策方法：决策矩阵、民主投票、领导/专家
评估方案及风险
衡量原有标准->持续追踪->建立流程->控制
总结如下图
{: .normal}
{: .normal}
{: .normal}
高质量技术方案
一个好的技术方案，一涵盖应有的深度和广度，二方案结构化清晰，三以实际案例说话。
技术方案体现深度和广度
个人经验，在编写，业务需求方案的时候，大多数编写的基本都是本次需求的需求背景，以及客户端部分改动点整理，偏简单明了。技术需求方案，会稍微涉及的多些，涵盖的面也会广些。感觉更像是给自己干活，更加专研，给产品干活，听命行事。这一块是个人需要改进的吧。其实也一直都知道这样不好，但是有时候带着自己的想法去跟产品沟通，产品对于自己要做的，更加坚持。
一个普通的技术方案，大多都是一下情景：场景简单、复杂度低、亮点少、设计普通等等。但是我们需要去思考背后的问题和原因，为什么会有这样的感受，如果这个事情交给另外一个人去做，为什么他却能设计出更好的方案，而当时你没有想到呢。
原因探究
一直将自己的目光聚焦在一件事上面，就事论事，因为只看到了这一件事，需要完成的就是解决这个事情去做某个功能点，而没有跳出这个事情的表象，去思考到底要什么、解决了什么问题、价值是什么。
就事论事的思考，很有可能你现在的解决方案只是其中一个很小的点，而没有站在全局的角度去思考问题。
但是就事论事也有好处，能够更高效，能够更聚精会神，但是这个没法让你到金字塔更高的地方去，永远只能在金字塔下面替别人解决事情。
手掌放在眼前，可能可以将整个手掌看的更清楚，但是你只能看到你的手掌，拿远一点，你的视野就更加广了。
不要只关注事情的本身，可以跳出来看看，或许你能想到的更多。
技术广度和深度
广度：从数量和类型等其他纬度去分析。
深度：体现出问题的识别和创新。别人没有发现的，你发现了就是深度。
比如现有优惠券服务。你扩充到礼品卡，补贴金这种，就是从数量类型上广度衍生。你想到资损，退货逆向返还，就是深度。
结构化清晰
系统性思考和结构化思维，是我现在需要提升的能力。
5W1H：why、what、when、who、where、how（which）
倒三角思考：战略->战术->技术动作
整体流转图分析：明确角色->梳理流程->穷尽状态->数据流转
常见方案模板
日常需求研发
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
需求描述
产品文档
现状
需求分析
总体设计
系统交互流程
总体设计原则
功能设计
非功能设计
功能降级
监控报警
涉及的工程和分支
开发任务分界
开发计划
问题列表
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
需求概述
背景
目标
概念申明
统一语言
核心概念
技术调研
现状分析
现状表现
现状方案
行业现状
可行性分析
现状可行性分析
行业竞品可行性分析
总体设计
现有方案优化
客户端方案架构设计
功能设计
功能概述和设计思路
流程设计
风险评估
非功能性设计
服务性能
缓存设计
防腐设计
监控预警
降级方案
容错
安全设计
立项评审方案
项目立项要求
1
2
3
4
5
6
7
8
9
10
11
12
项目价值描述
- 描述业务价值，还是技术价值
- 描述具体的价值指标，价值推导过程
- 描述是否匹配战略或者研发部KPI
设计方案描述
- 总体架构设计
- 行业内或者部门内类似产品对比。
- 技术选型，技术难点
- 风险评估（技术风险，资源风险等）
- 项目的资源投入评估，包括依赖方的资源投入，资源冲突评估。
- 项目推动计划，包括：每个子里程碑的计划。
- 项目的上线的验收标准
项目评审规约
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
考察维度1:项目价值
- 如果是直接业务价值
- 如果是非直接业务价值
- 如果是for间接业务价值，考察是否阐述具体的业务价值，是否匹配战略目标或者技术KPI或者研发部KPI，是否可衡量，可验证的，可推导的
- 如果是for技术价值，考察是否阐述具体的技术价值，是否匹配技术非业务KPI或者研发部非业务KPI，是否是可衡量，可验证，可推导的
技术价值1：研发效能，包括：持续发布能力（频率和过程时长），对外交付质量（单位时间的故障数，平均时长），交付过程质量（Bug分布），交付吞吐量（单位时间交付需求数量），需求响应周期（响应周期，开发周期）；
技术价值2：提升稳定性，高可用性，服务治理等例如：APM，依赖治理，缓存治理，埋点建设，上云等；
技术价值3：降低业务方成本，提高人效；
技术价值4：提升服务的性能，例如：首页加载速度，交易时长缩短等；
技术价值5：提升服务可扩展性，可维护性，可定制化能力，例如：平台建设，服务化，上云；
技术价值6：提升服务的安全性
考察纬度2：方案可行性
- 考察方案是否可以达成目标。
- 考察方案是否重复性建设，是否列出与项目内相似产品的区别，甚至包括行业内的比较。
- 考察方案是否进行初步风险评估。
- 考察方案的ROI，人力成本。
- 考察方案是否考虑可行性，包括：技术难点，团队协作等。
- 考察方案是否架构设计是否完整。