马斯克的五步工作法
- 质疑每项要求。提出任何一项要求时，都应该附上提出这一要求的人。永远不要接受一项来自某个部门的要求，比如来自“注务部门”或者“安全部门”的要求。你必须知道提出这项要求的人的名字。接下来你应该质疑它，不管这个人有多聪明。聪明人提出的要求才是最危险的，因为人们不太可能质疑他们。这件事要一直做下去，即便这项要求来自我马斯克本人。质疑后，大家就要改进要求，让它变得不那么愚蠢。
- 删除要求当中所有你能删除的部分和流程，虽然你可能还得把它们加回来。事实上，你如果最后加回来的部分还不到删除部分的10%，那就说明你删减得还不够。
- 简化和优化。这应该放在第2步之后，因为人们常犯的错误就是简化和优化一个原本不应该存在的部分或者流程。
- 加快周转时间。每个流程都可以加快，但只有遵循了前三个步骤之后才能这么做。在特斯拉工厂，我错误地把很多精力花在加快生产流程上，后来我才意识到有些流程原本就应该被拿掉。
- 自动化。在内华达工厂和弗里蒙特工厂犯下的一个大错就是我一开始试图将每个步骤进行自动化改造。我们本应该先质疑所有要求，删除不必要的部分和流程，把问题筛出来、处理掉，然后再推进自动化。
作为程序开发者，马斯克的五步工作法给我很多启发。让我从软件开发的角度来思考：
- 质疑每个需求的来源和必要性
在开发中，我们经常收到各种功能请求——来自产品经理、客户、老板或其他部门。马斯克提醒我们要追问：是谁提出的？为什么需要？
很多时候”产品部门说要加这个功能”或”用户要求的”这种模糊表述掩盖了真实需求。可能只是一个产品经理的个人想法，或者只是一个用户的特殊场景。我应该找到具体的人，了解背景，然后质疑：这个功能真的解决了核心问题吗？有没有更简单的方式？
特别危险的是来自技术大牛或架构师的要求——因为他们的权威性，我们往往不敢质疑，但这可能导致过度设计。 - 删除不必要的代码、功能和流程
这是最反直觉但最重要的一步。我们总是倾向于添加——添加新功能、新抽象层、新工具、新流程。但代码越多，维护成本越高，bug越多。
我应该问：这个功能真的有人用吗？这个抽象层真的简化了问题吗？这个微服务真的有必要吗？这个代码审查流程真的提高了质量吗？
如果删除后又加回来不到10%，说明之前有90%是浪费。这个比例让人震惊，但可能是真实的。 - 简化和优化现有系统
只有在确认某个部分确实需要存在后，才去优化它。我们经常犯的错误是：花大量时间优化一个本不该存在的功能，重构一段本该删除的代码，或者为一个过度复杂的架构编写精巧的解决方案。
先删减，再简化。 - 提高开发和部署速度
缩短编译时间、加快CI/CD、提升测试速度——这些都很重要，但前提是流程本身是必要的。如果某个测试覆盖的是无用功能，加快它只是在浪费资源上更高效而已。 - 自动化是最后一步
自动化一个糟糕的流程，只会得到一个快速运行的糟糕流程。我见过太多团队急于引入CI/CD、自动化测试、DevOps工具，却没有先质疑：我们构建的东西对吗？流程合理吗？
先让流程正确且精简，再自动化它。