decision

技术管理必备技能之决策

前一篇我们聊了优先级,以有限应对无限,今天再聊一聊经常会用到优先级的决策。

记得我刚开始带团队的时候,有位前辈和我说过,管理就是收集信息,做出决策。 这里的决策就是我们今天要聊的内容。

一个组织最有限且不可再生的资源是什么,就是成员的工作时间。 对于一个互联网企业或软件企业来说,人力成本是最大的成本。 而作为一个技术团队的管理者,其最大的作用是如何让研发同学的时间能产生最大的价值,也就是如何让这些成本的 ROI 最高。 为了提高 ROI 的时,我们经常要做出决策。那么什么是决策?

在说决策之前,我们先说一下决定,决策和决定是不同的。 在各种会上,或者平常的工作中,我们会做各种各样的决定,用哪种架构,做哪个流程或者用哪种方案等等。 只有这些决定产生了资源的分配,才是真正的决定,否则就只能算是一个「伪决定」,或者说根本没有改变什么,也就没有真正的决定什么。 上面所说的资源不仅仅是实体的资源,还有组织中最有限且不可再生的资源:组织成员的工作时间。

一个决定通常具备三个特征:

  1. 有要达到的目标 —— 没有目标,任何决定都无所谓
  2. 有选择或者说有不同的可选方案 —— 没有选择就没有决定可做;
  3. 资源是有限的 —— 资源如果是无限的,我们就可以做任何我们想做的事,而不需要做选择。

综上所述,决定就是选择最好(最合适)的方案,以有限的资源达成目的,其本质是资源的分配。

那么决策是什么,决策和决定是什么关系?

决策是关乎未来的,决策是一组具有长远影响的决定,是一系列的资源分配。

如何决策?

为回答这个问题,我们按结构化思维,把整个决策分为决策前期,决策中期和决策后期。

1. 决策前期

「功夫在诗外」,收集信息,决策是面向未来的连续决定,每个决定都是有着资源的分配,技术管理者作为分配环节主导人之一,如何高效的决策是一个值得探讨的命题。

1.1 收集信息

我们的决策大多是基于已有的信息做的,为了让决策更优,需要持续地收集信息。 虽然在我们需要做出决策时会了解一些信息,但更多的是平常的工作中主动去收集信息,支撑后续可能遇到的决策。

1.1.1 我们需要收集什么样的信息

收集信息,其实也是一个决策的过程。 确认要收集什么样的信息是确认收集的目标,我们收集信息是为了辅助做下一个决定,基于这个决定再来看要收集什么信息。

1.1.2 如何收集信息

平常工作中我们信息的收集渠道主要有如下一些:

  1. 从周报中收集;
  2. 从 IM 等沟通工具中,关注各种群的信息;
  3. 从文档中,历史的文档,团队的文档,此时要求有哪些文档;
  4. 从会议中收集,如需求规划会、技术方案评审会,晨会,例会等;
  5. 从平常的聊天中收集,正式的沟通或者非正式的聊天;
  6. 外部用户、内部员工投诉或反馈的问题;
  7. 从自建的一些质量监控报告,自动化测试报告,自动构建的结果和系统的告警、线上的事故;
  8. 从服务于整个公司或部门的业务支撑系统,大数据系统等;

通过这些渠道我们将收集到很多信息,在收集的过程中要注意信息的适当性、正确性和全面性。可以考量如下一些方面:

  1. 信息是否全面,是否包含了时间维的信息,如过来的信息和未来的假设;
  2. 信息收集的范围是否全面,是否包含了不同角色的观点;
  3. 信息是否是片面的,因为片面的信息可能会导致错误的推导,从而影响下一步的决定;
  4. 信息中是否包含错误或有些偏误的部分,有没有和权威机构做一些对比。

1.1.3 如何使用这些信息

  1. 通过收集到的信息评估我们过去对未来的假设是否正确;
  2. 通过收集到的信息评估我们有没有往目标靠近,如果能达成目标,或者能向目标靠近就是好的决定,可以继续,否则就需要调整。

1.2 确认目标

做开始决策时,先思考自己的目标,我们经常说「以终为始」,用想要的结果来反推现在的工作,用目标来标注现在的方向。

一个好的目标包括三个部分:

  1. 明确的目的 — 我们最终要的是什么,方向在哪里,目的地在哪里,「以终为始」;
  2. 明确的范围和边界 — 包括什么,不包括什么,没有范围和边界的目标不是目标;
  3. 明确的视角 — 我们从谁的角度/观点看事情,做决定,视角决定了方向。

对于目标我们一定要思考我们目标是否和组织的目标一致,是否和公司的战略一致。

技术管理者的责任是要用有限的资源去达到组织的目标,即使在处理眼前问题的时候,也必须以目标为思维的起点去思考,做决定,以终为始,这样才可能达到目标。

确定目标后才开始做决策。

2.决策中期

因为资源是有限的,而我们要面对的是一个无限的世界,以有限应对无限,就需要有优先级。

2.1 确认优先级

在确认优先级之前我们需要先明确未来的目标和现状有多大的差距,这个差距需要做哪些事情才能达成,哪些事情是最重要的,如果是最后一博,应该做哪件事?

把所有的事情拉通了来看,是否现在做的是最重要的,有没有更重要的事情要做,有没有重要不紧急的事情要做,如果有,那么就先做重要的,尽量做重要的事情不做紧急的事情,。

如果几件事的重要程度相当,从它们可能造成的影响或风险的角度来区分轻重,先做正面影响大、风险小的事情。

需要有所取舍,不要只看到短期的收益,对于长线的收益也不能忽视。

2.2 可选方案

在明确了目标,确认了优先级,下一步的核心的思考是有没有更好的方案。 更好的方案就意味着有多个方案,往往最终的方案不是某一个方案,而是多个方案综合起来后的方案。

我们在做决策时,常常落入只有一个方案的陷阱中,然后去思考这个方案有没有问题,或者如何让方案更优。 此时我们更应该做的是按「 MECE 原则」,尽可能的穷举行业内的,公司内的所有可能的方案,评估这些方案的优劣,成本收益,再确认方案是什么。

在评估方案时,列一个表格,设定必要项,可选项及其权重,对可选项进行评分,加权汇总,最终可量化的得出一个方案。 然后在这个得出的方案基础上再去完善。

2.3 影响决策的心理学

2.3.1 锚定效应

锚定,是指人们倾向于把对将来的估计和已采用过的估计联系起来。

我们在做决策的时候,当评估好坏时,经常会和一些锚定的东西对比,或者和一些先入为主的信息作对比,因为本来也不存在绝对意义上的好和坏,一切都是相对的,关键看我们如何定下基点。 基点定位就像一只锚一样,它定了,评价体系也就定了,好坏也就评定出来了。

2.3.2 惯性思维

先看一个关于惯性思维的小故事,这个小故事里的逻辑在我们在给人出脑筋急转弯的时候也会经常用到,故事是这样的:

心算家阿伯特·卡米洛从来没有失算过。有一天他做表演时,有人上台给他出了道题:“一辆载着283名旅客的火车驶进车站,有87人下车,65人上车;下一站又下去49人,上来112人;再下一站又下去37人,上来96人;再再下站又下去74人,上来69人;再再再下一站又下去17人,上来23人……”

那人刚说完,伯特·卡米洛便不屑地答道:“小意思!告诉你,火车上一共还有……”。
“不,”那人拦住他说,“我是请您算出火车一共停了多少站口。”
阿伯特·卡米洛呆住了,这组简单的加减法竟成了他的“滑铁卢”。
阿伯特·卡米洛是心算家,不论是算车上还有多少人,或火车一共停了多少站口,都是难不住他的。

惯性思维也称为思维定势,也就是我们常说的手里拿了一个锤子,看到什么都是钉子,总想敲一敲。 在环境不变的条件下,思维定势使人能够应用已掌握的方法迅速解决问题。

惯性思维是人类进化过程中形成的对人类有帮助的思维定势,能减少日常中很多时候思考问题的繁琐步骤,快速解决问题。 但是它不会一直正确,可能在我们做决策的时候把方向引导到一条偏僻或者不正确的路上,此时我们就需要打破惯性,重新出发。

2.3.3 沉没成本

沉没成本,是指由于过去的决策已经发生了的,而不能由现在或将来的任何决策改变的成本。

从决策的角度看,以往发生的成本只是造成当前状态的某个因素,当前决策所要考虑的是未来可能发生的成本及所带来的收益,而不考虑以往发生的成本。

人们在决定是否去做一件事情的时候,不仅是看这件事对自己有没有好处,而且也要看过去是不是已经在这件事情上有过投入。我们把这些已经发生不可收回的支出,如时间、金钱、精力等称为「沉没成本」。

有一个叫亚克斯的心理学家说过:“一个人生的90%以上的不幸都是因为不甘心造成的”,在生活中我们常常为了逃避损失带来的负面情绪而一味的沉迷于之前的付出当中,我们会选择一种非理性的思考方式。决策时我们需要特别注意。

2.3.4 确认偏误

确认偏误也称为「证实偏差」,它一般指在一大堆证据里面,人更容易注意,记住和相信对自己有利的证据,忽略相反的证据。

中国古代有句老话叫:“情人眼里出西施”,当你喜欢一个人的时候,她的一切都是这样的美好,你会找出她的各种优点在你的朋友面前描述她。

2.3.5 X-Y PROBLEM

X-Y PROBLEM 大概是这样:

  • 某人想要解决 X
  • 他不知道怎么样才能解决 X,但感觉 Y 可以解决
  • 他同样不知道怎么样才能解决 Y
  • 他寻求 Y 的解决办法
  • 其他人想要帮助他解决 Y,但是摸不着头脑为什么要使用 Y
  • 经过漫长的交流,终于明白了原来他是想要解决 X,而 Y 并不是解决 X 的合适的方案

做决策往往是要解决一些问题,而问题可能并不是根本的问题,只是一个表象,需要我们找到问题的根本原因再去做决策,否则就会在一个方向性的错误上浪费资源。

3.决策后期

在方案确认后就进入决策的后期,也就是决策的执行环节。 在执行决策过程中,还要持续地收集信息,对人员进行管理,对风险进行管理

3.1 人员管理

任何决策都是需要有人去执行的,项目管理中经常用到的 RACI 矩阵表能较好地解决人员管理的问题。

项目名称 执行(R) 决策(A) 顾问(C) 通知(I)
订单系统 研发二组 产品组王五 李四 商业化部门

RACI 矩阵表解释如下:

  • 谁负责(R = Responsible),即负责执行任务的角色,他/她具体负责操控项目、解决问题。
  • 谁批准(A = Accountable),即对任务负全责的角色,只有经他/她同意或签署之后,项目才能得以进行。
  • 咨询谁(C = Consulted),拥有完成项目所需的信息或能力的人员。
  • 通知谁 (I =Informed),即拥有特权、应及时被通知结果的人员,却不必向他/她咨询、征求意见。

有了 RACI 矩阵的表,我们就可以知道资源是谁在分配,谁来拍板,谁能够给我们提供帮助,谁能给我们提供输入,谁来具体执行,出了问题应该找谁,做好了找谁去汇报或通知。

3.2 过程控制

决策不是一个一次性的事件,是一个不断进步或者演变的过程。 决策是面向未来的,而其依据的却是已经发生了的事实和我们对于未来未知的假设。

在执行决策过程中,我们需要持续地收集信息,观察事项发展的态势和环境的变化,主动评估当时的决定对未来所做的假设是否还成立,评估实施后的效果是否达到预期,如果发现假设不成立或不达预期,要及时调整决策。

过程中可以设置如下一些机制以对整个过程进行控制:

  1. 假设实验的机制,因为决策是基于一些过去的事实和对未来的假设做出的,未来是不可知的,因此我们需要基于假设做一些实验,小范围试点,现在流行的数据驱动,A/B 实验是一个比较好的落地方案。这种机制是为了把未知转化为可能的风险,然后通过实验降低、控制、管理风险。
  2. 复盘的机制,每到一个里程碑做一次复盘,确认成果,并检查我们之前的假设是否正确,是否需要调整,复盘之后再重新出发。

4. 后记

技术管理的工作就是在不确定性中寻找平衡,通过不断地收集信息,决策,改变资源从而改变团队、架构,让组织的 ROI 更高。

你好,我是潘锦,超过 10 年的研发管理和技术架构经历,出过书,创过业,带过百人团队,也在腾讯,A 股上市公司呆过一些年头,现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM,对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣,平时喜欢读书、思考,终身学习实践者,欢迎一起交流学习。微信公众号:架构和远方,博客: www.phppan.com

priorities

以有限应对无限-互联网产品研发过程中的 5 种等级

一个互联网产品的生命周期大概可以分为需求阶段,研发阶段,运营阶段。 在需求阶段,通常我们会有需求优先级; 在研发阶段,会有转测 BUG 等级,BUG 的严重程度; 在运营阶段,会有线上 BUG 等级,线上事故等级。

为什么会有等级或者优先级?其背后的根本原因是资源是有限的。 在有限的资源内,如何更好地完成需求,修复线上问题,处理线上事故是我们在研发管理过程中要反复面对的问题。 而这个要反复面对的问题,业内通用的解决方式是定优先级,也就是我们常说的 P0,P1……

1. 需求优先级

需求优先级,指产品需求的优先级,哪些需求先做,哪些需求后做,哪些需求不做,其关注的是业务价值或者要解决问题的价值。

需求优先级一般有 3 个,P0,P1,P2 在资源有限的前提下,P0 是必须要做的,P1 是在 P0 做完后有空余人力可以去做,P2 现阶段基本可以不做。

当业务方问为啥我们:“这个需求没有咋没有排上,我都提了这么久了,你们是怎么评估优先级的?” 我们需要有一些相对客观的逻辑或方法来回复业务方。

需求的评估可以分两步:

第一步:从需求的角度来看,任何一个需求一定服务于某个战略 / 某个目标 / 某个场景,需要根据其服务的目标来做第一次的优先级评估。

  • 如果是服务于战略,根据战略的级别和影响范围来评估,比如是公司级的战略项目优先级肯定要高一些;
  • 如果是服务于某个目标,这里的目标可能是合同或者营收,根据合同的金额,合同的客户以及营收的大小来评估,比如一个合同金额为 500 万和一个合同金额为 5 万的需求,会有比较明显的优先级区别;
  • 如果是服务于某个场景,那这个场景一定有对应的目标人群,根据目标人群的特征、数量和其影响范围来评估,比如有些需求在业务关键链路上,优化可以影响的用户量比较多,又或者某些影响核心链路可用性的技术建设需求,当核心链路不稳时,所有用户都会受影响,此时需要评估为最高优先级;

在以上评估的基础上,还需要基于具体的实现做第二步的评估:

  • 参考需求实现的成本和难度,对于开发成本低,周期短,但价值高的需求,需要给予更高一些的优先级,其实就是看一下性价比;
  • 对于存在关联关系的需求,可能适当地调整优先级,比如某个需求 A 优先级高,另一个需求 B 优先级低,但是在做需求 A 的时候,再加点点人力就可以顺便把需求 B 给做了,此时可以适当调整,这里主要考虑的是事情的完整性,基于减少了认知成本和沟通成本的出发点;
  • 对于存在依赖关系的需求,可以适当调整优先级,比如在开发某个产品时,可以先把 MVP 版本的需求先做了,实现主体流程先跑通,或者某些需求在前后端上有依赖,可能需要后端先行等等。

以上只是我们评估的逻辑,换成更高大上的说法有如下一些方法:

  • 卡诺模型( KANO 模型):必备需求 > 期望需求 > 超出预期需求 > 无差异需求
  • 维格斯法:分为四个纬度进行评估:收益(Benefit)、损害(Penalty)、成本(Cost)、风险(Risk)。收益和损害是从客户角度出发,而成本和风险则从实现角度出发。
  • 波士顿矩阵:由用户价值维度和公司价值两个维度将需求分成了 4 个象限:明星需求,问题需求,金牛需求,瘦狗需求。
  • RICE 方法:包含 覆盖率,影响,信心和努力 4 个部分。对要素进行排名并根据这 4 个因素计算得分,以确定优先级。
  • WSJF 优先级:加权最短作业优先,项目成本 = 用户商业价值 + 时间成本 + 降低风险 / 新机会
  • 工作量和影响矩阵:也称为「价值与复杂性」矩阵,将工作量和影响组合分为 4 个象限
  • MoSCoW 方法:必须具备 > 应该具有 > 可能具有 > 非必要
  • 艾森豪威尔矩阵(时间管理四象限):马上要做(重要紧急) > 计划要做(重要不紧急) > 备选(紧急不重要) > 不需要做(不重要不紧急)

2. 转测 BUG 等级

转测 BUG 等级关注的是对测试执行的影响,这里之所以叫转测 BUG,是为了和线上运营时的线上 BUG 做区别。

转测 BUG 在 CMMI5 标准中可以分为 3~5 个等级,在实际研发过程中,我们常常将其分为 4 个等级,这里的等级属于处理的优先级,即对我们处理的时间和先后顺序有要求,如下:

等级 说明
P0 马上解决,表示 BUG 需要马上解决,否则就无法达到预期,测试执行完全没法操作
P1 急需解决,表示 BUG 的修复很紧要,关系到系统主要功能模块是否正常,严重影响测试执行
P2 高度重视,表示 BUG 有时间就要马上解决,否则系统偏离需求较大或预定功能不能正常实现,对测试执行有影响,但是可接受
P3 正常处理,表示 BUG 按个人计划解决,不影响需求的实现,在需求上线发布前需要确认解决或确认可以不予解决,对测试执行影响较小

以上是 BUG 的处理优先级,但是我们在确认 BUG 时还有一个维度是严重程序,如下:

严重性 说明
致命(非常严重) 在流程、数据或安全方面存在重大问题,导致软件不具可用性,或核心功能项无法使用,如系统崩溃、无法启动、实现和需求严重不符等导致测试无法进行
严重 由于设计的缺陷,导致软件使用中存在较明显的障碍,或者局部功能错误,但可以采取其他变通的操作实现,如功能未实现、功能错误,通讯错误等
一般 由于编码不够完善,使某个小功能无法使用,或者对特殊的操作与要求不能支持
提示 存在某些细微的缺陷,但不影响程序正常应用或该功能在下次升级版本中可以实现

对于转测 BUG 的优先级和严重性,有如下一些注意事项:

  1. 优先级和严重性并不总是一对应。有时候严重性高的 BUG,优先级不一定高,甚至不需要处理,而一些严重性低的 BUG 却需要及时处理,具有较高的优先级。如界面单词拼写错误,但是如果是系统名称或公司名称的拼写错误,则必须尽快修正,因为这关系到系统和公司的市场形象;
  2. 修复 BUG 不是一件纯技术问题,有时需要综合考虑项目周期、质量风险和修复成本等问题。例如如果某个严重的 BUG 只在非常极端的条件下产生,则可能没有必要马上解决,又或者修复一个 BUG 需要重新修改系统的整体架构,可能会产生更多潜在的 BUG,而且产品由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,需要通盘考虑后,以确认是否需要修正。

3. 产品模块等级

在讲线上 BUG 等级前我们需要先讲一下产品模块或产品链路等级。因为不管是线上 BUG 还是线上事故,其优先级的判定都依赖于产品模块的等级,在产品模块等级的基础上叠加影响范围 / 影响时长之类的因素才能构成线上 BUG 等级和线上事故等级。一般我们将产品模块等级分为以下 3 个等级:

等级 说明
P0 核心功能流程,是一个产品安身立命的根本,最最基础的功能,如电商场景下的浏览商品、商品详情、支付购买等
P1 非核心流程,却是重要的业务模块,如电商的优惠劵兑换、商详页里面的用户评论,在系统遇到问题时,可以降级的部分
P2 非核心流程,当不可用时,用户可以接受晚点再来,如一些运营活动,个人信息的展示等

基于产品模块等级我们讲一下在运营阶段常见的线上 BUG 等级和线上事故等级。

4. 线上 BUG 等级

线上 BUG 是指在线上环境中发现的 BUG,是相对于转测 BUG 来说,其关注点是对用户使用的影响,其优先级的评定也是根据用户影响范围及程度来决定的。 在实际执行中我们通常会根据客服的反馈和 BUG 所在的业务的重要程度来决定处理优先处理。

等级 说明 反应时长 处理周期
P0 因程序导致的 P0 级业务流程不可用,影响所有用户或大面积用户,或对用户/公司造成了实际经济损失,闪退 5分钟 1 小时内
P1 因程序导致的 P0 级业务流程不可用,但只影响部分用户正常操作,或 P1 级业务流程不可用,但影响所有用户 / 大面积用户 10 分钟 24 小时内
P2 因程序导致的 P1 级非核心业务流程异常,若持续故障将可能大面积影响用户体验 1 小时 1 周内
P3 因程序导致的 P1 / P2 非核心业务流程异常,影响少量用户使用体验 2小时内 两到三周内

5. 线上故障等级

线上 BUG 专指由于程序的问题导致的线上问题,而线上故障是对所有对线上业务产生了一定范围影响的线上问题。

线上故障和线上 BUG 不相同,线上 BUG 不一定会产生线上故障,而线上故障也不一定是由线上 BUG 造成的。如 DDoS 攻击,机房断网,域名到期等等都有可能产生线上故障。

线上故障等级关注的是对业务的影响范围和持续时长,实际应用中我们用可用性 SLA(Service-level Agreement)来描述和约束线上故障。其优先级如下:

等级 说明 反应时长 处理周期
P0 P0 级业务流程不可用,影响所有用户或大面积用户,或对用户/公司造成了实际经济损失 5分钟 1 小时内
P1 P0 级业务流程不可用,但只影响部分用户正常操作,或 P1 级业务流程不可用,但影响所有用户 / 大面积用户 10 分钟 12 小时内
P2 P1 级非核心业务流程异常,若持续故障将可能大面积影响用户体验 30 分钟 1 周内
P3 P1 / P2 非核心业务流程异常,影响少量用户使用体验 1 小时内 两三周内

6. 后记

优先级是我们以有限应对无限的策略,在没有办法的情况下可以这样用,但是如果人力充足是否就不需要优先级了?

答案是:依旧需要。

对于优先级更深层次的思考是 ROI,如何让研发投入产生更大的价值,是我们要不停思考的问题。

 

promotion

晋级 7 问 – 技术晋级答辩中常见问题解析

在一些大一些且相对正规的互联网企业,每年都会有一到两次的晋级答辩,在晋级答辩的过程中,台上要晋级的同学努力准备好 PPT ,希望在有限的时间内能说明通道评委能相信自己所说,能认可自己是一个和晋级标准能力对应的同学。而台下的评委,则从 PPT 中,从提问过程中确认台上的同学是否符合自己认知范围内某个级别的标准,给出相对客观公平的分数,最后得出一个晋级与否的结果。当然「无利不起早」,一般过了级的同学在加薪以及组织范围内的重要程度会有所提升和偏重。

但是今天我们不聊如何晋级答辩,我们来看看作为一个评委来如何提问。

有人说:「世界上最难的事有两件,一是把自己的思想装进别人的脑袋,二是把别人的钱装进自己的口袋。」

作为一个评委如何提出问题,找到对方想要告诉你的观点/论点以及相应的论据,并评估其准确性,并规避掉大多数的陷阱,这是一个批判思考的过程。

那么我们如何能系统的提出问题,了解到自己想要的信息,或达到自己的目的?

当别人想把思考装进我们的脑袋时,他一般会提出一个问题,并引出一个论点,针对这个论点提供一些论据来佐证,以让你相信他。

首先我们对对方表述的内容做一个结构化的梳理,大概的结构如下:

问题:
结论:
理由:

结论是晋级者在晋级述职时在 PPT 或表述时要传达给评委的多个观点,是晋级者想让评委相信的内容

评委心声:他想让我相信什么 / 他想表述的观点是什么

结论就是一个个观点,这些观点需要其他观点和证据来进行支撑。没有证据支撑的断言,不能称为结论,而只能称为纯观点。

评委心声:你为什么会有这个结论,这个结论是从哪里来的,有没有什么可量化的数据支撑

一般来说,评委大多数都会基于晋级者客观的表现和自我的认知来打分,而晋级者的水平参差不齐,为了不错过那些确实有能力,但是在表达方面有所不足的同学,需要提问得到自己想要的信息。

在晋级同学讲完后,评委一般会基于 PPT 内容来提问,以确认其表述的准确性或希望晋级者能有更好一些的回答表现来证明有自己的做事逻辑和方法论,以确认有类似的问题也能解决,是能力达到了的表现。

晋级答辩对于晋级者和评委来说都是一个考验,晋级者尽可能多的把自己的能力展现出来,而评委尽可能公平公正的评判。 晋级对于评委来说,是工作,也是考试,整个过程相当于连续 N 场的考试,考核评委看人识人的水平,而在这个过程中,评委可能通过倾听晋级者的讲述得到一个初步的评价,同时通过提问来佐证自己的判断,以下是关于评委提问的常见逻辑,其主要出发点并不是为难晋级者,而是想通过提问找到能佐证晋级者能力的项,以做到相对公平。

1. 问定义

在晋级者讲述时经常会有一些模糊指向的词,而这些词在晋级者平常工作中经常遇到,以为评委知道,然而评委第一次接触并不了解。特别是一些表义比较泛的词语,在不同的语境都有着不同的含义,比如“架构”这个词,不同的人在不同的时期,在不同的场景对它的定义就不同。所以评委会在晋级者表述观点中有一些模糊性指向的词语的时候,或者存在意思不明确 / 有歧义的情况时候,做出提问。

比如在我们晋级中常常会说:做了服务性能优化,接口速度快了很多 这里评委可能会问:

  • 这里的服务是指什么服务?
  • 这里的性能是指什么?
  • 优化是做了什么操作
  • 快了很多是多少?从多少提升到多少?如何量化的?

服务和性能等词语都是比较泛的,比如性能可能是查询的性能或者写入的性能,并且不同的性能其对应的优化方案完全不一样,有些是技术点的优化,有些可能是整个架构的调整。

晋级提示: 精准用词,减少歧义

2. 问过程

一个事情只有有了好的过程,才会有好的结果,并且没有好的过程的好结果是不可重复的。 对过程提问主要是想了解并确认晋升的同学在项目中的扮演的角色,具体的工作,发挥的作用,以及对项目的掌握度。 特别是一些在 PPT 或者讲述的时间有些信息没有讲清楚的同学,评委此时需要通过提问的方式来把这个项目信息补充完整。常常通过以下的维度来提出问题:

2.1 背景原因

  • 为什么要做这个方案 / 系统?背后的思考是什么
  • 这个项目要解决的核心痛点是什么?
  • 为什么是你来做这个?
  • 你在项目中的角色是什么?
  • 在项目执行过程你个人的价值如何体现的?

2.2 技术细节

  • 某个技术点是如何实现的,讲一下细节?
  • XXX 模块为什么要这样设计?有没有更好的方案?
  • 这里为什么要用 XXX 缓存?为什么要使用这样的缓存设计?可以不用缓存吗?
  • 业务领域为什么要这样划分?当时的思考是怎样的?
  • 这里为什么要用 XXX 协议?如果换成 YYY 协议会怎样?

2.3 方案风险

  • 做方案时有没有参考业界的方案,是哪些方案,方案的优劣是怎样的?
  • 为何选择当前这个方案?
  • 在评估方案时,考量的维度有哪些,为什么是这些维度?各维度的权重如何?
  • 对当前有进行全面的风险分析吗?分析结果是什么?
  • 如果分析出来的风险发生,如何应对?

2.4 数据指标

  • 为什么要用 XXX 指标?背后的逻辑是什么?
  • 这个项目产生的可量化的效果数据是怎样的?当初的预期是怎样的?达成情况如何?
  • 项目开始时定的目标是 3 倍,为什么这里是 3 倍而不是 5 倍 10 倍,有什么依据?
  • 这些数据是如何得出来的?
  • 为什么这里的提升是 30%?能不能到 50% ?如果要到 50% ,需要做什么?为什么当时不做?

晋级提示: 科学决策方案、可量化数据、能重复过程

3. 问难度

不同的级别对于难度的要求不一样,难度这个项能在一定程度上区分是否满足某个级别的要求。 在答辩过程中评委可能会针对相应的级别提出一些有难度的问题,这里的难度不局限于某个技术难点,可能是某些行业内最新的动态,或者某个经典策略/方案/架构,或者最新的架构/语言/范式等等,比如:

  1. 项目中你觉得最难的点是什么? 为什么这个才是最难的?
  2. 可以谈一下你对现在业界比较流行的 XXX 的看法吗?
  3. 你对业界现在最热的 XXX 怎么看?为什么没有用到你这个项目里面来?

晋级提示: 有难度才有区分度

4. 问大局观

在高阶一些的级别中,对于事情的大局观是一个比较看重的项。 这里的大局观是指从宏观角度看问题,分析问题,从更大的整体来解决问题,实现技术价值的全局最大化,而不仅仅是局限于自己的一亩三分地。常见问题如下:

  • 你所在项目的上下游是哪些?整个链路是如何联接的?
  • 在这个项目上你有影响产品经理什么吗?如果有的话,是哪些?如何影响的?
  • 你对项目最大的影响/改变是什么?当时是如何思考的?

晋级提示: 大局观决定了高度,尽在掌握

5. 问方法论

思考和总结是高阶一些的级别需要特别体现的内容,一般会落地成方法论,表示这个项目我这次能做成,下一次还能做成,有自己做事的节奏和方法。比如你讲某个地方的优化使用了缓存,此时需要对于缓存使用有自己的方法论,对于缓存其适用场景,优劣势,原理都尽在掌握,下次遇到类似的问题还可以解决,而且可能还是不同的方案,但是做事的方法和逻辑一样。

  • 从这个项目你学到了什么?你最大的收获是什么?
  • 如果还有 XXX 项目,你会怎样做?
  • 你做 XXX 决定的逻辑框架是什么?
  • XXX 背后的思考是什么?

晋级提示: 持续的成功才是能力

6. 问业务价值

技术最终还是服务于业务产生价值,而在晋级中如何把在做的东西的业务价值体现出来,也是要着重思考的。 如果你在讲述过程中没有提起或者提得不那么明显或清晰,那么评委可能会就此提问,可能的问题如下:

  • 这个项目的用户是哪些人?他为用户带来了什么?
  • 如何衡量你这个项目的价值?项目价值衡量的维度是否合理?
  • 从公司层面(部门/某个大一些的组织)看,你认为这个项目贡献情况如何?
  • 你当前组织的业务目标是什么?你这个项目是如何服务于这个业务目标的?如果没有这个项目业务目标会怎么样?

晋级提示: 将技术与业务价值和公司(部门)目标关联上

7. 问学习成长

  • 你在 PPT 上有讲架构能力有所欠缺,你打算如何提升这方面的能力?
  • 你有提到持续学习,你将如何持续学习,学习什么,有什么计划,预计会有什么样的收益?
  • 想象一下,一年后的你是怎样的?三年呢?五年呢?

晋级提示: 学习能力是必备能力之一

8. 技术晋级常见问题

以下是两个常见的问题集

8.1 性能优化

做了 XXX 优化,性能提升了很多

  • 为什么要做这个优化?做这个优化的出发点是什么?
  • 这里的性能是指什么?
  • 提升了很多是多少?从多少提升到多少?如何量化的?
  • 性能提升后对用户有什么影响?有什么业务价值?
  • 在系统中还有类似的性能问题吗?有没有系统思考过产生这个问题的原因?
  • 从研发流程或研发制度上有没有可以优化的点来规避这些性能问题?

8.2 信息系统

做了一个系统

  • 为什么要做这个系统?做这个系统的初心是什么?
  • 能解决什么问题,能带来什么效果
  • 能给公司带来什么价值?如何衡量这个价值?
  • 带来的这些价值如何服务于公司级的业务目标?
  • 系统的架构是怎样的?
  • 系统设计的时候有没有参考业界的方案?
  • 当时做方案选型的时候是如何评估的,重点是考察了哪些点?为什么要考察这些点,当时的思考是什么?
  • 你在这个系统过程中扮演的是什么角色?
  • 系统的优势和不足在哪里?
  • 这个系统下一步如何发展

9. 后记

晋级对于我们来说意味着「升职加薪」,意味着我们的能力、知识、技能等得到某种官方的认可。 同时也意味着将来要承担更多的责任,也会被更多的期待。

晋级并不是结束,而是下一个开始。

最后,今天是五一劳动节,祝大家节日快乐。

你好,我是潘锦,超过 10 年的研发管理和技术架构经历,出过书,创过业,带过百人团队,也在腾讯,A 股上市公司呆过一些年头,现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM,对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣,平时喜欢读书、思考,终身学习实践者,欢迎一起交流学习。微信公众号:架构和远方,博客: www.phppan.com