本文共2568个字，预估阅读时间10分钟

01 效率问题

程序员越高效产出越高，产出越高能力越强，于是形成一个增强环路。但是，就我观察，现实中的程序员，大部分没有用心去思考学习效率问题。

1975 年，弗雷德里克·布鲁克斯（Frederick Brooks）出版了软件行业的名著《人月神话》，他给出了一个统计结果，优秀程序员的开发效率是普通程序员的 10 倍。

40 多年过去了，这个数字得到了行业的普遍认同，成为 10x 程序员是很多程序员的追求。那么，问题来了，作为一个程序员，应该如何提升我们的工作效率呢？

02 思维框架

在打磨10x效率之前，我们先问自己三个问题：

我们想去哪儿？

我们现在哪儿？

我们打算怎么去？

我们可以试着回答一下：

我想成为一名架构师

我现在只是一个菜鸟

我打算通过半年培训入门架构设计

或者

我想从技术转产品经理

我目前对产品经理一无所知

我打算拜师学艺两个月入门产品经理

不管是谁，不管做的什么职业，似乎都可以用这种三段式的提问来思考问题。这其实是一种思维框架。虽然很简单，但是很实用，有时候我发现用在孩子的教育上也很管用，比如

暑假我要预习下个年级的语数英

我现在处在二年级下学期的水平

我打算通过项目管理的方式来完成任务

为什么是这种思维框架呢？

去哪儿明确的是目标和方向

现在在哪儿明确的是现状和坐标

打算怎么去要明确的是方法论和思维路径。

反过来：

如果你对未来是茫然的，尽管你也知道要努力，但劲儿该往哪里使呢？如果使劲的方向不对，那么你越使劲儿，可能会在错误的路上跑得越远。

如果目标明确，你却不实事求是，从自己实际出发，你可能半路就掉进坑里。

如果明确了目标，也知道了现状，但是方法太lower，思维混乱，结果可能是事倍功半。

大家可以试着用这个思维框架，或者变体，或许你不需要记那么多，但是没关系，你只要记住上面这张图。

03 改变询问对象

我们通过平时和产品经理的沟通来进一步实践该框架。在上面的假设里，我们问的对象是自己，在和产品经理沟通的过程中，我们也可以改变询问对象：

为什么要做这个功能，他会给用户带来什么价值？

现在没有吗，是不是一定要开发，还是伪需求？

用户会怎么使用这个功能，什么场景下使用，怎么用？

如果产品经理能够回答好这些问题，说明他基本上已经把这个工作想得比较清楚了，这个时候，我才会放心地去了解后续的细节。

我们用思维框架对照一下，为什么要这么问？一般开发前我们是知道目前系统现状的，所以，我比较关心最后的目标，这里“为什么要做这个功能”就是在问目标，“给用户带来什么价值”是在问这个目标的合理性，确保不是伪需求。接下来我会关注实现路径，用户会怎么用，是否有其他的代替手段，我需要了解产品经理设计的思考过程，是慎重考虑过的还是拍脑袋想出来的。衡量有效性，目的是要保证我的工作不被浪费。

04 实践原则

上面我们明白了框架的使用方法，也许你会说我明白了为什么要这么做，但是具体的问题要怎么问，有没有实践原则呢？我们可以考虑如下5个原则：

以终为始；

任务分解；

风险管理；

反思复盘

自动化。

这些原则其实和我们的思维框架是一脉相承的关系：

以终为始就是在工作的一开始就确定好自己的目标，我们需要看到的是真正的目标。

任务分解是将大目标拆分成一个一个可行的执行任务，工作分解得越细致，我们便越能更好地掌控工作，这是路径。

风险管理是确保过程可控，多方交流渠道是畅通的，意见是一致的，要减少因为理解偏差导致的工作疏漏。

反思复盘是为了迭代工作方法，完善工作中的不足，为下一轮循环做更好的准备。

自动化是程序员的优势，能靠机器做的事情尽量不要手工执行，这是我们的工作最值得优化的地方。

以上原则其实是参考了项目管理的方法，当然你可以增加变种，但是主干是不变的。

如表格所示：

现在在哪儿自个清楚，我有什么，我放弃什么，如果不清楚就要敲打自己的头了。

想去哪儿就是以终为始，我们要交付什么结果在里程碑的deadline？

打算怎么去就是手段和实现路径，这里借鉴的项目管理的方法。

知道了这些原则，我们看下最佳实践：

产品经理把要做的功能清单摆在我们面前，站在以终为始的角度，我需要了解真正的目标是什么，所以，我会关心为什么要做这个功能。为了保证目标是有效的，我会关心它给用户带来的价值。

有了任务分解的视角，我需要将一个大的目标进行拆解，如果我要达成这个目标，整体解决方案是远远不够的，我需要把任务分解成一个一个小的部分。所以，我会关心一下具体的使用场景。一方面，我会了解到更多的细节，另一方面，当时间紧迫的时候，我会和产品经理来谈谈究竟优先实现哪个场景。

为什么要学会风险管控？因为我需要明确，自己是否真正理解了产品经理提交的需求，自己真的和产品经理交代的内容一致？最坏的情况会是怎样的，自己能否承受的了？风险管理的目的是确保任务按照预定的轨道顺畅进行。

有些人会好奇，为什么没有沟通反馈？沟通的目的是达成一致，立即行动。如果沟通出现问题，那也是风险管控的一种方式，所以这里没有独立出来。

其实风险管控涉及的面非常广，贯彻整个研发生命周期，因为需求变化有风险、设计可能出现漏洞、开发有BUG、测试不完整等等，怎么强调都不为过。

自动化是手段，我们做的方案通常是一个自动化方案，但我们需要了解这个方案没有自动化之前是怎么做的。如果不自动化，用户会怎么用？所以，我会关心是不是还有其它替换方案，比如，买一个现成的服务。

反思复盘是流程的一个重要闭环，如果缺少了这一环节，可能整个思维框架由于缺少流量注入就固化、消亡了。

05 总结

大多数人工作低效是由于缺乏有效的思维框架，加上工作中偶然出现的复杂度，我们“真实”的工作效率自然会得大打折扣。

而想要减少偶然复杂度的消耗，就要了解一些高效的工作方式和行业的最佳实践，而这一切是可以用统一的框架进行串联思考。

运用这个思考框架，我们需要问自己三个问题：

Where are we（我们现在在哪儿？）

Where are we going（我们想去哪儿？）

How can we get there（我们打算怎么去？）

为了把这个框架应用在我们程序员的工作中，我给了你几个个实践原则：

以终为始，确定好终极目标；

任务分解，找到实施路径；

风险管控，解决过程中可能出现的问题；

反思复盘，保存思维框架的活力；

自动化，解决与机器打交道出现的问题。

如果今天的内容你只能记住一件事，那请记住：面对问题时，经常用思维框架问问自己，我要去哪儿，我现在在哪儿，我应该如何过去。