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

1、演讲人：许晓斌目 录01背景、技术规划源头02业务、产品、技术目标03规划的承载-OKR04上下文环境分析业务背景服务的部门淘天（淘宝、天猫）阿里云国际部门（AliExpress，Lazada 等）菜鸟本地生活、高德大文娱（优酷等）整体覆盖数万的工程师岗位和技术栈 后端工程师-Java（70%+）前端工程师 JavaScript，TypeScript 后端工程师 Go，C，C+算法和数据工程师 Python（增长）测试、运维/SRE为什么要做规划为了半年/一年的绩效考核组织习惯：财年开始做规划老板的要求聚焦团队的资源，实现关键的业务目标直接业务目标：通常是和经营、财务直接相关的。例如指标：产品

2、年度的收入，利润，运营成本（包括硬件资源成本，人力成本）间接业务目标：和用户规模和市场占有率相关的，例如月付费用户数，市场渗透率，用户的留存率等等。（前提：开放竞争市场）从组织的生存逻辑上看，组织内部很多时候也不完全是一个市场逻辑，这个时候一些关键干系人的需求就往往会直接变成业务目标虑业务、产品、技术目标通过产品目标支撑业务目标的实现其他方法：销售、运营、资源优化等关注用户行为的变化，而不是交付什么产品特性产品假设实际上是规划的核心组成部分技术决定了产品交付的可行性技术理解决定产品的 insight领域模型是产品和技术的 shared understanding技术目标本来就是产品目标最后：技

3、术的效率，决定交付效率，决定了产品可以更快速验证假设规划的承载：OKROKR 的产出依赖大量的分析活动大型组织的研发活动需要聚焦&一致组织 OKR 对齐讨论会，对齐理解，有不一致的地方讨论组织上下文环境唯技术论团队知识背景的缺失，团队内缺乏足够的业务和产品专业知识，这在技术主导的团队中比较常见，他们非常容易陷入到唯技术论的状况中而忽略了用户价值，网上有一段著名的乔布斯被质疑不懂技术后的回答视频，非常好的体现了这一现象。激励方式错误例如：在 OKR 设定后基于 KR 的具体数字进行僵化的考核，给团队带来巨大的压力，决策者会在压力下作出明知不正确但不得不做的判断，例如，如果团队的管理氛围不允许成员

4、犯错，那么团队成员就不会把假设放在台面上讨论，更不会去主动验证假设了。不做量化和数据分析证假设需要成本，无论是去做量化，做数据分析，还是做用户访谈，都需要投入非常多的资源。有时候技术系统错综复杂，光测量一个指标就需要很大的工程工作，有时候拜访用户还需要出差，还需要记录和分析。河马现象HiPPO，Highest Paid Persons Opinion 的缩写，或者可以称之为老板一言堂当团队的最高管理者因为个人喜好、临时感受、对下属的偏见、或者过度自信产生的傲慢等各类因素给出决策，不用数据和逻辑支撑决策却强势要求执行的时候，科学的方法自然就失效了。建立丰富的团队背景，综合技术、产品和业务能力。鼓励相互沟通增强理解。更科学的考核方式，不要把 OKR 等同于 KPI从长期主义看，重视量化和量化积累，并积极投入Leader 以身作则THANKS大模型正在重新定义软件Large Language Model Is Redefining The Software