如何做技术规划?
整理自如何做技术规划?
为什么要做技术规划?
资源是有限的，一个技术团队不可能同时做好所有事，必须面对选择，作为tech leader，为团队选择最有价值的工作才能使得整体收益最大化，无论团队还是个人都不能仅靠case/问题驱动去解决问题，这样做只会让团队或者自己辛苦一年而无产出，浪费业务资源，结果跑偏，影响业务发展。
对个人来说，这也是一个极其重要的能力，新手能把事情做对，高手要去做对的事情,而技术规划能力则是其中最重要的分水岭。
对于团队来说，tech eader 需要尽可能的打造一个技术上领先的团队去应对业务的发展，使得技术本身作为业务的核心竞争力,在稳定性/送代效率与质量/安全性/架构先进性上等等技术方面超越业界水平。
什么是技术规划
技术规划不仅是产出计划书或技术方案，更是对最终愿景的思考过程，着重在战略，而非战术。
做技术规划不能仅把过去遗留的问题，项目集合罗列出来，形成一个超级巨大的一年期的TODO list，这是一件很丢人的事情。
技术规划要抽象问题，发现本质原因，整体性，方向性，战略性的描述解决方案，所以一个技术规划通常要讲清楚，现状/目标(结果)/路径这三个基本要素。但现状有多种维度，目标可能有多个，路径也有多条，这时才体现规划的意义，你需要通过思考，调查最客观的现状，最有价值且可行明确的目标，综合最优的实现路径。
综上，技术规划就是一个描述在有限资源(时间/人力等)内从当前客观现状通过综合最优的实现路径完成最具价值的目标获得最大收益的战略性思考过程。
为什么它是一个思考过程?
因为规划要跟其他人(团队成员/你的leader/支持团队)去对齐，也作为事后复盘时的依据，更是晋升报告的能力证明，跳槽时的工作成果，所以要讲清楚整个思考过程。
技术规划的思考过程
Step1: 目标制定
目标的几种来源
1.现有扩展，过去一些指标的深度优化，或者已有技术债务的偿还。
2.深度挖掘，对同一标用其他指标来衡量，寻找新的优化方向。
3.新方向探索，引入新的业界技术与业界前沿建设思路对齐。
4.趋势判断，预测未来技术发展趋势，尝试将前沿的学界思想引入来建设当前工作，引领颠覆式的创新
明确可量化的目标
我们可以对目标做一个简单的分类，针对不同的类型目标有不同的描述方式
1.优化问题，要写清楚量化的指标，从X提升到Y，或者从X下降到Y。
2.建设问题，所建设的系统或工具有什么能力/功能，有怎样的使用规模(场景/用户数/客户数等)。
描述收益的维度
收益通常从交易，产品，用户三个视角去看
1.收入，是否可以直接换算为钱，赚的和省的都算作收益
2.效率，生产效率的提高，开发/迭代周期缩短，从难到易，减少人力等。
3.体验，接口延迟，开机速度，使用流畅度，CTR，留存等等。
目标的分配
1.目标要分给其他人一起来完成，要考虑整体可用的人力成本
2.按人才梯度去分配，考虑胜任情况与成长挑战。
Step2:全景图
领域驱动设计
需要从0到1建设的系统，要以DDD的思想进行架构组件的拆解，如果是一个已有的系统也可以试着从0到1的构建.
看看不合理之处在哪，逐步重构成最理想的状态。
全景架构图
有了领域驱动设计的拆解后，就要把架构组件放到对应的位置上组成一个整体，建设一个全局概念纵向上要分层，横向上要分模块，来描述整个系统的功能组件，让所有同学都清楚全局架构。
全景功能树
如果是建设问题，就以用户视角划分功能树，让所有同学都能明白每个部分谁来负责。
全景指标树
如果是优化问题，就按指标的计算公式进行拆解，将指标拆解到对应的负责的owner同学身上。
Step3:里程碑
规划全景图阶段，就已经确定了目标的实现策略与方案了，那么接下来就是要确保项目真正的能落地，拿到收益
里程碑本质上是并行执行项目的一个检查点，每个里程碑都是一个具有明确收益的子目标，多个子方向在里程碑处完成联调与对齐。本质上从理想目标到最终落地的过程，就是一个信息不确定性逐步收敛的过程，风险在开始时最大，完成时变为0。每个里程碑的完成都是对风险的一次收敛。
小步快跑
既然项目的落地是一个不确定性逐步收敛的过程，那么最佳的策略就是接受客观的反馈，只有反馈才能消除不确定性，因为反馈就是实验，实验就是观察，只有观察才能消除不确定性(类比海森堡测不准原理)。
从Demo开始，逐步通过单元测试丰富功能，逐步阶段获得收益，不断实验反馈，最后应用。
时间倒排
从最终项目落地的整体DDL开始，给每个关键里程碑一个DDL，时间要留有几余，旦越临近最终DDL时延期的风险应该越小，只有这样才是一个健康的项目管理过程。
按时间线细化具体的工作，从年到季度，从季度到月，从月到周，从周到日，由日到每小时的任务，这不需要你一个人来完成，做规划只要到季度目标即可。
优先级
当想要做的事情太多，但可用的资源过少时我们必须进行取舍，人们在做事的时候往往会目标迷失或者膨胀做了与最终目标无益的事情，要么是忘记了最终目的，要么是给自己加戏，等等原因导致延期。
目标不能仅按重要性和紧急性来区分，因为人们很难判断二者，常受各种情绪和噪声的干扰，短期内认为某件事更重要，也有可能认为某件事过于紧急，实则完全没有必要，白白浪费资源。
最佳的策略还是按照我们的第一原则，项目的落地过程是一个不确定性逐步收敛的过程来看。那么我们就可以有两个维度，风险和收益，但这里却和我们直觉性的想法有着区别:
1.风险是指如果这件事不做或者失败对最终目标的损失是多少?
2.收益则是指如果这件事完成，那么对最终目标的完成度贡献几何?
这两个维度某种意义上来说，是更加客观，受噪声影响较小的判断方式。
收益（ROI) = (收益-风险)/成本
Step4:风险管理
一个规划如果不能最终落地拿到成果，它就只能对你有思考上的锻炼而没有对外部产生任何价值。好的规划必须要考虑落地过程中的风险，需要对可预见的风险做PlanB，不确定性本身就意味着风险。事实上落地过程中的风险来自于两个方面，技术的风险与人的风险。
1.技术风险，在方案设计阶段不一定可以确定所有的操作都是可行的，执行中遇到无法解决的客观难题时常见的，这会导致排期失效，任务延期。针对这一问题，通常我们要找到上下游所有的决策人，然后达成共识，是选择延期交付还是要砍掉需求，亦或者某种”糙快猛的解决方案来保证交付上的DDL，并且作为项目的owner,要约定好check时间，依据项目的重要性以及紧急情况，约定单周或者双周组织开一次会对齐进度，暴露风险。
2.管理风险，项目需要人去完成，人存在诸多不稳定因素例如离职/请假/积极性等因素，另外事件发展也会有很多意外情况，法务合规等不可抗力等等，针对这些情况我们制定方案时，原则上要尽早暴露风险，对高风险项要有充足的planB，为最坏情况提前计划，对于不可撤回的颠覆性思想要警惕，充分评估后再执行。
本质上，项目的落地过程，就是从一个不确定性的想法逐步收敛到确定性结果的过程，从风险与收益的角度来对任务优先级排序要比使用紧急和重要这两个维度更加清晰，先挑选出对于完成最终目标必要性最强的任务，然后优先选择风险高收益大的任务完成，这样我们对不确定性的收敛进度会大幅度提升，项目的落地速度也会更快的完成，这就是所谓要去做难而正确的事，难就是风险大，正确则是收益高。
丰富经验的项目管理者会发现，所谓项目管理本质上就是风险的管理，这需要在事上炼
Step5: OKR
0是目标，KR是关键结果，OKR就是目标+关键结果。0用来描述本质的目标，KR则是用来描述O达成的必要条件，流于形式的OKR通常就是0不够本质/明确可行，KR不是0的必要条件，在写作OKR时要尤为注意。
OKR是组织目标管理工具也是个人目标管理工具，非常值得应用在工作和生活之中。对于知识型工作者它是一种高效的沟通方式，对于个人成长它则是一种高效的自我管理工具，使用OKR最大的收益是它能够帮助我们细化思考过程，是一种高效率的任务分解工具，他能够将长期战略规划与复杂的行动方案拆解为每个季度/每个月具体可落地执行的任务，让一个长期目标可逐步落地推进，最终实现。
推荐这个网站去学习OKR的更多知识，在落地应用中要多去翻阅一下这个网站，其中有很多案例与模版可以帮助正确使用。
整个OKR的实践过程是，具体的全流程实践请参考->OKR网站学习。
| case的调查与收集 -> 写作OKR -> 对齐OKR -> 周计划与排期 -> 周会复盘 -> OKR复盘会(中期/结尾)
对于技术规划来说我们要聚焦在写作OKR与对齐OKR上面即可。
写作OKR
O+KR = 有挑战(信心指数0.7)可量化的本质目标(多问几个为什么)+ 必要的可衡量的关键结果
- 从里程碑中拆解出的目标要有本质性，也就是要多去问几个为什么将受益和成本思考清楚。
- KR不是TODO代办列表，是达成目标的必要条件，应该遵循金字塔原理的MECE去拆解。
对齐OKR
- 要把OKR分配给最适合执行的那个人去做，技术规划通常不是一个人完成(个人OKR也需要他人配合)，要把O分配到具体的人，只有职责到人，这件事才会有人去做才会有结果。
- 约会对齐要讲清楚，O的收益与成本，其本质目的是为了哪个终极目标服务，KR要说明其必要性以及如何量化评估(怎么算完成，怎么算失败)。
- 如果时间允许，还可以讲一下调查的case以及方案的取舍过程，但要记住这不是重点，应该快速结束。
Plato业务架构规划
规划目标
从0到1的的设计并实现一个IM系统，这个IM系统在上亿DAU规模下依旧可以保持，高效/稳定/易于维护的特性。
一个IM的基本功能大体可以分为四大模块: 用户管理/好友关系/消息管理/会话管理
总体约束:
1.基于领域驱动设计的方法完成整个系统的落地
2.用户规模假设DAU达到上亿，消息收发QPS达到200K
3.除拉取消息接口外P99 不能超过50ms
4.消息拉取接口 P99 100ms以下
5.一个季度内完成整体的开发流程
全景图
回《领域驱动设计精粹》按照此书介绍的DDD方法,我们实战一下IM的业务架构战略设计!
用功能树进行业务建模
业务建模 通用语言+业务流程
由于IM系统的特殊性，其业务流程和专业术语，只要是微信用户基本都知道;多刷刷微信，基本微信上模块名称就是所谓的领域专家的通用语言，然后在辅助了解一下飞书的功能。基本消费级IM和企业级IM的流程就基本理解了，我们的Plato为追求一定的业务复杂度，从业务流程和功能设计上也主要参考微信以及辅助飞书的一些亮点功能。
注: app是一个持续迭代的系统，很可能当前的微信和飞书功能发生很大变化，Plato这里只会讲一些基础功能但足够大家理解IM系统的本质，也会具有足够的复杂性，未来无论怎么演进，基础架构大概率不会变化。
架构图
里程碑
时间倒排
战略优先级
消息/会话/社交 这是核心域，应该投入最多的人力，将其打造为产品竞争力;
Feed和User不是 但也找不到合适的标准软件，因此是支撑域,要尽量避免在这两个领域投入更多的人力过度设计。
Index/SrqlD/MessageStorage 三个基础服务主要负责核心域实体的存储以及高性能检索，本身还是算做领域服务内Cron Job/Cache/Graph 三个基础服务更多的算做基础中台，是支撑域，应该交给其他团队外包开发需要减少依赖各种开元的基础组件 Mysql，RodcksDB，TIDB，MQ等都是通用子域，有现成的开源实现无需开发，只要做好依赖倒置即可。
OKR拆解
01:IM系统架构规划和设计(1-2月完成)
KR1:创造详细的服务架构设计图用于参考
KR2: 确定关键领域的实体设计，形成设计图
KR3:设计数据库存储模型以满足IM系统的数据扩展性和稳定性需求
02:IM系统的核心模块开发(3-4月完成)
KR1: 完成IM系统用户管理、消息管理、好友关系以及会话管理模块的基本功能开发。
KR2:实现P99响应时间在50ms以内，消息拉取接口P99在100ms以内。
KR3:针对用户规模DAU达到上亿，消息收发QPS达到200K的假设。
03:IM系统部署和运维(5-6月完成)
KR1: 构建和部署基础架构组件，例如MySQL、Redis、MQ等。
KR2:实施全链路跑通测试，并修复出现的问题
KR3:完成IM系统的DevOps流程和环境的建设。
技术三板斧：关于技术规划、管理、架构的思考
如何成为一名优秀的技术Leader？
深入浅谈技术战略规划一二三（一：方法论）
技术管理- 怎样做好技术规划？
如何做好技术规划
技术创新战略规划