10倍程序员的思考模型

本文共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(我们打算怎么去?)

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

以终为始,确定好终极目标;

任务分解,找到实施路径;

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

反思复盘,保存思维框架的活力;

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

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

你可能感兴趣的:(10倍程序员的思考模型)