晋级 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

聊聊周报-团队管理和自我管理的利器

在职场多年,但凡大一点点的公司,周报/日报大多成了标配,而各家公司对于周报的要求也不相同,大家写周报的方式也不相同,有些是为了应付一下,如有这样写的: 本周周报:完成了上周工作,和领导交待的事项,下周继续;

有些的好一些,记了个流水账,大概是这样:

周一做了 XXX
周二完成了 XXX
周三对接了 XXX
……

再好一些的,对这些流水账做了一个分类:

上周完成:
重点事项:XXX
非重点事项:XXX
临时工作:XXX
下周计划:
重点事项:XXX
非重点事项:XXX

再好一些的,就会加一些可衡量的内容,或者一些量化的数据。 如此种种 还有更好一些的,都写成小作文了。 然而不管上面的这些如何,大家「苦周报久矣」。是什么让我们觉得周报是种负担,为什么我们不想写周报?

我们可以先看一下周报到底是什么?

1. 周报是什么

从公司管理的角度来看 周报是公司流程化管理的一部分,是正式沟通地一种手段或方式,其目的是为了更好的向下管理和向上反馈。 作为管理者可以通过周报了解一线的情况,如项目的进展,工作的动向;作为普通员工可以通过周报系统性地表述一线的状况。

从个人成长的角度来看 周报是个人反思成长的载体,是自我管理的一种方式,其核心逻辑是:在过去一周你的时间花在了哪里,解决了什么问题,过程中有什么思考,个人有哪些成长。

2. 周报怎么写

2.1 明确受众和主题

写周报和写其它文档一样,需要明确要写的东西是给谁看的,会有一个目标或目的,大的思考结构逻辑如下:

对象:这个周报是写给谁看的,受众是谁?

主题:你想在周报里面主要写什么内容

目标/目的:为什么要写这份周报 / 希望周报受众了解什么 / 希望他/他们给予你什么帮助

在搞清楚以上这些问题后,基本上要写什么就确定了,目标确认,接下来就是要怎样达到这个目标。 针对不同的受众,需要有不同的逻辑。在职场中,看我们周报的人无外乎上级、团队/下属和自己,下面我们就这三个维度看看一份合格的周报应该怎么写。

2.2 写给上级的周报

写给上级的周报主要是向上汇报,向上管理,其主要作用是让你的上级清楚知道你/你的团队在这周主要做了什么,其关键有 4 点:

  1. 有成果 一周你的团队肯定有产出,挑重点或上级关注的点呈现,不要太细节,大的事项就可以了;
  2. 有数据 对于成果的展现尽可能做到具体而有数据,可衡量或可量化,以确保上级能精确了解状态和相信结果
  3. 有思考 作为管理者,思考团队的问题是你的本职工作,在周报中要特别体现这点;
  4. 有格局 有格局是指不要把自己的眼光只停留在自己的一亩三分地,至少尝试站在你的上级的角度来思考问题。

作为一个技术管理者,一个合格的周报大概如下:

  1. 核心事项同步,你的上级当前的 OKR/KPI 关联的事项,你作为一个信息源提供信息,因为你的上级需要通过你拿到一线的情况,对于核心事项中需要上级协助的点也一并体现出来,加粗,需要上级协助的点要明确具体,大概标准是上级看到了就知道自己要做什么才能帮助到你;
  2. 业务里程碑,记录在业务事项推进过程中的阶段性成果,以业务价值为主,对于有明显价值或者有明显变化的予以体现;
  3. 研发流程、效率和质量,记录研发管理过程中出现的流程变更,组织结构的变动,效率的改进、质量的优化和线上的问题等等,如研发需求延期,线上事故复盘总结,人员变更(离职,转岗,入职,并说明情况)。对于一些问题或较大一些的事项,建议以 STAR 原则表述,Situation(情景)、Task(任务)、Action(行动)和Result(结果),同时在后面附加相关文档,如果问题需要上级来协调,在这部分内容中用加粗等较明显的方式标出;
  4. 思考和总结, 这里主要是体现你的思考和总结,可能你会想我哪有那么多总结和思考,这是一个问题,但是是可以解决的问题。如果在一周中你有持续思考团队的价值,团队的问题,并把这些思考和问题记录下来,在周报中一定可以呈现;
  5. 人才培养 这一项根据实际情况来,如果有长期的人才培养专项,可以单列体现,如果只是间歇性的,考虑整合到第 3 项。

在写周报之前,需要阶段性和上级沟通确认他在关注哪些事情。因为随着时间的推移,关注点是会变化的,此时我们需要调整我们周报的内容。

2.3. 写给团队的周报

写给团队的周报主要是从你的角度来看整个团队做了什么?哪些做得好的?哪些做得不好?当前团队状态是怎样的?思考如何改进? 并把你所看到的内容表述给团队成员看,让整个团队了解我们的方向和进展。

写给团队的周报的逻辑大概如下:

  1. 工作内容和业务价值的关联和进展 我们在做什么,做的东西的进度如何,做的东西服务于哪个业务的哪个目标,将会产生哪些业务价值;
  2. 问题和卡点 过程中我们有遇到哪些问题或卡点,解决了没有?解决了,是如何解决的?没有解决,需要哪些努力或协助,现在进展如何。如一些人员的变动,组织流程的变更,公司级的变更周知,大家捅的娄子,线上的事故,需求延期等等;
  3. 里程碑 过程中我们有达成哪些激动人心的小目标,如某大功能上线,某业务增长超出预期,某基建阶段性产出等;
  4. 时间维度的交付逻辑 落到细节上,从时间维度看,我们这周在哪些业务线交付了哪些内容,下周要交付哪些内容,哪些内容会跨更长的周期;
  5. 状态 整体团队、业务等状态如何,团队成长如何;
  6. 思考和总结 过程中我们有哪些思考和总结。

团队的周报更多的是从团队管理者的角度来看问题,抓大放小,持续思考。

2.4. 写给自己的周报

其实我平时很少单独给自己写周报,一些要写给自己看的东西基本都在写给团队的周报和写给上级的周报中,但是如果只是写给自己看的话,也是可以单独拎出来的。

写给自己的周报,其目的是强迫自己思考,如果不思考,你的周报将会流水账式的,每周例行公式的写本周总结,下周计划。 写给自己的周报其核心是自我反省和个人成长,反思一周工作中的表现和思考,一周中自己的学习和成长。

个人周报大概逻辑如下:

  1. 本周重要产出 每个人的工作都是为企业创造价值,我们在对本周进行总结时,需要把与业务价值相关联的事项拎出来,关注重要的事项,最多列三项,并且 review 这些事项的进展,问题以及下周我们要解决的点;
  2. 下周重点事项 列出下周要做的重点事项,有些是从本周的重点事项中引申出来的,还有一些是新增的;
  3. 问题和思考 列出工作中的问题和卡点,把问题反馈出来,并把思考总结的方案也写出来;
  4. 总结和成长 对个人一周内的成长做一些总结,是否比上周更好一些了?在哪些方面有所进步,技术基础技能,软技能,知识性的?技能性的?这里是关系个人成长关键的一节。

于公问自己:规划的三件事情有没有做好?三件事是怎么做的?成果怎么样?下周应该怎么去规划?

于私问自己:相比上周你有进步吗?有投入时间提升自己吗?投入了多少时间?有没有系统性地去规划自己的成长?

3. 写周报中的术

3.1 如何提高写周报的效率

  1. 养成写工作经验笔记的习惯;
  2. 养成系统性地回复问题,并在临时文档中存下来的习惯;
  3. 养成写日报的习惯。

3.2 STAR 原则

STAR 原则即情景(Situation)、任务/目标(Task/Target)、行动(Action)和结果(Result) 四个英文单词的首字母组合,STAR 原则是结构化面试当中非常重要的一个理论,常用于面试过程中涉及实质性内容的谈话程序。

我们写周报和面试时类似,都有给一个不熟悉某块东西的人讲清楚一个事情的逻辑,在这个场景下 STAR 原则会让你事半功倍,其结构化表述如下:

情景(Situation):事情的背景是什么,在什么情况下发生的; 任务/目标(Task/Target):明确要做什么,目标在哪; 行动(Action):针对以上的情景和目标,做详细分析的,你采用了什么行动方式; 结果(Result):有什么可衡量的结果。

如果要表述的是事故或问题类的,可以把原因分析和后续规避方案等加上。

4. 其它注意事项

  • 尽量不要有数据类的报表,数据类的报表通过数据系统来解决;
  • 细节不要写,要有重点,有主次;
  • 流水账不要写,要有结构化的表述;
  • 请求帮忙和协助最好是符合 SMART 原则,协助的点要明确具体,大概标准是上级看到了就知道自己要做什么;
  • 抓大放小,放开平时讨论的细节,更多地对大目标大问题进行讨论,思考目标达成,业务价值等重要的问题;
  • 要有观点,要有重点,要有想法,要有业务,要有数据。

5. 结语

写作并不难,重要的是思考,对于周报也一样。

如果你不能对自己想要在周报中表达的内容和观点有清晰、准确的认知,那么你将根本无法写好周报。

如果你在带一个团队,如果你想在团队中执行周报的逻辑,那么先思考一下你的目的是什么? 是想让同学们养成工作计划/思考/总结的习惯?还是想让他们快速成长?还是想拿到一线的情况? 对于技术管理者来说,周报是一个管理动作,而我们在做管理的时候不要做无效的管理动作,思考一下本质的逻辑

写了这么多,斟酌反复,还是觉得有些想说的没有说出来,就这样吧。

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

做到这五点你就可以从容面对 35 岁危机

以前听到过这样一个故事:

两个人在森林里,遇到了一只大老虎,A 赶紧从背后取下一双更轻便的运动鞋换上。 B 急死了,骂道:“你干嘛呢,再换鞋也跑不过老虎啊!” A 说:“我只要跑得比你快就好了。”

从这个故事中你感悟到了什么?可能每个人的感悟不一样。我在这里看到最多的是:丛林法则,危机感,没有危机感将会是我们最大的危机

特别是最近经常有人说 35 岁危机,是否你有思考过 35 岁的危机的本质是什么?我认为 35 岁危机的本质是核心竞争力的不足。 那么如何应对这种危机呢,特别是作为一个技术管理者,可能随着年纪的增大,越发“年老色衰”,体力、精力可能都会有些跟不上,从而显示竞争力不足,我们如何破这个局呢?

如果能扎扎实实的做到以下 5 点,你将不会有 35 岁危机的焦虑。

1. 做一个成年人

这里的「成年人」概念最开始的出处是在介绍网飞的那两本书《奈飞文化手册》和《不拘一格:网飞的自由与责任工作法》。网飞文化第一条:「只招成年人」,真正的成年人在公司是一个有机的整体。 成年人有如下 4 个特质:

  1. 有能力安排好自己的时间;
  2. 不会只是抱怨问题,会自己去解决问题;
  3. 懂得纪律和规则的重要性;
  4. 面对一个巨大的难度,能够和一群合适的同事一起解决它,成功是最好的激励;

除此之外,咱们这里的成年人还包含以下的一些特点:

  1. 随着年纪的增长,情绪越发的稳定,对同级,对下级都一样的稳,当然,情绪稳定不是指没有情绪,该生气的时候还是要生气的,需要有目的的生气;
  2. 有事能扛事,遇事不怕事,是一个有担当的人,能够被大家所依靠,遇到事情的时候,上级能第一时间想到你,下级遇到问题的时候,也能想到你;
  3. 不急于名利,稳打稳扎,一步步往前走,不要在过程中问:我现在应该有什么样的名利,要有什么样的待遇,要有什么样的地位。「但行好事,莫问前程」
  4. 有自己的品牌,刻意在职场中建立自己的专业品牌,比如当说到你时,别人会说,技术大神,业务专家,脾气好,能解决问题等等?

2. 执行力强

说到执行力强,想起 18 年在即构的时候,LYY 老板推荐我重读的那本《致加西亚的一封信》,虽然这本书销量很惊人,但褒贬不一,于我来说,书中主人翁罗文的使命必达最是感动,但是对于执行前的一些规划,书中没有重点体现(其实是有的)。那么在职场中,一个执行力强的同学应该是怎样的呢?

  1. 执行前有目标,有规划,有方案;
  2. 执行中有反馈,有节奏,有坚持;
  3. 执行完有结果,有思考,有沉淀。

2.1 执行前有目标,有规划,有方案

最简单的,看一个人执行力强不强,就看他守不守时,比如大家一起去出游,约好了 10 点集合,A 匆匆忙忙,大家都在等他,最后以各种理由解释迟到的原因; B 早早的就到了,可能还慢悠悠的吃了个早餐,问他什么时候到的,9 点就到了,为什么这么早,他说这个点是上班高峰期,中间会不会堵车,是不是可能遇到一些异常之类的,这些都会影响到最后的结果,提前计划好,早点到,事情就会顺很多。

在上面这个例子中,B 同学有计划,有章法,大概率是一个执行力强的同学。在执行前他有目标,10 点集合,有规划,提前出发。 在职场中,当上级指派一个事情的时候,我们第一步是要弄清楚,老板要的是什么,需求是什么,而不是傻傻的直接开干。这里有一个常用的思维:黄金圈思维,如图所示:

黄金圈思维分为三个维度,最外面表层是「 what 层」,也就是做什么,指的是事情的表象特征;中间是「 how 层」,也就是怎么做的,是实现目标的一些途径;最里面是 「 why 层」,就是为什么做这件事。

一些任务更多的是表述的是 「 what 层」,比如给的是方案,此时我们需要多问一些为什么,找到最核心的需求,其最终要的是什么,这样往往事半功倍。在「耗子叔」很早的一篇文章里面特地提了一个类似的问题《X-Y PROBLEM》,大概意思是:有人想解决问题 X,没有去问怎么解决问题 X,而是去问解决方案 Y 应该怎么去实现和操作。我们常常在执行的时候犯类似的错误。

当我们需要解决某个问题,或者要搞定某件事情的时候,可以先问自己三个问题:

  1. 这是否是核心的诉求或根本原因?
  2. 有想好怎么去做,有分析过行业内有人遇到过类似的问题吗,如果有人遇到,他们是怎么做的?
  3. 有结合自己的实际情况去思考吗?有形成可执行的方案吗?

2.2 执行中有反馈,有节奏,有坚持

当我们确认了目标,方案后,下一步就是实际操作了,这个时候可能就会有同学问了,这不就是执行了吗?还有其它讲究吗?蒙着头一直做是一种执行的方式,但不是一个好的方式,我们在执行过程中,特别是当执行需要持续一定时间的时候,需要不停的反馈。

比如你是一个商业化的团队的负责人,带着几十号人,运营到产品,到研发都有,在一个季度开始的时候已经和老板确认了目标,在执行的过程中,当有一些好的突破,应该和反馈给老板;或者有难题,拿着问题和方案和老板沟通;也可能业绩四平八稳,此时也可以定时汇总反馈给老板,让他知道一切正常,这样就让你的上级会觉得事情在控制之中。

在执行的过程中,我们经常会遇到困难,对于一个执行能力强的人,困难只会是路上的坑,没有趟不过去的,坚持到底,使命必达。 关于执行过程中的反馈、控制和坚持,我印象最深的还是在大学的时候选修课的老师给我们放的余世维的讲座视频,已经不记得是哪场培训了,只记得他举了他在日本航空的工作的例子,故事大概是这样的:

一次,有 4 个日航的本部长(相当于区域负责人),要到台湾东边的一个小岛南屿去度假。 南屿岛很小,上面只有两个饭店,而公司要求给 4 个本部长安排 4 个连在一起的套房,而且套房要面对太平洋。

余世维立刻打电话联系,饭店答复说一间都没有。他马上给东京发电报(当时电报是最快的联络方式),说一间都没有, 但他会努力去找。东京方面的回答只有两个字:了解。

余世维继续找,后来找到了两间,一个饭店一间。他马上致电东京:现在找到两间,可惜不在同一个饭店, 但我会继续努力找。东京的回电仍然是两个字:了解。

余世维继续协调查找,终于找到了 3 间,在同一个饭店里。他给东京方面发报,回答依然是那两个字。 报告之后,余世维就乘小飞机飞到南屿。向服务员打听:旁边的房间是谁住的呢? 服务员说:“那是一对夫妇,马上要来度假,今天下午就要来登记入住。” 余世维就坐在饭店等。那一对夫妇到了,带了一个孩子。他马上走过去自我介绍:“我是日本航空的,我非常喜欢您的房间, 您能不能把它让给我?”

那位先生说:“我为什么要让给你?” “您说的没错。不过,我在隔壁替您定下一间套房,面对太平洋,傍晚可以看到夕阳,波涛在您的窗下澎湃, 远处有千帆点点。关键是房费我已经付了,您可以免费入住。”余世维提出了自己的条件。 那位先生半信半疑:“真有这样的事?” 在确定无误之后,那对夫妇带着孩子,向隔壁房间走去。

余世维马上给东京发电报:4间套房全部找到,在南屿的绿岛饭店3楼,4 间套房连在一起,面对太平洋。 这次,东京方面的回电多了两个字——“谢谢”。

没多久,4 个休假的本部长到了。他们轻轻地拍着余世维的肩膀,说:“余桑,你做事很像我们日本人。” 余世维并不觉得“像日本人”是多么光荣的事情。但在日本人看来,这是极高的赞赏,是一种极大的荣耀。 整件事,余世维一共给东京方面发了 7 次电报,主动报告工作进度。那个免费的房间是他自己掏的腰包, 花了他半个月的薪水。其中的辛苦,东京方面并不了解。 但他认真做事的精神和主动报告的态度,给日航高层留下深刻的印象,很快,他就得到了晋升的机会。

2.3 执行完有结果,有思考,有沉淀

我们常说「凡事有交代,件件有着落,事事有回音」,这是指我们做事要有结果。 有结果分为两种:

  1. 最终结果,比如在约定的时间内达成了目标,或者延期了,此时需要告诉对方原因,解决方案以及最终延期到什么时候,或者根本就无法完成,这种情况应该早点告知,特别是对于老板,不要让这个结果变成惊吓;
  2. 中间结果,这个就是我们前面说的执行过程中的反馈,但是也属于结果的一种:阶段性的结果。

在一件事情结束后,特别是一件略大一些的事情,我们需要对这一件事情进行复盘,开放心态,对于整个事情的过程和结果进行复盘,看下好在哪里,不好在哪里,帮助自己和一起执行的小伙伴在过程中发现问题,并找到问题的背后原因,制定下一步改进计划,通过解决问题最终提高大家的能力。如果可以,提炼出做事情的方法论或固化的机制,将经验沉淀下来。

一个好的执行,基本上都能做到 「 PDCA 循环」。简单说一下 PDCA 循环,PDCA 是美国质量管理专家沃特·阿曼德·休哈特(Walter A. Shewhart)首先提出的,由戴明采纳、宣传,获得普及,又称戴明环。PDCA 循环包含四个阶段,即 Plan (计划)、Do (执行)、Check (检查) 和 Act (处理)。在管理活动中,要求把各项工作按照作出计划、计划实施、检查实施效果,然后将成功的纳入标准和固化为机制,不成功的留待下一循环去解决。如图所示:

3. 问题终结者

技术管理平常都是围绕「解决问题」而展开,从发现问题,认识问题,分析问题,最终解决问题,这就是我们常说的「发现问题解决问题」。

3.1 发现问题

作为管理者,在大家都低头走路的时候,你要多抬头看路。这里所说的看路一个是指战略规划,另一个是指发现问题,那么在哪里可以发现问题? 我们常见的发现问题的方法或位置如下:

  1. 外部用户、内部员工投诉或反馈的问题
  2. 1v1 聊天,绩效聊天,日报,周报等沟通渠道反馈的问题;
  3. 自建的一些质量监控报告,自动化测试报告,自动构建的结果等;
  4. 系统的告警、线上的事故;
  5. 定期观察业务数据,在分析数据过程中发现的差异,这里的差异可能是时间对比的差异,部门间的差异,和友商业对比的差异等,从这些差异中找到问题,这个发现问题的过程可以依赖于大数据平台,做一些观测指标;、
  6. 工作氛围相关问题,这个偏向于个人现场的感受;

在以上发现问题的过程中,我们需要用到系统化的思维,多问一些为什么,对问题时刻保持敬畏和危机感。

3.2 解决问题

解决问题笼统的包括认识问题,分析问题和解决问题,主要分为 6 步:

  1. 认识和分析问题,这里不仅仅是指问题是什么,有时候我们发现的问题只是表象,使用前面的「黄金圈思维」,多问问为什么,找到隐藏到冰山下真正问题,全面且客观的看问题。并且要找到问题的背景和出处,大环境是怎样的,利益相关有哪些,问题解决的价值是什么等等。
  2. 集思广益,他山之石,尽可能找到你可以找到的解决方案。
  3. 评估解决方案的优劣,必要项,可选项及其权重,对可选项评分,量化,加权汇总,选出最优方案。
  4. 对优选出来的方案进行全面的风险分析,对可能出现的风险制定风险应对措施。
  5. 执行方案,解决问题。
  6. 评估问题解决的结果,并复盘整个过程。

作为一个问题的终结者要能快速的发现问题,并且要发现问题的本质,有章法的从根本上解决问题,并形成一定的机制来保证问题不再重复出现。快速解决短线问题,有规划地解决长线问题。

4. 躬身入局

躬身入局是罗胖在 2019 年的跨年演讲中讲的一个故事,这个故事最开始是曾国藩讲的。 故事是这样的:

两个农人,挑着沉重的担子,相遇在农田间狭窄的田埂上。他们谁也不愿意相让,因为那样的话,想让的那人就要一脚踩到泥泞的水田里,沾一脚泥。他们就那样顶上了,谁也不让谁。

作为一个旁观者的你该如何相劝呢?我们能想到的是:退让一步,海阔天空,要不都走不了。其实大多数人,有时候脑子里想的就是:“我凭什么要让你?大不了都不走,看谁犟得过谁!”

曾老先生从另一个角度提出了解决问题的方法——做一个躬身入局的人: 旁观者跳入水田,接过其中一个人的担子,让他先过。这样,问题就解决啦。

这也就是曾老先生所说的:”所谓天下事,在局外呐喊议论总是无益,必须躬身入局,挺膺负责,方有成事之可翼。“

何为做事之人?

不是置身事外,指点江山。而是躬身入局,把自己放进去,把自己变成解决问题的那个人。

躬身入局是对一个管理者基本的要求,是对其执行力的要求。真正的执行力是深入业务场景,和产品,运营、开发小伙伴在一起,共同解决问题、共同克服困难、共同面对挑战、共同承担责任。败则拼死相救、胜则举杯同庆。时时刻刻思考“自己在团队发展过程中扮演什么角色”这个核心问题,以及如何把深度思考后的结论付诸行动,持续迭代。

一个管理者带一个团队要时刻思考如下的三个方面的问题:

  1. 团队变化
    • 有设定有挑战的目标并带领团队一起达成吗?
    • 有帮助其它兄弟部门完成相关目标吗?
    • 在下属遇到问题时有帮他们解决吗?
    • 有帮助下属成长并给团队带来了好的变化吗?
  2. 技术变化
    • 有给技术架构带来了哪些变化?
    • 有提升研发的效率和质量吗?
    • 有思考技术架构的难题并解决吗?
  3. 业务价值
    • 有给业务带来了哪些价值?
    • 有能做到和别人不一样的地方吗?

5. 终身学习

曾国藩曾写到:“盖世人读书,第一要有志,第二要有识,第三要有恒。有志则断不甘为下流;有识则知学问无尽,不敢以一得自足,如河伯之观海,如井蛙之窥天,皆无识者也;有恒则断无不成之事。此三者缺一不可。”

翻译到现在说我们读书要具备三个点:

  1. 要有方向,向上的方向,不自甘落在人后;
  2. 要有见识,眼界,要有自己独立思考和独立判断的能力;
  3. 要坚持,行百里者半九十。

我理解的终身学习,是一种态度,对于知识保持着天然的敬畏和谦卑,以虚心的状态不断学习;是一种价值观,坚持长期主义,做时间的朋友;也是一种活着的方式。

终身学习所希望我们做的,并不是为了让我们变得高深莫测,而是让我们拥有好奇心,知道自己不知道。好奇心让我们能有极强的动力地去追问关于这个世界的真理。

后记

絮絮叨叨说了这么多,回到最开头的故事,从这个故事里面我们还看到了:机会从来都是留给有准备的人。你准备好了吗?

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