许晓斌-负责任的技术规划 mdash;mdash; 不仅仅是技术.pdf

演讲人：许晓斌

目录

01背景、技术规划源头02业务、产品、技术目标

03规划的承载-OKR04上下文环境分析

业务背景

服务的部门岗位和技术栈

•淘天（淘宝、天猫）•后端工程师-Java（70%+）

•阿里云•前端工程师–JavaScript，TypeScript

•国际部门（AliExpress，Lazada•后端工程师–Go，C，C++

等）

•算法和数据工程师–Python（增长）

•菜鸟

•测试、运维/SRE

•本地生活、高德

•大文娱（优酷等）

整体覆盖数万的工程师

为什么要做规划

为了半年/一年的绩效考核

组织习惯：财年开始做规划

老板的要求

聚焦团队的资源，实现关键的业务目标

直接业务目标：通常是和经营、财务直接相关的。例如指标：产品年度的收入，利润，运营成本

（包括硬件资源成本，人力成本）

间接业务目标：和用户规模和市场占有率相关的，例如月付费用户数，市场渗透率，用户的留存

率等等。（前提：开放竞争市场）

•

•

•

•

从组织的生存逻辑上看，组织内部很多时候也不完全是一个市场逻辑，这个时候一些关键干系人

的需求就往往会直接变成业务目标

虑

业务、产品、技术目标

通过产品目标支撑业务目标的实现

其他方法：销售、运营、资源优化等

关注用户行为的变化，而不是交付什么产品特性

产品假设实际上是规划的核心组成部分

技术决定了产品交付的可行性

技术理解决定产品的insight

领域模型是产品和技术的sharedunderstanding

技术目标本来就是产品目标

最后：技术的效率，决定交付效率，决定了产品可以更快速验证假设

规划的承载：OKR

OKR的产出依赖大量的分析活动

大型组织的研发活动需要聚焦一致

组织OKR对齐讨论会，对齐理解，有不一致的地方讨论

组织上下文环境

唯技术论激励方式错误

团队知识背景的缺失，团队内缺乏足够例如：在OKR设定后基于KR的具体数

的业务和产品专业知识，这在技术主导字进行僵化的考核，给团队带来巨大的压

的团队中比较常见，他们非常容易陷入力，决策者会在压力下作出明知不正确但

到唯技术论的状况中而忽略了用户价值，不得不做的判断，

网上有一段著名的乔布斯被质疑不懂技

术后的回答视频，非常好的体现了这一例如，如果团队的管理氛围不允许成员犯

现象。错，那么团队成员就不会把假设放在台面

上讨论，更不会去主动验证假设了。

不做量化和数据分析河马现象

证假设需要成本，无论是去做量化，做数HiPPO，HighestPaidPerson’sOpinion

据分析，还是做用户访谈，都需要投入非的缩写，或者可以称之为老板一言堂

常多的资源。有时候技术系统错综复杂，