解读10x程序员工作法-以终为始

解读10x程序员工作法-以终为始

以终为始

以终为始：如何让你的努力不白费？

网上流传着一个帖子，亚马逊 CTO 介绍亚马逊是如何开发一项产品的，简单来说，他们采用向后工作的方法，开发一项产品的顺序为：

• 写新闻稿；
• 写 FAQ（常见问题解答）；
• 写用户文档；
• 写代码。

DoD的价值：你完成了工作，为什么他们还不满意？

DoD（Definition of Done，完成的定义）

• DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况。
• DoD 的检查项应该是实际可检查的。
• DoD 是团队成员间彼此汇报的一种机制。
• 当我们有了 DoD，做事只有两种状态，即“做完”和“没做完”。

我们本着“以终为始”的方式做事情，DoD 让我们能够在一开始就把“终”清晰地定义出来。

接到需求任务，你要先做哪件事？

我认为就是用户故事的关键点：验收标准，它可以清晰地定义出需求边界。

验收标准非常重要的一环是异常流程的描述。

验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量。

在做任何需求或任务之前，先定好验收标准。

持续集成：集成本身就是写代码的一个环节

解读10x程序员工作法-以终为始

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

精益创业就是在尽可能少浪费的前提下，面向不确定性创造新事物。

解读10x程序员工作法-以终为始

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

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

技术是一把利刃，程序员相信技术可以改变世界，但并不是所有问题都要用技术解决。花大力气去解决一个可能并不是问题的问题，常常是很多程序员的盲区。

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

对比我们的工作，多数情况下，即便目标清晰，路径却是模糊的。

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

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

从数据出发：

• 首先是基于数字进行技术决策。
• 其次是一个准备上线的案例。
• 再次，看一个从数字中发现问题的例子。

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

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

解读10x程序员工作法-以终为始

如何管理你的上级？

领导要求的，无力反驳怎么办？

我们要敢于管理上级。

• 第一，管理上级的预期。这个过程，相当于我把自己看到的问题暴露给上级，让他选择。
• 第二，帮助上级丰富知识。
• 第三，说出你的想法。这其实就是我们熟悉的一个最简单的道理：会哭的孩子有奶吃。

产品经理总拿老板说事，怎么办？

实际上，老板要求的是方向，不是产品特性。大老板不会安排那么细的细节。所以，一个产品经理该做的事就是把老板给的方向，变成一个个可以实现的产品特性，他要分析其中的合理与不合理。

不合理的部分应该是他和老板去沟通的，而不是让开发团队来实现。

别人能做的，我们也要做

第一，竞争对手有的产品，我们也要有。

“抄”不是问题，问题是无脑地抄。

所以，如果你的产品经理只想无脑抄袭，本质上，他就是在偷懒，没干好他该干的活。

第二：人家能做到，说明技术上是可行的。

要做什么是需求，怎么做是技术。与产品经理要确认的是，这个需求是不是合理，该不该做。技术上能否实现，这是开发团队要考虑的事情，并不是产品经理说事的理由。

1.png

获取以上Java高级架构最新视频，欢迎

加入Java进阶架构交流群：142019080。直接点击链接加群。https://jq.qq.com/?_wv=1027&k=5lXBNZ7