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（我们打算怎么去？）

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

• 以终为始，确定好终极目标；
• 任务分解，找到实施路径；
• 风险管控，解决过程中可能出现的问题；
• 反思复盘，保存思维框架的活力；
• 自动化，解决与机器打交道出现的问题。

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

作者：张飞洪

来源：cnblogs.com/jackyfei/p/15040146.html