如何做技术规划

为什么要做技术规划

资源是有限的,一个技术团队不可能同时做好所有事,必须面对选择,作为tech leader,为团队选择最有价值的工作才能使得整体收益最大化,无论团队还是个人都不能仅靠case/问题驱动去解决问题,这样做只会让团队或者自己辛苦一年而无产出,浪费业务资源,结果跑偏,影响业务发展。

对个人来说,这也是一个极其重要的能力,新手能把事情做对,高手要去做对的事情,而技术规划能力则是其中最重要的分水岭。

对于团队来说,tech leader 需要尽可能的打造一个技术上领先的团队去应对业务的发展,使得技术本身作为业务的核心竞争力,在稳定性/迭代效率与质量/安全性/架构先进性上等等技术方面超越业界水平。

什么是技术规划

技术规划不仅是产出计划书或技术方案,更是对最终愿景的思考过程,着重在战略,而非战术。 做技术规划不能仅把过去遗留的问题,项目集合罗列出来,形成一个超级巨大的一年期的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

O是目标,KR是关键结果,OKR就是目标+关键结果。O用来描述本质的目标,KR则是用来描述O达成的必要条件,流于形式的OKR通常就是O不够本质/明确可行,KR不是O的必要条件,在写作OKR时要尤为注意

OKR是组织目标管理工具也是个人目标管理工具,非常值得应用在工作和生活之中。对于知识型工作者它是一种高效的沟通方式,对于个人成长它则是一种高效的自我管理工具,使用OKR最大的收益是它能够帮助我们细化思考过程,是一种 高效率的任务分解工具,他能够将长期战略规划与复杂的行动方案拆解为每个季度/每个月具体可落地执行的任务,让一个长期目标可逐步落地推进,最终实现。

推荐这个网站去学习OKR的更多知识,在落地应用中要多去翻阅一下这个网站,其中有很多案例与模版可以帮助正确使用。

整个OKR的实践过程是,具体的全流程实践请参考->OKR网站学习。

case的调查与收集 -> 写作OKR ->对齐OKR ->周计划与排期 ->周会复盘 -> 0KR复盘会(中期/结尾)

对于技术规划 来说我们要聚焦在写作OKR对齐OKR上面可。

写作OKR

O+KR =有挑战(信心指数0.7)可量化的本质目标(多问几个为什么) + 必要的可衡量的关键结果

  • 从里程碑中拆解出的目标要有本质性,也就是要多去问几个为什么将受益和成本思考清楚。
  • KR不是TODO代办列表,是达成目标的必要条件,应该遵循金字塔原理的MECE去拆解。

对齐OKR

  • 要把OKR分配给最适合执行的那个人去做,技术规划通常不是一个人完成(个人OKR也需要他人配合),要把O分配到具体的人,只有职责到人,这件事才会有人去做才会有结果。
  • 约会对齐要讲清楚,O的收益与成本 ,其本质目的是为了哪个终极目标服务,KR要说明其必要性以及如何量化评估(怎么算完成,怎么算失败)
  • 如果时间允许,还可以讲一下调查的case以及方案的取舍过程,但要记住这不是重点,应该快速结束,

郑重申明:此篇为转载,出自硬核课堂 hardcore

相关推荐
waicsdn_haha12 分钟前
Java/JDK下载、安装及环境配置超详细教程【Windows10、macOS和Linux图文详解】
java·运维·服务器·开发语言·windows·后端·jdk
Q_192849990622 分钟前
基于Spring Boot的摄影器材租赁回收系统
java·spring boot·后端
良许Linux26 分钟前
0.96寸OLED显示屏详解
linux·服务器·后端·互联网
求知若饥38 分钟前
NestJS 项目实战-权限管理系统开发(六)
后端·node.js·nestjs
gb42152871 小时前
springboot中Jackson库和jsonpath库的区别和联系。
java·spring boot·后端
程序猿进阶1 小时前
深入解析 Spring WebFlux:原理与应用
java·开发语言·后端·spring·面试·架构·springboot
颜淡慕潇2 小时前
【K8S问题系列 |19 】如何解决 Pod 无法挂载 PVC问题
后端·云原生·容器·kubernetes
向前看-9 小时前
验证码机制
前端·后端
超爱吃士力架11 小时前
邀请逻辑
java·linux·后端