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

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

一个组织最有限且不可再生的资源是什么，就是成员的工作时间。 对于一个互联网企业或软件企业来说，人力成本是最大的成本。 而作为一个技术团队的管理者，其最大的作用是如何让研发同学的时间能产生最大的价值，也就是如何让这些成本的 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 矩阵表能较好地解决人员管理的问题。

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

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

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

周一做了 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

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

两个人在森林里，遇到了一只大老虎，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 个连在一起的套房，而且套房要面对太平洋。

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

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

余世维继续协调查找，终于找到了 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