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