软件行业的名著《人月神话》出版, 书中提到一个很有意思的结论: 优秀程序员的开发效率是普通程序员的 10 倍 .40 多年过去了, 这个数字得到了行业的普遍认同, 成为 10x 程序员成为很多程序员的追求.
但工作产出并不只是由编码效率决定的, 一些不恰当的工作方法, 在很大程度上影响着你的产出. 那么, 10x 程序员究竟是如何思考问题的?
一个思考框架
这个是一个看似简单, 但却非常有效的思考框架, 它已经成为我工具箱里一件非常称手的思考工具. 这个思考框架包括三个问题, 如果一个人能够清晰地回答出这三个问题, 通常意味着他对要做的事有着清晰的认识.
- Where are we?(我们现在在哪?)
- Where are we going?(我们要到哪儿去?)
- How can we get there?(我们如何到达那里?)
这三个问题实际上是帮我们确定:
现状
目标
实现路径
思考框架的应用
在实际的工作中, 这个思考框架会帮助我更好地了解自己的工作. 比如, 当一个产品经理给我交代一个要开发的产品特性时, 我通常会问他这样一些问题:
为什么要做这个特性, 它会给用户带来怎样的价值?
什么样的用户会用到这个特性, 他们在什么场景下使用, 他们又会怎样使用它?
达成这个目的是否有其它手段? 是不是一定要开发一个系统?
这个特性上线之后, 怎么衡量它的有效性?
如果产品经理能够回答好这些问题, 说明他基本上已经把这个工作想得比较清楚了, 这个时候, 我才会放心地去了解后续的细节.
四个思考原则
上面的思考框架, 让你明白了为什么要提出问题, 那么具体问题要怎么问呢? 你需要遵循下面这四个思考原则:
以终为始, 确定好真实目标;
任务分解, 找到实施路径;
沟通反馈, 解决与人打交道出现的问题;
自动化, 解决与机器打交道出现的问题.
以终为始, 即在工作一开始就确定好目标. 注意, 你需要看到真正的目标, 而不是把别人交代给你的工作当作目标. 可以看出, 这个原则在帮助我们回答思考框架中 "Where are we going?"(我们要到哪儿去?) 这个问题.
任务分解, 是指将大目标拆分成一个一个可行的执行任务, 工作分解得越细致, 我们越能更好地掌控工作. 它是帮助我们回答思维框架中 "How can we get there?"(我们如何到达那里?) 的问题.
沟通反馈, 是疏通与其他人交互的渠道. 一方面, 我们保证信息能够传达出去, 减少因为理解偏差造成的工作疏漏; 另一方面, 也要保证我们能够准确接收外部信息, 以免因为自我感觉良好, 阻碍了进步.
自动化, 就是将繁琐的工作通过自动化的方式交给机器执行, 这是我们程序员本职工作的一部分, 我们擅长的是为其他人打造自动化的服务, 但自己的工作却应用得不够, 这也是我们工作中最值得优化的部分.
四个思考原则的应用
怎么把这四个原则用在工作中呢? 我们回过头来看一下前面的场景, 产品经理把要做的产品特性摆在我面前.
站在 以终为始 的角度, 我需要了解真正的目标是什么, 所以会关心 为什么要做这个特性 , 为了保证目标是有效的, 会关心 它给用户带来的价值 .
有了 任务分解 的视角, 我需要将一个大的目标进行拆解, 如果我要达成这个目标, 整体解决方案是远远不够的, 我需要把任务分解成一个一个小的部分. 所以, 我会关心一个一个 具体的使用场景 . 一方面, 我会了解到更多的细节, 另一方面, 当时间紧迫的时候, 我会和产品经理沟通究竟优先实现哪个场景.
为什么要学会 沟通反馈 ? 因为我需要明确, 自己是否真正理解了产品经理提交的需求, 所以, 我要不断地问问题, 确保自己的理解和产品经理交代的内容一致. 另外, 我也需要保证我的产品做出来确实能够达到目标. 因此, 我关心它 上线后的衡量手段 , 毕竟这个行业里有太多代码上线后, 从来没有运行过.
自动化的角度很有意思, 我们做的方案通常是一个自动化方案, 但我们需要了解这个方案没有自动化之前是怎么做的. 如果不自动化, 用户会怎么用? 我会关心是不是还有其它替换方案, 比如买一个现成的服务如何? 因为很多需求的提出, 往往只是因为我们有了一个开发团队而已.
或许你在疑惑, 说我问的这些问题似乎已经 "超纲" 了, 远不是一个普通程序员应该关注的范畴. 但这就是真实世界, 它不像考试一样, 有一个标准答案.
来源: http://www.jianshu.com/p/d73f672849fc