高效程序员工作法(二)

前言：

  本篇博客内容来源自：极客时间课程《10x程序员工作法》处于学习记录。将个人认为比较重要的知识点进行摘抄记录。有兴趣的同学去极客时间学习完整课程。

10x程序员工作法_开发效率_10倍效率-极客时间

---

一、 精益创业：产品经理不靠谱，你该怎么办？

 精益创业到底说的是什么呢？其实很简单。我们不是要面向不确定性创造新事物吗？既然是不确 定的，那你唯一能做的事情就是“试”。

 怎么试呢？试就要有试的方法。精益创业的方法论里，提出“开发（build）- 测量（measure）- 认知（learn）”这样一个反馈循环。就是说，当你有了一个新的想法（idea）时，就把想法开发成产品（code）投入市场，然后，收集数据（data）获取反馈，看看前面的想法是不是靠谱。

精益创业提出一个非常重要的概念，最小可行产品，也就是许多人口中的 MVP（Minimum Viable Product）。简言之，少花钱，多办事。

精益创业提供给我们的是一个做产品的思考框架，我们能够接触到的大多数产品都可以放在这个框架内思考。

一句话总结：

默认所有需求都不做，直到弄清楚为什么要做这件事。

---

二、 解决了很多技术问题，为什么你依然在”坑”里？

  你在项目里打杂，你只能关注到一个具体的任务，而项目主力心目中是整个系统。虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考。

跳出程序员角色思维，扩大自己工作的上下文

虽然我不是项目主力，但不妨碍我去更深入地了解系统全貌；虽然我不是项目负责人，但不妨碍我去了解系统与其他组的接口；同样，虽然我不是项目经理，但我可以去了解一下项目经理是怎样管理项目的；虽然我不是产品经理，但了解一个产品的设计方法对我来说也是有帮助的。

当你对软件开发的全生命周期都有了认识之后，你看到的就不再是一个点了，而是一条线。

现在你知道为什么你的工作总能让老板挑出毛病了吧！没错，工作的上下文不同，看到的维度差异很大。单一维度的思考，在多维度思考者的眼里几乎就是漏洞百出的。

程序员总喜欢用技术去解决一切问题，但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案，很多时候原因在于程序员被自己的思考局限住了。

   不同角色工作真正的差异在于上下文的差异。在一个局部上下文难以解决的问题，换到另外一个上下文甚至是可以不解决的。所以说无论单点有多努力也只是局部优化，很难达到最优的效果。

   想把工作做好，就需要不断扩大自己工作的上下文，多了解一下别人的工作逻辑是什么样的，认识软件开发的全生命周期。扩大自己的上下文，除了能对自己当前的工作效率提高有帮助，对自己的职业生涯也是有好处的。随着你看到的世界越来越宽广，得到的机会也就越来越多。

一句话总结：

扩大自己工作的上下文，别把自己局限在一个程序员的角色上。

---

三、 为什么说做事之前要先进行推演？

结果是重要的，然而、通向结果的路径才是更重要的。

对比我们的工作，多数情况下，即便目标清晰，路径却是模糊的。所以，不同的人有不同的处理方式。有些人是走到哪算哪，然后再看；有些人则是先推演一下路径，看看能走到什么程度。

• 在做一个产品之前，先来推演一下这个产品如何推广，通过什么途径推广给什么样的人；
• 在做技术改进之前，先来考虑一下上线是怎样一个过程，为可能出现的问题准备预案；
• 在设计一个产品特性之前，先来考虑数据由谁提供，完整的流程是什么样的。

在软件开发过程中，我们就假设软件已经就绪，看就绪之后，要做哪些事情，比如，如何上线、如何推广等等，这样的推演过程会帮我们发现前期准备的不足之处，进一步丰富我们的工作计划。为了不让我们总在“最后一公里”摔跟头，前期的推演是不可或缺的，也是想让团队进入有条不紊状态的前提。

一句话总结：

在动手做一件事之前，先推演一番。

---

四、 你的工作可以使用数字衡量吗？

一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见（Insight），洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据。

结合着“以终为始”的思考，如果我们可以在一开始，就设计好测量工作有效性的指标，那么就可以更有目的性地去工作了。

而如果我们习惯了用数字去思考，就可以在很多方面让数字帮助我们。我举了几个小例子，比如：基于数据进行技术决策、预先设定系统指标，以及发现系统中的问题等等。希望你也可以把数字思维带到你的日常工作中。

一句话总结：

问一下自己，我的工作是不是可以用数字衡量

---

 五、迭代0：启动开发之前，你应该准备什么？

 

所谓迭代 0，就是在迭代 1 之前的一个迭代，所以，我们可以把它理解成开发的准备阶段。

根据我的经验，对比这个清单，大多数新项目都在一项或几项上准备得不够充分。即便你做的不是一个从头开始的项目，对照这个清单，也会发现项目在某些项上的欠缺，可以有针对性地做一些补充。

 一句话总结：

设计你的迭代 0 清单，给自己的项目做体检。

---

 总结：

在这个模块中，我们学习到了一些行业最佳实践。

• DoD，确定好完成的定义，减少团队内部的理解不一致。
• 用户故事，细化出有价值的需求。
• 持续集成，通过尽早集成，减少改动量，降低集成的难度。
• 精益创业，减少过度开发不确定性产品带来的浪费。
• 迭代 0，在项目开始之前，做好一些基础准备。

还学习到一些重要的思维转变。

• 任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）。
• 在更大的上下文内发现自己的“终”。
• 通过推演，找到通往“终”的路径。
• 用可度量的“数字”定义自己的“终”。